[Tux] This is Rakudo version 2016.10-111-g4fdf6d7 built on MoarVM version 2016.10-27-g196361f 07:50
csv-ip5xs 3.237
test 14.711
test-t 7.010
csv-parser 15.537
lizmat Files=1150, Tests=53703, 210 wallclock secs (12.69 usr 3.71 sys + 1282.98 cusr 120.12 csys = 1419.50 CPU) 08:00
m: sub a(array:U \a) { say "foo" }; a array # can have an array:U sig 08:11
camelia rakudo-moar 4fdf6d: OUTPUT«foo␤»
lizmat but other than that, it appears to be pretty useless 08:14
nine just submitted a "Web development and Perl 6" talk for LPW 2016. Stress level jumps up again... 09:12
masak ++nine 09:17
FROGGS o/
nine The final straw was the sentence "Even though I am in the thralls of Perl 6, I still do all my web development in Perl 5 because the ecology of modules is so mature." on blogs.perl.org/users/ken_youens-cla...erl-5.html linked by this week's Perlweekly. 09:18
Need to get the message across, that this shouldn't keep one from using Perl 6 :) 09:19
masak nine: you're my personal hero. keep it up.
vendethiel ^ that :-) 09:20
dalek kudo/nom: feb7bcb | lizmat++ | src/core/Array.pm:
Make AT-POS on 1,2,3dim arrays about 20x faster

