github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 21 August 2013.
BabsSeed Night all, going to test that pull for not_gerd on Ubuntu tomorrow 00:06
01:00 jnap joined 01:02 benabik joined
benabik Wow, I've been off IRC for >24 hours? I guess my client didn't like the on-again off-again connection I had at school. 01:04
You can only link actual OS X frameworks with the -framework flag. Unix shared libraries are linked with -l, like normal. 01:05
dalek Heuristic branch merge: pushed 74 commits to MoarVM/libuv5 by zhuomingliang
benabik OS X frameworks are a bundle that have all the headers, libraries, etc in one directory, organized by version. It lives parallel to the ordinary /usr hierarchy. 01:06
01:22 FROGGS_ joined
benabik Failing 4 string.t tests? 01:44
Huh... It's saying I'm failing 36-39, but the output _looks_ okay. 01:45
02:34 moritz joined
dalek arVM/libuv5: 398c783 | jimmy++ | src/io/fileops.c:
Now can read from tty in MVM_file_read_fhs
 04:23
arVM/libuv5: ecf5c3e | jimmy++ | src/ (3 files):
re-implemented MVM_socket_receive_string
 04:45
arVM/libuv5: 807d8cc | jimmy++ | / (2 files):
Add libuv as submodule
 05:45
06:05 lizmat joined 06:12 woolfy joined 06:38 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
06:46 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
06:48 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
06:53 _ilbot joined
moderator github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
dalek arVM/libuv5: 7c95d2b | jimmy++ | src/ (3 files):
refactor code in MVM_socket_receive_string and MVM_file_read_fhs
 07:00
07:04 woolfy left
dalek arVM/libuv5: 2c2d1ea | jimmy++ | src/io/ (2 files):
added back read length
 07:05
arVM/libuv5: 9df656f | jimmy++ | src/ (2 files):
re-implemented MVM_socket_listen function
 07:18
07:49 lizmat joined 07:54 donaldh joined
BabsSeed Can confirm master builds on Linux (Ubuntu 13.04 64-bit) but has a dependency on `uuid-dev` package. 09:01
09:04 eternaleye joined
FROGGS I think the uuid dependency will go when libapr is ripped out of moarvm 09:09
jnthn aye 09:13
09:38 eternaleye joined 09:46 donaldh joined 09:48 jnthn_ joined
masak does moarvm mmap in bytecode? 10:08
BabsSeed Can also confirm nqp-cc, nqp and parrot compile with just the software suite I'm running (build-essentials)
FROGGS that is pretty cool 10:11
masak: I believe I heard that, yes
masak I believe I heard that, too. 10:12
I was looking for some more direct confirmation, though. :)
FROGGS well, this is off to airport :o)
10:25 not_gerd joined
not_gerd o/ 10:25
BabsSeed: coud you try perl Configure.pl --shared on non-windows 10:26
masak: yes, bytecode is memory-mapped
not_gerd wrote MVM_platform_map_file() 10:27
masak checks that one out 10:31
nice. 10:32
not_gerd++
github.com/MoarVM/MoarVM/commit/1e...80330ced12 for those who are curious. 10:33
I was asking because twitter.com/ID_AA_Carmack/status/3...2718980096 and then twitter.com/pdcawley/status/371527095970975744 10:34
BabsSeed not_gerd: Sure, I got it to compare without --shared btw 10:35
compile* 10:36
not_gerd: On master branch, right? 10:37
linking libmoarvm.so
/usr/bin/ld: 3rdparty/linenoise/liblinenoise.a(linenoise.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
not_gerd BabsSeed: did you make clean before recompilation? 10:38
actually, I think you need to make realclean 10:39
BabsSeed not_gerd: I did make clean, didn't do make realclean
not_gerd: Tried with `make realclean`, got the same output 10:41
Wait no
linking libmoarvm.so
/usr/bin/ld: 3rdparty/apr/.libs/libapr-1.a(apr_strings.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
3rdparty/apr/.libs/libapr-1.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make: *** [libmoarvm.so] Error 1
Slightly different
not_gerd that makes sense 10:42
the APR configuration slags need to be changed
*flags
I'll get to that later today
BabsSeed not_gerd: Sure 10:44
10:55 grondilu joined
masak my make process aborts with this: 11:23
linking moarvm
/usr/bin/ld: cannot find -luuid
collect2: error: ld returned 1 exit status
make: *** [moarvm] Error 1
is that known? :/
masak re-clones and builds from scratch 11:26
same thing. :( 11:29
any advice?
not_gerd masak: install uuid-dev 11:34
(or wait until we kill off APR)
masak oh! 11:35
that's kind of a LTA error message for a missing dependency.
timotimo configure should have complained earlier 11:36
not_gerd timotimo: we're killing off APR
timotimo :)
in between sane states, insanity is to be expected, i suppose
masak well, the isolation level is not cranked high enough if the insanity between states can be ovserved. :) 11:40
observed* 11:43
not_gerd if you want to shorten the recovery time to a more sane state, help JimmyZ move sockets from APR to libuv and replace the remaining uses of apr_atomic with libatomic_ops
masak oki. 11:51
(clearly stated steps)++
not_gerd++
dalek arVM/stdtypes: 4e66626 | (Gerhard R)++ | / (103 files):
Use standard types instead of MVM(u)intXX and MVMnumXX
 12:10
not_gerd jnthn_: diakopter: ^^ 12:11
ready to go *if* we decide to go that way
JimmyZ looks good 12:14
not_gerd: Do you have a good idea about when use "%lld" or "%ld" ? 12:16
12:17 lizmat joined
JimmyZ "%lld" doesn't works on MSVC, even MSVC 2012 12:17
not_gerd JimmyZ: for the fixed-sized types, there are appropriate macros in inttypes.h
for long long itself, we could define one ourselves 12:18
JimmyZ though msdn said msvc2012 supports "%lld", but it doesn't work at all
not_gerd: our sprintf or printf use "%lld" 12:19
I want to avoid it on msvc
not_gerd JimmyZ: the standard provides a portable way to do that for fixed-sized types: "%" PRIi64 12:21
we can define a PRIll for MSVC ourselves
JimmyZ when use printf REG(1).i 12:23
how to known use PRIi64 or PRIll?
*know
or in MVM_coerce_i_s 12:24
not_gerd as far as I can see, our registers are always 64 bits 12:26
JimmyZ yes
so change lld to PRIi64? 12:27
not_gerd s/always 64 bits/always fixed-sized/ 12:28
sure
JimmyZ: do you have some particular line I can look at?
JimmyZ VM_coerce_i_s 12:29
in MVM_coerce_i_s
I mean coerce.c :)
not_gerd sprintf(buffer, "%" PRId64, i); 12:30
JimmyZ msdn said msvc2012 support %lld, but only one of sprintf/printf supports it
not_gerd I'll need to wire up inttypes.h before that, though 12:31
JimmyZ no hurry
dalek arVM/stdtypes: ad69b59 | (Gerhard R)++ | / (2 files):
Include inttypes.h instead of stdint.h - we'll need the printf macros
 12:35
arVM: c6107fb | (Gerhard R)++ | build/setup.pm:
Pass flags for compiling shareable objects down to APR
 12:51
not_gerd BabsSeed: yould you test building a shared lib again?
(don't forget to realclean)
*could
dalek arVM/libuv5: 4c51422 | jimmy++ | src/ (4 files):
re-implemented MVM_socket_close/MVM_socket_send_string function
 13:03
BabsSeed not_gerd: Sure sec 13:26
linking 3rdparty/sha1/libsha1.a 13:27
linking libmoarvm.so
linking moarvm
/usr/bin/ld: cannot find -lmoarvm
collect2: error: ld returned 1 exit status
make: *** [moarvm] Error 1
13:33 PerlJam joined 13:34 lizmat joined
not_gerd BabsSeed: hm, needs a -L. 13:36
it's encouraging that we got there at all
dalek arVM/libuv5: 2da2085 | jimmy++ | src/io/ (2 files):
re-implemented MVM_socket_accept function
 13:39
JimmyZ feels he is doing wrong things in sockectops.c. 13:40
dalek arVM: 62ed85a | (Gerhard R)++ | build/ (2 files):
Add . to library search path
 13:49
not_gerd BabsSeed: ^^
dalek arVM: 7d5cc45 | (Gerhard R)++ | src/core/interp.h:
Make void MVM_interp_enable_tracing() public
 13:51
not_gerd leaves for a bit 13:56
o/
diakopter masak: to be fair, it's prominent in the readme 14:14
masak diakopter: opening up the readme. "Build it" -- "perl Configure.pl" -- "make" 14:23
(exactly what I would expect to work)
oh, there it is, three paragraphs below.
long after, if I'd have gone that route, would have *tried the instructions*. 14:24
so no, not prominent.
actually, it even says "Building the VM itself takes just:". but it doesn't just take that. 14:26
dalek arVM/libuv5: b0199d1 | jimmy++ | src/io/socketops.c:
re-implemented MVM_socket_bind function
 14:31
JimmyZ anyone can do replace the remaining uses of apr_atomic with libatomic_ops?
I'd like to see how far we can go
dalek arVM/libuv5: bd1a500 | jimmy++ | src/ (3 files):
re-implemented MVM_socket_connect function
 14:53
masak JimmyZ: yes, I want to do that. 14:57
JimmyZ: do I do it in a branch? should I branch off master?
JimmyZ: is it as simple as s/apr_atomic/libatomic_ops/, or is it more detailed than that? 14:58
ah, I find calls such as "apr_atomic_cas32()" and "apr_atomic_casptr()", so I guess those are the ones that should be replaced. 14:59
so, I just need to figger out what they should be replaced with :)
masak goes looking for some kind of API documentation for libatomic_ops 15:00
JimmyZ yes
masak ok, this seems to be a good start: github.com/ivmai/libatomic_ops/tree/master/doc
JimmyZ if make test pass, it's ok to master :)
masak noted :)
I will still do it in a branch, 'cus it doesn't cost me anything. 15:01
masak starts reading
dalek arVM/libuv5: 669f829 | jimmy++ | src/ (8 files):
remove all of apr things except atomic parts
 15:02
arVM/libuv5: 8d0a0fb | jimmy++ | src/ (3 files):
remove some apr leftovers
 15:07
