travis-ci Rakudo build failed. jnthn 'Implement shortname method in CoercionHOW.' 00:04
travis-ci.org/rakudo/rakudo/builds/133497401 github.com/rakudo/rakudo/compare/1...4e4395856e
psch it looks to me like we're not doing anything with mast_frames from &EVAL on nqp-j 05:34
afaiu that would fit with the problem, maybe?
on the other hand, it's just an empty VMHash..? 05:35
well, unless HLL::Compiler.compile sets it somewhere i'm not seeing
or anything below, anyway
nine psch: the reason for passing mast_frames is to share the mast_frames of the mbc compiler used for the EVAL with the mbc compiler used for the outer comp unit. Otherwise the EVAL's code objects in the outer unit's serialization context wouldn't find their static frames. 07:25
psch: I have no idea how this static frame business is handled on the JVM 07:29
psch nine: i think we talked about that? ISTR that i guessed it's probably CallFrame.staticInfo 07:36
ah, CallFrame.codeRef.staticInfo rather 07:37
not sure how to wrangle that in there - i don't really see how mast_frames does what it does, anyway...
oh. it *is* written to by QASTCompilerMAST 07:38
hmm, actually it looks to me that a MAST::Frame most closely matches to a JAST::Method..? 07:40
nine Yes, I pass it to QASTCompilerMAST's constructor. 07:43
[TuxCM] This is Rakudo version 2016.05-24-gbe4e439 built on MoarVM version 2016.05 09:30
test 19.638
test-t 12.586
csv-parser 33.548
note that one of the tests failed twice, passed in manual mode and then passed in make test again 09:31
masak [TuxCM]: what kind of failure_ 10:22
? 10:23
lizmat grrr: 10:30
# Failed test 'my Int %h declares a Hash with Str(Any) keys'
# at t/spec/S09-typed-arrays/hashes.t line 14
# expected: (Str(Any))
# got: (Str(Any))
dalek p: a4143e3 | (Daniel Green)++ | docs/ops.markdown:
Fix two inconsistencies in the ops documentation
 10:46
p: 173098b | lizmat++ | docs/ops.markdown:
Merge pull request #288 from MasterDuke17/master

Fix two inconsistencies in the ops documentation
kudo/nom: c5dfd77 | lizmat++ | src/core/Hash.pm:
Bring Hash.keyof up to date, dogbert17++

Turned out we only needed jnthn++ 's last commit		 10:59
ast: 34ce0e9 | lizmat++ | S (2 files):
Fix Hash.keyof tests, now that it returns Str(Any)
 11:00
ast/6.c-errata: de024bb | lizmat++ | S (2 files):
Fix Hash.keyof tests, now that it returns Str(Any)
 11:06
masak lizmat++ 11:16
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Bring Hash.keyof up to date, dogbert17++ 12:00
travis-ci.org/rakudo/rakudo/builds/133572722 github.com/rakudo/rakudo/compare/b...dfd77a5838
pmurias jnthn: setwho deconts on the jvm but not on the moarvm, where deconts on the moarvm but not on the jvm 14:14
dalek p: 8cc1e10 | (Pawel Murias)++ | src/vm/js/nqp-runtime/reprs.js:
[js] Fix signature.
 14:16
p: af5b2dc | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Make callmethod decontainerize the invocant.
p: 54251ef | (Pawel Murias)++ | src/vm/js/Operations.nqp:
[js] Decontainerize arguments to some ops.
p: 1052795 | (Pawel Murias)++ | t/nqp/067-container.t:
Test that some ops on a container decontainerize.
nqp: c72188d | (Pawel Murias)++ | src/vm/js/nqp-runtime/sixmodel.js:
nqp: [js] Make a container type object decont it itself.
jnthn pmurias: Nice find :) 14:32
pmurias: I suspect they should decont both on both :)
pmurias jnthn: I can arrange that ;) 14:40
dalek kudo/nom: 7500ea2 | lizmat++ | src/core/List.pm:
Make List.new about 4x as fast
 19:48
