00:02 ilbot3 joined
jnthn timotimo: OK, go for it. :) 00:06
00:07 dalek joined, tokuhirom joined, rurban joined
jnthn Guess the commit message for the callback return values got lost :/ 00:08
timotimo i was wondering
jnthn Was github.com/MoarVM/MoarVM/commit/e6...a6554ddf64 anyways 00:09
00:10 _sri joined, FROGGS_ joined 00:11 hoelzro joined
timotimo how exactly do i build zavolaj for moar? with uf? 00:13
ufo?
00:13 tadzik joined
jnthn You could, though I've just been doing 00:14
prove --exec="perl6-m -Ilib" t
Rather than building it.
00:14 dalek joined
timotimo ah, right 00:16
jnthn Some of the C REPRs may be missing their repr data serialize functions yet too
timotimo getting the PREFIX command not found output
but all tests successfull 00:17
jnthn \o/ 00:19
timotimo but each of the tests outputs the warning about PREFIX :) 00:20
jnthn No idea what the PREFIX thingy is. Must be non-Windows-y :)
Since I don't se it at all here
00:22 tokuhirom joined
timotimo wait what. 00:22
stracing perl6-m gives me pages and pages and pages and pages and pages and pages and pages and pages of:
stat("/home/timo/perl6/rakudo/../install/languages/perl6/runtime/dynext/libperl6_ops_moar.so", {st_mode=S_IFREG|0644, st_size=305778, ...}) = 0
stat("/home/timo/perl6/rakudo/../install/languages/nqp/lib/dynext/libperl6_ops_moar.so", 0x7fff42b580e0) = -1 ENOENT (No such file or directory) 00:23
stat("/home/timo/perl6/rakudo/../install/languages/perl6/lib/dynext/libperl6_ops_moar.so", 0x7fff42b580e0) = -1 ENOENT (No such file or directory)
stat("/home/timo/perl6/rakudo/../install/languages/perl6/runtime/dynext/libperl6_ops_moar.so", {st_mode=S_IFREG|0644, st_size=305778, ...}) = 0
stat("/home/timo/perl6/rakudo/../install/languages/nqp/lib/dynext/libperl6_ops_moar.so", 0x7fff42b580e0) = -1 ENOENT (No such file or directory)
stat("/home/timo/perl6/rakudo/../install/languages/perl6/lib/dynext/libperl6_ops_moar.so", 0x7fff42b580e0) = -1 ENOENT (No such file or directory)
stat("/home/timo/perl6/rakudo/../install/languages/perl6/runtime/dynext/libperl6_ops_moar.so", {st_mode=S_IFREG|0644, st_size=305778, ...}) = 0
stat("/home/timo/perl6/rakudo/../install/languages/nqp/lib/dynext/libperl6_ops_moar.so", 0x7fff42b580e0) = -1 ENOENT (No such file or directory)
stat("/home/timo/perl6/rakudo/../install/languages/perl6/lib/dynext/libperl6_ops_moar.so", 0x7fff42b580e0) = -1 ENOENT (No such file or directory)
jnthn Wonder where those all come from o.O 00:24
Well, I need some rest. Will leave that little mystery (and probable speedup) for your hunting :)
'night 00:25
timotimo good night!
00:26 tokuhirom_ joined 00:30 rurban joined 00:37 _sri joined
timotimo "c_line" => "gcc -c -fPIC -o 01-argless.o -O1 -DNDEBUG -g3 -D_REENTRANT -D_FILE_OFFSET_BITS=64 -fPIC t/01-argless.c" 00:44
"l_line" => "gcc -shared -fPIC -O1 -DNDEBUG -g3 -Wl,-rpath,\$(PREFIX)/lib -lm -lpthread -lrt -ldl -o 01-arglesslib.so 01-argless.o"
01:12 MadHatter1987 joined 01:45 hoelzro joined 01:52 _sri joined 03:00 colomon joined 04:29 ggoebel11114 joined 04:41 ggoebel11115 joined
dalek arVM: fe23b59 | jimmy++ | / (2 files):
Restore using linenoise
 04:56
