01:34 sno joined 01:47 ilbot3 joined 03:42 sno joined 03:44 sno joined 03:48 astj joined 05:00 astj_ joined 05:13 astj joined 08:02 RabidGravy joined 09:35 cognominal joined
tomboy64 when compiling rakudo with rakudo already installed, with the JVM backend, it explodes like this: bpaste.net/show/4368581021ea 10:38
it's not always the same .nqp, though. Sometimes it's World.nqp. 10:39
i didn't observe others so far, but it only happens with the JVM backend.
psch tomboy64: i've seen that error a lot
and moar usually wasn't involved at all
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? ;)
any idea where to start?
psch well, from my point of view it looks like leftovers from previous compilations, probably in gen/jvm
tomboy64 oh, my building environment is clean every time
it's just that rakudo is already installed. 10:41
e.g. these files are present: bpaste.net/show/417c5ff2065c 10:42
psch github.com/perl6/nqp/blob/master/s....java#L278 is where the error comes from 10:43
tomboy64 bpaste.net/show/4cdeb1e4fa0f <--- without color codes
psch i don't really have much of a grasp of serialization in nqp, though 10:44
i'd guess that it tries to load the previous installs' Pod.nqp, which doesn't fit the about-to-be-installed compiler
stmuk tomboy64: is that the gentoo build?
psch but, yeah, i don't really grok what we do in those areas... :) 10:45
tomboy64 stmuk: with my patches, indeed
stmuk I'd suggest removing it and building outside gentoo (unless you are actually working on the gentoo build itself) 10:47
tomboy64 stmuk: i am working on the gentoo build itself 10:48
and psch could confirm the problem
stmuk I'd still suggest developing patches outside gentoo build system before patching it
if possible 10:49
tomboy64 well, it surely would be possible. but why would i want to give up the sandboxing gentoo provides?
psch this github.com/MoarVM/MoarVM/blob/mast...on.c#L2041 is the corresponding moar implementation of what throws on nqp-j 10:54
they look pretty much equivalent to me, which means that it shouldn't have a null sc in the first place i think..? 10:55
tomboy64 hmm github isn't opening for me 10:56
for whatever reason
psch well, you probably have the files locally too :)
dalek kudo/nom: e70601e | lizmat++ | src/core/List.pm:
Speed up List helper method 25%

For the most common case
kudo/nom: e3ded7b | lizmat++ | src/core/Array.pm:
Various shaped / typed Array streamlining

  - inline loops where possible
  - use ternaries where possible
  - postfixize where possible
tomboy64 facepalms 10:57
of course
right
psch in any case, figuring out why (or how) the serialization context shouldn't be null but is null is beyond me :/
tomboy64 wait a second 11:00
that's nqp 11:01
not rakudo
psch yeah, nqp handles the vm-dependant stuff on it's own, mostly 11:03
which also means that nqp complains when rakudo does weird things
i suspect the actual fix is somewhere in the CompUnit stuff
tomboy64 :-} 11:24
thanks for that, reading through the source files to get an idea what's happening
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:26
jnthn: that would perhaps allow for a nice speedup on multidim cases 11:27
as you wouldn't need to pop the thing from the indices
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
lizmat: Which will avoid constructing lists and slurpies and so on entirely.
lizmat ok :-)
jnthn Just didn't have chance to implement them. I think the ops are nqp::-mapped already though. 11:29
So it should, in theory, only be Rakudo work needed
lizmat ah?
hmmm...
dalek kudo/nom: b09f4d7 | lizmat++ | src/core/array_slice.pm:
Streamline multidim array slicing

  - postfixize loops
  - fail fast to slow path as soon as non-Int seen, instead of setting flag		 11:35
lizmat this makes @a[0,0] only 1.5x slower than @a.AT-POS(0,0) 11:37
(was 2x slower) 11:38
tomboy64 jnthn: psch just gave me pointers for checking up about bpaste.net/show/4cdeb1e4fa0f - do you have further ideas?
(it happens when i compile and rakudo is already installed) 11:39
but only when building the jvm backend
dalek kudo/nom: 64fbc84 | lizmat++ | src/core/Block.pm:
Some Block.assuming streamlining
 11:53
kudo/nom: d9803a4 | lizmat++ | src/core/Iterator.pm:
Pre-increment is no longer slower than i = i + 1
 11:58
