|
00:19
jnap1 joined
01:02
FROGGS_ joined
01:21
colomon joined
01:36
jnap joined
01:59
donaldh_ joined
02:25
donaldh joined
02:51
jnap joined
03:52
jnap joined
04:53
jnap joined
05:04
lue joined
05:54
jnap joined
06:54
jnap joined
08:06
lue joined,
donaldh joined,
FROGGS_ joined,
dalek joined,
lizmat joined,
hoelzro joined,
cognominal__ joined,
ashleydev joined,
cxreg joined,
odc joined,
flussence joined,
_sri joined,
timotimo joined,
brother joined,
bcode joined,
tadzik joined,
Util joined,
camelia joined,
sergot joined,
japhb joined,
jnthn joined,
xiaomiao joined,
retupmoca joined,
ChanServ joined,
nwc10 joined,
masak joined,
lee_ joined,
JimmyZ joined,
dagurval_ joined,
avar joined,
ingy joined,
moritz joined,
BinGOs joined,
colomon joined,
daxim joined,
woolfy joined,
[Coke] joined,
synopsebot joined
08:11
camelia joined,
ggoebel111113 joined,
harrow joined,
tokuhirom joined,
TimToady joined
08:56
jnap joined
|
|||
| 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 | ||
|
09:57
jnap joined
|
|||
| 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 | |||
|
10:57
jnap joined
|
|||
| 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 | ||
|
11:58
jnap joined
12:59
jnap joined
|
|||
| 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 | ||
|
14:00
jnap joined
|
|||
| 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 :) | |||
|
14:25
donaldh joined
|
|||
| 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. |
|||
|
15:00
jnap joined
|
|||
| 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 | |
|
16:01
jnap joined
|
|||
| 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 | |
|
17:02
jnap joined
18:03
jnap joined
|
|||
| 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 | |
|
18:31
zakharyas joined
|
|||
| 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 | |||
|
19:04
jnap joined
|
|||
| 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 | |||
|
19:12
benabik joined
|
|||
| 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 | |
|
20:02
zakharyas joined
20:04
jnap joined
20:37
woolfy joined
|
|||
| 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 | ||
|
21:05
jnap joined
21:17
cognominal__ joined
21:39
jnap joined
|
|||
| 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 | |
|
22:11
zakharyas joined
22:40
jnap joined
23:40
jnap joined
|
|||