Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-05

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

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

| Channels | #p6dev index | Today | | Search | Google Search | Plain-Text | summary