01:35 colomon joined 02:04 chipdude joined 03:58 lue joined 04:11 jnap joined
[Coke] moar at 63.36% of jvm 04:51
05:26 jnap joined 06:26 jnap joined 08:28 jnap joined 08:37 odc joined 09:29 jnap joined
masak [Coke]: is that Rakudo on Moar? 09:52
10:29 jnap joined 11:30 jnap joined 12:31 jnap joined
jnthn masak: Yes, it will be. :) 12:31
timotimo i'm interested in trying to compile moarvm with emscripten to ASM.js :P 12:40
jnthn Good luck :P 12:41
timotimo %)
jnthn I suspect compiling Moar ain't too bad but not sure how libuv will work out with that :)
timotimo oh. right. 12:42
the last time i tried to do emscripten i failed horribly for some entirely different reason
i'll give it some more time before i do the attempt 12:43
diakopter :D
timotimo jnthn: an idea why stage mast is only a tiny bit faster than stage parse? 13:03
1 1 3 4 5 7 8 9
now *that* is what i call sorted!
jnthn timotimo: Didn't dig into it yet 13:05
timotimo: oooh! That looks good.
timotimo i've written a version to use _i variants of *pos now 13:06
if it works, i'll commit
jnthn uh, you did switch to using a list_i everywhere, I assume? 13:07
timotimo yes
jnthn ok
anyway, looks like we get sort :)
timotimo i've changed the clone to a for loop, too
i'm thinking unboxing once at the beginning and boxing once at the end should be better than doing n log n boxings + unboxings or something like that
jnthn Well, I want to review the whole way we do sort at some point, 'cus I think we've got some potential other gains to be had there... 13:08
timotimo sounds good to me 13:15
it emits some warnings, but passes the sort test. 13:28
and i've committed it 13:30
jnthn \o/
timotimo \o/ 13:31
another LHF for me? :)
please don't say continuation passing transform :P
jnthn :P
No, though I am looking into the weird match issue at the moment...
13:32 jnap joined
jnthn I think I might have mentioned one yesterday, but forget what it was... 13:32
Oh...one possible thing to do is port the arity_fail stuff in the binder
(It's error message generation)
timotimo can moarvm get something like the getattr/setattr thing where we precalculate the "hint" at compile-time if we can? 13:33
jnthn Yeah
timotimo i bet stage mast can benefit a bit from that
i'll have a look at the binder thing
not actually sure where that lives :| 13:37
nwc10 timotimo: you didn't comment, so not sure if you saw it in scrollback. The author of the Perl 5 sort code thinks it probable that it is slightly more efficient than timsort
but it's not called tim :-(
timotimo right
it seemed pretty daunting to implement anyway
i'll stay with the mergesort variant for now.
13:37 benabik joined
jnthn timotimo: BOOTSTRAP.nqp 13:38
nwc10 that feels sane to me - do something that is good enough, but a lot easier to debug
timotimo ah, i was looking at nqp
and in the vm/moar/ folder
jnthn: is there a stub in the binder for that error already? i didn't see it on my first glance, but i also don't know what exactly to look for :P 13:43
a failing piece of code that triggers the poor error would be fantastic 13:44
FROGGS timotimo: src/Perl6/Metamodel/BOOTSTRAP.nqp:121: nqp::die('arity_fail NYI'); 13:47
timotimo thank you :)
er, that looks to simple to be what i think it is :P 13:48
FROGGS I just wonder why it is not fudged for moar 13:50
[Coke] nothing's fudged yet.
FROGGS [Coke]: I am talking about rakudo's source, not tests 13:51
[Coke] oh.
FROGGS so the question is, where to steal from?
jnthn Either the JVM or Parrot impl 13:52
FROGGS ahh 13:54
src/vm/parrot/guts/bind.c:195:Rakudo_binding_arity_fail(
found itz
-z
timotimo i've already found that part :)
that was easier now that i saw it's a separate sub
nwc10 jnthn: is the answer "dunno, take a look?" to "what would it take to get that assertion fail on setting compilation on not-Win32 fixed?" 13:55
FROGGS nwc10: I captured a bt today: gist.github.com/FROGGS/cbdcd4054a4...llbacks-sh 13:56
jnthn nwc10: Is it the uv one?
nwc10 yes, IIRC 13:57
but I'm a bit confused - sometimes there is an assertion failure (I thought), sometimes a SEGV because ...handle is a bad pointer.
the latter being because one thread frees something before another thread is done with it
nwc10 somewhat destressing
at the babysitting service
now have 10 copies of Robot Turtles (after visting post.at/BMZ and paying tax) 13:58
FROGGS I've got one, and it is awesome :o)
nwc10 my birth certificate has arrived and is being translated
jnthn nwc10: I think that the issue is that something we expect to happen sync is happening async...
nwc10 and there's something else but I forgot what that is somewhat under control
I do have to figure out contact details for the other 9 people, and how to get 2 to Salzburg 13:59
well, about 5 of the 9 others
jnthn Busy times :) 14:01
timotimo has a preliminary implementation of arity_fail 14:02
nwc10 other small things are under control - eg coffee beans exist to refil the coffee machine
timotimo Missing or wrong version of dependency 'src/gen/m-BOOTSTRAP.nqp' 14:05
er what?
jnthn wat
timotimo makes m-clean m-install :\
nwc10 jnthn: NQP HEAD builds with all my torture code
starting on Rakudo
timotimo F YEAH! :) 14:06
jnthn \o/
nwc10: 3122e830b is the commit that fixed things on Windows, I think.
nwc10: That then got backend out to only do those things on Windows. 14:07
Trouble is, the header file claims it's implemented on Windows and Unix, and yet the unix implementation is assert(0 && "implement me"); 14:10
timotimo wow, good job 14:11
jnthn It's that way in latest too.
timotimo Not enough positional parameters passed; got 2 but expected 3 14:15
\o/
FROGGS is that what you wanted?
timotimo it is
jnthn Yes, if you're impletmning arity_fial :)
FROGGS \o/ then
timotimo arity_fijal? what is the pypy dude doing here? :) 14:16
jnthn :P
14:16 jnap joined 14:44 benabik joined
timotimo i'm getting the bootstrap version problem more often now o_O 14:44
dalek arVM/try-fix-io: 66622a1 | jonathan++ | src/io/fileops.c:
Another try at fixing pipe writes.

