Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-10-16

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:04 lue joined #moarvm
01:39 JimmyZ joined #moarvm
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
04:45 ggoebel11111111 joined #moarvm
06:05 nebuchadnezzar joined #moarvm
07:02 FROGGS joined #moarvm
07:22 rurban joined #moarvm
07:48 zakharyas joined #moarvm
08:09 kjs_ joined #moarvm
08:13 brrt joined #moarvm
08:13 brrt \o
08:24 rurban \i
08:24 brrt \i ?
08:24 brrt :-)
08:25 rurban rewrote now almost all of imcc string handling, now also allowing and efficiently handling STRINGNULL, hashes can hold now \0
08:25 rurban \i is also illegal
08:26 rurban moar is so much cleaner than imcc
08:33 brrt imcc was a parrot construct for intermedia code right
08:34 JimmyZ parrot won't be bad if https://gist.github.com/pmichaud/1201282 is on the way and pmcs is ripped out
08:34 JimmyZ well, there is a branch that doesn't use pir for rakudo?
08:34 JimmyZ which use packfile or something?
08:41 rurban JimmyZ: It's on is way, yes. PCC is already much better, 70%. Threads are done 100%, I've added Strings to this list of TODOs
08:42 rurban And a precise GC is not needed with our threads now
08:43 JimmyZ that's good, though I'm more aware of Rewriting packfile loading, ripping out pmcs files and getting 6model in :P
08:43 brrt how did the gsoc project to optimize parrot call conventions go btw?
08:45 rurban success
08:46 rurban we just found one more optimization possibility, rip out unnecessary autoboxing which we will later
08:46 brrt good :-)
08:46 JimmyZ well, another off topic of moar, I think m0/m1 has wrong architecture, because m1 is not better than C, but worse, and m0 isn't better than CPU :P
08:49 brrt i think that's not entirely the point, although i may misunderstand
08:49 JimmyZ or /than C/than GCC/MSVC/ICC/g :P
08:49 brrt i thought the idea of m0 would be something that would be really easy to JIT
08:49 JimmyZ yeah, but m1 is not easy to call C function too
08:49 brrt well... that's just ironic isn't it
08:50 brrt ok, i'll be honest. i'm really ambivalent about projected succes of parrot
08:50 brrt i think parrot is an awesome idea
08:51 brrt but that it cannot overcome the fundamental limitations in wanting to run /all/ dynamic languages
08:51 JimmyZ yeah, if she can drop the history burden :P
08:51 brrt also given that the set of dynamic languages is a changing thing
08:52 brrt it's history, yes, but it's also a fundamental impossibility of treating every different thing like it's the same
08:52 JimmyZ yeah, if she appllies revolution :P
08:53 JimmyZ consider why 6model was in nqp but not  in parrot
08:56 brrt so while i honestly whish the parrot developers - notably rurban++ and pmichaud++ - the best of luck, i can't help feeling a bit sad for the parrot idea
08:59 moritz pmichaud still develops parrot?
08:59 brrt i thought he does? that's his github file right?
08:59 brrt i don't know
09:00 moritz git log --author=pmichaud says one commit Oct 2013, one Apr 2012, end then some from 2011
09:01 brrt well.. then he doesn't :-)
09:07 brrt joined #moarvm
09:08 rurban nope, it's only me and Chirag currently
09:33 FROGGS joined #moarvm
10:58 zakharyas joined #moarvm
12:14 colomon joined #moarvm
12:35 rurban joined #moarvm
13:10 flaviusb joined #moarvm
13:15 JimmyZ joined #moarvm
13:32 pmichaud I haven't considered myself a parrot developer for a long time.  :)
13:32 pmichaud also, NQP does have the goal of being a platform for running many dynamic languages.
13:33 pmichaud We just haven't put too much emphasis on that part yet
13:33 rurban :)
13:34 jnthn Also, MoarVM is actually already better at it than Parrot, in so far as it has a mechanism for cross-HLL conversions (used between Rakudo and NQP) that can be optimized out when we (dynamically) see that the caller and callee are the same language. Oh, and it already *is* doing that optimization.
13:36 JimmyZ well, we have php/ruby on NQP too
13:36 JimmyZ :P
13:37 brrt rubyish does seem a bit weird name
13:37 brrt :-p
13:37 brrt looks a bit like some other word
13:37 rurban yes
13:38 brrt joined #moarvm
13:39 brrt jnthn: hllize is a reasonable solution for object wrappers, i think.... but i don't see how it solves the problem of some values being expected to be e.g. true in one language and false in another
13:39 brrt and then passing values between languages
13:39 brrt i don't see any 'good' solution there, just different choices
13:42 rurban there cannot be good solutions for different sorts of equal, cmp and false
13:44 jnthn brrt: You think you're first to spot that pun? :-)
13:46 jnthn The "ish" was mostly "I don't even plan to make this accurate or complete". I didn't expect it'd get a load more patches afterwards. :)
13:46 jnthn Though it's kinda cool it has :)
13:46 brrt no :-P
13:47 jnthn On hllize - yeah, it's limited, but I only really needed a mechanism to solve the problem of Rakudo <=> NQP stuff for the moment. :)
13:47 brrt (re: first-to-see-pun)
13:47 brrt yeah, but my point is - you /can't/ do better than that really, because you'll run into the land of great confusion
13:47 brrt also, i agree with ruby-ish being cool
13:48 brrt :-)
14:42 kjs_ joined #moarvm
15:02 brrt i'm curious. how do you plan to do escape analysis on bytecode level? using the ssa form in spesh?
15:02 brrt what will that give you?
15:10 jnthn brrt: Yeah, the EA papers I've looked at seem quite consistent in wanting SSA.
15:11 jnthn And in applying the analysis at something close to bytecode level.
15:11 jnthn Essentially for each allocation point you end up computing if it escapes or not.
15:11 brrt hmm
15:12 brrt i think i see how that can be done in spesh, yes
15:12 brrt that said, what will you do with that information? have a special allocator for non-escaping objects?
15:13 brrt if so, i like that idea
15:13 moritz like, the stack? :-)
15:13 moritz well, maybe not
15:13 moritz but something very similar
15:15 brrt but /me already wants a stack allocation system for frames
15:15 brrt and cheap frames
15:15 brrt and... that's just all very complicated
15:15 brrt also... what about continuations
15:17 moritz .oO( escape analysis for frames )
15:18 moritz brrt: but in most --profile's I've seen, GC times are impressively low (like, 4% to 6% of the total runtime), so it can't be that bad
15:18 brrt that can be done as long as you know all callee's
15:18 brrt hmm... no that's not what i mean moritz
15:19 brrt i mean - making and clearing mvm frame's right now is kind of a big time-user, isn't it?
15:19 JimmyZ where is the ea paper?
15:21 brrt i don't think there's just one :-)
15:22 JimmyZ ea in jvm is on the same level
15:22 brrt i see
15:22 brrt i had not realized that :-)
15:36 itz joined #moarvm
16:31 hoelzro o/ #moarvm
16:36 cognome joined #moarvm
17:04 kjs_ joined #moarvm
17:31 cognome joined #moarvm
17:46 FROGGS[mobile] joined #moarvm
18:16 kjs_ joined #moarvm
18:44 colomon joined #moarvm
18:48 Sudogds joined #moarvm
18:54 ilbot3 joined #moarvm
18:54 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
18:55 zakharyas joined #moarvm
19:05 moritz could somebody please review (and possibly merge) https://github.com/MoarVM/MoarVM/pull/126 ?
19:10 itz_ joined #moarvm
19:21 FROGGS[mobile] joined #moarvm
19:27 jnthn Any patch that makes a "hammer time" pun has gotta be awesome :P
19:27 jnthn +1 to merge, I think
19:27 jnthn It's ifdef'd to the hilt, so I can't see it breaking any platforms...
19:28 dalek MoarVM: ef468fd | Carlin++ | src/io/signals.h:
19:28 dalek MoarVM: Add more signal code definitions
19:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ef468fd04a
19:28 dalek MoarVM: a265d01 | Carlin++ | src/io/signals.c:
19:28 dalek MoarVM: Add more signal handlers
19:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a265d01ae0
19:28 dalek MoarVM: 2f3ce09 | jonathan++ | src/io/signals. (2 files):
19:28 dalek MoarVM: Merge pull request #126 from carbin/moar-signals
19:28 dalek MoarVM:
19:28 dalek MoarVM: Handle more signals
19:28 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2f3ce09559
19:29 jnthn Builds fine on Windows fwiw. :)
19:32 vendethiel joined #moarvm
19:39 vendethiel- joined #moarvm
20:05 FROGGS[mobile] joined #moarvm
20:17 njmurphy joined #moarvm
20:23 itz joined #moarvm
20:31 colomon joined #moarvm
20:49 kjs_ joined #moarvm
21:06 FROGGS[mobile] joined #moarvm
21:19 kjs_ joined #moarvm
21:29 timotimo jnthn: does it sound worth it at all to try to implement a MVMString storage type for single graphemes that doesn't have the pointer + malloc part to it?
21:29 jnthn timotimo: Hmm
21:31 timotimo at least in that case building the cached hash code is simple
21:31 timotimo but i think we still flatten strings out before even looking to see if there's a cached hash code, no?
21:32 jnthn Did you measure how often we get 'em?
21:32 timotimo get single-element strigns you mean?
21:33 jnthn yes
21:33 timotimo not yet
21:33 timotimo best place would be in the constructor?
21:33 timotimo hm. no, not really
21:33 jnthn Not sure there is a single good place...hm.
21:34 timotimo don't think there is
21:34 jnthn Wait, does your gdb plug-in not support analyzing the strings in the heap?
21:34 jnthn Could look at the histogram on that to find out?
21:34 timotimo in theory yes
21:35 timotimo i haven't maintained that in a bit
21:35 timotimo and it's also very slow if you set it to check 100% of the gen2 rather than just sample a bit of it
21:44 dalek MoarVM: 55508a7 | TimToady++ | src/6model/reprs/NFA.c:
21:44 dalek MoarVM: arrange to strip out lit length after use
21:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/55508a78ff
21:44 dalek MoarVM: df05cf3 | TimToady++ | src/6model/reprs/NFA.c:
21:44 dalek MoarVM: tabs -> spaces fixup
21:44 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/df05cf38ea
22:29 vendethiel joined #moarvm
23:34 woolfy left #moarvm
23:35 woolfy joined #moarvm
23:55 carlin wut that signal stuff got merged
23:56 carlin my evil plan to get an HC Hammer reference into moarvm is complete
23:56 jnthn Congrats. :P

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary