| Geth | nqp: 1f0a598e37 | (Samantha McVey)++ | tools/build/MOAR_REVISION Bump MoarVM to get uniname fixes Adds hex digits to end of non-unique Unicode names, and returns noncharacter property for noncharacters as well as not returning <illegal> except for codepoints that are less than 0. Changes: 2017.09.1-32-g9749b0f..2017.09.1-46-g27d3d01e ... (6 more lines) |
00:11 | |
| ¦ nqp: version bump brought these changes: github.com/MoarVM/MoarVM/compare/2...-g27d3d01e | |||
| rakudo/nom: 9dba498f7f | (Samantha McVey)++ | tools/build/NQP_REVISION Bump NQP/Moar for uniname fixes Adds hex digits to end of non-unique Unicode names, and returns noncharacter property for noncharacters as well as not returning <illegal> except for codepoints that are less than 0. NQP changes: 2017.09-18-g59612c4..2017.09-36-g1f0a598e3 ... (26 more lines) |
00:13 | ||
| ¦ rakudo/nom: version bump brought these changes: github.com/perl6/nqp/compare/2017....g1f0a598e3 | |||
| roast: 8e4e510408 | (Samantha McVey)++ | S15-unicode-information/uniname.t Update uniname tests to test hex after non-unique's Instead of just testing <Control-0000> we also test for CJK Ideographs like <CJK Ideograph-XXXX>. All names starting with a '<' and ending with '>' are inherently nonunique names, so we give them names similar to how they are refered to within the Unicode dataset. Also test that noncharacters return <noncharacter-XXXX> rather than illegal or reserved. Check that we get reserved instead of illegal back for characters that are non-illegal but under 0x10FFFF |
00:21 | ||
| roast: 0b471ac100 | (Samantha McVey)++ | S32-str/utf8-c8.t Add UTF8-C8 tests for values > 0x10FFFF as well as Surrogates These tests also now pass due to recent fixes in MoarVM's UTF8-C8 generating code. |
|||
| travis-ci | NQP build failed. Samantha McVey 'Bump MoarVM to get uniname fixes | 00:26 | |
| travis-ci.org/perl6/nqp/builds/280210547 github.com/perl6/nqp/compare/8e780...0a598e37af | |||
| BenGoldberg | m: (-42).uniname | 00:44 | |
| camelia | ( no output ) | ||
| BenGoldberg | m: (-42).uniname.say | ||
| camelia | <illegal> | ||
| Zoffix | grrr fudger doesn't fudge subtests right >_< | 00:50 | |
| skids | timotimo: oh yay I was wrong, :sym stuff works fine. | 00:52 | |
| Geth | roast: 44937e865e | (Zoffix Znet)++ | S05-metasyntax/regex.t Add fudged tests for Range quantifiers in regexes |
00:53 | |
| travis-ci | Rakudo build passed. Zoffix Znet 'Fix infinilop in .^roles of class that does Rational | 01:35 | |
| travis-ci.org/rakudo/rakudo/builds/280107431 github.com/rakudo/rakudo/compare/6...61abe8fff0 | |||
| AlexDaniel | .tell skids “Any obvious repo in which to plop this?” – maybe github.com/rakudo/rakudo/wiki | 07:51 | |
| yoleaux | AlexDaniel: I'll pass your message to skids. | ||
| AlexDaniel | squashable6: status | 07:55 | |
| squashable6 | AlexDaniel, Next SQUASHathon in 9 days and ≈2 hours (2017-10-07 UTC-12⌁UTC+14) | ||
| AlexDaniel | :O | ||
| DrForr | On a split network, noone can hear you /say. | 08:03 | |
| nine_ | :) | 08:13 | |
| AlexDaniel | .oO( split network? ) |
08:29 | |
.oO( did somebody just think that whateverables rejoining is a network split? Or did I miss the actual split? ) |
08:30 | ||
| nine_ | AlexDaniel: you missed the split | 08:32 | |
| AlexDaniel | ah ok | ||
| teatime | Netsplit *.net <-> *.split quits: astj, nine, BooK, teatime, jdv79 | 08:34 | |
| granted I don't know much about irc, but hth can I see myself split | |||
| am I like Thomas Riker now, and there's another me, out there, somewhere... | 08:35 | ||
| lizmat | in QAST, I want to flatten an nqp::hash into a call, basically the |%attrinit | 09:24 | |
| is the only way really to call FLATTENABLE_HASH on the HLL version of it? | |||
| feels very wasteful to me | |||
| jnthn timotimo moritz ^^^ | 09:25 | ||
| feels I should only need to add a :flat in there somehow | 09:26 | ||
| and possibly a :named | |||
| moritz | you can iterate over the hash and add :named arg for each element | 09:33 | |
| lizmat | ok, I see that | 09:36 | |
| but I probably don't want to encode that in QAST for each BUILDALL, right ? | 09:38 | ||
| pmurias | jnthn: what does fles mean? attributes get that | 09:44 | |
| jnthn | If it's an NQP hash you just put :flat(1), :named(1) | 09:45 | |
| moritz | ah, nice | ||
| jnthn | That's actually what | compiles into also | 09:46 | |
| It just first calls .FLATTENABLE_HASH to extract the nqp hash inside of it | |||
| moritz | pmurias: it's "self" reversed | ||
| jnthn | m: "fles".flip.say :) | ||
| camelia | 5===SORRY!5=== Error while compiling <tmp> Unexpected closing bracket at <tmp>:1 ------> 3"fles".flip.say :7⏏5) |
||
| jnthn | m: "fles".flip.say # :) | ||
| camelia | self | ||
| moritz | pmurias: and seems to be used in locations where 'self' can't be used, because it's reserved, or bootstrapping doesn't like it | 09:47 | |
| jnthn | Yeah, it's that, I think 'cus the other self was needed in that context too or some such :-) | ||
| moritz | might be clearer to call it SELF | ||
| jnthn | bah, the reason my patch last night didn't work is 'cus I inverted the very conditions I meant to add | 09:56 | |
| lizmat | hehe | ||
| If in QAST I want to return from a sub, do I just call 'return' ? or is there a better way ? | |||
| jnthn | Are you in the outermost scope of it? | 09:58 | |
| lizmat | no | ||
| this is basically for the case that BUILD or TWEAK return a Failure | 09:59 | ||
| we want that returned immediately | |||
| jnthn | I mean, you're in the QAST::Op you want to return from? | 10:01 | |
| lizmat | this is what I need to rewrite in QAST: github.com/rakudo/rakudo/blob/nom/...Mu.pm#L159 | 10:02 | |
| jnthn | gah, I meant QAST::Block that you want to return from | 10:03 | |
| lizmat | yeah, that I am :-) | ||
| jnthn | Ok, I think then just QAST::Op.new( :op('return'), ...lookup the thing to return here... ) | ||
| Will be the best way | 10:04 | ||
| lizmat | ok, that's what I did | ||
| Zoffix | No [Tux] timings yet? I had a dream my optimizer fix made things .3s slower :D | ||
| jnthn | If you want to call the Perl 6 return sub you'd need to set up a return handler also | ||
| lizmat: Does it work, or not? :) | 10:05 | ||
| lizmat | well, building takes about 1.5 minutes each time :-) | ||
| jnthn | ah :) | ||
| lizmat | and now I'm looking at some wrongly positioned parens or something | 10:06 | |
| jnthn | Hm, what a bizzare failure mode I now get... | ||
| [TuxCM] | $work interfered and I forgot. running now | 10:08 | |
| Zoffix | \o/ | 10:11 | |
| [TuxCM] | This is Rakudo version 2017.09-100-g9dba498f7 built on MoarVM version 2017.09.1-46-g27d3d01e | 10:16 | |
| csv-ip5xs 1.299 - 1.320 | |||
| test 9.353 - 9.637 | |||
| test-t 3.314 - 3.429 | |||
| csv-parser 12.023 - 12.046 | |||
| Zoffix | buggable: speed 6 :4 | 10:18 | |
| buggable | Zoffix, dates: 2017-09-25–2017-09-27 | ||
| Zoffix, ▃▇ ▇ range: 3.314s–3.556s | |||
| Zoffix, ██▄█▄ speed: 6% faster | |||
| Zoffix, █████▁ | |||
| Zoffix | buggable: speed 100 :4 | 10:19 | |
| buggable | Zoffix, ▇▆▅↑↑↑▇▇▆▇▇↑↑↑█↑ ▃ dates: 2017-08-08–2017-09-27 | ||
| Zoffix, ████████████████ ▄ ▇ █ range: 3.314s–4.925s | |||
| Zoffix, ████████████████▄█▆▆▂█ ▂ ▂ ▇▃ ▇ ▇▃█▁ ▂ ▃ ██ speed: 8% faster | |||
| Zoffix, ███████████████████████▅▆█▆▆██▆▅▄▃██▄▅▄▆▅▄▅▃▄▄█▇▅▅▇████▅▆▆▅█▅▆▃▃▇██▇██▆▇▅▆▄▃▄▅▄▅▃▃▅▄▃▇▄▄▃▃▃▄▄▄▆▇▄▇▄▁ | |||
| Zoffix | Progress | ||
| jnthn | yay :) | 10:21 | |
| Wondered how async changes had managed to make a Rat test hang :P | 10:22 | ||
| Turns out I just needed to pull latest changes :) | |||
| lizmat | jnthn: No registered operation handler for 'return' :( | 10:30 | |
| grrr | |||
| I need to call 'return', right | |||
| jnthn | Hmmmm | 10:32 | |
| Yeah but that needs to wrap a return exception handler too | |||
| But it's the most expedient way for now | |||
| Geth | rakudo/nom: bd530108c4 | (Jonathan Worthington)++ | src/core/CurrentThreadScheduler.pm Fix CurrentThreadScheduler error handling It is used as a type object rather than an instance in quite some tests, and so very possibly in the wild too. So make sure that it doesn't explode due to trying to look up an error handler from a type object. |
10:33 | |
| lizmat | jnthn: any prior art that could enlighten me re wrapping an exception handler ? | ||
| now I get: Attempt to return outside of any Routine :) | 10:34 | ||
| jnthn | yeah, that's 'cus you're missing the handler | 10:35 | |
| lizmat | also: could that be set up conditionally upon receiving of a failure ? or does it need to be set always? | ||
| jnthn | in Actions.pm there's a wrap_return_handler | ||
| Setting it us is free anyway | |||
| lizmat looks | |||
| jnthn | It just makes a compile-time entry into a table of handlers | 10:36 | |
| You only pay for throwing the return control exception | |||
| oh also | 10:38 | ||
| you need something simpler than wrap_return_handler | |||
| lizmat | well, perhaps, I'm not seeing it yet :-) | ||
| jnthn | You don't need wrap_return_type_check nor the decontrv thing | ||
| sub wrap_return_handler($past) { | 10:39 | ||
| Is where I'm looking | |||
| The important bits you need are | |||
| QAST::Op.new( | |||
| :op<handlepayload>, | |||
| After that you put a QAST::Stmts holding your generated stuff | 10:40 | ||
| Then after it | |||
| 'RETURN', | |||
| QAST::Op.new( :op<lastexpayload> ) | |||
| ) | |||
| And you're done | |||
| Then calling return will work :) | |||
| lizmat | ok, lemme see if I can get that together :-) | ||
| jnthn | tests++ # keeping me from regressing error reporting on await | 10:46 | |
| Zoffix | ZOFVM: Files=1280, Tests=152198, 151 wallclock secs (21.91 usr 3.46 sys + 3149.98 cusr 269.45 csys = 3444.80 CPU) | 10:54 | |
| And strangeley the failing sock test file passed :| | |||
| The one about IPv6 | 10:55 | ||
| lizmat | jnthn: shouldn't it be the QAST::Block that I should wrap ? | 10:56 | |
| jnthn | No | ||
| Second QAST::Stmts that you put into the QAST::Block | |||
| lizmat | $stmts := QAST::Op.new( :op<handlepayload>, | ||
| $stmts, | |||
| 'RETURN', | |||
| QAST::Op.new( :op<lastexpayload> ) | |||
| ); | |||
| yeah, that's what I did, no? | 10:57 | ||
| jnthn | That looks ok | ||
| Seems so, if that's what $stmts is :) | |||
| You push $stmts into the QAST::Block after this, I presume? | |||
| lizmat | yes, that's what $stmts is | ||
| aaaaahhhh :-) spot on | |||
| whee! BUILD and TWEAK support now in | 11:01 | ||
| jnthn | \o/ | 11:02 | |
| lizmat++ | |||
| lizmat | now those pesky other cases :-) | ||
| jnthn | Hurrah, it looks like I've managed to unregress all that I broke in my supply internals refactor | 11:03 | |
| lizmat | jnthn++ | ||
| Geth | rakudo/nom: 9af5607d52 | (Jonathan Worthington)++ | 2 files Start using $*AWAITER in `await` in 6.c But set an additional flag indicating that we should really block, so we still get the 6.c semantics, just in terms of the new factoring. This means that the parts of the new supply concurrency model that depend on the use of $*AWAITER will now work out with 6.c code that does an `await` in the mainline of a `supply` block. It also means that we'll from today be exercising much of the code that makes up 6.d non-blocking await, except the bit in ThreadPoolScheduler that actually does the non-blocking part of the job. |
11:10 | |
| jnthn | Phew. :) | 11:12 | |
| lizmat | jnthn++ # wow | 11:13 | |
| jnthn | With all these changes, using await inside of a supply/react block will now be able to do the continuation thing also, plus supplies now have a better back-pressure model | 11:15 | |
| So I should be able to, in the coming weeks, put in some stuff so that if we are, say, processing lines from a Proc::Async too slowly to keep up with the rate of output, then we can stop the libuv reader for a bit, which will in turn push back on the outputing process. | 11:16 | ||
| Rather than them piling up in memory, as they have to date | |||
| Ditto for async sockets | |||
| Also, this now works: | 11:20 | ||
| my $s = supply { until my $end { emit 42 }; CLOSE { $end = True } }; react { whenever $s { .say; done if $++ == 5 } } | |||
| m: my $s = supply { until my $end { emit 42 }; CLOSE { $end = True } }; react { whenever $s { .say; done if $++ == 5 } } | |||
| camelia | 42 42 42 42 42 42 |
||
| jnthn | c: 2017.09 my $s = supply { until my $end { emit 42 }; CLOSE { $end = True } }; react { whenever $s { .say; done if $++ == 5 } } | ||
| committable6 | jnthn, ¦2017.09: ««timed out after 10 seconds» «exit signal = SIGHUP (1)»» | ||
| jnthn | Which is kinda nice in that it's now possible to write supply sources in a nicer way in various case | 11:21 | |
| *cases | |||
| For example: my $poll-api = supply { until my $end { emit await download-latest-stuff-from-api(); await Promise.in(10); }; CLOSE { $end = True } } | 11:22 | ||
| Will, in 6.d, work out without blocking a real thread anywhere, and let you write a supply source that polls an API every 10 seconds. | 11:23 | ||
| I'm considering whether an `emit` in an already closed block should just tear down the block also | |||
| So then folks who didn't think to write the CLOSE block won't end up in bother | 11:24 | ||
| Probably should do that :) | |||
| So it DWTM :) | |||
| tl;dr supply syntax is nicer for writing sources now, and back-pressues in a better way | 11:25 | ||
| Also I might find something to do that melts my brain slightly less after this :-) | 11:28 | ||
| Though I'm quite keen to get hyper/race in shape for 6.d | |||
| So will probably look at that in the not too distant future | 11:29 | ||
| hyper whenever and race whenever also, mebbe | |||
| We'll see :) | |||
| timotimo | i haven't heard of those yet :) | 11:40 | |
| lizmat suffers from melting brain as well | 11:44 | ||
| but is moving forward nonetheless... mostly SMOP now | |||
| Geth | roast: 292e1d9f7e | (Zoffix Znet)++ | VERSION Add version file |
12:13 | |
| roast/6.c-errata: 80a7391486 | (Zoffix Znet)++ | VERSION Add version file |
12:14 | ||
| nine_ | jnthn: do you think I can merge jit_nativecall this week? I'll be on vacation on the first 2 weeks of October | 12:26 | |
| jnthn | nine_: Yes; I will try and look it over today, now that I'm finally done with the supply things and seem to me largely without headache too | 12:34 | |
| nine_ | \o/ | ||
| jnthn | git push | 12:36 | |
| gah! | |||
| Geth | roast: ed27a2620e | (Jonathan Worthington)++ | S17-supply/syntax.t Test covering first part of RT #130716 solution |
||
| jnthn | nine_: I'm happy with it, and approved it. I trust the Travis failures are 'cus we need to merge the NQP commits also? | 12:44 | |
| nine_ | jnthn: yes, we do | 12:48 | |
| jnthn: thanks for looking :) | |||
| jnthn | I noticed one thing from brrt about adding a comment, but one added earlier on looked related, so not sure if that's still to do or not | 12:51 | |
| lizmat | hmmm... how do I pass an SVal as a named parameter ? | 12:52 | |
| just set :name<foo>, :named(1) ? | 12:53 | ||
| jnthn | QAST::SVal.new( :value('omg an awesome apricot'), :named('exclamation') ) | ||
| nine_ | jnthn: I added the describing comments to the header files while brrt's questions were added to the code where those constants were used | ||
| lizmat | oki | ||
| jnthn | nine_: Alrighty :) | ||
| Then I think we can merge it :) Shall i? :) | |||
| lizmat | jnthn: is there an QAST::OVal for opaque values? Or should I just use WVal for that ? | 12:56 | |
| timotimo | just WVal | 12:57 | |
| nine_ | jnthn: have to go to a meeting now. I'd be happy to let you do it :) | ||
| lizmat | timotimo: thanks | ||
| Geth | rakudo/multi-roast: 7d830d5c18 | (Zoffix Znet)++ | t/spectest.data.6.c Add 6.c test file list |
13:02 | |
| lizmat | only one more buildplan action to go! | 13:08 | |
| jnthn | nine_: It's merged; NQP/Rakudo ones and bumps I'll let you or somebody else do, as got language class now :) | 13:09 | |
| Zoffix pokes Geth | 13:11 | ||
| This thing's ded :o | |||
| travis-ci | Rakudo build failed. Jonathan Worthington 'Start using $*AWAITER in `await` in 6.c | ||
| travis-ci.org/rakudo/rakudo/builds/280379881 github.com/rakudo/rakudo/compare/b...f5607d523e | |||
| jnthn | Zoffix: It was a MoarVM merge I was mentioning and it was reported fwiw | ||
| buggable | [travis build above] ☠ Did not recognize some failures. Check results manually. | ||
| DrForr | *whirr* *click*buzz* it's dead, Ji. | ||
| *Jim | |||
| Zoffix | jnthn: I pushed github.com/rakudo/rakudo/commit/6c...b627d9091d and it didn't report it | 13:12 | |
| jnthn | Zoffix: ah, ok | ||
| timotimo | Stage parse : MoarVM panic: Internal error: invalid thread ID 14683768 in GC work pass | ||
| ouch?! | |||
| jnthn | Oops | 13:13 | |
| Wonder if that's the thing nwc10 spotted a while back, but I never managed to reproduce yet... | |||
| timotimo | (that's travis up there) | ||
| jnthn | Really time to go; bbiab | ||
| Geth | rakudo/multi-roast: 31cbdada73 | (Zoffix Znet)++ | t/harness5 Teach Harness5 to handle different roast versions |
13:23 | |
| rakudo/multi-roast: 16f64182f0 | (Zoffix Znet)++ | t/harness6 Teach Harness6 to handle different roast versions |
13:47 | ||
| Zoffix | huh | 13:50 | |
| m: "blazrg".IO.open andthen 42.say orelse dd $_ | |||
| camelia | Empty | ||
| Zoffix | not this again -_- | ||
| Ah, ok, it's per-spec. nevermind. I thought oreelse would have the Failure there | 13:51 | ||
| Geth | nqp: 71fc322e56 | (Stefan Seifert)++ | 13 files Map the new nativeinvoke OP nativecallbuild now has a return value indicating whether we were able to JIT compile code for the call site |
13:54 | |
| Zoffix | m: +"x" orelse note "{.exception.message.uc}" | 13:58 | |
| camelia | CANNOT CONVERT STRING TO NUMBER: BASE-10 NUMBER MUST BEGIN WITH VALID DIGITS OR '.' IN '⏏X' (INDICATED BY ⏏) | ||
| Zoffix | huh weird. On my terminal, everything before "X" is invisible | ||
| or blank rather | |||
| m: sub x { my $ver = .lines.uc with "blazr".IO.open orelse note "meow {.exception.message}" and return 42; "meow$ver" }; dd x | 13:59 | ||
| camelia | No such method 'exception' for invocant of type 'Any' in sub x at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| Zoffix | m: sub x { my $ver = .lines.uc with "blazr".IO.open orelse note "meow " ~ .exception.message and return 42; "meow$ver" }; dd x | 14:00 | |
| camelia | meow Failed to open file /home/camelia/blazr: No such file or directory 42 |
||
| ugexe | on a linux terminal im only getting a ), on osx i get the X | ||
| Geth | rakudo/nom: 6 commits pushed by (Stefan Seifert)++
|
14:01 | |
| nine | lizmat: for the weekly, JIT compilation of native calls gives ~ 2.5x speedup in micro benchmarks and ~ 7 % speedup for csv-ip5xs (which shows there's still a lot of overhead in Inline::Perl5's Perl 6 code). | 14:03 | |
| yoleaux | 24 Sep 2017 20:38Z <lizmat> nine: wrt to calling BUILDALL with positionals: could we create another name for that, like BUILDALL_WITH_POSITIONALS() ? | ||
| 24 Sep 2017 20:39Z <lizmat> nine: BUILDALL could then be an only method, instead of a multi | |||
| nine | lizmat: but that would break installed Inline::Perl5 versions? | 14:04 | |
| Zoffix | \o/ | 14:05 | |
| Geth | rakudo/multi-roast: 50d2013de5 | (Zoffix Znet)++ | t/harness6 Report reason for failure when can't read roast version |
14:07 | |
| Zoffix | Reported above andthen bug as rt.perl.org/Ticket/Display.html?id=132172 | 14:11 | |
| .seen the-eater | 14:14 | ||
| yoleaux | I haven't seen the-eater around. | ||
| Zoffix | .seen theeater | ||
| yoleaux | I haven't seen theeater around. | ||
| Zoffix | .seen eater | ||
| yoleaux | I saw eater 25 Sep 2017 11:05Z in #perl6-dev: <eater> Zoffix: poke me if you need help resolving it :) | ||
| Zoffix | .tell eater the IPv6 sock roast failure magically disappeared :/ Perhaps it was just something with my VM | 14:15 | |
| yoleaux | Zoffix: I'll pass your message to eater. | ||
| Zoffix | ZOFVM: Files=1280, Tests=152201, 147 wallclock secs (22.42 usr 3.36 sys + 3085.28 cusr 239.28 csys = 3350.34 CPU) | 14:16 | |
| Geth | rakudo: zoffixznet++ created pull request #1173: Multi roast |
14:18 | |
| rakudo/nom: 6 commits pushed by (Zoffix Znet)++ | |||
| Zoffix | .tell stmuk as promised, just pushed a fix so `make spectest` on 6.c-errata no longer has spurious warnings about missing files. Any warnings that appear should be assumed to be geniune. | 14:20 | |
| yoleaux | Zoffix: I'll pass your message to stmuk. | ||
| Zoffix | Thank you, robot. | ||
| AelxDnaiel | Zoffix++ | 14:25 | |
| Geth | roast: aa29b31f90 | (Zoffix Znet)++ | 5 files Remove empty dummy files |
14:27 | |
| rakudo/nom: f62950dcc8 | (Zoffix Znet)++ | t/spectest.data Remove dead test files from 6.d.proposals test file list All of these files are just empty dummies[^1] that existed only to ensure their 6.c-errata counterparts run. Now, they live in their separate t/spectest.data.6.c list [1] github.com/perl6/roast/commit/aa29b31f90 |
|||
| rakudo/nom: 85ae1c92a7 | (Zoffix Znet)++ | 2 files Check for proposal roast versions case insensitively |
14:34 | ||
| rakudo/nom: dd8a610214 | (Zoffix Znet)++ | docs/roast-spectest.data-versioning.md Document how spectest.data file versioning works |
14:39 | ||
| roast: 12e6a25d81 | (Zoffix Znet)++ | VERSION Point to docs of rakudo's use of file |
14:41 | ||
| roast/6.c-errata: 37a4a2e5df | (Zoffix Znet)++ | VERSION Point to docs of rakudo's use of file |
|||
| rakudo/nom: 36122f158f | (Zoffix Znet)++ (committed using GitHub Web editor) | docs/roast-spectest.data-versioning.md Document spectest.data is also used when… …file for specific version file isn't readable |
14:47 | ||
| rakudo/nom: 2a512f0c23 | (Zoffix Znet)++ | 2 files Skip empty lines when reading roast VERSION file |
14:50 | ||
| eater | Zoffix: :D | 15:06 | |
| yoleaux | 14:15Z <Zoffix> eater: the IPv6 sock roast failure magically disappeared :/ Perhaps it was just something with my VM | ||
| stmuk | . | 15:27 | |
| yoleaux | 14:20Z <Zoffix> stmuk: as promised, just pushed a fix so `make spectest` on 6.c-errata no longer has spurious warnings about missing files. Any warnings that appear should be assumed to be geniune. | ||
| stmuk | Zoffix++ | 15:28 | |
| Geth | rakudo/nom: f133451248 | (Zoffix Znet)++ | t/harness6 Remove Perlism |
||
| Zoffix | stmuk: so what does this commit fix exactly? github.com/rakudo/rakudo/commit/06...ab89f13797 | 15:31 | |
| I see no ticket nor any explanation of the problem and the harness works fine for me | |||
| with TEST_JOBS=30 | |||
| .ask stmuk why is t/harness6 blocked from using more than 1 test job? It works fine for me. What exactly is wrong with it? | 15:40 | ||
| yoleaux | Zoffix: I'll pass your message to stmuk. | ||
| Zoffix | c'mon people; explain why your code does things; it's programming 101 | ||
| </annoyed> | |||
| :) | 15:41 | ||
| ZOF6VM: Files=1225, Tests=75218, 182 wallclock secs | |||
| m: say 182/142 | |||
| camelia | 1.281690 | ||
| dogbert17 | Zoffix: it was broken until leont pushed a lot of fixes the other day | 15:42 | |
| Zoffix | w00t it got a lot faster. Used to be 2x slower | ||
| dogbert17: so it's fixed now? | |||
| dogbert17 | yes | ||
| Geth | rakudo/nom: 56193b5916 | (Zoffix Znet)++ | t/harness6 Remove jobs blocker 'cause it fixed now: irclog.perlgeek.de/perl6-dev/2017-...i_15224958 |
15:43 | |
| Zoffix | .tell stmuk never mind. Apparently the orignal problem was fixed already. I removed the plug that made harness die on JOBS>1 | 15:44 | |
| yoleaux | Zoffix: I'll pass your message to stmuk. | ||
| dogbert17 | Zoffix: how much slower is harness6 compared to harness5 now? | 15:45 | |
| Zoffix | See above. 28% | 15:46 | |
| dogbert17 | not too shabby :) | ||
| Zoffix | Yeah | 15:47 | |
| jnthn | New scheduler FTW, perhaps :) | 15:49 | |
| and/or maybe other supply optimizations | |||
| I don't think I yet optimized receiving stdout/stderr from an async process | |||
| As I did with sockets | |||
| So there may be some further percents in that. Hard to guess how much | |||
| ilmari | only one way to find out ;) | 15:50 | |
| Zoffix | Gonna mod &DEPRECATED with `:lang-vers` bool attr, when specified will treat given versions as language versions | 16:11 | |
| Geth | roast: 5fbc8ba3fd | (Jonathan Worthington)++ | S17-supply/syntax.t Tests to cover RT #130716 |
16:13 | |
| Zoffix | . | 16:17 | |
| yoleaux | 16:12Z <Xliff> Zoffix: So in this situation, should I not RT the infiniloop? Maybe add a caveat to the docs? | ||
| timotimo | Zoffix: what's coverable's health these days? | 16:23 | |
| i mean the page you have that collects core setting coverage | |||
| Zoffix | I see the domain's dead for it :) | 16:24 | |
| And it hasn't been updated since IO Grant | 16:25 | ||
| coverable6: help | |||
| coverable6 | Zoffix, Like this: coverable6: f583f22 grep=SETTING:: say ‘hello’; say ‘world’ # See wiki for more examples: github.com/perl6/whateverable/wiki/Coverable | ||
| Zoffix | I guess the bot gives different data | ||
| timotimo | it does | ||
| Zoffix | .in 5h schedule perl6.wtf update and fix the domain | ||
| yoleaux | Zoffix: I'll remind you at 21:25Z | ||
| timotimo | i don't have a specific idea in mind | 16:28 | |
| but i stumbled onto the moarvm c code coverage again | 16:29 | ||
| Zoffix | timotimo: k, domain's back up, but the data is likely from April or something. samcv++ had more coverage somehwere | 16:33 | |
| (my site used to have a link, but the page got overwritten with whatever the coverage reporter makes) | |||
| samcv | moarvm.github.io/coverage/ | 16:34 | |
| timotimo | that's a different kind of coverage :) | ||
| samcv | coverage report for the nqp tests | ||
| oh | |||
| also good morning | |||
| timotimo | the rakudo travis runs already take ages, wouldn't want to add a C-coverage taking extra to it | ||
| just to get extra coverage from spec tests | 16:35 | ||
| Zoffix | huggable: moar coverage :is: moarvm.github.io/coverage/ | ||
| huggable | Zoffix, Added moar coverage as moarvm.github.io/coverage/ | ||
| Zoffix | m: use v6.d.PREVIEW; say $*PERL.version before v6.d | 16:38 | |
| camelia | False | ||
| Zoffix | m: use v6.d.PREVIEW; say $*PERL.version cmp v6.d | ||
| camelia | Same | ||
| Zoffix tries to figure out DEPREFCATED thing | 16:39 | ||
| That sub could really use good docs. I struggle with it every time I reach for it | |||
| m: %*ENV<RAKUDO_NO_DEPRECATIONS> = 0; DEPRECATED "x", v2017.09 | 16:41 | ||
| camelia | Saw 1 occurrence of deprecated code. ================================================================================ Block <unit> (from unknown) seen at: <tmp>, line 1 Deprecated since v2017.09, will be removed sometime in the future Please … |
||
| Zoffix | m: %*ENV<RAKUDO_NO_DEPRECATIONS> = 0; DEPRECATED "x", $*PERL.compiler.version | ||
| camelia | ( no output ) | ||
| Zoffix | if it's "since", then the version itself should be deemed as being it | ||
| Zoffix tries changing that | |||
| hm, roast hanged on t/spec/S17-supply/syntax.t It happened yesterday with some file too, but I thought it might've been my VM | 16:50 | ||
| or maybe I don't got a rakudo commit for that last commit that went to roast | 16:51 | ||
| hm, no, I'm on rakudohead | |||
| timotimo | hm, supply/syntax.t ought to be fixed | 16:52 | |
| Zoffix | jnthn: you around? t/spec/S17-supply/syntax.t now hangs for me. Does it need bleed moar or something? | ||
| Hangs after this test "ok 78 - supply block loop did not run ahead of consumer" | |||
| yeah, so it's the newly added test | 16:53 | ||
| $ cat nqp/tools/build/MOAR_REVISION | 16:54 | ||
| 2017.09.1-49-gb3dd812aa | |||
| seems latest moarvm is in use | |||
| jnthn | Zoffix: needs Rakudo HEAD | ||
| timotimo | hm, i don't think there were actually moar or nqp changes | ||
| i mean, related to this | |||
| jnthn | oh, oops, I've one more local change too | ||
| Geth | rakudo/nom: 80f883bc7b | (Jonathan Worthington)++ | src/core/Supply.pm Do not resume after emit by closed `supply` block |
16:55 | |
| jnthn | Sorry 'bout that :) | ||
| Zoffix | :) | ||
| I' | 16:56 | ||
| timotimo | well, that looks important :) | ||
| jnthn | dinner & | ||
| Zoffix | I'm happy. I get to find out how to use the "stash" thing git has | ||
| seems simple enough | |||
| git stash; git pull --rebase; git stash apply; \o/ | 16:57 | ||
| lizmat | git stash pop even :-) | 16:58 | |
| Zoffix | Ah. Thanks. | ||
| dogbert2 | Zoffix: is this new? 'Testing Roast version 6.d-proposals using test file list from t/spectest.data' | 17:02 | |
| Zoffix | dogbert2: yes | ||
| dogbert2 | cool | 17:03 | |
| Zoffix | dogbert2: we have one t/spectest.data per language version now: github.com/rakudo/rakudo/blob/nom/...sioning.md | ||
| with `master` being the proposed version of what 6.d language will be, once released | 17:04 | ||
| (I know we have 6.d.PREVIEW, but I wanted the roast version to have more of a "this isn't final yet" feel to the name) | |||
| ZOFVM: Files=1275, Tests=152199, 154 wallclock secs (23.88 usr 3.63 sys + 3296.78 cusr 225.92 csys = 3550.21 CPU) | 17:05 | ||
| .ask nine you package some stuff so maybe you know: I want to add a helper test module to Rakudo's test suite. I heard that `make test` must not create any new test files or something, so I'm wondering, would that module need `no precompilation` so that it doesn't create any precompilation files when `make test` is run? | 17:08 | ||
| yoleaux | Zoffix: I'll pass your message to nine. | ||
| AlexDaniel | squashable6: status | 17:09 | |
| squashable6 | AlexDaniel, Next SQUASHathon in 8 days and ≈16 hours (2017-10-07 UTC-12⌁UTC+14) | ||
| Zoffix | buggable: LHF | ||
| buggable: tag LHF | |||
| buggable | Zoffix, There is 1 ticket tagged with LHF; See fail.rakudo.party/t/LHF for details | ||
| Zoffix | m: Bool.enums.^name.say; | 17:10 | |
| camelia | Map | ||
| Zoffix | That's already fixed | ||
| AlexDaniel | … now I just have to figure out what to do with squashable and RT | ||
| there are no webhooks for RT, at least none that I know of | 17:11 | ||
| so, uh… Hm… | |||
| I guess it's easier to just wait for the email notification to come and work with that | 17:14 | ||
| if somebody knows any better please tell me | |||
| lizmat confirms S17-supply/syntax.t hangs on test 79 when run by itself, dies when run as part of spectest jnthn | 17:17 | ||
| Zoffix | All the fixes would need one of core devs to merge, so I'm guessing the bot can be told to mark which which PRs got merged during squashathon and then a human can go through them and close all the RTs | ||
| I doubt there'll be a billion of them | |||
| lizmat: it got fixed for me with the last commit 80f883bc7b | 17:21 | ||
| lizmat | ah, missed that :p-) | ||
| AlexDaniel | Zoffix: well, I can just hang the bot on rakudo/rakudo repo similarly to what was happening the last time | 17:22 | |
| maybe with less noise for some irrelevant events, but still | |||
| and roast too, so that we get stuff for TESTNEEDED tickets | |||
| Geth | roast: b819af6fab | (Zoffix Znet)++ | S12-enums/basic.t Test Bool.enums value type RT#132039: rt.perl.org/Ticket/Display.html?id=132039 Rakudo fix: github.com/rakudo/rakudo/commit/e7a588060907e93 |
17:24 | |
| AlexDaniel | but how many tickets were closed? And how many were opened? The bot wouldn't know | ||
| Zoffix | You could take a snapshot of RT and then measure it later. There are no events, but there is an API | ||
| AlexDaniel | hm. That's a good idea actually | 17:25 | |
| Zoffix | I don't know if this ever/still works: github.com/zoffixznet/perl6-RT-REST-Client | ||
| Geth | rakudo/nom: 9837687d93 | (Elizabeth Mattijsen)++ | 5 files Stage 1 of auto-generated BUILDALL methods - generates all necessary methods, but with _UNDER_CONSTRUCTION postfix - this allows care-free building of the setting - added a Mu.new_UNDER_CONSTRUCTION, which calls autogenerated BUILDALL - this also allows for easy benchmarking of old/new object build methodology - preliminary benchmarks indicate 1.5x faster object creation ... (7 more lines) |
17:26 | |
| Zoffix | But ther's a Perl version here: github.com/zoffixznet/r6/blob/mast...ST/Lazy.pm and this script will generate an SQLite database of open tickets (so you could generate before/after dbs): github.com/zoffixznet/r6/blob/mast...builder.pl | ||
| AlexDaniel | how often does it let you do that? | 17:28 | |
| Zoffix | Don't think there's any hard limit, but that API is frail AF | ||
| really slow and sometimes doesn't work | 17:29 | ||
| AlexDaniel | okay | ||
.oO( again, why are we using RT? I know, I know, it's hard to move on… but still?? ) |
17:30 | ||
| Zoffix | I got used to it. | ||
| lizmat | I didn't | ||
| Zoffix | :D | 17:31 | |
| AlexDaniel clicks on the S button | 17:32 | ||
| well, in a way I did too. So I've spent a bunch of time on figuring out how to make the homepage show what I need (which does not need configuration anywhere else), and then I use hidden mobile version to submit bug reports (because we never got the fucking button back). So yeah, it kinda works. | 17:36 | ||
| Geth | rakudo/nom: bb0ebabc39 | (Elizabeth Mattijsen)++ | src/core/Proc/Async.pm Minimally invasive streamline Proc::Async.new |
17:39 | |
| AlexDaniel | but I die a little bit on the inside when I see somebody asking how to submit a bug report and we tell them to send an email… Being able to send a bug report by email probably does more harm than good (sure, it's a wonderful idea that you don't have to create an account, but pretty much everyone has a github account nowadays… especially given that we require it anyway if you want to contribute to any other part of perl 6) | ||
| I know, AlexDaniel is ranting again, but for how long are we planning to use this crap? :S | 17:40 | ||
| lizmat | AlexDaniel: FWIW, I agree | ||
| and I wonder who, apart from masak and now Zoffix, is a. able to really work with RT, and b. wants to do that | |||
| Zoffix | More precisely, I got used to RT + fail.rakudo.party + hidden mobile form for filing tickets :D | 17:43 | |
| AlexDaniel | during the last squashathon I've been splitting some tickets and creating fresh tickets from old tickets that accumulated some mold. IMO this made a lot of stuff easier to approach | 17:46 | |
| but I'm thinking that, even if don't do any migration or whatever, and just start using another tracker, tickets will eventually move | 17:47 | ||
| or maybe not, maybe I'm wrong | |||
| lizmat | which tracker were you thinking about | ||
| AlexDaniel | lizmat: I think there's a good candidate: github.com/rakudo/rakudo/issues . I agree that it's not perfect, but it's *way* better than what we have now. And given that we use github for everything else, it just makes it easier for everyone | 17:50 | |
| we can of course start bikeshedding it between gitlab, bitbucket, self-hosted gitlab, notabug, and so on and so forth… | 17:51 | ||
| Zoffix | I use gitlab at $work and I kinda hate it | 17:52 | |
| and gitlab.com is slow as hell | |||
| AlexDaniel | but as a user I expect to see a useful bug tracker on github, even if it's not the main one | 17:53 | |
| Zoffix | Come to think of it, my self-hosted gitlab is slow as hell too | ||
| Geth | rakudo/nom: a225e040f1 | (Zoffix Znet)++ | src/core/Deprecations.pm Make &DEPRECATED treat $vfrom inclusively The error message says "since blah blah", so it implies the specified version is included. Also, making the version included in the commit message makes it easier to specify restrictions, especially when testing against the language version. |
17:55 | |
| rakudo/nom: 36bc8e2d95 | (Zoffix Znet)++ | 2 files Implement language version testing in &DEPRECATED If :lang-vers Bool param is given, assume the given $vfrom/$vto versions are language versions as opposed to compiler versions. |
|||
| Zoffix | s/error message/deprecation message/; | 17:56 | |
| lizmat | hmmm... apparently "foo = bar" is *not* the same as "nqp::assign(foo,bar)" | 17:57 | |
| m: my $a; use nqp; nqp::assign($a,42); dd $a | 17:58 | ||
| camelia | Int $a = 42 | ||
| lizmat | m: my @a; use nqp; nqp::assign(@a,42); dd @a | ||
| camelia | Cannot assign to an immutable value in block <unit> at <tmp> line 1 |
||
| AlexDaniel | anyway, I'm going to take a nap now. I really recommend everyone to think about this issue by setting a goal to make things better, instead of the “it works for me let's not change anything” thing we had last time. Things are not OK. | ||
| lizmat | jnthn timotimo ^^^ this is blocking generated BUILDALL atm | 17:59 | |
| Zoffix takes "I don't care stance" on it | |||
| lizmat | suggestions? | ||
| timotimo | for @a you have to call .STORE i believe | ||
| AlexDaniel | buggable: tag RT | 18:00 | |
| buggable | AlexDaniel, There are 2 tickets tagged with RT; See fail.rakudo.party/t/RT for details | ||
| lizmat | hmmm... the BUILDPLAN doesn't know if the attribute is a $ or a @ or a % or a& | ||
| Zoffix | Yeah, younger-Zoffix wrote something there, but I no longer care about that :) | 18:01 | |
| (on the RT stuff) | |||
| greppable6: \.child | 18:02 | ||
| greppable6 | Zoffix, gist.github.com/3a9e07312dd0a37b5b...ae556d0c76 | ||
| Zoffix | Damn, that's a ton of use. I think the whole swapping .child to being a "secure" impl isn't feasible for 6.d. | 18:04 | |
| timotimo | lizmat: which buildplan opcode is this for? | ||
| Zoffix | I'm gonna just deprecate it in 6.d for swapping in 6.e | ||
| lizmat | initialize opaque from init hash *and* I guess setting the default | ||
| AlexDaniel | Zoffix++ # all v6.d progress | ||
| Zoffix | Or maybe it's fine. Since feature-wise it's not that much different, just a lot slower | ||
| I'm getting a ton of roast failures | 18:05 | ||
| lizmat | timotimo: think I found a way | ||
| timotimo | is this code number 4? | ||
| lizmat | 0 and 4 | ||
| Zoffix | gist.github.com/zoffixznet/e6a4209...ff11d296ff | ||
| lizmat | timotimo: I just realized I *do* have the full attribute name | 18:06 | |
| Zoffix | ZOFFLOP: t/spec/S26-documentation/wacky.t | ||
| Zoffix re-runs | |||
| lizmat | so if the first char is '@' or '%', then call .STORE | ||
| timotimo | how exactly do we compile = when we don't know the lhs? | ||
| nqp::p6store? | 18:07 | ||
| lizmat | doesn't look like it | 18:08 | |
| timotimo | i compiled 5 = 42 and it used that | ||
| Zoffix | I'm gonna move .child -> .child (secure) swap to 6.e. Too much current use + IO::Path.add is too new for module authors to be able to safely switch to it | 18:09 | |
| lizmat tries | |||
| timotimo++ # that seems to be the trick | 18:11 | ||
| timotimo | nice! | ||
| Geth | 6.d-prep: 183cfcab4c | (Zoffix Znet)++ | 2 files Postpone .child -> .child (secure) swap to 6.e Postponed until 6.e because there's a huge amount of ecosystem usage and the IO::Path.add that is the alternative is too new for module authors to reliably switch to using it. |
18:13 | |
| Zoffix | still a bunch of failures after re-stresstest: gist.github.com/zoffixznet/8feb84d...cf2ccc2358 | 18:14 | |
| Geth | 6.d-prep: b57b372425 | (Zoffix Znet)++ | 2 files Keep already-implemented features in a separate file |
18:18 | |
| lizmat | Zoffix: if they are S10-packages/precompilation.t / S12-introspection/methods.t integration/advent2009-day11.t | 18:20 | |
| Zoffix: then they are my fault | |||
| Zoffix | heh, okthen :) | 18:21 | |
| lizmat | well, you could consider the tests faulty, as they don't take a generated BUILDALL into account | 18:22 | |
| Zoffix | So is_approx from Test.pm6 is on the chopping block, but how do we go about it. | ||
| timotimo | oh, wait, the generated buildplan got merged? | ||
| oh, no, that's just the signature, right? | |||
| Zoffix | Like, 6.c-errata uses it | 18:23 | |
| lizmat | timotimo: it got merged, but it is still called BUILDALL_UNDER_CONSTRUCTION | ||
| timotimo | even the procasync one? | ||
| Zoffix | Its deprecation period is already expired. | ||
| lizmat | the p6store trick made everything work | ||
| now running a spectest with the generated BUILDALL | |||
| timotimo | hm, it wants Proc::Async.new() to throw X::Multi::NoMatch, but the new method has been turned into an only perhaps? | 18:26 | |
| lizmat | ah, that | ||
| hmmm.. yes, it is an only now | 18:27 | ||
| perhaps that one should be reverted | |||
| although from a performance point of view, we shouldn't | |||
| timotimo | then the test is too specific | ||
| ugexe | m: class Foo { method new (*@ [$path, *@args]) { say $path.perl; say @args.perl; say %_.perl } }; Foo.new(<a b c>, :cwd<abc>) | 18:28 | |
| camelia | "a" ["b", "c"] {:cwd("abc")} |
||
| ugexe | m: class Foo { method new ($path, *@args) { say $path.perl; say @args.perl; say %_.perl } }; Foo.new(<a b c>, :cwd<abc>) | ||
| camelia | $("a", "b", "c") [] {:cwd("abc")} |
||
| ugexe | re: github.com/rakudo/rakudo/commit/bb...ff115ac1fe | 18:29 | |
| timotimo | oh whoops | ||
| Geth | rakudo/nom: 167f0f83c9 | (Elizabeth Mattijsen)++ | src/core/Proc/Async.pm Revert "Minimally invasive streamline Proc::Async.new" This reverts commit bb0ebabc39ec0ffe8db04d6ef1b1dbff115ac1fe. |
18:32 | |
| lizmat | sorry for the noise | ||
| Zoffix | It actually used to be that in the past, but was changed in github.com/rakudo/rakudo/commit/92...a9dba6f13e | 18:33 | |
| ugexe | i hope method call speed is never the bottle neck of spawning processes, but in 10 years i might have to eat those words | 18:41 | |
| lizmat | ugexe: fwiw, the Rakudo overhead of walking a directory and inspecting file attributes, is like 90% if I recall correctly | 18:43 | |
| jnthn | lizmat: See the infix:<=> impl in CORE.setting for what we compile it as | 18:47 | |
| but iirc it's something like nqp::iscont(x) ?? nqp::assign(x, y) !! x.STORE(y) | |||
| In the compiler we case-anlayze the sigil | 18:48 | ||
| *analyze | |||
| lizmat | yeah, that's the approach I took now as well | ||
| jnthn | Don't you have the attribute name to hand though? | ||
| When compiling the build plan? | |||
| lizmat | yes, the name | ||
| I was thinking about the Attribute object | |||
| jnthn | So nqp::substr($name, 0, 1) is the sigil :) | ||
| lizmat | that's *not* in the plan | 18:49 | |
| yup | |||
| done that | |||
| jnthn | iirc that's all that we do in the compiler :) | ||
| yup: github.com/rakudo/rakudo/blob/nom/....nqp#L6926 | 18:50 | ||
| ohh | |||
| There's a p6store op that | |||
| does the runtime check | 18:51 | ||
| That's what we use if we're lacking a sigil | |||
| But an attribute will always have one; there's no sigilless attrs :) | |||
| github.com/rakudo/rakudo/blob/nom/....nqp#L6959 fwiw | |||
| lizmat | so you're saying I should call .STORE directly, rather than calling nqp::p6store | ||
| ? | |||
| jnthn | I'd do the sigil analysis | 18:55 | |
| And call .STORE for @ an %, use assign for $ and &, and then if you for robustness (people constructing objects my hand? other weird) have p6store fallback | |||
| p6store is the worst case for runtime | |||
| spesh can usually rip out the branch | |||
| But it's still nice to not have to :) | 18:56 | ||
| lizmat | ok, gotcha | 19:01 | |
| argh, due to the BUILDALL(@positional...) business, I need to make the generated BUILDALL's multis | 19:07 | ||
| jnthn timotimo: is there something more I should do than just .add_multi_method ? | |||
| jnthn | Ummm...outside of the setting no, inside of it you'd need to install a proto method | 19:09 | |
| Do you really need to make them multis? :) | |||
| Or better: why do you need to? | |||
| Ah, time for walk here before shop closes :) | |||
| bbi20-30 | |||
| lizmat | github.com/rakudo/rakudo/blob/nom/...Mu.pm#L152 # the reason jnthn | 19:10 | |
| Geth | rakudo/nom: 4c337e8ef9 | (Zoffix Znet)++ | 3 files Deprecate dummy arg on .Rat/.FatRat… For Rat, FatRat, and Int types |
19:18 | |
| 6.d-prep: bb6eb35c64 | (Zoffix Znet)++ | 2 files Mark dummy .Rat/.FatRat params as completed Done in github.com/rakudo/rakudo/commit/4c337e8ef9 |
19:21 | ||
| Zoffix | AlexDaniel, I'm assuming all interested parties by now seen all the changes that are listed in perl6/6.d-prep repo. There's a huge amount of bikeshedding about .flatmap on the doc issue #1428. A lot of it seems to be about performance gained by saving one method call, which I don't find relevant, so I quite honestly didn't bother reading all of it. I'm marking .flatmap as deprecated in 6.d for removal in | 19:29 | |
| 6.e and will close RT#130520. If I missed some pertinent detail, feel free to revert and re-open | |||
| .tell AlexDaniel irclog.perlgeek.de/perl6-dev/2017-...i_15226307 | 19:30 | ||
| yoleaux | Zoffix: I'll pass your message to AlexDaniel. | ||
| jnthn | lizmat: oh, in that case the add_multi_method should suffice, in that the proto comes from Mu and will be cloned from it :) | 19:31 | |
| lizmat: So ignore my comment about the setting | |||
| lizmat | I also needed to move self.incorporate_multi_candidates($obj); | 19:32 | |
| but it looks like I need to do that twice atm | |||
| jnthn | Oh? | ||
| We really should only do it once | |||
| lizmat | just moving it after the BUILDALL generation makes the build fail | ||
| jnthn | Maybe it's BUILDALL generation that's gotta move... | 19:33 | |
| lizmat | could be :-) | ||
| jnthn | But yeah, the order in there needs a good bit of care :) | ||
| lizmat | looking at github.com/rakudo/rakudo/blob/nom/...assHOW.nqp , do you think it could move to before self.incorporate_multi_candidates($obj); ? | 19:34 | |
| jnthn | Hmmm | 19:35 | |
| It probably has to be after compose_attributes | |||
| lizmat | ok | 19:36 | |
| jnthn | How did the build fail? | ||
| lizmat | Cannot have a multi candidate for 'WHICH' when an only method is also in the package 'CompUnit::Repository::FileSystem' | 19:38 | |
| Zoffix | m: «"foo "bar"» # more on the missing quotes topic | 19:39 | |
| camelia | 5===SORRY!5=== Error while compiling <tmp> Unable to parse expression in double quotes; couldn't find final '"' at <tmp>:1 ------> 3r"» # more on the missing quotes topic7⏏5<EOL> expecting any of: double quotes … |
||
| Zoffix | oh | ||
| jnthn | Oh...I wonder if that's 'cus attribute composition might generate a multi | ||
| Zoffix | m: «"$*EXECUTABLE -e "print 'test passed'"» | ||
| camelia | 5===SORRY!5=== Error while compiling <tmp> Unable to parse expression in double quotes; couldn't find final '"' at <tmp>:1 ------> 3«"$*EXECUTABLE -e "print 'test passed'"»7⏏5<EOL> expecting any of: double quotes … |
||
| Zoffix | Weird, locally I get "Unable to parse expression in shell-quote words; couldn't find final '»'" | 19:40 | |
| .tell AlexDaniel commitable isn't getting new versions anymore. Last commit from 5 hours ago.... Now that I think of it, I killed some moar process when I was debugging ded bots and it might've been whatever the updater is... | 19:46 | ||
| yoleaux | Zoffix: I'll pass your message to AlexDaniel. | ||
| lizmat | hmmm... somehow the signature doesn't make it to the method :-( | ||
| Geth | roast: 59b4c8556b | (Zoffix Znet)++ | S17-procasync/basic.t Test Proc::Async.new can take cmd+args via single Iterable |
19:48 | |
| lizmat | actually, the whole signature appears to be awol | 19:50 | |
| grrr | |||
| jnthn timotimo: could it be I need to handle the signature differently with multi methods? | 19:56 | ||
| jnthn | How are you attaching the signature at the moment? | ||
| lizmat | if I make the generated BUILDALL method an only method, the signature arrives fine | ||
| $!w.create_code_object($block, 'Method', $sig); | |||
| actually: $!w.create_code_object($block, 'Submethod', $sig) | 19:57 | ||
| jnthn | Oh | ||
| And how are you introspecting the signature? | |||
| If you install it as a multi then .^lookup of .^find_method will give back a proto | 19:58 | ||
| And you'd need to .candiates[0] | |||
| lizmat | class A { has $.a }; dd A.can("BUILDALL_UNDER_CONSTRUCTION")[0].signature' | ||
| invocant_type = A:D | |||
| :(A:D $: ;; %init, *%_) | |||
| "invocant_type = A:D" was debugging info | |||
| jnthn | That looks right? | ||
| Oh, or you mean the ;; is there | 19:59 | ||
| lizmat | indeed, but this is the method case | ||
| if I make it a multi, I get | |||
| jnthn | Ah, right | ||
| lizmat | method BUILDALL_UNDER_CONSTRUCTION (Mu $: | is raw) { #`(Method|140291808297056) ... }) | ||
| jnthn | That looks like the proto | 20:00 | |
| lizmat | the whole list: | ||
| (method BUILDALL_UNDER_CONSTRUCTION (A:D $: ;; %init, *%_) { #`(Method|140291827101656) ... }, method BUILDALL_UNDER_CONSTRUCTION (Mu $: | is raw) { #`(Method|140291808297056) ... }) | |||
| oops, no | 20:01 | ||
| hhmmm | |||
| jnthn | Did you call .candidates like i noted? | ||
| lizmat | do you need that for .can ? | 20:02 | |
| on what should I call .candidates ? | |||
| No such method 'candidates' for invocant of type 'List' | 20:03 | ||
| jnthn | Yes | ||
| .can('...')[0].candidates[0].signature | |||
| lizmat | ack | ||
| $ 6 'class A { has $.a }; dd A.can("BUILDALL_UNDER_CONSTRUCTION")[0].candidates[0].signature' | 20:04 | ||
| :(A:D $: ;; %init, *%_) | |||
| ok, *phew* | |||
| jnthn | :) | ||
| lizmat | ok, gotten a bit further | 20:11 | |
| the Mu.BUILDALL masks the class's BUILDALL | |||
| so it's still getting called | 20:12 | ||
| however, if I remove it, the compiling the setting dies with: Cannot call BUILDALL; no signatures match | |||
| jnthn: I think this is the problem: (A:D $: ;; %init, *%_) versus (Mu:D $: %attrinit, *%_) | 20:23 | ||
| jnthn | Yes | ||
| lizmat | aka, the %init in the generated BUILDALL is after the ;; | ||
| jnthn | Where are you building the sig? | 20:24 | |
| uh, what's the code like? | |||
| I bet it's a missing :multi_invocant(1) or something | |||
| lizmat | ah, lemme see | ||
| jnthn | Seems you're already setting :invocant(1) or so on the first parameter | 20:25 | |
| So that'd need to go on all of 'em | |||
| lizmat | all of them ? | ||
| jnthn: like this? nqp::hash('variable_name','%init','multi_invocant',1) | 20:26 | ||
| jnthn | yes :) | 20:27 | |
| I think that's what it's called | |||
| nope | 20:28 | ||
| is_multi_invocant | |||
| lizmat | justi multi I think ? | ||
| jnthn | git grep <3 | ||
| afk for a bit | |||
| jdv79_ | my conc heavy app still stalls out and eats cpu | 20:30 | |
| travis-ci | Rakudo build failed. Zoffix Znet 'Remove dead test files from 6.d.proposals test file list | 20:31 | |
| travis-ci.org/rakudo/rakudo/builds/280457303 github.com/rakudo/rakudo/compare/e...2950dcc87d | |||
| buggable | [travis build above] ✓ All failures are due to: GitHub connectivity (1 failure). | ||
| jdv79_ | i was hoping the new supply work would fix that | ||
| dogbert2 | # expected: 'bark|name' | 20:36 | |
| # got: 'BUILDALL_UNDER_CONSTRUCTION|bark|name' | |||
| lizmat: | 20:37 | ||
| lizmat | yeah | ||
| that test is faulty | |||
| dogbert2 | ok | ||
| lizmat | it doesn't expect a auto-generated BUILDALL to appear in the class | ||
| (which is for now called BUILDALL_UNDER_CONSTRUCTION) | 20:38 | ||
| [Coke] | is it 'prove6' or 'p6prove' ? | 20:39 | |
| timotimo | jdv79_: aye, it should figure out that it might need more threads and add more, but it's not doing that in your case? | 20:40 | |
| travis-ci | Rakudo build errored. Stefan Seifert 'Remove unnecessary creation of an extra serialization context | 20:42 | |
| travis-ci.org/rakudo/rakudo/builds/280445160 github.com/rakudo/rakudo/compare/9...9fe7dbbd7b | |||
| buggable | [travis build above] ✓ All failures are due to: missing build log (1 failure). | ||
| lizmat | jnthn: current state | 20:44 | |
| class A { has $.a }; say $_.perl for A.can("BUILDALL")[0].candidates | |||
| method BUILDALL (Mu:D $: @positional, %attrinit, *%_) { #`(Method|140428415732240) ... } | |||
| method BUILDALL (Mu:D $: %attrinit, *%_) { #`(Method|140428415732392) ... } | |||
| submethod BUILDALL (A:D $: %init, *%_) { #`(Submethod|140428461458232) ... } | |||
| [Coke] | .seen tadzik | 20:45 | |
| yoleaux | I saw tadzik 19 Sep 2017 13:58Z in #perl6: <tadzik> oh, 18 is some black magic then | ||
| lizmat | If I change the submethod to a method, then building core.d hangs | ||
| [Coke] | .ask tadzik if p6prove is busted with "replace this Array is copy logic" | ||
| yoleaux | [Coke]: I'll pass your message to tadzik. | ||
| lizmat | jnthn: probably because an error occurs in the dispatch, and it all goes into lala land | 20:46 | |
| with these candidates, it calls the Mu.BUILDALL candidate | |||
| [Coke] | (RT) I am ok with a switch to github issues, but I would recommend doing it lazily: new stuff goes there. Link to old tickets as duplications happen or we need history. | 20:47 | |
| (RT) maybe find out if we can leave the queue but prevent new issues from being opened and leave it there for historic RT# lookups. (If not, then given the large # of refs in roast, maybe we can't be lazy and have to actively convert tickets over) | 20:48 | ||
| Zoffix | Was gonna ask, perhaps the new buildall stuff should be moved to a branch until the tests are fixed? It's hard to tell whether the breakage is due to the changes I'm introducing or not | 20:57 | |
| lizmat | well, lemme put it this way: the tests are a bit bogus to begin with, as they assume nothing will ever get auto-generated into a class | 21:01 | |
| so I guess I will fix the tests | |||
| Zoffix | Sure, but if I make a change and see 12 failures, I've no idea if my change is crap or not | 21:02 | |
| m: sub foo {}; unit class Foo; | |||
| camelia | ( no output ) | ||
| lizmat | fixing tests now | 21:03 | |
| Zoffix | I recall talk that `use v6.d.PREVIEW` needs to be the same as `unit` thing and die if it's too late. Should it be even sooner though? Since above the sub would be parsed using 6.c lang for example | ||
| m: say $*PERL.version; use v6.d.PREVIEW; | 21:04 | ||
| camelia | v6.d | ||
| Zoffix | m: BEGIN say $*PERL.version; use v6.d.PREVIEW; | ||
| camelia | v6.c | ||
| Zoffix | ...wonder how much code has `use v6;` not as a first line :/ | 21:05 | |
| greppable6: use\ v6 | |||
| greppable6 | Zoffix, gist.github.com/54116362ad46da23ea...6172b43517 | ||
| Zoffix | .oO( would be cool to get that output in JSON instead... ) |
21:06 | |
| $ perl6 -e '"result.md".IO.lines.grep(/":*" <-[123]> "*:"/).elems.say' | 21:08 | ||
| 108 | |||
| 108 matches for when `use` line is not on 1st, 2nd, 3rd lines (though still might be as the first line of code) | |||
| Hm, I'm actually not totally following how the setting switch happens. From what I can see P6::World.loading_and_symbol_setup loads the setting at the start of P6::Grammar parsing, but then a `use v6.d.PREVIEW` parse does World.load_setting. So what exactly is the point when it's too late to load a new setting? | 21:23 | ||
| And can you load more and more, like: parse some stuff with 6.c, load 6.d, parse more stuff, load 6.e. And can you downgrade after doing that? | |||
| This is about this BTW: github.com/perl6/6.d-prep/blob/mas...s-to-throw | 21:24 | ||
| Zoffix dinners & | |||
| yoleaux | Zoffix: schedule perl6.wtf update and fix the domain | 21:25 | |
| Zoffix | Thanks. | 21:26 | |
| jnthn | lizmat: --ll-exception maybe? | 21:35 | |
| Though probably you tried that | |||
| lizmat | --ll-exception during the setting build ? | 21:36 | |
| jnthn | Yeah but maybe we've got that on already | ||
| Was just thinking of avoiding the exception loop | 21:37 | ||
| But then realized that maybe the loop is in building the exception objects :P | |||
| lizmat | yeah, got that already | ||
| yeah, probably :-) | |||
| thoughts about the candidates ? | |||
| jnthn | The candidates look sensible | ||
| lizmat | do they look good to you | ||
| ok | |||
| now, I wonder if I could eject the Mu.BUILDALL from the list is one is generated | 21:38 | ||
| jnthn | As in, I'd expect the generated one to be typically picked | ||
| lizmat | or: take its place ? | ||
| jnthn | (unless there was an @foo arg too) | 21:39 | |
| No, that's not needed | |||
| All multi-dispatch lists look like this | |||
| That is, contain the parents shadowed by the children too | |||
| lizmat | m: class A { multi method a(Mu:D:) { "Mu" }; multi method a(A:D:) { "A" } }; A.a | ||
| camelia | Cannot resolve caller a(A: ); none of these signatures match: (Mu:D $: *%_) (A:D $: *%_) in block <unit> at <tmp> line 1 |
||
| jnthn | So that's totally normal | ||
| lizmat | m: class A { multi method a(Mu:D:) { "Mu" }; multi method a(A:D:) { "A" } }; A.new.a | 21:40 | |
| camelia | ( no output ) | ||
| lizmat | m: class A { multi method a(Mu:D:) { "Mu" }; multi method a(A:D:) { "A" } }; dd A.new.a | ||
| camelia | "A" | ||
| lizmat | hmmm | ||
| m: class A { multi method a(Mu:D:) { "Mu" }; multi submethod a(A:D:) { "A" } }; dd A.new.a | |||
| camelia | "A" | ||
| lizmat | m: class A { multi method a(Mu:D:) { "Mu" }; multi submethod a(A:D:) { "A" } }; dd A.can("a").candidates[0] | ||
| camelia | No such method 'candidates' for invocant of type 'List' in block <unit> at <tmp> line 1 |
||
| lizmat | m: class A { multi method a(Mu:D:) { "Mu" }; multi submethod a(A:D:) { "A" } }; dd A.can("a")[0].candidates | 21:41 | |
| camelia | (method a (Mu:D $: *%_) { #`(Method|79805352) ... }, submethod a (A:D $: *%_) { #`(Submethod|79805504) ... }) | ||
| Geth | rakudo/nom: 63cf246fd4 | (Elizabeth Mattijsen)++ | 3 files Stage 2 of auto-generated BUILDALL methods - the _UNDER_CONSTRUCTION postfix is removed - they've become multi's - it *should* be possible to remove the Mu.BUILDALL candidate but it breaks the core setting build - and somehow the Mu.BUILDALL shadows all auto-generated BUILDALLs - so no speed improvement yet :-( |
22:02 | |
| lizmat | to bad we can't make BUILDALL an only :-( | ||
| jnthn | Why can't we? | ||
| I thought it used to be | 22:03 | ||
| And taking a throwaway arg should be pretty cheap | |||
| lizmat | so you're saying we should take a slurpy list ? | 22:04 | |
| jnthn | I thought it was a single positional? | 22:05 | |
| Oh.... | |||
| The callers are inconsistent :S | |||
| lizmat | github.com/rakudo/rakudo/blob/nom/...Mu.pm#L141 | ||
| it's needed for Inline::Perl5 somehow :-( | 22:06 | ||
| jnthn | I was sure that once we had it as an only method that always took two args? | ||
| lizmat | well, that was long ago... apparently ? | ||
| I only know of the multi BUILDALL | |||
| Geth | roast: 031b9cecdd | (Elizabeth Mattijsen)++ | S10-packages/precompilation.t Make sure we ignore BUILDALL |
22:07 | |
| jnthn | github.com/rakudo/rakudo/commit/41...babceaca55 :P | 22:08 | |
| Year and a bit ago | |||
| It used to be only | |||
| lizmat | ok, I guess I did that | 22:09 | |
| 1.8x faster :-) | |||
| jnthn | Could undo it ;) | ||
| Surely mostly from the .bless change though | |||
| Could just pass Empty or some other constant empty list to BUILDALL | |||
| Rather than slurping | 22:10 | ||
| I bet the cost was over 90% for the slurply in bless, not for the extra arg to BUILDALL | |||
| lizmat | still, it feels like a waste | 22:11 | |
| :-( | |||
| will look at that tomorrow | |||
| jnthn | Are you grabbing it into a local? | ||
| If so, spesh will toss out the parameter receiving code anyway | |||
| lizmat | what? the hash > | ||
| ? | |||
| jnthn | Yeah | ||
| Oh, that was confused | |||
| Geth | roast/6.c-errata: 35b4b43b22 | (Elizabeth Mattijsen)++ | S10-packages/precompilation.t Make sure we ignore BUILDALL |
22:12 | |
| jnthn | Better put: if you grab it into a local, not a lexical, then don't use it, then spesh will toss out the parameter receiving code anyway :) | ||
| lizmat | QAST::Var.new(:decl<param>, :scope<local>, :name('%init')) | ||
| so already a local | |||
| ok, will do this tomorrow | 22:13 | ||
| getting some sleep first :-) | 22:14 | ||
| good night, #perl6-dev! | |||
| jnthn | 'night, lizmat++ | ||
| Zoffix | timotimo: trying running coverage report but all tests bail out. Tried a few tests on their own and they work. I suspect cover script is broken. Won't try to fix it right now, unless someone really needs an updated coverage report than on what's cover.rakudo.party | 22:19 | |
| timotimo | oof | ||
| OK, thanks, i'll look at what's wrong locally | |||
| Zoffix | I mean my coverage-generating script | 22:20 | |
| Which is this: gist.github.com/zoffixznet/eff5c8f...ab8a94d7e2 | |||
| jnthn | sleep time o/ | ||
| Zoffix | \o | 22:21 | |
| AlexDaniel | did committable just segfault? :-/ | 22:24 | |
| yoleaux | 19:30Z <Zoffix> AlexDaniel: irclog.perlgeek.de/perl6-dev/2017-...i_15226307 | ||
| 19:46Z <Zoffix> AlexDaniel: commitable isn't getting new versions anymore. Last commit from 5 hours ago.... Now that I think of it, I killed some moar process when I was debugging ded bots and it might've been whatever the updater is... | |||
| timotimo | i'll go to sleep soon enough, too | ||
| AlexDaniel | Zoffix: ah ok, thanks | ||
| c: HEAD say 42 | 22:25 | ||
| committable6 | AlexDaniel, ¦HEAD(36122f1): «42» | ||
| AlexDaniel | Zoffix: it was a build lock left behind. It may have been a build process that you killed, I've seen that happen before. But I'm always wondering why this does not fire in these cases: github.com/perl6/whateverable/blob...ild.p6#L61 | 22:29 | |
| greppable6: flatmap | 22:30 | ||
| greppable6 | AlexDaniel, gist.github.com/0b6a13973d31ee817c...994a4a4765 | ||
| AlexDaniel | Zoffix: so the libssl issue was exactly this: github.com/perl6/6.d-prep/blob/mas...id-library ? | 22:34 | |
| the version was precompiled and then I updated the library? | 22:35 | ||
| am I reading it right? | |||
| Zoffix | no idea. jnthn++ told me he fixed something in SSL sock and I updated the module and it worked | 22:36 | |
| AlexDaniel | ah, okay | ||
| Zoffix | a ton of those flatmap usages look to be just people flattening everything several times for no reason just because they don't know what flattens and when | 22:37 | |
| timotimo | ctrl-f "timo", phew. | 22:38 | |
| AlexDaniel | timotimo: haha | ||
| Zoffix: when I realized that flatmap used to do something different in pre-glr I lost any motivation to justify its usage in existing modules | 22:40 | ||
| c: pre-glr say ((1, 2), <a b>).map(&uc).join('|'); | 22:41 | ||
| committable6 | AlexDaniel, ¦pre-glr: «1 2|A B» | ||
| AlexDaniel | c: pre-glr say ((1, 2), <a b>).flatmap(&uc).join('|'); | ||
| committable6 | AlexDaniel, ¦pre-glr: «1|2|A|B» | ||
| AlexDaniel | c: HEAD say ((1, 2), <a b>).map(&uc).join('|'); | ||
| committable6 | AlexDaniel, ¦HEAD(36122f1): «1 2|A B» | ||
| AlexDaniel | c: HEAD say ((1, 2), <a b>).flatmap(&uc).join('|'); | ||
| committable6 | AlexDaniel, ¦HEAD(36122f1): «1 2|A B» | ||
| timotimo | c: HEAD say ((1, 2), <a b>).flatmap({ $_, $_ }).join("|") | 22:42 | |
| committable6 | timotimo, ¦HEAD(36122f1): «1|2|1|2|a|b|a|b» | ||
| timotimo | c: HEAD say ((1, 2), <a b>).map({ $_, $_ }).join("|") | ||
| committable6 | timotimo, ¦HEAD(36122f1): «1 2 1 2|a b a b» | ||
| timotimo | c: HEAD say ((1, 2), <a b>).map({ $_, $_ }).flat.join("|") | ||
| committable6 | timotimo, ¦HEAD(36122f1): «1|2|1|2|a|b|a|b» | ||
| timotimo not sure what he wanted to do there | 22:43 | ||
| AlexDaniel | c: pre-glr say ((1, 2), <foo bar>).flatmap(&tc).join('|'); | ||
| committable6 | AlexDaniel, ¦pre-glr: «1|2|Foo|Bar» | ||
| AlexDaniel | c: HEAD say ((1, 2), <foo bar>).flatmap(&tc).join('|'); | ||
| committable6 | AlexDaniel, ¦HEAD(36122f1): «1 2|Foo bar» | ||
| AlexDaniel | hmmm how do I get this behavior on HEAD… | ||
| c: HEAD say ((1, 2), <foo bar>).deepmap(&tc).join('|'); | 22:44 | ||
| committable6 | AlexDaniel, ¦HEAD(36122f1): «1 2|Foo Bar» | ||
| Zoffix | .flat.map | ||
| AlexDaniel | or that, yeah | ||
| AlexDaniel is reading 6.d-prep docs | 22:47 | ||
| Zoffix: fwiw, have you seen TimToady's answer for the naming question on one of the recent conferences? It was like “things can have multiple names at the same time and it's ok” | 22:48 | ||
| Zoffix: maybe that can be used as an answer to this part: “Executive decision on whether the name extension can be officially made” | |||
| timotimo | but aliasing prevents a lot of optimizations! | ||
| Zoffix | AlexDaniel: no, didn't see any answers. | 22:49 | |
| AlexDaniel | fwiw, looking at Go/golang I find “6lang” as a very achievable alternative branding. And if we feel extra fancy, we can pronounce it as “slang” | 22:51 | |
| but I didn't really think this through, so feel free to call this idea moronic | 22:52 | ||
| Zoffix | I like 6lang | 22:53 | |
| And even those that don't know an alternate name for "Perl 6" can fill in the dots and figure out what it is | 22:54 | ||
| AlexDaniel | Zoffix++ for making me recognize the need for alternative name. For a long time I was against | ||
| and honestly, I can start using something like 6lang right away. “Rakudo Perl 6” is infringing on language/compiler distinction so I'm feeling reluctant | 22:58 | ||
| Zoffix | OK, I'll too start using 6lang | 23:01 | |
| Zoffix is now a proud owner of 6lang.party :D | 23:03 | ||
| timotimo | wow | 23:04 | |
| AlexDaniel | that was quick | ||
| this was the actual answer: youtu.be/E5t8qaAGw9w?t=4886 | 23:10 | ||
| Zoffix | hehe :) Nice | 23:13 | |
| AlexDaniel | c: HEAD say 42 | ||
| committable6 | AlexDaniel, ¦HEAD(63cf246): «42» | ||
| AlexDaniel | m: say 42 | 23:14 | |
| camelia | 42 | ||
| Zoffix | TIL Perl is in oxford dict: en.oxforddictionaries.com/definition/perl | ||
| AlexDaniel | uhh | 23:19 | |
| u: U+FD3E | |||
| unicodable6 | AlexDaniel, U+FD3E ORNATE LEFT PARENTHESIS [Pe] (﴾) | ||
| AlexDaniel | greppable: ﴾ | ||
| greppable6 | AlexDaniel, Found nothing! | ||
| AlexDaniel | quotable6: ﴾ | 23:21 | |
| quotable6 | AlexDaniel, gist.github.com/92cb23faf4207e312a...b10fa614fe | ||
| AlexDaniel | quotable6: ‘﴾’ | ||
| quotable6 | AlexDaniel, gist.github.com/b2949b262f5278820d...c437e94b00 | 23:22 | |
| AlexDaniel | .tell samcv IMO the issue with ornate parens is clearly a mistake that arguably could've been fixed within v6.c, so I think you should feel free to go ahead and drop them in v6.d. | 23:26 | |
| yoleaux | AlexDaniel: I'll pass your message to samcv. | ||
| samcv | yes i plan to drop in 6.d. the problem is there were roast tests for it | 23:27 | |
| yoleaux | 23:26Z <AlexDaniel> samcv: IMO the issue with ornate parens is clearly a mistake that arguably could've been fixed within v6.c, so I think you should feel free to go ahead and drop them in v6.d. | ||
| samcv | i fixed a few parens being the wrong order, so it wanted the end paren at the start and the start at the end. but the ornate need to be removed | ||
| AlexDaniel | right, so we still have to treat them the old way within “use v6.c”… :S | 23:28 | |
| samcv | well if people think i should just remove them I will | ||
| as long as other devs are okay with it | |||
| AlexDaniel | I'm OK with it. If there's one person who was using these parens in real code I can send them an apology letter :) | 23:30 | |
| Zoffix | :D | ||
| samcv | greppable6, ﴾ | ||
| greppable6 | samcv, Found nothing! | ||
| samcv | greppable6, « | ||
| greppable works for random symbols yes or no? | |||
| AlexDaniel | greppable6, « | ||
| greppable6 | AlexDaniel, gist.github.com/eb41060509502bf3b5...e6c8a0d61c | 23:31 | |
| AlexDaniel | that was a SEGV too, I think | ||
| I'll try to reproduce it here | |||
| samcv | greppable6, ﴾ | 23:32 | |
| greppable6 | samcv, Found nothing! | ||
| AlexDaniel | gcan't reprduce | 23:33 | |
| samcv: yes, unless it blows up due to random segfault or whatever | 23:34 | ||
| samcv | ok. so Zoffix is ok with me changing 6.c-errata then? | ||
| also 6lang i kind of like as a name. the only question becomes how branding would go | |||
| Geth | rakudo/nom: 6d2adb20f2 | (Zoffix Znet)++ | 3 files [6.d] Deprecate IO::Path.chdir |
23:35 | |
| samcv | a brand doesn't work if it has no recognition | ||
| Zoffix | We build it | 23:36 | |
| AlexDaniel adds “6lang” tag to whateverable repo | |||
| Zoffix | samcv: I wasn't following… if the test is wrong or tests incorrectly implemented behaviour, then sure, we can change 6.c-errata | 23:37 | |
| samcv | well it'd be removing ornate parenthesis. i mean it really depends how you define it. but it is wrong. and nobody is using it which i think i guess is a big thing | ||
| it's only real thing for keeping it, is that it's in 6.c-errata | |||
| timotimo | the perl6 peeps must be crazy thinking they can build reputation for a whole new name out of thin air :) | 23:38 | |
| samcv | but unicode properties do not consider them a bracket | ||
| Geth | 6.d-prep: 71d057c49c | (Zoffix Znet)++ | 2 files Mark IO::Path.chdir deprecation as completed Done in github.com/rakudo/rakudo/commit/6d2adb20f2 |
||
| AlexDaniel | timotimo: you mean 6lang peeps? | 23:41 | |
| timotimo | :) | ||
| Zoffix | \o/ | ||
| MasterDuke | timotimo: btw, figure out that MVM_string_equal (or was it something to do with ?CLASS) business? | 23:42 | |
| samcv: could you look at jnthn | |||
| 's last comment on github.com/MoarVM/MoarVM/pull/705 ? | |||
| samcv | about nfg stable? | 23:43 | |
| MasterDuke | that's why i was asking about combiners, but everything i tried seemed to work | ||
| yeah | |||
| timotimo | haven't figured it out | ||
| AlexDaniel | greppable6: slurp-rest | ||
| greppable6 | AlexDaniel, gist.github.com/c72b21a180067cff69...7d3a54b46e | ||
| AlexDaniel | Zoffix: is correct that I can just s/slurp-rest/slurp/ in all of my code? | 23:44 | |
| timotimo | m: say $*IN.slurp | ||
| camelia | »Wann treffen wir drei wieder zusamm?« »Um die siebente Stund‘, am Brückendamm.« »Am Mittelpfeiler.« »Ich lösche die Flamm.« »Ich mit« »Ich komme vom Norden her.« »Und ich vom Süden.«… |
||
| timotimo | m: say $*IN.slurp-rest | ||
| camelia | »Wann treffen wir drei wieder zusamm?« »Um die siebente Stund‘, am Brückendamm.« »Am Mittelpfeiler.« »Ich lösche die Flamm.« »Ich mit« »Ich komme vom Norden her.« »Und ich vom Süden.«… |
||
| Zoffix | AlexDaniel: yes | 23:45 | |
| AlexDaniel | greppable6: lines.*count | 23:46 | |
| greppable6 | AlexDaniel, gist.github.com/212c6c503e09866c51...ac64eb1d93 | ||
| AlexDaniel | m: say lines(:1count); say lines(:1count) | 23:47 | |
| camelia | (»Wann treffen wir drei wieder zusamm?« »Um die siebente Stund‘, am Brückendamm.« »Am Mittelpfeiler.« »Ich lösche die Flamm.« »Ich mit« »Ich komme vom Norden her.« »Und ich vom Süden.« »Und… | ||
| AlexDaniel | m: say lines(:1count); | ||
| camelia | (»Wann treffen wir drei wieder zusamm?« »Um die siebente Stund‘, am Brückendamm.« »Am Mittelpfeiler.« »Ich lösche die Flamm.« »Ich mit« »Ich komme vom Norden her.« »Und ich vom Süden.« »Und… | ||
| samcv | MasterDuke, i don't get what you're doing here | 23:48 | |
| the all_strands_of_same_type variable only seems to hold whether the separator is a strand | 23:49 | ||
| is it just named badly? | |||
| AlexDaniel | $count ?? self.lines.elems !! self.lines; | ||
| wtf :D | |||
| MasterDuke | it also checks the pieces later in the code | ||
| samcv | ok well what cases are being optimized here | 23:50 | |
| compared to the other cases | |||
| where you're joining strands instead of flat strings? | |||
| MasterDuke | just the case of all the strings (separator + list of other strings) are strands | ||
| samcv | so you only are copying strands or something? | 23:51 | |
| MasterDuke | in that case, yeah | ||
| AlexDaniel | “De-magicalize '-' in IO::Handle.open” yes, yes | 23:52 | |
| samcv | also | ||
| 16 <= total_graphs / total_strands | |||
| MasterDuke | yeah? | 23:53 | |
| samcv | yeah so what are you controlling for here. that's total_strands of all pieces combined? | 23:54 | |
| and total_graphs of all pieces? | |||
| MasterDuke | yep | ||
| a heuristic to avoid the overhead of messing around with strands instead of a flat string unless it would be helpful | 23:55 | ||
| AlexDaniel | Zoffix: my opinion may not matter much, but I've read through v6.d-prep docs and everything makes a lot of sense | 23:56 | |
| samcv | so yeah you need to control for combininers | ||
| just because you haven't triggered it. i guarentee you it's there ;) | |||
| though if you want to trigger it easier you can turn on NFG_CHECK i think it's called | |||
| MasterDuke | how do i trigger it? | 23:57 | |
| samcv | i *think* i have one of those at the end of join. though you should check | ||
| well i'd look at things which change under normalization. and also add a fprintf t o make sure you know if it's actually triggering this section of the code | |||
| MasterDuke | the `STRAND_CHECK(tc, result);`? | ||
| samcv | nope | ||
| AlexDaniel | greppable6: write-internal | ||
| greppable6 | AlexDaniel, Found nothing! | ||
| AlexDaniel | greppable6: read-internal | ||
| greppable6 | AlexDaniel, Found nothing! | ||
| MasterDuke | samcv: so there aren't any tests in roast for that condition? | 23:58 | |
| samcv | in that case you should add NFG_CHECK(tc, result, "MVM_string_join") | ||
| for join? probably not | |||
| there are for concat | |||
| i would try altering those to also do it for join | |||
| give me a sec i'll find where they're generated | |||
| MasterDuke | thanks | 23:59 | |
| samcv | also go to src/strings/ops.h | ||
| and define MVM_DEBUG_NFG and MVM_DEBUG_NFG_STRICT |