nwc10 jnthn: botherit, in that I'd forgotten where the Moar-on-Pi error was 09:31
it's an "index out of range" during NQP
however, gcc is 4.6 (and valgrind is 3.7.0
so I'm dist-upgrading to debian testing to get a vaguely current toolchain 09:32
jnthn nwc10++ # portability stuffs 10:15
nwc10 jnthn: which filled / 10:17
so xkcd.com/349/
(have discovered apt-get autoclean)
have second working SD card. Going to use this, etc 10:18
but need to do some setup first
for which it turns out that it's fairly useful to have a satellite receiver which is actually running linux 10:19
even if (grumble) it can't do ext4
jnthn Interesting thing that might tempt somebody: you can use the spesh graph building infrastructure for more than just that. One other application is to instrument the code for profiling. 11:01
That's probably how we should build profiling support into MoarVM.
FROGGS_ cool!! 11:22
timotimo might like that idea :o)
jnthn is doing the next round of spesh work and it's tricky
timotimo hmmm
timotimo jnthn: can i has a flag that i can set on the vm instance that causes moarvm to shut down and clean up when a gc is hit? 13:17
jnthn That sounds like a weird thing to want... 13:18
What're you trying to achieve? 13:19
FROGGS_ hehe
timotimo have a moarvm in-process and have a way to stop it
when it's infinilooping, for example
making it a separate process makes it simpler to kill, but then i have to think about ipc, instead of just exposing a few C functions to NativeCall 13:22
dalek arVM/spesh_trace: 2938e6d | jnthn++ | src/ (2 files):
Add slots related to logging things we saw.
 14:10
arVM/spesh_trace: 5170681 | jnthn++ | / (11 files):
Re-organize spesh to have log/specialize phases.

When we first decide to specialize, we now only go so far as creating argument guards. There is a place for logging instructions to be added
  (though none are being yet). This information will then be available
when we reach specialize time, to guide specialization.
timotimo ah, so it'll be a bit more like pypys tracing jit 14:13
where they run the code that's been considered hot once while looking really closely, logging everything, tracing through the whole interpreter
jnthn Well, sorta-ish-kinda :) 14:14
We don't trace through the interpreter or log everything. Just some interesting things we can't figure out otherwise.
But yeah, it should gets us various benefits :) 14:15
timotimo ah, ok 14:19
yay :)
dalek arVM/spesh_trace: 91b5df6 | jnthn++ | src/core/interp.c:
Implement sp_log op.
 14:49
arVM/spesh_trace: e720acd | jnthn++ | src/spesh/ (3 files):
Start inserting logging instructions.
JimmyZ wonders what spesh trace is about 15:14
timotimo jnthn explained it a bit above 15:21
dalek arVM/spesh_trace: 009fb08 | jnthn++ | src/6model/reprs/MVMStaticFrame.c:
Correct log slot marking.
 15:33
arVM/spesh_trace: 1d10c99 | jnthn++ | src/core/interp.c:
Fix scoped/lifetimed lexical lookup opts.
arVM/spesh_trace: 031f7ed | jnthn++ | src/spesh/candidate.c:
Add missing write barrier after spesh.
jnthn The goal is partly to allow spesh to benefit Rakudo more, but also this is part of preparing the way for inlining.
JimmyZ That's very nice 15:42
jnthn Yes. A bit tricky, though :P 15:43
dalek arVM/spesh_trace: 2b08076 | jnthn++ | src/spesh/optimize.c:
getlexstatic_o optimization.
 16:31
