01:31
vendethiel joined
03:02
vendethiel joined
04:32
vendethiel joined
05:01
vendethiel joined
|
|||
dalek | arVM: f12710c | paultcochrane++ | .travis.yml: Change Travis matrix option to --no-jit This is because JIT is on by default, thus only the JIT was being tested in all configurations. It was also throwing the warning that --enable-jit was obsolete and mentioning the --no-jit option, which would make sense so as to test with and without JIT. |
05:09 | |
arVM: b1fe8c1 | (Jimmy Zhuo)++ | .travis.yml: Merge pull request #205 from paultcochrane/pr/enable_jit_to_no_jit Change Travis matrix option to --no-jit 0afe1e0 | paultcochrane++ | src/6model/reprs/MVM (3 files): Initialise unset fields in MVMStorageSpec These fields were uninitialised and thus flagged as a potential problem by Coverity Scan. The nqp tests pass and this seems correct in this situation, however a code review would be a good idea to be on the safe side. |
|||
arVM: 42e66bc | (Jimmy Zhuo)++ | src/6model/reprs/MVM (3 files): Merge pull request #204 from paultcochrane/pr/set_spec_fields Initialise unset fields in MVMStorageSpec |
|||
arVM: 56dcbaa | (Francois Perrad)++ | / (2 files): enforce C99 compliance needs -D_GNU_SOURCE or -D_XOPEN_SOURCE=600 |
05:12 | ||
05:13
dalek joined
05:22
colomon joined
05:26
vendethiel joined
06:25
vendethiel joined
|
|||
jnthn | On 0afe1e0, any code reading those fields when the box type is reference is wrong anyway; they're meaningless whatever values they have in that case. | 06:28 | |
So, wasn't a bug, but don't mind the patch. | 06:29 | ||
56dcbaa is curious in that it's C89 we're targetting. | |||
07:10
zakharyas joined
|
|||
dalek | arVM: 94199b9 | jnthn++ | src/core/bytecode.c: Toss commented out code. |
07:15 | |
arVM: 052c210 | jnthn++ | docs/ChangeLog: Add 2015.04 ChangeLog entries. |
07:23 | ||
jnthn | Busy month! | ||
157 commits | 07:24 | ||
nwc10 | I failed to make 2 (more) of mine work. (So far) | ||
jnthn | There's always a next month | 07:25 | |
nwc10 | right now it's feeling like unless that's a month made of Sundays, they're not going to work. | ||
07:27
FROGGS joined
|
|||
dalek | arVM: 4ee2748 | jnthn++ | VERSION: Bump VERSION. |
07:27 | |
arVM: 3607c62 | jnthn++ | README.markdown: Tweak a README item. To better indicate what sort of things we can do, now we can do 'em. |
|||
07:28
vendethiel joined
|
|||
jnthn | I'll give folks a chance to review the README etc. | 07:28 | |
Anything from that aside, 3607c62 is what will be released in a couple of hours. | 07:29 | ||
FROGGS | jnthn++ | ||
jnthn | masak: Moar release should be in place in time :) | 07:30 | |
FROGGS | jnthn: the section "Building a Rakudo with MoarVM" mentions parrot | 07:31 | |
jnthn | Ah | ||
FROGGS | s/parrot/jvm/? | 07:32 | |
"Precise, generational, parallel, GC" -- is the last comma correct there? | |||
dalek | arVM: cdcbf43 | jnthn++ | README.markdown: Give Rakudo Configure.pl example that works. FROGGS++ |
07:33 | |
jnthn | FROGGS: It's probably an over-reaction to cdn2.thegloss.com/wp-content/upload...09/jfk.jpg :) | 07:34 | |
FROGGS | lol | 07:35 | |
dalek | arVM: 6c7541e | jnthn++ | README.markdown: Grammar tweak; FROGGS++. |
07:38 | |
nwc10 | jnthn: "Implement a more compact varint serialization format" isn't quite correct | 07:42 | |
I think it's usually *less* compact. | 07:43 | ||
(slightly) | |||
but it uses less CPU | |||
it will be more compat for values between 64 and 126 | |||
jnthn | nwc10: Better wording? "more efficient" :) | 07:45 | |
nwc10 | Yes, that seems bnetter | 07:47 | |
jnthn cvhanges it | |||
FROGGS | you guys are snilly | 07:48 | |
dalek | arVM: d56c8a6 | jnthn++ | docs/ChangeLog: Tweak varint ChangeLog entry; nwc10++. |
07:49 | |
lizmat wonders how interesting www.liblfds.org would be for MoarVM ? | 07:55 | ||
probably not, as it is already 2.5 years old :-( | 07:56 | ||
sorry for the noise | |||
jnthn | lizmat: Well, code doesn't rot with age :) | 07:57 | |
lizmat: It looks familiar, I'm sure I've looked over it before | 07:58 | ||
lizmat: But it's quite restricted | |||
e.g. | |||
"hash (add-only)" | |||
FROGGS | wasn't there an intend to to something (replace) uthash? | ||
jnthn | At some point, yes. | 07:59 | |
FROGGS | why ooc? is it inefficient? | ||
jnthn | It could be more memory efficient, but more notably it's missing sufficient randomization. | 08:00 | |
FROGGS | ahh jnthn, before I forget... can you look at my question from yesterday? irclog.perlgeek.de/moarvm/2015-04-22#i_10484760 | 08:01 | |
ahh | |||
I always wonder why we want to have randomization at all | |||
jnthn | Check for matching SC - yes | ||
Randomization - thwart DoS attacks | |||
FROGGS | where are these checks? | 08:02 | |
jnthn | See write_obj_ref | ||
Well, actually it's not "check for matching SC" | |||
It's "check for no SC and put it into the current one if so" | |||
FROGGS | ahh, nice | ||
that is what I was looking for | |||
I was thinking the check happens earlier | 08:03 | ||
jnthn | I think "packed" is the thing what nwc10++ added recently so we can store things more compact. :) | ||
No, happens during traversal | |||
FROGGS | I see | ||
veeeery nice... so I can continue now :o) | 08:04 | ||
jnthn | \o. | ||
\o/ even | |||
08:04
rurban joined
|
|||
nwc10 | Given that MoarVM isn't using shared hash keys, I suspect that randomisation could be added by storing a small (eg) 32 bit salt value for each (and every hash) | 08:15 | |
with the salt coming from a private drand48() or similar | 08:16 | ||
ie, not much effort needed | |||
because, as best I can tell/remember, the actual integer hash values are not exposed outside of the hash table code | 08:17 | ||
masak | jnthn: thank you :) | 08:33 | |
08:34
vendethiel joined
08:48
Ven joined
09:04
Ven joined
|
|||
jnthn | www.moarvm.org/releases/MoarVM-2015.04.tar.gz | 09:44 | |
masak: ^^ | |||
Will do the website updates later. | 09:45 | ||
09:58
vendethiel joined
10:04
raiph joined
11:10
vendethiel joined
|
|||
masak | \o/ | 11:21 | |
jnthn++ | |||
"Native reference related optimizations (goal: 2015.04)" | 11:22 | ||
"Optimize away unrequired native reference takes and dereferences, including over inlining boundaries." | 11:23 | ||
I'm out of touch. how much was this goal achieved? | |||
FROGGS | still todo | 11:24 | |
11:42
vendethiel joined
|
|||
FROGGS thinks about adding MVM_nuke_idx_of_sc() | 11:52 | ||
12:11
dalek joined
12:19
dalek joined
12:23
dalek joined
12:35
BinGOs joined
12:48
vendethiel joined
12:49
Ven joined
13:14
vendethiel joined
13:43
vendethiel joined
14:09
vendethiel joined
|
|||
jnthn | Yeah, missed the native ref opts. The parameterics serialization got done, and NFG is basically there. | 14:14 | |
Not wired up everywhere, but the key algos are in place. Plus we got all /NFK?[D|C]/ too and an update to Unicode 7 :) | 14:15 | ||
14:18
Ven joined
14:49
FROGGS joined
14:59
vendethiel joined
15:13
TimToady joined
15:33
vendethiel joined
15:50
brrt joined
|
|||
brrt | \o | 15:50 | |
jnthn | o/ brrt | 15:51 | |
I see you're now up to 7 comments on the JIT proposal :) | 15:52 | ||
brrt | yes :-) and all positive | 15:53 | |
i'd better start reading intel docs then :-) | |||
i think what you said about using the jit as a stepping-stone as it were for small-bigints, nativecall, etc.. that has a lot of potential | 15:55 | ||
jnthn | *nod* | ||
Well, they also can produce expression trees. | 15:56 | ||
15:57
vendethiel joined
|
|||
brrt | right. expression trees should be much more ... malleable (i think) | 16:02 | |
i'm off for an errand | 16:15 | ||
16:27
vendethiel joined
16:46
brrt joined
16:59
vendethiel joined
18:08
vendethiel joined
|
|||
FROGGS | jnthn: do you want to answer? github.com/MoarVM/MoarVM/pull/202#...t-95679004 | 18:53 | |
19:11
brrt joined
19:24
zakharyas joined
21:42
Peter_R joined
21:50
pyrimidine joined
22:15
vendethiel joined
22:28
Peter_R joined
22:44
LLamaRider joined
23:15
vendethiel joined
23:41
vendethiel joined
23:54
danaj joined
|