Unfortunately, this only translates in about 5x faster for single dim shaped arrays and only 1.5 times faster for 2/3dim arrays if you're using postcircumfix [;]		 10:27
lizmat jnthn: is this what you had in mind using the specialized nqp ops for 2/3 dim ? ^^^^ 10:31
jnthn Umm 10:32
m: my @a[2] = [1,2],[3,4]; say @a[1;1] 10:33
camelia rakudo-moar feb7bc: OUTPUT«Cannot access 1 dimension array with 2 indices␤ in block <unit> at <tmp> line 1␤␤»
jnthn Oh?
lizmat star: my @a[2] = [1,2],[3,4]; say @a[1;1]
camelia star-m 2016.04: OUTPUT«4␤»
jnthn I was gonna say
That's a bad regression.
lizmat not caught by spectest :-(
jnthn :-( 10:34
Anyway, my idea was that we'd put those into a Shaped2D and Shaped3D role
masak time to write more tests!
jnthn And mix it in only when we have an array with 2 or 3 dimensions
At the same time we mix in the ShapedArray role
Or whatever it's called
lizmat ah, ok, gotcha
I think :-) 10:35
masak jnthn: what about Shaped4D? or rather, what makes 2 and 3 dimensions special? that they are far more common?
jnthn masak: Yeah, there's special VM-level ops for 2 and 3
masak gotcha
jnthn masak: That avoid an indice array allocation
I figure they will be the overwhemlingly common case in the wild.
masak what if someone mixes Shaped2D into something else?
jnthn I suspect it'll live in Rakudo::Internals. So on your own head be in :P 10:36
*it
masak kind of the answer I expected :)
jnthn If we really worried about the role leaking we could .^add_method the two things I guess but... :) 10:37
masak not sure it's an actual worry, just something my brain flagged up as "what about quests^Wfalse positives?" 10:38
lizmat jnthn: do you agree that the current naming of ShapedArray is in fact wrong, and should be ShapedNArray ?
so we can have Shaped1Array, Shaped2Array and Shaped3Array ?
jnthn lizmat: Well, my original thinking was ShapedArray is the one you always have, and then you add Shaped2 or Shaped3 on top of them 10:40
And they just provide the couple of extra methods
Since we will want the slurpy ones for fallback
lizmat ah, ok 10:41
jnthn: btw, would appreciate your thoughts on gist.github.com/lizmat/4dd5117f34f...8b297d8b19 10:55
m: for 42 { "foo".match(/foo/); say $/ } 10:56
camelia rakudo-moar feb7bc: OUTPUT«Nil␤»
lizmat m: for "foo" { /foo/; say $/ }
camelia rakudo-moar feb7bc: OUTPUT«｢foo｣␤»
lizmat m: for "foo" { .match(/foo/); say $/ } 10:57
camelia rakudo-moar feb7bc: OUTPUT«Nil␤»
lizmat jnthn: only happens in a for block :-(
m: for "foo" { my $/; .match(/foo/); say $/ }
camelia rakudo-moar feb7bc: OUTPUT«｢foo｣␤»
lizmat note: ^^^ no redef warning
jnthn Well, it's not a redef since $/ is not block level, but routine/unit level 10:58
Plus a start block gets a fresh one
lizmat m: my $/; for "foo" { my $/; .match(/foo/); say $/ }
camelia rakudo-moar feb7bc: OUTPUT«Potential difficulties:␤ Redeclaration of symbol '$/'␤ at <tmp>:1␤ ------> my $/⏏; for "foo" { my $/; .match(/foo/); say ␤｢foo｣␤»
lizmat in the gist I added debug code to show the nqp::where of $/
and it's the same everywhere, but still $/ does not get the Match object 10:59
I also verified it doesn't assign
m: my $/ = 42; for "foo" { .match(/foo/); say $/ }
camelia rakudo-moar feb7bc: OUTPUT«Potential difficulties:␤ Redeclaration of symbol '$/'␤ at <tmp>:1␤ ------> my $/⏏ = 42; for "foo" { .match(/foo/); say $/␤42␤»
lizmat m: $/ = 42; for "foo" { .match(/foo/); say $/ }
camelia rakudo-moar feb7bc: OUTPUT«42␤»
lizmat the only difference I see between before and after the Str.match refactor: 11:00
*differences
1. Str.match is now a multi
2. instead of looking up $/ all the time, it's only done once and then passed around as an alias 11:01
I'm afraid if we don't solve this, I would have to revert the Str.match refactor :-( 11:03
jnthn Think I've solved things like this before 11:08
Typically it needs a $/ := nqp::getcallerlex('$/') somewhere 11:09
lizmat well, it's using getlexdyn atm
jnthn Oh
That may be the problem
Perhaps it's wrongly finding the $/ inside of map internals
lizmat changing them to getcallerlex did *not* solve the problem
by all means, I'll do this again
jnthn OK, I can look more deeply into it this afty :) 11:10
lizmat I'll push the getcallerlex fix that FROGGS suggested yesterday just in case 11:11
ok
?
jnthn Sure
dalek kudo/nom: ec3af56 | lizmat++ | src/core/ (25 files):
Remove trailing open curlies from comments

They were bothering me for some time already :-)
lizmat jnthn: nqp::getlexrelcaller(nqp::ctxcaller(nqp::ctx()), '$/') right ? 11:12
jnthn Oh no
It's not that op
lizmat ok, that may be the issue then, trying now 11:13
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Make AT-POS on 1,2,3dim arrays about 20x faster
travis-ci.org/rakudo/rakudo/builds/171944546 github.com/rakudo/rakudo/compare/4...b7bcb42e76
jnthn getlexcaller iirc
github.com/rakudo/rakudo/blob/70a3...rol.pm#L98 11:14
Like that
lizmat gotcha 11:16
jnthn: no dice 11:20
is there something against passing what nqp::getlexcaller returns as an argument ?
$ 6 'for 42 { "foo".match(/foo/); say $/ }' 11:21
Nil
$ 6 'if 42 { "foo".match(/foo/); say $/ }'
｢foo｣
it's definitely something related to for / map
m: $ 6 'map { "foo".match(/foo/); say $/ }, 42'
Nil
camelia rakudo-moar feb7bc: OUTPUT«===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------> $⏏ 6 'map { "foo".match(/foo/); say $/ }, ␤ expecting any of:␤ infix␤ infix stopper␤ statement end␤ statement modif…»
lizmat $ 6 'map { "foo".match(/foo/); say $/ }, 42' 11:22
Nil
star: map { "foo".match(/foo/); say $/ }, 42
camelia star-m 2016.04: OUTPUT«｢foo｣␤»
lizmat jnthn: fwiw, that code runs IterateOneWithoutPhasers.sink-all : github.com/rakudo/rakudo/blob/nom/...ds.pm#L440 11:49
perhaps the problem is related to the "Cannot reference undeclared local '__lowered_lex_3225'" issue 11:50
fwiw, removing that block, replacing the nqp::while($running), with while $running {} doesn't fix the issue 11:51
travis-ci Rakudo build passed. Elizabeth Mattijsen 'Remove trailing open curlies from comments 11:59
travis-ci.org/rakudo/rakudo/builds/171953993 github.com/rakudo/rakudo/compare/f...3af5659942
dalek kudo/nom: 8e79509 | lizmat++ | src/core/Str.pm:
Replace getlexdyn by getlexcaller

As that appears to be the correct nqp::op invocation for passing $/ around: irclog.perlgeek.de/perl6-dev/2016-...i_13491020		 12:09
lizmat still: $ 6 'for 42 { "foo".match(/foo/); say $/ }' 12:10
Nil
timotimo when you're passing around $/, does it accidentally get deconted somewhere? 12:11
so you can't assign into it no more?
lizmat wouldn't that just cause an exception then ? 12:12
timotimo probably, yeah
lizmat also: my test file in which I did the refactor 12:13
which contains functional equivalent of code, with slightly different names
works fine :-(
timotimo is something going in between the match method and the caller so we get the wrong caller? 12:14
lizmat gist.github.com/lizmat/86611194472...ad393ea9a7 # madch.pl
run that, and you see it works ok there
development is on that file 12:15
once I deem it ready, I remove all the match code from Str, read the file, remove the proto and code at beginning and end 12:16
do s:g/IDERATOR/ITERATOR/ and s:g/madch/match/
and presto
saves me ~ 2 minutes trying every change
timotimo yeah 12:17
dalek kudo/nom: 4bd09a7 | lizmat++ | / (4 files):
Split off array operators into a separate file

The source of Array.pm is becoming unwieldy, and will be more so before long. So split off stuff that can be split off easily.
This requires re-running Configure.pl, alas.		 12:41
lizmat actually, only on the JVM 12:50
timotimo what is? 12:55
oh, btw, were you considering generating the source for 2dim and 3dim array stuff?
[Coke] nine++
lizmat timotimo: when I have more clarity on that, but yes, that is an option 12:56
[Coke] lizmat++ 12:57
jnthn I'd not expect there to be much worth generating for the 2d/3d things; it's just a handful of methods in each of the roles, I'd expect 12:59
lizmat and they would take different numbers of parameters, which would make generating a bit awkward 13:00
but still :-)
jnthn dislikes generating code generally 13:01
So if it's borderline worth it, please don't 13:02
timotimo OK
dalek kudo/nom: fb0c648 | lizmat++ | tools/build/ (2 files):
Extract settings JVM file list into separate file

So that we don't have to do a re-configure if we change the list of files of which the settings consists.		 13:07
jnthn Righty, five minutes break and then I'll have Perl 6 shaped tuits :) 13:25
viki \o/
lizmat yeah! 13:29
masak .oO( array3d shaped tuits ) :P 13:30
lizmat hopes for Str.match refactor saving tuits, actually 13:31
gfldex .oO( www.eski.io/demo/mill-crimson/wp-co...rs-2-p.jpg )
dalek kudo/nom: b5302b8 | lizmat++ | / (5 files):
Split off the TypedArray role into its own file

Also make sure we close the Array class in array_operators.pm, as we want the TypedArray role to only be visible inside the Array class		 13:35
jnthn lizmat: So, the match/map problem is still there? I just nead HEAD of Rakudo? 13:40
lizmat yup
jnthn OK, building latest everything :)
lizmat gist.github.com/lizmat/86611194472...ad393ea9a7 # madch.pl
that's my dev code, that works ok outside of the setting
jnthn my $cursor-init := Cursor.^can("!cursor_init").AT-POS(0); 13:41
Any reason not just Cursor.^lookup('!cursor_init') ?
And similar for others bloew
*below
m: for 42 { say "foo".madch(/foo/); say $/ } 13:42
camelia rakudo-moar fb0c64: OUTPUT«No such method 'madch' for invocant of type 'Str'␤ in block <unit> at <tmp> line 1␤␤»
jnthn m: for 42 { say "foo".match(/foo/); say $/ }
camelia rakudo-moar fb0c64: OUTPUT«｢foo｣␤Nil␤»
jnthn star: for 42 { say "foo".match(/foo/); say $/ }
camelia star-m 2016.04: OUTPUT«｢foo｣␤｢foo｣␤»
jnthn bisectable: for 42 { say "foo".match(/foo/); say $/ }
bisectable6 jnthn, Bisecting by output (old=2015.12 new=fb0c648) because on both starting points the exit code is 0
jnthn, bisect log: gist.github.com/6e5d51c186915835d1...b191049a20
jnthn, (2016-10-23) github.com/rakudo/rakudo/commit/b7...e8f5c77f41
lizmat it's the initial refactor commit, that was already known 13:43
jnthn: no particular reason to use ^can over ^lookup, is ^lookup faster ?
jnthn Yes 13:45
It's likely just a hash table access, whereas the can approach finds all candidates up the mro and puts them in a list, which is then indexed by AT-POS and thrown away 13:46
So it's more GC overhead and more work to use .^can for this
lizmat ok, will fix and test
jnthn $ ./perl6-m -e '<foo>.map({ .match(/foo/); say $/ })' 14:00
｢foo｣
m: <foo>.map({ .match(/foo/); say $/ }) 14:01
camelia rakudo-moar b5302b: OUTPUT«Nil␤»
jnthn m: for ^2 { <foo>.map({ .match(/foo/); say $/ }) }
camelia rakudo-moar b5302b: OUTPUT«Nil␤Nil␤»
jnthn spectests 14:02
lizmat: So I did one fix but then looked a bit deeper and am now trying a second probably better one 14:11
lizmat ok, *phew*
jnthn lizmat: I was a tad worried my fix may have a perf impact but now I've dug deeper it seems it won't
lizmat well, I'm looking forward to looking at the patch :-) 14:12
jnthn If this second approach works it'll be a one-line change ;)
Will need to re-spectest it though
lizmat gotcha
jnthn Anyone else got any major blockers I should take a peek at? 14:13
Otherwise I'll probably pick off some RTs 14:14
lizmat I had something else yesterday...
hmmmm.... stack overflowed I guess :-( 14:16
jnthn np :)
jnthn has no shortage of things that want attention
dalek kudo/nom: ba152bd | jnthn++ | src/core/Cool.pm:
Fix handling of $/ in some uses of `.match`.

This of note fixes the use of `match` in a `for` loop, which was failing to set `$/`. This happened when `match` became a multi.		 14:19
jnthn lizmat: Will you add a test for that or should I?
lizmat argh: I had missed the proto :-( 14:20
I will add tests as penance :-)
jnthn Thanks! :)
I'll go golf some supply code that causes a GC abort as a...reward? 14:21
lizmat :-) yes, please...
also: HARNESS_TYPE=6 make spectest still breaks could be an attention point
dalek kudo/nom: 0245eb8 | lizmat++ | src/core/ (3 files):
Use much cheaper ^lookup instead of ^can, jnthn++
 14:22
