|
02:06
colomon joined
02:48
ilbot3 joined
02:51
colomon joined
06:04
harrow joined
|
|||
| FROGGS happily deletes a lot of jnthn's code | 09:10 | ||
|
09:12
sivoais joined
09:22
vendethiel joined
09:38
woolfy joined,
woolfy left
|
|||
| FROGGS | jnthn: the segfault from yesterday can be turned off by doing: | 10:06 | |
| src/spesh/log.c:61 @@ void MVM_spesh_log_add_logging(MVMThreadContext *tc, MVMSpeshGraph *g, MVMint32 | |||
| - case MVM_OP_getlexstatic_o: | |||
| + //~ case MVM_OP_getlexstatic_o: | |||
| jnthn: does that make any sense to you? | |||
| m: use Test; class Foo { method bar { } }; my $foo = Foo.new; my @a = <a b c d>; sub baz(|) { ok $foo.bar, "bar" }; for @a { for @a { baz @a } } | 10:07 | ||
| camelia | rakudo-moar 7f2085: OUTPUT«(signal SEGV)not ok 1 - bar# Failed test 'bar'# at /tmp/9vhi17JrwM line 1not ok 2 - bar# Failed test 'bar'# at /tmp/9vhi17JrwM line 1not ok 3 - bar# Failed test 'bar'# at /tmp/9vhi17JrwM line 1not ok 4 - bar# Faile…» | ||
| FROGGS | this one | ||
| the funny thing is that the logging itself seems to trigger it | 10:11 | ||
| commenting out the case MVM_OP_getlexstatic_o in optimize.c does not change anything | 10:12 | ||
| I dunno how to continue from here :o( | 10:27 | ||
| jnthn | FROGGS: Doesn't make much sense to me that logging would do it, no... :S | 11:08 | |
| FROGGS: It's more likely something using the logged info is to blame | 11:09 | ||
| FROGGS | hmmm | ||
| jnthn | in facts.c there's a log_facts that incorporates the facts from the logs. Commenting the call to that will help test that hypothesis. | 11:10 | |
| FROGGS | do you mean I shall comment out this one? | 11:12 | |
| //~ if (po != MVM_OP_getlexstatic_o && po != MVM_OP_getlexperinvtype_o) | |||
| //~ log_facts(tc, g, bb, ins); | |||
| jnthn | Yes | 11:13 | |
| FROGGS | that does not change anything | ||
| jnthn | Hmmm | ||
| FROGGS | I commented out every mention of MVM_OP_getlexstatic_o, and only the one in log.c makes the error go away | 11:14 | |
| jnthn | o.O | 11:16 | |
| That's really odd. | |||
| FROGGS | aye | ||
| that's my conclusion also :o9 | |||
| :o) | |||
| jnthn | I want to continue on natives stuff at the moment | 11:17 | |
| Is there an issue for this bug? | |||
| Looks like now | |||
| *not | |||
| jnthn added one and linked the irc log from above | 11:18 | ||
| FROGGS | jnthn++ | 11:19 | |
|
11:32
tgt joined
11:59
rurban__ joined
|
|||
| dalek | arVM/native-ref: eecd6ee | jnthn++ | src/ (3 files): Implement native attribute reference taking ops. This is an initial, basic, implementation; we'll be able to make it a bit more performant in a few ways later (without any outside API changes, which is the key thing). |
12:00 | |
|
12:08
colomon joined
|
|||
| dalek | arVM/native-ref: 77b0480 | jnthn++ | src/6model/reprs/NativeRef. (2 files): Stub native reference read functions. |
12:37 | |
| arVM/native-ref: 8d142cd | jnthn++ | src/6model/containers.c: Flesh out native ref container fetch functions. |
|||
| arVM/native-ref: 59ef11f | jnthn++ | src/6model/reprs/NativeRef.c: Implement native ref reading. |
|||
| arVM/native-ref: ec64685 | jnthn++ | src/6model/reprs/NativeRef. (2 files): Stub native reference write functions. |
12:54 | ||
| arVM/native-ref: b759791 | jnthn++ | src/6model/containers.c: Implement native ref container store functions. |
|||
| arVM/native-ref: 407a85f | jnthn++ | src/6model/reprs/NativeRef.c: Implement native ref attribute writing. |
13:01 | ||
|
14:09
tgt joined
14:45
rurban__ joined
14:46
lue joined
14:50
[Coke] joined
|
|||
| dalek | arVM/native-ref: cebc244 | jnthn++ | src/ (3 files): Implement ops for taking positional references. |
15:17 | |
| arVM/native-ref: 732696c | jnthn++ | src/6model/reprs/NativeRef.c: Implement positional ref read/write. |
|||
|
15:33
colomon joined
16:05
harrow joined
16:49
colomon joined
|
|||
| jnthn | lexrefs, y u no work... | 17:13 | |
| Ah, they do, but the Rakudo optimizer doesn't know not to optimize lexicals out when I use the ref-taking by name op. Fair enough. | 17:23 | ||
| timotimo | good catch. that means we will have $x++ ob native types work? | 17:24 | |
| dalek | arVM/native-ref: eb2e520 | jnthn++ | src/6model/reprs/NativeRef.c: Native lexical ref read/write functions. |
||
| arVM/native-ref: ca82f8a | jnthn++ | src/ (3 files): Stub native lexical ref taking ops. |
|||
| arVM/native-ref: ba84cf3 | jnthn++ | src/6model/reprs/NativeRef.c: Implement native lexical reference by name ops. |
|||
| jnthn | timotimo: Well, I've several more steps to get us there. | ||
| timotimo: But yeah, hopefully by tomorrow we have that bit. | |||
| Already today got us rw accessors for native attrs and fixed the Buf assignability problem somewhat :) | 17:25 | ||
| timotimo | \o/ | 17:39 | |
| i like to hear that | |||
| much closer to Struct-like classes now | 17:40 | ||
|
18:30
FROGGS[mobile] joined
19:14
colomon joined
19:33
zakharyas joined
19:35
colomon joined
20:12
FROGGS[mobile]2 joined
|
|||
| FROGGS | jnthn++ # :o) | 20:13 | |
|
20:21
V_S_C joined
|
|||
| timotimo | jnthn: would you like to tell me about what stuff could be optimized with the native-ref branch in spesh? or perhaps tell about the "generate an accessor/... for me please, dear VM" thing | 20:40 | |
| or perhaps you have a clever idea for how to compile BUILDPLAN and BUILDALLPLAN to actual code | |||
| is that all we were thinking of? buildplan, buildallplan and accessor methods? | 20:42 | ||
| jnthn | Yeah. I was thinking of providing some compiler services API that can be used for this. | 20:48 | |
| And it's only available if you're currently at compile time | |||
| timotimo | who gets to decide? :D | 20:49 | |
| jnthn | Basically it'd mostly use code available in Perl6::Actions and Perl6::World | ||
| "The compiler" :) | |||
| I think we can do it with a contextual *if* we're careful. | |||
| timotimo | how about composing stuff for classes with the MOP? | 20:50 | |
| that's not at compile time … | |||
| jnthn | Then we fall back to the existing approach | 20:51 | |
| If you do your generation at BEGIN time, you get the fast stuff | |||
| timotimo | OK :) | ||
| well, if my ADT module generates the classes when it gets use'd by something else, it's at run time during compile time | 20:54 | ||
| so it should be fine, i guess? | |||
| jnthn | That's runtime of the module | 20:57 | |
| Not sure if we can get away with that | |||
| timotimo | hehe. | ||
| i wouldn't get BEGIN time inside the module multiple times if there's multiple different use lines, so that's not so awesome | 20:59 | ||
|
21:18
sivoais joined
22:04
FROGGS_ joined,
ChanServ joined
|
|||
| FROGGS | dalek: ? | 22:46 | |
| I lust committed: updating dyncall (still 0.9) and libuv (0.11.29 to 1.0.0) | 22:47 | ||
| review: github.com/MoarVM/MoarVM/commit/79...34c787f254 | |||
| @all: please test... works perfectly on my linux box | 22:48 | ||
|
22:48
d4l3k_ joined
|
|||
| timotimo | cool. any interesting features? | 22:49 | |
| FROGGS | and yes, libuv made their 1.0.0 release, so it is important for us to test it, since this will be packaged and we perhaps have to live with that for a while | ||
| timotimo | or important bugfixes? | ||
| FROGGS | read the top 139 lines here: github.com/joyent/libuv/blob/master/ChangeLog | 22:50 | |
| mostly (minor?) fixes and docs | |||
| for dyncall it is just build system stuff I think: github.com/MoarVM/dyncall/compare/......903ef9c | 22:51 | ||
|
22:51
ingy joined
|
|||
| timotimo | OK | 22:51 | |
| well, it's still good everything is good | |||
|
22:52
harrow joined
|
|||
| FROGGS | aye | 22:52 | |
|
23:02
Util joined
23:09
zakharyas joined
|
|||