15:09 not_gerd joined
not_gerd back for a bit 15:09
JimmyZ well, all sockect test failed in libuv5 :) 15:11
not_gerd masak: as I understand it, you need to create an MVM_cas() macro that maps to AO_fetch_compare_and_swap()
also, cas32 is not supported everywhere 15:12
masak AO_t fetch_compare_and_swap ?
not_gerd AO's compare_and_swap maps to MVM_trycas, and fetch_compare_and_swap should map to MVM_cas 15:13
masak gotcha.
not_gerd 32-bit atomic access needs to go, ie you need to change those types to AO_t
as AO_t is always pointer-sized, it should be fine to just pun pointers to AO_t -- (volatile AO_t *)&ptrvar 15:15
strictly speaking, that's disallowed by the C standard, but if it works ;) 15:16
masak JimmyZ: 'make test' -- there's no such target. am I meant to run 'make test' on the cross-compiler?
or is there something else I'm missing? 15:17
there are 7 calls to apr_atomic_cas32() in the whole codebase, and 3 to apr_atomic_casptr(). this feels entirely manageable. 15:20
one is in threads.c, the remaining 9 are in the GC. :)
not_gerd: there's already a MVM_trycas() macro (in src/moarvm.h). any relation? 15:23
15:31 benabik joined
not_gerd masak: yes 15:34
the problem was that APR's cas() should be mapped to AO's fetch_compare_and_swap(), and the latter wasn't available in the version of libatomic_ops we originally used 15:35
masak but it is now? 15:36
not_gerd since 03ecaa1e55e0 15:38
masak ah, Thursday.
is there any way I can run 'make test'? I'd like to make sure everything passes before and after any change I make. 15:40
FROGGS masak: in nqp-cc you an make test and make nqptest
15:41 dalek joined
masak tries this 15:41
FROGGS can*
dalek arVM: cd9ca87 | (Gerhard R)++ | / (4 files):
Add some make targets - in particular 'help'
 15:42
FROGGS not_gerd: add coffee while you are at it 15:43
not_gerd FROGGS: shouldn't the meme be 'sandwich'? 15:44
FROGGS sandwich would be fine too :o)
benabik sandwich? where? 15:45
masak not_gerd++ 15:46
FROGGS no make target for it yet :/
dalek arVM: 7f345d9 | (Gerhard R)++ | build/Makefile.in:
Add 'sandwich' make target
 15:49
FROGGS haha 15:50
not_gerd++
[x] Ester Egg
done.
benabik Sadly, I don't think you can do a cross-platform check for root. :-D
not_gerd well, we could compile a small C program that does it for us 15:51
but I think that's going a bit too far ;)
masak still pretty funny :) 15:55
description of AO_t fetch_compare_and_swap(): "Atomically compare *addr to old_val, and replace *addr by new_val if the first comparison succeeds; returns the original value of *addr." 15:57
not_gerd: but it seems to me that the current apr_atomic_* instructions check the return value, expecting it to be either the old or the new value depending on success. 15:58
is that why we have to create a macro, to retain that semantics?
how in an AO_t fetch_compare_and_swap world would we pose the question "did the CAS operation succeed?" if it always returns the original value? 15:59
jnthn! \\o/
not_gerd jnthn: right on time 16:00
masak seems to me it'd be better to base this on 'int compare_and_swap()' which returns nonzero on success.
correct me if I'm wrong :)
jnthn um, it depends
The "seen" thing returning one is easier in some cases
masak sorry, could you rephrase that? 'the "seen" thing'? 16:01
and it returns nonzero, which I guess could be one.
and... I don't understand the rest of the sentence. the problem with AO_t fetch_compare_and_swap is that it returns the old value regardless. 16:02
jnthn masak: The places that could use an MVM_trycas are already updated. The remaining ones want to use MVM_cas
masak oki.
jnthn masak: Yes, it's meant to return the old value regardless.
That's the typical definition of CAS
masak so, taking a step back. what's MVM_cas, and why do we need it?
I'm guessing it's to be a macro in src/moarvm.h, but what's it meant to consist of, loosely? 16:03
jnthn moment, brb
dalek arVM: a22e0fc | (Gerhard R)++ | build/setup.pm:
Set cygwin shell to posix
 16:04
