Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-02-10

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

All times shown according to UTC.

Time Nick Message
00:04 colomon joined #moarvm
00:10 vendethiel joined #moarvm
00:32 vendethiel joined #moarvm
01:11 colomon joined #moarvm
01:17 vendethiel joined #moarvm
01:41 vendethiel joined #moarvm
02:29 vendethiel joined #moarvm
02:59 colomon joined #moarvm
04:06 vendethiel joined #moarvm
04:32 vendethiel joined #moarvm
06:08 vendethiel joined #moarvm
07:47 FROGGS joined #moarvm
07:51 FROGGS jnthn: are you fine with calling the repr 'C++Struct' instead of 'CPPStruct'?
07:52 FROGGS that would allow traits like `sub foo is mangled('C++') { * }` align more nicely
07:56 FROGGS to align*
07:56 FROGGS hmmm, maybe we should even call it 'C++Class'...
07:57 vendethiel joined #moarvm
08:05 Ven_ joined #moarvm
08:11 arnsholt FROGGS: Wouldn't you have to have both C++Struct and C++Class?
08:12 arnsholt Don't they have subtly different rules?
08:12 FROGGS I think C++Structs are identical to CStructs
08:13 FROGGS only C++Structs might have a different memory layout due to vtables pointers
08:13 FROGGS please tell me if that's wrong
08:14 FROGGS it is kinda hard to find detailed information on this topic because answers on stackoverflow are usually: "depends" and "why do you wanna do that at all?"
08:14 FROGGS which is not helpful
08:18 arnsholt Well, the problem is (I think) that almost all of this is implementation-specific
08:18 FROGGS not quite
08:19 FROGGS the memory layout seems to be not compiler specific
08:20 arnsholt Ah, right
08:20 zakharyas joined #moarvm
08:20 FROGGS but the name mangling scheme certainly is... but supporting g++, clang and msvc should do for a start
08:20 arnsholt I guess you'll have to get your hands on a copy of the spec
08:21 FROGGS I started to add tests to check certain scenarios
08:22 vendethiel joined #moarvm
08:26 FROGGS this evening I'll start to push my stuff to branches, in case you want to review :o)
09:07 vendethiel joined #moarvm
09:13 jnthn FROGGS: Hm, I'm somewhat inclined to keep the REPR names to identifier chars.
09:14 FROGGS k
09:25 Ven_ joined #moarvm
09:32 nwc10 FROGGS: IIRC the C++ standard says directly or indirectly that structs and classes are the same thing, just with different defaults (public vs private)
09:32 nwc10 and that a class (or struct) consisting solely of public members and no functions must be laid out the same way that C does it
09:32 FROGGS right
09:32 nwc10 (ie things that are valid C must lay out the same as C)
09:33 nwc10 I *think* (but I am not sure) that private, protected and public members must each be laid out in sequence
09:33 nwc10 but can be in 3 separate sequences
09:34 nwc10 but as I understand it, it's intended in the design of things that different compilers mangle symbols differently, to ensure bogus linking can't accidentally happen
09:34 nwc10 I believe that leont would be a much better person to ask than me
09:34 FROGGS ohh, good to know
09:35 * nwc10 is still liking https://techbase.kde.org/Projects/MoveToGit/UsingSvn2Git/
09:35 nwc10 and how fast git is at things like filter-branch
09:35 FROGGS wikipedia also states, that: "Though it would seem that standardised name mangling in the C++ language would lead to greater interoperability between compiler implementations, such a standardization by itself would not suffice to guarantee C++ compiler interoperability and it might even create a false impression that interoperability is possible and safe when it isn't."
09:36 FROGGS "Name mangling is only one of several application binary interface (ABI) details that need to be decided and observed by a C++ implementation. Other ABI aspects like exception handling, virtual table layout, structure and stack frame padding, etc. also cause differing C++ implementations to be incompatible."
09:36 FROGGS this bit though does not apply for us: "Further, requiring a particular form of mangling would cause issues for systems where implementation limits (e.g., length of symbols) dictate a particular mangling scheme. A standardised requirement for name mangling would also prevent an implementation where mangling was not required at all — for example, a linker which understood the C++ language."
09:38 rurban joined #moarvm
09:53 vendethiel joined #moarvm
10:33 Ven_ joined #moarvm
11:00 vendethiel joined #moarvm
12:32 vendethiel joined #moarvm
13:07 Ven_ joined #moarvm
13:22 vendethiel joined #moarvm
14:29 vendethiel joined #moarvm
14:34 rurban joined #moarvm
14:42 Ven_ joined #moarvm
14:59 vendethiel joined #moarvm
15:33 colomon joined #moarvm
15:51 Ven_ joined #moarvm
16:04 vendethiel joined #moarvm
16:31 vendethiel joined #moarvm
17:40 vendethiel joined #moarvm
18:31 FROGGS joined #moarvm
19:54 brrt joined #moarvm
19:56 brrt on the topic of clang
19:57 brrt i don't really find it that much better *in practice*, certainly with respect to me as a compiler user
19:58 brrt (for one thing, gcc is still - in my experience - much faster)
20:31 jnthn Its errors/warnings are prettier. Still, given the amount of warnings it likes to offer up, they'd better be pretty :P
20:35 hoelzro the nice thing about clang is that its prettier warnings/errors gave rise to prettier ones in GCC as well =)
20:39 rurban gcc-5.0 is pretty nice now, but broke perl5
20:43 hoelzro rurban: oh, it did?
20:45 brrt is there a gcc 5? :-o
20:45 rurban https://rt.perl.org/Ticket/Display.html?id=123784
20:46 rurban I'm working with the pre-5.0 for some weeks already. much better than 4.9
20:46 rurban I switched from clang back to gcc
20:50 dalek MoarVM/cpp: 7b8fec9 | FROGGS++ | / (6 files):
20:50 dalek MoarVM/cpp: add CPPStruct representation
20:50 dalek MoarVM/cpp: review: https://github.com/MoarVM/MoarVM/commit/7b8fec92aa
20:52 dalek MoarVM/cpp: 29f6a69 | FROGGS++ | src/core/nativecall. (2 files):
20:52 dalek MoarVM/cpp: handle C++ structures in native calls and add thiscall calling convention
20:52 dalek MoarVM/cpp: review: https://github.com/MoarVM/MoarVM/commit/29f6a69995
21:00 brrt i could tolerate clang if weren't so darn slow
21:01 brrt or at least, if it wasn't so slow on moarvm :-P
21:02 * jnthn blames interp.c ;P
21:02 timotimo let's just use gcc on interp.c and clang on the rest
21:03 TimToady just tell clang to emulate gcc on interp.c
21:03 brrt that will probably even work
21:04 brrt compile interp.c to interp.o with gcc
21:04 brrt let me try that
21:04 jnthn omg... :P
21:04 jnthn .oO( --compiler=clang-AND-gcc )
21:05 timotimo scary-hybrid
21:05 timotimo just run both compilers on every .c file and just use the .o file that finishes first
21:05 TimToady what would be completely ironic is if that fixed all the instabilities
21:06 brrt don't expect magic
21:06 brrt but anyway, it just took 13s for a really-clean build now, that's acceptable
21:06 jnthn Sadly, past experience shows instabilities are fixed by hours and hours and hours of debugging...
21:07 brrt and hours
21:07 TimToady so if clang takes hours and hourse, all that's left is the debugging
21:07 TimToady s/e//
21:07 jnthn :P
21:07 TimToady er, :2nd
21:08 TimToady I even looked, and didn't see the e in "takes"
21:08 jnthn Talking of taking hours and hours, I should probably get back to working out why loading CORE.setting hangs with my natives patches...
21:08 TimToady something is whiling away teh hours...
21:08 TimToady *he
21:09 brrt by the way, that scary hybrid does actually seem to work
21:09 brrt as in
21:09 brrt i compiled with clang
21:09 brrt then changed the makefile to use gcc
21:09 brrt then removed moar, libmoar.so, and src/core/interp.o
21:09 brrt hit make
21:09 TimToady but linked with gcc?
21:09 brrt yes
21:09 brrt CC=gcc and LD=gcc
21:10 brrt .. awesome
21:10 brrt and now i've built nqp with that.. hybrid
21:10 TimToady but does clang produce faster code from interp.c?
21:11 brrt i couldn't say
21:11 brrt that would need benchmarking
21:11 brrt msvc does make better code than gcc, at least it used to, not sure about now that we've upped the -O flag
21:12 jnthn aha...--optimize=off fixes le hang does it
21:12 jnthn s/does it//
21:13 brrt jnthn, do you have some of those nice design docs you use to make on the nativeref things?
21:14 jnthn brrt: Sadly not; there's a sort of one on the 6pe stuff, the natives stuff got largely scribbled on my notebook and other disparate bits of paper.
21:14 jnthn I can do one "after the fact"
21:14 brrt fair enough
21:15 brrt that would be awesome
21:15 TimToady we should have a program that reads your C code and then just intuits the design from that
21:15 TimToady s/C//
21:16 jnthn Hm, seems the multi-dispatcher isn't so aware of native refs as I expected...
21:16 TimToady the natives are refless tonight
21:17 brrt timtoady, that'd be perl7 right
21:18 brrt the ultimate do what i mean
21:31 vendethiel joined #moarvm
21:37 japhb TimToady++ #  "the natives are refless", one of the better puns I've seen recently
21:38 timotimo omg
21:47 jnthn Fun fact: maor --dump on CORE.setting produces a 25MB file
21:48 timotimo that's not that terrible :P
21:48 timotimo perl6 is big language
21:48 TimToady nah, English is a big language
21:48 TimToady perl6 is a medium-sized language
21:51 japhb jnthn: Why is the minimum size of a running Rakudo >3x that amount?  I would have naively assumed CORE.setting would be the majority of the bytecode the moarvm process would need to load?  Or am I seeing the result of:  (CORE.setting.moarvm + <others>.moarvm) * 2  # For loaded bytecode, and then unpacked in-memory structures
21:51 japhb ?
21:51 jnthn japhb: Well, we mmap the .moarvm files, but yes, it's largely unpacking
21:52 brrt if perl6 is medium sized, is perl5 smaller-than-medium-sized?
21:52 * japhb assumes better static optimization could shrink CORE.setting a fair bit ... half size maybe?
21:53 japhb brrt: L M S XS mini!  (Joke only makes sense to people who saw the original mini car teaser ads)
21:54 brrt (which unfortunately i did not)
21:54 jnthn japhb: The bytecode is less than half the size of the serialized objects blob.
21:55 japhb woofta
21:56 japhb Which makes me wonder what needs to be optimized to shrink the serialized objects blob.
21:57 * japhb realizes whenever someone states a number in reference to programs, he immediately has two mental questions: 1. Would it be nicer if that was smaller or larger?  2. What can be changed to push it that direction?
21:57 japhb Damn obsession
22:00 brrt with regards to blobs though, the size/time tradeoff seems very relevant
22:02 brrt as in, small blobs are nice; quick access to blobs may be nicer
22:02 brrt and we are still by no means pypy
22:03 japhb brrt: Not sure what you mean by that last statement
22:03 japhb (regarding pypy)
22:04 FROGGS_ joined #moarvm
22:05 brrt pypy is my personal limit on the maximum (runtime) size a project should obtain
22:05 japhb How big is it?
22:05 brrt building pypy requires either a prebuilt pypy (because python is too slow) or very much patience and arround ~4G of RAM
22:06 brrt pypy is really unacceptably big and slow to build (imho)
22:06 * japhb is trying to imagine a language-VM that's significantly more memory-hungry than the JVM
22:06 brrt well, check out pypy for one
22:07 japhb brrt: For a while, Rakudo development was being slowed by people with 32-bit CPUs being unable to build locally.
22:07 japhb I'll take your word for it.  :-)
22:08 brrt repo is also 240mb large iirc
22:09 brrt i didn't use to be able to develop rakudo-on-parrot
22:10 brrt but in fairness, pypy is really very advanced, and it really does work (or so i'm told)
22:36 jnthn Darn, this is proving a tricky one to hunt...
22:58 jnthn Arrrgh
23:03 japhb Beer?
23:03 jnthn uh, good suggestion :)
23:16 vendethiel joined #moarvm
23:42 vendethiel joined #moarvm

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