[Tux] This is Rakudo version 2016.05-116-g5d49498 built on MoarVM version 2016.05-18-g1339332 06:08
test 17.164
test-t 9.781
csv-parser 21.413
dalek kudo/nom: b351d61 | lizmat++ | src/core/Mu.pm:
Fix for RT #128393, sortiz++ for spotting
 09:03
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128393
sortiz lizmat, about the nqp::while Seq producer semantic, wondering why a simple while is more expensive or if other looping construct can be faster. 09:30
lizmat the reason I changed many of those loops to nqp::while, is that they're guaranteed to not sink 09:31
postfix while currently doesn't sink either, but that could be considered a bug 09:32
also, I don't think nqp::while generates a Seq: it's just that if you look at it at the p6 level, it turns into a Seq
jnthn: please correct me if I'm talking nonsense here :-) 09:33
jnthn m: say nqp::while(my $i = 0, $i, $i = $i + 1)
camelia rakudo-moar b351d6: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Could not find nqp::while, did you forget 'use nqp;' ?ā¤at <tmp>:1ā¤------> y nqp::while(my $i = 0, $i, $i = $i + 1)ā<EOL>ā¤Ā»
jnthn m: use nqp; say nqp::while(my $i = 0, $i, $i = $i + 1)
camelia rakudo-moar b351d6: OUTPUTĀ«()ā¤Ā»
jnthn m: use nqp; say nqp::while(my $i = 0, $i < 10, $i = $i + 1)
camelia rakudo-moar b351d6: OUTPUTĀ«()ā¤Ā»
jnthn m: use nqp; nqp::while(my $i = 0, $i < 10, $i = $i + 1).say
camelia rakudo-moar b351d6: OUTPUTĀ«()ā¤Ā»
lizmat jnthn: nqp::while takes the condition as the first 09:34
jnthn oh wait
yeah, duh
sortiz m: use nqp; my int $i = 0; nqp::while(nqp::islt_i($i,10),($i = nqp::add_i($i,1))).say';
camelia rakudo-moar b351d6: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Two terms in a rowā¤at <tmp>:1ā¤------> lt_i($i,10),($i = nqp::add_i($i,1))).sayā';ā¤ expecting any of:ā¤ infixā¤ infix stopperā¤ statement endā¤ statement modiā€¦Ā»
jnthn m: use nqp; say nqp::while($i < 10, $i = $i + 1)
camelia rakudo-moar b351d6: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Variable '$i' is not declaredā¤at <tmp>:1ā¤------> use nqp; say nqp::while(ā$i < 10, $i = $i + 1)ā¤Ā»
jnthn m: use nqp; my $i = 0; say nqp::while($i < 10, $i = $i + 1)
camelia rakudo-moar b351d6: OUTPUTĀ«(1 2 3 4 5 6 7 8 9 10)ā¤Ā»
psch m: use nqp; my $i = 0; say nqp::what(nqp::while($i < 10, $i = $i + 1))
camelia rakudo-moar b351d6: OUTPUTĀ«(Sub+{<anon|65390768>})ā¤Ā»
jnthn m: use nqp; my $i = 0; say WHAT nqp::while($i < 10, $i = $i + 1)
camelia rakudo-moar b351d6: OUTPUTĀ«(Seq)ā¤Ā»
jnthn Interesting... :) 09:35
Oh...maybe we did override it to do that :)
To ease code-gen of r-value while loops
Which is good really...
I guess in sink context it just does The Usual Thing :) 09:36
dalek kudo/nom: 4890cdc | lizmat++ | src/core/Mu.pm:
Pass on any fail in BUILD directly back to caller

