| 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 |