kudo/nom: cb8f783 | lizmat++ | / (5 files):
Seperate the ShapedArray role into a separate file
japhb Since jnthn asked earlier -- jnthn, nine: github.com/jnthn/oo-monitors/issues/8 is giving me some grief. Appears to be finicky and related to precomp, but I tried a number of different variants and recorded them in the issue, so maybe that will jumpstart debugging. 14:42
As jonathanstowe surmised, it appears related to rt.perl.org/Ticket/Display.html?id=127858
jnthn m: gist.github.com/jnthn/5f7801deffdf...957423312c 14:47
camelia rakudo-moar cb8f78: OUTPUT«(signal ABRT)ok␤ok␤ok␤ok␤ok␤ok␤ok␤ok␤ok␤ok␤ok␤ok␤ok␤»
jnthn There's an interesting golf 14:49
gfldex is .^lookup as official as .^can ? 14:57
[Coke] gfldex: it's in t/spec .. 14:59
viki .^can gets a company car, but .^lookup always wears ties... I'd say they're equally official ^_^ 15:05
gfldex what is the difference between .^can and .^lookup ? 15:07
lizmat gfldex: the way I understand it is that ^lookup doesn't walk .mro 15:09
it just checks in the class itself 15:10
jnthn lookup will walk MRO too 15:12
dalek kudo/nom: 221633a | lizmat++ | / (6 files):
Create Shaped(1|2|3)Array roles / files