masak hm, if that's the typical definition of CAS, is that what apr_atomic_* does already in the code?
I need to re-read the 10 spots with that as a hypothesis :)
oh, 'make test' completed. I have five test failures. 16:05
t/moar/string.t (Wstat: 0 Tests: 40 Failed: 4) Failed tests: 36-39
t/moar/threads.t (Wstat: 0 Tests: 6 Failed: 1) Failed test: 5
not_gerd that's the 'normal' state of affairs right now
masak ok.
benabik The string tests confused me because the displayed output looks identical to the expected to me. 16:06
not_gerd benabik: really?
not for me
there's something funny going on when joining empty strings
benabik It might have been a whitespace difference. 16:07
not_gerd benabik: you could also try building with Configure.pl --shared on OSX 16:08
given my track record, it probably will fail ;)
masak ok, let's take this first one as a concrete example, just so I'm sure I grok what it does:
} while (apr_atomic_casptr((volatile void**)threads, child, child->body.next) != child->body.next);
benabik Shared libraries on OS X are... sometimes pesky. 16:09
masak I read the CAS operation as "set 'threads' to new value 'child->body.next', *if* the old value was 'child' (atomically)"
benabik *blinks* It built a .so?
masak how far off am I? :)
benabik Shared libraries on OS X are generally .dylib 16:10
not_gerd benabik: I've done nothing special for OSX yet
if it's BSD enough, it might work ;)
apparently, it wants a -dynamiclib flag instead of a -shared flag 16:11
masak ah, I was a bit off: apr.apache.org/docs/apr/0.9/group_...734597b0fa
benabik Well it seems to have built.
masak third arg is the compared value; second is the replacement. 16:12
benabik testing will take a while due to waiting for nqp-cc to build.
not_gerd benabik: as long as the moarvm executable runs, there shouldn't be issues
benabik Well it runs from the same directory, but fails as ../moarvm from nqp-cc 16:13
Ah. Runs if I set DYLD_LIBRARY_PATH. 16:15
masak ok, so the biggest difference between fetch_compare_and_swap() and apr_atomic_casptr() is that 2nd and 3rd parameters have been swapped around. 16:17
hm, no. scratch that. 16:18
they're the same. (*ptr, old, new)
oh! but it returns the original value of the *pointer*, which will implicitly tell you whether the swap was made or not. (because atomic, d'oh!) 16:19
yeah, I get it now. :)
dalek arVM: e64c29c | (Gerhard R)++ | build/setup.pm:
Generate .dylib on MacOS
 16:21
