|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 4 June 2013. |
|||
|
00:13
kbenson1 joined
00:16
colomon joined
00:52
benabik joined
00:57
tgt joined
01:42
colomon joined
01:53
colomon joined
02:08
colomon joined
02:23
lizmat joined
03:44
FROGGS joined
04:49
colomon joined
04:59
birdwindupbird joined
05:41
birdwindupbird joined
05:50
tomyan joined
07:12
flaviusb joined
07:32
flaviusb joined
07:44
flaviusb joined
08:02
flaviusb joined
08:21
flaviusb joined
08:41
flaviusb joined
09:00
flaviusb joined
09:20
flaviusb joined
09:39
flaviusb joined
10:04
Guest1337 joined
12:32
Ulti left
13:18
sorear_ joined
13:27
JimmyZ joined
14:03
FROGGS joined
14:21
sorear joined
14:25
lizmat joined
14:32
benabik joined
|
|||
| dalek | arVM: cab28e4 | benabik++ | / (5 files): say and print should be IO ops, not dev say_[ins] are all doomed, but left as is until after removing them from the tests. |
14:35 | |
| arVM: 8652eb7 | benabik++ | nqp-cc/ (36 files): Remove say_* from tests |
|||
| arVM: ddc8699 | benabik++ | nqp-cc/src/QASTOperationsMAST.nqp: Tell QAST to use say instead of say_s |
14:36 | ||
|
14:36
colomon joined
|
|||
| benabik | Logged in just in time to see my commits merged. \\o/ | 14:38 | |
| JimmyZ | benabik++ | 14:39 | |
|
14:54
bronco_creek joined
14:58
FROGGS joined
15:00
cognominal joined
15:16
lizmat joined
15:19
cognominal joined
|
|||
| dalek | arVM: 900d1b0 | jonathan++ | src/6model/reprs/P6opaque.c: Fix GC mark offset calculation. Got the wrong answer in cases where complex inlines that are not box targets were made. Found by arnsholt++. |
15:50 | |
| jnthn | diakopter: When you get chance, plz to review github.com/MoarVM/MoarVM/pull/4 | ||
| (and merge if you agree with it) | |||
| dalek | arVM: 33abf54 | jimmy++ | / (2 files): small refactor to latin1 strings this will improve a little performance |
15:51 | |
| arVM: 4b0f9b4 | (Matthew Wilson)++ | / (2 files): Merge pull request #4 from zhuomingliang/master small refactor to latin1 strings |
|||
|
16:30
colomon joined
16:43
colomon joined
17:15
japhb_ joined
17:39
_sri joined
18:57
FROGGS joined
19:37
lizmat joined
19:38
japhb_ joined
19:40
FROGGS joined
19:47
labster joined
|
|||
| dalek | arVM: 352135e | jonathan++ | / (7 files): Rename ops; no need to creat weird spellings. |
20:19 | |
| arVM: dfcce29 | jonathan++ | nqp-cc/src/QASTOperationsMAST.nqp: Map nqp::sethllconfig. |
|||
| arVM: 41ec98a | jonathan++ | src/6model/reprs/MVMIter.c: Add missing deserialize_stable_size. |
|||
|
20:36
rurban joined
|
|||
| rurban | did you consider libgc for the GC? it has nice threads support and seems to be more precise. it walks thread-locals (the red-zone), the stack, and even loaded dll space (good for ffi'd callbacks) | 20:37 | |
| I'm considering switching over to libgc soon | |||
| diakopter | it's less precise; it's conservative | 20:38 | |
|
20:39
tomyan joined
|
|||
| jnthn | rurban: No, I decided gc is something Moar should implement itself. | 20:39 | |
| diakopter | rurban: re loaded dlls, I don't see a reason to pass moar-managed pointers to native libs | 20:40 | |
| benabik | NativeCall? | 20:41 | |
| diakopter | what about it? | ||
| Tene | Implementing a GC would be a lot of fun... | ||
| benabik | Or is NativeCall expected to use malloc? | ||
| diakopter | well, you wouldn't want to pass native libs pointers to moar objects because: what would it do with them? | ||
| jnthn | The CStruct REPR points off to a piece of unmanaged memory, which is what is shared with native-land | ||
| diakopter | oops | 20:42 | |
| well, you wouldn't want to pass moar objects pointers to native libs because: what would the native lib do with the moar pointers? | |||
| you wouldn't want it digging inside moar objects | |||
| arnsholt | Yeah, the NativeCall REPRs actually have two independent storages, one managed used by Perl 6 code and one unmanaged used by C code | 20:43 | |
| dalek | arVM: 8e18302 | jonathan++ | / (4 files): Use portable REPR names. |
||
|
20:44
bronco_creek joined
|
|||
| benabik | And the NativeCall REPRs free the unmanaged memory when the managed memory is collected? | 20:44 | |
| arnsholt | Yup | ||
| Or, can | 20:45 | ||
| tadzik | isn't DESTROY support something moar gc should be aware of? That was my impressin | ||
| jnthn | .oO( every problem can be solved with a level of indirection ) |
||
| FROGGS | jnthn: that is why we are chatting here | ||
| benabik | So NC programs just have to make sure they hold onto the memory longer than the native code. :-D | ||
| arnsholt | Right now we don't free() the unmanaged memory because C code might've taken a reference to it, but I'm working on functionality to alleviate that | ||
| benabik | Ah. | ||
| Go's response is what I just said: arrange to hold a reference longer than C code. | 20:46 | ||
| arnsholt | Essentially a flag that lets the destructor know if it should free it or not | ||
| rurban | ok, but libgc also has the nice feature to be incremental, so it can run in some thread woken up by a timer periodically, to keep the 1st generation fresh, and if takes too long stop and resume later (real-time). | 20:54 | |