Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-11-06

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

All times shown according to UTC.

Time Nick Message
09:30 xtt joined #moarvm
09:50 bart joined #moarvm
09:51 brrt \o
10:08 nine o/ brrt
10:08 nine How's it going?
10:14 FROGGS joined #moarvm
10:18 domidumont joined #moarvm
10:23 domidumont joined #moarvm
10:33 brrt alright :-)
10:33 brrt well, incredibly busy, really
10:35 brrt https://brrt-to-the-future.blogspot.nl/2016/11/a-guide-through-register-allocation.html <- blogged :-)
10:35 brrt how about you?
10:35 nine Cool! Half an hour ago I looked at your blog if there's anything new :)
10:35 nine "incredibly busy" fits just right ;)
10:36 brrt :-)
10:38 brrt I aim to make a few more (and perhaps a bit rougher) blog posts
10:39 brrt i have quite a few stalled in perfectionism
10:41 nine Looking forward to those :)
11:01 domidumont joined #moarvm
11:03 domidumont joined #moarvm
11:03 domidumont joined #moarvm
11:28 bart joined #moarvm
11:40 jnthn brrt++ # blog
11:45 timotimo just makes me wonder why the processor doesn't expose its own internal virtual registers and register allocator so programs can use it :P
12:09 MasterDuke joined #moarvm
12:12 MasterDuke jnthn: timotimo was asking about not being able to serialize VMHashs a day or two ago (something i ran into when working on the line numbers). you said it was special-cased in serialization.c and i see references to REFVAR_VM_HASH_STR_VAR
12:15 MasterDuke however, it looks like it's failing the "if (REPR(obj)->serialize)" check. and it turns out there's no serialize/deserialize, serialize_repr_data/deserialize_repr_data functions in MVMHash.c
12:17 MasterDuke if i add a stub serialize, i don't get the "Missing..." error and it dies in my stub. is adding real versions of those what's needed?
12:19 timotimo nah
12:20 timotimo it seems like the function that can figure out if a reference is to a VMHash is a different function from the one that you're hitting them
12:28 FROGGS why isnt the (de)serialize code in MVMHash? sounds weird that it is somewhere else
12:32 timotimo hm. perhaps it's there for when we know the target of a reference has to be an MVMHash? i don't know, i haven't looked at the code.
12:46 MasterDuke well, the code in serialization.c that references REFVAR_VM_HASH_STR_VAR seems (for the most part) similar to the code that references the different REFVAR_VM_ARR_*
12:47 MasterDuke aside from deserialize_method_cache_lazy
12:51 MasterDuke timotimo: ahh, you're saying it should be in serialize_object in the first place?
12:51 MasterDuke *shouldn't
12:52 timotimo could be
13:10 MasterDuke does moar know the name of variables?
13:12 MasterDuke i.e., i have an MVMObject, can i easily know what it's called in nqp/rakudo?
13:13 timotimo rakudo has a thing called "container descriptor" or "scalar descriptor"
13:13 timotimo that holds the name the variable has been given
13:14 MasterDuke ah, that's what those are!
13:14 timotimo there's also the lexpad that has names for the slots
13:19 MasterDuke https://github.com/perl6/nqp/blob/master/src/vm/moar/QAST/QASTCompilerMAST.nqp#L854-L882
13:20 MasterDuke looks to me like the if on line 869 will never be true?
13:22 MasterDuke since serialize_sc always returns an nqp::null as the second element
13:26 timotimo we used to have the string hash as a list, now we have it in a separate section that can store it more efficiently
13:26 timotimo so having it as a tuple is probably not needed any more, but i suppose it's become API
13:27 MasterDuke the only place serialize_sc is called is line 862
13:27 timotimo the comment says something about serving as a hook point for overriding when you want serialization to work differently
13:27 MasterDuke for moar, there's one call for js
13:28 MasterDuke but then shouldn't something else implement serialize_sc somewhere?
13:28 timotimo dunno
13:28 timotimo it could be extremely rarely needed
13:37 MasterDuke fyi, nqp and rakudo both build i just remove serialize_sc entirely. spectesting now
14:15 MasterDuke FWIW, seems to spectest clean
15:54 domidumont joined #moarvm
16:29 ggoebel joined #moarvm
16:37 dalek MoarVM: c8bfc15 | usev6++ | src/core/exceptions.c:
16:37 dalek MoarVM: Fix typo in function name
16:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c8bfc15c7a
16:37 dalek MoarVM: 0b66389 | FROGGS++ | src/core/exceptions.c:
16:37 dalek MoarVM: Merge pull request #439 from usev6/typo_exceptions
16:37 dalek MoarVM:
16:37 dalek MoarVM: Fix typo in function name
16:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0b66389240
16:51 zakharyas joined #moarvm
16:55 japhb MasterDuke: We've found out far too often that "spectest clean" really means "spectest incomplete".  It's excellent for catching gotchas when it shows a problem, but is not a strong enough indicator of success when it's clean.
16:56 FROGGS @all: moarvm, nqp and rakudo 2016.10 got migrated from unstable to debian testing today! \o/
16:59 japhb \o/
17:00 japhb FROGGS++ domidumont++ nebuchadnezzar++ for that
17:00 japhb (Did I miss anyone?)
17:01 japhb Are there any plans to start packaging modules?  Or at least panda and/or zef?
17:04 FROGGS I think there are, but we need to fix things first... like the scenario where we install stuff to a system perl6
17:04 FROGGS like native libs (Linenoise, perhaps others), where
17:04 FROGGS where the lib needs to be in a certain path
17:05 FROGGS lib, as in 'liblinenoise.so'
17:06 japhb Right
17:59 geekosaur joined #moarvm
18:30 MasterDuke japhb: sure, and i definitely don't know the codebase well enough to always know which it is. but removing a three line function (of which two appear to be no-ops) that's only called in one spot and then builds and spectests clean seems relatively safe
18:39 vendethiel joined #moarvm
18:42 FROGGS joined #moarvm
19:11 FROGGS joined #moarvm
19:14 bart joined #moarvm
19:31 nine FROGGS: what about 'liblinenoise.so'?
19:36 FROGGS nine: it gets installed into ~/.perl6/perl6-2016.10/lib or how the path is spelled
19:37 FROGGS and according to debian rules a path in your home can never be part or moarvm's rpath, so the library isnt loadable
19:37 FROGGS that means, liblinenoise.so needs to be installed in site
19:41 nine By whom does it get installed there?
19:45 FROGGS by the user
19:45 FROGGS it is not packaged (yet)
19:45 FROGGS so it gets installed via panda/zef
19:47 nine Then it's installed as a resource into the ~/.perl6 repo and loaded via NativeCall? I don't see what we would change about that?
19:48 mst FROGGS: I'm not sure what you mean by "according to debian rules" ?
19:48 FROGGS it cant be loaded via nativecall if you use debians rakudo/moarvm package
19:48 nine So what?
19:48 FROGGS we need an option to install to site, not to home
19:48 nine Can't Firefox on debian load plugins from ~/.mozilla/plugins?
19:48 mst FROGGS: could you start by explaining the actual problem please
19:48 mst rather than throwing around 'we need' without explanation
19:50 FROGGS 1) .so libraries can only be loaded from directories that are either known by ld.config, or which are in rpath of an executable
19:50 mst uh. LD_LIBRARY_PATH exists?
19:50 FROGGS 2) cite "a directory belonging to a user cannot be added in rpath (which
19:50 FROGGS would also be a security hole and against debian policy)" from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801498
19:51 FROGGS mst: LD_LIBRARY_PATH exists, yes
19:51 mst I mean, (2) is obvious, yes
19:51 mst because multi-user system so duh
19:51 FROGGS yes, and you cannot refer to "home"/"~" in any way
19:52 mst ok, so how come DynaLoader works for perl5 with a local::lib then?
19:52 moritz mst: that was my next question too
19:53 mst so we don't need 'an option to install to site', we need to figure out the actual problem and fix it.
19:53 mst sadly, I don't speak sufficient C to know where to look
19:54 FROGGS mst: do you happen to know if DynaLoader also works with local::lib on openbsd? I remember horrible problems with .so libs on openbsd from my old Alien::SDL days...
19:54 mst FROGGS: I've never had a bug report about it and have plenty of obsd users, so I'm assuming yes
19:55 FROGGS AFAIK, you cannot load libs from a to ld unknown directory without invoking a subprocess
19:55 FROGGS hmmmm
19:55 mst I mean, I can't be 100% sure, but you'd've thought I'd've been told by now
19:55 FROGGS I had spent days on that topic, but that was at least four years ago
19:56 FROGGS I'll study DynaLoader the next evenings then... let's see if I can find out how it works
19:57 mst but basically I *think* "make NativeCall do whatever DL does" is probably the true answer, and if it isn't, we need to know why it isn't to get any further
19:57 mst FROGGS: seem sane?
19:57 nine FROGGS: if your interpretation of this were correct, one wouldn't be able to compile a program from sources and run it from one's home directory if it's dynamically linked. That's clearly not the case.
19:58 mst nine: not actually true, in that case the relevant things would be in the rpath
19:58 mst nine: so, actually, even if his original guess was true, that would still be the case
19:59 nine What exactly is an rpath by the way?
20:00 * mst handwaves frantically, defers a real explanation to somebody with more understanding of C
20:00 FROGGS mst: "make NativeCall do whatever DL does" sounds very sane
20:01 FROGGS nine: rpath is a compile time option to your C compile that registers a path to your to-be-compiled program (like moar)
20:01 FROGGS nine: it is the compile time version of LD_LIBRARY_PATH
20:01 nine Doesn't sound like it would have anything to do with how we load a liblinenoise.so that's installed as part of a module.
20:02 FROGGS well, it does
20:02 nine We load from ~/.perl6/resources
20:02 nine I can't find that path anywhere in Moar or nqp or the perl6 shell script
20:03 FROGGS nine: https://github.com/MoarVM/MoarVM/commit/d2e5c768f1ea69932d0a2ed1e0b26299281700ca
20:03 nine The only part of the rakudo stack that even knows about that directory is CompUnit::Repository::Installation. I'm quite sure I've not touched any other part of the code base.
20:03 FROGGS nine: it is not run time, it is compile time of *moar*
20:03 mst nine: yes, you won't
20:03 nine I don't know what goes into @prefix@/share/perl6/site/lib but libraries installed during module installation are _not_ it
20:04 mst honestly I'm not actually sure why this case doesn't just work
20:04 mst given it does for a hand-built rakudo
20:04 nine We load the shared libs that are module resources by full path
20:05 mst FROGGS: hang on. what if his /home is mounted noexec? did you ask?
20:05 mst that would explain everything
20:05 FROGGS I didn't
20:05 mst maybe check that before expending further effort?
20:06 * mst regularly breaks things by building on a system with a noexec /tmp
20:06 mst e.g. I have to do TMP=$HOME/tmp perl-build ...
20:13 FROGGS okay, the lib is installed to nqp/install/share/perl6/site/resources/DEEB27B5853BA6C98B824267B82369F02D44CB2F.so on my box
20:14 FROGGS and it goes to ~/.perl6/... for the bug reporter because his site directory is somewhere in /usr or /var or something
20:14 FROGGS we still should have an abspath to that file in the end...
20:14 * FROGGS write the mail about noexec
20:15 FROGGS writes*
20:16 FROGGS *facepalm*
20:19 FROGGS the bug report was more than a year old -.-
20:23 FROGGS lemme install a debian testing to test this bug report successfully
20:40 FROGGS .tell nebuchadnezzar can we somehow put /usr/share/perl6/site/bin in PATH?
20:40 yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.
20:41 FROGGS ahh dammit, I've got no non-root user in a chroot -.-
20:42 FROGGS need to install in a VM
20:53 lizmat Q: what is Moar's relaton to Lua-JIT (if any) ?
21:05 japhb lizmat: Using its assembler in our JIT, IIRC.
21:05 japhb dynasm
21:05 lizmat but not Lua-JIT itself?
21:08 japhb lizmat: No, it is tuned for Lua the way MoarVM is tuned for 6Model, NQP, and Perl 6
21:09 lizmat so what does it mean when someone says they can make Perl 6 faster by using llvm instead of Lua-JIT ?
21:09 * lizmat fears some misconception in the mind of that person
21:10 japhb lizmat: From historical precedent, I'd say they haven't fully researched the question.
21:11 timotimo if that someone really wants to put in the massive amounts of effort to make moar work with llvm, sure
21:11 japhb That suggestion is in a class led by "Couldn't you just ...?" which essentially always ends with a naive but unworkable "solution" that has to be explained away ad nauseum.
21:12 timotimo http://brrt-to-the-future.blogspot.de/search?q=llvm - brrt already posted a bit about "why we don't use llvm for rakudo"
21:13 timotimo in general, irclog search in #moarvm will find you a few instances of "why no llvm"
21:14 lizmat timotimo japhb thanks!
21:14 timotimo YW
21:14 timotimo BBL
21:15 japhb yw
21:26 FROGGS mst / nine: it just works... ("it" being Linenoise and the .so as /home/froggs/.perl6/resources/DEEB27B5853BA6C98B824267B82369F02D44CB2F.so)
21:28 jnthn I think it's by now fairly well established that LLVM is good at a bunch of things, but being a first-resort JIT compiler for dynamic languages isn't one of them.
21:29 jnthn If you want to have it in your most expensive tier of compilation for very hot code, then it may be worth it.
21:45 FROGGS .tell nebuchadnezzar forget what I said :o)
21:45 yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.

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