02:22
sortiz joined
|
|||
nine_ | .oO(I love the smell of refactor in the morning) |
06:11 | |
08:09
RabidGravy joined
|
|||
jnthn | :) | 09:00 | |
jnthn slept non-awfully and might manage some refactoring now :) | |||
dalek | p: b466eea | tomboy64++ | / (4 files): enable custom jars to be used for building the JVM backend |
09:17 | |
p: 10b44b7 | jnthn++ | / (4 files): Merge pull request #281 from tomboy-64/tomboy64-gentoo Enable usage of custom asm.jar, asm-tree.jar, jline.jar and jna.jar |
|||
RabidGravy | harr | 09:18 | |
tomboy64 hails jnthn :) merci bien | 09:31 | ||
jnthn | Want to give the MoarVM one a try out on Windows (or maybe you already did that?), but I'm good with merging it otherwise too. | 09:32 | |
tomboy64 | sorry, don't have a win environment available to do that | 09:33 | |
what about the (minimal) rakudo patch? | 09:34 | ||
i noticed quite a backlog in pull requests there | |||
jnthn | I've got a win environment, can do it later :) | 09:37 | |
tomboy64 | thanks | 09:38 | |
jnthn | github.com/rakudo/rakudo/pull/758/...f9cf78ca65 looks OK in what it does, though does something weird with whitespace... | 09:39 | |
tomboy64 | lol yeah | 09:40 | |
i only just noticed | |||
jnthn | :) | ||
tomboy64 | i have my tabs set to two chars indents | ||
and your indentation is extra-weird - 1 tab + 4 chars | 09:41 | ||
jnthn | wow :) | ||
I'm quite sure that's acciental. | 09:42 | ||
tomboy64 | i can correct that as well. which indentation then? | 09:43 | |
tabs? or a number of whitespaces? | 09:44 | ||
jnthn | Well, its a Makefile, so the non-continuation lines have to be tabs, so probably tabs is the least crazy :) | 09:45 | |
10:42
brrt joined
|
|||
dalek | kudo/nom: 0035cd7 | lizmat++ | src/core/Cursor.pm: Be smarter about looping in MATCH |
10:58 | |
kudo/nom: 1e5955c | lizmat++ | src/core/Str.pm: Be smarter about looping in .split/.trans |
|||
kudo/nom: 9b318e3 | lizmat++ | src/core/ (10 files): Replace i = i + 1 by ++i There is no performance reason anymore to use the more verbose + 1 |
|||
lizmat | jnthn: running with HARNESS_TYPE=6, it looks like the 198th test file always has "no subtests run" | 11:38 | |
and between 10 and 19 files later, it looks like it is just not starting another test file | 11:39 | ||
the base process just hangs, probably waiting for a promise to be kept, and it is never kept | |||
0% CPU | |||
jnthn | Hm, what emits no subests run? The harness? | 11:49 | |
lizmat | TAP.pm6 | 11:50 | |
jnthn | Hm, so something going wrong with the it spawning or getting the output of that test I guess | 11:51 | |
198 is kinda close to 200 | |||
lizmat | yeah | ||
figured it's basically the 200 issue in disguise | 11:52 | ||
jnthn | Don't suppose you tried with MVM_SPESH_OSR_DISABLE, since the OSR threshold is 200? | ||
lizmat | ah, will try | 11:53 | |
jnthn: no difference with MVM_SPESH_OSR_DISABLE=1 | 11:59 | ||
is that the right name ? | |||
yeah, looks like | 12:00 | ||
so, no, that's not it, by the looks of it | |||
dyncall has a DC_CALL_SYS_DEFAULT at 200 | 12:01 | ||
jnthn | moar --help to check :) | 12:02 | |
I don't think NativeCall is being used anywhere by it though? | |||
And that doesn't seem likely even so | |||
lizmat | just grepping for 200 :-) | ||
jnthn | Could always try the wider MVM_SPESH_DISABLE just to check :) | ||
lizmat | nope, the 198th test file fails, but it does seem to get further on from there | 12:08 | |
25 additional test files | |||
so, feels to me there's multiple interaction bugs :-( | 12:09 | ||
*interacting | |||
jnthn | Well, it's possible that removing spesh simply changed some timings and made the smae thing come up later | ||
*same | |||
lizmat | ok, stopping this line of investigation until moar fixes land :-) | 12:20 | |
dalek | kudo/nom: 810788b | lizmat++ | src/core/Any.pm: Postfixize another for loop |
13:09 | |
lizmat | afk& | 13:19 | |
13:20
skids joined
|
|||
dalek | kudo/moar/reframe: 2cbea3b | jnthn++ | src/vm/moar/ops/perl6_ops.c: Chase MoarVM reframe branch changes. |
14:11 | |
p: 04a10f7 | (Pawel Murias)++ | src/vm/js/nqp-runtime/runtime.js: [js] Export loadOps to enable loading the rakudo specific ops. |
14:37 | ||
p: 0d4b885 | (Pawel Murias)++ | src/vm/js/DWIMYNameMangling.nqp: [js] More pleasant to read name mangling. |
|||
p: ea94370 | (Pawel Murias)++ | src/vm/js/Operations.nqp: [js] Implement nqp::takedispatcher/nqp::cleardispatcher/nqp::setdispatcher. |
|||
tomboy64 | jnthn: do you have any idea how to get the build log file by appveyor? | 18:25 | |
jnthn | tomboy64: No...haven't had chance to look at appveyor at all yet | 18:26 | |
tomboy64 | meh. | 18:28 | |
alright, so no indentation improvements for rakudo :p | |||
19:14
brrt joined
|
|||
[Coke] | tomboy64: do you mean .indent, or source code indentation? | 19:48 | |
huh. I see tabs have snuck in. evil. | |||
[Coke] cleans up src/ | 19:51 | ||
dalek | kudo/nom: 8ef120c | coke++ | src/ (4 files): replace tabs with spaces in source |
19:52 | |
kudo/nom: b05593c | coke++ | / (4 files): replace tabs with spaces in source |
20:00 | ||
tomboy64 | [Coke]: bpaste.net/show/8e5b5c93f00e <--- this makes stuff fail with appveyor checks and i'm not in the mood to check myself :p | 20:04 | |
[Coke]: github.com/rakudo/rakudo/pull/758 this is the pr it would apply against. it won't apply against stock tree. | 20:08 | ||
[Coke] | are you just shortening lines in that bpaste? | 20:21 | |
makefiles can have spaces and tabs, and tabs mean something very specific. the commit message on a56911e doesn't give the feeling that was taken into account. | |||
there is no need to have line 65's leading space be a tab, for example. | 20:22 | ||
(which it looks like that commit changes) | 20:23 | ||
So I probably would not merge 758 as it stands. | 20:24 | ||
0caa945f00 seems reasonable to apply. | 20:25 | ||
tomboy64 | oh | ||
RabidGravy | yeah for almost all makes the command lines have to be prefixed by a tab | ||
tomboy64 shrugs | |||
i edited that because in the original files there are leading tabs/spaces mixed | |||
[Coke] | right, but that commit is changing things that are continuation lines, which aren't commands. Having tabs there is not technically wrong, but more stylistically wrong. | ||
tomboy64: yes.. | 20:26 | ||
welcome to makefiles. | |||
tomboy64 | yay | ||
tomboy64 reverts a569 | |||
[Coke]: okay, removed the tab-"fix" | 20:34 | ||
[Coke]: also, i'm experiencing build failures with the jvm backend whenever i try to build with rakudo already being installed. | 20:35 | ||
would you be interested in helping me debug that? | 20:36 | ||
dalek | kudo/nom: 780f073 | lizmat++ | src/core/ (2 files): Make LoL accesses about 3x as fast - by introducing a new WALK-AT-POS method in Rakudo::Internals - using that method in Any.(DELETE|EXISTS|AT|ASSIGN)-POS - alas, BIND-POS did not work correctly with this treatment it looks like Array.pop is somehow returning a different container than an AT-POS does :-( |
21:58 | |
timotimo | wow, 3x, that's fantastic | 21:59 | |
probably still rather expensive? | |||
21:59
Skarsnik joined
|
|||
lizmat | well, the AT-POS itself is still rather expensive | 21:59 | |
but walking the indices array is now 3x as fast | |||
timotimo | oh, i see | 22:00 | |
lizmat | m: my @a = [1,2],[3,4]; dd @a.AT-POS(0,0) | 22:01 | |
camelia | rakudo-moar b05593: OUTPUT«Int <element> = 1» | ||
lizmat | that part has gotten faster | ||
m: my @a = [1,2],[3,4]; dd @a[0;0] # how you would write this normally | |||
camelia | rakudo-moar b05593: OUTPUT«Int <element> = 1» | ||
timotimo | oh, ah | ||
lizmat | not sure how fast it goes from [0;0] to AT-POS(0,0) | 22:02 | |
timotimo | mhm | ||
lizmat | looks like direct AT-POS is 2x as fast as [0;0] | 22:03 | |
room for improvement there | |||
timotimo | wow | 22:04 | |
lizmat | but first, sleep& | ||
timotimo | gnite! |