This means that .new may return a Failure from now on. So you can do a Foo.new // say "what" now.
This behaviour change does not cause any spectest breakage, and seems useful to have. sortiz++ for suggesting		 09:39
lizmat jnthn: any opinions about this ^^^ ? 09:40
jnthn Hmm 09:42
Dunno, it costs us the extra type-check... 09:43
OTOH, we don't have the cost of sinking :)
sortiz m: class Foo { submethod BUILD { fail "noway" }}; with Foo.new { say "good" } else { .fail };
camelia rakudo-moar b351d6: OUTPUTĀ«nowayā¤ in submethod BUILD at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Actually thrown at:ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
jnthn And they should probably be something we can optimize out in many cases, after my next chunk of work on code-gen'd BUILDALL 09:44
So I'm OK with it I think, but it could do with a pass through TimToady also. :)
It may be that failure to construct an object deserves to be fatal for some reason... 09:45
lizmat but being able to do Foo.new // say "what" seems useful as well, no ?
sortiz Or handled with 'with', 'andthen', etc. 09:46
jnthn Yes, provided it doesn't cause some kind of WTF I didn't foresee yet :) 09:47
lizmat fwiw, it didn't cause any spectest breakage :-)
sortiz lizmat, btw, what is the impact of that change in performance? 09:48
lizmat it would only affect classes with a BUILD in them 09:49
and now cause an extra nqp::istype
I'll benchmark in a moment, but I don't think it will cause a problem 09:50
sortiz Oki, thank you for the fast fix, and the improvement. 09:51
dalek ast: f2105b8 | lizmat++ | S12-construction/BUILD.t:
Add tests for RT #128393
 09:54
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128393
psch hmm, am i getting this right that the fix in nqp commit adb2c8f7 means that the nested CU MAST::Frames get added to the surrounding CU? as in, the EVAL M::Frames get added to the CU that does the EVAL 09:56
and doesn't that mean for nqp-j that, if we are in an EVAL, we don't want a J::Class, but just add the J::Methods to the surrounding J::Class?
well, even if that's true, there's still something missing. we also return a MAST::CU, and we probably also always use that for something... :/ 09:58
lizmat sortiz: within noise levels 10:00
sortiz lizmat++ # RT#128393 closed! 10:01
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128393
lizmat [Tux] : I seem to have mislaid the link to the test-t graphs again :-( 10:14
jnthn lizmat: See my blog post to learn how to measure beneath the noise leve :D ;) 10:15
lizmat yeah, I've read it...
jnthn (If it's helpful to you, anyways. :))
lizmat well, on OS X it's all different... :-( 10:16
jnthn Oh, damn :(
I had trouble using valgrind there, yeah :(
I can work it's just...it seems the OSX folks break the APIs they need every darn release or something :/
*It can work 10:17
lizmat anyways, it think it was more about "does this passing on Failure feature make things a lot slower" question
jnthn So last time I tried, I found that the latest shiny OSX version was just too new for valgrind to have been ported to it yet
lizmat it probably does, but we should have fixed the non-sinking of BUILD anyway, so
jnthn I'm somewhat tempted by OSX, but things like that kinda put me off...
lizmat yeah, I hear you 10:18
stmuk_ dtrace is a nice feature of OS X but the security settings don't let you trace system binaries like /bin/sh so no tracing of shell scripts :/
jnthn fwiw, is the "run latest" thing a carrot or a stick with OSX?
stmuk_ that really annoyed me
jnthn very rarely upgrades OS
(Still on Win7) 10:19
So I could live with "run an earlier version where valgrind et al work" :)
Provided that's practical (e.g. still gets security updates)
timotimo lizmat, jnthn, remember how i complained about the buildall generator being broken in a way i didn't understand at all? 10:23
yeah, more like, i forgot to return self at the end
lizmat remembers
that will break things :-) 10:24
timotimo on the other hand, the restricted setting blows up now while trying to compile ... :(
psch hrm, so i have an unsorted list of ints that are strictly ascending with one gap
dalek kudo/generate_buildallplan_3: 3fe4c30 | timotimo++ | src/ (3 files):
get a tiny head-start on generating buildallplan code in CompilerServices
kudo/generate_buildallplan_3: 8942239 | 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.
kudo/generate_buildallplan_3: 05b7c4c | timotimo++ | src/Perl6/World.nqp:
BUILDALL has to return self.
rakudo/generate_buildallplan_3: 9344cd9 | timotimo++ | src/Perl6/World.nqp:
psch e.g. (2, 1, 5, 3, Any, 0) or somesuch
dalek rakudo/generate_buildallplan_3: we removed the autovivs parameter for the time being
timotimo ^- rebased onto nom
psch sorting first is probably the best way to find the missing value, right? 10:25
timotimo that's not strictly ascending :)
lizmat psch: is it one or are there more ?
psch timotimo: well, right, sorted they would be, with one gap
lizmat: there could be more, but i care about all
timotimo ah
lizmat .grep(Int) ? 10:26
timotimo maybe Int:U
lizmat no, Int would be sufficient as Any is not an Int :-)
psch well, i'm in jvm/QAST/Compiler.nqp :)
timotimo oh, of course
lizmat and it would be fast, as grep is optimised to handle type objects, afaik
psch so this is more of a "how do i algo this", instead of "how do i use perl6 for this" type of question 10:27
(compounded by the fact that we apparently don't have an nqp level &sort, and i'd have to write that too...)
so, in the end i'm kinda hoping there's a smart solution that doesn't need me to implement sorting, but i'm all but resigned to have to implement sorting... :S 10:28
timotimo you can copy-paste it from QASTOperationsMAST
psch anyway, yeah, the problem itself is "i have a list of unordered ints that when ordered would be ascending with one or more gaps. how do i find the values that would fill the gaps to result in a strictly ascending list of ints" 10:29
and i'm thinking "sort and $a - $b == 1 afterwards for all elements"
timotimo sounds sensible 10:30
psch 'cause everything else i can think of involves at least two nested loops, and that's clearly slower than sorting and one pass over the sorted list
timotimo yeah 10:31
in algorithms class we were taught "always sort your input before you do anything with it, because complexity-wise, sorting is basically free"
psch yeah, that sounds reasonable
hm, p6sort is probably what i steal for that right 10:32
though i can probably simplify it at least a bit, since i only ever have < as comparator 10:33
timotimo so, the custom buildallplan is recursing endlessly ...
lizmat
.oO( it takes a while to build the univers )
timotimo maybe it's running into a code 0, which involves calling FLATTENABLE_LIST, which perhaps runs another BUILDALL to work?
lizmat FLATTENABLE_LISTS are really just the nqp:: parts, no ? 10:34
timotimo dunno, would have to look closer
what about FLATTENABLE_HASH? 10:36
lizmat they all just return nqp::hashes 10:37
timotimo hmm
maybe you have the chance to look at that branch and figure out what i'm failing 10:38
especially since you have memory of BUILDALL fresh in your mind :)
OK, the debug output i put into the step 0 runners doesn't show up 10:39
p6box_s shouldn't cause a BUILDALL to run, should it? 10:40
lizmat I don't see how it could
timotimo i've only implemented code 0 and code 1 in this branch ... so it must be one of those that's exploding
lizmat I mean, p6box_s is just short for box_s(..,Str), isnit it ? 10:41
psch practically, yeah
i think it does look into the hllconfig, but that turns out the same in the end
timotimo yeah, that's right
it shouldn't look into the hllconfig, though
it could perhaps be an exception being thrown from the buildall code 10:44
and creating the exception object invokes the buildall again?
dalek kudo/nom: 0b824ba | lizmat++ | src/core/SlippyIterator.pm:
/STATEMENT_LIST/stmts/ for SlippyIterator.slip-one