not_gerd benabik: could you test if it still works?
benabik building...
linked. 16:22
run
not_gerd++
16:25 donaldh joined
masak 8 of the apr_atomic calls compare the return value to the new value, either with == or != 16:33
the remaining 2 don't care about the return value... which bothers me.
I'm not clear about why you would CAS and then not care about success. 16:34
jnthn sorry, back 16:46
Don't...care? that is odd...where?
not_gerd oO( ack to the rescue ) 16:51
src/gc/orchestrate.c 203, 205
masak it kinda stood out among the other calls, which all did a comparison. 16:56
jnthn hm, it may not be wrong 17:00
If it's unable, steal. If it's none, interupt. It has to be in one of those who. 17:01
It's just relying on the fact that cas implies an if statement.
not_gerd what happends if something messes with the status between these two calls? 17:02
*happens
jnthn not_gerd: Thay may well be impossible; it's part of the GC orchestration, and is within the "stop the world" part. 17:04
So I'd asume (diakopter can probably answer better) that only other bits of code that could be running are GC things... 17:05
not_gerd jnthn: if nothing else can mess with the status, why use atomic access at all? 17:06
or am I missing something obvious?
jnthn not_gerd: Good question.
not_gerd: No, and I need to read more of the surrounding code to get the context, and I'm really hungry so that won't happen right now
bbl 17:09
not_gerd for what it's worth, I think it may be ok as well 17:12
masak ok, then I'll just assume that. 17:17
for now.
not_gerd masak: well, feel free to figure out how the different thread pass their messages around 17:18
but just translating the code faithfully won't introduce any regressions and would unblock the APR removal 17:19
masak aye. 17:27
one thing at a time :)
now, just translating the code faithfully *could* be as simple as just finding the right s///g to do. (I'm still not clear on what we need the MVM_cas macro for, rather than calling fetch_compare_and_swap() directly.) 17:28
not_gerd masak: well, MVM_trycas() does argument conversion 17:35
also, who knows if we stay with libatomic_ops indefinitely
masak ah, so macro-as-interface, sounds like. 18:03
ok, next specific question: 18:21
fetch_compare_and_swap() expects AO_t values, but that's not what the current code has. should I cast whatever type is there now to AO_t? 18:22
hm, yes, probably, since AO_t is simply an unsigned int. 18:23
not_gerd masak: AO_t should be a pointet-sized integer 18:26
casting anything that's not pointer-sized to AO_t is a bad idea
(for the pointer argument, that is) 18:27
eg the gc_status member of MVMThreadContext needs to changed from MVMint32 to AO_t 18:31
masak hm, then I'm more sure what to do with the 3 apr_atomic_casptr() calls. but less sure how to convert the 7 apr_atomic_cas32() calls. 18:32
oh!
well, that answers it.
and then I see why this is a rather larger change than it seemed up until now. :)
still manageable, though. 18:33
not_gerd note that there's also AO_int_fetch_compare_and_swap() that could in principle be used for 32-bit values (on reasonable architectures) 18:36
that might not be available on win64, though
masak ok, next concrete question: why does the linker say `undefined reference to `fetch_compare_and_swap'', when src/moarvm.h:17 says `#include <atomic_ops.h>' ? 18:37
not_gerd there might be architectures for which we need to generate actual code 18:40
on windows, libatomic_ops is header only as it just wraps the Interlocked winapi
but for other systems, there are some assembler files that need to be compiled and linked against
the build system *should* take care of that 18:41
masak hrm. 18:43
I won't exclude the possibility that I did something wrong. 18:44
not_gerd masak: which architecture/os are you working on?
masak Linux. 18:46
x86_64 GNU/Linux
not_gerd does 3rdparty/libatomic_ops/src/libatomic_ops.a exist?
masak yes. 18:48
-rw-r--r-- 1 masak masak 15482 Aug 25 13:27 3rdparty/libatomic_ops/src/libatomic_ops.a
18:48 donaldh joined
not_gerd does `nm 3rdparty/libatomic_ops/src/libatomic_ops.a` tell you anything interesting? 18:50
actually, the function should map to gcc compiler built-ins 18:54
I'm wondering if we shouldn't just write our own wrappers
probably not if we want to support other things besides MSVC and gcc 18:55
arnsholt Probably going to regret this, but how many compilers beyond MSVC and GCC are we going to care about for the foreseeable future? 18:59
not_gerd clang, at least
arnsholt After icc and clang, I run out of compilers =)
benabik I think clang supports the GCC atomic functinos. 19:00
arnsholt Wouldn't surprise me. Clang cares quite a bit about GCC compat, for obvious reasons
masak not_gerd: I don't know how to do that. I think we've reached the point where this turned out to be too hard for me after all. 19:01
not_gerd masak: was that a literal paste of the error message? 19:02
because we need AO_fetch_compare_and_swap, not fetch_compare_and_swap
benabik I can't find any documentation that says it, but there's at least one bug report about the behavior of __sync_val_compare_and_swap, so...
masak not_gerd: oh! 19:03
not_gerd: yes, a literal paste. I try to make those.
ok, trying with AO_*, then.
not_gerd well, good thing I looked at the backscroll again ;)
masak ;)
jnthn back 19:09
How's the atomics work going? :)
masak ooh! it linked! \\o/ 19:13
jnthn Like a chain of sausages
masak though with a few warnings, predictably. 19:14
jnthn: your mom is like a chain of sausages.
19:14 cognominal joined
not_gerd throws www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/TINYMT/ into the mix as backing algorithm for our random numbers 19:14
needs 16 bytes of state 19:15
jnthn
.oO( Can't we just role some dice? :P )
masak diakopter: I was surprised that github.com/MoarVM/MoarVM/commit/62...8d0#L2R205 and before that github.com/MoarVM/MoarVM/commit/70...4cc#L6R222 made CAS operations, but didn't check the return value. 19:17
diakopter: out of 10 CAS operations in the source, only those 2 don't check the result. so they stood out a little.
diakopter that idiom is useful if you don't care if someone else beat you to making a change, but you don't want to unk owingly overwrite some other value 19:20
jnthn ah
It's fair play, but deserving of a comment.
masak +1
diakopter i'll look at those kinks in a bit to see if thats the csse yhere 19:21
limks
links
casr
case
therr
there
argh
jnthn how do you type THAT badly??? 19:22
masak phone, prolly.
diakopter phobt
masak :P
benabik Go home diakopter's keyboard, you're drunk.
diakopter phone
BabsSeed lol
Buy a better phone :D
masak dawn you, autocollect. 19:23
not_gerd btw, I've also done the replacement of MVM(u)intXX, MVMnumXX to standard C types in a branch
someone now only needs to decide if we want to do it or not
custom fixed-sized integer types are so 90s
diakopter 1890s 19:24
or 2090s
jnthn I hate it when autocorrect makes me look regarded 19:25
moritz spots an autopun! 19:26
diakopter bwahahz
masak imagines diakopter laughing explosively, then falling asleep just as quickly 19:28
diakopter not far from the truth but I'm also drivimg 19:31
jnthn wtf!
FROGGS -.-
diakopter: put it away, please 19:32
diakopter kiddong 19:33
about to drive tho
bbl
masak is finally getting somewhere 19:51
dalek arVM/apr_to_libatomic_trial_1: 5c14ad5 | masak++ | src/ (6 files):
s/apr_atomic_\\w+/AO_fetch_and_compare/g

Also changed MVMFrame->gc_seq_number and MVMThreadContext->gc_status to type AO_t, becuase that's what the above function expects.		 20:03
masak please review/advise the above. 20:04
it's what I have so far.
phenome-wise, it builds just fine (both moar and nqp-cc), but it hangs on t/moar/gc.t 20:05
not_gerd masak: you lost some volatile qualifiers 20:08
or does the AO_t typedef include that? 20:09
not_gerd goes looking
masak oh! 20:10
no, probably not.
masak adds them back
not_gerd (it doesn't)
masak ok, trying that. 20:13
not_gerd not sure if that should make a difference as the threads and target_tray variables are declared volatile themselves 20:14
I suspect gc_seq_number and gc_status should be volatile-qualified as well 20:16
masak way ahead of you there ;) 20:17
not_gerd hm... 20:19
stackoverflow.com/questions/1467597...d-volatile # random google search
masak gc.t still hangs, though. :/
dalek arVM/apr_to_libatomic_trial_2: a4c807d | masak++ | src/ (6 files):
s/apr_atomic_\\w+/AO_fetch_and_compare/g

Also changed MVMFrame->gc_seq_number and MVMThreadContext->gc_status to type AO_t, becuase that's what the above function expects.
The 'volatile' modifier is still kept on the AO_t, as it was on the void pointer.
diakopter
.oO( every commit a branch )
 20:20
masak branches are cheap. 20:21
I'll clean up after myself afterwards. :)
not_gerd: I read through it. not sure how it applies to my case.
anyway, the good news so far is that it actually compiles and everything. I didn't expect that!
the bad news is that gc.t now hangs, for reasons I cannot guess. 20:22
not_gerd masak: the point of the SO answer is that the __sync gcc builtins (which the AO stuff wraps) do the right thing without volatile 20:23
volatile and _Atomic are (mostly but not quite) orthogonal
diakopter ok
not_gerd (_Atomic would be the C11 way to do this stuff) 20:24
"Volatile is for reading from tape drives. Atomics are for concurrency. One has nothing to do with the other." 20:26
^^ another nice quote from SO
masak heh :) 20:27
not_gerd: the correct action may be obvious to you, but it isn't to me... 20:28
do I add __sync... somewhere?
diakopter not_gerd: but that's not true 20:29
not_gerd masak: no 20:30
AO_* wraps the gc __sync_* stuff
s/gc/gcc/
masak so, adding volatile was unnecessary and essentially a no-op? 20:34
not_gerd masak: not so sure about that 20:37
depending on your compiler, it can do the right thing
the point is, you *shouldn't* need volatile to make it work 20:39
masak ok, what I hear is "unnecessary". :) 20:40
anyway, I don't know how to move forward from this spot. 20:41
it was an interesting experiment, for sure. hopefully it can be of help to someone else.
not_gerd I can check what happens on windows
masak thanks. 20:44
not_gerd (waiting for nqp-cc to compile) 20:45
and gc.t hangs 20:50
masak well, 9 of the 10 replaced calls were in src/gc/, so I guess it makes sense. 20:52
but that means the change added something bad or removed something useful. 20:53
diakopter probably just inverted args 20:55
not_gerd that could bery well be the case 21:00
*very
apr.apache.org/docs/apr/1.4/group__...tomic.html vs github.com/ivmai/libatomic_ops/tree/master/doc agrees 21:01
masak d'oh. 21:02
I looked at the orders, noticed they were reversed, but then somehow convinced myself they weren't. 21:03
ok, I can now make a third attempt. hold on.
21:03 dalek joined
masak wohoo, gc.t didn't hang \\o/ 21:08
same 5 test failures as before the patch. 21:09
dalek arVM/apr_to_libatomic_trial_3: 6f0a5c7 | masak++ | src/ (6 files):
s/apr_atomic_\\w+/AO_fetch_and_compare/g

The second and third arguments were interchanged, due to different function signatures.
Also changed MVMFrame->gc_seq_number and MVMThreadContext->gc_status to type AO_t, becuase that's what the above function expects.		 21:10
masak I advise review of the above commit, and merging into master.
in fact, while you do that, let me try to remove the APR dependency :)
hm... the obvious thing didn't work: gist.github.com/masak/6336338 :) 21:12
not_gerd masak: that's only possible if you combine your atomic stuff with JimmyZ's libuv5 21:13
masak oh!
not_gerd you should be able to remove apr_atomic.h
masak tries that
would it be interesting to rebase my work on top of JimmyZ's branch?
not_gerd masak: yes
masak ok, will try that too then. 21:14
diakopter I was wondering why no one answered your question of which branch to start on
dalek arVM/apr_to_libatomic_trial_3: 56c47ed | masak++ | src/moarvm.h:
remove apr_atomic dependency
masak never too late in Git, though 21:15
diakopter git was once an invective 21:17
masak getting some build errors. hold on, let me push what I haz. 21:18
dalek arVM/libuv5+no_apr_atomic: de32839 | (Gerhard R)++ | build/setup.pm:
Pass flags for compiling shareable objects down to APR
arVM/libuv5+no_apr_atomic: 4fbf203 | (Gerhard R)++ | build/ (2 files):
Add . to library search path

slight cleanup after removing APR
Turned out we were indirectly depending on stdarg.h, so adding that as a direct dependency instead.
Also, there was one mention of APR_SUCCESS, which I simply replaced by 0 and an explanatory comment.
masak (the rebase went fine, except for a trivial conflict in src/moarvm.h) 21:19
I'll nopaste my build problems.
21:19 dalek joined
not_gerd I'd like to see those AO_* calls put behind some macros like gist.github.com/gerdr/6e8c183fc1039293133a 21:19
diakopter yah 21:20
not_gerd preserves a tiny bit of type safety
masak not_gerd: will do.
*nod*
build problems: gist.github.com/masak/6336393
while you look at that, I'll look into making a macro.
not_gerd apparently, we depended on implicitly including stdarg.h through APR 21:22
masak heh :)
not_gerd just put #include <stdarg.h> at the top of moarvm.h for a quick fix 21:23
masak oki
it got further. 21:24
jnthn sleep time
'night, #moarvm
not_gerd o/
FROGGS gnight
masak moar build errors: gist.github.com/masak/6336419 21:25
ah:
src/core/threads.c:150:22: error: ‘APR_SUCCESS’ undeclared (first use in this function)
indeed, that line says 'status = APR_SUCCESS;' 21:26
FROGGS whee ud
not_gerd probably just 0
masak ok. 21:27
not_gerd #define APR_SUCCESS 0
FROGGS apr_errno.h:225:#define APR_SUCCESS 0
not_gerd from 3rdparty/apr/include/apr_errno.h
FROGGS yeah
not_gerd ;)
masak that's the only mention of APR_SUCCESS in the whole source code. 21:28
not_gerd we still use APR for some random bits 21:29
random taking literally
masak or indeed the only mention of any APR_* constant.
now it builds! \\o/
not_gerd that's why I proposed including TinyMT some ways up
should fail to link
apr_generate_random_bytes will be missing 21:30
masak not_gerd: well, it didn't fail to link. 21:31
not_gerd that's surprising
masak gets back to the macros
not_gerd: build it and see for yourself... :)
not_gerd actually, it's not surprising as we still link against APR 21:32
masak oh!
that should probably go as well, I guess. 21:33
not_gerd you should get a warning about an implicitly defined function, though
masak mebbe. 21:35
dalek arVM/apr_to_libatomic_trial_3: 15e451d | masak++ | src/ (5 files):
introduce a macro

And replace all occurrences of AO_fetch_compare_and_swap, essentially hiding them behind a thin layer of sanity.		 21:38
masak it builds! and on the rebased branch, too! :) 21:39
not_gerd \\o/
masak++
dalek arVM/libuv5+no_apr_atomic: 1e5b3e1 | masak++ | src/ (5 files):
introduce a macro

And replace all occurrences of AO_fetch_compare_and_swap, essentially hiding them behind a thin layer of sanity.		 21:40
21:40 benabik left
masak I don't know about the libuv5 branch and its readiness status, but as far as my bits are concerned, they're ready to be merged into master. 21:40
the fact that we still link APR is a bit of a loose end.
not_gerd sockets are still broken there
compiles, but doesn't work 21:41
masak ah.
not_gerd also, we need a new random generator
masak well, I'll just leave it like this, then, I think.
I removed the earlier experiment branches.
but I'll leave the above two tips there if anyone wants them.
diakopter masak: for redundancy.. parens around the args in MVM_cas macro definition 21:45
masak excellent point. 21:46
masak fixes
not_gerd actually, should be OK without them
but add them for consistency anyway
masak hm, they're not in any of the pre-existing macro definitions in that file... 21:48
so I dunno about consistency.
diakopter oh :)
masak only not_gerd's second one, which has a cast so it makes sense. 21:49
diakopter giggles at the commit rate of the past week
masak I think I'll leave it as it is.
not_gerd if you add parens around macro parameters defensively, aou'll never run into the problem of forgetting them where they are necessary
masak *nod*
I know about the problem it solves :) 21:50
not_gerd of course if you're confident enough in your C knowledge *shrugs*
diakopter wonders what this is github.com/tokuhirom/Perl6-PVIP 21:51
jnthn: ^
masak jnthn just went offline, because teaching tomorrow. 21:52
diakopter masak: have you seen that?
also github.com/tokuhirom/pvip/
masak no, I hadn't seen. 21:53
looking at it now.
probably deserves a mention on #perl6, as well.
so, it's a yacc grammar for Perl 6. 21:54
yeah, well, that's one kind of self-inflicted pain.
diakopter well no 21:55
it's a peg/greg grammar generator generator
the last two compilers I wrote used greg parsers 21:58
as does rurban's p2
(the two before those two used antlr parsers)
the most recent one being a little pir-like language for moarvm 22:00
masak I see.
diakopter tokuhirom_: ping :) 22:01
22:01 colomon joined
dalek arVM/noapr: fbdf144 | (Gerhard R)++ | build/ (3 files):
No longer build APR
 22:03
not_gerd there's something funny going on with the winsock headers in that branch 22:04
so I can't actually test it right now
but *now* it should fail to link ;)
diakopter not_gerd: what are your thoughts on using assertions [anywhere]? 22:05
not_gerd diakopter: I generally find them rather useful 22:06
22:07 BenGoldberg joined
not_gerd I also use them for testing - instead of using a test suite, just have t-*.c files with a bucnh of asserts 22:08
diakopter not_gerd: so the dll branch can build a .dll? also can it build a static (but not executable) lib? 22:09
not_gerd diakopter: dll branch has landet in master 22:10
diakopter oh ok
not_gerd you should be able to do Configure.pl --shared
diakopter oh hm
does it build shared in addition to the normal?
or just the shared 22:11
not_gerd either static or shared
diakopter I wish it could build both
would it be hard to make it do both?
not_gerd well, it means putting the .o files somewhere else
one set with and one without -fPIC 22:12
diakopter can you put a prefix on them?
not_gerd sure
diakopter (so you don't have to move)
not_gerd assuming MSVC will just ignore __declspec annotations if we don't build with /dll 22:13
otherwise, that needs to be handles as well
diakopter has someone gone through and marked the public api?
not_gerd no, just the few functions used by main.c 22:14
diakopter ah
which things need marked? functions, macros? structs?
includes? 22:15
or are we just marking the private things and assuming the rest is public?
like the includes
(of external things) 22:16
not_gerd stuff with external linkage needs to be declared MVM_PUBLIC or the linker won't find it on windows
diakopter hm, oh
not_gerd on windows, it's private by default, on *nix, it's public by default
marking stuff MVM_PRIVATE probably will improve load times on non-windows 22:17
(if our API ever grows so large it becomes an issue) 22:18
diakopter has jnthn commented on which things he wants private?
not_gerd no, just that he's fine with making everything either public or private
diakopter hah, okay
not_gerd either it's part of the API, or it's not
diakopter oh, you mean "anything" 22:19
or "each thing"
not_gerd yea, that ;)
marking everything with one or the other would fail 50% of the time
(ie when everything is privte ;))
diakopter is noapr ready to merge? 22:20
not_gerd no
diakopter what's remaining?
not_gerd socket failures and we need a new random generator
diakopter did anyone complain about the one you suggested? 22:21
if not, just use that :)
flussence saw a PRNG mentioned on /r/programming a few days back... 22:22
diakopter our pseudo-randomness is hardly critical at the moment 22:23
no need to spend much time on it
just make a note to revisit it
not_gerd it needs a bot of adjusting so the algorithm parameters are shared and just the state needs to be thread-local
* bit
to get it to build, just return 42 or whatever
diakopter our hash library uses its own randomness thing, I think 22:24
not_gerd: heh.
dalek arVM/serialize: 0e86db8 | (Gerhard R)++ | build/setup.pm:
Pass flags for compiling shareable objects down to APR
 22:25
arVM/serialize: 79e015c | (Gerhard R)++ | build/ (2 files):
Add . to library search path
arVM/serialize: b05527e | (Gerhard R)++ | src/core/interp.h:
Make void MVM_interp_enable_tracing() public
arVM/serialize: bad169b | (Gerhard R)++ | / (4 files):
Add some make targets - in particular 'help'
diakopter ok, time to try to unblock jnthn 22:26
not_gerd: have you thought about an install target? I'd like it to be easy to have the following scenarios: 22:31
1. install moarvm executable (as it is currently essentially) in /usr/bin or LSB or whatever
2. same for shared and static libraries
3. install (including nqp executable and dependencies!) to perl5 install tree 22:32
just plan ahead for 3.. don't actually do it yet.. until we have a ConfigureMoar.pl in the nqp repo that pulls down MoarVM repo like it does for parrot 22:33
not_gerd diakopter: right now, we just have the lib and the dll, so that's not really in issue
mor 'interesting' are the headers and how to factor NQP into that 22:34
s/mor/moar/
diakopter well, I think of NQP as a MoarVM "extension" that doesn't need to expose its own api, other than its native stuff as moar extops 22:35
not_gerd: did you read the docs/extops.markdown? if so, did you have any thoughts/comments?
not_gerd diakopter: I read that some time ago, but would have to re-read 22:37
diakopter (I don't remember whether you were involved at the time, sorry :()
not_gerd I wasn't - as far as *I* can remember ;) 22:38
dalek arVM/serialize: e9b3089 | diakopter++ | src/6model/serialization.c:
nuke trailing whitespace
diakopter wonders what PARROT_CALLCONTEXT does 22:41
strangely, google's no help 22:42
oh.
ergh. 22:43
need chromatic or someone
not_gerd just return the attribute structure, doesn't it?
diakopter yeah
well pmc data
ah well, I'll just guess 22:46
I'm not usually horrible at that 22:47
actually, still ergh 22:48
golly, this is quite complex 22:53
hrm 23:01
actually
o_O since all of these are actually MVMObjects now.. nearly all of this code can be moved into the repr->serialize functions (for contexts (frames) and closures) 23:02
hrm 23:03
23:03 cognominal__ joined
diakopter argh argh argh 23:05
not_gerd: I'm having trouble discerning jnthn's intent here 23:07
not_gerd diakopter: which particular part 23:08
diakopter when he wants something serialized, is he essentially asking every object reachable from that object to be serialized too?
(and just every object that's not already in an sc?) 23:12
b/c I suspect that a lot of this code isn't needed
.. and I'm not entirely sure which 23:14
argh, I'm suspecting only jnthn can do it from here :(
.tell yoleaux < diakopter> argh, I'm suspecting only jnthn can do it from here :( 23:15
yoleaux diakopter: Thanks for the message.
diakopter erm.
.tell jnthn < diakopter> argh, I'm suspecting only jnthn can do it from here :(
yoleaux diakopter: I'll pass your message to jnthn.
not_gerd diakopter: as far as I can tell, we indeed just walk the object graph and add it to the writer's objects_list 23:17
(if it's not already associated to a sc)
diakopter well in that case... this can actually be simplified *greatly*
by delegating it all to the reprs
also I don't see special code to handle compunits 23:18
ergh
not_gerd yeah, the if/elsif, switch kinda begs for a refactor 23:19
would be interesting to see how the java version looks
interesting - as suspected, the java stuff uses instanceof for that 23:21
which is kinda an anti-pattern
diakopter well, I dunno.
hrm. 23:23
well I can follow the java version better. 23:26
so I'll just copy that for now
well, maybe. 23:30
.tell jnthn line 572 of SerializationWriteer.java - staticCode is always null 23:32
yoleaux diakopter: I'll pass your message to jnthn.
23:57 benabik 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!