Removes Win32-specific things, and takes another approach that makes things work fine still on Windows. Needs testing elsewhere.		 14:53
jnthn FROGGS, nwc10: The above may help with the exit segfaults etc. 14:55
Feel free to give it a try and see if it's any improvement.
diakopter hi moat denoaems 15:31
her moar denizens
er moar denizens 15:32
masak kinda liked "moat daemons" :P 15:56
16:01 jnap joined
nwc10 ./perl6-m --target=mbc --output=lib/Test.moarvm lib/Test.pm 16:07
Unhandled exception: While looking for 'ModuleLoader.moarvm': no such file or directory
at <unknown>:1 (/home/nicholas/Perl/rakudo-moar/perl6.moarvm:frame_name_16:6)
which seems to be blib/Perl6/ModuleLoader.moarvm 16:08
but not found
jnthn Oddness... 16:09
nwc10 yes 16:10
jnthn I've never had that one happen here. I have heard it reported...
But was under the impression it boiled down to some oddity with something being out of date...
nwc10 strace shows it looking for ./ModuleLoader.moarvm and then twice for ModuleLoader.moarvm
jnthn Odd...should be looking for it under libpath iirc 16:11
nwc10 OK, clean, rebase and try again...
jnthn What does your perl6-m look like?
nwc10 setting did compile with all the current torture
um, it just got wiped.
sorry, will answer that if I can recreate
jnthn I just found and fixed a nasty segfault. 16:12
May have been to blame for various test fails.
dalek arVM: 7cd9221 | jonathan++ | src/6model/reprs/P6opaque.c:
Fix multiple thinkos in P6opaque.

