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