00:04 colomon joined 00:10 vendethiel joined 00:32 vendethiel joined 01:11 colomon joined 01:17 vendethiel joined 01:41 vendethiel joined 02:29 vendethiel joined 02:59 colomon joined 04:06 vendethiel joined 04:32 vendethiel joined 06:08 vendethiel joined 07:47 FROGGS joined
FROGGS jnthn: are you fine with calling the repr 'C++Struct' instead of 'CPPStruct'? 07:51
that would allow traits like `sub foo is mangled('C++') { * }` align more nicely 07:52
to align* 07:56
hmmm, maybe we should even call it 'C++Class'...
07:57 vendethiel joined 08:05 Ven_ joined
arnsholt FROGGS: Wouldn't you have to have both C++Struct and C++Class? 08:11
Don't they have subtly different rules? 08:12
FROGGS I think C++Structs are identical to CStructs
only C++Structs might have a different memory layout due to vtables pointers 08:13
please tell me if that's wrong
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
which is not helpful
arnsholt Well, the problem is (I think) that almost all of this is implementation-specific 08:18
FROGGS not quite
the memory layout seems to be not compiler specific 08:19
arnsholt Ah, right 08:20
08:20 zakharyas joined
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
FROGGS I started to add tests to check certain scenarios 08:21
08:22 vendethiel joined
FROGGS this evening I'll start to push my stuff to branches, in case you want to review :o) 08:26
09:07 vendethiel joined
jnthn FROGGS: Hm, I'm somewhat inclined to keep the REPR names to identifier chars. 09:13
FROGGS k 09:14
09:25 Ven_ joined
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
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
FROGGS right
nwc10 (ie things that are valid C must lay out the same as C)
I *think* (but I am not sure) that private, protected and public members must each be laid out in sequence 09:33
but can be in 3 separate sequences
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
I believe that leont would be a much better person to ask than me
FROGGS ohh, good to know
nwc10 is still liking techbase.kde.org/Projects/MoveToGi...ngSvn2Git/ 09:35
and how fast git is at things like filter-branch
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."
"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
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 09:53 vendethiel joined 10:33 Ven_ joined 11:00 vendethiel joined 12:32 vendethiel joined 13:07 Ven_ joined 13:22 vendethiel joined 14:29 vendethiel joined 14:34 rurban joined 14:42 Ven_ joined 14:59 vendethiel joined 15:33 colomon joined 15:51 Ven_ joined 16:04 vendethiel joined 16:31 vendethiel joined 17:40 vendethiel joined 18:31 FROGGS joined 19:54 brrt joined
brrt on the topic of clang 19:56
i don't really find it that much better *in practice*, certainly with respect to me as a compiler user 19:57
(for one thing, gcc is still - in my experience - much faster) 19:58
jnthn Its errors/warnings are prettier. Still, given the amount of warnings it likes to offer up, they'd better be pretty :P 20:31
hoelzro the nice thing about clang is that its prettier warnings/errors gave rise to prettier ones in GCC as well =) 20:35
rurban gcc-5.0 is pretty nice now, but broke perl5 20:39
hoelzro rurban: oh, it did? 20:43
brrt is there a gcc 5? :-o 20:45
rurban rt.perl.org/Ticket/Display.html?id=123784
I'm working with the pre-5.0 for some weeks already. much better than 4.9 20:46
I switched from clang back to gcc
dalek arVM/cpp: 7b8fec9 | FROGGS++ | / (6 files):
add CPPStruct representation
 20:50
arVM/cpp: 29f6a69 | FROGGS++ | src/core/nativecall. (2 files):
handle C++ structures in native calls and add thiscall calling convention
 20:52
brrt i could tolerate clang if weren't so darn slow 21:00
or at least, if it wasn't so slow on moarvm :-P 21:01
jnthn blames interp.c ;P 21:02
timotimo let's just use gcc on interp.c and clang on the rest
TimToady just tell clang to emulate gcc on interp.c 21:03
brrt that will probably even work
compile interp.c to interp.o with gcc 21:04
let me try that
jnthn omg... :P
.oO( --compiler=clang-AND-gcc )
timotimo scary-hybrid 21:05
just run both compilers on every .c file and just use the .o file that finishes first
TimToady what would be completely ironic is if that fixed all the instabilities
brrt don't expect magic 21:06
but anyway, it just took 13s for a really-clean build now, that's acceptable
jnthn Sadly, past experience shows instabilities are fixed by hours and hours and hours of debugging...
brrt and hours 21:07
TimToady so if clang takes hours and hourse, all that's left is the debugging
s/e//
jnthn :P
TimToady er, :2nd
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...
TimToady something is whiling away teh hours...
*he
brrt by the way, that scary hybrid does actually seem to work 21:09
as in
i compiled with clang
then changed the makefile to use gcc
then removed moar, libmoar.so, and src/core/interp.o
hit make
TimToady but linked with gcc?
brrt yes
CC=gcc and LD=gcc
.. awesome 21:10
and now i've built nqp with that.. hybrid
TimToady but does clang produce faster code from interp.c?
brrt i couldn't say 21:11
that would need benchmarking
msvc does make better code than gcc, at least it used to, not sure about now that we've upped the -O flag
jnthn aha...--optimize=off fixes le hang does it 21:12
s/does it//
brrt jnthn, do you have some of those nice design docs you use to make on the nativeref things? 21:13
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
I can do one "after the fact"
brrt fair enough
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
s/C//
jnthn Hm, seems the multi-dispatcher isn't so aware of native refs as I expected... 21:16
TimToady the natives are refless tonight
brrt timtoady, that'd be perl7 right 21:17
the ultimate do what i mean 21:18
21:31 vendethiel joined
japhb TimToady++ # "the natives are refless", one of the better puns I've seen recently 21:37
timotimo omg 21:38
jnthn Fun fact: maor --dump on CORE.setting produces a 25MB file 21:47
timotimo that's not that terrible :P 21:48
perl6 is big language
TimToady nah, English is a big language
perl6 is a medium-sized language
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
?
jnthn japhb: Well, we mmap the .moarvm files, but yes, it's largely unpacking
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?
brrt: L M S XS mini! (Joke only makes sense to people who saw the original mini car teaser ads) 21:53
brrt (which unfortunately i did not) 21:54
jnthn japhb: The bytecode is less than half the size of the serialized objects blob.
japhb woofta 21:55
Which makes me wonder what needs to be optimized to shrink the serialized objects blob. 21:56
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
Damn obsession
brrt with regards to blobs though, the size/time tradeoff seems very relevant 22:00
as in, small blobs are nice; quick access to blobs may be nicer 22:02
and we are still by no means pypy
japhb brrt: Not sure what you mean by that last statement 22:03
(regarding pypy)
22:04 FROGGS_ joined
brrt pypy is my personal limit on the maximum (runtime) size a project should obtain 22:05
japhb How big is it?
brrt building pypy requires either a prebuilt pypy (because python is too slow) or very much patience and arround ~4G of RAM
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
brrt well, check out pypy for one
japhb brrt: For a while, Rakudo development was being slowed by people with 32-bit CPUs being unable to build locally. 22:07
I'll take your word for it. :-)
brrt repo is also 240mb large iirc 22:08
i didn't use to be able to develop rakudo-on-parrot 22:09
but in fairness, pypy is really very advanced, and it really does work (or so i'm told) 22:10
jnthn Darn, this is proving a tricky one to hunt... 22:36
Arrrgh 22:58
japhb Beer? 23:03
jnthn uh, good suggestion :)
23:16 vendethiel joined 23:42 vendethiel joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!