Zoffix | Someone familiar with GLR and for loops, please advise how to proceed with rt.perl.org/Ticket/Display.html?id=124568 It's about whether this test should be removed now: github.com/perl6/roast/blob/ab7476...for.t#L473 | 00:50 | |
What do we do with tickets like this one? rt.perl.org/Ticket/Display.html?id=123577 | 02:05 | ||
I mean. Large proposals that don't gather any comments on the ticket? | 02:06 | ||
gfldex | the role part could warn depending on use warn-multiple-inheritance. The first part would require AI. | 02:09 | |
Zoffix | AI? 0.o | 02:10 | |
gfldex | to actually solve it rakudo would need to understand each and any where clause | ||
Zoffix | Well, it can just bail out and call it ambiguous. Though, of course, that would severely limit the usefulness of subtypes | 02:11 | |
gfldex | and how would it know that the where clause part is ambiguous? | 02:12 | |
geekosaur | I think the suggestionis "if it has a where clause, it is ambiguous" | ||
Zoffix | It wouldn't. It'd just call ambiguousness if it sees same ... yeah, that | ||
But that's crap :) | 02:13 | ||
gfldex | as long as a basic type is used, one could write a module that uses aproximation to find some ambiguous where clauses | 02:14 | |
i fixed the CSS fallout from my Pod::To:HTML changes | |||
i will care about the JS stuff tomorrow | |||
Zoffix | gfldex++ | 02:15 | |
gfldex | i put the ToC into a table. It's a good bit narrower and and less nervous. If we want to move it side by side with the main content, it will be easier to do so. | 02:17 | |
Zoffix | Table? Like <table>? | 02:18 | |
gfldex | yes | ||
Zoffix | Why? It's a list of links. tables for markup are so 1990s :) | 02:19 | |
gfldex | i don't care how old an idea is. If it gets the job done I use it. | 02:20 | |
Zoffix | gfldex, but what problem are you experiencing with a <ol>? | 02:21 | |
gfldex | also, I do know why LaTeX uses item lists for ToC. Multi page tables are a bitch. In html that's not a problem. There is no bottom of the page. | ||
Zoffix | It probably uses item lists for Toc because is a list of a items :) Tables are for tabular data. | 02:23 | |
gfldex | the problem I got with ol is that you pretty much have to use indentation for separation. I strongly dislike it when I read a ToC and have to adjust the beginning of the line for every 3rd line or so. Very nervous to read. | ||
Zoffix | How does a table solve that? | 02:24 | |
Just toss the indent add borders and it'll look exactly the same | |||
You even have display: table-* CSS properties to make any element behave and look like a proper table. | |||
I don't care much what people use, but IMO using a table for markup in 2016 is the lamest thing in web dev. | 02:25 | ||
s/markup/layout/; | |||
gfldex | if it doesn't work out, it would not be hard to change it to a ol | 02:26 | |
Zoffix | Obligatory link: www.hotdesign.com/seybold/everything.html | 02:27 | |
gfldex | why exactly 2016, why not 2015? It's an empty argument and I would prefere not to follow it further. | ||
Zoffix | I've not used it since my days in #css a decade ago :P | ||
gfldex, because a decade ago CSS was poorly supported and people used tables for layout because it was a pain in the ass to do it with CSS and have it work. Today, it works, so using semantically incorrect markup just makes zero sense | 02:28 | ||
It's like seeing a shelf with pears in the store tagged as apples. | |||
The argument isn't empty and people stopped having it a while ago :) | 02:29 | ||
If you want to use tables, use tables. Who am I to stop you. | 02:30 | ||
[Tux] | This is Rakudo version 2016.06-154-g55c359e built on MoarVM version 2016.06-9-g8fc21d5 | 06:52 | |
test 15.632 | |||
test-t 9.104 | |||
csv-parser 16.806 | |||
all in the 9.[0-2]: | 06:53 | ||
2016-06-30 15:19:35 test-t 9.171 | |||
2016-07-03 14:17:35 test-t 9.284 | |||
2016-07-03 14:38:20 test-t 9.285 | |||
2016-07-05 09:25:29 test-t 9.072 | |||
2016-07-05 09:29:59 test-t 9.146 | |||
2016-07-07 08:50:47 test-t 9.104 | |||
nine | I'll take the 2016-07-05 ;) | 07:03 | |
psch | gist.github.com/peschwa/b23c2882ff...c23fc42216 is a thing, apparently | 07:58 | |
i think what's going on there is that we just straight up don't install a handler at all | |||
and i'm not sure what kind of handler we have to put there, and how | |||
like, clearly a control handler that handles the return would be wrong, because actually wanna throw X::ControlFlow::Return | 07:59 | ||
+we | |||
hm, actually, maybe if we just don't panic() in ExceptionHandling but instead build the HLL exception there..? | 08:00 | ||
or is that the wrong layer..? :/ | 08:01 | ||
dalek | kudo/nom: 34463ec | (Zoffix Znet)++ | src/core/Exception.pm: Remove trailing whitespace |
08:16 | |
kudo/nom: 6d0cc07 | (Zoffix Znet)++ | src/core/Exception.pm: Improve error message for leading 0 on numerals. The message must avoid proposing the user uses an invalid octal number. |
|||
kudo/nom: 55605b8 | lizmat++ | src/core/Exception.pm: Merge pull request #813 from zoffixznet/LTA-octal-message Improve LTA octal message |
|||
kudo/nom: 2ff5adb | lizmat++ | src/core/Array.pm: Streamline Array.new - by adding candidates for no params, and no :shape params. |
08:23 | ||
psch | hm, i guess i have to port ef3a804d7 | 08:42 | |
so, yeah, "don't just panic in ExceptionHandling" seems to be half right | 08:54 | ||
(the commit is a moar commit, fwiw) | |||
humm, now what's the corresponding nqp commit... :S | 09:05 | ||
specifically i'm wondering if there's anything i can look at for how we put the handlers in place on moar | 09:19 | ||
...if we even do that there, which i actually don't know if we do | |||
timotimo | we just have a table for each frame where we look what we're supposed to do | 09:23 | |
hm, but that's just regular frame handlers | |||
not 100% sure how about going up the stack | 09:24 | ||
psch | right, but that's kinda the thing | 09:34 | |
the commit i mentioned above installs something that lets the hll handle a runaway lexical exception | |||
s/installs/implements/ | |||
but the hll somehow has to know about that, doesn't it? :S | |||
wait, nqp doesn't really do that, does? | 09:41 | ||
timotimo | the code gen puts the annotations in and i think that's it | ||
nqp::handle takes care of most of that | |||
psch | as in, the throwpayloadlexcaller and getextype in rakudo does it | ||
aha! BOOTSTRAP.nqp:3207 | 09:43 | ||
there's lexical_handler_not_found_error | |||
which is what moar uses to throw X::Control::Return | |||
timotimo | ah, right | 09:44 | |
moar requires a code frame to exist in order to throw an exception | 09:45 | ||
at least i think so | |||
that's why we register a callable via the hll mechanism | |||
psch | sounds reasonable to me | ||
and should also be rather portable | |||
i mean, it means i just need a check if we have that Callable in handlerLexical | |||
and if we do, call that instead of calling panic()9 | 09:46 | ||
-9 | |||
timotimo | mhm | 09:47 | |
psch | jnthn: what's behind $out_of_dyn_scope? it's not used from the looks of it..? | 10:01 | |
jnthn | psch: Yeah, it's there so (when we get around do it) we can distinguish these two: | ||
m: sub foo() { (1..10).map({ return 1 }) }; foo() | 10:02 | ||
camelia | rakudo-moar 2ff5ad: OUTPUTĀ«Attempt to return outside of any Routineā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
jnthn | From this: | ||
m: return 1 | |||
camelia | rakudo-moar 2ff5ad: OUTPUTĀ«Attempt to return outside of any Routineā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
jnthn | Which get the same error now, but the first one would be better saying something more like "you already returned from this routine" or so | ||
psch | ah, alright | ||
jnthn | The difference is that in the first case you have a handler in the lexical scope, but it's out of the dynamic scope so it's impossible to unwind to it. | ||
In the second you don't have a handler at all | 10:03 | ||
Given I did most of the hard work wiring it up, that's an easy improvement now for anybody who fancies it ;) | |||
psch | mhm, i guess it depends on whether i can see an easy way to know the distinction on the jvm :) | 10:04 | |
which, as of right now, i don't vOv | |||
but well, it'll stay around for others in the worst case :) | 10:05 | ||
actually, we have to different methods for handlers, handlerLexical and handlerDynamic. isn't that already the distinction? | 10:06 | ||
as in, if we don't find the handler in handlerDynamic we throw to lexical_handler_not_found with $out_of_dyn_scope == 1, and 0 for handlerLexical? | |||
i guess i'll se whether the .map case above still dies wrongly or not | |||
jnthn | No, I think handlerLexical maybe has a check for "is the target frame on the call stack"? | 10:14 | |
psch | well, we have skipCaller in handlerLexical | 10:15 | |
aside from that, handlerLexical and handlerDynamic are pretty much identical, except the former goes via .outer and the latter via .caller | 10:16 | ||
jnthn | Hm, interesting. I wonder how it behaves in the first of the two cases (there's a lexical return handler but it's out of dynamic scope) | 10:20 | |
psch | right, so checking for lexical_handler_not_found in handlerLexical solves the bare return case | 10:28 | |
the (1..10).map({ return }) case from earlier leaks an UnwindException | 10:29 | ||
i'm not sure it did that before, though | |||
so i'm gonna stick the hllConfig check into handlerDynamic now and see what happens :) | |||
jnthn | Yeah, I think the UnwindException measn that we ploughed ahead unwinding the stack looking for a hnadler that's not there. | 10:36 | |
psch | alright, putting a check for lexical_handler_not_found in handlerDynamic didn't help | 10:44 | |
so i'm gonna stash my changes and see if we fail the same way without the patch to handlerLexical | |||
there's a lot about this handler code that i don't quite get, so i might well be looking in the wrong spot :| | 10:45 | ||
well, it seems like the lexicalHandler change doesn't impact the leaking UnwindException | 10:58 | ||
so i'm gonna commit that, cause we have a bunch of tests in e.g. S04-statements/return.t that should pass then | |||
...yes, i'm also gonna run the tests before pushing :P | 11:00 | ||
dalek | kudo/nom: e2029cb | lizmat++ | src/core/Array.pm: Make Array.pop about 2.5x as fast - lose the "ensure-allocated" call (no longer allocate if empty) - don't fail, but return Failure objects - rewrite using nqp completely |
11:09 | |
p: f84cc8a | peschwa++ | src/vm/jvm/runtime/org/perl6/nqp/runtime/ (3 files): Add lexical_handler_not_found_error to HLLConfig. |
11:18 | ||
kudo/nom: 0e2a4a2 | peschwa++ | tools/build/NQP_REVISION: Bump NQP_REVISION This gets us nqp-j handling of lexical_handler_not_found_error, which means can throw X::ControlFlow::Return on JVM now. |
|||
psch | +we # >_> | ||
lizmat | psch++ | ||
psch | the .map case above is gonna be lots harder i fear :| | 11:19 | |
dalek | kudo/nom: 2d27bde | lizmat++ | src/core/Array.pm: Make Array.shift about 2x as fast - lose the "ensure-allocated" call (no longer allocate if empty) - rewrite using nqp completely |
11:31 | |
moritz | globalnews.ca/news/2807854/a-leap-s...d-of-2016/ oh man, what were they thinking | 11:38 | |
adding a leap second at the turn of the years | |||
gfldex | they where thinking: "ppl will be to drunk to notice" | 11:39 | |
moritz | the scary thing is that when I ask myself "what could possibly go wrong?", I don't really know. Potentially everything. | ||
dalek | kudo/nom: e8a9585 | lizmat++ | src/core/Array.pm: Simplify Array.WHICH |
11:42 | |
kudo/nom: d1ebac0 | lizmat++ | src/core/Array.pm: Squeeze a few more percent out of Array.shift - by handling holes smarter |
11:54 | ||
Tux_ | lizmat, 90_csv.t started failing under prove | 12:14 | |
t/90_csv.t ........ All 329 subtests passed | |||
lizmat | oki, will look | ||
Tux_ | a manual run now always ends with | ||
ok 426 - Out to Str | |||
1..426 | |||
which indeed is the last test | |||
The good news however ā¦ā¦ | 12:17 | ||
This is Rakudo version 2016.06-163-gd1ebac0 built on MoarVM version 2016.06-9-g8fc21d5 | |||
test 15.296 | |||
test-t 8.995 | |||
csv-parser 16.491 | |||
BrokenRobot | :o below 9 secs! | ||
lizmat | whoopee! | ||
BrokenRobot | lizmat++ | ||
Tux_ | personally I rather see 9.0001 that passes | 12:18 | |
lizmat | Tux_: wasn't 90_csv.t already problematic in the past ? | ||
Tux_ | yes | ||
but it was steady now for a long(er) time | |||
Sep 12 11:54:25 <[Tux]> t/90_csv.t ........ All 27 subtests passedr-nom/install/bin/moar': double free or corruption (out): 0x00007f642010f860 *** | 12:20 | ||
Nov 27 08:29:05 <[Tux]> in block <unit> at t/90_csv.t:104 | |||
dalek | ast: e669003 | (Zoffix Znet)++ | S15-literals/numbers.t: Test warnings for 0 prefixed numbers RT#119339 - 0-prefixed number must warn about using 0o prefix - This warning must not suggest the user to use an invalid octal, e.g. 0o9 |
13:00 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=119339 | ||
ast: 7dce301 | (Zoffix Znet)++ | S19-command-line/repl.t: Test octal warnings in REPL RT#119339 - 0-prefixed number must warn about usin 0o prefix - This warning must not suggest the user uses invalid octal, e.g. 0o9 - 0o prefix on valid octal must work in REPL |
13:01 | ||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=119339 | ||
gfldex | moritz: please update Pod::To::HTML on docs.perl6.org | 13:15 | |
moritz | ijen? | 13:16 | |
gfldex | moritz: most of the HTML rendering for docs.perl6.org is actually done in that module | 13:18 | |
i wonder if we should put it in to docs repo as a 3rd party | 13:19 | ||
moritz: o.0 do you wish me to go to hell? www.google.de/search?q=define:+ije...Bm4QsAQIOg | 13:20 | ||
moritz | gfldex: do you have a hack.p6c.org account? | 13:23 | |
dalek | ast: 6c01b3f | (Zoffix Znet)++ | S15-literals/numbers.t: Conversion of 'No' chars to numeric is not supported RT#127866 As per github.com/rakudo/rakudo/commit/e2...6d25995a90 and related discussion, we do not support explicit conversion of lone 'No' chars to numerics. Such functionality must be explicitly requested by the programmer via unival() |
||
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=127866 | ||
gfldex | moritz: i do not | 13:24 | |
moritz | gfldex: alright, done it myself | 13:25 | |
gfldex | moritz: thanks | 13:26 | |
moritz | ("ijen" was my botched attempt to translate "again" to Norwegian, simply because I'm surprised this module has activity again) | 13:27 | |
ilmari | m: say Ā³Ā² | 13:28 | |
camelia | rakudo-moar d1ebac: OUTPUTĀ«9ā¤Ā» | ||
ilmari | m: say "Ā³".Int | ||
camelia | rakudo-moar d1ebac: OUTPUTĀ«Cannot convert string to number: base-10 number must begin with valid digits or '.' in 'āĀ³' (indicated by ā)ā¤ in block <unit> at <tmp> line 1ā¤ā¤Actually thrown at:ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
ilmari | moritz: you almost got it rigth. it's "igjen" | 13:29 | |
moritz | ilmari: I know the sound, because my wife talks to the kids, and doesn't write them :-) | 13:36 | |
and spelling is tricky for me | 13:37 | ||
[Coke] | RT: 1338; CONC: 7; GLR: 6; JVM: 69; LHF: 1; LTA: 74; NYI: 28; OSX: 6; PERF: 16; POD: 3; PRECOMP: 4; RFC: 22; SEGV: 22; STAR: 1; TESTNEEDED: 12; TODO: 8; UNI: 5; UNTAGGED: 675; WEIRD: 3 | ||
ilmari | moritz: ah, I wasn't aware your wife's norwegian | 13:40 | |
BrokenRobot | I should be able to swat a couple more of TESTNEEDED today. | ||
Several of them are still unfixed tho. And I'm unsure what tests to write, since it's unclear what the correct behaviour should/gonna be | 13:41 | ||
moritz | ilmari: half norwegian, actually | 13:42 | |
[Coke] | BrokenRobot: it should be clear in the ticket; if not, ping someone to double check. | ||
in some cases, the test is "code doesn't emit a compiler error" | |||
BrokenRobot | This is still broken, and I'm unsure what error is expected to be emited: rt.perl.org/Ticket/Display.html?id=125817 | 13:43 | |
I commented on the ticket here; unknown whether tests needs to be deleted from roast: rt.perl.org/Ticket/Display.html?id...xn-1408240 | |||
On this one... I guess the test would be just for a segfaul, but are all those "is-prime on Mu" errors in my runs supposed to be there in the first place? The code suggests they shouldn't be: rt.perl.org/Ticket/Display.html?id=127208 | 13:45 | ||
[Coke] | BrokenRobot: sure, it's possible that since it was marked testneeded, it went haywire again | ||
125817 probably needs to decide if it's taking an int or an Int | 13:46 | ||
BrokenRobot | One more closed tickets and we'll have a 1337 number of open tickets :P \o/ | 13:49 | |
m: my @aaa = :foo(1), :bar(2); say $aaa[2] | 13:55 | ||
camelia | rakudo-moar d1ebac: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Variable '$aaa' is not declared. Did you mean '@aaa'?ā¤at <tmp>:1ā¤------> my @aaa = :foo(1), :bar(2); say ā$aaa[2]ā¤Ā» | ||
BrokenRobot | m: my %aaa = :foo(1), :bar(2); say $aaa{'foo'} | 13:56 | |
camelia | rakudo-moar d1ebac: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Variable '$aaa' is not declared. Did you mean '%aaa'?ā¤at <tmp>:1ā¤------> my %aaa = :foo(1), :bar(2); say ā$aaa{'foo'}ā¤Ā» | ||
MasterDuke_ | [Coke]: re RT #125817 and it needing to decide on int vs Int, i feel it's the same for RT #125814 | 13:59 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125817 | ||
Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125814 | |||
MasterDuke_ | changing int to Int at github.com/rakudo/rakudo/blob/nom/...Str.pm#L71 fixes #125814 | 14:00 | |
synopsebot6 | Link: rt.perl.org/rt3//Public/Bug/Displa...?id=125814 | ||
MasterDuke_ | and i'm pretty sure there are a bunch of other places all over where an int is used instead of an Int | 14:01 | |
and i'm not sure whether the expected behavior of those places has been documented | 14:03 | ||
skids | m: sub a (int() $f) { }; a(9) # maybe if that was brought up to speed it would help with chr | 16:03 | |
camelia | rakudo-moar d1ebac: OUTPUTĀ«Method 'int' not found for invocant of class 'Int'ā¤ in sub a at <tmp> line 1ā¤ in block <unit> at <tmp> line 1ā¤ā¤Ā» | ||
tbrowder | ref table pod: I've found no graceful way to signal a bad table from Pod.nqp except an nqp::die which is not graceful IMHO. This morning I thought about sending messages to the user by appropriate messages in the generated table pod. ShimmerFairy is working on a very complex table handling grammar, but that is some time down the road. I assume it will | 17:37 | |
have some way to point to the bad table pod, but I think we need something now better than an exception complaining something about not being able to handle a P6opaque object. Comments, please. | |||
One nice thing about my idea is it should yield a stringified object that can be tested without throwing an exception. | 17:39 | ||
Of course all this is based on my presently quite limited view of the whole process. | 17:40 | ||
[Coke] | pod is parsing. why not throw a compile time exception on bad pod? | 17:42 | |
m: may $a = 3; | |||
camelia | rakudo-moar d1ebac: OUTPUTĀ«===SORRY!=== Error while compiling <tmp>ā¤Variable '$a' is not declaredā¤at <tmp>:1ā¤------> may ā$a = 3;ā¤Ā» | ||
tbrowder | I'm happy to do that if that is acceptable! | ||
gfldex | tbrowder: rendering pod for a large code base is right now in the range of 10th of minutes. The ealier the error is loudly reported the better because then you don't have to start over again and wait another 30min or so. | 17:47 | |
s/10th/10s/ | |||
tbrowder | okey dokey! | 17:49 | |
gfldex | tbrowder: also we do use precompilation (by hand, in the renderer for now) so there is some caching on the correctly finished files. It's ok if the compiler bails in the middle of the build. | 17:52 | |
[Coke] | tbrowder: note that we currently have a few pod exception types, inc.: X::Syntax::Pod::BeginWithoutEnd | 17:54 | |
seems like an InvalidTable would be fine there. | |||
tbrowder | gotcha. i'll try to make the die messages very helpful. anyone know if there is a way to get a file name or line number from an nqp match object? | ||
FROGGS | there certainly is a way | 18:38 | |
timotimo | oh hey froggs :) | 18:40 | |
FROGGS | nqp/src/vm/moar/QAST/QASTCompilerMAST.nqp:1396: my $line := HLL::Compiler.lineof($node.orig(), $node.from(), :cache(1)); | ||
hi timotimo | |||
the match itself might not know about the file it is from... | 18:43 | ||
tbrowder: ^^ | |||
BrokenRobot | Anyone know of an easy ticket for a n00b to hack on? | 19:08 | |
moritz | BrokenRobot: rt.perl.org/Ticket/Display.html?id=128569 | 19:12 | |
timotimo | BrokenRobot: how interested are you in HTML and JS development? :) | ||
moritz | also, test rt.perl.org/Ticket/Display.html?id=128564 on windows and linux | 19:13 | |
BrokenRobot | timotimo: I'm positively-oriented. | ||
timotimo | cool. because you might know we have this profiler thingie, right? | 19:14 | |
moritz | oh wait, the last one was a p5 ticket :( | ||
BrokenRobot | timotimo: yeah | ||
timotimo | it has a few bits that aren't as cool | 19:16 | |
BrokenRobot | Like what? | 19:17 | |
timotimo | beginning with "the pop-up that opens for the allocations lists of code frames per type" won't close when you hit the X | ||
somewhere in the middle of difficulty, i have b0rked the icicle graph, the one that shows when you click "call graph"; most of the boxes have the name of the frame missing, even though they show up in the list at the bottom | 19:18 | ||
either easier or harder than that: the call graph isn't searchable; there's a little filter, but it only filters the callees of the currently selected node. i think it ought to highlight all callees that have anything matching the search/filter "below" it | |||
and the perhaps hardest part: it's slow as molasses. | |||
BrokenRobot | k, I'll see what I can do | 19:20 | |
timotimo | way cool! | 19:24 | |
do you need an example file to play around with? | |||
you can find the template in nqp's repo under src/vm/moar/profiler | |||
BrokenRobot | Sure, if you have an example file. | 19:28 | |
timotimo | gimme a sec :) | 19:29 | |
tbrowder | FROGGS: thanks | ||
timotimo | oh, another thing i haven't mentioned: sometimes some values don't make sense, and i don't know if they come from the json data supplied by moarvm being wrong or something going wrong in the calculations the html is doing | 19:31 | |
t.h8.lv/p6profile/profile_galtonbox.html <- BrokenRobot | 19:32 | ||
BrokenRobot: perhaps a good first step is to look if there's a newer version of Angular 1 that we could upgrade to. perhaps even porting to Angular 2, or re-writing for something else | |||
BrokenRobot | Oh neat. I wanted to learn Angular | 19:33 | |
[Coke] | I did the last angular 1 upgrade on that. | 19:34 | |
going to 2 is, as I recall, basically a full rewrite, and I had to learn enough angular just to bump the 1 version. | |||
BrokenRobot | But it's OK to do that full rewrite? | ||
timotimo | right | 19:35 | |
moritz | somehow the icicle graph and routines tab contract each other | ||
timotimo | contract? | ||
moritz | contradict, sorry | ||
timotimo | shouldn't be so. how do you figure? | ||
moritz | display-board only has 0.15% exclusive time | ||
[Coke] | we're at 1.4.2, latest 1 is 1.5.7 | ||
moritz | but if you look at the icicle graph, it looks like it has about as much eclusive time as sleep, which is roughly 20% | 19:36 | |
*exclusive | 19:37 | ||
timotimo | you don't see exclusive time in the icicle graph | 19:39 | |
at the moment at least | |||
because the other boxes don't have text in them and so they appear almost invisible | |||
moritz | that makes the graph much less useful :( | 19:40 | |
lizmat | m: class A { method a() {} }; for ^1000000 { A.a } # this allocates 1M BOOThashes, one for each call to the method | 19:44 | |
camelia | ( no output ) | ||
lizmat | jnthn: do we really have to allocate a BOOThash for each method call ? | ||
moritz | where does it happen? | 19:45 | |
for potential named args somewhere? | |||
lizmat | moritz: according to the profile, it happens in the method | ||
yes, I guess so | |||
moritz | the implicit *%_ ? | ||
timotimo | i think something we don't know about is preventing it from removing that as unused | 19:46 | |
moritz | or is that optimized out when it's not used in the body? | ||
lizmat | yes, but absence of a BOOThash could as well be taken as an empty *%_, could it not ? | ||
well, see the above example: not much going on there, apart from allocating BOOThashes :-) | |||
jnthn | lizmat: It's the implicit *%_. The "accept all named args" bit has to make it down to the VM level, but it's capable of detecting it's unused and removing it, in theory. Additionally, the Perl 6 optimizer is meant to be looking at whether %_ can possibly be referenced in the scope of the method and removing the binding of it if so. | 19:55 | |
lizmat: I'm not sure which of those two steps is not taking place in this case. | |||
lizmat | jnthn: but that's NYI at this point, right ? | ||
jnthn | Both are implemented. | ||
So it's not clear why they're not operating | 19:56 | ||
Ohhh | |||
There's also a small chance of an unfortunate interaction | |||
Whereby the allocating logging instruction keeps the nameds hash alive from the view of spesh...and so doesn't get eliminated under profiling. | |||
lizmat | ah, so you're saying Heisenberg is at work here ? | 19:57 | |
jnthn | (Since spesh works on the post-instrumented code) | ||
No | |||
Well, yes | |||
:) | |||
Both? :D | |||
lizmat | hehe | ||
jnthn | But yeah, it could well be soemthing like that... | ||
FROGGS | Heisenbergs Cat? | ||
lizmat | that's Schrƶdinger :) | ||
FROGGS | maybe not in this case :o) | 19:58 | |
lizmat | ok, so I shouldn't worry about that | ||
or should I :-) | |||
jnthn | .oO( April 1st joke: replace /bin/cat some something that drops 1 in 100 lines :P ) |
||
*with something | |||
FROGGS | /o\ | ||
jnthn | lizmat: Well, depends if you want to go digging in spesh to find out if that's what is going on, though it's feasible. | ||
If it *is* that it may be causing other distortions too... | 19:59 | ||
geekosaur | schrƶdinger's cat is both alive and dead; heisenberg's cat only knows either where it is or where it is going, but not both :p | ||
jnthn | So it's worth investigating. | ||
It's also possible that one or the other optimization has regressed. | |||
lizmat | yeah, but I'm a 200% spesh noob :-) | ||
jnthn | :) | ||
Feel free to drop a MoarVM issue | |||
lizmat | so i'll ticket it | 20:00 | |
ok | |||
jnthn | Yeah...I just glanced the code and now I'm decidedly suspicious it *is* the instrumentation to do the allocation logging blocking the optimization. | ||
Composability is hard... | 20:01 | ||
.oO( Apparently, so is beating France, if you're Germany... :P ) |
20:02 | ||
jnthn bbl :) | 20:03 | ||
lizmat | jnthn: FYI: github.com/MoarVM/MoarVM/issues/384 | ||
jnthn | lizmat: Thanks :) | 21:16 | |
dalek | kudo/nom: d77174e | lizmat++ | src/core/Array.pm: Make circumfix:[ ]> about 2.5x as fast Turns out that the Iterable:D candidate was basically doing all of the work, because as soon as we have any , within [], it creates a List using infix:<,>. Since this is an Iterable, it would be caught by the Iterable:D candidate, which then assumed it was something strange and started the whole iterator process. Instead, we now check whether it is a non-lazy List (which is usually the case), we simply copy all of the elements over into containers and return the resulting Array. |
21:26 | |
timotimo | whoa | 21:28 | |
nice | 21:29 | ||
dalek | kudo/nom: 29a1107 | lizmat++ | src/core/Exception.pm: "no error message should ever use the second person." grondilu++ |
21:38 | |
lizmat | and with that I wish #perl6-dev a good night | ||
jnthn | 'night, lizmat | 21:39 | |
timotimo | gnite lizmat | 21:40 | |
jnthn | Sleep time for me also, I think. o/ | 21:43 | |
timotimo | gnite jnthn :) | 21:56 | |
dalek | ast: 8463d2d | (Zoffix Znet)++ | packages/Test/Util.pm: Add is_run_repl function to Test::Util Simplify testing of REPL output |
23:39 | |
ast: a3fd6e4 | (Zoffix Znet)++ | S19-command-line/repl.t: Simplify REPL tests use is_run_repl from Test::Util |
|||
ast: 8480c26 | (Zoffix Znet)++ | packages/Test/Util.pm: Fix typo MasterDuke++ |
23:57 |