09:30 xtt joined 09:50 bart joined
brrt \o 09:51
nine o/ brrt 10:08
How's it going?
10:14 FROGGS joined 10:18 domidumont joined 10:23 domidumont joined
brrt alright :-) 10:33
well, incredibly busy, really
brrt-to-the-future.blogspot.nl/201...ation.html <- blogged :-) 10:35
how about you?
nine Cool! Half an hour ago I looked at your blog if there's anything new :)
"incredibly busy" fits just right ;)
brrt :-) 10:36
I aim to make a few more (and perhaps a bit rougher) blog posts 10:38
i have quite a few stalled in perfectionism 10:39
nine Looking forward to those :) 10:41
11:01 domidumont joined 11:03 domidumont joined 11:28 bart joined
jnthn brrt++ # blog 11:40
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 11:45
12:09 MasterDuke joined
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:12
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:15
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:17
timotimo nah 12:19
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:20
FROGGS why isnt the (de)serialize code in MVMHash? sounds weird that it is somewhere else 12:28
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:32
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:46
aside from deserialize_method_cache_lazy 12:47
timotimo: ahh, you're saying it should be in serialize_object in the first place? 12:51
*shouldn't
timotimo could be 12:52
MasterDuke does moar know the name of variables? 13:10
i.e., i have an MVMObject, can i easily know what it's called in nqp/rakudo? 13:12
timotimo rakudo has a thing called "container descriptor" or "scalar descriptor" 13:13
that holds the name the variable has been given
MasterDuke ah, that's what those are! 13:14
timotimo there's also the lexpad that has names for the slots
MasterDuke github.com/perl6/nqp/blob/master/s...#L854-L882 13:19
looks to me like the if on line 869 will never be true? 13:20
since serialize_sc always returns an nqp::null as the second element 13:22
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
so having it as a tuple is probably not needed any more, but i suppose it's become API
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
MasterDuke for moar, there's one call for js
but then shouldn't something else implement serialize_sc somewhere? 13:28
timotimo dunno
it could be extremely rarely needed
MasterDuke fyi, nqp and rakudo both build i just remove serialize_sc entirely. spectesting now 13:37
FWIW, seems to spectest clean 14:15
15:54 domidumont joined 16:29 ggoebel joined
dalek arVM: c8bfc15 | usev6++ | src/core/exceptions.c:
Fix typo in function name
 16:37
arVM: 0b66389 | FROGGS++ | src/core/exceptions.c:
Merge pull request #439 from usev6/typo_exceptions

