MasterDuke | moritz: i definitely typed out my message and then went back and double checked before hitting enter, seemed like a good possibility for egg on the face | 00:12 | |
if i add an attribute to Perl6::World, how would i access that from the rest of the settings? | 02:03 | ||
timotimo | what do you mean by "the settings"? | 03:49 | |
MasterDuke | m-CORE.setting | ||
timotimo | the world is purely a compile-time construct | 03:50 | |
the code inside the core setting is partially run at compile time (when there's BEGIN blocks, or constants), but mostly run-time code | |||
MasterDuke | so i want to create a data structure at compile time that's available at run time | 03:51 | |
timotimo | how would you like to access it? | 03:52 | |
is this about getting per-piece filenames/line numbers? | |||
MasterDuke | exactly | ||
so i probably want it somewhere in Exception.pm and/or Backtrace.pm and/or CallFrame.pm | 03:53 | ||
timotimo | there's multiple ways to go about this. i suggest you have a look at Actions.nqp where "special symbols" are handled | ||
gimme a sec | |||
hmm | 03:54 | ||
MasterDuke | like the stuff happening around line 3150? | 03:55 | |
gfldex | RT129787 could do with a [CONC] tag | 03:56 | |
timotimo | what file are you looking at? | ||
MasterDuke | Actions.nqp | 03:57 | |
timotimo | i don't think so? | ||
here's an idea | 03:58 | ||
keep your datastructure around in an attribute, make a rule in the grammar that'll let you return the datastructure when a given very special name is invoked, and ther just compile it as QAST::WVal.new( :value( $!datastructure )) | 03:59 | ||
MasterDuke | gfldex: done | ||
timotimo | perhaps you'll want to put a QAST::Op.new( :op<clone>, ... ) around its o you can't change the data from one place | ||
(though clone is only one level deep) | |||
MasterDuke | hmmm...i already have a token that looks for '#line 1 ' and captures what comes next... | 04:01 | |
timotimo | 045611 gfldex ā RT129787 could do with a [CONC] tag | ||
whoops :D | |||
045611 gfldex ā RT129787 could do with a [CONC] tag | 04:02 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=129787 | ||
timotimo | good | ||
MasterDuke | where would that attribute live? | ||
timotimo | it can live inside World | ||
MasterDuke | i think i know how to do that. but don't know how to get to it from an Exception at runtime | 04:03 | |
timotimo | EZ | ||
add a rule to the grammar like token get_filenumbers_thingie { '$?GET_MASTERDUKES_FANTASTIC_DATASTRUCTURE' } | 04:04 | ||
the actions will look like make QAST::WVal.new( :value($*W.filenumbers_accessor_method) ) | |||
filenumbers_accessor_method will just return the attribute | 04:05 | ||
when the compiler sees that WVal node, it'll put your datastructure into the serialized blob and you'll get its value where $?GET_..._DATASTRUCTURE was in the code | |||
MasterDuke | ahhh...i think i'm following that | 04:06 | |
timotimo | it's really fantastic how easy this is | ||
there's another piece in the compiler that has a proto sub in one line, a WVal in the next and an QAST::Op.new( :op<call>, ... ) around it | 04:07 | ||
so it's putting a piece of code from inside the compiler itself into the serialized blob of our target and compiles a call to it | |||
MasterDuke | reminds me of the "Reflections on Trusting Trust" paper | 04:08 | |
timotimo | i don't think i've heard of that | 04:09 | |
MasterDuke | pretty famous, by Ken Thompson | 04:10 | |
www.ece.cmu.edu/~ganger/712.fall02...ompson.pdf | 04:11 | ||
timotimo | i'm already reading it :) | 04:14 | |
it seems to be about quines? | |||
oh, it's *this* paper | |||
dalek | p: 97e20d8 | MasterDuke17++ | src/vm/moar/QAST/QASTOperationsMAST.nqp: Remove some unused variables+accessor methods See irclog.perlgeek.de/perl6-dev/2016-...i_13495026 and irclog.perlgeek.de/perl6-dev/2016-...i_13496388 |
07:39 | |
p: 81a85b9 | niner++ | src/vm/moar/QAST/QASTOperationsMAST.nqp: Merge pull request #317 from MasterDuke17/master Remove some unused variables+accessor methods |
|||
|Tux| | This is Rakudo version 2016.10-144-ga1347ca built on MoarVM version 2016.10-35-gec45ae2 | 08:51 | |
csv-ip5xs 3.138 | |||
test 13.917 | |||
test-t 6.781 | |||
csv-parser 14.866 | |||
lizmat | Files=1151, Tests=53707, 212 wallclock secs (12.66 usr 3.44 sys + 1302.53 cusr 115.74 csys = 1434.37 CPU) | 09:11 | |
m: my @a[1,1] = (42,),(666,) # jnthn, this feels like an off-by-one error ? | 10:46 | ||
camelia | rakudo-moar a1347c: OUTPUTĀ«Index 1 for dimension 1 out of range (must be 0..0)ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
lizmat | ah no, duh, should wake up first :-) | ||
dalek | kudo/nom: 84455f3 | jnthn++ | t/04-nativecall/20-concurrent. (2 files): Test using NativeCall from multiple threads. This was already fixed a while ago, but not test was added. |
||
jnthn | :) | 10:47 | |
lizmat | m: my @a[1,1] = (42,) # this *is* strange, no/ | ||
camelia | rakudo-moar a1347c: OUTPUTĀ«Assignment to array with shape 1 1 must provide structured dataā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
lizmat | ? | ||
jnthn | m: my @a[1,1] = ((42,),) | 10:50 | |
camelia | ( no output ) | ||
jnthn | Needs to be that | 10:51 | |
If you want to "pour" data into a shaped array then | |||
lizmat | hmmm... | ||
guess so :-) | |||
jnthn | m: my @a[1,1] Z= 42; say @a | ||
camelia | rakudo-moar 84455f: OUTPUTĀ«[[42]]ā¤Ā» | ||
lizmat | .oO( more tea is needed ) |
||
jnthn | :) | ||
jnthn is looking into RT #129994 | |||
In no small part 'cus somebody also mailed me a while ago about the same problem (or what I suspect is the same problem) and I forgot about it... | 10:52 | ||
gfldex | jnthn: you need to hurry, they are catching up! :-> blog.nightly.mozilla.org/2016/11/0...n-firefox/ | 11:19 | |
jnthn | Yeah, but in Perl 6 we don't need no stinking await ;-) | 11:21 | |
argh | |||
Yeah, but in Perl 6 we don't need no stinking async ;-) | 11:22 | ||
(We only need the await bit, which means you don't have to refactor your whole callstack) | |||
It's async/await is very good news for JS though :) | |||
grr, I shouldn't try to write GC/nativecall patches and write here at the same time :) | |||
gfldex | jnthn: don't worry. Your code is supposed to be [CONC]. You are perfectly fine in the usual serial fashion. :) | 11:40 | |
jnthn | ;) | 11:46 | |
Yay, another conc/nativecall bug down | 11:47 | ||
dalek | p: 3a09f86 | jnthn++ | tools/build/MOAR_REVISION: Bump MOAR_REVISION for nativecall/GC fixes. |
11:48 | |
gfldex | jnthn: HTTP::Server::Threaded segfaults reliablely on my end | 11:49 | |
jnthn: that's with a 1h old Rakudo | 11:50 | ||
dalek | kudo/nom: f99d958 | jnthn++ | tools/build/NQP_REVISION: Bump for MoarVM with nativecall/GC fixes. With this fix, we make sure to GC-block the current thread before we make a nativecall, and unblock it afterwards (taking care with the handling of callbacks). This fixes an issue where calling a long running bit of native code on one thread could make the others all hang at the next GC until the native code completed. |
11:51 | |
kudo/nom: 5ba75f4 | jnthn++ | t/04-nativecall/20-concurrent.t: Test native call on one thread won't block others. |
|||
jnthn | gfldex: If that ain't RT'd, please do so | 11:55 | |
Lunch; bbiab | 11:56 | ||
dalek | kudo/nom: 8064ff1 | lizmat++ | src/core/Shaped1Array.pm: Make @a[10].STORE at least as fast as @a.STORE In practice, this makes my @a[10] = ^10 about 7x faster. Most of the overhead is still in my @a[10] though. |
11:58 | |
gfldex | jnthn: that segfault seamed not CONC related after all. It had a Supply where it needed a Supplier but didn't produce the correct error message with the first test. | 12:06 | |
MasterDuke | i have added a method to Perl6::World in World.nqp, but why i try to call it in Actions.nqp i get "Cannot find method '<my_method>' on object of type Perl6::World" | 12:14 | |
oh ha, nm. i added it to Perl6CompilationContext | 12:15 | ||
pebkac | |||
gfldex | jnthn: the segfaults are gone after some patching but pretty much all tests hang now. The test look OK to me. Could you have a look? (depends on pending PR github.com/tony-o/perl6-http-serve...ed/pull/4) | 12:17 | |
travis-ci | Rakudo build failed. Jonathan Worthington 'Test native call on one thread won't block others.' | 12:34 | |
travis-ci.org/rakudo/rakudo/builds/172584833 github.com/rakudo/rakudo/compare/8...a75f445dc7 | |||
buggable | [travis build above] ā Did not recognize some failures. Check results manually. All failures are on JVM only. | ||
moritz | buggable++ | ||
lizmat | m: my @a[42;666]; say @a.elems # is .elems on shaped arrays supposed to give the elems in the first dimension, jnthn ? | 12:59 | |
camelia | rakudo-moar 8064ff: OUTPUTĀ«42ā¤Ā» | ||
lizmat | or is that an artefact ? | 13:00 | |
timotimo | i think it's supposed to behave like a one-dimensional array of arrays with some things | 13:02 | |
lizmat | or a bug? I sorta expected to see 42*666 as the number of elems | ||
timotimo | but .values.elems should probably give you the product | ||
lizmat | well, it better :-) | ||
otherwise .values wouldn't produce all the values :-) | |||
well, I can live with either behaviour, just would be different optimizations :-) | 13:05 | ||
dalek | kudo/nom: 8c3e57d | lizmat++ | src/core/Shaped1Array.pm: Go straight to the source for @a[10].elems |
13:07 | |
ilmari | github.com/a must be thrilled with all the mentions he's getting in these commits ;) | 13:15 | |
lizmat | :-) | ||
jnthn | lizmat: .elems should give the number of elements in the first dimension, which is what it appears to be doing. | 13:25 | |
lizmat | ok | 13:26 | |
jnthn | So that once we have partial views, @a[*] can work (since it uses @a.elems) | ||
lizmat | just checking... | ||
jnthn | :) | ||
lizmat | also, is it intentional that $!shape is a List rather than an nqp::list ? | 13:27 | |
jnthn | Can't remember which way it is, but either way works I think | 13:31 | |
lizmat | It's List now | 13:32 | |
jnthn | I think that's fine | ||
Since .shape has to return a List anyway | |||
So we'd only have to wrap it every single time in that case | |||
And that's far more expensive that dereferencing | |||
And range checks don't use it directly anyway; the REPR itself does those. | |||
lizmat | true, but in the core we could use $!shape directly | ||
jnthn | Sure, we can now, just nqp::getattr on it :) | ||
That's a really cheap op after optimization | 13:33 | ||
lizmat | the fact that each shaped array keeps another List inside of it doesn't bother you ? | ||
jnthn | Not particularly | ||
lizmat | it does me :-) | 13:34 | |
jnthn | Unless your shaped array is tiny it's not a great deal of overhead...and won't the List be shared between instances of the same shape anyway? | ||
So your plan is that .shape causes memory allocation every time, thus causing even more memory pressure? :P | |||
lizmat | eh, I don't think the shape is shared between incarnations of the same shape, atm | ||
jnthn | Hm | 13:35 | |
I thought in @a[2;2] we might have a List (2,2) constant-folded and passed in as the shape arg each construction | |||
lizmat | if it would be shared, I wouldn't worry so much about it | ||
jnthn | If that isn't happening that's perhaps the thing to do | ||
[Coke] | Hey, all my non US dev buddies, can I get some vague assurances that the US will be fine when I wake up next Wednesday? Thanks. :P | ||
lizmat | ok, will look at that | ||
timotimo | voting is coming up? | 13:36 | |
jnthn | (I kinda thought it already was, but it's been a while.) | ||
lizmat assures [Coke] that all will be well | |||
timotimo | yeah, it ain't so bad | ||
lizmat promised [Coke] that all will be well | |||
*promises | |||
jnthn | [Coke]: It's possible that brexit used up all the stupid for 2016, and that it's now out of stock until 2017... ;-) | ||
moritz always presumed that there's an infinite supply of stupid | 13:37 | ||
jnthn crosses fingers :) | |||
moritz: Well, darn. :P | |||
[Coke] | moritz: not helping! :) | ||
moritz | [Coke]: anyway, we have cookies in Europe too, electricity, and developer jobs | 13:38 | |
arnsholt | moritz: Not to mention vacation days =) | ||
moritz | right; I have 30, plus public holidays. Health insurance included | 13:39 | |
arnsholt | (And in Norway a legal obligation to take a minimum of vacation) | ||
moritz | Norway++ | 13:40 | |
jnthn | Legal obligation to take vacation? That's great. :D | ||
gfldex | Technically we got the same in Germany but it's not enforced. | 13:41 | |
moritz | though at $work here, even team and departments leads take 3 weeks of consecutive vacation | ||
I don't know if our CEO does, but he's also (partial) owner of the business, so nobody bothers him | 13:42 | ||
[Coke] | I am lucky enough to have the "take all the vacation you can get away with" policy. | ||
moritz | [Coke]: how many days is that, on average, per year? | 13:43 | |
[Coke] | 0? :) | 13:44 | |
jnthn didn't use many vacation days this year, but is looking forward to some good time off around Christmas/New Year :) | |||
lizmat | jnthn: when setting up a shaped array like @a[10], 1/3 of CPU is spent in mixing in the role | 13:45 | |
with set-shape at 15%, does at 9% and mixin at 8% | |||
jnthn | lizmat: How many arrays did you make? | 13:47 | |
lizmat | 10K | ||
for ^10000 { my @a[10] } | |||
jnthn | Umm...and why can't I find the shape handling code in Array... | 13:48 | |
lizmat | it lives in src/core/ShapedArray nowadays | ||
and Shaped1Array/Shaped2Array/Shape3Array | |||
jnthn | Wait, doesn't that expose it? | 13:49 | |
lizmat | no, it's still part of the Array class | ||
jnthn | Rather than it being lexically scoped inside of Array? | ||
lizmat | it's still lexically scoped in Array | ||
jnthn | Doesn't look like it to me? | ||
lizmat | say ShapedArray | ||
m: say ShapedArray | |||
camelia | rakudo-moar 8c3e57: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Undeclared name:ā¤ ShapedArray used at line 1ā¤ā¤Ā» | ||
lizmat | Array.pm only has an opening curly | ||
jnthn | oh...damn | 13:50 | |
o.O | |||
The things people consider improvements sometimes surprise me :P | |||
lizmat | sorry, but that file was getting *way* too big | ||
jnthn | The things people consider problems sometimes surprise me :P | ||
But OK, if it made it easier for you to work on... :) | |||
lizmat | yes, very much so | ||
I mean, when I started working on this, 1 dim shaped arrays were like 15x slower than normal arrays | 13:51 | ||
they're almost on par now | |||
jnthn | OK, finally found the bit of the code I was looking for :) | 13:52 | |
lizmat | which is ? | ||
jnthn | set-shape | ||
And yeah, SHAPED-ARRAY-STORAGE is what I was thinking about | 13:53 | ||
(It interns types) | |||
Thing is, mixin types are also interned | 13:54 | ||
So I guess it's already saving some amount of time | |||
We may be able to re-shuffle things to just create the correct type in the first place and avoid the does | |||
lizmat | so, how many times should infix:<does> be called for "for ^10000 { my @a[10] }" ? | 13:55 | |
1 or 10000 ? | |||
jnthn | Well, at the moment it'll be 10000 | ||
But it won't actually go through the whole role composition process every time, I don't think | |||
mixin will hit a cache | |||
Can verify that by a --profile I guess | |||
lizmat | mixin is also called 10K times | 13:56 | |
jnthn | Yes, but I belive mixin is what looks in the cache | ||
You might be a speedup calling mixin directly rather than going via does | |||
*get | |||
lizmat | ok | 13:57 | |
jnthn | But alternative would be avoiding that altogether | ||
And figure out what shaped type we want up front | |||
lizmat | especially if the dimension list contains int constants only | ||
jnthn | That is, obtain Array but Shaped1Array[Mu] | ||
(which doesn't cause a deopt) | |||
And then nqp::create that | 13:58 | ||
lizmat | obtain ? | ||
jnthn | Obtain as it "just do that" :) | ||
When you mix in to a type object, it doesn't really mix in, it just gives back a type object | 13:59 | ||
And if you make an instance of that, you can avoid the whole mixing in process | |||
.^mixin is slow in part because it is a global deopt | |||
So it de-optimizes the whole callstack | |||
So even your for ^10000 { } loop will run slower | |||
travis-ci | Rakudo build failed. Elizabeth Mattijsen 'Go straight to the source for @a[10].elems' | 14:00 | |
travis-ci.org/rakudo/rakudo/builds/172602457 github.com/rakudo/rakudo/compare/8...3e57d77e90 | |||
buggable | [travis build above] ā Did not recognize some failures. Check results manually. | ||
lizmat | ah, so say something lilke: my $dim1 := Array but Shaped1Array(Mu); then nqp::create($dim1) ? | ||
with the $dim1 living as a lexical in Array class ? | |||
viki | t/04-nativecall/20-concurrent.t .......... Dubious, test returned 255 (wstat 65280, 0xff00) | 14:01 | |
(travis above; one failure) | |||
jnthn | Nice, and the output provides no clue at all why | 14:02 | |
lizmat: Something like that, though not sure it's worth interning them further than but does | 14:03 | ||
lizmat: Could try it though | 14:04 | ||
lizmat | will do, after some break and fresh air :-) | ||
afk& | |||
gfldex | my \IOL = Lock.new; &say.wrap( -> |c { IOL.protect: { callwith |c } }); for ^100 { say "oops" } | 15:31 | |
does callwith refer to the innermost block in this case? | |||
jnthn | It's dynamically scoped | 15:32 | |
So it'll be talking about the dispatcher of the nested block | |||
Not the wrapping block | |||
m: nextcallee | |||
camelia | rakudo-moar 8c3e57: OUTPUTĀ«nextsame is not in the dynamic scope of a dispatcherā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
jnthn | I think your best bet is to use that to get it in the outer block | 15:33 | |
So, at the moment when you await or .result a Promise that gets broken, the error reproting is a bit suck | 15:35 | ||
Because you get the message of the exception, but only the backtrace of where you called .result | |||
I just made it look this way: | |||
gist.github.com/jnthn/d03966f24159...f030c2c4df | |||
Any wording tweaks desired? | |||
(Note this is done by mixing in to the original exception type, and so when X::Foo { } matchers will continue to work as before) | 15:36 | ||
gfldex | m: my \IOL = Lock.new; &say.wrap( -> |c { IOL.protect: { nextcallee.callwith |c } }); for ^100 { say "oops" } | 15:40 | |
camelia | ( no output ) | ||
jnthn | no, the idea was to use nextcallee int he closure actually doing the wrapping | 15:45 | |
m: use soft; my \IOL = Lock.new; &say.wrap( -> |c { my &wrappee = nextcallee; IOL.protect: { &wrappee(|c) } }); for ^100 { say "oops" } | 15:47 | ||
camelia | rakudo-moar 8c3e57: OUTPUTĀ«oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¤oopsā¦Ā» | ||
gfldex | m: my \IOL = Lock.new; &say.wrap( -> |c { my &wrappee = nextalleee; IOL.protect: { wrappee.callwith |c } }); for ^100 { say "oops" } | ||
camelia | rakudo-moar 8c3e57: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Undeclared routine:ā¤ nextalleee used at line 1. Did you mean 'nextcallee'?ā¤ā¤Ā» | ||
gfldex | also ENODOC | ||
jnthn notes that IO handles do locking down at the VM level | 15:49 | ||
gfldex | ENODOC-- | 15:58 | |
dalek | kudo/nom: abf6caf | jnthn++ | src/core/Promise.pm: Improve error reporting around broken promises. Previously, we had the message of the original exception, together with the backtrace of the await or .result call. Now, we: * Clearly indicate that the exception was raised by obtaining the result of a broken Promise * Provide the location that this happened * Provide the original exception's message * Provide the backtrace of the original exception |
15:59 | |
moritz | jnthn++ | 16:00 | |
makes me want to reconsider my choice to use 2016.10 for the book :-) | 16:01 | ||
dalek | ast: 2972719 | jnthn++ | S17-promise/start.t: Test to cover RT #125782. |
||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125782 | ||
jnthn | Yes, that one is a rather nice usability improvement. | 16:06 | |
dalek | ast: c3b28cc | jnthn++ | S17-channel/stress.t: Test for RT #127960. |
16:32 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127960 | ||
pmurias | nqp::copy behaves differently on moar and jvm | 16:35 | |
yoleaux2 | 31 Oct 2016 23:33Z <MasterDuke> 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 | ||
dalek | ast: d573ecb | jnthn++ | S17-supply/watch-path.t: Remove a warning due to a bogus unused string. |
||
viki | m: my $a = (:10a).Bag; my $b = (:42a).Bag; say $a (^) $b eqv ($a ā $b) āŖ ($b ā $a) | ||
camelia | rakudo-moar abf6ca: OUTPUTĀ«Falseā¤Ā» | ||
pmurias | nqp::copy behaves differently on moar and jvm | 16:36 | |
when given a symlink as the target it follows on the moar and overwrites on the jvm | 16:37 | ||
viki | m: my $a = (:10a).Bag; my $b = (:42a).Bag; say ($a ā $b) āŖ ($b ā $a) | 16:46 | |
camelia | rakudo-moar abf6ca: OUTPUTĀ«set(a)ā¤Ā» | ||
viki | m: my $a = (:42a).Bag; my $b = (:10a).Bag; say ($a ā $b) āŖ ($b ā $a) | ||
camelia | rakudo-moar abf6ca: OUTPUTĀ«bag(a(32))ā¤Ā» | ||
dalek | p: b07c356 | (Pawel Murias)++ | src/vm/js/ (2 files): [js] Implement stuff needed to get test 19 to pass again. Make nqp::unlink fail quietly when it's target doesn't exit. |
16:54 | |
viki | m: my $a = (:a).Set; dd $a.Bag | 17:03 | |
camelia | rakudo-moar abf6ca: OUTPUTĀ«("a"=>1).Bagā¤Ā» | ||
viki | m: my $a = (:a).Set; dd $a.Mix | ||
camelia | rakudo-moar abf6ca: OUTPUTĀ«("a"=>True).Mixā¤Ā» | ||
TimToady | Hotkeys: the main reason there's a .sum but not a .product is that we wanted an optimization target for [+] 1..1000000000000000 | 17:20 | |
and we just decided to make it user-visible | |||
viki | TimToady: FWIW, there's a proposal for how (^) operator should behave with Sets/Bags/Mixes, if you wanted to weigh in: github.com/rakudo/rakudo/pull/911 | 17:23 | |
TimToady | I very much like that the set behavior is a degenerate case of the bag behavior; what I do not like is any approach that autocoerces bags or mixes to sets, which is pretty non-sensical, so I think such coercions should explicitly pull out the keys and make a set, if that's really what is wanted, and fail otherwise | 17:33 | |
FROGGS | o/ | 17:35 | |
viki is getting a bunch of stresstest failures for various reasons | 18:31 | ||
dalek | ast: 91c57c3 | (Zoffix Znet)++ | S17-procasync/stress.t: Test::Util needs t/spec/packages in the use lib |
18:33 | |
viki | t/spec/S17-supply/return-in-tap.t says "getexpayload needs a VMException" | 18:34 | |
Full output: gist.github.com/zoffixznet/0c4b4e8...2077c92cd7 | |||
dalek | kudo/nom: cdb3699 | lizmat++ | src/core/Shaped (2 files): All shaped arrays share the same .elems logic |
18:35 | |
jnthn | viki: On Rakudo HEAD? | 18:36 | |
viki | jnthn: yeah | ||
jnthn | viki: (Which implies NQP HEAD and MoarVM HEAD) | ||
timotimo | i, for one, am glad that shaped arrays are getting a bit of a performance pass | ||
viki | jnthn: oh, no, rakudo HEAD and the rest is whatever the specificied bumps are | 18:37 | |
jnthn | Are you sure? That error message is notable in being what that test would give before github.com/MoarVM/MoarVM/commit/a4...bb3e0bebe8 | ||
lizmat | timotimo: glad to hear that | ||
viki | This is Rakudo version 2016.10-150-gabf6caf built on MoarVM version 2016.10-15-g715e39a | ||
jnthn | $ ./moar --version | 18:38 | |
This is MoarVM version 2016.10-37-gf769569 built with JIT support | |||
viki | I guess bumpage is needed | ||
jnthn | $ cat tools/build/MOAR_REVISION | 18:39 | |
2016.10-37-gf769569 | |||
(in NQP) | |||
$ git describe | |||
2016.10-43-g3a09f86 | |||
(also in NQP) | |||
And that's what's in NQP_REVISION | |||
So it *looks* like I did the bumps right | 18:40 | ||
viki | OK. Located the issue. I ran make install only instead of the full thing | ||
jnthn | oh :) | ||
viki | Sorry :) | ||
jnthn | np | ||
Glad the failure mode you pasted was an easily recognizable one :) | 18:41 | ||
viki | ZOFVM: Files=1200, Tests=130118, 171 wallclock secs (20.93 usr 3.29 sys + 3086.64 cusr 296.65 csys = 3407.51 CPU) | 18:53 | |
lizmat | m: role A { multi method a() {"one"}; multi method a() {"two"} }; say A.a # this feels like it should complain somehow | 18:54 | |
camelia | rakudo-moar cdb369: OUTPUTĀ«oneā¤Ā» | ||
timotimo | yeah, it should | 18:55 | |
dalek | kudo/nom: 78ef944 | lizmat++ | src/core/ShapedArray.pm: How did two identical methods get in here??? |
||
kudo/nom: 7ba7eb4 | (Zoffix Znet)++ | src/core/Setty.pm: Add specific .Mix and .MixHash coercers to Setty ...just like we have ones for Bag(Hash). Otherwise, a set coerced to a Mix has Bools for weights instead of Ints |
|||
ast: ccc9301 | (Zoffix Znet)++ | S02-types/set.t: Set.Mix/.MixHash does not produce Bool weights |
18:56 | ||
kudo/nom: 28e11c4 | lizmat++ | / (7 files): Move set-shape logic to new ShapeNArray.pm - also close class Array in TypedArray.pm - no need to stub Shaped123Array roles Really preliminary work for more optimizations |
19:16 | ||
kudo/nom: d036a50 | lizmat++ | src/core/Shaped (5 files): Add some comments indicating part of Array class |
19:19 | ||
kudo/nom: 5d1b2c3 | lizmat++ | src/core/ShapedArray.pm: Fix type in comment, MasterDuke17++ |
19:22 | ||
[Coke] | *typo | 19:24 | |
:) | |||
viki | meta-typo | 19:26 | |
[Coke] | meat type | 19:27 | |
lizmat | .oO( once you start... ) |
19:30 | |
masak | ...it's hrad to sotp | 19:31 | |
lizmat | m: my Int @a; @a.BIND-POS(0,42) # seems I missed one place handling completely empty lists | 19:45 | |
camelia | rakudo-moar 5d1b2c: OUTPUTĀ«This type (Scalar) does not support positional operationsā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
dalek | kudo/nom: 0bbe98d | lizmat++ | src/core/TypedArray.pm: Make sure BIND-POS works the same on typed arrays |
20:12 | |
bartolin | pmurias: sorry for making 019-file-ops.t fail for nqp-js. what do I need only node.js to be able to build nqp-js? (I've just read github.com/perl6/nqp/#javascript-backend ) | 20:20 | |
s/what// | 20:21 | ||
[Coke] | hurm. rakudo's js branch's Configure.pl mentions a js backend, but then dies with: sh: gen/js/Makefile-JS.in: No such file or directory | 20:28 | |
dalek | kudo/nom: ebcc33e | (Carl Masak)++ | tools/build/create-moar-runner.pl: fix typo |
20:44 | |
lizmat | jnthn: was there a specific reason to keep "int" and Int:D candidates for AT-POS and friends around> | 20:50 | |
? | |||
it appears that removing the "int" candidate at the moment improves performance for calls with native ints | 20:51 | ||
nine | That's quite counter intuitive | 21:01 | |
timotimo | not if you know that native ints make our static optimizer unhappy | 21:02 | |
(the fix for that seems to require jnthn. or at least something more than timo) | |||
lizmat | well, the way I see it, is that I remove all of the "int" candidates now | 21:03 | |
and then when we have "int" grokked by the optimizer, change the "Int:D" to "int" in the sigs | |||
m: sub a(int $a) { dd $a }; a my Int $ = 42 # cause this works | 21:05 | ||
camelia | rakudo-moar ebcc33: OUTPUTĀ«42ā¤Ā» | ||
timotimo | well, that probably unboxes | 21:06 | |
lizmat | yup | 21:08 | |
so, when the optimizer groks int, we can simply change the sig from Int:D to int | 21:09 | ||
the Ints will be unboxed automagically | |||
and potentially be unboxed during optimization time already | |||
travis-ci | Rakudo build errored. Elizabeth Mattijsen 'All shaped arrays share the same .elems logic' | 21:16 | |
travis-ci.org/rakudo/rakudo/builds/172716018 github.com/rakudo/rakudo/compare/a...b369903f3a | |||
buggable | [travis build above] ā Did not recognize some failures. Check results manually. | ||
jnthn | Uh, you can't remove the Int candidate and expect the multi-dispatcher to send an Int to an int candidate | 21:28 | |
lizmat | no? | ||
jnthn | No | 21:29 | |
lizmat | :-( | ||
timotimo | Int can asplode when it doesn't fit into an int | ||
jnthn | Right | ||
Also int is tighter than Int | |||
So if int candidates accepted Int then you'd never dispatch to an Int candidate even when you did have a big integer | 21:30 | ||
I'd leave the int candidates int, especially for native shaped arrays | |||
lizmat | ok | ||
jnthn | Just because we don't always generate the code I'd like us to for these things now doesn't mean we won't in the future. | 21:31 | |
lizmat | it's just a significant maint burden atm | ||
ok | |||
but, re AT-POS(Int:D) taking int values larger than what an int can hold | |||
do we foresee supporting arrays with more than 2**64 elements ? | 21:32 | ||
jnthn | No, I'm talking about the multi-dispatcher in general | ||
lizmat | ok | 21:33 | |
jnthn | Of course, it's possible we'll also end up clever enough to get away with the Int:D candidates and stripping out the boxing... | ||
But that feels like it'll need another level of clever than just getting the code-gen to them straightened out | |||
lizmat | the thing is, I'm adding quite a lot of code atm | 21:34 | |
and compile times are going > 60 seconds for me | 21:35 | ||
and it looks like bare startup time isn't getting lower :-( | |||
perhaps I should look at gen-cat.nqp autogenerating the "int" candidates | 21:37 | ||
argh, but then line number referrals :-( | |||
ok, back to adding int / Int:D candidates all the time | 21:41 | ||
jnthn: getting back to the difference between for ^10000 { my @a } and for ^10000 { my @a[10] } | 21:42 | ||
in the former case, Array.new is never called: it looks like a Array object is created at compile time, and then cloned during each iteration. | 21:43 | ||
is there a reason to not do the same for shaped arrays if the shape list consists of constant values | |||
? | |||
aka, create the object, and then clone it during execution? | 21:44 | ||
I guess it would have to be a HLL .clone | |||
jnthn | For the "usual" case we just clone the P6opaque, yeah, but it's a shallow clone | 21:54 | |
And it happens relatively low-level too | |||
lizmat | well, I've just added a .clone to ShapedArray | 21:56 | |
my @a[10]; for ^10000 { my @b := @a.clone } | |||
is 60x faster than | 21:57 | ||
for ^10000 { my @a[10] } | |||
jnthn | Does it clone the storage too? | ||
lizmat | yes | ||
gist.github.com/lizmat/a087f82975d...8438ce5fc1 | |||
jnthn | May be worth looking into if we can do it that way, then :) | ||
Ohh... | 21:58 | ||
But you can't do it for dynamic sizes | |||
lizmat | indeed | ||
jnthn | Which is why it's code-gen'd the way it is now | ||
lizmat | indeed... so we need to check if it's a constant, then code gen it with a .clone | ||
jnthn | (Doesn't mean we can't do better on the static sizes) | ||
lizmat | otherwise, well, we have to do it the cirrent way | ||
indeed | |||
jnthn | Aye. I was largely in "make it work" mode when I put this stuff in :) | ||
lizmat | I know | 21:59 | |
:-) | |||
I'm in "making it work faster" mode now :-) | |||
jnthn | \o/ | 22:01 | |
lizmat++ | |||
Will be nice when I get optimization tuits again | 22:02 | ||
But should really get a bunch of our concurrency issues cleared up | |||
Well, a bunch more :) | |||
Trouble is, the more I fix, the better the remaining ones are at hiding. | |||
lizmat | yeah, I know :-( | 22:03 | |
jnthn wanders off to rest | 22:09 | ||
lizmat | jnthn: one quick question | 22:10 | |
is it | |||
ok to have shaped arrays carry around a $!todo even though it gets never set ? | |||
dalek | kudo/nom: 40429f3 | lizmat++ | src/core/ShapedArray.pm: Give shaped arrays its own fast .clone To be hopefully used later to quickly initialize shaped arrays in loops. |
22:12 | |
lizmat also goes off for some shuteye | 22:13 | ||
MasterDuke | jnthn: reading the backlog, i thought lizmat was asking about removing the 'int' candidates (and just having 'Int'), but you said removing 'Int' (and just having 'int') was bad? | 22:27 | |
timotimo | yeah, only having int is bad | 22:29 | |
what do you do with 2 ** 70 then? | 22:30 | ||
MasterDuke | well yeah, but is it bad to only have Int, when those are faster than int anyway? | 22:57 | |
dalek | kudo/nom: c59ab18 | raiph++ | src/core/Str.pm: Fix off by one errors in Failure messages |
23:27 | |
kudo/nom: 88cb05e | (Zoffix Znet)++ | src/core/Str.pm: Merge pull request #912 from raiph/patch-1 Fix off by one errors in Failure messages |