|
01:47
ilbot3 joined
08:40
cognominal joined
09:17
RabidGravy joined
09:34
Ven joined
09:37
Ven joined
|
|||
| dalek | kudo/nom: 440da02 | lizmat++ | src/core/allomorphs.pm: Allomorphs don't need a .gist of their own As they inherit the Str.gist |
09:51 | |
| kudo/nom: ae2afdc | lizmat++ | src/core/allomorphs.pm: Make allomorph.perl show any subclass info |
10:03 | ||
| kudo/nom: 9206848 | lizmat++ | src/core/allomorphs.pm: Fix infix:<cmp> for allomorphs - because of missing :D, one of the base variants was chosen before - simplify condition, no need for given if you use || |
10:32 | ||
|
10:44
travis-ci joined
|
|||
| travis-ci | Rakudo build failed. Elizabeth Mattijsen 'Allomorphs don't need a .gist of their own | 10:44 | |
| travis-ci.org/rakudo/rakudo/builds/130194084 github.com/rakudo/rakudo/compare/3...0da02594ca | |||
|
10:44
travis-ci left
|
|||
| RabidGravy | is it me or are the jvm builds that are failing duplicates of the ones that are already in the "allowed failures"? | 10:47 | |
| or should they be added to the "allowed failures" at least | 10:48 | ||
| lizmat | afaics, something broke "make install" | 10:49 | |
| RabidGravy | for jvm only though right? | 10:51 | |
| psch | well, the r-j build worked, then i removed the r-j build from allowed failures | 10:55 | |
| and then everything broke again and everyone is waiting for me to fix it... :) | |||
| lizmat | ++psch :-) | 10:56 | |
| dalek | kudo/nom: 2ddac6a | lizmat++ | src/core/allomorphs.pm: Use nqp::eqat to check for occurence in string We have a dedicated nqp::op for checking whether a given string occurs at a position in another string. So no need to substr! |
10:58 | |
| lizmat | which concludes my submissions for the coming days | 10:59 | |
| commute to OSCON& | |||
|
11:04
Ven joined
11:21
travis-ci joined
|
|||
| travis-ci | Rakudo build failed. Elizabeth Mattijsen 'Make allomorph.perl show any subclass info' | 11:21 | |
| travis-ci.org/rakudo/rakudo/builds/130195268 github.com/rakudo/rakudo/compare/4...2afdcd746e | |||
|
11:21
travis-ci left
|
|||
| timotimo | huh, how did that happen | 11:22 | |
| seems like at some point it just went belly-up? | 11:23 | ||
| psch | 1e5df4130e6 is the commit that worked on r-j, which is my it exists | 11:24 | |
| 'cause it's the one that removes *nix r-j from allowed_failures | |||
| bartolin | psch: I was curious and applied your changes from gist.github.com/peschwa/e82fac05cb...6687a15aa1 | 11:30 | |
| could the error during installation (class 'NativeCall::Types::void' not found) be related to precomp again? | |||
| psch | bartolin: probably, yeah | 11:31 | |
| bartolin | running with RAKUDO_MODULE_DEBUG=1 I saw some lines about failed precompilations. | ||
| psch | i mean, the error is that it doesn't recognize the type, which i take to mean that the import doesn't work | ||
| which could happen when it did precompile in a broken way and thus can't load it then i guess..? | 11:32 | ||
| bartolin | yeah, that's what I thought as well | ||
| wasn't there a way to disable precompilation? | |||
| psch | we have a 'no precompilation' pramga i think? | ||
| bartolin | 'no precompilation' seems to have no effect. | 11:33 | |
| psch | where'd you put it? | ||
| bartolin | I tried to put it in lib/NativeCall/Types.pm6 and lib/NativeCall/Compiler/GNU.pm6 | ||
| psch | i'd try it in install-core-dist.pl | ||
| bartolin | m: use NativeCall::Types; say (NativeCall::Types::void).^name | 11:36 | |
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«Could not find symbol '&void'⤠in block <unit> at /tmp/BiE9xcmmcm line 1ā¤ā¤Actually thrown at:⤠in block <unit> at /tmp/BiE9xcmmcm line 1ā¤ā¤Ā» | ||
| bartolin | hmm. | ||
| psch | m: use NativeCall::Types; say NativeCall::Types::.keys | 11:37 | |
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«Could not find symbol '&Types'⤠in block <unit> at /tmp/nV3znYAc38 line 1ā¤ā¤Actually thrown at:⤠in block <unit> at /tmp/nV3znYAc38 line 1ā¤ā¤Ā» | ||
| psch | m: use NativeCall; say NativeCall::.keys | ||
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«()ā¤Ā» | ||
| psch | m: use Test; ok 1, 1 | ||
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«ok 1 - 1ā¤Ā» | ||
| bartolin | that works locally with r-m | 11:38 | |
| anyway, I'll look again and play with 'no precompilation' and some debug statements ... | 11:39 | ||
|
12:02
travis-ci joined
|
|||
| travis-ci | Rakudo build failed. Elizabeth Mattijsen 'Fix infix:<cmp> for allomorphs | 12:02 | |
| travis-ci.org/rakudo/rakudo/builds/130198431 github.com/rakudo/rakudo/compare/a...068485c8c3 | |||
|
12:02
travis-ci left
|
|||
| psch | bartolin: fwiw, 'module Foo { our class Bar { } }' also doesn't find Foo::Bar | 12:21 | |
| bartolin: i'm fairly sure it should... :S | |||
| m: module Foo { our class Bar { } }; say Foo::Bar | 12:24 | ||
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«(Bar)ā¤Ā» | ||
| psch | yeah, that works in-line (so to speak) on r-j too | 12:25 | |
| but stuff the Foo definition into a file, and it doesn't... vOv | 12:26 | ||
|
12:36
travis-ci joined
|
|||
| travis-ci | Rakudo build failed. Elizabeth Mattijsen 'Use nqp::eqat to check for occurence in string | 12:36 | |
| travis-ci.org/rakudo/rakudo/builds/130201108 github.com/rakudo/rakudo/compare/9...dac6a8faef | |||
|
12:36
travis-ci left
|
|||
| timotimo | oh come on, travis :| | 12:36 | |
| psch | ...why doesn't 'no precompilation' turn off precompilation? | 12:43 | |
| for that matter, i also thought 'use lib ...' would turn it off, but that doesn't either... | |||
| timotimo | use lib will not deactivate precompilation | 12:45 | |
| instead you.ll end up with a precomp store in that lib directory | |||
| moritz | there's "no precomp;" if you want to turn off precomp | ||
| timotimo | m: no precompilation | ||
| camelia | ( no output ) | ||
| timotimo | i wonder why that doesn't error out when it sees a thing we don't have? | 12:46 | |
| psch | m: no funny-business | 12:47 | |
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«===SORRY!===ā¤Don't know how to 'no funny-business' just yetā¤Ā» | ||
| timotimo | oh | ||
| m: no precomp | |||
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«===SORRY!===ā¤Don't know how to 'no precomp' just yetā¤Ā» | ||
| timotimo | so it *is* "no precompilation" | ||
| psch | m: no precomp | ||
| camelia | rakudo-moar 2ddac6: OUTPUTĀ«===SORRY!===ā¤Don't know how to 'no precomp' just yetā¤Ā» | ||
| psch | oh, yeah | ||
| but it doesn't do anything. or rather, i still get logging output from RAKUDO_MODULE_DEBUG that says precomp is happening | 12:48 | ||
| i mean, it might be doing something, but it's not turning of precomp vOv | |||
| timotimo | it only prevents the module it's in from being precompiled | ||
| psch | ah, yeah | 12:50 | |
| so, apparently precomp of modules with our-scoped classes ia broken on r-j | |||
| timotimo | oh crap | 12:51 | |
| bartolin | hmm. if I have Bar.pm6 which has 'no precompilation' and then run "perl6-m -e 'use Bar'" it looks like Bar _gets_ precompiled | 12:52 | |
| psch | bartolin: it aborts | ||
| bartolin: when it sees the pragma | 12:53 | ||
| bartolin | (according to output with RAKUDO_MODULE_DEBUG=1) | ||
| timotimo | it can hardly know not to precompile before it started trying | ||
| psch | 4420 32384 RMD: /home/psch/rakudo/rakudo/Foo.pm aborted precompilation without failure | ||
| timotimo | because it's not allowed to precompile the "don't precompile me" thingie | ||
| bartolin | ahh, I see | 12:54 | |
| psch | hm | 12:59 | |
| maybe even worse: both "module Foo { }" and "unit module Foo;" seem broken | |||
| bartolin | ok, doing the following seems to work: 1. apply psch's++ patches; 2. add 'no precompilation' to 'lib/NativeCall/Types.pm6'; 3. run perl6-j -Ilib -e 'use NativeCall::Types; say NativeCall::Types::void.^name' | 13:00 | |
| oh, and remove an existing dir lib/.precomp before step 3 | |||
| so, maybe your patches are good at least | 13:02 | ||
| psch | yeah, probably | 13:04 | |
| but precomp loading is completely busted on r-j it seems | |||
| Foo.pm with "class Foo { }" can't be loaded without having "no precompilation" in there | 13:05 | ||
| bartolin | yes, looks like it :-/ | ||
| psch | or well, it gets loaded, and says it imports symbols, but Foo isn't found in the using mainline | ||
| which, honestly, even makes me doubt i'm doing the syntax right haha :) | |||
| bartolin | psch: yesterday you were reluctant to put your changes to the Binder in a commit. since the new error ('NativeCall::Types::void') seems to be unrelated to that -- shouldn't your patches go in? | 13:13 | |
| dalek | kudo/nom: f6bc8b7 | peschwa++ | src/ (4 files): Fix some cases of extra containers in param binding. This fixes e.g. < my $b = Buf.new; $b.push(Buf.new(1,2)) >, but doesn't fix RT #126493 for example. This might mean there's a better, more complete version around, but this is still better than nothing. |
||
| synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=126493 | ||
| psch | bartolin: well... :) | ||
| bartolin | lol | ||
| psch++ | 13:14 | ||
| psch | bartolin: fwiw, the reluctance was because i had thought that my interpretation of "don't mess up explicit $_ binding" for the r-j Binder was wrong | ||
| bartolin: since the failing bit was a given/when | |||
| bartolin | aha, I see | ||
| psch | hmm | 13:19 | |
| CompUnit::Loader.load-precompilation-file just does nothing on r-j..? | |||
| i mean, the call to loadbytecodefh is moar-only | |||
| bartolin | psch: but in CompUnit::PrecompilationRepository is an '#?if moar' statement, so load-precompilation-file not called there on JVM | 13:25 | |
| psch | ah, alright then :) | 13:26 | |
|
14:02
Ven joined
14:11
travis-ci joined
|
|||
| travis-ci | Rakudo build failed. Pepe Schwarz 'Fix some cases of extra containers in param binding. | 14:11 | |
| travis-ci.org/rakudo/rakudo/builds/130215385 github.com/rakudo/rakudo/compare/2...bc8b7dec65 | |||
|
14:11
travis-ci left
|
|||
| psch | yes travis, soon. maybe... | 14:12 | |
| [Tux] | This is Rakudo version 2016.04-199-gf6bc8b7 built on MoarVM version 2016.04-134-g9879233 | 14:27 | |
| test 20.853 | |||
| test-t 13.463 | |||
| csv-parser 35.589 | |||
|
14:34
Ven joined
|
|||
| nine | psch: odd. I specifically tried to make sure loading precompiled files works on the JVM before merging my branch :/ | 15:11 | |
| psch | nine: the precomp files are jars, aren't they? | 15:18 | |
| 'cause calling loadNew skips all the "pull the jar appart and check its serialization" stuff | 15:19 | ||
| also apparently a Buf is a VMArrayInstance_u8, not _i8 | |||
| also loadbytecodebuffer didn't have a fail branch for that instanceof check | 15:20 | ||
| well, that's the changes i'm trying right now, fwiw :) | |||
| nine | I was actually surprised when it seemed to work :) | 15:25 | |
| psch | m: say 4260626932.base(16) | 15:43 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«FDF401F4ā¤Ā» | ||
| psch | m: say (0xffffffff - 4260626932).base(16) | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«20BFE0Bā¤Ā» | ||
| psch | hm, that doesn't immediately help me vOv | ||
| that's the first 4 bytes of a precomp file, fwiw | 15:44 | ||
| well, after the bitshifting and bitanding at the start of loadBuffer, which is what's after the readAllBytes call in loadFile... | 15:45 | ||
| huh | 15:48 | ||
| 0x504B0304 is what we expect at the start of a .jar file | |||
| $ xxd install/share/perl6/precomp/A7D2CC4F2100F2EFB26241A5A219EDE670349041.1.463240427251E9/09/09A0291155A88760B69483D7F27D1FBD8A131A35 | head | |||
| 0000000: 0a50 4b03 0414 0008 0808 0045 7dae 4800 .PK........E}.H. | |||
| but we get 0x0a504b0304 | |||
| oh, wasn't there some "mush it together with our own delimiters" magic going on..? | 15:49 | ||
| nine | psch: precomp files are now a combination of dependency information + the bytecode file | 15:50 | |
| the first part is actually human readable | 15:51 | ||
| The bytecode part starts after the first empty line | |||
| psch | yeah, that's what i just realized | ||
| i mean, the fact that we start with a line break and then comes the jar | 15:52 | ||
| nine | That would be a file with no dependencies | ||
| psch | yeah, which is a problem if we don't have anything implemented that tosses everything that's before the line break before feeding it into the ClassLoader... :) | 15:53 | |
| nine | But that should be taken care of by using loadbytecodebuffer instead of loadbytecodefile? | ||
| or loadbytecode rather | |||
| psch | well, yeah, if it was implemented in loadbytecodebuffer it probably would :D | 15:54 | |
| but currently it just feeds the whole file, including empty line (or dependency information) into the class loader | |||
| or, well, upstream it actually realizes its a VMArrayInstance_i8 and not _u8 and just does nothing | 15:55 | ||
| well, unless i missed an nqp bump here of course | |||
| s/file/buffer/ | |||
| github.com/perl6/nqp/blob/master/s...java#L5642 gets called | 15:56 | ||
| from github.com/rakudo/rakudo/blob/nom/...der.pm#L58 | 15:57 | ||
| if the caller of load-precompilation doesn't break the $buf apart... | |||
| nine | This is the place: github.com/rakudo/rakudo/blob/nom/...ile.pm#L41 | 15:59 | |
| psch | m: say $*IN.get.split[*-1] | 16:00 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«Cannot call split(Str: ); none of these signatures match:⤠(Cool $: Regex:D $pat, $limit = Inf;; :$all, *%_)⤠(Cool $: Cool:D $pat, $limit = Inf;; :$all, *%_)⤠(Str:D $: Regex:D $pat, $parts = *;; :$v is copy, :$k, :$kv, :$p, :$skip-empty, *ā¦Ā» | ||
| psch | m: say $*IN.get.split()[*-1] | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«Cannot call split(Str: ); none of these signatures match:⤠(Cool $: Regex:D $pat, $limit = Inf;; :$all, *%_)⤠(Cool $: Cool:D $pat, $limit = Inf;; :$all, *%_)⤠(Str:D $: Regex:D $pat, $parts = *;; :$v is copy, :$k, :$kv, :$p, :$skip-empty, *ā¦Ā» | ||
| psch | oh grr | ||
| m: say $*IN.get.comb[*-1] | |||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«lā¤Ā» | ||
| psch | humm, does that chomp..? :) | ||
| nine | Yes, all line reading methods should chomp | 16:01 | |
| psch | i am so confused right now | 16:11 | |
| i mean, what i do know is that the buf that arrives in loadbytecodebuffer still has the line break | |||
| and testing around with the pattern (i.e. < $h.get; ... ; $h.slurp-rest(:bin) >) i don't get any data from the slurp-rest | 16:12 | ||
| gist.github.com/peschwa/7423e9802b...8dd77f84d1 like this | 16:13 | ||
| nine | Maybe this combination of Str get and slurp-rest(:bin) doesn't work as well on the JVM | ||
| psch | *also* scary is the new part in the updated gist | 16:14 | |
| nine | Shouldn't it be $h.slurp-rest(:bin)? | ||
| Or $h.slurp-rest: :bin | |||
| psch | doesn't change anything | ||
| m: class A { methdo foo($) { } }; A.foo 1 | |||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/3JBUIlBsvDā¤Unexpected block in infix position (missing statement control word before the expression?)ā¤at /tmp/3JBUIlBsvD:1ā¤------> class A { methdo foo($)ā { } }; A.foo 1⤠expecting any of:ā¦Ā» | ||
| psch | m: class A { method foo($) { } }; A.foo 1 | 16:15 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«===SORRY!=== Error while compiling /tmp/mkAqX8uRQXā¤Two terms in a rowā¤at /tmp/mkAqX8uRQX:1ā¤------> class A { method foo($) { } }; A.fooā 1⤠expecting any of:⤠infix⤠infix stopper⤠statement end⤠ā¦Ā» | ||
| psch | m: class A { method foo(:$a!) { } }; A.foo :a | ||
| camelia | ( no output ) | ||
| psch | nameds are weird vOv | ||
| bartolin | I seem to remember a bug for JVM wrt :chomp | ||
| some tests in S16-io/lines.t are fudged for JVM | |||
| .. though i'm not sure, that is related here | |||
| psch | bbi20 or so o/ | 16:16 | |
| bartolin | not ok 463 - handle 1,2: chomp => True / colons | ||
| expected: 'onetwo' | |||
| got: 'one: | |||
| :two: | |||
| ^^ that's one of the failing tests there. | 16:17 | ||
| nine | I dare say the main issue here is different buffers used by different ways to read the file | 16:28 | |
| psch | well, i don't get it | 16:43 | |
| i mean, something is weird with using a combination of .get and .slurp-rest, as the gist shows | |||
| i had thought it might be cause of all the ByteBuffer.flip()ing we do, but i don't grok what exactly we do in SyncHandle.read in the first place, so i don't know... :) | 16:44 | ||
| bartolin | btw, I see no test for slurp-rest(:bin) in roast | 16:46 | |
| nine | psch: the weird thing is that while I can reproduce the problem with mixing get() and slurp-rest, it doesn't seem to affect precomp loading. | 16:48 | |
| Run this twice: RAKUDO_MODULE_DEBUG=1 ./perl6-j -Ilib -e 'use Test' | |||
| Loading precompiled | |||
| /home/nine/rakudo/lib/.precomp/614C136150B073F1BC3374FAF4340A880DA97C37.1.46324436631E9/3A/3AF393AF91BDB1C86C71740C13F8E9A89BF7C3ED | |||
| Both times it seems to load the precompiled file just fine. I would assume that if loading was broken, it would kind of explode | 16:49 | ||
| psch | nine: try 'use NativeCall' instead of Test | ||
| nine | That looks like a different issue | ||
| Or maybe it really doesn't explode. I modified the precomp file so it definitely would no longer be valid and I still get no error. | 16:50 | ||
| psch | fwiw, locally even "class Foo { }" doesn't load correctly without 'no precompilation' | ||
| nine | What's the easiest way to add debug output to the Java code? | 16:53 | |
| bartolin | nine: and if you add '; ok 1' after 'use Test'? | ||
| nine | psch: we never even tried to load the precomp due to the type difference you noticed | 17:10 | |
| psch | nine: yeah, but fixing that isn't enough, because the first few bytes aren't right | 17:11 | |
| because it still has the 0x0a | |||
| nine | I may have a workaround for that | 17:15 | |
| Well, still not right there yet: java.lang.ClassFormatError: Incompatible magic value 173034243 | 17:20 | ||
| Ah, a simple off by one error....another try | 17:21 | ||
| TimToady | huh, my forest fire program is bust, something is deconting my neighbors... | 17:43 | |
| (the program depends on the calculated neighbors being lvalues pointing back into the grid) | 17:44 | ||
| I wonder when it was borken... | 17:45 | ||
|
17:46
sortiz joined
|
|||
| TimToady | m: gist.github.com/anonymous/5eb500b8...daeccd5d8d | 18:19 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«Bad decont⤠in block <unit> at /tmp/mTNZ5_iO1d line 13ā¤ā¤Ā» | ||
| TimToady | there's a cutdown version of it | ||
| the forest fire program won't work unless we can assign back to a spot through the neighbor slice | 18:22 | ||
| jnthn | star: gist.github.com/anonymous/5eb500b8...daeccd5d8d | 18:23 | |
| camelia | ( no output ) | ||
| TimToady was planning to use the forest fire program at oscon maybe... | 18:25 | ||
| and it's just a lot cleaner to use a referential slice than an indirection... | 18:27 | ||
| I suppose if nothing is obvious, we could bisect | 18:30 | ||
| jnthn | m: use nqp; my @spot = [rand xx 10] xx 10; say nqp::iscont($_) for (gather { take-rw @spot[0][0]; }) | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«0ā¤Ā» | ||
| jnthn | star: use nqp; my @spot = [rand xx 10] xx 10; say nqp::iscont($_) for (gather { take-rw @spot[0][0]; }) | ||
| camelia | star-m 2016.01: OUTPUTĀ«0ā¤Ā» | ||
| jnthn | darn, over-recued it apparently | 18:31 | |
| star: use nqp; my @spot = [rand xx 10] xx 10; for (gather { take-rw @spot[0][0]; }) <-> $_ { say nqp::iscont($_) } | 18:32 | ||
| camelia | star-m 2016.01: OUTPUTĀ«Parameter '$_' expected a writable container, but got Num value⤠in block <unit> at /tmp/nedoaWaoQZ line 1ā¤ā¤Ā» | ||
| jnthn | hm, if that doesn't work, how does it work on star from 2016.01 at all? | 18:33 | |
| TimToady | eager? | ||
| star: use nqp; my @spot = [rand xx 10] xx 10; for (eager gather { take-rw @spot[0][0]; }) <-> $_ { say nqp::iscont($_) } | 18:34 | ||
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤Ā» | ||
| jnthn | m: use nqp; my @spot = [rand xx 10] xx 10; for (eager gather { take-rw @spot[0][0]; }) <-> $_ { say nqp::iscont($_) } | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«Parameter '$_' expected a writable container, but got Num value⤠in block <unit> at /tmp/gNaXPsd7dl line 1ā¤ā¤Ā» | ||
| jnthn | star: use nqp; my @spot = [rand xx 10] xx 10; for (eager gather { take-rw @spot[0][0]; }) <-> $_ { say nqp::iscont($_) } | ||
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤Ā» | ||
| jnthn | aha | ||
| TimToady | is that, 'aha, eager', or 'aha, I know what the problem is'? :) | 18:35 | |
| jnthn | m: use nqp; say nqp::iscont (eager gather { take-rw my $a })[0] | 18:37 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«0ā¤Ā» | ||
| jnthn | star: use nqp; say nqp::iscont (eager gather { take-rw my $a })[0] | ||
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤Ā» | ||
| jnthn | m: use nqp; say nqp::iscont (gather { take-rw my $a })[0] | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«1ā¤Ā» | ||
| jnthn | star: use nqp; say nqp::iscont (gather { take-rw my $a })[0] | ||
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤Ā» | ||
| jnthn | I think that points the finger pretty strongly at eager | 18:38 | |
| TimToady | m: use nqp; say nqp::iscont (eager my $a)[0] | 18:40 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«0ā¤Ā» | ||
| TimToady | m: use nqp; say nqp::iscont (my $a)[0] | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«1ā¤Ā» | ||
| TimToady | kinda surprised we don't have a test that caught that... | 18:41 | |
| jnthn | Me too | 18:43 | |
| m: use nqp; my \a = (gather { take-rw my $a }).list; say a.elems; say nqp::iscont(a[0]); | |||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«1ā¤0ā¤Ā» | ||
| jnthn | star: use nqp; my \a = (gather { take-rw my $a }).list; say a.elems; say nqp::iscont(a[0]); | ||
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤1ā¤Ā» | ||
| TimToady | so the implicit eager in .elems is also clobbering it | 18:45 | |
| explains some of my results with the big program | |||
| could fix the immediate assertion failure by removing eager, but still failed the same way later | 18:46 | ||
| m: use nqp; my \a = (my $a).list; say a.elems; say nqp::iscont(a[0]); | 18:47 | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«1ā¤0ā¤Ā» | ||
| jnthn | m: use nqp; my \ib = IterationBuffer.new; (gather { take-rw my $a }).iterator.push-all(ib); say nqp::iscont(ib[0]); | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«0ā¤Ā» | ||
| TimToady | don't need the gather | ||
| jnthn | star: use nqp; my \ib = IterationBuffer.new; (gather { take-rw my $a }).iterator.push-all(ib); say nqp::iscont(ib[0]); | ||
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤Ā» | ||
| jnthn | star: use nqp; my \ib = IterationBuffer.new; (my $a).list.iterator.push-all(ib); say nqp::iscont(ib[0]); | 18:49 | |
| camelia | star-m 2016.01: OUTPUTĀ«0ā¤Ā» | ||
| TimToady | star: use nqp; my \a = (my $a).list; say a.elems; say nqp::iscont(a[0]); | 18:50 | |
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤0ā¤Ā» | ||
| jnthn | m: use nqp; say nqp::iscont (my $a).list[0] | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«0ā¤Ā» | ||
| jnthn | star: use nqp; say nqp::iscont (my $a).list[0] | ||
| camelia | star-m 2016.01: OUTPUTĀ«0ā¤Ā» | ||
| TimToady | star: use nqp; my \a = (my $a,).list; say a.elems; say nqp::iscont(a[0]); | ||
| camelia | star-m 2016.01: OUTPUTĀ«1ā¤1ā¤Ā» | ||
| TimToady | .list is no-oping on Scalar, seems | ||
| jnthn | But that doesn't look like a change? | ||
| TimToady | m: use nqp; my \a = (my $a,).list; say a.elems; say nqp::iscont(a[0]); | 18:51 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«1ā¤1ā¤Ā» | ||
| TimToady | hmm | ||
| odd | |||
| jnthn | m: use nqp; say nqp::iscont (gather { take-rw my $a }).iterator.pull-one | 18:53 | |
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«0ā¤Ā» | ||
| jnthn | star: use nqp; say nqp::iscont (gather { take-rw my $a }).iterator.pull-one | ||
| camelia | star-m 2016.01: OUTPUTĀ«0ā¤Ā» | ||
| jnthn | That's also odd | ||
| TimToady | maybe the problem is in .push-all? | ||
| jnthn | Well, except I'd expect that pull-one to give back a container there too? | 18:54 | |
| star: say (gather { take-rw my $a }).iterator.pull-one.perl | |||
| camelia | star-m 2016.01: OUTPUTĀ«Anyā¤Ā» | ||
| TimToady | well, but if it fails in star... | ||
| jnthn | Yeah, it can't be The Thing to blame but it's still odd | ||
| star: say (gather { take-rw my $a }).iterator.pull-one.VAR.WHAT | |||
| camelia | star-m 2016.01: OUTPUTĀ«(Any)ā¤Ā» | ||
| TimToady | might be a different bug we fixed after star | 18:55 | |
| jnthn | m: say (gather { take-rw my $a }).iterator.pull-one.VAR.WHAT | ||
| camelia | rakudo-moar f6bc8b: OUTPUTĀ«(Any)ā¤Ā» | ||
| jnthn | That seems wrong in both | ||
| There's a missing `is rw` on the pull-one | |||
| TimToady | could that explain the original problem too? | 18:57 | |
| jnthn | We'll see :) | ||
| (Building...) | |||
| Yes, seems like it fixes the original too | 18:59 | ||
| TimToady | looks like about a 1/3 of the method pull-one have 'is raw', and the rest are bare | 19:00 | |
| did you put 'is rw' or 'is raw'? | 19:01 | ||
| surely 'is rw' would break some things | 19:02 | ||
| jnthn | raw :) | ||
| Adding your case as a test, then will do a spectest run | |||
| TimToady | I worry a bit about all the bare pull-ones that are out there | 19:03 | |
| I suppose special ones might know there can't be an lvalue | |||
| but you'd think the lack of 'is raw' is causing unnecessary deconts in various spots | 19:04 | ||
| jnthn | Yeah, worth reviewing them all | ||
| TimToady | well, thanks for lookin' at this | 19:05 | |
| TimToady was sufficiently panicky about his oscon talk without the ohnoez | 19:06 | ||
| jnthn | Don't think I'm up for the full audit this evening :) | 19:07 | |
| But will push this fix and test provided spectest looks good | |||
| TimToady | jnthn++ | 19:08 | |
| TimToady is kinda glad it turned out to be a sin of omission rather than a sin of commission :) | 19:09 | ||
| jnthn | :) | ||
| TimToady | probably a "revealed check" situation, in chess terms | 19:10 | |
| jnthn | Up to S17 and no problems so far. | ||
| TimToady | (my original plaint, that is) | 19:11 | |
| hard to see how something could be relying on a premature decont... | 19:12 | ||
| maybe I just don't have a good enough imagination... | 19:13 | ||
|
19:13
Ven joined
|
|||
| dalek | kudo/nom: ad82657 | jnthn++ | src/core/Seq.pm: Add missing `is raw` needed to fix `take-rw`. |
19:15 | |
| ast: 6fceefc | jnthn++ | S04-statements/gather.t: Test for `take-rw`. |
|||
| jnthn | There we go :) | ||
| Good luck with the talk :) | |||
| TimToady | thanks for pulling my ox out of the ditch, whether or not you consider it the sabbath :) | 19:16 | |
| jnthn | :) | 19:17 | |
| jnthn wanders off to the corner shop | 19:18 | ||
| TimToady | fyi forest fire works again, \o/ | 19:25 | |
| japhb | TimToady: Is it the same one used in perl6-bench? Or something different? | 19:32 | |
| moritz would guess Rosettacode | 19:36 | ||
| TimToady | it's pretty close to RC's version | 19:38 | |
| not the old one that copies arrays | |||
| timotimo | how's the performance? should we put the new code into perl6-bench, or do we have to fix the one in perl6-bench? | 19:39 | |
| TimToady | well, the new one is always gonna be faster than the old one | 19:40 | |
| timotimo | not if it's purely a bugfix change | 19:41 | |
| then we might have to make it slower | |||
| though what with 6.c that shouldn't be necessary often | |||
| TimToady | there was some period of time between star and now that the new one wasn't working | 19:42 | |
| dunno if the old one has had any dropouts | 19:43 | ||
| lunch & | 19:44 | ||
| timotimo | i think we had a period of time where the rc-forest-fire in perl6-bench didn't work | 19:45 | |
| japhb | *sigh* | 19:49 | |
|
22:43
Ven joined
|
|||
| nine | Turns out: practically nothing about my first attempt at a loadbytecodebuffer implementation for JVM was right :) | 23:04 | |