Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-05-06

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

All times shown according to UTC.

Time Nick Message
00:08 woosley joined #moarvm
01:35 colomon joined #moarvm
01:58 FROGGS_ joined #moarvm
02:03 woosley joined #moarvm
02:25 donaldh joined #moarvm
05:47 nwc10 Stage start      :   0.000
05:47 nwc10 Stage parse      : 5493.118
05:47 nwc10 Stage syntaxcheck:   0.037
05:47 nwc10 Stage ast        :   0.048
05:47 nwc10 Stage optimize   : 4285.018
05:47 nwc10 Stage mast       : 25445.270
05:47 nwc10 Stage mbc        : 424.588
05:48 nwc10 swap dropped from 475616 (K) to 35628
05:55 nwc10 All tests successful.
05:56 nwc10 Files=22, Tests=271, 371 wallclock secs ( 2.02 usr  0.40 sys + 344.21 cusr 14.34 csys = 360.97 CPU)
05:56 nwc10 Result: PASS
05:56 nwc10 and the total build time
05:56 nwc10 real    634m20.712s
05:56 nwc10 user    113m48.770s
05:56 nwc10 sys     18m31.920s
06:03 nwc10 tadzik: no, it's swapping to the attached external HD
06:09 JimmyZ_ joined #moarvm
06:09 JimmyZ_ nwc10++ # It's a hard bug
06:43 nwc10 $ grep DWord /proc/cpu/alignment
06:43 nwc10 DWord:          4555449
06:43 nwc10 yes, long long is hitting a kernel fixup handler
06:43 nwc10 which is why we're still trucking
07:06 zakharyas joined #moarvm
07:14 FROGGS joined #moarvm
07:27 dalek MoarVM/nwc10++: 3eea1e7 | nicholas++ | src/strings/utf8.c:
07:27 dalek MoarVM/nwc10++: Remove BOM-discarding code from MVM_string_utf8_decode()
07:27 dalek MoarVM/nwc10++:
07:27 dalek MoarVM/nwc10++: This code is unreachable on a platform where char is signed, because there
07:27 dalek MoarVM/nwc10++: utf8[0] will be between -128 and and 127 inclusive, and hence never equal to
07:28 dalek joined #moarvm
07:39 nwc10 and at the end of NQP we had reached:
07:39 nwc10 DWord:          24936669
07:39 nwc10 it was rebooted before this run
07:44 FROGGS I am not sure I understand what that means :o)
07:45 nwc10 almost 2.5 millon CPU aborts caused by reading 64 bit integers from aligned addresses, trapped by the kernel and fixed up
07:45 nwc10 "spendy" seems like the relevant slang
07:47 FROGGS ohh
07:50 LLamaRider joined #moarvm
08:00 moritz nwc10: s/aligned/unaligned/ ?
08:08 nwc10 yes
08:08 nwc10 ENOCOFFEE
08:26 LLamaRider joined #moarvm
08:48 JimmyZ_ It's really a goooood branch name :P
08:49 JimmyZ_ It may fix my build problem too
08:49 timotimo it's    really  a       good    branch  name    i       think
09:20 LLamaRider joined #moarvm
09:24 masak hehe, way to hack the karma system ;)
09:25 masak at least until dalek gets kick'd.
09:44 FROGGS nwc10: nqp m-test, perl6-m m-test and m-spectest is successfull on linux x86 and x86_64
09:44 FROGGS nwc10: currently testing 32bit windows
09:44 nwc10 which didn't use to work?
09:45 nwc10 and you can then test 64bit windows? and that would mean all 3 known good platforms are still good, and we have a 4th?
09:45 nwc10 (OK, yes, I know that OS X x86_64 is working, and probably x86 if someone tries)
09:48 FROGGS I can answer "yes" to all
09:48 FROGGS I'll test Win7 64bit in a few hours though
10:30 FROGGS nwc10: Win32_x86 test summary: https://gist.github.com/FROGGS/611321ffafb37fa0bdda (nqp's and rakudo's sanity tests are fine)
10:32 FROGGS I removed the S17 fails now btw
10:34 FROGGS I think I've seen that S02 fail on perl6-p already
10:47 FROGGS okay, I am testing on wWin7 x64 now and it seems the fails are windows specific, I've seen them there already perhaps
11:13 FROGGS nwc10: I also added the Win7 x64 output: https://gist.github.com/FROGGS/611321ffafb37fa0bdda
11:15 FROGGS I rerun the failing tests not with moar-master
11:19 FROGGS nwc10: moar-master fails the same way
11:19 FROGGS I'd say +1 to merge
11:20 FROGGS the fails are like this:
11:20 FROGGS not ok 4 - Current directory is 't' subfolder (absolute)
11:20 FROGGS #      got: 'C:\rakudo/t'
11:20 FROGGS # expected: 'C:\rakudo\t'
11:58 nwc10 oh, fun :-/
11:58 nwc10 or is that
11:58 nwc10 fun :-\
11:59 nwc10 anyway, I'd prefer it properly evaluated to rush-merged
11:59 nwc10 as I'm running on a local branch anyway
11:59 nwc10 also, this is needed to unblock building a Moar-star MSI for Win32?
12:07 FROGGS I already built that moar-star yesterday
13:39 jnap joined #moarvm
13:42 domidumont joined #moarvm
13:45 btyler joined #moarvm
14:13 jnap joined #moarvm
14:25 donaldh joined #moarvm
14:36 domidumont joined #moarvm
15:56 lizmat joined #moarvm
15:56 nwc10 jnthn: yes, technially this is "Read the fine source code", but is freshly compiled in-memory bytecode run through the validator?
15:57 nwc10 ie, does MoarVM trust its compiler?
15:58 jnthn No, it doesnt trust its compiler
15:58 jnthn 'cus MAST is pretty close to the bytecode
15:58 jnthn And you could slip something invalid into there if you were being malicious.
15:58 nwc10 OK
15:58 jnthn And I didn't really want to implementation validation in two places.
15:59 nwc10 from disk bytecode is memory mapped. Presumably freshly compiled is from malloc(). How does it know what to free?
15:59 nwc10 that's possibly "look at this file..."
16:00 jnthn MVMCompUnit.c will be the place, but I'm really not sure how well that's handled yet.
16:00 * jnthn checks
16:01 jnthn oh, apparently it isn't. D'oh.
16:01 nwc10 at all? it leaks?
16:03 jnthn Probably.
16:03 jnthn But I'm not entirley sure SCs are properly redeemed either
16:04 jnthn "Make sure eval is really non-leaky" has been on my todo list for a while.
16:04 jnthn It's just that the current level of leakiness isn't actually hurting anything afaik.
16:04 jnthn So it didn't get too close to the top yet.
16:05 jnthn SCs have some curious weakhash arrangement that I'm not 100% comfortable with at present either, or at least couldn't yet convince myself is right or wrong.
16:06 nwc10 OK, and SCs will be holding onto frames of bytecode? meaning that if SCs are leaking, even well behaved bytecode won't clean up?
16:06 jnthn Right.
16:06 jnthn So it's fine to fix MVMCompUnit to know the state of its bytecode
16:07 jnthn But I don't think it alone will mean we ain't leaking there.
16:07 nwc10 OK, just wanted to be consistent
16:07 jnthn I've somtimes pondered holding two pointers in there
16:07 jnthn but that's mahybe not enough
16:08 jnthn I'm now wondering if it wants an enum BytecodeState of mmaped, generated, and transformed.
16:08 jnthn And if it's in the latter two we know it needs freeing.
16:09 nwc10 is there any real difference between generated and transformed?
16:09 jnthn Hm, probably not...
16:09 jnthn Depends if we make src/mast/compiler.c spit out bytecode in current-endian format when we're going to use it right away.
16:09 nwc10 I think compiler should spit out in current-endian format
16:10 nwc10 and fixing should be done on writing
16:10 nwc10 that ensures only one place needs to fix
16:10 jnthn Hmmm
16:10 nwc10 but yes
16:10 lizmat_ joined #moarvm
16:10 nwc10 it does mean that the writer needs to do the same as validate
16:15 jnthn aye
16:15 jnthn but "transform at the boundaries" is usually sane design
16:16 nwc10 I was working on the assumption of "transform at the boundaries"
16:16 nwc10 so validation of from-disk bytecode
16:16 nwc10 and writing out of bytecode to disk
16:17 nwc10 mmm, should also check what happens to bytecode on platforms that can't mmap
16:19 jnthn Heck knows...
16:20 jnthn Think the code currently assumes mmap 'cus we didn't yet go somewhere without it. :)
16:20 jnthn What notable places can't mmap, ooc?
16:20 nwc10 oh, Win32 is happy to mmap?
16:22 jnthn Well, it provides the functionality
16:22 jnthn Just not under the name mmap
16:22 jnthn src/platform/win32/mmap.c has the gory details
16:24 cognominal__ jnthn, can a (parametric) role be imported from another compulation unit?
16:26 cognominal If so, there must be a lot of magic.
16:26 jnthn wow, my brain fixed that spelling to "copulation unit" :P
16:27 jnthn Well, you can put "is export" on it...
16:27 jnthn So yeah, don't see why not
16:27 jnthn bbi10
16:28 cognominal sorry for the typo :)
16:30 lizmat joined #moarvm
16:33 cognominal may be it is an horizontal transfer of gene, but it is a digital one, not one involving bacteria, or missionary position
16:39 nwc10 jnthn: is prepare_and_verify_static_frame in frame.c supposed to be static?
16:51 jnthn nwc10: yes
16:51 jnthn I'm kinda surprised it isn't
16:51 jnthn Should probably some day get a list of symbols we export to spot similar accidents
16:53 nwc10 medium term define a public API, and where possible use linker scripts to enforce that only API symbols are exported
16:53 nwc10 but there can be things that are needed in different files internally, that aren't supposed to escape
16:53 nwc10 would be hard(er) to spot those
16:54 jnthn MVM_PUBLIC is already existing to do that.
16:54 jnthn Though so far "public API" is "I needed it in Rakudo ext ops" :)
17:05 dalek MoarVM: 3eea1e7 | nicholas++ | src/strings/utf8.c:
17:05 dalek MoarVM: Remove BOM-discarding code from MVM_string_utf8_decode()
17:05 dalek MoarVM:
17:05 dalek MoarVM: This code is unreachable on a platform where char is signed, because there
17:05 dalek MoarVM: utf8[0] will be between -128 and and 127 inclusive, and hence never equal to
17:05 jnthn Was happy with all, verified them on Win64 also.
17:05 dalek joined #moarvm
17:06 jnthn (The experimental patch wasn't included.)
17:08 nwc10 yes, it had a massive great XXX
17:08 nwc10 and the local copy has been --amended
17:10 timotimo i love the sound of commits in the evening :)
17:11 jnthn Evening plan: 1) dinner, maybe at Mexican place. 2) Drink a porter. 3) Code if time. :)
17:12 benabik joined #moarvm
17:14 timotimo m: say so time
17:14 7F1AAEDN9 rakudo-moar 1ccc4d: OUTPUT«True␤»
17:14 camelia rakudo-moar 1ccc4d: OUTPUT«True␤»
17:14 timotimo ^-   :)
17:15 jnthn so optimism :)
17:15 timotimo :D
17:19 moritz who or what is 7F1AAEDN9
17:19 moritz ?
17:21 nwc10 moritz: seemingly, a Camelia
17:21 nwc10 Day changed to 03 May 2014
17:21 nwc10 08:11 -!- camelia is now known as 7F1AAEDN9
17:22 benabik m: say 1
17:22 camelia rakudo-moar 1ccc4d: OUTPUT«1␤»
17:22 7F1AAEDN9 rakudo-moar 1ccc4d: OUTPUT«1␤»
17:22 jnthn dinner &
17:22 benabik That's... less than optimal.
17:23 moritz and now we have two of them?
17:24 nwc10 if we ask it to solve the halting problem, will it ping out?
17:24 moritz usually not.
17:27 domidumont joined #moarvm
17:27 camelia joined #moarvm
17:28 FROGGS joined #moarvm
17:29 moritz killed.
17:29 nwc10 camelia: say 42
17:29 nwc10 er
17:30 nwc10 m: use more 'coffee';
17:30 camelia rakudo-moar 1ccc4d: OUTPUT«===SORRY!===␤Could not find more in any of: /home/p6eval/.perl6/2014.04-185-g1ccc4d3/lib, /home/p6eval/rakudo-inst-1/languages/perl6/site/lib, /home/p6eval/rakudo-inst-1/languages/perl6/vendor/lib, /home/p6eval/rakudo-inst-1/languages/perl6/lib␤»
17:30 FROGGS ahh, the branch got merged, nice :o)
17:31 FROGGS jnthn: I am about to make the windows spectest clean this evening
17:34 nwc10 branch was merged but not yet deleted?
17:39 domidumont joined #moarvm
17:45 ggoebel111113 joined #moarvm
17:47 ggoebel111114 joined #moarvm
17:52 FROGGS - [deleted]         nwc10++
17:52 FROGGS done
17:54 japhb joined #moarvm
18:27 benabik joined #moarvm
18:30 raiph joined #moarvm
18:33 raiph FROGGS: what's the latest on nativecall on 32 bit?
18:35 FROGGS raiph: are there issues?
18:36 raiph don't know. someone said the latest they'd heard was that nativecall didn't work on 32 bit systems.
18:36 raiph http://www.perlmonks.org/?parent=1085145;node_id=3333
18:37 FROGGS hmmm, I'll check that
18:39 raiph thx
18:51 ggoebel111115 joined #moarvm
19:01 nwc10 jnthn: the "boundary" approach to endian-ness probably doesn't work. All the serialisation code, to read and to write, is tightly coupled to endian swapping
19:04 FROGGS joined #moarvm
19:14 jnthn nwc10: As far as the bytecode format is concerned, the serialization blob is just, well, a blob.
19:14 jnthn nwc10: It doesn't care about it any deeper than a bunch of bytes
19:15 jnthn FROGGS: Some NativeCall tests apparently fail on r-m in 32-bit.
19:15 jnthn FROGGS: Something to do with sized ints.
19:15 FROGGS jnthn: ahh, of course, I remember
19:15 [Coke] raiph: when was that comment posted? (I don't see anything obvious on the monks page indicating it)
19:17 FROGGS [Coke]: today
19:17 FROGGS May 06, 2014 at 08:06 UTC
19:18 [Coke] FROGGS: I am bummed that that appears nowhere on that page.
19:20 FROGGS [Coke]: see http://www.perlmonks.org/?node_id=1085133
19:20 FROGGS it is at the bottom somewhere
19:24 nwc10 jnthn: OK. Looking at the code, the bytecode part of the bytecode blob/file could take the same approach as the serialisation blob
19:33 lizmat joined #moarvm
19:39 lizmat joined #moarvm
19:49 raiph joined #moarvm
19:51 raiph [Coke] sorry, I posted a somewhat bogus link (right content but no post date). it was posted this morning.
19:51 raiph by grondilu
19:58 raiph FROGGS: would you be happy to post a reply on perlmonks about 32 bit or would you prefer I do that?
20:00 FROGGS raiph: you can post there, that would be nice
20:00 FROGGS fact is, there are failing tests about int/int32 usage, but NativeCall is still usable (would need a --force to install though)
20:01 FROGGS or a --notests
20:01 raiph FROGGS: is that just r*m or r*j / r*p too?
20:02 FROGGS r-m* only AFAIK
20:02 FROGGS though, I can't build r-j* atm on that kind of platform
20:05 brrt joined #moarvm
20:08 camelia joined #moarvm
20:17 dalek MoarVM: 4150d51 | (Tobias Leich)++ | src/io/fileops.c:
20:17 dalek MoarVM: steal P5's unlink magic for windows, clear readonly flag when needed
20:17 dalek MoarVM:
20:17 dalek MoarVM: When are file is meant to be deleted, and when we are have the privilegues
20:17 dalek MoarVM: to clear the readonly flag, then we do that first before attempting to delete
20:17 dalek MoarVM: the file. In case the file was not deleted we restore the original file flags.
20:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4150d51581
20:18 FROGGS joined #moarvm
20:21 brrt \o #moarvm
20:22 jnthn o/ brrt
20:22 dalek MoarVM/spesh_trace: a41515d | jnthn++ | / (6 files):
20:22 dalek MoarVM/spesh_trace: Add lexical lookup lifetime hinting ops.
20:22 dalek MoarVM/spesh_trace:
20:22 dalek MoarVM/spesh_trace: Allow us to convey that a given lexical lookup can be relied on to
20:22 dalek MoarVM/spesh_trace: always resolve to the same thing, or can be relied on to resolve to
20:22 timotimo o brrt
20:23 jnthn hope nobody had a checkout of spesh_trace 'cus I just rebase and -f'd it. :)
20:23 brrt hows it here
20:23 dalek joined #moarvm
20:23 brrt not checked out, no
20:23 * jnthn figured it was a safe bet :)
20:23 jnthn Or an especially safe bet nobody else was patching it :)
20:25 brrt we should have stats on relative commit / loc contributions
20:25 brrt github probably has these
20:25 brrt git pull fixed it all for me :-)
20:26 FROGGS hi brrt
20:26 brrt hi FROGGS
20:35 hoelzro what's the purpose of the annotation segment in a MoarVM bytecode file?
20:37 brrt optimization hints, i'm guessing
20:37 colomon joined #moarvm
20:37 jnthn hoelzro: line/file info
20:37 hoelzro oh, duh
20:37 brrt :-)
20:37 hoelzro it says right here =/
20:37 jnthn bytecode.md or so :)
20:38 hoelzro I see a bunch of entries where the bytecode offset and line number are 0
20:38 hoelzro and the filename is a crazy hex string
20:38 FROGGS base64?
20:38 FROGGS do we do that kind of crazyness still?
20:39 jnthn doubtful, I thought it was just references into the string heap
20:40 hoelzro hang on
20:40 hoelzro I'll pull one up
20:40 hoelzro Annotation.new(bytecode-offset => 0, filename => "903A5CBF1ABDC8EE51C11A21DCBD082D502A98F6", line => 0)
20:40 hoelzro that filename is from the string heap
20:40 jnthn ah, hmm :)
20:40 jnthn interesting :)
20:41 jnthn That looks like like an SC handle than a filename...
20:41 jnthn *more like
20:42 hoelzro what's "SC" stand for, anyway?
20:43 [Coke] serialization context
20:43 [Coke] (though it means something else entirely at $dayjob, and it always confuses me here. :)
20:43 hoelzro ah ha
20:52 FROGGS joined #moarvm
21:20 ilbot3 joined #moarvm
21:20 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
21:33 FROGGS joined #moarvm
22:28 benabik joined #moarvm
22:43 dalek MoarVM: 61f9cdb | (Tobias Leich)++ | / (10 files):
22:43 dalek MoarVM: implement op execname, which stores the path of the runner
22:43 dalek MoarVM:
22:43 dalek MoarVM: We can set the path to the runner in the runner scripts itself, store that information
22:43 dalek MoarVM: and retrieve that later through nqp::execname. moritz++
22:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/61f9cdb8b6
23:03 lizmat joined #moarvm
23:11 lizmat joined #moarvm

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