arVM/spesh_trace: f4ba822 | jnthn++ | src/spesh/c (2 files):
Be more careful with no-handler frames.
arVM/spesh_trace: 5b9af98 | jnthn++ | src/spesh/codegen.c:
Better error on handler fixup failure.
timotimo jnthn: i'm not sure i understand how that getlexstatic_o thing is supposed to work; would it turn redundant getlexes into a cheap operation like accessing a local? 16:33
but only if it's still the same object?
jnthn timotimo: When you do $a + $b, if we didn't override the +, it's the same one every time. 16:34
The other op that I added that we don't use yet is for type variables
Where if we specialized on the invocant type then ::?CLASS (used for attribute lookups) can be considered static 16:35
timotimo ooooh
that does sound good
jnthn Sadly, we get some Rakudo test fails with this and the NQP patches I just pash 16:36
timotimo does it do things yet?
jnthn But it seems it's a silly thing
timotimo ah, ok
jnthn It's somehow failing to re-compute frame handler addresses.
Despite the dump showing annotations in the right place.
bbl & 16:37
timotimo that's probably sanity tests then? 16:38
nwc10 how could I run the NQP tests using the stage 0 NQP? 18:18
oh, do I even need to? -e0 fails the same way 18:19
timotimo oh, that sounds bad 18:30
nwc10 it's very strange. -e0 fails within a couple of seconds 18:34
the first command that the NQP build runs takes 90 seconds
most curious. I have a long long value of 4294967296 18:40
which I suspect should be 0
timotimo huh? 18:41
nwc10 "live debugging"
it will hopefully all make more sense soon
nwc10 OK, this is whacko that I didn't know about 19:09
sizeof(int64_t) = 8 __alignof__(int64_t) = 8
yet if I have an int64_t in a structure, the alignment is only 4 19:10
this is x86
it's a WTF moment
timotimo the what now? 19:15
nwc10 alignment mismatch
jnthn: what code where writes to index in a MAST::Local? C code or NQP code? 19:16
I can't spot any assignment in C 19:17
FROGGS_ must be nqp
timotimo where does the alignment mismatch come from?
nwc10 that is the question I'm figuring out 19:18
but I suspect that it's a bad assumption about C ABI alignment in strucutres
japhb jnthn: Is there an update to gist.github.com/jnthn/11126125 or is that the current way you'd write that? I'm starting to think about turning pieces of that into helper routines, and want to make sure I'm working off current thinking .... 19:22
lizmat japhb: afaik, that is still current thinking 19:28
japhb lizmat: Have there been any changes in async I/O or the concurrency primitives since then? 19:29
Hmmm, looks like you've been doing some Supply work 19:30
lizmat hehe, yes :-) 19:33
ingy moarning
FROGGS_ hi ingy 19:34
lizmat ingy FROGGS_ /o
FROGGS_ o\
ingy hi all! 19:35
lizmat japhb: perhaps this discussion should be on #perl6 ?
japhb lizmat: Sure. I'm beginning to have a problem with #perl6, so it's no longer default for me, but you're right, it's more on topic there. 19:36
timotimo too much text in #perl6? 19:40
FROGGS_ timotimo: yeah, it is very hard sometimes... 19:44
japhb timotimo: Yeah. Just way too much to simultaneously be there and actually get hacking done. 19:46
12 hours of day job + 3 kids + #perl6 + hacking > capacity
timotimo i see
japhb I'd love to turn the SNR on #perl6 up a few notches (by reducing noise). But it's civil as always, I don't want to break the community. 19:47
BTW, I came to this conclusion when I just tried to keep up with #perl6 for a while -- and realized I hadn't done any good hacking done in *months*. 19:49
Sigh, sorry for turning this into #perl6-meta for half an hour. :-(
FROGGS_ *g* 19:51
jnthn back 21:01
lizmat jnthn o/
jnthn japhb: It's the current way, but .then will likely get a 2-arg version for a keep and break closure.
lizmat hmmm... intriguing thought 21:02
jnthn japhb: My expectation is that most users will be using modules built out of IO::Socket::Async rather than using it directly.
japhb: So I'm not really inclined to see it sugared greatly.
lizmat: Not sure if 2-arg version is best way, but I think we want to somehow avoid the if $res.status == Kept { ... } boilerplate. 21:03
lizmat yup
jnthn nwc10: I suspect P6opaque.c is the place that may be making the bad ABI assumption, though I don't immediately see it... 22:10

Powered by Cro and the Raku® Programming Language.

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

Thank you!