TimToady I get millions of > now :/ 05:08
JimmyZ you didn't update linenoise 05:09
TimToady it said "Fetching submodule 3rdparty/linenoise 05:10
JimmyZ try 'git clean -xdf'? 05:13
I reproduced the bug and fixed it by set STDIN to block mode 05:15
TimToady still fails after recompiling moarvm and nom; does nqp have to be recompiled? 05:20
JimmyZ hmm, Could you `cd 3rdparty/linenoise && git log` to make sure it's the newest version? 05:21
only needs to recompile moarvm 05:23
and make install
TimToady has your patch 05:25
have completely cleaned/recompiled all of moarvm/nqp/nom, still fails 05:26
is it supposed to install any kind of library? it only installs a .h 05:28
or is it already linked into moarvm 05:29
JimmyZ it linked into moarvm
TimToady ok, I see the liblinenoise.a compiled 05:30
so I think it's just not working here 05:31
JimmyZ Could you help me gdb nqp? set breakpoint to : b 3rdparty\linenoise\linenoise.c:422
TimToady doesn't break, just spews > 05:34
JimmyZ yeah, I want to know what's there in line 422 05:36
TimToady it says I don't know what that is, do you want to set breakpoint on shared library
so it's probably not finding it
JimmyZ that's not a share lib 05:37
TimToady well, it's not finding it
JimmyZ hmm
TimToady that's: gdb /home/larry/nom/install/bin/moar 05:38
then run nqp.moarvm
and that's presumably the moar that was installed, lemme double check
I may have lost my prefix somewhere 05:39
\o/ 05:40
that was it
was installing it into nqp's install dir instead of nom's 05:41
works now, JimmyZ++
JimmyZ great
TimToady thanks!
JimmyZ You can input things and press ctrl+r to search it, after ctrl+r, you can press tab to continue searching 05:44
something different from lib-readline :P
and works on widnows also
windows
06:22 vincent22 joined
nwc10 jnthn: "nearly" works on "my" machine - valgrind and ASAN spot a use-after free in the callback test: paste.scsys.co.uk/325393 07:43
ooh, and an optimised build on (at least one) x86 system didn't like 05
oh, the non-optimised build on the other x86 system was unhappy too 07:44
same 'long' problem as yesterday
07:59 FROGGS joined
nwc10 jnthn: the problem is the second free() here: 08:05
/* Clean up. */
free(args);
free(cs);
is subsequently read by this:
if (ctx->callsite->has_flattening) {
er, memory freed by that is read later by the other
I can't figure out how to fix it 08:22
08:47 colors joined 08:55 woolfy joined
nwc10 OK, only works on "my" machine if it's little endian 08:55
Unhandled exception: Bytecode validation error at offset 0, instruction 0:
invalid extension opcode 40704 - should be less than 1024
that's on a power7 machine running Fedora 08:56
this is probably not today's problem
09:17 woolfy joined 10:22 lizmat joined 10:27 lizmat joined 10:36 lizmat joined
jnthn nwc10: Probably I shoulda thought to hang the callsite off the callback cache. That'd also mean we can compute it once and re-use it... 10:51
Wil look at it in a little bit.
And yes, BE will be broken until we write a smallish patch to endian convert the bytecode on first invocatin. 10:52
FROGGS does that mean I can't compile to a CD-R? :P 10:53
jnthn You can compile to anything if you write the porting patches :P 10:55
JimmyZ jnthn: I restored linenoise... 10:57
jnthn yes, noticed... 10:58
FROGGS .oO( don't talk like that about Perl! )
jnthn :D 10:59
heh, I'd never considered the amusement of a VM for a Perl depending on linenoise :)
jnthn trying the update here 11:00
FROGGS :o)
JimmyZ well, there is a lua version for linenoise, we can write a Perl6 one too by using nativecall ... 11:01
github.com/fperrad/ljlinenoise/blo...enoise.lua FYI :P 11:09
jnthn JimmyZ: Seems to work for me. 11:14
JimmyZ \o
timotimo o/ 11:30
jnthn hi timotimo 11:31
JimmyZ Hello, moarer
timotimo "moarons"? 11:32
JimmyZ moarning
11:42 lizmat joined, woolfy joined, dalek joined
timotimo it seems like the pages and pages of stats for the perl6_ops_moar were caused by something in nativecall 11:48
maybe some result of some temporary hack
so no easy wins to be had there
12:39 vincent22 joined
dalek arVM: f55b8ed | jnthn++ | src/core/nativecall. (2 files):
Build and cache callsite once per callback.

Saves per-callback overhead, but also means lifetime of it is righter, hopefully avoiding referencing unused memory.		 13:07
jnthn nwc10: That should fix your SEGV 13:08
uh, or my SEGV
Or valgrind's complaint
Or whatever :)
JimmyZ jnthn: line CArray.c:88, Did it miss else if (repr_data->elem_kind == MVM_CARRAY_ELEM_KIND_STRING) ? 13:39
hmm, looks like the comments is wrong-ish 13:47
13:58 tgt joined
nwc10 tests 14:09
jnthn: valgrind happy for that test. ASAN build not yet there 14:18
jnthn ok
nwc10 jnthn: ASAN hapy with all 8 tests 14:23
jnthn: "righter" ?? - where was you drug up? :-) 14:24
jnthn nwc10: We never reclaim the callback cache entries at present. 14:25
nwc10 so the "cache" grows without limits until process exit? 14:26
and gotcha - it's better, but not "best" yet.
jnthn nwc10: So in the (unlikely) event you are eval'ing lots of callback routines...
...then yeah, you leak.
That's a pretty odd thing to be doing though :)
nwc10 valgrind still grumps about this: 14:30
t/05-arrays.t .......... 1/26 ==14553== Conditional jump or move depends on uninitialised value(s)
==14553== at 0x4F7CD4F: MVM_nativecall_make_cpointer (nativecall.c:171)
==14553== by 0x4FBBC43: make_wrapper (CArray.c:209)
I think that it's the test for an uninitialised pointer 14:31
jnthn Yeah, I think so 14:36
14:36 zakharyas joined
nwc10 valgrind happy with all 8 14:39
jnthn hehe...with pre-comp and --jobs=6 I can run the NativeCall tests in 2s on Moar :) 14:44
JimmyZ nmake compile is a pain when you edit a .h file 14:45
dalek arVM: ff01095 | jnthn++ | src/6model/reprs/C (4 files):
Implement missing deserialize_stable_size funcs.