lizmat not sure how often that actually gets called, but it seems to have a positive effect on the spectest 19:49
jnthn :)
lizmat Files=1098, Tests=52263, 254 wallclock secs (14.59 usr 4.19 sys + 1584.49 cusr 122.92 csys = 1726.19 CPU)
jnthn lizmat: Don't suppose you had chance to try out MoarVM HEAD yet? :)
lizmat indeed, not yet
trying to wrap my head around List reification
jnthn :-)
lizmat I'm getting more and more the feeling there's at least one level of indirection too many 19:50
jnthn heh :)
lizmat jnthn: could that be the case?
anyways, I got this concept of another speedup in reification 19:52
but somehow in some cases, it reifies a number of elements now that get lost
jnthn Well, it *could*, but what's there now is mostly a result of starting out as simple as could possibly work and then refactoring it until it handled the cases it needs to 19:53
lizmat m: my $a := squish( 42..Inf ); say $a[0]
camelia rakudo-moar c5dfd7: OUTPUT«42␤»
lizmat this gives 44 or 45 in my case :-(
jnthn o.O
One LOI is needed to make things not go incredibly wrong in cases like 19:54
my @a = 1, @a, 2;
lizmat oddly enough, (42..Inf).squish[0] works fine
jnthn Where the RHS mentinos the LHS
*mentions
lizmat yeah, I got that
jnthn And then the level of indirection around pushing reified results is there to allow the same reification code to work out with List and Array and typed arrays and so on, iirc. 19:55
But most of those latter cases are inline-sized.
lizmat m: my @a = ^5; @a[2]:delete; $_++ for @a # also looking at fixing this 19:56
camelia rakudo-moar c5dfd7: OUTPUT«Cannot call postfix:<++>(Any); none of these signatures match:␤ (Mu:D $a is rw)␤ (Mu:U $a is rw)␤ (Int:D $a is rw)␤ (int $a is rw)␤ (Bool:U $a is rw)␤ (Bool:D $a is rw)␤ (Num:D $a is rw)␤ (Num:U $a is rw)␤ (num …»
jnthn wonders if that's broken... :) 19:58
Guess it arguably is
lizmat m: my %h; %h<a>++; dd %h # we also expect this to work
camelia rakudo-moar c5dfd7: OUTPUT«Hash %h = {:a(1)}␤»
jnthn That's not an iteration case though 19:59
lizmat true
jnthn m: my @a = ^5; @a[2]:delete; @a[2]++
camelia ( no output )
jnthn That works out fine for example
lizmat m: my @a = ^5; @a[2]:delete; @a[2]++; dd @a
camelia rakudo-moar c5dfd7: OUTPUT«Array @a = [0, 1, 1, 3, 4]␤»
lizmat ok
hmmm....
jnthn So it's a bit distinct. But yeah, arguably iterating over a deleted element could produce a container that if assigned will bind itself into the array that position, just as assignment to a deleted element does. 20:00
*at that position
lizmat yeah, that was the plan
jnthn I think I'm good with it doing that :)
lizmat I mean, we already check for null's 20:01
jnthn Yeah. I guess a List should never contain a null 'cus there's no :delete
lizmat m: my Int @a = ^10; @a[2]:delete; .say for @a
camelia rakudo-moar c5dfd7: OUTPUT«0␤1␤(Int)␤3␤4␤5␤6␤7␤8␤9␤»
jnthn So putting it in the iterator code (that is shared between List/Array) should do it 20:02
And shouldn't do any accidental harm.
lizmat hmmm.... that means there can never be a nqp::null in a List ?
jnthn I can't think of a case where that'd ever happen. 20:07
lizmat cool 20:09
another thing in which List.iterator and Array.iterator can differ
jnthn Hm, I guess there is the case where we wrap an NQP array up in a Perl 6 List, but even there I can't think of a concrete case where one of those would result in it either 20:13
Time to go relax :) Probably will be about tomorrow o/ 20:14
lizmat jnthn: enjoy relaxation, cu tomorrow ... or some other time soon (I hope) 20:15
jnthn I expect to do Perl 6 stuff all Tue/Thu next week :) 20:16
So certainly then ;-)
lizmat ++jnthn
:-)
masak m: sub foo { sub bar { state $x; $x++; say $x }; bar; bar }; foo; foo 20:27
camelia rakudo-moar 7500ea: OUTPUT«1␤2␤1␤2␤»
masak in other words, `state` variables inside a sub means behavior isn't preserved when the sub is moved inside another routine. 20:28
just realized this.
oh, hey, this ain't #perl6...
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Make List.new about 4x as fast' 20:50
travis-ci.org/rakudo/rakudo/builds/133634119 github.com/rakudo/rakudo/compare/c...00ea2a100b
cognominal m: sub foo { our sub bar { state $x; $x++; say $x }; bar; bar }; foo; foo 21:47
camelia rakudo-moar 7500ea: OUTPUT«1␤2␤1␤2␤»
cognominal inner our chocks my inner self 21:48
on the other hand, in that case "1\n\2\n\3\n4" would not have surprised me, here. 21:50
lizmat m: use nqp; say nqp::isbig_I(int.Range.max) # jnthn: expected a 0 there 21:51
camelia rakudo-moar 7500ea: OUTPUT«1␤»
lizmat m: use nqp; say nqp::isbig_I(int32.Range.max) 21:52
camelia rakudo-moar 7500ea: OUTPUT«0␤»
lizmat m: use nqp; say nqp::isbig_I(int32.Range.max + 1) # cutoff seems to be at 32bit ?
camelia rakudo-moar 7500ea: OUTPUT«1␤»

Powered by Cro and the Raku® Programming Language.

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

Thank you!