00:04 lue joined 01:39 JimmyZ joined 01:48 ilbot3 joined 04:45 ggoebel11111111 joined 06:05 nebuchadnezzar joined 07:02 FROGGS joined 07:22 rurban joined 07:48 zakharyas joined 08:09 kjs_ joined 08:13 brrt joined
brrt \o 08:13
rurban \i 08:24
brrt \i ?
:-)
rurban rewrote now almost all of imcc string handling, now also allowing and efficiently handling STRINGNULL, hashes can hold now \0 08:25
\i is also illegal
moar is so much cleaner than imcc 08:26
brrt imcc was a parrot construct for intermedia code right 08:33
JimmyZ parrot won't be bad if gist.github.com/pmichaud/1201282 is on the way and pmcs is ripped out 08:34
well, there is a branch that doesn't use pir for rakudo?
which use packfile or something?
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:41
And a precise GC is not needed with our threads now 08:42
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?
rurban success 08:45
we just found one more optimization possibility, rip out unnecessary autoboxing which we will later 08:46
brrt good :-)
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
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
brrt i thought the idea of m0 would be something that would be really easy to JIT
JimmyZ yeah, but m1 is not easy to call C function too
brrt well... that's just ironic isn't it
ok, i'll be honest. i'm really ambivalent about projected succes of parrot 08:50
i think parrot is an awesome idea
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
brrt also given that the set of dynamic languages is a changing thing
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
consider why 6model was in nqp but not in parrot 08:53
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:56
moritz pmichaud still develops parrot? 08:59
brrt i thought he does? that's his github file right?
i don't know
moritz git log --author=pmichaud says one commit Oct 2013, one Apr 2012, end then some from 2011 09:00
brrt well.. then he doesn't :-) 09:01
09:07 brrt joined
rurban nope, it's only me and Chirag currently 09:08
09:33 FROGGS joined 10:58 zakharyas joined 12:14 colomon joined 12:35 rurban joined 13:10 flaviusb joined 13:15 JimmyZ joined
pmichaud I haven't considered myself a parrot developer for a long time. :) 13:32
also, NQP does have the goal of being a platform for running many dynamic languages.
We just haven't put too much emphasis on that part yet 13:33
rurban :)
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:34
JimmyZ well, we have php/ruby on NQP too 13:36
:P
brrt rubyish does seem a bit weird name 13:37
:-p
looks a bit like some other word
rurban yes
13:38 brrt joined
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
and then passing values between languages
i don't see any 'good' solution there, just different choices
rurban there cannot be good solutions for different sorts of equal, cmp and false 13:42
jnthn brrt: You think you're first to spot that pun? :-) 13:44
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
Though it's kinda cool it has :)
brrt no :-P
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)
yeah, but my point is - you /can't/ do better than that really, because you'll run into the land of great confusion
also, i agree with ruby-ish being cool
:-) 13:48
14:42 kjs_ joined
brrt i'm curious. how do you plan to do escape analysis on bytecode level? using the ssa form in spesh? 15:02
what will that give you?
jnthn brrt: Yeah, the EA papers I've looked at seem quite consistent in wanting SSA. 15:10
And in applying the analysis at something close to bytecode level. 15:11
Essentially for each allocation point you end up computing if it escapes or not.
brrt hmm
i think i see how that can be done in spesh, yes 15:12
that said, what will you do with that information? have a special allocator for non-escaping objects?
if so, i like that idea 15:13
moritz like, the stack? :-)
well, maybe not
but something very similar
brrt but /me already wants a stack allocation system for frames 15:15
and cheap frames
and... that's just all very complicated
also... what about continuations
moritz
.oO( escape analysis for frames )
 15:17
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
hmm... no that's not what i mean moritz
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?
brrt i don't think there's just one :-) 15:21
JimmyZ ea in jvm is on the same level 15:22
brrt i see
i had not realized that :-)
15:36 itz joined
hoelzro o/ #moarvm 16:31
16:36 cognome joined 17:04 kjs_ joined 17:31 cognome joined 17:46 FROGGS[mobile] joined 18:16 kjs_ joined 18:44 colomon joined 18:48 Sudogds joined 18:54 ilbot3 joined 18:55 zakharyas joined
moritz could somebody please review (and possibly merge) github.com/MoarVM/MoarVM/pull/126 ? 19:05
19:10 itz_ joined 19:21 FROGGS[mobile] joined
jnthn Any patch that makes a "hammer time" pun has gotta be awesome :P 19:27
+1 to merge, I think
It's ifdef'd to the hilt, so I can't see it breaking any platforms...
dalek arVM: ef468fd | Carlin++ | src/io/signals.h:
Add more signal code definitions
 19:28
arVM: a265d01 | Carlin++ | src/io/signals.c:
Add more signal handlers
arVM: 2f3ce09 | jonathan++ | src/io/signals. (2 files):
Merge pull request #126 from carbin/moar-signals

Handle more signals
jnthn Builds fine on Windows fwiw. :) 19:29
19:32 vendethiel joined 19:39 vendethiel- joined 20:05 FROGGS[mobile] joined 20:17 njmurphy joined 20:23 itz joined 20:31 colomon joined 20:49 kjs_ joined 21:06 FROGGS[mobile] joined 21:19 kjs_ joined
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
timotimo at least in that case building the cached hash code is simple 21:31
but i think we still flatten strings out before even looking to see if there's a cached hash code, no?
jnthn Did you measure how often we get 'em? 21:32
timotimo get single-element strigns you mean?
jnthn yes 21:33
timotimo not yet
best place would be in the constructor?
hm. no, not really
jnthn Not sure there is a single good place...hm.
timotimo don't think there is 21:34
jnthn Wait, does your gdb plug-in not support analyzing the strings in the heap?
Could look at the histogram on that to find out?
timotimo in theory yes
i haven't maintained that in a bit 21:35
and it's also very slow if you set it to check 100% of the gen2 rather than just sample a bit of it
dalek arVM: 55508a7 | TimToady++ | src/6model/reprs/NFA.c:
arrange to strip out lit length after use
 21:44
arVM: df05cf3 | TimToady++ | src/6model/reprs/NFA.c:
tabs -> spaces fixup
22:29 vendethiel joined 23:34 woolfy left 23:35 woolfy joined
carlin wut that signal stuff got merged 23:55
my evil plan to get an HC Hammer reference into moarvm is complete 23:56
jnthn Congrats. :P

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!