Perl 6 - the future is here, just unevenly distributed

IRC log for #p6dev, 2016-05-06

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

All times shown according to UTC.

Time Nick Message
01:34 sno joined #p6dev
01:47 ilbot3 joined #p6dev
01:47 Topic for #p6dev is now Perl 6 language and compiler development
03:42 sno joined #p6dev
03:44 sno joined #p6dev
03:48 astj joined #p6dev
05:00 astj_ joined #p6dev
05:13 astj joined #p6dev
08:02 RabidGravy joined #p6dev
09:35 cognominal joined #p6dev
10:38 tomboy64 when compiling rakudo with rakudo already installed, with the JVM backend, it explodes like this: https://bpaste.net/show/4368581021ea
10:39 tomboy64 it's not always the same .nqp, though. Sometimes it's World.nqp.
10:39 tomboy64 i didn't observe others so far, but it only happens with the JVM backend.
10:39 psch tomboy64: i've seen that error a lot
10:39 psch and moar usually wasn't involved at all
10:40 psch as in, to me that happens when i (1) build and installed r-j with --make-install, (2) change stuff, (3) don't git clean -xdf before compiling again
10:40 tomboy64 that would be a great thing to fix, don't oyu think? ;)
10:40 tomboy64 any idea where to start?
10:40 psch well, from my point of view it looks like leftovers from previous compilations, probably in gen/jvm
10:40 tomboy64 oh, my building environment is clean every time
10:41 tomboy64 it's just that rakudo is already installed.
10:42 tomboy64 e.g. these files are present: https://bpaste.net/show/417c5ff2065c
10:43 psch https://github.com/perl6/nqp/blob/master/src/vm/jvm/runtime/org/perl6/nqp/sixmodel/SerializationReader.java#L278 is where the error comes from
10:43 tomboy64 https://bpaste.net/show/4cdeb1e4fa0f <--- without color codes
10:44 psch i don't really have much of a grasp of serialization in nqp, though
10:44 psch i'd guess that it tries to load the previous installs' Pod.nqp, which doesn't fit the about-to-be-installed compiler
10:44 stmuk tomboy64: is that the gentoo build?
10:45 psch but, yeah, i don't really grok what we do in those areas... :)
10:45 tomboy64 stmuk: with my patches, indeed
10:47 stmuk I'd suggest removing it and building outside gentoo (unless you are actually working on the gentoo build itself)
10:48 tomboy64 stmuk: i am working on the gentoo build itself
10:48 tomboy64 and psch could confirm the problem
10:48 stmuk I'd still suggest developing patches outside gentoo build system before patching it
10:49 stmuk if possible
10:49 tomboy64 well, it surely would be possible. but why would i want to give up the sandboxing gentoo provides?
10:54 psch this https://github.com/MoarVM/MoarVM/blob/master/src/6model/serialization.c#L2041 is the corresponding moar implementation of what throws on nqp-j
10:55 psch they look pretty much equivalent to me, which means that it shouldn't have a null sc in the first place i think..?
10:56 tomboy64 hmm github isn't opening for me
10:56 tomboy64 for whatever reason
10:56 psch well, you probably have the files locally too :)
10:56 dalek rakudo/nom: e70601e | lizmat++ | src/core/List.pm:
10:56 dalek rakudo/nom: Speed up List helper method 25%
10:56 dalek rakudo/nom:
10:56 dalek rakudo/nom: For the most common case
10:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e70601e856
10:56 dalek rakudo/nom: e3ded7b | lizmat++ | src/core/Array.pm:
10:56 dalek rakudo/nom: Various shaped / typed Array streamlining
10:56 dalek rakudo/nom:
10:56 dalek rakudo/nom: - inline loops where possible
10:56 dalek rakudo/nom: - use ternaries where possible
10:56 dalek rakudo/nom: - postfixize where possible
10:56 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/e3ded7ba85
10:57 * tomboy64 facepalms
10:57 tomboy64 of course
10:57 tomboy64 right
10:57 psch in any case, figuring out why (or how) the serialization context shouldn't be null but is null is beyond me :/
11:00 tomboy64 wait a second
11:01 tomboy64 that's nqp
11:01 tomboy64 not rakudo
11:03 psch yeah, nqp handles the vm-dependant stuff on it's own, mostly
11:03 psch which also means that nqp complains when rakudo does weird things
11:03 psch i suspect the actual fix is somewhere in the CompUnit stuff
11:24 tomboy64 :-}
11:24 tomboy64 thanks for that, reading through the source files to get an idea what's happening
11:26 lizmat jnthn: would it be too late to change the signature on BIND-POS and ASSIGN-POS to move the thing to be bound/assigned to the first parameter?
11:27 lizmat jnthn: that would perhaps allow for a nice speedup on multidim cases
11:27 lizmat as you wouldn't need to pop the thing from the indices
11:28 jnthn lizmat: Yes, too late. But note that I expect 2D and 3D arrays to be the most common, and for those there are special VM ops and we'll add special candidates for them.
11:28 jnthn lizmat: Which will avoid constructing lists and slurpies and so on entirely.
11:28 lizmat ok  :-)
11:29 jnthn Just didn't have chance to implement them. I think the ops are nqp::-mapped already though.
11:29 jnthn So it should, in theory, only be Rakudo work needed
11:29 lizmat ah?
11:29 lizmat hmmm...
11:35 dalek rakudo/nom: b09f4d7 | lizmat++ | src/core/array_slice.pm:
11:35 dalek rakudo/nom: Streamline multidim array slicing
11:35 dalek rakudo/nom:
11:35 dalek rakudo/nom: - postfixize loops
11:35 dalek rakudo/nom: - fail fast to slow path as soon as non-Int seen, instead of setting flag
11:35 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/b09f4d7395
11:37 lizmat this makes @a[0,0] only 1.5x slower than @a.AT-POS(0,0)
11:38 lizmat (was 2x slower)
11:38 tomboy64 jnthn: psch just gave me pointers for checking up about https://bpaste.net/show/4cdeb1e4fa0f - do you have further ideas?
11:39 tomboy64 (it happens when i compile and rakudo is already installed)
11:39 tomboy64 but only when building the jvm backend
11:53 dalek rakudo/nom: 64fbc84 | lizmat++ | src/core/Block.pm:
11:53 dalek rakudo/nom: Some Block.assuming streamlining
11:53 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/64fbc8431e
11:58 dalek rakudo/nom: d9803a4 | lizmat++ | src/core/Iterator.pm:
11:58 dalek rakudo/nom: Pre-increment is no longer slower than i = i + 1
11:58 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/d9803a4f58
12:04 jnthn tomboy64: Um, that paste is just a list of files? What is it? :)
12:17 psch jnthn: http://irclog.perlgeek.de/p6dev/2016-05-06#i_12442407 is where it starts
12:18 psch jnthn: the issue itself is r-j somehow not finding an SC when compiling with an existing r-j installation in the prefix
12:18 psch at least that's what it looks like when i encounter it
12:19 psch for any of World.nqp, Pod.nqp and i think i also saw Actions.nqp - the Perl6/ ones in each case
12:22 jnthn psch: Sounds like it's somehow picking up installed files when it shouldn't be...
12:23 jnthn Some class path ordering issue maybe?
12:25 psch yeah, that sounds right.  i'm not sure what we can do there though
12:25 psch like, the runner that runs install-core-dist.pl is the same that we install later
12:25 psch so it has to look at the target prefix there
12:26 psch i'm actually not even completely sure what the error means.  as in, does it find the source but not the right precompiled version?
12:27 jnthn Well, in that case we don't even look for the source
12:27 jnthn We go straight to loading a precomp
12:28 jnthn So it simply means we're loading the wrong one
12:28 jnthn There's an envvar (RAKUDO_MODULES_DEBUG or something, I forget) that may provide more verbose output
12:28 psch ah, so the SC doesn't fit into the current compiler is all
12:28 psch hm, does 'no precompilation' prohibit loading precomps?
12:29 psch i'll check with the modules debug envvar
12:32 lizmat RAKUDO_MODULE_DEBUG
12:40 psch hm, something broke on r-j since 631a36cbe32c98fba05582f15b58380f1a93cc79 or so :/
12:40 * psch bisects
12:41 Skarsnik joined #p6dev
12:43 lizmat ++psch
12:48 dalek rakudo/nom: eca89b4 | lizmat++ | src/core/Junction.pm:
12:48 dalek rakudo/nom: Small optimization for one junction.ACCEPTS
12:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/eca89b40c8
12:48 dalek rakudo/nom: 36ff6d0 | lizmat++ | src/core/List.pm:
12:48 dalek rakudo/nom: Streamline some List internals
12:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/36ff6d0966
12:48 dalek rakudo/nom: efb3810 | lizmat++ | src/core/Mu.pm:
12:48 dalek rakudo/nom: Streamline Mu.isa(Str) && .* and hyper dispatchers
12:48 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/efb381055e
12:59 [Coke] i'm going to merge PR#758, if no one objects. (doing a test build with it now)
13:02 lizmat afk&
13:11 dalek rakudo/nom: 0ba49da | tomboy64++ | tools/build/Makefile-Moar.in:
13:11 dalek rakudo/nom: Also use includes which were used to build MoarVM
13:11 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/0ba49da107
13:11 dalek rakudo/nom: 7db7b46 | (Will Coleda)++ | tools/build/Makefile-Moar.in:
13:11 dalek rakudo/nom: Merge pull request #758 from tomboy-64/tomboy64-gentoo
13:11 dalek rakudo/nom:
13:11 dalek rakudo/nom: Also use includes which were used to build MoarVM.
13:11 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/7db7b46b39
13:13 bartolin psch: I suspect, it was the merge of the precomp branch (cmp http://irclog.perlgeek.de/p6dev/2016-05-02#i_12422526 and http://irclog.perlgeek.de/perl6/2016-05-03#i_12429980 )
13:13 psch bartolin: yeah, that seems likely
13:14 psch yeah, the prefix one is the error i'm seeing
13:16 bartolin my daily spectest run before the merge had only one failing file (11 tests) in j-spectest; on 2016-05-02 there where 7876 failing tests -- and the spectest took about 10 hours :-(
13:16 psch hrm
13:16 psch 3c5f7bcbf63b6d6386e92af036b2e49f9016a561 doesn't build for me anymore either
13:17 psch that's from may 1st
13:17 psch i do remember that working before the merge, but apparently the merge is now before that commit
13:19 bartolin back to $work &
13:19 psch ...i don't think i want to mess with reverting merge commits to figure this out :P
13:21 bartolin d7698f3de2 was still fine (that's what I spectested on may 1st (early in the morning)
13:23 psch well, that's the thing.  3c5f7bc worked when i commited it, but after the merge the merge commits appear before it and it doesn't anymore
13:23 psch and i don't understand that :)
13:23 psch do merges do that?  insert commits based on timestamp?
13:24 psch probably not right?
13:49 tomboy64 jnthn: oh, pardon me. https://bpaste.net/show/4368581021ea is the explosion
13:50 tomboy64 jnthn: the "list of files" is what is installed by rakudo. when building rakudo while having rakudo installed, it explodes like in the paste i just gave
13:51 tomboy64 jnthn: it does not happen with the moarvm backend. and it only happens when rakudo is installed.
13:52 jnthn tomboy64: Yeah, my guess is some mis-ordered search path
13:52 jnthn Or at least inconsistent with how it is on Moar
13:53 tomboy64 yeah, just read the log
13:54 tomboy64 just setting RAKUDO_MODULE_DEBUG=1 is sufficient?
14:00 perlpilot joined #p6dev
14:56 psch well, the prefix breakage is apparently from d2586ff296b25609ac14e4c9d8c941bd8f636ead
14:57 psch which is interesting, because that commit supposedly *fixes* "weird errors" ;)
15:25 tomboy65 joined #p6dev
15:33 skids joined #p6dev
16:11 psch on a slighty-related note, i'd really like it if we could somehow get travis to actually do r-j builds
16:11 psch afaik the issue is that everything takes too long though, which is really hard to fix :/
16:11 jnthn psch: It's really *that* slow? :(
16:14 psch jnthn: i thought i read travis has an hour or so limit for OSS, but their plans page says unlimited build minutes...
16:14 psch jnthn: so maybe "slow" isn't actually the problem or the plans changed
16:14 psch fwiw, a full spectest was at slightly over two hours a few days back
16:14 psch i think that was without TEST_JOBS though
16:16 jnthn psch: Yeah, but even a normal "make test" would be a big improvement over nothing.
16:16 jnthn Since it'd catch accidental build breakage.
16:16 psch jnthn: i'd be fine with Configure.pl --make-install, actually... :)
16:17 jnthn Or that :)
16:17 psch i mean, i totally get that not everyone wants to build r-j after making something big work, but it's definitely a problem
16:17 jnthn Yeah, automation is the way to go
16:17 psch oh
16:18 psch according to .travis.yml we do run r-j build
16:18 jnthn Oh...
16:18 psch but we also allow failures there
16:18 jnthn Ah, well :P
16:19 jnthn If it's in a state where it builds fine now, then it'd probably make sense to consider changing that
16:19 jnthn I see multiple folks taking care of r-j these days
16:20 psch https://travis-ci.org/rakudo/rakudo/builds/127035462
16:21 psch that's interesting
16:21 psch --gen-nqp=master passed
16:22 psch but --gen-nqp didn't
16:22 psch missing NQP_REVISION bump?
16:23 jnthn Dunno...maybe :)
16:23 jnthn I thought it was OSX failed and Linux worked though?
16:24 psch oh, yeah, i misread that
16:24 psch that's even more weird
16:27 psch 'cause that exact build fails on linux for me
16:27 psch well, git ref checkout w/e :)
16:27 jnthn Wonder if it's different JVM versions...
16:28 psch yeah, it is
16:28 psch some 30 patches behind the one on hack
16:28 psch 'java version "1.7.0_101"' on hack vs 'Using java version "1.7.0_76"' on travis
16:29 psch ohh
16:29 psch it doesn't --make-install
16:29 psch which means install-core-dist isn't run
16:29 psch which means the error doesn't show up
16:30 psch i think i want to duplicate all current envs with added --make-install
16:30 psch that's the best we have for a canary for CURI, isn't it?
16:31 psch i also kind of want to un-ignore jvm failures, but i have a hunch that very few people would really like that :P
16:34 psch https://gist.github.com/peschwa/0058be633bbb35a3d1331f044a505163 this looks right, doesn't it? :)
16:34 psch ...actually, does duplicating really make sense there?
16:34 jnthn Either dupe or just add it on all of them
16:34 jnthn I mean, it really should work...
16:35 psch yeah, i think i'll just add it everywhere instead of duping
16:37 dalek rakudo/nom: ac36d2f | peschwa++ | .travis.yml:
16:37 dalek rakudo/nom: Test installation with travis as well
16:37 dalek rakudo/nom: review: https://github.com/rakudo/rakudo/commit/ac36d2f7ef
17:41 [Coke] for the longest time, r-j built but didn't install, yyup, need to test taht.
18:01 [Tux] This is Rakudo version 2016.04-99-g475063a built on MoarVM version 2016.04
18:01 [Tux] test            22.133
18:01 [Tux] test-t          14.100
18:01 [Tux] csv-parser      35.321
18:02 timotimo oh, huh
19:16 sortiz jnthn, May I ask you a question?
19:32 * TimToady suggests asking a different question
19:36 sortiz Why Arrays don't reify its !todo list on demand?  (A better question, TimToady?)
19:41 * TimToady suggests no-pasting some sample code that shows the alleged misbehavior
19:42 sortiz m: my @a := List.from-iterator((loop { }).iterator);
19:42 camelia rakudo-moar ac36d2: ( no output )
19:42 sortiz m: my @a := Array.from-iterator((loop { }).iterator);
19:42 camelia rakudo-moar ac36d2: OUTPUT«(timeout)»
19:45 sortiz m: my @a := Array.from-iterator((lazy loop { }).iterator); # This works, why List don't need 'lazy'
19:45 camelia rakudo-moar ac36d2: ( no output )
19:48 sortiz I.e. I don't allege any misbehavior, I understand the code, but I would like to understand the reason.
19:50 TimToady presumably the difference is todo.reify-until-lazy(); which biases it toward assuming that a list of unknown laziness is not lazy
19:52 TimToady so yes, that would be a good question to ask jnthn++ :)
19:52 sortiz Yep. Array.pm L53.
19:53 sortiz Thanks TimToady.
19:56 TimToady I mean, it's easy enough for us to look at loop {} and see that it's gotta be lazy, but not so easy for the compiler, so I don't think we'll get into the business of analyzing loops to see if they halt
19:57 TimToady the other question is more interesting from a language design point of view, but I think the current behavior is more in keeping with the expectations of a lot of people, that arrays are primarily for reified values, and only secondarily to represent reifiable lists
19:57 sortiz Yes, I use loop in my example, but that can be any Iterable.
19:58 TimToady it's arguably inconsistent, but perhaps usefully so
19:59 TimToady All interesting universes must break some symmetry somewhere. :)
20:01 sortiz All this is 'cus I noted that lot of people, by perl5 habit, uses Arrays even when not needed, and most think in @ === Array, when there a lots of Positional types.
20:02 sortiz And Array, by this asymetry is much more expensive.
20:03 TimToady there are many dimensions of "expensive" to balance out
20:04 sortiz Sure.
20:20 [Tux] a second run an hour later was test-t          14.478
20:20 [Tux] so yes, slower
20:32 [Coke] Reminder, we have no one to do the release this month, and we have a blocker ticket open stopping the release.
20:32 [Coke] no one *scheduled to... I mean to say
20:35 MadcapJake If I find a job (can stop spending my day applying), I might have time to do the release.  Doesn't seem too challenging (do let me know if it's more challenging than I'm thinking)
20:36 MadcapJake I hopefully will have one within the next week and a half *crosses fingers*
20:41 tomboy65 psch: the commit you gave me earlier, https://github.com/rakudo/rakudo/commit/d2586ff, that you associated with the jvm failures - i don't have that line in my install-core-dist.pl
20:57 tomboy65 psch: just confirmed that error creeping up with or without that commit
21:00 tomboy65 if someone else is interested: https://bpaste.net/show/ebb9d22c275c is the compile failure with commit d2586ff; https://bpaste.net/show/4368581021ea this is the compile failure without it. only happens when building the jvm-backend and only when rakudo is already installed.
21:28 psch tomboy65: what's your "java -version"?
21:29 psch tomboy65: actually, never mind that.  i misread travis
22:04 tomboy65 $ java -version
22:04 tomboy65 openjdk version "1.8.0_91"
22:04 tomboy65 OpenJDK Runtime Environment (IcedTea 3.0.1) (Gentoo icedtea-3.0.1)
22:04 tomboy65 OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
22:04 tomboy65 psch: ^

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