Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6-toolchain, 2016-01-17

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
04:44 autarch I think I have a more or less working Test::Stream
04:45 autarch and by more I mean it has events, a Test.pm6-alike sub exporter, and it has a context system for making sure that test events appear to come from the place where you call ok() rather than inside the ok() sub or elsewhere
04:45 autarch and by less I mean no built-in IPC support and it could probably use more tests
04:46 autarch and it has no docs yet
05:05 MadcapJake joined #perl6-toolchain
05:05 yurivish joined #perl6-toolchain
05:06 yurivish left #perl6-toolchain
09:23 pnu joined #perl6-toolchain
09:39 nine Sounds like great progress :)
11:09 jdv79 joined #perl6-toolchain
11:10 jdv79 what did i miss?
11:11 stmuk_ joined #perl6-toolchain
11:11 azawawi joined #perl6-toolchain
11:11 azawawi hi
11:12 azawawi on windows, i want to depend on Alien::OpenCV::Windows to install the DLL . On unix, i need LibraryMake but not on windows
11:12 azawawi basically i need "depends" in META.info to be platform-specific
11:15 jdv79 i'm not aware of that being a thing.  maybe there's a better place to make that distinction.
11:15 masak I redirected azawawi here because I wasn't aware of any solution. it sounds like a topic for this channel.
11:16 masak maybe start by asking: is there such a mechanism for CPAN?
11:17 jdv79 yeah, i can't recall ever seeing that done in that manner but i could be wrong.  isn't there an escape hatch hook or something?
11:18 jdv79 perpahs that would be done with "dynamic config" in p5 world
11:18 jdv79 but i just came of hibernating for a couple weeks so probably best to not pay much attention to me:)
11:19 azawawi This is a real-life scenario. On unix, you can tell the user to 'sudo apt-get install libfoo-dev" and then use LibraryMake to build it
11:20 azawawi On windows, things are different and asking the user to get opencv zipped archive then extract and set an environment variables is a bit too much
11:20 azawawi s/variables/variable
11:23 jdv79 for now maybe panda's Build.pm feature can help you
11:24 jdv79 i don't know much about it yet.  sorry if that's not helpful.
11:26 azawawi no problem i was just thinking about the distribution footprint (+3.24MB uncompressed DLL) and windows compatibility.
11:26 azawawi i wanted a cleaner solution
11:29 jdv79 azawawi: doesn't seem that dirty to me.  either bundle it or fetch it on the spot or require user action.
11:29 nine Yes, right now downloading the DLL on demand in a Build.pm sounds like the way to go. I don't know any other solution. But it's certainly a use case we're gonna want to consider.
11:30 jdv79 there may or may not be better ways later on for sure.  maybe record this somewhere.  do we have a file or a issues list or something yet?
11:30 azawawi jdv79: true, the problem is the LibraryMake dependency needs a working nmake which on windows is not the default
11:31 azawawi jdv79: you need to set environment variables for it to work
11:32 nine jdv79: there's https://github.com/perl6/toolchain-bikeshed
11:32 azawawi jdv79: and given you're going to download and not install it on windows, then LibraryMake is not needed on windows but was installed and maybe can fail during installation depending on environment
11:34 jdv79 ah.  could you form this into some issue(s) on the repo nine just mentioned?
11:35 azawawi sure
11:35 jdv79 i'm still jetlagged and need some food. cool, thanks!
11:43 azawawi https://github.com/perl6/toolchain-bikeshed/issues/3  # done
11:43 azawawi masak++, jdv79++
11:45 azawawi left #perl6-toolchain
13:51 FROGGS_ joined #perl6-toolchain
15:47 mst autarch: what
15:47 autarch ?
15:47 mst autarch: the sub exporter part and ok() are *not* supposed to be in that part of the code
15:47 mst autarch: that's why the perl5 stuff ended up changing namespaces
15:47 mst Test2 is, correctly, just the streaming part
15:47 mst sadly perl5's Test::Stream released already with an exporter so we had to burn the namespace
15:48 mst please don't copy the same design error
15:48 autarch we can split it into multiple distros
15:48 autarch but I needed to test that this stuff actually worked for the API that people want to use
15:48 mst ah, yes, you moved it to a random namespace to remind us that needed to be possible
15:48 mst sorry. every time you mention it without caveat I jump to "aaaaaaaa" since we've already had it go horribly wrong in perl5 space
15:48 autarch yeah, I don't think Test::Predicates is the final namespace this should be in
15:48 autarch this is a prototype that exists purely so people can review the API design
15:49 mst I know that's not your fault but I hope you understand where my paranoia comes from
15:49 autarch I'm perfectly happy to rename all the modules, split it into several distros, etc.
15:49 mst right. that's what Test::Stream was supposed to be, then Exodist released it with stability guarantees while I wasn't looking and we ended up fucked
15:49 autarch and if anyone starts using it now they that's their problem - note that I haven't added this to the ecosystem yet either
15:49 mst yep
15:50 mst it's ok, had I finished my current coffee I'd probably've remembered we already covered this and you're already being sensible
15:50 mst I'd rather panic twice about a solved problem than not at all about an unsolved one though
15:55 autarch anyway, if you could review the API that'd be great - it's not a 100% port of the p5 stuff by any means, but I think it has all the things it needs
15:55 autarch I think the next step is for me to build another more complex testing module on top of it, like Test::Class, which is why I started working on this in the first place
15:56 mst I would suggest you prod leont, since I think his review would be at least an order of magnitude more valuable than mine
15:57 autarch well, multiple reviewers is even better, but yes, I will ask him
16:05 mst oh, absolutely
16:05 mst autarch: repo URL?
16:05 autarch https://github.com/autarch/perl6-Test-Stream
16:06 autarch there's no docs yet, because I don't want to invest a lot of time writing them before it's reviewed, which is a bit of a catch-22 I guess
16:06 mst well, lucky I usually read source before docs anyway then
16:41 domidumont joined #perl6-toolchain
16:44 domidumont joined #perl6-toolchain
18:34 leont joined #perl6-toolchain
19:33 hankache joined #perl6-toolchain
19:34 * flussence writes a thing, lets it stew for a while: https://github.com/perl6/toolchain-bikeshed/issues/4
19:36 * mst agrees except for an extra bit of paranoia
19:38 flussence aha, I was hoping there'd be some pushback there.
19:39 mst I agree we want to try and handle this. I agree META is where to put the info. I *really* don't want to end up with something that isn't fully battle tested in the spec
19:39 mst similarly to how rakudo tends to implement things a fair bit before they become 6.* spec material
19:45 flussence one vague end-goal I'm going for with this is to avoid the situatin Gentoo ended up with - package metadata with tons of flexibility... and can only be parsed correctly with bash 3
19:45 flussence s/tin\b/tion
19:47 mst right, turing complete dependency specifications can fuck right off
19:50 leont Yeah, let's please try to avoid that
19:55 mst rakudo currently totally supports them, per S22. I think the tooling is likely going to have to warn loudly when you do it but allow it anyway
19:59 flussence one thing I've noticed (and CPAN::Meta::Spec appears to be the same, fwiw) is we have ways to specify "I need everything in this list" and "I don't *need* anything in this list but it's here FYI", but not "I need at least one of the things in this list to work". That's easy enough to fix, I just haven't decided a good peg to hang it off of yet
20:00 mst yeah. the reason for that is that basically you could easily go from there to other binary combinations like "I need either X alone or both of Y and Z"
20:00 leont It's not a very common case, but it's useful every now and then
20:01 flussence I guess it's reasonable to just lump that in with optional dependencies for now, then
20:01 jdv79 i disagree with your proposal flussence
20:01 jdv79 i just haven't delved and asked and thought enough to propose a real fix
20:01 jdv79 except to say that parsing p6 in json is likely a bad idea
20:02 mst jdv79: what
20:02 jdv79 it should be splayed out into individual simple stringy things i think
20:02 mst we're talking about NOT parsing p6 in JSON here
20:03 flussence jdv79: some of these things are JSON keys, so it's kinda difficult to add structure to them...
20:03 mst well, I do admit that something like
20:04 mst { "Foo::Bar" => { auth => "BOB, version => "1.3.*" } }
20:04 jdv79 part of the problem is trying to match up the dep meta with the use counterpart
20:04 mst would seem nicer to me as a syntax within the JSON
20:04 jdv79 that's got be a bit worried
20:05 jdv79 *me
20:05 mst I'm not sure I understand, that problem is basically always going to be "you'll have to parse the .pm6 files for the use statement" no?
20:06 jdv79 well, iirc ver and auth and i guess api now can essentially be arbitrary at use time since they are spec'ed as just being a smartmatchable
20:07 mst but you said you disagreed with flussence's proposal, which is exactly about not doing that
20:08 mst I don't understand
20:09 ugexe isn't the 'one of these things in this list to work' solved by ['Wanted::First', 'Some::Backup']? (at least solved spec wise)?
20:10 jdv79 ugexe: but what if that doesn't pick the same thing that the use call does
20:11 jdv79 if you have to parse the p6 code to determine deps that kinda sucks.  i was hoping we could avoid that somehow.
20:12 jdv79 similar to the insanity of requiring runtime deps to gen pod kinda
20:12 ugexe i dont think parsing the source will be a solution, especially with supercedes, superceded_by, etc
20:12 mst I'm really confused here
20:13 jdv79 ugexe: note that S22 is not set in stone.  we could chuck it.
20:13 mst right, I want to chuck the turing complete parts of S22 as soon as possible
20:13 ugexe i dont see anything wrong with that part of the spec, or why it would require someone to parse the source to get dependencies
20:13 mst or at least declare them "you can use these in code, but don't expect the toolchain to even try"
20:13 mst yeah, I only mentioned parsing the source in terms of correlating the META6 info and where it came from
20:14 mst I mean, where it's being used
20:16 jdv79 for example, let's say we have something like this:  use Dog:auth({ .substr(0,5) eq 'cpan:'}):ver({.match(/^1/)});
20:16 jdv79 how does the meta mirror that?
20:16 mst it doesn't
20:16 mst we declare that 'unsupported, fuck off'
20:16 jdv79 so to me that's a problem
20:17 jdv79 welcome to p6 atm at leasy
20:17 ugexe ah, i do not like that either and mentioned this the other day as well
20:17 mst yes. that's a problem from S22, which we're going to have to apply cleansing fire to
20:17 jdv79 so either that closes down or meta tries to support it or we have an unbridged mismatch
20:17 jdv79 also S11
20:17 jdv79 as spec'd in 6.c...
20:18 mst I expect 'unbridged mismatch with loud warning'
20:18 jdv79 so that's a larry change
20:18 mst for the moment
20:18 mst I understand why the language offers it, but META ain't supporting it, because it's not going to work right
20:18 mst we -might- be able to bring limited stuff back later, but you'd start trending rapidly towards turing complete JSON
20:19 jdv79 yeah.  i don't really understand why the lang has it.  i just noticed the discrepency.
20:21 mst right. the point is, the discrepancy is both intentional and necessary
20:21 jdv79 but overall smells of not being thoroughly thought though
20:21 mst no, we've been thinking this through from the start
20:22 mst non-range or otherwise simple deps are just not going to be a thing any time soon
20:22 mst we've got enough other problems that are more pressing
20:22 jdv79 what start?  i'm talking about S11 and S22 and related
20:22 mst the start of this channel, and the various discussions about producing a real world viable toolchain
20:23 mst the synopses' beautiful academic overcleverness notwithstanding ;)
20:23 jdv79 i'm saying they are not that beautiful except perhaps from a distance or just on the high points.
20:24 flussence I'm inclined to smack it with a YAGNI hammer here and wait until someone who actually needs a quantum hyperspace runtime-generated version number comes to complain about META being inadequate
20:24 jdv79 anyway, why can't we just take CPAN::Meta::Spec and adapt it minimally?
20:24 jdv79 that was my first idea
20:24 jdv79 and what i planned on exploring
20:24 mst 20:04 < mst> { "Foo::Bar" => { auth => "BOB, version => "1.3.*" } }
20:24 mst was meant to be gesturing at precisely that
20:24 jdv79 pretty much:)
20:25 mst but then we're using cpanmeta version declarations in META and ranges in code
20:25 mst so I wonder if we're better specifying range style version formatting for this
20:25 leont Well, versions would have to be one of the main adaptations
20:25 jdv79 well, with p6 adjustments
20:25 jdv79 yeah
20:25 leont Otherwise, the prereqs format is superior IMO
20:26 * sjn wonders if it would make sense to concoct a URN scheme for those module-author-versions
20:26 leont That said, to me it may make sense to separate prereqs from the other meta. They tend to be used in very different circumstances, and in p5 are often generated kind of differently.
20:27 jdv79 leont: in what ways?
20:28 jdv79 are you talking about runtime/on the fly gen'd?
20:28 leont IN p5, the prereqs aren't really set until after configuration, in p6 we probably want to avoid that if we can
20:29 ugexe there is a speced urn, storage:AUTHOR:Module::Name:1.0
20:30 jdv79 i'm not sure what problem that solves but sure.
20:31 jdv79 its also pretty easy to split it out like mst mentioned
20:31 ugexe sure because command lines love arguments with < ( quotes etc
20:31 jdv79 iirc p5 does static with dynamic mixin.  perhaps that's almost exactly usable.
20:32 mst not entirely true
20:32 mst the META.json deps don't actual have to bear any relevance at all to the MYMETA.json deps
20:32 mst however 'MYMETA will, if anything, add deps' is what I'd consider well-behaved
20:33 mst (there's some fun fuckery in Moo's Makefile.PL to ensure we don't include optional deps in META even if we're building on a platform that needs them; not everybody goes to the effort)
20:36 jdv79 ok, but why can't we just do that more or less?
20:38 jdv79 i also wonder if we have time to bang out a more real meta setup now or should we just fix it up a bit and stamp it and then work on a next ver with real sophistication
20:38 sjn what's a "more real meta setup"?
20:39 jdv79 oh.  i mean something more resembling p5's level of support.
20:39 mst I think having one store for static-canonical meta, one for advisory prereqs, and one for final prereqs
20:39 mst rather than mashing the latter two into the former
20:39 mst might rather be an improvement
20:39 mst leont: is that what you were thinking about?
20:39 jdv79 what we have now is pretty rudimentary and doesn't even have solutions to some relatively basic things
20:41 leont mst: Sounds sensible. Even if we need some form of dynamic dependencies, that really should be more explicit than in CMS
20:41 jdv79 mst: curious why that's would be useful
20:41 jdv79 oh, nm.  yeah.
20:42 mst jdv79: "don't mash different things together" seems quite sufficient :)
20:45 jdv79 dyn deps will be necessary for at least plaform based choices right?  it can also be the easy way to handle the use vs meta gap.
20:45 sjn btw, do we have a basic set of assumptions that we agree upon written down somewhere? (e.g. "no turing complete configuration" and "we'll use JSON as metafile format" etc.)
20:46 jdv79 im sure there's something that doesn't cover but seems better than trying to handle subsets of p6 syntax in static text formats.
20:47 sjn (do we care?)
20:47 jdv79 uh, there's S11 and S22 as suggestion atm.  and i think whoever builds it first and gets it working and the community doesn't dislike terribly will stand.  more of less
20:47 jdv79 *or
20:49 jdv79 to me json seems uncontroversial as well as your other point.
20:50 sjn uncontroversial != decided
20:50 sjn but sure
20:51 sjn there's also an issue of how far it's meaningful to go with the "no turing complete" requirement
20:51 jdv79 decided is a bit too strong a concept maybe.
20:51 jdv79 :)
20:52 sjn do we handle post- and pre- install scripts?
20:52 flussence I think panda runs a "Build.pm", never used it myself though
20:53 flussence and it's not really specced afaik, it's just something thrown in there because it was needed...
20:53 sjn how about about other build phases that may make sense, like post- and pre-build and a "filtering" phase where one might run .js file minifyers before build?
20:53 jdv79 if we do its a installer specific thing right now
20:53 jdv79 non-spec yet
20:53 jdv79 i don't believe so but panda may have changed since last i saw
20:54 flussence ufo used to run makefiles if they were present iirc, a long time ago
20:54 jdv79 panda run a "build phase" out of Build.pm i think
20:55 mst sjn: the point is 'turing incomplete dependency resolution'
20:55 mst that's the most important thing
20:55 jdv79 mst: well, statically.
20:56 mst jdv79: I was riffing off 'no turing complete', do you have a point or are you just nitpicking my language? :P
20:56 jdv79 and that versions in string form don't start with "v".  might be a few other dumb things like that.
20:57 jdv79 mst: well, you seem to be saying no non-static dep resolution.
20:57 ugexe zef used to support all those hooks
20:57 jdv79 maybe we should use that then
20:57 sjn mst: right, so no "dynamic dependencies", like leont mentioned? or is that a different thing in your mind?
20:57 ugexe problem is getting people to switch off Build.pm
20:57 leont ugexe: we need to first offer something better…
20:58 mst jdv79: I've no idea what you mean by 'non-static' in that case
20:58 jdv79 i don't think that's viable - "no dyn meta"
20:58 ugexe leont: i just said zef supported all the hooks sjn just mentioned
20:58 sjn ugexe: hey, cool
20:58 mst I'm not sure those hooks are a remotely good idea
20:58 autarch leont: please review https://github.com/autarch/perl6-Test-Stream when you get a chance - I have what I think is a working first draft of the API
20:58 ugexe sjn: it does not anymore, but it was implemented at one time. just everyone kept using Build.pm
20:58 mst ah
20:59 leont Hooks doesn't sound like a good solution
20:59 mst I misunderstood there. it's the Build.pm system that's heinous
20:59 mst then again, hooks might also be heinous
20:59 mst it's toolchain. about 99% of options are heinous
20:59 jdv79 then how do you handle things like win vs osx or a ver range or a more complicated "long name" match?
20:59 * sjn think they are a *very* good idea to have, as long as they can be configured from a static file (
21:00 ugexe right, you could do your build stuff in whichever pre- hook made the most sense
21:00 mst jdv79: what
21:00 mst jdv79: I'm totally talking about version ranges being handled
21:00 mst I don't think I want to do os-specific stuff -yet-, that's the sort of thing where configure-time deps make sense
21:01 jdv79 i thought we were talking about config time.
21:02 jdv79 are you talking about a subset of p6 range syntax or full on or something else then?
21:03 mst I was thinking re-casting the CPAN::Meta version system in terms of a subset of p6 ranges
21:03 jdv79 i was thinking maybe just go totally simple in static meta and escape to hooks for anyting else
21:03 mst since that seems like the simple way to get things to match up
21:03 leont I'd think the config issue has a higher priority (it affects way more dists), but the build issue should be tackled too
21:04 leont jdv79: how do you imagine those hooks to be sane? The installer needs to know all dependencies
21:05 jdv79 i feel like i'm not up to speed enough with you p6 toolchain guys to be useful.
21:05 mst this isn't mostly about p6 at all as such, just the requirements of writing installers in general
21:05 jdv79 how would they be insane?
21:06 mst I don't understand how a hook can influence dependencies
21:06 mst in a way that allows the builder to resolve them sensibly
21:06 leont jdv79: hooks are typically things with side-effects but no result value
21:06 leont We rather want the opposite in this case
21:07 jdv79 ok, so wrong vocab.  i'm talking about being able to gen metadata.
21:09 jdv79 essentially just do something like http://search.cpan.org/~dagolden/CPAN-Meta-2.150005/lib/CPAN/Meta/Spec.pm#dynamic_config
21:09 jdv79 is that not a good idea here?
21:09 mst every time you say 'just do' in a toolchain conversation you accidentally brush all the sharp edges that will fuck you later under the rug
21:09 mst I am actually physically twitching every time you say 'just' here
21:10 jdv79 yeah.  sorry.  i'll stop.
21:10 jdv79 maybe i should just write some code and show it - that might be easier
21:10 mst seriously though, 'just' in a toolchain conversation is usually more of a harbinger of disaster than 'hold my beer' ;)
21:13 jdv79 well, we're still kinda in hand wavy stages aren't we?  or have we progressed beyond that now.
21:16 jdv79 ugexe: is zef back in action?  and does it have cpan support yet?
21:18 ugexe yes, and not really. if you can get your server back online i can check again. otherwise it at least will download perl5 Acme::Goatse, extract it, and try to install it
21:19 jdv79 ha, ok.
21:20 leont I think we're doing fine at identifying issues, and are already suggesting solutions; at least we're doing things in the right order
21:20 * mst points at the first thing in the topic
21:20 * mst added that for a bloody reason
21:25 sjn "Justin joustes just for Justice" # mst-twitch-of-death
21:27 mst "... oh, dear, did I just twitch so hard I stabbed you in the eyesocket with this butter knife? terribly sorry, old boy ..."
21:27 sjn hehe
21:29 sjn btw,
21:29 sjn I'm being Warnock'ed with https://github.com/sjn/toolchain-bikeshed/blob/master/doc/ # I'd like to make this into something useful; Feedback wanted
21:31 leont autarch: will try to look at it tomorrow
21:32 autarch leont: thanks
21:34 * nine is actually thinking that zef is better than panda by now
21:36 mst I'm starting to suspect that zef certainly has a better chance of evolving into a 'real' client (for fuzzy values of real not in any way to criticise its current capabilities)
22:05 ranguard joined #perl6-toolchain
22:08 llfourn_ joined #perl6-toolchain
22:48 llfourn joined #perl6-toolchain
22:53 leont joined #perl6-toolchain
22:57 pnu joined #perl6-toolchain
22:57 flussence joined #perl6-toolchain

| Channels | #perl6-toolchain index | Today | | Search | Google Search | Plain-Text | summary