|
01:14
avuserow joined
01:16
FROGGS_ joined
01:47
daxim__ joined
01:51
ilbot3 joined
01:54
Juerd joined,
go|dfish joined,
itz joined,
TimToady joined,
leedo joined,
moritz joined
01:55
go|dfish joined
03:31
vendethiel- joined
03:36
vendethiel joined
|
|||
| timotimo | given sufficient jnthntime, rakudo-jvm could become a whole deal faster right from the start, i believe | 03:48 | |
| so many cool new things we learnt in rakudo-moar that can apply to jvm as well | 03:52 | ||
| (but tbh i'd prefer jnthn time spent on moarvm :P) | 03:53 | ||
|
05:15
itz joined
06:16
FROGGS_ joined
|
|||
| FROGGS_ | timotimo: I'd also vote for 'make one thing awesome first, then the other(s)' | 06:23 | |
| timotimo: but also, we have to unbust the other backends way faster that we did in the past | |||
| it is pain in the ass to bisect codebases that are broken for 30+ commits in a row | 06:24 | ||
| perhaps we should run travis on parrot and jvm also, in case it won't timeout | 06:31 | ||
| timotimo | what's the maximum time we're allowed to keep a travis-ci instance working? | 06:35 | |
| FROGGS_ | I dunno | ||
| hmmm, perhaps there is no limit? | 06:38 | ||
| timotimo | that would be good for us | 07:10 | |
|
07:18
BinGOs joined
07:19
zakharyas joined
07:53
brrt joined
|
|||
| sergot | mo/rning | 07:57 | |
|
08:59
cognome joined
10:46
cognome joined
11:58
colomon joined
|
|||
| jnthn | Yeah, there's plenty of room for JVM improvements. :) | 12:57 | |
| (Rakudo on JVM, that is.) | |||
|
14:15
cognome joined
14:25
FROGGS joined
|
|||
| [Coke] | someone doing a moarvm release for the rakudo release? | 14:58 | |
| jnthn | Rakudo release is tomorrow, yes? | ||
| [Coke] | aye | ||
| ... and, crap, I have a meeting. | |||
| ~~ | 14:59 | ||
|
15:03
leont joined
|
|||
| leont | jnthn: so in async_read for example, an array is created, rooted in one of the if blocks, and then pushed to the work queue | 15:25 | |
| What keeps it alive when not rooted? | |||
| jnthn | The work queue is also a GC-able object | 15:26 | |
| And it is rooted (from MVMInstnace iirc) | |||
| So its being in the queue keeps it alive. | |||
| leont | Yes, but it's only pushed to the queue at the end | 15:27 | |
| FROGGS | does something allocate in between? | 15:28 | |
| jnthn | Right, but nothing can cause us to enter GC when we're outside of the MVMROOT | ||
| leont | Ah, I see | ||
| jnthn | We only ever enter the GC at certain "safe points" | ||
| An allocation request is one such point | |||
| In C code, in fact, that's pretty much the only one. | |||
| The only other way you end up there is that back branches in the interpreter check if some other thread requested we join a GC | 15:29 | ||
| Which is between instructions and thus also a natural safe point. | |||
| leont | Is that also why the array is allocated before the Task is looked up? The task could otherwise move? | 15:31 | |
| jnthn | Yes | ||
| It's certainly the case that code is often written...strategically...so as to minimize the need for MVMROOT, when clarity doesn't suffer as a result. :) | 15:32 | ||
| Generally, the less bits we need to do in C, the better. | |||
| jnthn hopes the amount of C code in MoarVM will shrink rather than grow over time :) | 15:33 | ||
| FROGGS | shrink, really? | ||
| that sounds unlikely :o) | |||
| jnthn | Well, if you can JIT native calls really well... :) | 15:34 | |
| And JIT other things just as well... | |||
| Opens up some options. | |||
| FROGGS | true | ||
| jnthn | But that's for the future, not for Rght Now. :) | ||
| FROGGS | nwc10: have already tested MoarVM on 64bit PowerPC? | 15:35 | |
|
15:38
ggoebel11111111 joined
|
|||
| dalek | arVM: 71ed8bf | jonathan++ | docs/ChangeLog: ChangeLog entries for 2014.09. |
15:43 | |
| jnthn | Please review ^^ :) | 15:48 | |
| dalek | arVM: e71e022 | jonathan++ | README.markdown: Minor README updates. |
||
| arVM: c42968a | jonathan++ | VERSION: Bump VERSION, as part of release preparation. |
|||
| jnthn | I'll do the actual cutting of the relesae tomorrow. | 15:49 | |
|
17:00
BinGOs joined
17:02
cognome joined,
btyler joined
17:03
btyler joined,
cognome joined,
ChanServ joined,
retupmoca joined,
Util joined,
diakopter joined,
sergot joined,
lue joined,
masak joined,
cxreg joined,
tadzik joined,
PerlJam joined,
[Coke] joined,
avar joined,
nine joined,
jnthn joined,
dalek joined,
carlin joined,
synopsebot joined,
jlaire joined,
nwc10 joined,
ingy joined,
oetiker joined,
pmichaud joined,
timotimo joined,
odc joined,
danaj joined,
harrow joined,
ashleyde1 joined,
japhb joined,
betterwo1ld joined,
_sri joined,
nebuchadnezzar joined,
brother joined,
hoelzro joined,
bcode joined,
woolfy joined,
flussence joined,
camelia joined,
avuserow joined,
Juerd joined,
TimToady joined,
leedo joined,
moritz joined,
go|dfish joined,
vendethiel joined,
itz joined,
colomon joined,
FROGGS joined,
leont joined,
BinGOs joined
17:10
zakharyas joined
|
|||
| [Coke] | jnthn: any worries about committing in the meantime? | 17:13 | |
| timotimo | oh, this release date kind of took my by surprise | 17:57 | |
| nwc10 | FROGGS: it SEGVs t/nativecall/01-basic.t | 18:03 | |
| which I think is to do with bad assumptions about something being 32 bit when it's actually 64 | |||
| (but I've not been digging) | |||
| FROGGS | nwc10: ahh, so it at least builds :o) | ||
| nwc10: I had guesses that we only ever tried 32bit PowerPC | |||
| nwc10 | slightly more than "at least" | ||
| FROGGS | :o) | 18:04 | |
| true | |||
| nwc10 | I don't know if anyone has tried 32 bit PowerPC | ||
| (this is MoarVM + NQP + Rakudo) | |||
| not sure if with the relevant compiler and linker flags this system can be persauded to build 32 bit | |||
| FROGGS | and it is also unlikely that I'll be able to obtain a 32bit blade once I got my bladecenter | 18:08 | |
| nwc10 | FROGGS: as for the spectest: Result: PASS | 18:12 | |
| FROGGS | very very nice | ||
| I'm eager to see it by myself :o) | 18:13 | ||
|
18:55
Ven joined
19:42
Ven joined
20:24
kjs_ joined
20:48
flussence joined,
Ven joined
21:37
colomon joined
|
|||