jnthn tomboy64: Um, that paste is just a list of files? What is it? :) 12:04
psch jnthn: irclog.perlgeek.de/p6dev/2016-05-06#i_12442407 is where it starts 12:17
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
at least that's what it looks like when i encounter it
for any of World.nqp, Pod.nqp and i think i also saw Actions.nqp - the Perl6/ ones in each case 12:19
jnthn psch: Sounds like it's somehow picking up installed files when it shouldn't be... 12:22
Some class path ordering issue maybe? 12:23
psch yeah, that sounds right. i'm not sure what we can do there though 12:25
like, the runner that runs install-core-dist.pl is the same that we install later
so it has to look at the target prefix there
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:26
jnthn Well, in that case we don't even look for the source 12:27
We go straight to loading a precomp
So it simply means we're loading the wrong one 12:28
There's an envvar (RAKUDO_MODULES_DEBUG or something, I forget) that may provide more verbose output
psch ah, so the SC doesn't fit into the current compiler is all
hm, does 'no precompilation' prohibit loading precomps?
i'll check with the modules debug envvar 12:29
lizmat RAKUDO_MODULE_DEBUG 12:32
psch hm, something broke on r-j since 631a36cbe32c98fba05582f15b58380f1a93cc79 or so :/ 12:40
psch bisects
12:41 Skarsnik joined
lizmat ++psch 12:43
dalek kudo/nom: eca89b4 | lizmat++ | src/core/Junction.pm:
Small optimization for one junction.ACCEPTS
 12:48
kudo/nom: 36ff6d0 | lizmat++ | src/core/List.pm:
Streamline some List internals
kudo/nom: efb3810 | lizmat++ | src/core/Mu.pm:
Streamline Mu.isa(Str) && .* and hyper dispatchers
[Coke] i'm going to merge PR#758, if no one objects. (doing a test build with it now) 12:59
lizmat afk& 13:02
dalek kudo/nom: 0ba49da | tomboy64++ | tools/build/Makefile-Moar.in:
Also use includes which were used to build MoarVM
 13:11
kudo/nom: 7db7b46 | (Will Coleda)++ | tools/build/Makefile-Moar.in:
Merge pull request #758 from tomboy-64/tomboy64-gentoo

Also use includes which were used to build MoarVM.
bartolin psch: I suspect, it was the merge of the precomp branch (cmp irclog.perlgeek.de/p6dev/2016-05-02#i_12422526 and irclog.perlgeek.de/perl6/2016-05-03#i_12429980 ) 13:13
psch bartolin: yeah, that seems likely
yeah, the prefix one is the error i'm seeing 13:14
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
3c5f7bcbf63b6d6386e92af036b2e49f9016a561 doesn't build for me anymore either
that's from may 1st 13:17
i do remember that working before the merge, but apparently the merge is now before that commit
bartolin back to $work & 13:19
psch ...i don't think i want to mess with reverting merge commits to figure this out :P
bartolin d7698f3de2 was still fine (that's what I spectested on may 1st (early in the morning) 13:21
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
and i don't understand that :)
do merges do that? insert commits based on timestamp?
probably not right? 13:24
tomboy64 jnthn: oh, pardon me. bpaste.net/show/4368581021ea is the explosion 13:49
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:50
jnthn: it does not happen with the moarvm backend. and it only happens when rakudo is installed. 13:51
jnthn tomboy64: Yeah, my guess is some mis-ordered search path 13:52
Or at least inconsistent with how it is on Moar
tomboy64 yeah, just read the log 13:53
just setting RAKUDO_MODULE_DEBUG=1 is sufficient? 13:54
14:00 perlpilot joined
psch well, the prefix breakage is apparently from d2586ff296b25609ac14e4c9d8c941bd8f636ead 14:56
which is interesting, because that commit supposedly *fixes* "weird errors" ;) 14:57
15:25 tomboy65 joined 15:33 skids joined
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
afaik the issue is that everything takes too long though, which is really hard to fix :/
jnthn psch: It's really *that* slow? :(
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
jnthn: so maybe "slow" isn't actually the problem or the plans changed
fwiw, a full spectest was at slightly over two hours a few days back
i think that was without TEST_JOBS though
jnthn psch: Yeah, but even a normal "make test" would be a big improvement over nothing. 16:16
Since it'd catch accidental build breakage.
psch jnthn: i'd be fine with Configure.pl --make-install, actually... :)
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
jnthn Yeah, automation is the way to go
psch oh
according to .travis.yml we do run r-j build 16:18
jnthn Oh...
psch but we also allow failures there
jnthn Ah, well :P
If it's in a state where it builds fine now, then it'd probably make sense to consider changing that 16:19
I see multiple folks taking care of r-j these days
psch travis-ci.org/rakudo/rakudo/builds/127035462 16:20
that's interesting 16:21
--gen-nqp=master passed
but --gen-nqp didn't 16:22
missing NQP_REVISION bump?
jnthn Dunno...maybe :) 16:23
I thought it was OSX failed and Linux worked though?
psch oh, yeah, i misread that 16:24
that's even more weird
'cause that exact build fails on linux for me 16:27
well, git ref checkout w/e :)
jnthn Wonder if it's different JVM versions...
psch yeah, it is 16:28
some 30 patches behind the one on hack
'java version "1.7.0_101"' on hack vs 'Using java version "1.7.0_76"' on travis
ohh 16:29
it doesn't --make-install
which means install-core-dist isn't run
which means the error doesn't show up
i think i want to duplicate all current envs with added --make-install 16:30
that's the best we have for a canary for CURI, isn't it?
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:31
gist.github.com/peschwa/0058be633b...044a505163 this looks right, doesn't it? :) 16:34
...actually, does duplicating really make sense there?
jnthn Either dupe or just add it on all of them
I mean, it really should work...
psch yeah, i think i'll just add it everywhere instead of duping 16:35
dalek kudo/nom: ac36d2f | peschwa++ | .travis.yml:
Test installation with travis as well
 16:37