Regardless of STATEMENT_LIST being public or not, feels to me we shouldn't have it in the setting.		 10:45
lizmat timotimo: *that* could very well be the case
and from there, it goes into building a universe of errors
seen that before :-)
timotimo yes, Exception. over, and over, and over, and over again 10:51
beh. how do i figure out where this asplodes? 10:52
nine psch: yes, adding the MAST::Frames to the surrounding CU is exactly what happens and adding the J::Methods to the surrounding J::Class is exactly what we should do. It only gets complicated, when we have more than one EVAL and all of them should add to the surrounding J::Class. 10:55
psch: on Moar we just merge those hashes into one. We cannot just do that with J::Classes 10:56
psch: instead we have to pass on the first J::Class to those other EVALs and finally use it for the surrounding CU.
psch nine: right. i was thinking on building a J::Method that calls the nested J::Class' mainline
nine: i don't think we can reuse the same J::Class, since JAST::Compiler always builds a full class 10:57
nine psch: can we tell the JAST::Compiler to keep the class "open" so we can continue to add?
psch nine: the problem i see is that we'd have to conditianally skip/hack around a lot of things, e.g. generation of getCallSites, loadQbid, entryQbid 10:59
Zoffix šŸŽŗšŸŽŗšŸŽŗ REMINDER: Rakudo #100 will be released this Saturday. You're invited to to update the ChangeLog file, update the ROADMAP, etc.
psch which i think is more trouble than it'd be worth. i'm still wondering where to put the nested JCLASS, though...
nine: also, i don't think "keeping open" is the problem, the problem is more that we generate a whole class for the nested CU, with e.g. the mentioned methods 11:00
nine psch: ah, now I get you. So for our nested CU structure we get an equally nested JCLASS structure.
psch nine: yeah, that's my thought
'cause we kinda have to lean onto the jvms structure there 11:01
nine Sounds like a clean solution if you can pull that off :)
psch yeah, wondering about that myself... :)(
-(
|Tux| lizmat, I have no scrollback of the past 3 hours, but you were looking for tux.nl/Talks/CSV6/speed4.html ? 11:03
lizmat yup, thanks
timotimo ha!
i'll just bail out of creating the buildall when the name is "Exception"
fantastic!!
nine |Tux|: maybe we should put your URI into the topic ;) You seem to be answering the question quite regularly 11:04
|Tux| feel free 11:05
timotimo .. and for "Any" as well ... 11:06
things are still broken :( 11:15
dalek kudo/nom: 313bb18 | lizmat++ | src/core/Str.pm:
/STATEMENT_LIST/stmts/ for Str.split
 11:16
lizmat timotimo: not sure how I can help you with that 11:17
timotimo Use of uninitialized value of type Str in string context
Any of .^name, .perl, .gist, or .say can stringify undefined things, if needed. in block <unit> at tools/build/install-core-dist.pl line 18
that seems to happen after the first customly compiled buildplan runs in the build process
lizmat something with code 10 ? 11:18
seems to be the only string like initialization ? 11:19
timotimo thing is, i put little says into the compiled code to run for each code 11:20
the only buildplan that gets compiled & run is Cool, which ends up with 0 steps
lizmat hmmm...
I must admit I don't fully grok the building of the buildplan itself 11:21
I basically only looked at the code and made sure it did the same thing when optimizing BUILDALL
:-(
timotimo the only thing i know about that is that we inspect all the vars and such and then emit a list of "opcodes" with the right parameters ...
lizmat yup, that is my understanding as well
and those "opcodes" are handled by BUILDALL 11:22
timotimo right
i don't know more than you, then :)
one thing i do know is if i implement code 4 next, all the X:: classes will suddenly have their buildplans compiled 11:23
of course it'd be much nicer if the compiled buildplans would actually not cause things to asplode 11:24
dalek kudo/nom: 56bbc8d | lizmat++ | / (2 files):
/STATEMENT_LIST/stmts/ in SLICE
 11:29
p: 0f4d0af | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Implement dummy nqp::lock and nqp::unlock, we don't support threads on the js backend.
 11:36
p: dcb6308 | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js:
[js] Avoid a console.log when throwing an exception that might get caught.
p: dd2a118 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Support creating a dummy ReentrantMutex type object.
p: 297fb11 | (Pawel Murias)++ | src/vm/js/Compiler.nqp:
[js] Use the variable type when compiling variables as dynamic.
nqp: 1a373fd | (Pawel Murias)++ | src/vm/js/nqp-runtime/sixmodel.js:
nqp: [js] Remove no longer needed TODO.
kudo/nom: ae74c90 | lizmat++ | src/core/Map.pm:
/STATEMENT_LIST/stmts/ for Map.kv
 11:45
psch hrm, this is really keeping me guessing 12:04
i mean, we do have the right amount of methods, but one slot is empty and we have one method that has a qbid equal to the size of the class' methods array 12:05
moritz we have quantum bids now? :-) 12:09
psch moritz: we've had them in nqp-j since its inception, i think ;) 12:10
moritz psch: maybe we should use that to get some grant money :-)
psch although i readily admit i don't really know what the qb in qb id stands for
QAST Border, maybe..?
oh, QAST Block, if anything like that 12:11
cause that's what they correspond to on the nqp-ish level i think
jnthn QAST::Block
psch well, i'll just assume that we actually are just missing one jmeth, and the fact that we have a qbid that's greater than the last assignable element in JCLASS.methods happens because we count only the existing methods 12:15
because if i'd assume that we have an off-by-one somewhere in cuid_to_qbid then i'd be completely clueless vOv 12:16
because that sub really shouldn't produce anything off-by-one-y
dalek kudo/nom: 7f0f464 | lizmat++ | src/core/Hash.pm:
/STATEMENT_LIST/stmts/ for Hash.push/append
 12:24
nine So it's not a q bid but a qb id! That explains the mystery :) 12:52
psch: I guess the missing jmeth is the EVAL's mainline? 12:53
psch nine: yeah, that's what i'd assume 12:54
dalek kudo/nom: ea53ce5 | lizmat++ | src/core/Array.pm:
/STATEMENT_LIST/stmts/ for Array.iterator|is-lazy|shift
 12:57
timotimo lizmat: i don't know if you've looked at the buildplan compiler, but all it does is read the buildallplan (just like BUILDALL itself would) but instead of acting it out, it concatenates the instructions into a QAST::Block or whateve 13:10
lizmat I looked at it, but got scared by the amount of QAST 13:11
I don't think enough in trees yet
timotimo ah
ideally, the trees would look the same as the stuff in the BUILDALL
but ... yes, it's a bit hard on the eyes
lizmat I'm trying to get some things done before travel to YAPC::NA 13:12
timotimo OK 13:13
lizmat won't be having much time for hacking while there, I would think
and I plan to be translating perl6intro to Dutch on the way there
(and back, probably)
timotimo oh, that's pretty cool! 13:17
dalek kudo/nom: 350a8cd | lizmat++ | src/core/List.pm:
s/STATEMENT_LIST/stmts/ for List.iterator|is-lazy|FLATTENABLE_LIST
 13:30
kudo/nom: ffba1fd | lizmat++ | src/core/List.pm:
/STATEMENT_LIST/stmts/ for infix:<,>
 13:40
kudo/nom: 42e72a4 | lizmat++ | src/core/Any-iterable-methods.pm:
/STATEMENT_LIST/stmts/ sequential-map

Alas, couldn't nqp-ify deeper: during setting compilation, MAST stage the error "Cannot reference undeclared local '__lowered_lex_3205'" would occur. Could not find a way around that :-(		 14:50
timotimo uh oh, the optimizer has asploded when that message shows 14:51
dalek kudo/nom: c8c8de6 | (Brock Wilcox)++ | src/ (2 files):
Migrate more looping and printing into REPL.pm
kudo/nom: 74138ef | (Brock Wilcox)++ | src/core/REPL.pm:
Make implicit return style consistent

  /STATEMENT_LIST/stmts/ for IO::Handle.comb|Supply
lizmat sorry dalek
afk for a few hours& 15:13
|Tux| This is Rakudo version 2016.05-138-g6b93592 built on MoarVM version 2016.05-18-g1339332 16:00
test 16.669
test-t 9.356
csv-parser 21.309
psch "java.lang.invoke.WrongMethodTypeException: expected (ThreadContext,CodeRef,CallSiteDescriptor)void but found (ThreadContext,CodeRef,CallSiteDescriptor)void" 16:02
oh java /o\
masak [Tux]: wow, 9.4 16:04
no longer noise :)
lizmat++ jnthn++ others++ # fasterening
|Tux| I'd say: just continue this nice work :) 16:05
masak playing devil's advocate for a while... I for one would really like to see Rakudo become a lot slower again 16:07
(not really) :P
sexy-coder-girl Is one of those values the Perl 5 version? 16:09
nine sexy-coder-girl: AFAIK the Perl 5 versions are in the 0.1 second range or even faster... 16:10
perlpilot only if you adjust the location of the decimal place
sexy-coder-girl :(
jnthn nine: Pure Perl 5 versions? 16:19
timotimo yeah, tux has a bunch of csv benchmark code thingies in a table 16:31
tux.nl/Talks/CSV6/speed5.html 16:32
jnthn: ^ 16:33
[Coke] m: say 9.536 / 0.033 16:50
camelia rakudo-moar 6b9359: OUTPUTĀ«288.969697ā¤Ā»
[Coke] m: say 9.536 / 0.125
camelia rakudo-moar 6b9359: OUTPUTĀ«76.288ā¤Ā»
[Coke] so about 76 times slower than the pure perl5 version.
... er. that table has lots of things under modules, probably -this- one: 16:51
m: say 9.536 / 0.501
camelia rakudo-moar 6b9359: OUTPUTĀ«19.033932ā¤Ā»
[Coke] that's perl6's Text::CSV vs. perl5's Text::CSV_PP
wow. and 8s of that has nothing to do with processing time, it seems. 16:52
m: say (9.536-8.045) / (0.501-0.484) 16:53
camelia rakudo-moar 6b9359: OUTPUTĀ«87.705882ā¤Ā»
|Tux| [Coke] feel free to improve of timing approaches ( github.com/Tux/CSV/blob/master/time.pl )
[Coke] [Tux]: not sure how to improve it, just wanted to compare apples to apples if possible. 16:54
I think I ended up in the right place.
masak .oO( you ended up in the 80s ) 16:55
[Coke] RT: 1326; CONC: 7; GLR: 6; JVM: 70; LHF: 1; LTA: 75; NYI: 28; OSX: 6; PERF: 16; POD: 3; PRECOMP: 3; RFC: 24; SEGV: 21; STAR: 1; TESTNEEDED: 29; TODO: 9; UNI: 5; WEIRD: 3 17:13
timotimo spending only 80s in the 80s doesn't sound so terrible 17:25
TimToady spent 315619206s in the 80s 17:51
nine To calculate that I'd need a definition of an exact moment of birth 17:53
sexy-coder-girl I spent... 17:55
m: say DateTime.new(:1990year :01month :01day).Instant - DateTime.new(:1986year :04month :03day :23hour :57minute).Instant
camelia rakudo-moar 6b9359: OUTPUTĀ«118195382ā¤Ā»
sexy-coder-girl m: say DateTime.now - DateTime.now
camelia rakudo-moar 6b9359: OUTPUTĀ«Cannot resolve caller Numeric(DateTime: ); none of these signatures match:ā¤ (Mu:U \v: *%_)ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā»
sexy-coder-girl ^ kinda expected that to DWIM
geekosaur spent more time in the 80s than he prefers to remember >.> 17:58
nine I'm bisecting Perl 5 to find where exactly Inline::Perl5 stopped working (somewhere between 5.23.7 and 5.23.8). But what do I do when I do get an error that's a bit like the one I'm looking for but not exactly the same? 18:13
bad or good?
[Coke] nine- you can also skip 18:16
nine I voted bad on the premise that debugging an error is much harder when there's another one around that leads to a similar error message 18:17
Oh, this commit message explains rather well why we segfault after an endless recursion of "Method 'DESTROY' not found for invocant of class 'X::Method::NotFound': 18:23
[perl #124387] call AUTOLOAD when DESTROY isn't defined
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=124387
FROGGS o/ 18:24
timotimo o/ 18:26
lizmat the core is now STATEMENT_LIST free 18:54
dalek kudo/nom: f7c8dc3 | lizmat++ | src/Perl6/Grammar.nqp:
Eradicate SEQ
 18:56
lizmat wrt STATEMENT_LIST: I propose we remove directly after the next release
so we have a whole month to catch any ecosystem fallout 18:57
vendethiel oh, that's to be removed? I need to backlog. 18:58
lizmat vendethiel: well, it's not documented anywhere, there are no tests for it, and it feels like a core / setting internal 19:00
which it isn't anymore
if we want something like that in the language, it should probably be called something else
vendethiel well, it was removed back when TimToady++ was implementing his LOLlypop (; as dimensions), and it was used to replace it. 19:01
lizmat otoh, ideally the optimizer should be able to tell it can do a STATEMENT_LIST on any scope
vendethiel I can see a point to a comma operator, though.
lizmat vendethiel: ??
STATEMENT_LIST was a way to e.g. postfix loop / if on a set of statements without creating a scope 19:02
vendethiel I mean a comma operator in the C-family-of-languages sense 19:05
FROGGS (I still dont get it)
vendethiel C, Java, JavaScript, C++
well, in all of these, if (true) print("a"), print("b"); will do both prints sequentially in the if. That's what it did before LoL semantics in Rakudo 19:06
nine lizmat: looking at travis-ci.org/niner/Inline-Perl5/b.../137321222 it seems like it's impossible to provide an Inline::Perl5 that works with rakudos before and after your removal of BUILDALL's positional :(
lizmat hmmm... perhaps if add another candidate *with* positionals ? 19:07
FROGGS nine: cant you query BUILDALL.signature.params.elems or so? 19:08
I mean, it's horrible, but still
m: if 1 { say(42), say(111) }
camelia rakudo-moar 6b9359: OUTPUTĀ«42ā¤111ā¤Ā»
FROGGS vendethiel: where is my thinko? 19:09
timotimo the return value of a comma operator is the last value of the "list"
in your example the return value would be a list of two True s
FROGGS m: say do if 1 { say(42), say(111) } 19:10
camelia rakudo-moar 6b9359: OUTPUTĀ«42ā¤111ā¤(True True)ā¤Ā»
FROGGS yes, that's what I would expect
nine lizmat: you mean like this? gist.github.com/niner/9dcfde064e19...013107a69c 19:11
lizmat nine: no, I was thinking to have that candidate in the settings 19:12
spectesting that now
nine ok...my patch doesn't work anyway :) 19:13
vendethiel FROGGS: well, that's not a "comma operator" :-) 19:16
in the languages I listed above, (1, 2, 3) is 3. 19:17
FROGGS "I see" :P 19:18
dalek kudo/nom: ed510c5 | lizmat++ | src/core/Mu.pm:
Provided a BUILDALL with positionals

For compatibility with modules such as Inline::Perl5		 19:22
lizmat nine: ^^^
nine lizmat: great! Then I'll revert your Inline::Perl5 patch 19:47
lizmat okidoki... 19:48
nine Closed 5 Inline::Perl5 issues today. I almost forgot how much fun working on such "little" things can be :) 19:59
jdv79 nice 20:04
oh, in installs now. woohoo. 20:07
*it
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/06/13/...ng-to-tpc/ 20:09
FROGGS \o/ 20:13
perlpilot Is YAPC re-branding to TPC, or is that a lizmatism? 20:27
masak yay, `signal(SIGINT)` works just splendid!
perlpilot I mean, so far the only person I 20:28
I mean, so far the only person I've seen call it TPC has been lizmat 20:29
[Coke] perlpilot: that's the old name.
IIRC
perlpilot no, TPC morphed into OSCON.
[Coke] also, look at www.yapc.org/
masak perlpilot: so far the only people I've seen call YAPC::NA "YAPC" has been people from the US :P
lizmat and YAPC is now morphing into The Perl Conference
check out www.yapcna.org/yn2016/ 20:30
perlpilot excellent
lizmat it says:
"The Perl Conference in Orlando"
perlpilot I've never thought much about it but recently had to explain to a few people what "YAPC" is and then had to explain why it's called YAPC. Calling it "The Perl Conference" is definitely better. 20:32
masak: The US is the most important country on the planet dontcha know! ;)
dalek kudo/nom: 5de2d8b | lizmat++ | docs/ChangeLog:
Add some ChangeLog entries
 20:35
timotimo typo "no longer fail." -> "no longer fails." 20:37
masak perlpilot: I can't think of anything to say in response to that that isn't kicking someone who's already down :P 20:38
jdv79 the next iteration will be to PerlCon and then finally to PCON 20:39
masak perlpilot: I'll give you this: your presidential races are captivating.
perlpilot masak: hey! Didn't you see the sign last time you were here? "USA -- birthplace and current residence of Larry Wall" 20:44
masak you have a point, sir. 20:46
jnthn lizmat++ # p6weekly 21:03
dalek kudo/nom: 865bf36 | lizmat++ | docs/ChangeLog:
Fix typo, timotimo++
timotimo weekly++ # lizmat 21:11
jnthn icecream has 40% discount.. 21:21
oh
Not only wrong window, but wrong app. Good job, jnthn :P 21:22
tadzik :D
lizmat screams haz 50% 21:31
jnthn Those I get for free just by reverting the right commit :P 21:43
'night, #perl6-dev 21:49
Zoffix night 21:52
lizmat gnight jnthn 21:55
developer.apple.com/library/prerel...TP40016999
AppleFS
gnight, perl6-dev! 22:07
Zoffix night 22:11

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!