Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-11-04

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

All times shown according to UTC.

Time Nick Message
01:33 dalek MoarVM: 68a18b4 | timotimo++ | src/ (2 files):
01:33 dalek MoarVM: cannot * in a type object also outputs the debug_name.
01:33 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/68a18b4f22
01:40 mst joined #moarvm
01:40 BinGOs joined #moarvm
01:44 mst joined #moarvm
06:23 domidumont joined #moarvm
06:28 domidumont joined #moarvm
06:56 domidumont joined #moarvm
07:05 sivoais joined #moarvm
07:51 sivoais joined #moarvm
08:23 brrt joined #moarvm
08:26 brrt good *, #moarvm
08:26 nwc10 good *, brrt
08:28 nwc10 brrt: I finally got round to watching https://air.mozilla.org/language-composition/
08:28 nwc10 (it's from 2014)
08:28 brrt then evidently you got further than me :-)
08:28 brrt what is it about?
08:28 nwc10 and apart from the content, a bit of me is wondering "what happened next?" because the concepts and projects described seem to have vanished
08:29 nwc10 using 2 (or more) languages at the same time
08:29 brrt oh, that seems... evil
08:29 nwc10 specific examples were Prolog and Python (on the PyPy backend)
08:29 nwc10 and PHP and Python (again with PyPy)
08:30 nwc10 but the interesting part was that there was very little overhead in calling between them
08:30 brrt hmmm
08:30 nwc10 because it's all written in RPython
08:30 brrt aha
08:30 nwc10 *one* interesting part was that
08:30 nwc10 there was also "Even with mixed source files, our performance is better than the stock PHP interpreter." from the abstract
08:30 brrt well, that is ....
08:30 nwc10 it's not clear why http://hippyvm.baroquesoftware.com/ stalled
08:30 brrt not all that unexpected, given when comparing pypy with php
08:31 nwc10 but I'm going to guess "because no-one wants it enough to pay for it"
08:31 * brrt resists snarking about facebooks' php engineers
08:32 brrt I will remark only that writing your own interpreter is much more fun than using another ones
08:33 brrt also, and that is I guess part of the problem/barrier that the PyPy folks are facing, it isn't exactly hard
08:33 brrt unlike compilers
08:33 brrt well, 'good' compilers
08:34 nwc10 I admit that "I read it on the Internet" and not in a technical publication
08:34 nwc10 (IIRC it was reputable, and I think it was bloomberg)
08:34 nwc10 how it took a *long* time to get HHVM to out-perform HipHop
08:34 nwc10 but implied was that this wasn't done for "fun", but because it was thought to make (some) business sense
08:35 brrt I'm very, very curious what that business sense could be
08:35 nwc10 hardware is expensive, at Facebook scale
08:35 brrt note that those remarks also go, just as well, to the question 'why didn't we use LLVM for the JIT'
08:36 nwc10 I thought that Pyston had demonstrated why LLVM isn't great for a dynamic language JIT :-)
08:36 brrt part of the answer is of course 'using LLVM is total pain for a dynamic language JIT'
08:36 nwc10 well, more, at Facebook scale, engineering time may actually be cheaper than even more hardware
08:36 brrt but that doesn't... hold *completely*, because Julia does get away with it
08:36 nwc10 was Julia designed for it?
08:36 brrt yes
08:36 nwc10 my understanding is that Scala makes trade-offs to fit the JVM
08:36 brrt on it, is maybe a better way to say it
08:37 nwc10 Julia is like that?
08:37 nwc10 (for its target)
08:37 zakharyas joined #moarvm
08:37 brrt actually, Julia was designed to be like R, but with the added luxury of writing your own for loops
08:37 brrt but yes, I got that impression that Julia was bound to LLVM tightly
08:38 brrt I guess I'm saying that, given all the things the facebook folks could've chosen to do with HHVM, it doesn't seem like they chose the shortest / most efficient path
08:39 nwc10 ah OK. I missed that that was what you were saying
08:39 brrt and I get that for facebook, none of that matters
08:39 brrt because scale
08:39 nwc10 and I assume "because x86_64"
08:40 nwc10 and IIRC "because Ubuntu"
08:40 nwc10 at least, they can assume that they don't need portability
08:40 brrt and one of the things that they could've done was build on something like HippyVM or started their own PyPy based effort - PyPy ought to be considered proven by now
08:40 nwc10 I think that they *did* pay for HippyVM for a while
08:41 nwc10 I've not looked at the HHVM source. Maybe I should. How long does it take to build?
08:41 brrt never looked at it, never built it, probably C++
08:41 brrt so 'longish'
08:41 nwc10 IIRC MoarVM is seconds
08:41 brrt yes :-D
08:41 nwc10 Rubinius (which is C++)(when I could get it to build) was about 10 minutes
08:41 nwc10 PyPy was 40
08:41 nwc10 and is a complete RAM hog
08:42 brrt that is the other part of pypy's problem
08:42 brrt the problem that RPython is solving, strictly speaking, isn't a hard one and can be done in C/C++ by an experienced engineer easily
08:43 nwc10 :-)
08:43 brrt the problem solved by their JIT compiler and meta-tracing backend, that *is hard*, but people forego it because using RPython is a pain
08:43 nwc10 the :-) was because I was jumping to the conclusion "so they would be better of *not* self-hosting"
08:44 brrt .. I think so, yes
08:44 brrt but I may be wrong about that
08:45 nwc10 well, we need a parallel universe before we can prove it
08:45 nwc10 and probably several, so that we have enough experiments to avoid errors :-)
08:45 brrt :-)
10:44 JimmyZ joined #moarvm
10:45 ilmari joined #moarvm
12:19 zakharyas joined #moarvm
13:42 JimmyZ joined #moarvm
18:47 domidumont joined #moarvm
19:12 masak joined #moarvm
19:12 masak jnthn: according to a git grep I just made of the moarvm source code, you're a three-star programmer ;)
19:13 masak three asterisks occur in 15 places of the source code. four don't occur.
19:13 masak I'm not stating this as any kind of challenge or call for action, by the way :P
19:41 sivoais joined #moarvm
19:48 jnthn I didn't make it to four stars anywhere? :)
19:48 timotimo hm, can i break upon entering a .c file from anywhere in gdb?
19:50 jnthn masak: At a guess, those 15 places are largely under src/gc/? :)
19:50 nine timotimo: don't think so :/
19:51 jnthn Moving GCs talk a lot about the location of pointers, which gets you to two stars. And you're sometimes interested in lists of those locations, which gets you to three.
19:52 jnthn So in that domain you kinda end up there without doing anything clever.
19:52 masak jnthn: 10 are in src/gc
19:52 jnthn To the extent that a moving GC isn't already sorta clever. :P
19:52 nine .oO(lists of locations of string arrays)
19:53 masak jnthn: 3 are in src/core, 1 is in src/strings/unicode_db.c, 1 is in tools/ucd2c.pl (but still C code)
19:53 jnthn Oh man, I wonder if that Unicode one is the primary composites table :P
19:53 masak jnthn: comp_p? :)
19:53 jnthn Yup :)
19:54 masak it's actually `static const MVMint32 ***comp_p[]`, so I guess that one could be seen as four stars :P
19:54 jnthn And I'll get in sr/core one or more is in threadcontext.h and is GC related.
19:54 jnthn *src/core
19:54 timotimo nine: here's my setup (it has nothing to do with perl6 or moarvm): i have a game that misbehaves when multiple monitors are connected. it still has DWARF symbols for the SDL2 that's compiled into it (i.e. statically linked and partially inlined). i'd like to see how exactly it uses the SDL api without manually typing every SDL function i could be interested in as breakpoints
19:54 jnthn *guess also :)
19:56 jnthn timotimo: ltrace?
19:57 timotimo "It intercepts and records the dynamic library calls which are called by the executed process"
19:57 timotimo does it also handle non-dynamic library calls?
19:57 nine (gdb) help rbreak
19:57 nine Set a breakpoint for all functions matching REGEXP.
19:57 jnthn No idea, sorry
19:57 nine Do SDL functions have a common prefix?
19:57 timotimo oooh
19:57 timotimo yes, they do
19:57 jnthn nine++ # I didn't know about that one either...nice! :)
19:58 timotimo Breakpoint 1289 at 0x8404fb0
19:58 timotimo <function, no debug info> NInputHandler::InitInputDevices(SDL_Window*, void*, bool, bool);
19:58 nine Apparently one can even do: rbreak file.c:.
19:58 timotimo %)
19:59 timotimo neat.
20:02 timotimo another question: this file is full of references to /home/kyle/blahblah/blahblah/SDL2-2.0.1/src/... files
20:02 timotimo can i tell gdb "i have the same files, but at a different path"?
20:03 timotimo aha
20:03 timotimo set substitute-path
20:07 timotimo ohmygosh it works
20:07 timotimo this is pretty cool
21:04 timotimo jnthn: how come we don't have a serialization and deserialization function for MVMHash?
21:07 lizmat jnthn: https://gist.github.com/lizmat/32ce2b17a5acaf38b153779a64ca9bef   # concurrent fail on OS X
21:08 lizmat { my $*PROMISE := $p; $vow.keep(code(|c)) },
21:08 lizmat looks like it lost the code to be executed
21:11 jnthn timotimo: It's handled specially (grep for MVMHash in serialization.c)
21:11 timotimo oh
21:11 timotimo well, that explains it. but why do we get errors for it missing? just a bug?
21:11 jnthn lizmat: I suspect elsewhere.
21:11 jnthn timotimo: Yeah, sounds like
21:11 timotimo OK, good to know
21:11 jnthn timotimo: Something doing write_obj_ref instead of write_ref or something I guess
21:12 jnthn lizmat: As in, I suspect not just OSX :)
21:12 timotimo interesting. that should be findable
21:12 jnthn I've seen that one on Linux also
21:12 timotimo ltrace gives me an incredible amount of output
21:12 lizmat jnthn: ok
21:12 jnthn Didn't get to the bottom of why yet
21:18 timotimo because ltrace also gives operator new, operator new[], operator delete, operator delete[], but also memcmp, memcpy, str*cmp, ...
21:19 jnthn Hm, you can't tell it which libraries you do/don't care about? :)
21:20 timotimo -l, --library filename
21:20 timotimo Display only the symbols included in the library filename.
21:20 timotimo this ought to be it, but i'm not sure it actually considers the statically linked SDL a "library" in that sense
21:21 jnthn ah, ok
21:26 timotimo "Because it uses the dynamic library hooking mechanism, ltrace cannot trace calls to libraries which are statically linked directly to the target"

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