So it will be easier to see the differences and similarities. If the similarities prove to be sufficiently similar, these new roles may well become generated.
jnthn It just stops when it finds a result
jnthn Whereas can keeps going, and makes a list of all of the possible results
lizmat ah, TIL something (again) 15:13
dalek ast: 14358e2 | lizmat++ | S05-match/arrayhash.t:
Add test for smartmatching finite vs infinite Seq

Also add some comments on the existing tests		 15:18
ast: 819db21 | lizmat++ | S05-modifier/continue.t:
Add test for $/ not being set inside for { } issue
|Tux| re-runs timing after seeing this many messages from dalek … 15:46
lizmat [Tux]: won't be much difference, I'm afraid 15:47
|Tux| still curious
lizmat m: my @a[2] = [],[]; @a[0;0] = 42; dd @a # jnthn, I assume this is supposed to work ? 15:51
camelia rakudo-moar 221633: OUTPUT«This type cannot unbox to a native integer: P6opaque, Array␤ in block <unit> at <tmp> line 1␤␤»
lizmat aka, a 2 element shaped array with sizable arrays in them
|Tux| This is Rakudo version 2016.10-121-g221633a built on MoarVM version 2016.10-27-g196361f 15:54
csv-ip5xs 3.143
test 14.227
test-t 7.181
csv-parser 15.423
jnthn lizmat: Yeah, would expect it to 15:55
lizmat this I did not break :-) 15:56
jnthn OK, seems that fixing LEAVE and friends to really properly get things right with threads is what's needed to deal with the bug I'm hunting properly 16:25
timotimo sounds like a quite involved bug 16:28
jnthn Yeah
I thought I could put in a band-aid fix in the meantime
Then realized it ain't gonna fly
So, guess I've some design work to be doing 16:29
dalek kudo/nom: 07eeea8 | jnthn++ | src/core/Exception.pm:
Add a couple of missing CX:: classes.
 16:35
