00:00 lizmat joined
dalek kudo/nom: 00e71c8 | lizmat++ | src/core/Version.pm:
Add another way of creating Version object

This will basically allow alternate ways of parsing Version strings that generate an array of parts to compare, and possibly an alternate string representation.
   class Version::Reverse is Version {
   method new(Str $s) {
stmuk seen azawawi
lizmat .seen azawawi 00:38
geekosaur yoleaux isn't in here 00:41
lizmat yeah, got that now :-) 00:42
dalek kudo/nom: b952687 | lizmat++ | src/core/Version.pm:
Handle lazy lists correctly
lizmat good night, #perl6! 00:53
01:00 lizmat joined 01:47 ilbot3 joined 02:02 stmuk_ joined 05:00 skids joined
tomboy64 any comments on the jvm backend for rakudo? 07:56
stuff asplodes badly when i try to build against the jvm 07:57
bartolin there are a lot of issues with the jvm backend, but at least I was able to build it in the last few weeks. what version of rakudo do you try to build and how does it explode? 08:00
08:12 RabidGravy joined
psch tomboy64: nom HEAD should definitely build and install, details would be very interesting 08:21
08:24 [TuxCM] joined 08:25 lizmat_ joined
tomboy64 second 08:30
bartolin: psch: bpaste.net/show/487fbdbcd5be 08:36
hmm i wonder if the nqp jars are seen at all 08:37
psch oh 08:38
yeah, look it doesn't find them
tomboy64: "warning: [options] bootstrap class path not set in conjunction with -source 1.7" surprises me a little 08:41
because we *do* set -Xbootclasspath during build somewhere, i'm not sure it's in that spot though
tomboy64 yeah, i think i've seen that
it's probably gentoo's messing things up here, but i doubt it, since nothing java-mangling is being pulled in. 08:42
psch i'll start a manual run, for reference
lizmat jnthn: re irclog.perlgeek.de/p6dev/2016-04-23#i_12381803 08:44
jnthn: looks like it needs to be done somewhere near src/Perl6/Metamodel/MultiMethodContainer.nqp, line 94
jnthn: but I have no idea of the necessary incantation to tweak the package
[TuxCM] This is Rakudo version 2016.04-22-gb952687 built on MoarVM version 2016.04 08:45
test 21.538
test-t 12.798
csv-parser 23.692
psch tomboy64: just to verify, nqp is installed and e.g. < nqp-m -e'say("hi")' > works? 08:55
tomboy64 $ nqp-m -e'say("hi")' 08:56
psch fwiw, i don't get the warning about the unset bootclasspath
tomboy64 moarvm is installed as well, works as well
psch OpenJDK Runtime Environment (IcedTea 2.6.4) (7u95-2.6.4-1~deb8u1)
tomboy64 i am using 2016.03 - if that's worth anything? 08:57
psch tomboy64: oh, my bad, nqp-j, not nqp-m...
ah, 1.8
tomboy64 $ nqp-j -e'say("hi")'
takes a little but works fine as well
psch yeah, that's expected 08:58
tomboy64 is 2016.04 released?
should i try with that?
psch */usr/usr/*share/nqp/runtime/ # <- that's your classpath..? :)
tomboy64 nope
psch but that's in your paste
well, minus the *, those were for emphasis :S 08:59
tomboy64 hah 09:00
that seems to have been it
good catch
i had --sysroot=/usr; making it / made it work 09:01
bartolin psch++ # even without coffee 09:03
psch 2016.03 probably won't install, fwiw 09:04
tomboy64 well, the moar backend installs just fine
was able to run perl repl from that last night 09:05
psch yeah, but moars p6sort impl cheats somehow
[TuxCM] perl6 -v does not show the nqp version. Should it?
psch and deals fine with a Mu (or VMNull, not sure anymore) as first element, which gives an NPE on r-j
tomboy64: 2016.04 is tagged though, that one should work 09:06
tomboy64 ^^ okay, gonna test soon
btw, what would you think about adding this to moarvm's Configure.pl? bpaste.net/show/e6d9849d7d77 09:07
psch tomboy64: i'd bring that to #moarvm
tomboy64 i had problems including locally installed libffi.h
ah, alright. thought it was part of perl6
psch i mean, people will probably see it here too, but it doesn't seem to directly relate to p6 itself
well, moar is designed upon 6model, which is an object model that does what perl6 needs, but moar can probably be used for other things... :) 09:08
nine_ Oh boy. I got a "Cannot find method 'run_alt'" again 09:09
psch nine_: that's QRegex, isn't it..? 09:10
nine_ I think so. The issue was first exposed when we started precompiling all modules but disappeared on it's own for unknown reasons. It was probably just hidden though. 09:12
moritz psch: 6model isn't really an object model in the sense that language users think of an object model 09:20
it's more like a framework for separating object storage and object behavior
timotimo yeah, 6model gives you very basic meta-programming stuff that you can build your own stuff upon 09:21
moritz oh gosh, I think tht#s a terrible explanation I just gave
timotimo that's what REPRs are, mostly
psch moritz: yeah, i get that much. 6model is a bootstrapping object model for building a languages object model 09:22
timotimo in order to figure out how powerful it is, we'd really need someone to implement every single object model out there on top of it :D 09:23
moritz psch: that sounds like you'd stop using using it once your language object model is bootstrapped. Which isn't the case
psch: I guess we both have problems finding the right words here :-) 09:24
psch moritz: yeah, seems like. i'll readily admit my experience with 6model is also purely "what is this even and what i can do to {implement,fix} this..?" :) 09:27
dalek ast: 34eda5f | usev6++ | S32-hash/adverbs.t:
Only skip tests for rakudo-m

add reference to RT #126823
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126823
09:43 [TuxCM] joined
dalek ast: 4a8c7ea | usev6++ | S32-array/adverbs.t:
Only skip tests for rakudo-m

add reference to RT #126823
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126823
tadzik github.com/tadzik/rakudobrew/issues/80 has an idea of tagging the latest stable release of rakudo as latest-stable, so rakudobrew and such can install the latest release rather than blead or whatnot. Yay or nay? 09:55
(last comment is the most relevant)
psch i thought retagging is a bad idea? 09:56
tadzik I'unno 09:58
it may also be interesting to see how perlbrew/plenv handles this
where do they get the version listing from
psch blog.iqandreas.com/git/how-to-move-tags/ says every clone has to manually delete the tag at the old location before pulling the tag at the new location 09:59
which i personally would find somewhat annoying and at least a bit tedious... :)
otoh, that blog post is 3 years old, no idea if anything changed in git wrt tags since then
on an unrelated note, where do i test the fix for #127916? my first idea is in S14-roles, probably mixin.t, but i'm really not confident about that 10:02
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127916
lizmat m: say v1.2 eq v1.2.0 # I posit this is correct 10:08
camelia rakudo-moar b95268: OUTPUT«True␤»
lizmat m: say v1.2 eqv v1.2.0 # I posit that this is *also* correct, as these versions are *not* deeply equal 10:09
camelia rakudo-moar b95268: OUTPUT«False␤»
lizmat if we have consensus on this behaviour, I will need to fix a few tests
masak lizmat: I tentatively agree 10:10
m: say v1.2.3 ~~ v1.2; say v1.2.3 ~~ v1.2.0 # because of this 10:11
camelia rakudo-moar b95268: OUTPUT«True␤False␤»
masak I wouldn't expect two canonically equal things to smartmatch differently
psch equivalent between a superset and one of its members seems to not work if the superset can have more than that one member, right?
...although i'm not sure set theory applies that rigorously to version numbers
masak I think it does
psch: but I don't understand what your argument there is -- that sounds more like Russel's paradox, which we're not aiming for :P 10:12
psch that's the one with the teapot..? :)
masak no, the one with the barber 10:13
and sets
psch but you're probably right, the argument doesn't really work, because eq doesn't really work by the same rules, does it
masak eq is just string equivalence
that's easy
lizmat m: say v1.2.3 ~~ v1.2; say v1.2.3 ~~ v1.2.0 # masak: are you saying this is correct ?
camelia rakudo-moar b95268: OUTPUT«True␤False␤»
masak lizmat: oh yes 10:14
psch exactly, but the string equivalence has to mean (elem) for my argument to work
masak lizmat: in other words, v1.2 and v1.2.0 sort of denote "version ranges"
psch and that's just don't right
masak it's how I always understood the spec
psch "member of" for a given patch-level version happens by comparing to a minor-version-level version, and not with eq
in that sense, it works with the smartmatch above 10:15
(where a "version range" is a set of versions)
masak psch: I understand the smartmatch as being a containment check between two version ranges 10:16
psch i'm not sure if shaving himself matters there for the barber, but maybe i'm overlooking something
lizmat actually, thinking about this more, I think we're conflated Version and VersionRange into a single object :-(
masak psch: if the user chooses to picture the lhs version range as actually a point (and thus the check as membership instead of subsetship), then that's fine
lizmat: but it works out
lizmat not sure about that in the future 10:17
I mean, v1.* is *not* a version, it's a version range
psch masak: ohh, right. now i see where the barber comes into play
masak re-reads S11
psch: you were talking about comparing a set with its members 10:18
lizmat: S11 seems pretty clear that Version fills *both* roles, depending on context 10:19
lizmat: for example, in a `use` with :ver<1.2.1>, it's an exact match -- a point, not a range
lizmat well I guess I'm saying is that a Version is acceptable as a VersionRange 10:20
masak lizmat: to get a range, you'd use an actual range in :ver, or :ver<6.2.3+>
lizmat whereas a VersionRange is *not* acceptable as a Version
masak lizmat: ok, I can see that point. 10:21
lizmat aka, you can say a module is at version v1.2
not at v1.*
but currently, there's no way to inhibit such a statement
masak aha
lizmat that's why I think we need to split the functionality
masak I wouldn't go so far as needing to split it
lizmat (an insight I got late last night)
masak but it does sound like we need some checks in some places... 10:22
lizmat well, if we're going to add an "is-range" method to Version, we're hacking a difference into it 10:23
psch isn't it just ACCEPTS that needs to know this?
lizmat how would you use smartmatch to check whether a META6.json spec of a version is in fact a version and not a range ? 10:24
psch well, and any intended-as-point spot needs to fill the version to patch-level, so to answer my own question "no"...
lizmat indeed :-)
psch m: say (v1.2).perl 10:25
camelia rakudo-moar b95268: OUTPUT«v1.2␤»
tadzik considers opening a rakudobug just so he has a number to put near the roast test
psch yeah, that seems a bit too contextually-overloaded from here
masak psch: "needs to fill the version to patch-level" -- that's only true if the whole world runs on semantic versioning, isn't it? 10:27
psch: as in, I should be allowed to call my *point* versions v1, v2, v3...
(I hope) 10:29
lizmat masak: yes, you are allowed :-) 10:32
masak then a point version doesn't have to fill the version to patch level. 10:33
and that's a sense in which point versions "are" ranges, because I'm intentionally grabbing a whole range and using that as a point
m: say v1.2.3.4
camelia rakudo-moar b95268: OUTPUT«v1.2.3.4␤»
masak the rabbit hole goes deeper than patch 10:34
so even patch versions are ranges
psch masak: yeah, and that's where it turns from "with classes as major versions, sets as minor versions, points as patch-level version" stops working 10:35
s/" stops working/it works" turns into a barber/
...that's still butchered.
masak psch: that's not my mental model of it at all 10:36
psch masak: no, but it was mine :)
masak psch: well, stop it :P
psch *was*. i said *was* :P
masak to a first approximation, versions are ranges (though not on the real line)
m: say v1.1938 10:37
camelia rakudo-moar b95268: OUTPUT«v1.1938␤»
dalek kudo/nom: 15a0dca | lizmat++ | src/core/Version.pm:
Move "+" logic to general .new
psch m: sub f(+@a) { say @a.perl }; sub g(*@a) { say @a.perl }; f [1, 2], 3; g [1,2], 3 10:42
camelia rakudo-moar b95268: OUTPUT«[[1, 2], 3]␤[1, 2, 3]␤»
psch ...my camelia query used to be win5, now that's p6dev :S
dalek ast: 95a5c18 | peschwa++ | S14-roles/mixin.t:
Add test for RT #127916
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127916
dalek ast: 16338c5 | (Tadeusz “tadzik” Sośnierz)++ | S06-other/main-usage.t:
Add a test for #127977
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127977
tadzik who is this Tadeusz “tadzik” Sośnierz stealing all my karma
dalek kudo/rt-127977: d548b23 | (Tadeusz “tadzik” Sośnierz)++ | src/core/Main.pm:
Fix RT #127977
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127977
tadzik any comments on that one, before I go forgiveness>permission and merge it? :)
psch looks 10:59
masak too
tadzik lizmat++'s idea: use .startswith() instead of .index() == 0 11:00
masak tadzik: s/and/&&/ both times
lizmat likes && in that case because it lines up better
tadzik alright, I can agree to that. It lines up better with 'if' :P
masak tadzik: the whole patch feels a bit like a band-aid, and there's a deeper underlying problem somewhere :/
psch i'd also appreciate a comment that notes that we probably want a not-X::AdHoc eventually 11:01
and i do agree with masak as well, but i often bandaid myself, soo... :)
masak I'm just generally against mis-using `and` when `&&` works just as well. `and` is for loose, statement-ish-level precedence
tadzik masak: it is :/ But it fixes the problem, and getting binder to throw out perl6 exceptions sounds like a good reason why it's adhoc in here
masak I'd say the band-aid is fine if we also commit somehow to fixing the deeper problem
psch tadzik: the binder has a mechanism in place for throwing typed exceptions 11:02
it's just a bit fiddly, mostly
tadzik oh
psch grep for P6EX
i'm not sure catching a e.g. X::Bind::Argument::Constraint instead of X::AdHoc completely removes the bandaid feeling, though... 11:05
it also reaffirms my wish for introspectable where constraints 11:06
m: sub MAIN(Int $x where * > 5) { } # this usage is lacking
camelia rakudo-moar 15a0dc: OUTPUT«Usage:␤ /tmp/vZHUYsPoqq <x> ␤»
dalek kudo/nom: 1034c62 | lizmat++ | src/core/Version.pm:
Allow setting of "+" functionality also
kudo/rt-127977: 4543464 | (Tadeusz “tadzik” Sośnierz)++ | src/core/Main.pm:
Style fixes for the #127977 fix
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127977
lizmat hmmm... so what *are* the semantic differences between cmp <=> and leg ? 11:14
I'm starting to feel that github.com/rakudo/rakudo/commit/688ddee was a mistake 11:15
should have been < instead of lt
<= instead of le etc etc
tadzik so, who's fine with applying the band-aid but keeping the RT open until we get a more proper solution? o/ 11:19
psch isn't sure what else but a narrower Exception would go into a proper solution 11:22
lizmat tadzik: +1
psch if that's all i can probably hack that in rather quickly
tadzik that'd be nice, I don't know where to start on that 11:23
psch well, for now subclassing TypeCheck::Argument doesn't help, 'cause we can't show the failed constraint 11:27
someone once pointed me at a gist that shows how we could get the where constraint back during runtime, but i neither grokked nor saved it
m: sub f(Int $x) { }; f "f" # this message ~~ s/declared signature/declared constraint $contraint/ 11:29
camelia rakudo-moar 1034c6: OUTPUT«===SORRY!=== Error while compiling /tmp/lJDpOvE90C␤Calling f(Str) will never work with declared signature (Int $x)␤at /tmp/lJDpOvE90C:1␤------> sub f(Int $x) { }; ⏏f "f" # this message ~~ s/declared signa␤»
psch hm, and probably s/f(Str)/f($actual-argument)/
well, i'll subclass but add a # TODO: ... 11:30
and also note that in the ticket
hm, maybe it should be X::TypeCheck::Binding::Constraint, actually..? 11:34
'cause ::Argument is about protoguilt and all that jazz
dalek kudo/rt-127977: d3c2254 | peschwa++ | src/ (3 files):
Add and throw a typed Exception for where constraints.
psch tadzik: ^^^
note that i actually realized that we do need to propagate the reason for the dispatch failure towards USAGE somehow 11:48
as in, a < sub MAIN(Str $x where .chars > 5) { } > giving USAGE as-is when i supply "foo" doesn't help enough 11:49
maybe having where constraints in USAGE is enough there, though
oh duh
that actually works for the wrong reasons it seems
the patch i mean 11:50
tadzik psch (IRC): I think the if chain can go now
psch tadzik: maybe, i have to fix the lookup via P6EX first though... :) 11:51
there was two copy-pastos :/
tadzik sits on the edge of his chair
dalek kudo/rt-127977: 3381d20 | peschwa++ | src/ (2 files):
Correct copy-pastos.
kudo/rt-127977: 0ca6e3d | peschwa++ | src/core/Main.pm:
Simplify, tadzik++
psch now, who was it that pointed me at code object introspection..? :/
also, grr me 11:53
the previous one didn't work, which i noticed because i tested *after* pushing
and now i pushed again without testing :(
...we can squash before merging, right? :P
tadzik I'll get that :)
squashing seems like a sensible thing, yes 11:54
timotimo wow, so much #p6dev chat today :)
psch $ ./perl6-m -e'sub f($x where 5) { }; try f 2; $!.perl.say' 11:55
X::TypeCheck::Binding::Constraint.new(symbol => "\$x", operation => Any, got => Any, expected => Any)
that's rt-127977 HEAD, so i did good :P
timotimo lizmat: i was also quite surprised when you used eq and friends for versions, because i'd expect lt, gt and friends to coerce things to strings 11:56
lizmat timotimo: yeah, I had just come to the same conclusion 11:57
tadzik psch: www.tf2sounds.com/495 :P
yep, tests pass
I'll squash and merge, alrigh?
psch let me see if i can find that introspection gist
'cause if we can already have the code of the where constraint in the Exception that'd definitely be cooler :) 11:58
tadzik okayo
psch same for USAGE, too
tadzik oh yes
psch hmm, gist.github.com/niner/3be0c164d847ca794e18 was the gist 12:00
i don't know if that actually helps, 'cause Backtrace just opens its $.file and looks for the surrounding lines...
psch wonders what a good solutions could look like there 12:01
annotating every WhateverCode with its source seems kinda ehh
otoh, doing what Backtrace does might not work with e.g. -e..? 12:03
well, i suppose for Parameter constraints it makes me sense to stuff it into the Parameter anyway, e.g. < has str $!post_constraints_src > or something, maybe 12:04
s/me/more/ 12:05
i'll have to ponder that a bit 12:09
which probably mostly means accepting that i don't know a better solution than telling a Parameter what the source of its post_constraint looks like textually
during parse that is 12:10
lizmat lunch& 12:14
psch oh shucks 12:53
the parts of a stage parse Match object are BOOTStr, which i somehow can't figure out how to stuff into a str Attribute of Parameter..? 12:54
12:56 astj joined, hankache joined
psch ...the only thing i can think of is unbox_s(box_s($str, find_symbol([Str]))... o.o 13:00
and that's pretty terrible
well, it still gives a BOOTStr anyway 13:03
$ ./perl6 --ll-exception -e'sub f($ where * < 2) { }; say &f.signature.params[0].post_constraints_src' 13:08
where * < 2
RabidGravy anyway, all my modules pass with the 2016-04 13:09
psch gist.github.com/peschwa/cf6314bd11...e4ad855f25 13:27
tadzik: ^^^
tadzik psch (IRC): awesome :)
psch well, and anyone else, really :)
it could be more awesome i suppose 13:28
like, the sub example could print "0 < <anon> < 2" 13:29
but that's potentially really complicated
timotimo i didn't know you can have multiple "where"s there
psch timotimo: fwiw, what clued me in is that it's Parameter.post_constraints :)
timotimo ah 13:30
well, you could just write that as where 0 < * < 2
psch yeah, in that case
timotimo if it were <= each time, you could write 0..2
psch well, the example is clearly best written as "sub f(1)" :P 13:31
but that doesn't demonstrate the constraint Exception :)
dalek kudo/rt-127977: e0f12a4 | peschwa++ | src/ (6 files):
Expand USAGE to include post constraints.

Necessary condition for that was obviously adding a typed Exception and stuffing the post constraint source into Parameter, which we profit from in normal subroutine invocation as well.
tadzik <3 13:34
lizmat m: dd v6.*.2 # should this be a valid Version object??
camelia rakudo-moar 1034c6: OUTPUT«v6.*.2␤»
psch fwiw, it's a great solution for the USAGE case, but the implementation still feels band-aid-y to me
lizmat and if so, what does it mean in a Range context ?
psch but it's probably the best we can do there, as we can't find out the post constraint source later, so carrying it around from parse time is the only thing we can do (...i think) 13:35
tadzik: can i ask you to write tests for the new typed Exception? :) 13:36
hm, maybe that's pending a more general agreement with the patch anyway... vOv 13:37
tadzik yeah, if we are to write spectests, we need some more speculation I'd say 13:39
so we have --output, but --profile-filename. Would you oppose to changing it to --profile-output for consistency? 13:41
lizmat says +1 13:42
psch no opposition here
13:49 astj_ joined
dalek kudo/nom: 1512da2 | lizmat++ | src/core/Version.pm:
We should use numerical compares for Version
vendethiel lizmat: should Less/More/Same use ==/!=? 14:11
lizmat vendethiel: not sure I understand the question 14:13
vendethiel lizmat: you use == and != with "compare" objects,is that correct? is that not supposed to use eqv or whatever else form or equality there is? probably doesn't matter
lizmat "compare" objects? you mean Version objects ? 14:14
timotimo tadzik: if you change that, either make both flags work for a while, or directly fix camelia to use --profile-output as well :) 14:30
tadzik timotimo: both are probably sensible :) 14:31
vendethiel lizmat: no, I mean Less/Same/.. - that's just an enum? 14:44
lizmat m: dd Same, Less, More
camelia rakudo-moar 1512da: OUTPUT«Order::Same␤Order::Less␤Order::More␤»
lizmat vendethiel: yes :-)
psch m: say so 1 <=> 1 # this consequence tripped me up once 14:49
camelia rakudo-moar 1512da: OUTPUT«False␤»
psch but then cmp and friends aren't for equality
lizmat m: m: say so (1 <=> 1) 15:23
camelia rakudo-moar 1512da: OUTPUT«False␤»
lizmat m: m: say so Same
camelia rakudo-moar 1512da: OUTPUT«False␤»
lizmat m: say so Same
camelia rakudo-moar 1512da: OUTPUT«False␤»
lizmat duh :-) 15:24
psch m: say Same.value
camelia rakudo-moar 1512da: OUTPUT«0␤»
timotimo tadzik: but clearly ' and \ must be escaped inside there
which you'd only notice if you have stuff like that in filenames or something silly like that
and \ are probably doubled accidentally 15:25
tadzik ww? :)
well, they're not, somehow :P
timotimo ww, yes
lizmat PSA re v2.*.3 : I'm thinking about disallowing that 15:26
too bad it has one spectest for that particular case
comments / opinions / suggestions ?
tadzik kill it, imho 15:27
timotimo it's a strange thing to want 15:28
but it may have a reason to exist
lizmat fwiw, S11 only has examples of * at the end of a version 15:33
tadzik does git-blame tell anything interesting?
lizmat the wording is a bit ambiguous, but I don't think it shows intent of v2.*.3 meaning anything
pmichaud, Nov 2008 15:34
ugexe v2.*.1+ specifically could make sense, but in general i dunno
lizmat ugexe: what would that mean ?
timotimo anything starting in v2, with one part in the middle and ending in .1 or more than that 15:35
but never ending in .0
ugexe only use module whatever version after its first patch (you dont trust the first release). yes this is a stretch
lizmat feels to me that could be served better with a "where" type clause 15:36
specifically, is the * supposed to be slurpy?
ugexe well, not if you are declaring dependencies in a meta file or something
lizmat would v2. ~~ v2.*.1 be true or not ? 15:37
the reason I'm asking, is that I think v2.4.* should really be a Range 15:38
m: dd v.2.4..* 15:39
camelia rakudo-moar 1512da: OUTPUT«===SORRY!=== Error while compiling /tmp/zLZsmB2JVR␤Malformed postfix call␤at /tmp/zLZsmB2JVR:1␤------> dd v.⏏2.4..*␤»
lizmat m: dd v2.4..*
camelia rakudo-moar 1512da: OUTPUT«Method 'succ' not found for invocant of class 'Version'␤ in block <unit> at /tmp/YV2nLFaV2T line 1␤␤»
lizmat m: say v2.4..*
camelia rakudo-moar 1512da: OUTPUT«v2.4..Inf␤»
tadzik I would assume v2.*.1 means v2.[0-9]+.1
lizmat so a Version object like that would return a Regex really ?
15:41 mst joined
mst libuv has a unix domain socket and/or win32 named pipe abstraction, is that exposed to perl6 space? 15:41
lizmat mst: what is the name of that abstraction ? 15:42
could grep MoarVM source for it maybe ? 15:43
mst docs.libuv.org/en/v1.x/pipe.html
MadcapJake lizmat: I am in favor of disallowing vX.*.X for the reason that the amount of work for a dependency manager to support it far outweighs the supposed gain 15:45