[Coke] for the longest time, r-j built but didn't install, yyup, need to test taht. 17:41
[Tux] This is Rakudo version 2016.04-99-g475063a built on MoarVM version 2016.04 18:01
test 22.133
test-t 14.100
csv-parser 35.321
timotimo oh, huh 18:02
sortiz jnthn, May I ask you a question? 19:16
TimToady suggests asking a different question 19:32
sortiz Why Arrays don't reify its !todo list on demand? (A better question, TimToady?) 19:36
TimToady suggests no-pasting some sample code that shows the alleged misbehavior 19:41
sortiz m: my @a := List.from-iterator((loop { }).iterator); 19:42
camelia ( no output )
sortiz m: my @a := Array.from-iterator((loop { }).iterator);
camelia rakudo-moar ac36d2: OUTPUT«(timeout)»
sortiz m: my @a := Array.from-iterator((lazy loop { }).iterator); # This works, why List don't need 'lazy' 19:45
camelia ( no output )
sortiz I.e. I don't allege any misbehavior, I understand the code, but I would like to understand the reason. 19:48
TimToady presumably the difference is todo.reify-until-lazy(); which biases it toward assuming that a list of unknown laziness is not lazy 19:50
so yes, that would be a good question to ask jnthn++ :) 19:52
sortiz Yep. Array.pm L53.
Thanks TimToady. 19:53
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:56
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.
TimToady it's arguably inconsistent, but perhaps usefully so 19:58
All interesting universes must break some symmetry somewhere. :) 19:59
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:01
And Array, by this asymetry is much more expensive. 20:02
TimToady there are many dimensions of "expensive" to balance out 20:03
sortiz Sure. 20:04
[Tux] a second run an hour later was test-t 14.478 20:20
so yes, slower
[Coke] Reminder, we have no one to do the release this month, and we have a blocker ticket open stopping the release. 20:32
no one *scheduled to... I mean to say
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:35
I hopefully will have one within the next week and a half *crosses fingers* 20:36
tomboy65 psch: the commit you gave me earlier, 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:41
psch: just confirmed that error creeping up with or without that commit 20:57
if someone else is interested: bpaste.net/show/ebb9d22c275c is the compile failure with commit d2586ff; 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:00
psch tomboy65: what's your "java -version"? 21:28
tomboy65: actually, never mind that. i misread travis 21:29
tomboy65 $ java -version 22:04
openjdk version "1.8.0_91"
OpenJDK Runtime Environment (IcedTea 3.0.1) (Gentoo icedtea-3.0.1)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)
psch: ^

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!