ast: d67b3ba | jnthn++ | S04-exception-handlers/control.t:
Cover CX::Emit and CX::Done.
 16:36
jnthn Some bonus work done while investigating and bug-hunting :)
afk for a bit
viki m: gist.github.com/zoffixznet/14ae655...2b28969408 16:39
camelia rakudo-moar 221633: OUTPUT«#<failed match>␤»
viki Interesting it's a #<failed match> and not Nil :/
Oh, that's what subparse always returns :/
star: gist.github.com/zoffixznet/14ae655...2b28969408
camelia star-m 2016.04: OUTPUT«#<failed match>␤»
viki OK then 16:40
lizmat viki: yeah, that's ultimately the difference between parse and subparse 16:41
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Create Shaped(1|2|3)Array roles / files 17:12
travis-ci.org/rakudo/rakudo/builds/172011516 github.com/rakudo/rakudo/compare/c...1633ac8221
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0).
dalek p: 25cee34 | (Pawel Murias)++ | src/vm/js/ (2 files):
[js] CPS support is currently broken, so I remove the parts of it that cause performance problems.

Once I'm fixing CPS I will re-add them in a way that doesn't cause performance problems for non-CPS using code.		 19:05
p: fe038b8 | (Pawel Murias)++ | src/vm/js/nqp-runtime/ (4 files):
[js] Make multi caches be serialized as null as they get recreated.
p: ad1a799 | (Pawel Murias)++ | t/serialization/01-basic.t:
Test serialization of a multi cache.
kudo/nom: d4355cb | lizmat++ | src/core/ShapedArray.pm:
Activate the Shaped123Array roles

So that we get the efficiency gains of feb7bcb42e76c3c back again.		 19:41
ast/lexical_module_load: e9205cc | niner++ | / (4 files):
Fixup tests for lexical module loading

We now need to explicitly use modules if we want to use their symbols and can no longer rely on them being loaded by one of our dependencies.		 19:52
ast/lexical_module_load: a31614e | niner++ | / (2 files):
Test that globals of loaded modules are imported lexically
kudo/lexical_module_load: 56e4044 | niner++ | / (5 files):
Make importing globals from loaded modules lexical

Right now if A depends on C:auth<foo> and B depends on C:auth<bar> you cannot use A and B in the same program. Fix this by having not only exported symbols be lexical but also the globals contained in a module.
So only A will even have a C that's bound to C:auth<foo>. This means that you have to "use" modules in every scope that accesses those names, 5cdba73 | niner++ | src/Perl6/World.nqp: Fix: use Foo::Bar; class Foo { my Foo::Bar $bar; } not finding Foo::Bar
A lexically imported package stub was replaced instead of upgraded when a class of the same name was declared.
kudo/lexical_module_load: 45d12e0 | niner++ | src/Perl6/ModuleLoader.nqp:
Fix: class Foo { use Foo::Bar; my Foo $foo; } not finding Foo

