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

Powered by Cro and the Raku® Programming Language.

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

Thank you!