|
00:05
eternaleye joined
02:40
woosley joined
03:03
FROGGS joined
07:19
brrt joined
07:27
woosley joined
08:09
zakharyas joined
|
|||
| brrt | hi #moarvm | 10:51 | |
| nwc10 | hi brrt | 10:52 | |
| brrt | hi nwc10 | 10:53 | |
| anybody seen my pull request? :-) | |||
|
11:56
woolfy1 joined
12:31
colomon joined
13:12
colomon joined
14:04
btyler joined
14:17
jnap joined
14:26
zakharyas joined
14:37
FROGGS joined
|
|||
| dalek | arVM: c5f3b53 | (David Warring [email@hidden.address] | src/core/interp.c: check for invalid code points (jvm port) |
14:44 | |
| arVM: 24ff37d | jonathan++ | src/core/interp.c: Merge pull request #80 from dwarring/master chr() check for invalid code points (jvm port) |
|||
|
14:50
zakharyas joined
14:51
jnap joined
|
|||
| jnthn has trouble figuring out if brrt++'s pull request is correct at first glance... | 14:55 | ||
| I mean, github.com/MoarVM/MoarVM/blob/mast...ots.c#L249 does a similar compaction job with a lot less code. | 14:56 | ||
| And is much more obviously correct to me. | |||
| I think the patch is doing the same 2-finger approach, it's just less clear. | 14:57 | ||
| JimmyZ agrees | 15:07 | ||
|
15:27
jnap1 joined
15:33
cognominal joined
15:35
brrt joined
|
|||
| JimmyZ | jnthn: Is this useful? gist.github.com/zhuomingliang/9742792 | 15:43 | |
| lizmat | jnthn is just boarding his flight... will be offline for a few hours, afaik | 15:44 | |
| brrt | jimmyz - i'm not really sure that is correct | 15:47 | |
| oh, wait, read it wrong | 15:48 | ||
| no matter | |||
| JimmyZ | :) | 15:55 | |
| brrt | anyway, on the ticket i described an ever better way to compact arrays | ||
| start seeking nonenmpty elements at the ent | 15:56 | ||
| end | |||
| (and empty elements at the beginning) | |||
| you'll be done when nonempty < empty | |||
| JimmyZ | Is it better Time Complexity? | 15:57 | |
| good night | |||
| brrt | identical time complexity | 15:59 | |
| average running time is what i expect to be less | |||
| good night, by the way :-) | |||
| basically, if the array of n elements is filled to X% | |||
| the algorithm that jnthn posted will do (1+x)*n incremeents and x*n swaps | 16:01 | ||
| in the algorithm i propose.. it kind of depends on how much the list is 'weighed' to the right | 16:02 | ||
| .. but as far as i can see it can only do x*n swaps and n increment / decrements | |||
| which is ever so slightly cheaper :-) | |||
| cognominal | we need to implement multithreaded concurrent jnthns | 16:13 | |
| brrt | as long as they communicate by message passing | 16:19 | |
|
16:31
brrt left
|
|||
| tadzik | is there a way to produce a statically linked moarvm? | 18:23 | |
| OH WOW | 18:24 | ||
| I .tar.xz-ed the moarvm+rakudo bundle, now it takes 2.2MB instead of 22 | 18:25 | ||
| when I use gzip it's 4.2 MB | |||
|
18:28
btyler joined
|
|||
| FROGGS | nice! | 18:40 | |
| tadzik | I wonder which files gain the most | ||
| "gain" | |||
|
18:41
zakharyas joined
|
|||
| nwc10 | tadzik: I think that it is possible to build a static MoarVM, but then there's no way to link in the extra ops Rakudo compiles. | 18:59 | |
| it's not as flexible as perl 5 (yet) | |||
| tadzik | ah | 19:00 | |
| well, I can always bundle libmoar.so and adjust LD_LIBRARY_PATH or something | |||
| FROGGS | tadzik: IMO when you preload that lib, you don't need LD_LIBRARY_PATH | 19:12 | |
| there is a LD_PRELOAD_LIBS IIRC, and that was kinda helpful on bsd or osx | 19:13 | ||
|
19:34
btyler joined
19:35
jnap joined
|
|||
| tadzik | oh, nice | 20:42 | |
|
20:55
brrt joined
21:23
cognominal joined
21:29
jnap1 joined
21:50
brrt left
22:46
colomon joined
|
|||