00:08 woosley joined 01:35 colomon joined 01:58 FROGGS_ joined 02:03 woosley joined 02:25 donaldh joined
nwc10 Stage start : 0.000 05:47
Stage parse : 5493.118
Stage syntaxcheck: 0.037
Stage ast : 0.048
Stage optimize : 4285.018
Stage mast : 25445.270
Stage mbc : 424.588
swap dropped from 475616 (K) to 35628 05:48
All tests successful. 05:55
Files=22, Tests=271, 371 wallclock secs ( 2.02 usr 0.40 sys + 344.21 cusr 14.34 csys = 360.97 CPU) 05:56
Result: PASS
and the total build time
real 634m20.712s
user 113m48.770s
sys 18m31.920s
tadzik: no, it's swapping to the attached external HD 06:03
06:09 JimmyZ_ joined
JimmyZ_ nwc10++ # It's a hard bug 06:09
nwc10 $ grep DWord /proc/cpu/alignment 06:43
DWord: 4555449
yes, long long is hitting a kernel fixup handler
which is why we're still trucking
07:06 zakharyas joined 07:14 FROGGS joined
dalek MoarVM/nwc10++: 3eea1e7 | nicholas++ | src/strings/utf8.c: 07:27
MoarVM/nwc10++: Remove BOM-discarding code from MVM_string_utf8_decode()
MoarVM/nwc10++:
MoarVM/nwc10++: This code is unreachable on a platform where char is signed, because there
MoarVM/nwc10++: utf8[0] will be between -128 and and 127 inclusive, and hence never equal to
07:28 dalek joined
nwc10 and at the end of NQP we had reached: 07:39
DWord: 24936669
it was rebooted before this run
FROGGS I am not sure I understand what that means :o) 07:44
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
"spendy" seems like the relevant slang
FROGGS ohh 07:47
07:50 LLamaRider joined
moritz nwc10: s/aligned/unaligned/ ? 08:00
nwc10 yes 08:08
ENOCOFFEE
08:26 LLamaRider joined
JimmyZ_ It's really a goooood branch name :P 08:48
It may fix my build problem too 08:49
timotimo it's really a good branch name i think
09:20 LLamaRider joined
masak hehe, way to hack the karma system ;) 09:24
at least until dalek gets kick'd. 09:25
FROGGS nwc10: nqp m-test, perl6-m m-test and m-spectest is successfull on linux x86 and x86_64 09:44
nwc10: currently testing 32bit windows
nwc10 which didn't use to work?
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
(OK, yes, I know that OS X x86_64 is working, and probably x86 if someone tries)
FROGGS I can answer "yes" to all 09:48
I'll test Win7 64bit in a few hours though
nwc10: Win32_x86 test summary: gist.github.com/FROGGS/611321ffafb37fa0bdda (nqp's and rakudo's sanity tests are fine) 10:30
I removed the S17 fails now btw 10:32
I think I've seen that S02 fail on perl6-p already 10:34
okay, I am testing on wWin7 x64 now and it seems the fails are windows specific, I've seen them there already perhaps 10:47
nwc10: I also added the Win7 x64 output: gist.github.com/FROGGS/611321ffafb37fa0bdda 11:13
I rerun the failing tests not with moar-master 11:15
nwc10: moar-master fails the same way 11:19
I'd say +1 to merge
the fails are like this: 11:20
not ok 4 - Current directory is 't' subfolder (absolute)
# got: 'C:\rakudo/t'
# expected: 'C:\rakudo\t'
nwc10 oh, fun :-/ 11:58
or is that
fun :-\
anyway, I'd prefer it properly evaluated to rush-merged 11:59
as I'm running on a local branch anyway
also, this is needed to unblock building a Moar-star MSI for Win32?
FROGGS I already built that moar-star yesterday 12:07
13:39 jnap joined 13:42 domidumont joined 13:45 btyler joined 14:13 jnap joined 14:25 donaldh joined 14:36 domidumont joined 15:56 lizmat joined
nwc10 jnthn: yes, technially this is "Read the fine source code", but is freshly compiled in-memory bytecode run through the validator? 15:56
ie, does MoarVM trust its compiler? 15:57
jnthn No, it doesnt trust its compiler 15:58
'cus MAST is pretty close to the bytecode
And you could slip something invalid into there if you were being malicious.
nwc10 OK
jnthn And I didn't really want to implementation validation in two places.
nwc10 from disk bytecode is memory mapped. Presumably freshly compiled is from malloc(). How does it know what to free? 15:59
that's possibly "look at this file..."
jnthn MVMCompUnit.c will be the place, but I'm really not sure how well that's handled yet. 16:00
jnthn checks
oh, apparently it isn't. D'oh. 16:01
nwc10 at all? it leaks?
jnthn Probably. 16:03
But I'm not entirley sure SCs are properly redeemed either
"Make sure eval is really non-leaky" has been on my todo list for a while. 16:04
It's just that the current level of leakiness isn't actually hurting anything afaik.
So it didn't get too close to the top yet.
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:05
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.
So it's fine to fix MVMCompUnit to know the state of its bytecode
But I don't think it alone will mean we ain't leaking there. 16:07
nwc10 OK, just wanted to be consistent
jnthn I've somtimes pondered holding two pointers in there
but that's mahybe not enough
I'm now wondering if it wants an enum BytecodeState of mmaped, generated, and transformed. 16:08
And if it's in the latter two we know it needs freeing.
nwc10 is there any real difference between generated and transformed? 16:09
jnthn Hm, probably not...
Depends if we make src/mast/compiler.c spit out bytecode in current-endian format when we're going to use it right away.
nwc10 I think compiler should spit out in current-endian format
and fixing should be done on writing 16:10
that ensures only one place needs to fix
jnthn Hmmm
nwc10 but yes
16:10 lizmat_ joined
nwc10 it does mean that the writer needs to do the same as validate 16:10
jnthn aye 16:15
but "transform at the boundaries" is usually sane design
nwc10 I was working on the assumption of "transform at the boundaries" 16:16
so validation of from-disk bytecode
and writing out of bytecode to disk
mmm, should also check what happens to bytecode on platforms that can't mmap 16:17
jnthn Heck knows... 16:19
Think the code currently assumes mmap 'cus we didn't yet go somewhere without it. :) 16:20
What notable places can't mmap, ooc?
nwc10 oh, Win32 is happy to mmap?
jnthn Well, it provides the functionality 16:22
Just not under the name mmap
src/platform/win32/mmap.c has the gory details
cognominal__ jnthn, can a (parametric) role be imported from another compulation unit? 16:24
cognominal If so, there must be a lot of magic. 16:26
jnthn wow, my brain fixed that spelling to "copulation unit" :P
Well, you can put "is export" on it... 16:27
So yeah, don't see why not
bbi10
cognominal sorry for the typo :) 16:28
16:30 lizmat joined
cognominal may be it is an horizontal transfer of gene, but it is a digital one, not one involving bacteria, or missionary position 16:33
nwc10 jnthn: is prepare_and_verify_static_frame in frame.c supposed to be static? 16:39
jnthn nwc10: yes 16:51
I'm kinda surprised it isn't
Should probably some day get a list of symbols we export to spot similar accidents
nwc10 medium term define a public API, and where possible use linker scripts to enforce that only API symbols are exported 16:53
but there can be things that are needed in different files internally, that aren't supposed to escape
would be hard(er) to spot those
jnthn MVM_PUBLIC is already existing to do that. 16:54
Though so far "public API" is "I needed it in Rakudo ext ops" :)
dalek arVM: 3eea1e7 | nicholas++ | src/strings/utf8.c:
Remove BOM-discarding code from MVM_string_utf8_decode()

