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) {
   Version::Reverse.Version::new($s.split(".").reverse,$s)
   }
   }		 00:30
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
 00:48
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
hi
yup
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")'
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		 09:32
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		 09:48
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?
*equivalence
...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
Russell's*
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
also:
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
err
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
 10:50
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
 10:56
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
 10:58
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
s/Bind/TypeCheck/
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
 11:07
kudo/rt-127977: 4543464 | (Tadeusz “tadzik” Sośnierz)++ | src/core/Main.pm:
Style fixes for the #127977 fix
 11:08
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.
 11:47
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.
 11:52
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.		 13:33
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
 14:08
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.2.2.2.1 ~~ 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
ugexe s11 says `"use" searches for modules matching a version prefix`
MadcapJake So far the use cases brought up here seem really trivial 15:46
can you actually turn a version into a regex directly? 15:47
lizmat mst: there appears to be an nqp::syncpipe
MadcapJake Thinking on it some more, I suppose the work involved isn't monumental but still seems superfluous 15:48
mst lizmat: ooh, so that might turn out to be it
MadcapJake I feel like there should be a Version.absolute method to check if it's got whatevers or +'s in it 15:57
lizmat MadcapJake: that feels like a hack
MadcapJake why? 15:58
lizmat what I'm working on is that v2.3+ is actually syntactic sugar for v2.3..*
which would actually be a Range object which you could smartmatch
m: say v2.4 ~~ v2.2..*
camelia rakudo-moar 1512da: OUTPUT«True␤»
lizmat m: say v2.4 ~~ v2.2+
camelia rakudo-moar 1512da: OUTPUT«True␤»
lizmat m: say v2.4 ~~ v2.2..*
camelia rakudo-moar 1512da: OUTPUT«True␤»
lizmat m: say (v2.2..*).WHAT 15:59
camelia rakudo-moar 1512da: OUTPUT«(Range)␤»
lizmat m: say (v2.2.*).WHAT
camelia rakudo-moar 1512da: OUTPUT«(Version)␤»
lizmat m: say (v2.2+).WHAT # would say (Range)
camelia rakudo-moar 1512da: OUTPUT«(Version)␤»
MadcapJake so v2.2+ equiv to v2.2..* ? 16:00
lizmat yes
MadcapJake what about v2.2.* would that be a Range too?
lizmat yes 16:01
then checking version dependencies would just fall out of smartmatch
MadcapJake so could I do $version !~~ Range to see if it's "absolute"?
ugexe if its an actual range type wouldnt `for v1.0.0..* { say $_; }` be expected to work? 16:02
lizmat well, there's no Version.succ at the moment
but conceivably, that could be defined, yes
m: .say for v2..* 16:03
camelia rakudo-moar 1512da: OUTPUT«Method 'succ' not found for invocant of class 'Version'␤ in block <unit> at /tmp/k4GwHsybhO line 1␤␤»
MadcapJake in gx-perl6, I will need to resolve dependency versions and I could shortcut that if I have an absolute version rather than one with +'s and *'s
lizmat and checking for an absolute version would be ~~ Version
MadcapJake oh so v2.2.* ~~ Version would return False?
lizmat yes 16:04
it would be a Range
MadcapJake seems kind of magical though, don't ya think?
lizmat so we can shout at people putting v2.* as the version of a module in the META6.JSON
Version objects are highly magical already, I'm afraid
16:05 skids joined
lizmat m: say v2.abc cmp v2.ab 16:05
camelia rakudo-moar 1512da: OUTPUT«More␤»
MadcapJake well that could be solved by just having `method absolute { any(self.parts) ~~ Whatever && not self.plus }`
lizmat m: say v2.abc cmp v2.b
camelia rakudo-moar 1512da: OUTPUT«Less␤»
lizmat m: say v2.a cmp v2.bcd
camelia rakudo-moar 1512da: OUTPUT«Less␤»
lizmat MadcapJake: yes, that would be one solution, yes... 16:06
however, if we only allow * at the end, that would just be Version.plus 16:07
MadcapJake yeah that sounds good to me
I really don't see the point in a * anywhere else
tadzik is 2.3 a valid Version.plus for 2.2.4? 16:08
(I hope not :o)
lizmat no, Version.plus just indicates whether you had a + at the end
m: dd (v2.3+).plus 16:09
camelia rakudo-moar 1512da: OUTPUT«Bool::True␤»
lizmat m: dd (v2.3).plus
camelia rakudo-moar 1512da: OUTPUT«Bool::False␤»
MadcapJake m: v2.3+ ~~ v2.2.4
camelia ( no output )
MadcapJake m: say v2.3+ ~~ v2.2.4
camelia rakudo-moar 1512da: OUTPUT«False␤»
skids suspects there will eventually be a need for an array of ranges of Version many places they are used, so this all would just be a convenience. 16:10
e.g. to skip a buggy release.
MadcapJake fwiw, I'm not aware of any semver model that allows for * equivalents anywhere but at the end of a version 16:11
ugexe maybe Range should be a parameterized role so users can can `use v1.*.roll` 16:12
lizmat that's why I want v2.3+ to be a Range, so you can use it like any other Range
MadcapJake but I do have an affinity to how npm does it: ~1.0.4 means "I installed 1.0.4 but you can upgrade any patch release" and ^1.0.4 means "I installed 1.0.4 but you can upgrade to any minor release" and * or 'x' means "any major release is fine" 16:13
ugexe that seems to rely on semantic versions 16:14
MadcapJake so maybe allowing v1.2+.4 would be cool for that "any minor release" case. This way you can be aware of what version you have *and* what's an acceptable upgrade path 16:15
ugexe: yeah it does but I just mean for inspiration, specifically in terms of allowing a + after any element of a version literal
lizmat well, that's a step further again from v1.2.*.4
MadcapJake lizmat: maybe not further but a sidestep :) 16:16
lizmat that would basically turn a version into a sequence of regexes
Basically, my premise is that Version is now hacked into using for two functions:
MadcapJake lizmat: it would translate to a version v1.2 but allow you to pull the actual version via Str 16:17
correction: v1.2+ would be the actual version matcher
lizmat 1. specification of a fixed version, like in META6.JSON a module claiming to be v.1.2
2. specification of an acceptable version, like in META6.JSON in a depends specification
I think these functiionalitiies are currentlly conflated 16:18
MadcapJake my $v = v1.2+.4; $v.Str #={'v1.2.4'}; $v ~~ v1.3 #={True}; # what I'm proposing
lizmat so the Str representation would not visualize the range aspect ? 16:20
MadcapJake In that idea, I would say no because you're looking for Str value, what would visualizing the range accomplish? Having a Str value would allow you to create per-version anything (dir, files, hashes, etc) 16:21
lizmat would v1.2.4 and v1.2+.4 be eqv ? 16:25
because that is using .Str comparison atm
MadcapJake I would say that ~~ should convert plus'd versions into ranges 16:26
lizmat ~~ is not eqv 16:27
MadcapJake hmm 16:28
m: say v1.2+ eqv v1.2 16:29
camelia rakudo-moar 1512da: OUTPUT«False␤»
MadcapJake I'd say stick to that same semantics
stmuk_ lizmat: FYI I'm hoping to the R* release before you do the p6weekly 16:30
^ to do the
lizmat stmuk_: that would be great!
stmuk_ pl6anet.org/drop/rakudo-star-2016.04-RC2.tar.gz 16:31
but I'm on Pacific Time!
lizmat I'll prepare the P6W later today, will be travelling most of tomorrow, and then either very late on Mon or early on Tue do the P6W
MadcapJake although I *could* see eqv there being True but perhaps we don't want to change the semantics of `v1.2+ eqv v1.2` ?
lizmat well... I'm still not convinced keeping the two uses of Version in the same object, is a good idea in the long run 16:32
MadcapJake lizmat: I think the two uses are connected though, (1) validation and (2) comparison 16:33
lizmat see S11:547
synopsebot6 Link: design.perl6.org/S11.html#line_547
stmuk_ later might be better for the R*
lizmat "so :ver<6.2.3+> is short for :ver(v6.2.3 .. v6.2.*)" 16:34
so that actually states that it is a Range
MadcapJake lizmat: thanks for the Syn link, this is actually exactly what I was looking for yesterday :) 16:36
lizmat stmuk_: noted :-) 16:37
MadcapJake interesting that :ver(v1.2.1 | v1.3.4) is allowed too :) 16:38
lizmat it's all just smartmatching, really :-)
MadcapJake i'm starting to see that :) 16:39
lizmat m: say "foo" if v2.3 ~~ v1.2.1 | v2.2 | v2.3
camelia rakudo-moar 1512da: OUTPUT«foo␤»
skids I think what this boils down to is that in a lot of cases where you need a group of versions, you also have one that is special -- e.g. the providing module's version or a preferred version.
ugexe m: use Test:ver({ 1 * 3 }); 16:40
camelia ( no output )
MadcapJake skids: that's true, that's the purpose behind my v1.2+.3 idea; it contains the installed version (v1.2.3) and the matcher (v1.2+) 16:41
lizmat: I would say that case #1 is really just a string, right? I don't see the point in separating the two when the first case is so simple. 16:43
lizmat MadcapJake: no, it's not just a string, unfortunately 16:44
MadcapJake what's the difference between v1.2.4 and "1.2.4"
lizmat m: say "1.20.1" cmp "1.2.1" 16:45
camelia rakudo-moar 1512da: OUTPUT«More␤»
lizmat m: say "1.10.1" cmp "1.2.1"
camelia rakudo-moar 1512da: OUTPUT«Less␤»
lizmat m: say v1.10.1 cmp v1.2.1
camelia rakudo-moar 1512da: OUTPUT«More␤»
lizmat each component of the Version string is checked separately
m: say v1.10 cmp v1.10.abcd 16:46
camelia rakudo-moar 1512da: OUTPUT«More␤»
lizmat that's because missing components get replaced by Int() 0, and numerics always are More than Str
MadcapJake ok, yeah. is that any different though from how you'd do cmp for a v1.2.*? 16:51
lizmat actually, I think cmp for a version with a Whatever, is currently broken 16:52
16:52 hankache joined
lizmat and has been for a while afaics 16:52
MadcapJake yeah seems so, does it just get turned into a 0?
lizmat hmmm... maybe it works out anyway... :-) 16:54
lizmat is getting tired 16:55
too many short nights in a row
MadcapJake isn't sure what the intended semantics of cmp'ing versions with *'s 16:58
are* 16:59
m: say v1.2.4 cmp v1.2.* # I would think this would return Same 17:00
camelia rakudo-moar 1512da: OUTPUT«More␤»
MadcapJake lizmat: have a good night then! ping me if you make any headway with this version stuff, I'm interested in how it all ends up 17:02
lizmat MadcapJake: no rest for the wicked... ;-) 17:04
just expressing lack of being able to think straight from tiredness :-)
MadcapJake ahh! I know the feeling xD
MadcapJake is off to lunch & 17:05
awwaiid I'm trying to debug the REPL.pm lifting of code out of nqp and into rakudo on the jvm. I want to sprinkle some nqp::say type debugging into nqp and rakudo. The nqp/ bit make / make install'd ok, but when I pop back out to rakudo and make I keep getting "Missing or wrong version of dependency 'gen/jvm/stage2/QAST.nqp'" -- any pointers? 17:26
timotimo awwaiid: at some point things in precompilation blew up hugely when you had says in the wrong places 17:28
because the output ended up in files that weren't expecting to have debug stuff in them
btw, you can use "note" in nqp code to output strings to stderr
17:32 mst left
awwaiid ok, yes I did run into that before. What is a good way to reset? I did 'make clean' in rakudo and then make still has issues. According to git diff all my current debugging output is to stderr 17:34
timotimo you may have to make clean; make install inside nqp
awwaiid ok, trying that 17:35
lizmat rm -rf install
might also help
awwaiid ok, I'll try that after this :)
since it's complaining about stuff in gen/jvm, maybe I'll rm that stuff too
(again, if other things don't work. one var at a time) 17:36
psch awwaiid: r-j is much more picky wrt left-over files, in my experience 17:45
i usually git clean -xdf before every rebuild
Pod.pm is one that i often get complaints about, too 17:46
dalek kudo/nom: c066434 | leont++ | tools/build/Makefile- (4 files):
Make perl 5 calls in Makefile more explicit
 18:17
kudo/nom: 8a5b0be | leont++ | / (3 files):
Try to avoid using perl5 in small commands
kudo/nom: 531a044 | leont++ | / (3 files):
Convert create-moar-runner to perl 6
kudo/nom: 13ea1a1 | leont++ | / (8 files):
Use pure-perl6 harness
timotimo *neat* 18:18
dalek kudo/nom: 4232204 | lizmat++ | src/core/Any.pm:
Make dd for lazy list not look like valid .perl
lizmat drink! 18:29
&
19:03 cognominal joined
timotimo do we even actually need @autovivs for bless and BUILDALL 19:40
19:41 Skarsnik joined
moritz timotimo: iirc there's an obscure feature for initializing the attributes from a parent class 20:59
timotimo yeah
but is that actually implemented?
moritz Foo.new(x => 42, Bar{ x => 23 }) 21:00
timotimo or just a performance drain?
moritz probably not
but pre-nom it was iplemented, iirc
timotimo ugh 21:01
masak .oO( le prénom, il a été implémentée ) 21:08
awwaiid psch: thanks, git clean -xdf, while tedious, did the trick 21:52
dalek kudo/generate_buildallplan_2: e76d070 | timotimo++ | src/ (3 files):
get a tiny head-start on generating buildallplan code in CompilerServices
 22:17
kudo/generate_buildallplan_2: 8d1725d | timotimo++ | src/Perl6/ (2 files):
implement a lot more for code-genning BUILDALLPLAN.

currently creates a setting that immediately crashes when it gets loaded. not sure why.
timotimo jnthn: i think i need your help with this branch; i'm potentially using the MOP wrong or something like that, but i can't quite figure out what's going wrong 22:41
github.com/rakudo/rakudo/commit/8d1725daf5 - corresponding backtrace when trying to build the restricted setting

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!