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
|