With this, pre-compiling NativeCall now works.
jnthn JimmyZ: Yes, nmake is too stupid to support parallel builds :/ 14:46
JimmyZ hopes someone will split moar.h file
14:47 woolfy joined
jnthn Very much doubt that will happen. 14:48
It's not like a non-parallel build takes long.
JimmyZ gerdr said about it...
jnthn Especially as we're using link time code generation.
So much of the cost is there. 14:49
15:07 woolfy joined 15:10 brrt joined
brrt hi #moarvm 15:10
JimmyZ hello
15:11 lizmat joined
brrt 88 commits in what, 3 days? moarvm goes fast 15:12
jnthn It's due to our use of nuclear power. 15:13
timotimo it does, aye
jnthn
.oO( That's what they meant by "atomic commits", right? )
 15:15
hoelzro ba-dum tssssh 15:17
15:20 brrt joined
brrt unrelated aside - actors are basically what objects could've been if people had taken 'message passing' seriously from the start 15:28
JimmyZ brrt: you know akka? 15:37
16:11 woolfy joined 16:16 brrt joined
TimToady has never bothered to parallelize any of his makes because he has only two cores on his ancient laptop, and wants to save one core for doing other things while he's compiling :) 16:27
and does irclog.perlgeek.de/moarvm/2014-03-15#i_8440520 mean we're planning to always include lua now? :) 16:29
jnthn TimToady: No, it was just pointing out lua had a binding to liblinenoise and we could potentially get at it the same way (through native calling) rather than making Moar itself aware of it. 16:30
TimToady oic <-- channeling diakopter++ 16:32
it's obviously still too early in the morning, since I'm considering whether we should always embed lue++ as our resident AI 16:37
which would explain the reticence to reveal his True Name :)
because then we could unplug him 16:38
lizmat wonders how dangerous it is to channel diakopter++ this early in the morning 16:41
japhb__ lizmat: Safer than at midnight? 16:49
lizmat ah, probably, yes :-) 16:50
brrt wonders if moarvm doesn't have an unwieldily-sized opcode library for JITTING 16:52
in other words 16:53
maybe we should generate bytecode from a different IR than from moarvm opcodes
jnthn brrt: No, you just JIT things that contain ops you know how to JIT. 16:54
brrt: JIT should be frame level anyway.
brrt how large is a frame level?
TimToady about the same size as a frame, so maybe about as big as a house? 16:55
jnthn Method/sub/non-inlined block.
brrt right 16:56
brrt is thinking a bit
i don't think i agree entirely 16:57
that is to say, i think the biggest gains of JIT-ing in a very-high-level language such as p6 will be due to making routine calls faster 16:58
i.e. p6 has rather complex parameter binding semantics iirc
japhb__ brrt: Many opcodes for same-size functionality space is just another way of providing information to the JIT. It's when you have many opcodes that sprawl over a much larger functionality space that it gets to be painfully more work, I should think. 16:59
jnthn Yeah, though the pre-JIT specializer work will help a lot on those too. And JIT can take it a step further...
brrt but for routines that have simple parameters or that are allways called in the same manner (from a certain site) you'd want to optimise that to as simple as possible
good point japhb__ :-)
jnthn Ah, I was unclear in what I wrote, and now see what you meant.
I wasn't saying we shouldn't do inter-procedural opts, inlining, etc. 17:00
Just that we shouldn't have to be able to JIT every single op used in an entire compilation unit in order to JIT at all.
brrt i agree
but i'm not sure the bytecode format is a good 'starting point' for a JIT compiler :-) 17:01
TimToady
.oO(All ops are equal, but some are more equal than others.)
brrt i believe - totally unsure - the hotspot compiler does a form of 'decompiling' before JIT-ing
jnthn Right, nor is it for any kind of optimization, which is why the stuff I've been working on locally builds a CFG...
With instruction nodes, etc. 17:02
brrt and v8 is said to use the original source
ok i see 17:03
jnthn Which should be in SSA form also, which should help further.
brrt uhuh
brrt is only now reading the 'dragon book'
jnthn The bytecode specializer will produce bytecode with some non-userspace-accessible instruction codes based on "proofs" it can do with runtime info. I suspect a similar approach can be used in order to take things apart or re-structure them for JITting. 17:05
(At the tree level.)
brrt what bytecode specializer do you refer too? the one for moarvm-bytecode or for jit-opcode? can i read the source? :-) 17:06
jnthn brrt: The thing that's still mostly in my head, that I promise to turn into code as soon as we've got the Moar star out of the door :) 17:07
brrt: But basically, it will 1) take hot bytecode, 2) build an SSA data structure, 3) in conjunction with runtime-known stuff, produce specialized bytecode from it, and 4) turn it back into improve bytecode, registering what we assumed so we can undo it if things change. 17:09
*improved 17:10
brrt ok understood
thats still mvm-level bytecode isn't it?
again, learning from v8, it is said to use the original source + runtime information for creating specialised (native) bytecode 17:11
jnthn yes, mvm-level 17:12
brrt which is possible because memory is cheap and javascript programs are small
ok, so in that case the JIT could use some / many of the same mechanisms but not the ultimate bytecode generation
jnthn Yes, that was my design idea. :)
brrt then i understand it :-)
interesting 17:13
jnthn One reason we have a bunch of ops is to try and keep the semantic information to let us do a good job of optimizing without having source-level knowledge.
brrt ok, why don't you want source-level knowledge?
jnthn It leads to a rather tight compiler/runtime coupling.
Which if you've v8 and your language is very stable is fine. 17:14
brrt that is true, i guess
jnthn *you're
Also, JavaScript is rather smaller than Perl 6 :)
brrt also true
brrt is, by the way, a bit of angry about the 'wat' video that keeps coming up 17:15
yeah javascript is a bit over-dwimmy wrt comparisons
many languages do the same
nobody / too few people gives java a hard time about == meaning identity comparison for objects 17:16
which is just as unintuitive
jnthn I think the issue there is that you can either have static types and overload operators with different semantics, or give operators one semantic and have them coerce types freely, but the multiple semantics and automatic coercion mix tends to lead to more surprises. 17:17
The == thing in Java is a mess. 17:18
"foo" == someString // that's a reference comp, wtf. :/
brrt precisely :-)
TimToady you must surprise Some of the people All of the Things!
jnthn Every single Java program I write ends up with that bug at some point. Thankfully I don't write many of them :) 17:19
brrt equality is a difficult problem - ask frege
:-)
TimToady or orwell
brrt don't know what orwell has written about it
TimToady some of the things he writes about it are more equal than others 17:20
brrt oh i see :-) animal farm
what confuses me most is that there are so many different semantics 17:26
:-) 17:27
17:44 woolfy left
brrt dining 17:53
masak oh, I know Frege had conceptual problems in his works, but I didn't know they related somehow to equality. 17:54
I know category theory has three different notions of it, though, on different levels.
18:17 FROGGS joined
lue TimToady: not like I've never put my name anywhere, I just don't like websites asking for it when it seems unnecessary :P 18:29
TimToady lue: but does that indicate Natural Intelligence or Artificial Intelligence? :) 19:25
lue :) 19:26
19:27 zakharyas joined
TimToady if I were an AI, I'd put out a fake real name as bait, to see who was coming after me :) 19:27
as they say, they absence of smoke proves the fire is carefully hidden :) 19:29
*the
TimToady's Inequality: For every secret, there are many unequal and not-quite-opposite conspiracy theories. 19:32
lue
.oO(The teapot is actually a government espresso machine!)
timotimo jnthn: did you look at the output from $l_line? 19:54
"l_line" => "gcc -shared -fPIC -O1 -DNDEBUG -g3 -Wl,-rpath,\$(PREFIX)/lib -lm -lpthread -lrt -ldl -o 01-arglesslib.so 01-argless.o" 19:57
the \$(PREFIX) arguably should have been expanded when writing this string to wherever it is 19:58
well, they ought to be expanded by *something* at *some* point 20:00
in parrot's $*VM these variables seem to be expanded 20:01
build systems *shudder* 20:02
now i'm wondering by what heuristic to put self.intern calls into the actions 20:09
jnthn timotimo: I think we could just s/// it out 20:12
timotimo mhh 20:16
hm. in NQP, will ~$foo give the identical object back if it's already a string? 20:20
jnthn It'll probably unbox it 20:40
timotimo unbox and rebox?
so same MVMString, but different P6str? 20:41
jnthn If you manage to ~ in a context that needs to, yeah
~ in NQP is "give me a str"
timotimo yeah
i still segfault :\ 20:42
jnthn What backend are you on? Try it on one that is less explodey over null...
(if you're using Moar)
timotimo moar, yeah 20:43
even worse, when i stash my changes and try to rebuild, it doesn't fail any more
jnthn well, then your changes are to blame, no? :) 20:48
timotimo yes
21:21 cognominal joined 21:23 cognominal joined
dalek Heuristic branch merge: pushed 84 commits to MoarVM/moar-conc by jnthn 22:20
22:21 dalek joined
timotimo ooooh 22:30
jnthn Just updating the branch. :)
TimToady we wants it, my precioussss 22:31
jnthn Turns out I'd rather face a parallel GC bug than a Makefile split job :P
timotimo :D 23:08
dalek arVM/moar-conc: 6ec25c5 | jnthn++ | src/ (4 files):
Eliminate the new_child mechanism.

Causes a deadlock, couldn't figure out what it was trying to deal with, didn't actually work like it said anyway, and spawning a thread triggering an immediate GC run seems less than ideal.		 23:31
arVM/moar-conc: f9ac15d | jnthn++ | src/gc/collect.c:
Move corruption check to after work pass.

If the work belongs to another thread, it makes no sense to check.
MoarVM/moar-conc: ce2ee48 | jnthn++ | src/gc/collect.c:
jnthn The real, nasty bug I'm currently hunting is that some of the workload just gets dropped. 23:32
Don't think I'll find it tonight, but I know where to look now, at least. 23:37

Powered by Cro and the Raku® Programming Language.

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

Thank you!