The lexically imported "Foo" package stub containing "Bar" shadowed the
  "Foo" class we're currently declaring. Fix by considering all scopes
when looking for existing symbols, not just the one we're importing into.
kudo/lexical_module_load: 6e5d96a | niner++ | src/Perl6/World.nqp:
Fix our scoped nested package swallowed by lexically scoped parent

In "use Foo; class Foo::Bar { }" Foo::Bar would be created as child of the lexically imported Foo class and was thus missing from the globals. Previous fixes only handled the case when Foo was a stub package, not when it was a full class. Remove the special case and fix the follow up bug that we now got a duplicate symbol when trying to lexically override classes in the RESTRICTED setting. There's no need to upgrade the main package to a global if we only want to create a lexically scoped child anyway.
nine Rebased the lexical_module_load branches to current nom/master.
lizmat :-)
nine Considering that the branch passes test and stresstest and successfully installs Task::Star, we're gonna need an executive decision on how to go forward. 20:08
lizmat do you have an idea on the ecosystem fallout ? 20:10
japhb nine: While you're waiting on that, do you have desire/cycles to look at rt.perl.org/Ticket/Display.html?id=127858 (which I found out about via github.com/jnthn/oo-monitors/issues/8)? 20:11
lizmat and another Perl 6 Weekly hits the Net: p6weekly.wordpress.com/2016/10/31/...-в-perl-6/
japhb lizmat: I literally refreshed 3 minutes ago, thinking "Isn't this about when Liz publishes a new weekly?" :-) 20:12
lizmat :-)
well, usually I'm an hour later or so.... but since we went back from DST and you guys haven't, I thought I'd do it one hour earlier :-) 20:13
japhb Heh
[Coke] pmurias: the latest short blog post was nice, thanks for the update. 20:27
FROGGS o/ 20:33
nine japhb: that looks....headachy to fix 20:44
dalek kudo/nom: 7e534bb | lizmat++ | src/core/Rakudo/Internals.pm:
Remove now unused role MatchIterator
 20:46
kudo/nom: 59b4526 | lizmat++ | src/core/Ra (2 files):
Abstract the int Range iterator away

So we can use it elsewhere		 21:12
kudo/nom: ba49679 | lizmat++ | src/core/List.pm:
Add count-only/bool-only/sink-all

If a List is completely reified, we don't need to run through it to find out how many elements, any elements, or just sink the whole thing.		 21:25
MasterDuke timotimo (or others), i'm looking in src/vm/moar/QAST/QASTOperationsMAST.nqp at MAST::InstructionList.new(), which takes an optional $lineno. i see lot of calls to MAST::InstructionList.new(), but never with the lineno 21:36
i still haven't been able to find a/the spot where a line number is actually stored somewhere when being compiled 21:38
FROGGS when source code is parsed with Perl6::Grammar and Perl6::Actions, the current match $/ is put into the QAST tree as 'node', like in: QAST::Op.new (..., :node($/) ) 21:45
and when that op fails it gets the line number from $/
MasterDuke interesting. same for the core settings? 21:47
japhb nine: Yep. Hence the reason I'm reduced to finding interesting variations of the failure mode to hopefully trigger a flash of insight in whichever hero steps forward. :-) 21:48
FROGGS MasterDuke: yes, all Perl 6 code is parsed the same 21:52
dalek kudo/nom: d53a905 | lizmat++ | src/core/List.pm:
Let List.keys use IntRangeIterator when it can
 21:55
MasterDuke FROGGS: where would one of those failures be? 21:57
FROGGS what failures? 22:00
MasterDuke "when the op fails"?
dalek ast: e0bc46d | lizmat++ | S03-metaops/hyper.t:
Fix test expecting a Range rather than a Seq