These could cause box allocation with incorrent STable, or problems when doing attribute auto-viv on mixed-into objects.		 16:13
jnthn Fixes t\spec\integration\rule-in-class-Str.t at least.
But I can see that fix helpling a lot more generally too 16:14
For anybody wanting another thing to investigate: working out why S16-io/basic-open.t hangs may in turn open up various other IO tests 16:22
FROGGS jnthn: that try-fix-io branch made my test hand that segfaulted before... 16:37
or do I have to rebuild nqp/rakudo too? 16:38
jnthn FROGGS: No, should just be a MoarVM change. 16:39
:/
OK, then apparently that's not the way to fix it then. :/
FROGGS :(
I'll play with it in a bit
jnthn libuv basically doesn't provide a way to do a synchronous pipe write.
Well, not a portable one. 16:40
nwc10 synchronous? ENOTTRENDY :-( 16:41
jnthn yeah :/ 16:42
Trouble is, it's the "odd one out"...
For file handles and TTYs it seems you can force sync
(and we do)
16:46 colomon joined
dalek arVM: db68b8f | jonathan++ | src/core/interp.c:
Add missing type-object checks.

Turns various ways to segfault into an appropriate exception.		 16:49
jnthn bbl 16:55
[Coke] I may manually run the moar run again after the slow java run to pick up a few more commits. 17:22
(and then pretend it was the only run)
FROGGS hehe
[Coke]++ 17:23
17:23 jnap joined
[Coke] today's moar run up to S05. I'll shove a copy on feather when it finishes. 17:23
looks like it's running with 7f8a180 17:24
Error while compiling op p6getouterctx: No registered operation handler for 'p6getouterctx' - seeing a bit of that. 17:32
timotimo did you make sure to build all things on master (or on moar-support)? 17:35
[Coke] timotimo: github.com/coke/perl6-roast-data/b...do.moar.sh 17:37
(yup)
timotimo strange 17:38
i thought i saw something mentioning that op, but apparently not. 17:39
[Coke] Might be a few builds behind. 17:40
timotimo i'll run a full spectest run now, too :3
[Coke] it was master -at the time the run started-, and I'm not sure rakudo is updating it's dep on nqp or nqp is updating it's dep on moar.
timotimo good point.
benabik [Coke]: Might I suggest `git clone -b moat-support $URL rakudo.moar` instead of separate clone and checkout operations? Saves some I/O time. 17:41
*moar-support, obv
[Coke] benabik: sure, though time is swamped by "run jvm tests". 17:42
timotimo if you rm-rf it all the time anyway, why not --shallow=1 or what that argument was?
benabik [Coke]: Fair enough.
[Coke] I'm eventually going to do it as japh did in bench, where I have -a- local copy of rakudo and then clone the local copy for builds.
timotimo right 17:43
shallow cloning helps most in nqp, because of the huge stage0 files
and with half blocks you can use background and foreground to have two colors above each other for every character in your terminal 17:45
and these colors will be in mostly square blocks, rather than horribly stretched rectangles
[Coke] timotimo: ? 17:48
timotimo ww 17:49
i wonder how much work it would be to make the junction autothreader be called properly after the binder decides it needs to happen
S03 \o/ 17:52
358 tests more than planned were run 17:54
huh.
benabik Bad fudging? 17:55
timotimo there's loops in there that may be wrong 17:56
weird, there is no plan in that file
i'm confuse.
S05 \o/ 18:05
S06 ... 18:12
FROGGS timotimo: it is unsafe, but there is no need for a plan
timotimo how does it measure "more than planned" then?
ah, because it skipped the "done"?
FROGGS if it dies before it can print it, yes 18:13
timotimo that explains it
FROGGS it will print the tests run due to an END block in Test.pm
[Coke] feather.perl6.nl/~coke/moar.out - first pass today.
20866 passing. 18:14
jvm yesterday passed 28453
timotimo wow, that's pretty cool!
p: say (20866 / 284.53) 18:15
camelia rakudo-parrot dc1544: OUTPUTĀ«73.334973ā¤Ā»
tadzik nice!
timotimo S11 18:16
[Coke] biggest failure still in S05; S32 seems to be much healthier.
timotimo the S05 fails may be what jnthn fixed when he made froggs strange test case work (gather/take f-ups) 18:17
[Coke] I'll rerun in a few hours when parrot & jvm are done.
timotimo oh, it's mostly properties 18:18
i don't know about that.
[Coke] 211 segfaults; 8 killed by memory/timeouts 18:20
timotimo S16 already
we may have to increase the time limit a tiny bit 18:31
the rat tests pass when run without an ulimit.
and i think if you put a "don't dump a core" ulimit in there as well, it'll all be faster
[Coke] it's the same limit parrot has. :P
timotimo hm
i wonder what the cause of those .^ errors may be 18:32
AFK
[Coke] ulimit -c 0, looks like.
timotimo should be, yes 18:33
[Coke] oh, I lied, parrot isn't ulimited, looks like. *boggle* 18:34
timotimo Leading 0 does not indicate octal in Perl 6; please use 0o3 if you mean thattee: write error 18:53
sh full_spectest_moar.sh 3099,23s user 71,67s system 94% cpu 56:05,38 total
... wat
"total", 20967, 7317, 402, 975, 29162, 28494 18:54
so barely any change from your previous run
like 1%
19:39 jnap joined
nwc10 finds a bug in the torture code. = should have been -- 20:08
er, ==
nwc10 re-tortures, properly
timotimo oops 20:14
FROGGS to your defence, = looks almost the same as --
==, even 20:15
timotimo :) 20:16
it seems like the hottest function in all of compiling the core setting is at_pos 20:20
japhb_ That ... really doesn't surprise me. :-) 20:23
nwc10, I haven't been backlogging here for a while -- what is your torture code? What kind of torture does it perform?
timotimo yeah
maybe there's more opportunity to use atpos_i and friends 20:24
nwc10 usign mmap to make fromspace unreadable 20:25
and trying to force a lot of GC runs and move things around a lot
to increase the chances of a GC run happening and exposing a pointer to fromspace
20:40 jnap joined
japhb_ nwc10, So how is the current torture run going? Still producing new bugs? 21:10
dalek arVM/try-fix-io: 67d6ba5 | (Tobias Leich)++ | src/io/fileops.c:
make streams blocking on unixes too, and unref write req

In theory we are unreferencing the write request twice after a successful write, but only doing so makes the uv__delete assertion go away.		 22:25
FROGGS please please test that
22:34 colomon joined
FROGGS dev/rakudo-moar$ perl6-m -e 'say nqp::backendconfig<config>' 22:35
--prefix=../nqp/install --optimize=3
---------------------^
do you guys see that?
timotimo --prefix=../../install 22:38
FROGGS no, not the prefix, the --optimize=3 22:39
timotimo don't have that
FROGGS that is MoarVM's config string... I am now able to compile rakudo with MoarVM @ -O3 22:40
timotimo oh!
FROGGS and I don't have segfaults anymore
timotimo YEAH! :D
how much faster is it?
FROGGS about 5s for stage parse
but the timings are not measured correctly, mind 22:41
timotimo aaw, in the first split second i thought your stage parse now only takes 5s ;)
FROGGS nah
it will take a few months to get there :o)
I really hope that fixes the uv__delete assertions for all of us... including they guys++ with a fruit on their lid 22:44
diakopter SO FRUIT 22:48
jnthn back
japhb_ Welcome back! 22:49
FROGGS jnthn: can you test my patch on your box?
maybe we need to tweak it for windows
jnthn FROGGS: In try-fix-io? 22:50
FROGGS yes
jnthn Trying it.
22:54 woolfy joined
[Coke] that sounds like a HP spell. 23:01
jnthn FROGGS: I have a debug build that seemed to do OK 23:02
I should try an opt one I guess.
FROGGS so far so good
jnthn Well, the NQP build done with that branch optimized passes tests. Well into the Rakudo one now. 23:15
FROGGS: This helps on Linux and gets rid of the assertion fails? 23:16
FROGGS jnthn: at least for me, yes
I have an -O3 optimized Moar build or rakudo, and I've not seen any of the assertions 23:17
jnthn :D
FROGGS and before my patch I had them at least in 20% of the cases
jnthn FROGGS: Yeah, it seems good. 23:21
Feel free to merge
dalek arVM: 66622a1 | jonathan++ | src/io/fileops.c:
Another try at fixing pipe writes.

Removes Win32-specific things, and takes another approach that makes things work fine still on Windows. Needs testing elsewhere.		 23:25
arVM: 67d6ba5 | (Tobias Leich)++ | src/io/fileops.c:
make streams blocking on unixes too, and unref write req

In theory we are unreferencing the write request twice after a successful write, but only doing so makes the uv__delete assertion go away.

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!