Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-08

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

All times shown according to UTC.

Time Nick Message
00:38 danaj 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
02:11 vendethiel joined #moarvm
02:31 colomon joined #moarvm
02:35 colomon joined #moarvm
05:22 pyrimidine joined #moarvm
07:34 FROGGS joined #moarvm
07:52 zakharyas joined #moarvm
08:17 brrt joined #moarvm
08:17 brrt timotimo: you can merge jit_devirt_reprops_4 if you wish
08:24 brrt btw, i suppose you've all seen https://github.com/hintjens/zs
08:25 brrt i have one thing to say..... does the author think we've regressed since the 80's with direct threaded interpreters?
08:26 brrt i mean, why even encode an interpretation mode in your language
09:09 timotimo i havent seen it
09:14 brrt wants to be javascript, but based on forth and zeromq
09:14 brrt it's a bad idea
09:56 timotimo zeromq? how does that fit?
10:49 vendethiel joined #moarvm
11:09 brrt it does not :-)
11:14 timotimo No recursive descent parsers either. A language that needs recursion to parse it is too complex.  ← huh?
11:16 timotimo "I don't see why regular expressions, commands, keystrokes, or template code should have different syntaxes. They're all text." - wow, that goes in the complete opposite direction from perl6
11:17 brrt i don't see why we can't all just write lisp, forth, or failing that, assembly language
11:17 brrt :-P
11:17 brrt i mean
11:19 brrt complexity is additive, thus complexity of your program is the complexity of the language + the complexity of your code, therefore a complex language will always yield more complex programs, q.e.d
11:19 brrt (find the five logic flaws)
11:38 dalek Heuristic branch merge: pushed 32 commits to MoarVM by timo
11:38 timotimo thank you, brrt
11:38 timotimo ... 32 commits?
11:38 timotimo oh my
11:40 brrt yes
11:40 brrt long list
11:40 brrt hard work
11:41 brrt perchance a non-ff merge?
11:41 timotimo oh
11:41 brrt oh, no, oh well :-)
11:42 timotimo i can still put a non-ff merge commit on top
11:42 brrt yeah, but it doesn't matter all that much
11:42 timotimo hm
11:42 brrt although maybe it matters for disecting
11:42 vendethiel joined #moarvm
11:44 brrt i can fix it i think, if you want
11:44 timotimo oh?
11:45 timotimo it'd be a great help if you gave me the commit id that was pre-merge
11:45 timotimo i seem to lack my favourite git log alias
11:45 dalek MoarVM: 9ffd57c | brrt++ | src/ (4 files):
11:45 dalek MoarVM: Merge remote-tracking branch 'origin/jit_devirt_reprops_4'
11:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9ffd57c317
11:45 timotimo perfect
11:45 brrt 1475976 was your commit :-)
11:46 brrt that was easier than i thoughth, no forcing was required
11:46 timotimo of course not
11:46 timotimo :)
11:47 timotimo what should i do next-ish?
11:47 brrt eh...
11:47 timotimo i don't feel like working on UDP sockets again
11:47 brrt what do you want to do, and how much time do you have for it
11:47 timotimo i want perl6 to be better :P
11:47 brrt right. so do i :-)
11:48 brrt that said, i wouldnt know how to do anything about the nqp/rakudo stack
11:48 brrt tracing has been on my mind, but it's more complex than it looks in some cases
11:48 timotimo most probably
11:48 FROGGS timotimo: you are more interested in C stuff, right?
11:48 brrt do we have something like a shared wiki page where we can dump ideas?
11:49 timotimo more in C than in what?
11:49 FROGGS Perl 6
11:49 brrt (when i say it's more complex than it looks, that means i think i've some unresolved issues, not that it's nearly impossible)
11:49 FROGGS like, you seem to be more interesting in tuning MoarVM than working on nqp/rakudo itself
11:49 timotimo i like both
11:50 FROGGS timotimo: well, then grepping for #?rakudo in roast might be inspiring... it is at least for me
11:51 brrt roadmap says nativeref optimization would be desirable
11:51 brrt i'd.... think that would be doable, but not very small
11:52 timotimo i've been banging my head against trying to get local/localref code-gen working properly
11:52 timotimo that's more or less a prerequisite to having nativeref optimizations have a big effect, i think?
11:53 timotimo well, i suppose it can make lexicalref things better, too
11:57 brrt alright, lets rubber duck a bit :-)
11:57 brrt what does local/localref do
11:57 timotimo right, the thing i'm talking about is having a variable that's defined to be a local accessed somewhere in a scope set to localref
11:58 timotimo or the other way around, having a variable that's defined to be a localref accessed as a local
11:58 timotimo currently, the code-gen for one of these cases throws a bogus instruction right in the middle of the code that makes things blow up
11:59 brrt ok, is that always the same bogus instruction?
11:59 brrt do you know what inserts it?
11:59 timotimo i haven't found what inserts it
11:59 timotimo gimme a second, i'll find it for you again
11:59 brrt :-D
12:00 timotimo i mean, find what instruction it is
12:01 brrt right
12:01 brrt my next question would be, are you sure the information in the oplist is correct
12:02 timotimo bleh, gnome3 just stole my mouse
12:03 timotimo hum
12:03 timotimo this is an output i don't remember seeing
12:04 timotimo not ok 1 - localref of type int with value 23 assigned to itQAST::Var with scope 'localref' NYI
12:04 timotimo QAST::Var with scope 'localref' NYI
12:04 timotimo ... what?
12:04 timotimo didn't i just implement that ...
12:06 timotimo well, anyway ... the code is in "mast_localref_2"
12:06 timotimo in t/moar/02*t
12:07 timotimo i'll be AFK for a bit
12:10 brrt ok, that's the branch?
12:33 timotimo yes, that's right
12:36 timotimo ah, i know what i did wrong
12:36 timotimo i ran "make" instead of "make install"
12:37 brrt :-D
12:38 brrt that is a moarvm branch, right
12:38 brrt because i can't fetch it
12:40 timotimo no, an nqp branch
12:40 timotimo not ok 4 - a localref'd var can have a local ref'd thing bound to it and accessed (str)Cannot assign to an immutable value
12:40 timotimo moar doesn't even have a t/ :)
12:42 brrt quite true
12:42 brrt which is probably right, and probably wrong, at the same time
12:47 timotimo check this
12:47 timotimo https://gist.github.com/timo/ac81c1ee775152202e23
12:48 timotimo you see that decont_s there?
12:49 timotimo we're getting the string out of the strlexref, boxing it into a Str and trying to assign to that Str box
12:49 timotimo which ... wat
12:49 timotimo oh, hold on
12:50 timotimo maybe decl'ing a localref with :returns(str) is the culprit?
12:50 timotimo removing that gets rid of the bogus str boxing at least
12:51 timotimo gist updated
13:00 brrt let me see
13:01 brrt not sure i fully understand...
13:02 timotimo that's what i'm here for
13:03 timotimo isn't it fun when the duck and duckee switch places? :P
13:04 timotimo ah
13:04 timotimo sorry, the explanation was wrong
13:04 timotimo what i really wanted to point out was this:
13:04 timotimo assign_s is trying to assign into a register that hasn't been set up with anything
13:04 timotimo er
13:04 timotimo that's also not true
13:05 timotimo but why does it decont? :(
13:15 brrt for safety
13:16 cygx joined #moarvm
13:17 timotimo i just dcon't understand
13:17 cygx should dynload on windows be patched to use something like LoadLibraryExA(libPath, NULL, LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS) instead of plain LoadLibraryA(libPath)?
13:18 brrt ok, the decont takes the string out of the localref and into r2
13:18 cygx LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR seems a reasonable thing to have
13:18 brrt const_s stores 'hooray' into in r3
13:18 brrt assign_s assigns r3 into r2, which is impossible, because r2 holds a string and not a container
13:19 brrt what it should be, i think, is assign(r1, r3)
13:19 brrt cygx: sorry, our resident windows expert is at osdc.no i'm afraid :-)
13:20 brrt if that goes on to search for libs in directories it is a nice-to-have and also a security risk,
13:20 brrt possibly the dynload folks know the tradeoff there
13:21 cygx brrt: the alternative is to tell your users to add to their PATH
13:31 timotimo that's what it should be, yeah, brrt
13:32 timotimo it's also strange that moar emits a decont rather than a decont_s
13:32 timotimo how does that even work?
13:32 brrt you tell me
13:32 brrt :-)
13:33 brrt do you think this is a bug in moarvm level codegen? but that seems unlikely imho
13:34 timotimo it's in nqp
13:34 timotimo all moar does is turn a MAST into bytecode
13:34 timotimo i hope i didn't give you the impression i was looking at moar's internals to fix this
13:40 rurban joined #moarvm
13:41 brrt ah, ok
13:41 brrt could've been moar :-)
13:42 brrt but yeah, i'm afraid i'm rather unhelpful here
13:43 timotimo aaw
13:46 brrt i know very little about nqp except how to use it
13:47 brrt but anyway, that codegen is certainly of whack
13:48 timotimo good to know i'm not just hallucinating the problem
13:54 cygx .tell jnthn dynload might need patching: https://github.com/MoarVM/MoarVM/issues/214
13:54 cygx no msg bot?
13:56 timotimo only in #perl6 so far
13:58 timotimo BBL
14:06 jepeway joined #moarvm
14:08 brrt no, no message bot here
14:12 * cygx needs to go
14:12 cygx o/
14:12 cygx left #moarvm
14:19 brrt \o
14:20 brrt oh, too late
15:12 FROGGS joined #moarvm
15:16 lizmat joined #moarvm
15:38 jnthn oh noes...
15:38 jnthn compiling graph.c explodes on MSVC
15:42 lizmat on to the venue&
15:47 dalek MoarVM: 2015f07 | jnthn++ | src/jit/graph.c:
15:47 dalek MoarVM: Unbust the MSVC build.
15:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2015f07607
15:47 jnthn t stillf djfd 3 warnings
15:47 jnthn ...
15:48 jnthn It still gives 3 warnings.
16:18 dlem joined #moarvm
16:18 dlem \o/
16:22 dlem jnthn: I have looked more closely into the matter on the time spent on UTF-8 decoding.
16:23 dlem Unfortunately I won't be able to make it to the OSDC - I've been hit by the flu and am just now starting to recover.
16:24 dlem Anyway, here goes:
16:25 dlem 1: The three first functions in utf8.c should be marked MVM_STATIC_INLINE
16:28 dlem 2: The CHAR/NONCHAR distinction is incorrect, see http://www.unicode.org/versions/corrigendum9.html
16:29 dlem (I should rather say; NONCHAR must not be disallowed!)
16:36 colomon joined #moarvm
16:38 dlem 3: I have implemented The World's Fastest UTF-8 Decoder (TM) ;-), however this probably won't improve things that much for you - the decoding itself is already so fast that loop overhead and pipeline stalls may take longer time.
16:59 dlem joined #moarvm
19:11 arnsholt joined #moarvm
20:05 nebuchadnezzar mazette! nqp “make test” is somewhat faster on moar than on jvm ;-)
20:05 nebuchadnezzar 14 wallclock secs for MoarVM and 491 wallclock secs for JVM
20:06 nebuchadnezzar arf, 6 t/hll/06-sprintf.t tests failes: Failed tests:  75-80
20:07 FROGGS nebuchadnezzar: what os are you on?
20:07 FROGGS I think we had sprintf tests on freebsd only
20:08 nebuchadnezzar FROGGS: Debian, in a schroot
20:08 FROGGS hmmmm, strange
20:08 nebuchadnezzar FROGGS: I try to update the packaging of nqp since MoarVM is waiting in new queue of Debian
20:08 FROGGS 32bit by chance?
20:09 nebuchadnezzar 64
20:09 FROGGS ahh, packager you are
20:09 nebuchadnezzar yes
20:09 FROGGS then you probably use your packaged libtommath, which misses important patches
20:10 FROGGS nebuchadnezzar: read https://github.com/perl6/nqp/issues/234
20:11 nebuchadnezzar ok, dod is my mentor and I did not notice is work, shame on me :-/
20:11 FROGGS :o)
20:11 FROGGS np
20:14 nebuchadnezzar erf, no release of libtommath since 23 Jul 2010
20:14 nebuchadnezzar and dod already did the job https://github.com/libtom/libtommath/issues/35 :-D
23:33 lizmat joined #moarvm
23:37 japhb Anyone happen to know if the .so file installation under panda got fixed?
23:38 timotimo i haven't kept sufficiently close tabs
23:40 timotimo i haven't run benchmarks in a long time, i think
23:41 timotimo but right now "turning lexicals into locals" is not really in effect, so we are sort of in the "pre-lowering era" again
23:41 timotimo and that makes me sad

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