List.keys had a short-cut whereby it would return a Range, rather than a Seq (which one should expect). This has been remedied with d53a90594ce8010d0c and thus the test failed.		 22:01
MasterDuke ah ha, i may have found something 22:02
FROGGS github.com/rakudo/rakudo/blob/nom/....nqp#L1715 22:03
MasterDuke github.com/perl6/nqp/blob/master/s....nqp#L1402
FROGGS this is how it is attached to the AST
yes, correct
you might find spots in Perl6::Actions where :node is not set, and that might be a place where we loose the line number information 22:04
dalek ast/6.c-errata: 1b62d04 | lizmat++ | S03-metaops/hyper.t:
Fix test because of fix in d53a905

List.keys should always return a Seq. It returned a Range if it wasn't lazy. The test depended on this behaviour. Altered to what it should be and marked as "todo"
MasterDuke FROGGS: so the backstory is that i wrote a horrible hack for moar that would parse gen/moar/m-CORE.setting (at exception time) to get actual source filename+line number 22:06
dalek kudo/nom: 839e523 | lizmat++ | src/core/Shaped1Array.pm:
Make Shaped1Array use IntRangeIterator

As we know its size in advance
MasterDuke chatted with timotimo a little bit about it last night
a real solution would be figuring out that information at compile time 22:07
lizmat MasterDuke: I think the only thing that is really needed
is to make "#line 1 src/core/core_prologue.pm" work
this is the syntax in Perl 5 for setting line number and file name
the core setting file already has that info in there 22:08
so, afaics, this needs to be parsed and not ignored as comments
MasterDuke lizmat: what i did is just parse m-CORE.setting looking for the last one of those before the line number the exception had, and then reporting the bit after "#line 1 " and making the line number = given line number - offset 22:10
so what's output is something like: ... in method floor at src/core/Rational.pm line 53 ... 22:11
so yeah, i'm trying to figure out how to find/store that info when compiling the setting 22:12
lizmat in Perl6/Grammar.nqp, look for $?FILES ? 22:14
a year ago I also looked at this... didn't get very far :-( 22:15
MasterDuke uh oh, that doesn't sound promising. do you remember what was the sticking point? 22:18
lizmat not at the moment :-(
seen a lot of code since :-(
MasterDuke well, i'll keep poking around for a little while longer at least 22:19
lizmat please do :-) I would really like to see it as well!
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Remove now unused role MatchIterator' 22:22
travis-ci.org/rakudo/rakudo/builds/172112674 github.com/rakudo/rakudo/compare/d...534bb4c586
buggable [travis build above] ✓ All failures are due to timeout (1), missing build log (0), or GitHub connectivity (0). All failures are on JVM only.
lizmat good night, #perl6-dev! 22:41
timotimo gnite lizmat 22:42
i don't think we still need to add a nqp::time_n to the end of the alt_nfa_* names 22:46
the string heap of the core setting seems to contain at least a thousand stringified numbers 22:51
pmurias the TODO comment in src/Perl6/World.pm:3120 is no longer needed?
yoleaux2 14 Oct 2016 02:17Z <MasterDuke> pmurias: you seem to know a bit about the JVM implementation, any suggestions for how to tackle the BOOTSTRAPATTR -> Attribute problem i've been working on?
timotimo no clue, pmurias :( 22:52
pmurias MasterDuke: have you solved your problem? 22:53
timotimo: looking at git history there seems to have been a moar specific if
timotimo ah
pmurias MasterDuke: sorry for not noticing the msg
timotimo turns out we do require that nqp::time_n to be concatenated there
it seems like there's really about 10000 stringified numbers in the thing 22:54
probably keys to some hash that has numbered things as keys in it? 22:55
pmurias slightly crazy side project: make MoarVM support WebAssembly 23:02
s/side project/project/ 23:03
then we could compile Perl 6 modules with inline C into MoarVM bytecode (with webassembly mixed in) 23:07
MasterDuke .tell pmurias kind of. i think all the ones that are left also fail on moar. i'd like to get some more of them eventually, so i'll ping you again if i run into jmv problems 23:33
yoleaux2 MasterDuke: I'll pass your message to pmurias.
timotimo gist.github.com/timo/63b1ff332bec2...895c579e03 23:34
i'm not sure if there's anything to gain in NQPArray's serialization 23:35
impressive how many container descriptors are still there 23:43
oh, that may be because i didn't actually land the cache for those 23:44
because it was still causing problems in the spec tests :(
parameter also has a lot more fields than ContainerDescriptor does 23:49
i'm afraid they aren't really sharable :\

Powered by Cro and the Raku® Programming Language.

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

Thank you!