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!