This code is unreachable on a platform where char is signed, because there utf8[0] will be between -128 and and 127 inclusive, and hence never equal to 4150d51 | (Tobias Leich)++ | src/io/fileops.c: steal P5's unlink magic for windows, clear readonly flag when needed
When are file is meant to be deleted, and when we are have the privilegues to clear the readonly flag, then we do that first before attempting to delete the file. In case the file was not deleted we restore the original file flags.		 17:05
jnthn Was happy with all, verified them on Win64 also.
17:05 dalek joined
jnthn (The experimental patch wasn't included.) 17:06
nwc10 yes, it had a massive great XXX 17:08
and the local copy has been --amended
timotimo i love the sound of commits in the evening :) 17:10
jnthn Evening plan: 1) dinner, maybe at Mexican place. 2) Drink a porter. 3) Code if time. :) 17:11
17:12 benabik joined
timotimo m: say so time 17:14
7F1AAEDN9 rakudo-moar 1ccc4d: OUTPUTĀ«Trueā¤Ā»
camelia rakudo-moar 1ccc4d: OUTPUTĀ«Trueā¤Ā»
timotimo ^- :)
jnthn so optimism :) 17:15
timotimo :D
moritz who or what is 7F1AAEDN9 17:19
?
nwc10 moritz: seemingly, a Camelia 17:21
Day changed to 03 May 2014
08:11 -!- camelia is now known as 7F1AAEDN9
benabik m: say 1 17:22
camelia rakudo-moar 1ccc4d: OUTPUTĀ«1ā¤Ā»
7F1AAEDN9 rakudo-moar 1ccc4d: OUTPUTĀ«1ā¤Ā»
jnthn dinner &
benabik That's... less than optimal.
moritz and now we have two of them? 17:23
nwc10 if we ask it to solve the halting problem, will it ping out? 17:24
moritz usually not.
17:27 domidumont joined, camelia joined 17:28 FROGGS joined
moritz killed. 17:29
nwc10 camelia: say 42
er
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ā¤Ā»
FROGGS ahh, the branch got merged, nice :o)
jnthn: I am about to make the windows spectest clean this evening 17:31
nwc10 branch was merged but not yet deleted? 17:34
17:39 domidumont joined 17:45 ggoebel111113 joined 17:47 ggoebel111114 joined
FROGGS - [deleted] nwc10++ 17:52
done
17:54 japhb joined 18:27 benabik joined 18:30 raiph joined
raiph FROGGS: what's the latest on nativecall on 32 bit? 18:33
FROGGS raiph: are there issues? 18:35
raiph don't know. someone said the latest they'd heard was that nativecall didn't work on 32 bit systems. 18:36
www.perlmonks.org/?parent=1085145;node_id=3333
FROGGS hmmm, I'll check that 18:37
raiph thx 18:39
18:51 ggoebel111115 joined
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:01
19:04 FROGGS joined
jnthn nwc10: As far as the bytecode format is concerned, the serialization blob is just, well, a blob. 19:14
nwc10: It doesn't care about it any deeper than a bunch of bytes
FROGGS: Some NativeCall tests apparently fail on r-m in 32-bit. 19:15
FROGGS: Something to do with sized ints.
FROGGS jnthn: ahh, of course, I remember
[Coke] raiph: when was that comment posted? (I don't see anything obvious on the monks page indicating it)
FROGGS [Coke]: today 19:17
May 06, 2014 at 08:06 UTC
[Coke] FROGGS: I am bummed that that appears nowhere on that page. 19:18
FROGGS [Coke]: see www.perlmonks.org/?node_id=1085133 19:20
it is at the bottom somewhere
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:24
19:33 lizmat joined 19:39 lizmat joined 19:49 raiph joined
raiph [Coke] sorry, I posted a somewhat bogus link (right content but no post date). it was posted this morning. 19:51
by grondilu
FROGGS: would you be happy to post a reply on perlmonks about 32 bit or would you prefer I do that? 19:58
FROGGS raiph: you can post there, that would be nice 20:00
fact is, there are failing tests about int/int32 usage, but NativeCall is still usable (would need a --force to install though)
or a --notests 20:01
raiph FROGGS: is that just r*m or r*j / r*p too?
FROGGS r-m* only AFAIK 20:02
though, I can't build r-j* atm on that kind of platform
20:05 brrt joined 20:08 camelia joined
20:18 FROGGS joined
brrt \o #moarvm 20:21
jnthn o/ brrt 20:22
dalek MoarVM/spesh_trace: a41515d | jnthn++ | / (6 files):
MoarVM/spesh_trace: Add lexical lookup lifetime hinting ops.
MoarVM/spesh_trace:
MoarVM/spesh_trace: Allow us to convey that a given lexical lookup can be relied on to
MoarVM/spesh_trace: always resolve to the same thing, or can be relied on to resolve to
timotimo o brrt
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
brrt not checked out, no 20:23
jnthn figured it was a safe bet :)
Or an especially safe bet nobody else was patching it :)
brrt we should have stats on relative commit / loc contributions 20:25
github probably has these
git pull fixed it all for me :-)
FROGGS hi brrt 20:26
brrt hi FROGGS
hoelzro what's the purpose of the annotation segment in a MoarVM bytecode file? 20:35
brrt optimization hints, i'm guessing 20:37
20:37 colomon joined
jnthn hoelzro: line/file info 20:37
hoelzro oh, duh
brrt :-)
hoelzro it says right here =/
jnthn bytecode.md or so :)
hoelzro I see a bunch of entries where the bytecode offset and line number are 0 20:38
and the filename is a crazy hex string
FROGGS base64?
do we do that kind of crazyness still?
jnthn doubtful, I thought it was just references into the string heap 20:39
hoelzro hang on 20:40
I'll pull one up
Annotation.new(bytecode-offset => 0, filename => "903A5CBF1ABDC8EE51C11A21DCBD082D502A98F6", line => 0)
that filename is from the string heap
jnthn ah, hmm :)
interesting :)
That looks like like an SC handle than a filename... 20:41
*more like
hoelzro what's "SC" stand for, anyway? 20:42
[Coke] serialization context 20:43
(though it means something else entirely at $dayjob, and it always confuses me here. :)
hoelzro ah ha
20:52 FROGGS joined 21:20 ilbot3 joined 21:33 FROGGS joined 22:28 benabik joined
dalek arVM: 61f9cdb | (Tobias Leich)++ | / (10 files):
implement op execname, which stores the path of the runner

We can set the path to the runner in the runner scripts itself, store that information and retrieve that later through nqp::execname. moritz++		 22:43
23:03 lizmat joined 23:11 lizmat joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!