Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-05-31

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

All times shown according to UTC.

Time Nick Message
00:47 ggoebel114 joined #moarvm
01:25 cognominal joined #moarvm
01:26 cognominal joined #moarvm
01:27 cognominal joined #moarvm
01:28 cognominal joined #moarvm
01:29 cognominal_ joined #moarvm
01:29 cognominal__ joined #moarvm
01:30 cognominal_ joined #moarvm
01:31 cognominal_ joined #moarvm
01:32 cognominal joined #moarvm
01:32 cognominal joined #moarvm
01:33 cognominal_ joined #moarvm
01:34 cognominal_ joined #moarvm
01:35 cognominal joined #moarvm
01:36 cognominal joined #moarvm
01:37 cognominal joined #moarvm
01:38 cognominal joined #moarvm
01:38 cognominal joined #moarvm
01:39 cognominal joined #moarvm
01:40 cognominal joined #moarvm
01:41 cognominal joined #moarvm
01:42 cognominal joined #moarvm
01:46 cognominal joined #moarvm
01:46 cognominal joined #moarvm
01:46 cognominal_ joined #moarvm
01:46 cognominal_ joined #moarvm
01:46 cognominal joined #moarvm
01:46 cognominal_ joined #moarvm
01:47 cognominal joined #moarvm
01:47 cognominal_ joined #moarvm
01:48 cognominal_ joined #moarvm
01:49 cognominal_ joined #moarvm
01:50 cognominal_ joined #moarvm
01:51 cognominal joined #moarvm
01:52 cognominal joined #moarvm
01:53 cognominal joined #moarvm
01:53 cognominal joined #moarvm
01:54 cognominal joined #moarvm
05:37 domidumont joined #moarvm
05:41 domidumont joined #moarvm
06:00 domidumont joined #moarvm
06:37 brrt joined #moarvm
06:48 zakharyas joined #moarvm
09:38 brrt ok, i may have this One Weird Trick which makes assembly somewhat cross-platform
09:39 brrt you know how OS X (and perhaps other BSDs) likes its C-visible symbols to be prefixed with underscore?
09:39 brrt a 'function' is just a globally exported label in assembly
09:40 brrt anyway, linux does not like its C-visible symbols prefixed with an underscore
09:40 brrt with linux, i mean 'the linux linker'
09:40 brrt and with os x, i mean 'the osx linker'
09:41 brrt windows, idk
09:42 brrt nothing whatever stops me from inserting two labels, one with an underscore, and one without
09:46 timotimo m)
09:48 brrt and nothing also stops me from inserting an earlier label for the windows version
09:49 timotimo if there's two labels with the same name, windows chooses the earlier one, linux chooses the later one?
09:53 brrt no, i conditionally-compile a call to the windows version or the posix version
09:54 brrt so we get: _foo_posix, foo_posix, and foo_win32
09:56 timotimo oh, ok
09:56 timotimo how do you deal with different calling conventions "outward"?
09:57 brrt hmm, i don't even know if VSC++ accepts the same kind of assembly as gcc
09:57 brrt or clang
09:57 brrt this is for the stack-walking routine
09:57 brrt so we're never calling outward
09:57 timotimo oh, ok
10:02 brrt lunch &
12:15 colomon joined #moarvm
12:21 cognominal joined #moarvm
12:37 lizmat http://liblfds.org   # interesting for Moar ?
12:38 lizmat hmmm...  https://news.ycombinator.com/item?id=11805728
12:40 brrt joined #moarvm
12:40 brrt lizmat: looks interesting though
12:41 brrt my other 2 cents: we have 99 problems, and lock-free data structures aren't necessarily a solution to a problem that i would know (now)
12:42 nwc10 https://github.com/MoarVM/MoarVM/issues -- 48 Open
12:43 [Coke] nwc10: https://www.google.com/#q=99+problems
12:44 jnthn I'm sure some RTs are Moar's fault too :P
12:44 nwc10 yes, I know it's a meme
12:46 brrt oh, lord
12:46 brrt i had no idea we had so many GH issues
12:47 [Coke] don't look at the rakudo queue, then. :|
12:48 brrt best not
12:49 brrt what do we think of this one: https://github.com/MoarVM/MoarVM/issues/372
12:50 [Coke] since moarvm also installs files, shouldn't it also be asking for moarm to install there too?
12:54 brrt probably....
12:54 brrt packaging o.O
13:03 [Coke] there are 5 PRs for moarvm (dating back to last september) that need to be rejected or merged.
13:04 jnthn One of them iirc is awaiting testing on 32-bit
13:06 nwc10 32-bit what?
13:07 jnthn Whatever I think
13:07 nwc10 OK. I think I had all the flags for an -m32 build in my shell history at one point...
13:07 nwc10 ie x86_64 host generating x86 objects
13:09 brrt i'm going to go ahead and not think about it today
13:09 brrt packaging, i mean
13:11 [Coke] jnthn: do we maybe want a 32bit tag?
13:32 nwc10 $ file /home/nicholas/Sandpit/moar-32/bin/moar
13:32 nwc10 /home/nicholas/Sandpit/moar-32/bin/moar: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
13:32 nwc10 I'd only build MoarVM 32 bit previously
13:33 nwc10 re-run with MoarVM master
13:33 nwc10 now building NQP with it
14:08 nwc10 spectest fine, but 3 nativecall tests fail
14:08 nwc10 however I was building with -funsigned-char
14:09 nwc10 so whilst they *are* bugs, they may not be bugs that actually affect x86
14:29 nwc10 1 is related to (seemingly) assuming that char is signed
14:29 nwc10 t/04-nativecall/11-cpp.t and t/04-nativecall/13-cpp-mangling.t seem to be more general
15:23 ilmari how about x32?
15:24 ilmari which is x86_64 code with 32bit ints/longs/pointers
15:28 nwc10 I don't know if that gcc can do that
15:28 ilmari -mx32
15:28 ilmari supported on 4.9 at least
15:29 nwc10 as: unrecognized option '--x32'
15:29 nwc10 "my" machine is not my machine, so I'm not root
15:29 nwc10 however I'm root on my work desktop
15:29 nwc10 so will try that tomorrow
15:30 * ilmari installs libc6-dev-x32 and tries
15:31 ilmari configure: error: cannot run C compiled programs.
15:31 ilmari $ grep _X32_ /boot/config-$(uname -r)
15:31 ilmari CONFIG_X86_X32_DISABLED=y
15:31 ilmari oops
15:31 ilmari presumably requires a command line parameter
15:32 * ilmari tries it on his sid vm instead
15:39 ilmari lots of warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
15:40 nwc10 oh? do sizeof(int) and sizeof(void *) differ on x32?
15:40 ilmari it's casting pointers to/from MVMuint64
15:40 nwc10 or at least, sizeof(something we didn't expect) and sizeof(void *)
15:40 nwc10 aha. oooh.
15:42 ilmari it doesn't seem to be propagating CFLAGS to the 3rdparty stuff
15:42 ilmari /usr/bin/ld: i386:x86-64 architecture of input file `3rdparty/dyncall/dyncall/libdyncall_s.a(dyncall_api.o)' is incompatible with i386:x64-32 output
15:43 nwc10 I did something like this:
15:43 nwc10 Configure.pl --no-jit --prefix=/home/nicholas/Sandpit/moar-32 --cc=ccache\ /usr/local/gcc49/bin/gcc\ -Wl,-rpath=/usr/local/gcc49/lib32\ -m32\ -funsigned-char --ld=/usr/local/gcc49/bin/gcc\ -Wl,-rpath=/usr/local/gcc49/lib32\ -m32 --debug --optimize=0 --enable-jit
15:43 nwc10 (that was the one with -funsigned-char)
15:43 nwc10 and didn't do a CFLAGS
15:44 nwc10 probably means I'm working around what is a bug
15:52 ilmari only dyncall gets it wrong
15:59 ilmari oh, git clean -xfd doesn't descend into submodules
16:00 ilmari submodules--
16:01 ilmari git submodule foreach git clean -xfd # to the rescue
16:02 ilmari works with --cc='gcc -mx32' --ld='gcc -mx32'
16:04 ilmari Segmentation fault
16:04 ilmari Makefile:223: recipe for target 'gen/moar/stage1/nqpmo.moarvm' failed
16:04 timotimo oh my :|
16:04 ilmari fsvo "works" in "builds"
16:06 ilmari does the JIT support x32?
16:06 timotimo no
16:06 timotimo it ought to turn itself off when it sees 32bit builds
16:06 timotimo oh, that's only for mac
16:07 timotimo for linux and windows it relies on a define being set, i think?
16:07 ilmari I see there's an --enable-jit, but no --disable-jit
16:07 ilmari ah, it's --no-jit
16:10 ilmari --no-jit makes nqp build and tests mostly pass
16:10 ilmari t/nqp/060-bigint.t ..................... Failed 2/89 subtests
16:11 ilmari timotimo: how does it detect 32bit-ness?
16:11 timotimo dunno
16:11 ilmari x32 is x86-64 ISA (so extra registers and stuff) but 32bit ints/longs/pointers
16:11 timotimo we might not handle that at all
16:12 timotimo the reason we don't have x86-64 is because it has too few registers to make us happy
16:12 tomboy64 joined #moarvm
16:12 tomboy64 but even when specifying --has-libffi, the logic in Configure.pl 1. tests for libff, 2. tests for dyncall, 3. tests for nativecall, all three exclusively. and during the build itself, 3rdparty/dyncall is accessed nevertheless.
16:13 tomboy64 this happens when i install libffi + dyncall + rm 3rdparty/dyncall
16:13 ilmari huh? you mean the reason you don't have x86-32?
16:13 timotimo sorry, yes.
16:13 geekosaur was wondering there...
16:14 ilmari well, x32 is meant to fix that, without the extra memory pressure caused by wider types
16:14 timotimo right
16:14 timotimo we'd probably have to write a second .dasc for x32
16:15 * geekosaur is still a bit bemused by x32, since when x86-64 was added people asked if this would be done as well and were given fairly firm "no"s
16:15 ilmari people changing their minds in the face of evidence and experience?! shocking!
16:15 geekosaur "why would anyone want that?" (list of reasons including more registers and lower memory pressure) "but you should just run in 64 bit if you want that"
16:16 geekosaur frm some segments of the open source community, yes, changing minds in the face of evidence is *very* shocking. sadly.
16:27 nwc10 clearly the folks answering "but you should just run in 64 bit if you want that" had never exposed themselves to 64 bit Solaris
16:27 nwc10 very few things on Solaris were 64 bit
16:27 nwc10 because, well, why burn twice as much memory (and cache) if you didn't need the address space?
16:27 nwc10 (and here I'm only repeating what I was told when I asked the question)
16:27 nwc10 I think PPC and PPC64 were roughly the same story
16:28 ilmari the key difference is that both ppc and sparc have decent amounts of registers in 32bit mode
16:28 nwc10 yes, exactly
16:43 tomboy64 okay, let me rephrase my initial question. are libffi and dynlib excluding each other as dependencies?
16:44 timotimo we will only build moar with a single one of them
16:44 tomboy64 alright, thanks
17:08 geekosaur yes, iirc most of them were i386 only and couldn't imagine such occurrences
17:08 geekosaur on the flip side, their past experience included memory models, and I can see why someone might not want to reintroduce that insanity
17:08 geekosaur (the key difference there being that you still have sane memory management with x32)
17:09 ilmari x32 is a new ABI, so they can ditch a lot of cruft
17:39 ggoebel115 joined #moarvm
17:41 domidumont joined #moarvm
17:52 brrt joined #moarvm
17:53 brrt yeah, i'm not so fond of the whole x32 idea
17:53 brrt tbh
18:33 TimToady joined #moarvm
19:12 nine I cannot imagine there being many users of x32 anyway.
19:16 nwc10 we might have used it at NETBANX. We switched our Perl build back from 64 to 32 bits, because we figured that on the hosts running the web servers, what we had were a lot of processes wating on "the backend" (read, banks are slow at AUTHs), so what mattered more was how many we could keep in RAM easily than how fast they actually were
19:16 nwc10 but back then x86 was what the toolchain offered
19:16 nwc10 the hardware was all x86_64
19:17 nwc10 Amex is particularly slow. But I have some confidence that that's because they are actually running decent fraud checking.
19:17 nwc10 not because they are crap.
19:19 nwc10 er, by banks I think I techncailyl mean "merchant aquirers" but I've probably forgotten all the right terms.
19:19 nwc10 and I can't spell
20:50 brrt joined #moarvm

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