Fix typo in function name
16:51 zakharyas joined
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:55
FROGGS @all: moarvm, nqp and rakudo 2016.10 got migrated from unstable to debian testing today! \o/ 16:56
japhb \o/ 16:59
FROGGS++ domidumont++ nebuchadnezzar++ for that 17:00
(Did I miss anyone?)
Are there any plans to start packaging modules? Or at least panda and/or zef? 17:01
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
like native libs (Linenoise, perhaps others), where
where the lib needs to be in a certain path
lib, as in 'liblinenoise.so' 17:05
japhb Right 17:06
17:59 geekosaur joined
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:30
18:39 vendethiel joined 18:42 FROGGS joined 19:11 FROGGS joined 19:14 bart joined
nine FROGGS: what about 'liblinenoise.so'? 19:31
FROGGS nine: it gets installed into ~/.perl6/perl6-2016.10/lib or how the path is spelled 19:36
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
that means, liblinenoise.so needs to be installed in site
nine By whom does it get installed there? 19:41
FROGGS by the user 19:45
it is not packaged (yet)
so it gets installed via panda/zef
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:47
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
nine So what?
FROGGS we need an option to install to site, not to home
nine Can't Firefox on debian load plugins from ~/.mozilla/plugins?
mst FROGGS: could you start by explaining the actual problem please
rather than throwing around 'we need' without explanation
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?
FROGGS 2) cite "a directory belonging to a user cannot be added in rpath (which
would also be a security hole and against debian policy)" from bugs.debian.org/cgi-bin/bugreport....bug=801498
mst: LD_LIBRARY_PATH exists, yes 19:51
mst I mean, (2) is obvious, yes
because multi-user system so duh
FROGGS yes, and you cannot refer to "home"/"~" in any way
mst ok, so how come DynaLoader works for perl5 with a local::lib then? 19:52
moritz mst: that was my next question too
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
sadly, I don't speak sufficient C to know where to look
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
FROGGS AFAIK, you cannot load libs from a to ld unknown directory without invoking a subprocess 19:55
hmmmm
mst I mean, I can't be 100% sure, but you'd've thought I'd've been told by now
FROGGS I had spent days on that topic, but that was at least four years ago
I'll study DynaLoader the next evenings then... let's see if I can find out how it works 19:56
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
FROGGS: seem sane?
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.
mst nine: not actually true, in that case the relevant things would be in the rpath 19:58
nine: so, actually, even if his original guess was true, that would still be the case
nine What exactly is an rpath by the way? 19:59
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
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
nine: it is the compile time version of LD_LIBRARY_PATH
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.
FROGGS well, it does 20:02
nine We load from ~/.perl6/resources
I can't find that path anywhere in Moar or nqp or the perl6 shell script
FROGGS nine: github.com/MoarVM/MoarVM/commit/d2...99281700ca 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.
FROGGS nine: it is not run time, it is compile time of *moar*
mst nine: yes, you won't
nine I don't know what goes into @prefix@/share/perl6/site/lib but libraries installed during module installation are _not_ it
mst honestly I'm not actually sure why this case doesn't just work 20:04
given it does for a hand-built rakudo
nine We load the shared libs that are module resources by full path
mst FROGGS: hang on. what if his /home is mounted noexec? did you ask? 20:05
that would explain everything
FROGGS I didn't
mst maybe check that before expending further effort?
mst regularly breaks things by building on a system with a noexec /tmp 20:06
e.g. I have to do TMP=$HOME/tmp perl-build ...
FROGGS okay, the lib is installed to nqp/install/share/perl6/site/resources/DEEB27B5853BA6C98B824267B82369F02D44CB2F.so on my box 20:13
and it goes to ~/.perl6/... for the bug reporter because his site directory is somewhere in /usr or /var or something 20:14
we still should have an abspath to that file in the end...
FROGGS write the mail about noexec
writes* 20:15
*facepalm* 20:16
the bug report was more than a year old -.- 20:19
lemme install a debian testing to test this bug report successfully 20:23
.tell nebuchadnezzar can we somehow put /usr/share/perl6/site/bin in PATH? 20:40
yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.
FROGGS ahh dammit, I've got no non-root user in a chroot -.- 20:41
need to install in a VM 20:42
lizmat Q: what is Moar's relaton to Lua-JIT (if any) ? 20:53
japhb lizmat: Using its assembler in our JIT, IIRC. 21:05
dynasm
lizmat but not Lua-JIT itself?
japhb lizmat: No, it is tuned for Lua the way MoarVM is tuned for 6Model, NQP, and Perl 6 21:08
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
japhb lizmat: From historical precedent, I'd say they haven't fully researched the question. 21:10
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.
timotimo brrt-to-the-future.blogspot.de/search?q=llvm - brrt already posted a bit about "why we don't use llvm for rakudo" 21:12
in general, irclog search in #moarvm will find you a few instances of "why no llvm" 21:13
lizmat timotimo japhb thanks! 21:14
timotimo YW
BBL
japhb yw 21:15
FROGGS mst / nine: it just works... ("it" being Linenoise and the .so as /home/froggs/.perl6/resources/DEEB27B5853BA6C98B824267B82369F02D44CB2F.so) 21:26
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:28
If you want to have it in your most expensive tier of compilation for very hot code, then it may be worth it. 21:29
FROGGS .tell nebuchadnezzar forget what I said :o) 21:45
yoleaux2 FROGGS: I'll pass your message to nebuchadnezzar.

Powered by Cro and the Raku® Programming Language.

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

Thank you!