Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-08-25

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

All times shown according to UTC.

Time Nick Message
00:06 BabsSeed Night all, going to test that pull for not_gerd on Ubuntu tomorrow
01:00 jnap joined #moarvm
01:02 benabik joined #moarvm
01:04 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:05 benabik 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
01:06 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:22 FROGGS_ joined #moarvm
01:44 benabik Failing 4 string.t tests?
01:45 benabik Huh...  It's saying I'm failing 36-39, but the output _looks_ okay.
02:34 moritz joined #moarvm
04:23 dalek MoarVM/libuv5: 398c783 | jimmy++ | src/io/fileops.c:
04:23 dalek MoarVM/libuv5: Now can read from tty in MVM_file_read_fhs
04:23 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/398c783586
04:45 dalek MoarVM/libuv5: ecf5c3e | jimmy++ | src/ (3 files):
04:45 dalek MoarVM/libuv5: re-implemented MVM_socket_receive_string
04:45 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/ecf5c3e114
05:45 dalek MoarVM/libuv5: 807d8cc | jimmy++ | / (2 files):
05:45 dalek MoarVM/libuv5: Add libuv as submodule
05:45 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/807d8ccc6e
06:05 lizmat joined #moarvm
06:12 woolfy joined #moarvm
06:38 _ilbot joined #moarvm
06:38 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:46 _ilbot joined #moarvm
06:46 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:48 _ilbot joined #moarvm
06:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
06:53 _ilbot joined #moarvm
06:53 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
07:00 dalek MoarVM/libuv5: 7c95d2b | jimmy++ | src/ (3 files):
07:00 dalek MoarVM/libuv5: refactor code in MVM_socket_receive_string and MVM_file_read_fhs
07:00 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/7c95d2b1ce
07:04 woolfy left #moarvm
07:05 dalek MoarVM/libuv5: 2c2d1ea | jimmy++ | src/io/ (2 files):
07:05 dalek MoarVM/libuv5: added back read length
07:05 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/2c2d1eaff5
07:18 dalek MoarVM/libuv5: 9df656f | jimmy++ | src/ (2 files):
07:18 dalek MoarVM/libuv5: re-implemented MVM_socket_listen function
07:18 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/9df656fce7
07:49 lizmat joined #moarvm
07:54 donaldh joined #moarvm
09:01 BabsSeed Can confirm master builds on Linux (Ubuntu 13.04 64-bit) but has a dependency on `uuid-dev` package.
09:04 eternaleye joined #moarvm
09:09 FROGGS I think the uuid dependency will go when libapr is ripped out of moarvm
09:13 jnthn aye
09:38 eternaleye joined #moarvm
09:46 donaldh joined #moarvm
09:48 jnthn_ joined #moarvm
10:08 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)
10:11 FROGGS that is pretty cool
10:11 FROGGS masak: I believe I heard that, yes
10:12 masak I believe I heard that, too.
10:12 masak I was looking for some more direct confirmation, though. :)
10:12 FROGGS well, this is off to airport :o)
10:25 not_gerd joined #moarvm
10:25 not_gerd o/
10:26 not_gerd BabsSeed: coud you try perl Configure.pl --shared on non-windows
10:26 not_gerd masak: yes, bytecode is memory-mapped
10:27 * not_gerd wrote MVM_platform_map_file()
10:31 * masak checks that one out
10:32 masak nice.
10:32 masak not_gerd++
10:33 masak https://github.com/MoarVM/MoarVM/commit/​1e64add2b6ecce804fc3607f5fff9f80330ced12 for those who are curious.
10:34 masak I was asking because https://twitter.com/ID_AA_Carm​ack/status/371384902718980096 and then https://twitter.com/pdcawle​y/status/371527095970975744
10:35 BabsSeed not_gerd: Sure, I got it to compare without --shared btw
10:36 BabsSeed compile*
10:37 BabsSeed not_gerd: On master branch, right?
10:37 BabsSeed linking libmoarvm.so
10:37 BabsSeed /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
10:38 not_gerd BabsSeed: did you make clean before recompilation?
10:39 not_gerd actually, I think you need to make realclean
10:39 BabsSeed not_gerd: I did make clean, didn't do make realclean
10:41 BabsSeed not_gerd: Tried with `make realclean`, got the same output
10:41 BabsSeed Wait no
10:41 BabsSeed linking libmoarvm.so
10:41 BabsSeed /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
10:41 BabsSeed 3rdparty/apr/.libs/libapr-1.a: could not read symbols: Bad value
10:41 BabsSeed collect2: error: ld returned 1 exit status
10:41 BabsSeed make: *** [libmoarvm.so] Error 1
10:41 BabsSeed Slightly different
10:42 not_gerd that makes sense
10:42 not_gerd the APR configuration slags need to be changed
10:42 not_gerd *flags
10:42 not_gerd I'll get to that later today
10:44 BabsSeed not_gerd: Sure
10:55 grondilu joined #moarvm
11:23 masak my make process aborts with this:
11:23 masak linking moarvm
11:23 masak /usr/bin/ld: cannot find -luuid
11:23 masak collect2: error: ld returned 1 exit status
11:23 masak make: *** [moarvm] Error 1
11:23 masak is that known? :/
11:26 * masak re-clones and builds from scratch
11:29 masak same thing. :(
11:29 masak any advice?
11:34 not_gerd masak: install uuid-dev
11:34 not_gerd (or wait until we kill off APR)
11:35 masak oh!
11:35 masak that's kind of a LTA error message for a missing dependency.
11:36 timotimo configure should have complained earlier
11:36 not_gerd timotimo: we're killing off APR
11:36 timotimo :)
11:36 timotimo in between sane states, insanity is to be expected, i suppose
11:40 masak well, the isolation level is not cranked high enough if the insanity between states can be ovserved. :)
11:43 masak 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
11:51 masak oki.
11:51 masak (clearly stated steps)++
11:51 masak not_gerd++
12:10 dalek MoarVM/stdtypes: 4e66626 | (Gerhard R)++ | / (103 files):
12:10 dalek MoarVM/stdtypes: Use standard types instead of MVM(u)intXX and MVMnumXX
12:10 dalek MoarVM/stdtypes: review: https://github.com/MoarVM/MoarVM/commit/4e66626c04
12:11 not_gerd jnthn_: diakopter: ^^
12:11 not_gerd ready to go *if*  we decide to go that way
12:14 JimmyZ looks good
12:16 JimmyZ not_gerd: Do you have a good idea about when use "%lld" or "%ld" ?
12:17 lizmat joined #moarvm
12:17 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
12:18 not_gerd 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
12:19 JimmyZ not_gerd: our sprintf or printf use "%lld"
12:19 JimmyZ I want to avoid it on msvc
12:21 not_gerd JimmyZ: the standard provides a portable way to do that for fixed-sized types: "%" PRIi64
12:21 not_gerd we can define a PRIll for MSVC ourselves
12:23 JimmyZ when use printf REG(1).i
12:23 JimmyZ how to known use PRIi64 or PRIll?
12:23 JimmyZ *know
12:24 JimmyZ or in MVM_coerce_i_s
12:26 not_gerd as far as I can see, our registers are always 64 bits
12:26 JimmyZ yes
12:27 JimmyZ so change lld to PRIi64?
12:28 not_gerd s/always 64 bits/always fixed-sized/
12:28 not_gerd sure
12:28 not_gerd JimmyZ: do you have some particular line I can look at?
12:29 JimmyZ VM_coerce_i_s
12:29 JimmyZ in MVM_coerce_i_s
12:29 JimmyZ I mean coerce.c :)
12:30 not_gerd sprintf(buffer, "%" PRId64, i);
12:30 JimmyZ msdn said msvc2012 support %lld, but only one of sprintf/printf supports it
12:31 not_gerd I'll need to wire up inttypes.h before that, though
12:31 JimmyZ no hurry
12:35 dalek MoarVM/stdtypes: ad69b59 | (Gerhard R)++ | / (2 files):
12:35 dalek MoarVM/stdtypes: Include inttypes.h instead of stdint.h - we'll need the printf macros
12:35 dalek MoarVM/stdtypes: review: https://github.com/MoarVM/MoarVM/commit/ad69b590e9
12:51 dalek MoarVM: c6107fb | (Gerhard R)++ | build/setup.pm:
12:51 dalek MoarVM: Pass flags for compiling shareable objects down to APR
12:51 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c6107fbec6
12:51 not_gerd BabsSeed: yould you test building a shared lib again?
12:51 not_gerd (don't forget to realclean)
12:51 not_gerd *could
13:03 dalek MoarVM/libuv5: 4c51422 | jimmy++ | src/ (4 files):
13:03 dalek MoarVM/libuv5: re-implemented MVM_socket_close/MVM_socket_send_string function
13:03 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/4c51422626
13:26 BabsSeed not_gerd: Sure sec
13:27 BabsSeed linking 3rdparty/sha1/libsha1.a
13:27 BabsSeed linking libmoarvm.so
13:27 BabsSeed linking moarvm
13:27 BabsSeed /usr/bin/ld: cannot find -lmoarvm
13:27 BabsSeed collect2: error: ld returned 1 exit status
13:27 BabsSeed make: *** [moarvm] Error 1
13:33 PerlJam joined #moarvm
13:34 lizmat joined #moarvm
13:36 not_gerd BabsSeed: hm, needs a -L.
13:36 not_gerd it's encouraging that we got there at all
13:39 dalek MoarVM/libuv5: 2da2085 | jimmy++ | src/io/ (2 files):
13:39 dalek MoarVM/libuv5: re-implemented MVM_socket_accept function
13:39 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/2da20858e2
13:40 * JimmyZ feels he is doing wrong things in sockectops.c.
13:49 dalek MoarVM: 62ed85a | (Gerhard R)++ | build/ (2 files):
13:49 dalek MoarVM: Add . to library search path
13:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/62ed85a1d1
13:49 not_gerd BabsSeed: ^^
13:51 dalek MoarVM: 7d5cc45 | (Gerhard R)++ | src/core/interp.h:
13:51 dalek MoarVM: Make void MVM_interp_enable_tracing() public
13:51 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7d5cc4509e
13:56 * not_gerd leaves for a bit
13:56 not_gerd o/
14:14 diakopter masak: to be fair, it's prominent in the readme
14:23 masak diakopter: opening up the readme. "Build it" -- "perl Configure.pl" -- "make"
14:23 masak (exactly what I would expect to work)
14:23 masak oh, there it is, three paragraphs below.
14:24 masak long after, if I'd have gone that route, would have *tried the instructions*.
14:24 masak so no, not prominent.
14:26 masak actually, it even says "Building the VM itself takes just:". but it doesn't just take that.
14:31 dalek MoarVM/libuv5: b0199d1 | jimmy++ | src/io/socketops.c:
14:31 dalek MoarVM/libuv5: re-implemented MVM_socket_bind function
14:31 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/b0199d1196
14:31 JimmyZ anyone can do replace the remaining uses of apr_atomic with libatomic_ops?
14:31 JimmyZ I'd like to see how far we can go
14:53 dalek MoarVM/libuv5: bd1a500 | jimmy++ | src/ (3 files):
14:53 dalek MoarVM/libuv5: re-implemented MVM_socket_connect function
14:53 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/bd1a500d7e
14:57 masak JimmyZ: yes, I want to do that.
14:57 masak JimmyZ: do I do it in a branch? should I branch off master?
14:58 masak JimmyZ: is it as simple as s/apr_atomic/libatomic_ops/, or is it more detailed than that?
14:59 masak 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 masak so, I just need to figger out what they should be replaced with :)
15:00 * masak goes looking for some kind of API documentation for libatomic_ops
15:00 JimmyZ yes
15:00 masak ok, this seems to be a good start: https://github.com/ivmai/li​batomic_ops/tree/master/doc
15:00 JimmyZ if make test  pass, it's ok to master :)
15:00 masak noted :)
15:01 masak I will still do it in a branch, 'cus it doesn't cost me anything.
15:01 * masak starts reading
15:02 dalek MoarVM/libuv5: 669f829 | jimmy++ | src/ (8 files):
15:02 dalek MoarVM/libuv5: remove all of apr things except atomic parts
15:02 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/669f8290b1
15:07 dalek MoarVM/libuv5: 8d0a0fb | jimmy++ | src/ (3 files):
15:07 dalek MoarVM/libuv5: remove some apr leftovers
15:07 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/8d0a0fbac2
15:09 not_gerd joined #moarvm
15:09 * not_gerd back for a bit
15:11 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()
15:12 not_gerd also, cas32 is not supported everywhere
15:12 masak AO_t fetch_compare_and_swap ?
15:13 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.
15:13 not_gerd 32-bit atomic access needs to go, ie you need to change those types to AO_t
15:15 not_gerd as AO_t is always pointer-sized, it should be fine to just pun pointers to AO_t -- (volatile AO_t *)&ptrvar
15:16 not_gerd 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?
15:17 masak or is there something else I'm missing?
15:20 masak there are 7 calls to apr_atomic_cas32() in the whole codebase, and 3 to apr_atomic_casptr(). this feels entirely manageable.
15:20 masak one is in threads.c, the remaining 9 are in the GC. :)
15:23 masak not_gerd: there's already a MVM_trycas() macro (in src/moarvm.h). any relation?
15:31 benabik joined #moarvm
15:34 not_gerd masak: yes
15:35 not_gerd 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:36 masak but it is now?
15:38 not_gerd since 03ecaa1e55e0
15:38 masak ah, Thursday.
15:40 masak 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 #moarvm
15:41 * masak tries this
15:41 FROGGS can*
15:42 dalek MoarVM: cd9ca87 | (Gerhard R)++ | / (4 files):
15:42 dalek MoarVM: Add some make targets - in particular 'help'
15:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/cd9ca8707f
15:43 FROGGS not_gerd: add coffee while you are at it
15:44 not_gerd FROGGS: shouldn't the meme be 'sandwich'?
15:44 FROGGS sandwich would be fine too :o)
15:45 benabik sandwich?  where?
15:46 masak not_gerd++
15:46 FROGGS no make target for it yet :/
15:49 dalek MoarVM: 7f345d9 | (Gerhard R)++ | build/Makefile.in:
15:49 dalek MoarVM: Add 'sandwich' make target
15:49 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7f345d915d
15:50 FROGGS haha
15:50 FROGGS not_gerd++
15:50 FROGGS [x] Ester Egg
15:50 FROGGS done.
15:50 benabik Sadly, I don't think you can do a cross-platform check for root.  :-D
15:51 not_gerd well, we could compile a small C program that does it for us
15:51 not_gerd but I think that's going a bit too far ;)
15:55 masak still pretty funny :)
15:57 masak 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:58 masak 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 masak is that why we have to create a macro, to retain that semantics?
15:59 masak 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 masak jnthn! \o/
16:00 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.
16:00 masak correct me if I'm wrong :)
16:00 jnthn um, it depends
16:00 jnthn The "seen" thing returning one is easier in some cases
16:01 masak sorry, could you rephrase that? 'the "seen" thing'?
16:01 masak and it returns nonzero, which I guess could be one.
16:02 masak 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
16:02 masak oki.
16:02 jnthn masak: Yes, it's meant to return the old value regardless.
16:02 jnthn That's the typical definition of CAS
16:02 masak so, taking a step back. what's MVM_cas, and why do we need it?
16:03 masak 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
16:04 dalek MoarVM: a22e0fc | (Gerhard R)++ | build/setup.pm:
16:04 dalek MoarVM: Set cygwin shell to posix
16:04 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a22e0fca38
16:04 masak hm, if that's the typical definition of CAS, is that what apr_atomic_* does already in the code?
16:04 masak I need to re-read the 10 spots with that as a hypothesis :)
16:05 masak oh, 'make test' completed. I have five test failures.
16:05 masak t/moar/string.t               (Wstat: 0 Tests: 40 Failed: 4) Failed tests:  36-39
16:05 masak t/moar/threads.t              (Wstat: 0 Tests: 6 Failed: 1) Failed test:  5
16:05 not_gerd that's the 'normal' state of affairs right now
16:05 masak ok.
16:06 benabik The string tests confused me because the displayed output looks identical to the expected to me.
16:06 not_gerd benabik: really?
16:06 not_gerd not for me
16:06 not_gerd there's something funny going on when joining empty strings
16:07 benabik It might have been a whitespace difference.
16:08 not_gerd benabik: you could also try building with Configure.pl --shared on OSX
16:08 not_gerd given my track record, it probably will fail ;)
16:08 masak ok, let's take this first one as a concrete example, just so I'm sure I grok what it does:
16:08 masak } while (apr_atomic_casptr((volatile void**)threads, child, child->body.next) != child->body.next);
16:09 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)"
16:09 benabik *blinks*  It built a .so?
16:09 masak how far off am I? :)
16:10 benabik Shared libraries on OS X are generally .dylib
16:10 not_gerd benabik: I've done nothing special for OSX yet
16:10 not_gerd if it's BSD enough, it might work ;)
16:11 not_gerd apparently, it wants a -dynamiclib flag instead of a -shared flag
16:11 masak ah, I was a bit off: https://apr.apache.org/docs/apr/0.9/group__apr_​_atomic.html#gfdd02b41cc39ade873daa2734597b0fa
16:11 benabik Well it seems to have built.
16:12 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.
16:12 not_gerd benabik: as long as the moarvm executable runs, there shouldn't be issues
16:13 benabik Well it runs from the same directory, but fails as ../moarvm from nqp-cc
16:15 benabik Ah.  Runs if I set DYLD_LIBRARY_PATH.
16:17 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:18 masak hm, no. scratch that.
16:18 masak they're the same. (*ptr, old, new)
16:19 masak 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 masak yeah, I get it now. :)
16:21 dalek MoarVM: e64c29c | (Gerhard R)++ | build/setup.pm:
16:21 dalek MoarVM: Generate .dylib on MacOS
16:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e64c29c0f2
16:21 not_gerd benabik: could you test if it still works?
16:21 benabik building...
16:22 benabik linked.
16:22 benabik run
16:22 benabik not_gerd++
16:25 donaldh joined #moarvm
16:33 masak 8 of the apr_atomic calls compare the return value to the new value, either with == or !=
16:33 masak the remaining 2 don't care about the return value... which bothers me.
16:34 masak I'm not clear about why you would CAS and then not care about success.
16:46 jnthn sorry, back
16:46 jnthn Don't...care? that is odd...where?
16:51 not_gerd oO( ack to the rescue )
16:51 not_gerd src/gc/orchestrate.c 203, 205
16:56 masak it kinda stood out among the other calls, which all did a comparison.
17:00 jnthn hm, it may not be wrong
17:01 jnthn If it's unable, steal. If it's none, interupt. It has to be in one of those who.
17:01 jnthn It's just relying on the fact that cas implies an if statement.
17:02 not_gerd what happends if something messes with the status between these two calls?
17:02 not_gerd *happens
17:04 jnthn not_gerd: Thay may well be impossible; it's part of the GC orchestration, and is within the "stop the world" part.
17:05 jnthn So I'd asume (diakopter can probably answer better) that only other bits of code that could be running are GC things...
17:06 not_gerd jnthn: if nothing else can mess with the status, why use atomic access at all?
17:06 not_gerd or am I missing something obvious?
17:06 jnthn not_gerd: Good question.
17:06 jnthn 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
17:09 jnthn bbl
17:12 not_gerd for what it's worth, I think it may be ok as well
17:17 masak ok, then I'll just assume that.
17:17 masak for now.
17:18 not_gerd masak: well, feel free to figure out how the different thread pass their messages around
17:19 not_gerd but just translating the code faithfully won't introduce any regressions and would unblock the APR removal
17:27 masak aye.
17:27 masak one thing at a time :)
17:28 masak 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:35 not_gerd masak: well, MVM_trycas() does argument conversion
17:35 not_gerd also, who knows if we stay with libatomic_ops indefinitely
18:03 masak ah, so macro-as-interface, sounds like.
18:21 masak ok, next specific question:
18:22 masak 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:23 masak hm, yes, probably, since AO_t is simply an unsigned int.
18:26 not_gerd masak: AO_t should be a pointet-sized integer
18:26 not_gerd casting anything that's not pointer-sized to AO_t is a bad idea
18:27 not_gerd (for the pointer argument, that is)
18:31 not_gerd eg the gc_status member of MVMThreadContext needs to changed from MVMint32 to AO_t
18:32 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 masak oh!
18:32 masak well, that answers it.
18:32 masak and then I see why this is a rather larger change than it seemed up until now. :)
18:33 masak still manageable, though.
18:36 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 not_gerd that might not be available on win64, though
18:37 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:40 not_gerd there might be architectures for which we need to generate actual code
18:40 not_gerd on windows, libatomic_ops is header only as it just wraps the Interlocked winapi
18:40 not_gerd but for other systems, there are some assembler files that need to be compiled and linked against
18:41 not_gerd the build system *should* take care of that
18:43 masak hrm.
18:44 masak I won't exclude the possibility that I did something wrong.
18:44 not_gerd masak: which architecture/os are you working on?
18:46 masak Linux.
18:46 masak x86_64 GNU/Linux
18:46 not_gerd does 3rdparty/libatomic_ops/src/libatomic_ops.a exist?
18:48 masak yes.
18:48 masak -rw-r--r-- 1 masak masak 15482 Aug 25 13:27 3rdparty/libatomic_ops/src/libatomic_ops.a
18:48 donaldh joined #moarvm
18:50 not_gerd does `nm 3rdparty/libatomic_ops/src/libatomic_ops.a` tell you anything interesting?
18:54 not_gerd actually, the function should map to gcc compiler built-ins
18:54 not_gerd I'm wondering if we shouldn't just write our own wrappers
18:55 not_gerd probably not if we want to support other things besides MSVC and gcc
18:59 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
18:59 arnsholt After icc and clang, I run out of compilers =)
19:00 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
19:01 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:02 not_gerd masak: was that a literal paste of the error message?
19:02 not_gerd because we need AO_fetch_compare_and_swap, not fetch_compare_and_swap
19:02 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...
19:03 masak not_gerd: oh!
19:03 masak not_gerd: yes, a literal paste. I try to make those.
19:03 masak ok, trying with AO_*, then.
19:03 not_gerd well, good thing I looked at the backscroll again ;)
19:03 masak ;)
19:09 * jnthn back
19:09 jnthn How's the atomics work going? :)
19:13 masak ooh! it linked! \o/
19:13 jnthn Like a chain of sausages
19:14 masak though with a few warnings, predictably.
19:14 masak jnthn: your mom is like a chain of sausages.
19:14 cognominal joined #moarvm
19:14 * not_gerd throws http://www.math.sci.hiroshim​a-u.ac.jp/~m-mat/MT/TINYMT/ into the mix as backing algorithm for our random numbers
19:15 not_gerd needs 16 bytes of state
19:15 jnthn .oO( Can't we just role some dice? :P )
19:17 masak diakopter: I was surprised that https://github.com/MoarVM/MoarVM/commit/6247​2fbd36b49b6fdcfc40e47b75ec58691a58d0#L2R205 and before that https://github.com/MoarVM/MoarVM/commit/7097​fb4460b2854fc3166d132d5a838c494514cc#L6R222 made CAS operations, but didn't check the return value.
19:17 masak diakopter: out of 10 CAS operations in the source, only those 2 don't check the result. so they stood out a little.
19:20 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
19:20 jnthn It's fair play, but deserving of a comment.
19:20 masak +1
19:21 diakopter i'll look at those kinks in a bit to see if thats the csse yhere
19:21 diakopter limks
19:21 diakopter links
19:21 diakopter casr
19:21 diakopter case
19:21 diakopter therr
19:21 diakopter there
19:21 diakopter argh
19:22 jnthn how do you type THAT badly???
19:22 masak phone, prolly.
19:22 diakopter phobt
19:22 masak :P
19:22 benabik Go home diakopter's keyboard, you're drunk.
19:22 diakopter phone
19:22 BabsSeed lol
19:22 BabsSeed Buy a better phone :D
19:23 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
19:23 not_gerd someone now only needs to decide if we want to do it or not
19:23 not_gerd custom fixed-sized integer types are so 90s
19:24 diakopter 1890s
19:24 diakopter or 2090s
19:25 jnthn I hate it when autocorrect makes me look regarded
19:26 * moritz spots an autopun!
19:26 diakopter bwahahz
19:28 * masak imagines diakopter laughing explosively, then falling asleep just as quickly
19:31 diakopter not far from the truth but I'm also drivimg
19:31 jnthn wtf!
19:31 FROGGS -.-
19:32 FROGGS diakopter: put it away, please
19:33 diakopter kiddong
19:33 diakopter about to drive tho
19:33 diakopter bbl
19:51 * masak is finally getting somewhere
20:03 dalek MoarVM/apr_to_libatomic_trial_1: 5c14ad5 | masak++ | src/ (6 files):
20:03 dalek MoarVM/apr_to_libatomic_trial_1: s/apr_atomic_\w+/AO_fetch_and_compare/g
20:03 dalek MoarVM/apr_to_libatomic_trial_1:
20:03 dalek MoarVM/apr_to_libatomic_trial_1: Also changed MVMFrame->gc_seq_number and MVMThreadContext->gc_status
20:03 dalek MoarVM/apr_to_libatomic_trial_1: to type AO_t, becuase that's what the above function expects.
20:03 dalek MoarVM/apr_to_libatomic_trial_1: review: https://github.com/MoarVM/MoarVM/commit/5c14ad59d7
20:04 masak please review/advise the above.
20:04 masak it's what I have so far.
20:05 masak phenome-wise, it builds just fine (both moar and nqp-cc), but it hangs on t/moar/gc.t
20:08 not_gerd masak: you lost some volatile qualifiers
20:09 not_gerd or does the AO_t typedef include that?
20:09 * not_gerd goes looking
20:10 masak oh!
20:10 masak no, probably not.
20:10 * masak adds them back
20:10 not_gerd (it doesn't)
20:13 masak ok, trying that.
20:14 not_gerd not sure if that should make a difference as the threads and target_tray variables are declared volatile themselves
20:16 not_gerd I suspect gc_seq_number and gc_status should be volatile-qualified as well
20:17 masak way ahead of you there ;)
20:19 not_gerd hm...
20:19 not_gerd http://stackoverflow.com/questions/146​75975/gcc-atomic-builtins-and-volatile # random google search
20:19 masak gc.t still hangs, though. :/
20:19 dalek MoarVM/apr_to_libatomic_trial_2: a4c807d | masak++ | src/ (6 files):
20:19 dalek MoarVM/apr_to_libatomic_trial_2: s/apr_atomic_\w+/AO_fetch_and_compare/g
20:19 dalek MoarVM/apr_to_libatomic_trial_2:
20:19 dalek MoarVM/apr_to_libatomic_trial_2: Also changed MVMFrame->gc_seq_number and MVMThreadContext->gc_status
20:19 dalek MoarVM/apr_to_libatomic_trial_2: to type AO_t, becuase that's what the above function expects.
20:19 dalek MoarVM/apr_to_libatomic_trial_2:
20:19 dalek MoarVM/apr_to_libatomic_trial_2: The 'volatile' modifier is still kept on the AO_t, as it was on the
20:19 dalek MoarVM/apr_to_libatomic_trial_2: void pointer.
20:19 dalek MoarVM/apr_to_libatomic_trial_2: review: https://github.com/MoarVM/MoarVM/commit/a4c807d272
20:20 diakopter .oO( every commit a branch )
20:21 masak branches are cheap.
20:21 masak I'll clean up after myself afterwards. :)
20:21 masak not_gerd: I read through it. not sure how it applies to my case.
20:21 masak anyway, the good news so far is that it actually compiles and everything. I didn't expect that!
20:22 masak the bad news is that gc.t now hangs, for reasons I cannot guess.
20:23 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 not_gerd volatile and _Atomic are (mostly but not quite) orthogonal
20:23 diakopter ok
20:24 not_gerd (_Atomic would be the C11 way to do this stuff)
20:26 not_gerd "Volatile is for reading from tape drives. Atomics are for concurrency. One has nothing to do with the other."
20:26 not_gerd ^^ another nice quote from SO
20:27 masak heh :)
20:28 masak not_gerd: the correct action may be obvious to you, but it isn't to me...
20:28 masak do I add __sync... somewhere?
20:29 diakopter not_gerd: but that's not true
20:30 not_gerd masak: no
20:30 not_gerd AO_* wraps the gc __sync_* stuff
20:30 not_gerd s/gc/gcc/
20:34 masak so, adding volatile was unnecessary and essentially a no-op?
20:37 not_gerd masak: not so sure about that
20:37 not_gerd depending on your compiler, it can do the right thing
20:39 not_gerd the point is, you *shouldn't* need volatile to make it work
20:40 masak ok, what I hear is "unnecessary". :)
20:41 masak anyway, I don't know how to move forward from this spot.
20:41 masak it was an interesting experiment, for sure. hopefully it can be of help to someone else.
20:41 not_gerd I can check what happens on windows
20:44 masak thanks.
20:45 not_gerd (waiting for nqp-cc to compile)
20:50 not_gerd and gc.t hangs
20:52 masak well, 9 of the 10 replaced calls were in src/gc/, so I guess it makes sense.
20:53 masak but that means the change added something bad or removed something useful.
20:55 diakopter probably just inverted args
21:00 not_gerd that could bery well be the case
21:00 not_gerd *very
21:01 not_gerd http://apr.apache.org/docs/ap​r/1.4/group__apr__atomic.html vs https://github.com/ivmai/li​batomic_ops/tree/master/doc agrees
21:02 masak d'oh.
21:03 masak I looked at the orders, noticed they were reversed, but then somehow convinced myself they weren't.
21:03 masak ok, I can now make a third attempt. hold on.
21:03 dalek joined #moarvm
21:08 masak wohoo, gc.t didn't hang \o/
21:09 masak same 5 test failures as before the patch.
21:10 dalek MoarVM/apr_to_libatomic_trial_3: 6f0a5c7 | masak++ | src/ (6 files):
21:10 dalek MoarVM/apr_to_libatomic_trial_3: s/apr_atomic_\w+/AO_fetch_and_compare/g
21:10 dalek MoarVM/apr_to_libatomic_trial_3:
21:10 dalek MoarVM/apr_to_libatomic_trial_3: The second and third arguments were interchanged, due to different function
21:10 dalek MoarVM/apr_to_libatomic_trial_3: signatures.
21:10 dalek MoarVM/apr_to_libatomic_trial_3:
21:10 dalek MoarVM/apr_to_libatomic_trial_3: Also changed MVMFrame->gc_seq_number and MVMThreadContext->gc_status
21:10 dalek MoarVM/apr_to_libatomic_trial_3: to type AO_t, becuase that's what the above function expects.
21:10 dalek MoarVM/apr_to_libatomic_trial_3: review: https://github.com/MoarVM/MoarVM/commit/6f0a5c7f7b
21:10 masak I advise review of the above commit, and merging into master.
21:10 masak in fact, while you do that, let me try to remove the APR dependency :)
21:12 masak hm... the obvious thing didn't work: https://gist.github.com/masak/6336338 :)
21:13 not_gerd masak: that's only possible if you combine your atomic stuff with JimmyZ's libuv5
21:13 masak oh!
21:13 not_gerd you should be able to remove apr_atomic.h
21:13 * masak tries that
21:13 masak would it be interesting to rebase my work on top of JimmyZ's branch?
21:13 not_gerd masak: yes
21:14 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
21:14 dalek MoarVM/apr_to_libatomic_trial_3: 56c47ed | masak++ | src/moarvm.h:
21:14 dalek MoarVM/apr_to_libatomic_trial_3: remove apr_atomic dependency
21:14 dalek MoarVM/apr_to_libatomic_trial_3: review: https://github.com/MoarVM/MoarVM/commit/56c47ed835
21:15 masak never too late in Git, though
21:17 diakopter git was once an invective
21:18 masak getting some build errors. hold on, let me push what I haz.
21:18 dalek MoarVM/libuv5+no_apr_atomic: de32839 | (Gerhard R)++ | build/setup.pm:
21:18 dalek MoarVM/libuv5+no_apr_atomic: Pass flags for compiling shareable objects down to APR
21:18 dalek MoarVM/libuv5+no_apr_atomic: review: https://github.com/MoarVM/MoarVM/commit/de32839bc1
21:18 dalek MoarVM/libuv5+no_apr_atomic: 4fbf203 | (Gerhard R)++ | build/ (2 files):
21:18 dalek MoarVM/libuv5+no_apr_atomic: Add . to library search path
21:19 masak (the rebase went fine, except for a trivial conflict in src/moarvm.h)
21:19 masak I'll nopaste my build problems.
21:19 dalek joined #moarvm
21:19 not_gerd I'd like to see those AO_* calls put behind some macros like https://gist.github.com/gerdr/6e8c183fc1039293133a
21:20 diakopter yah
21:20 not_gerd preserves a tiny bit of type safety
21:20 masak not_gerd: will do.
21:20 masak *nod*
21:20 masak build problems: https://gist.github.com/masak/6336393
21:20 masak while you look at that, I'll look into making a macro.
21:22 not_gerd apparently, we depended on implicitly including stdarg.h through APR
21:22 masak heh :)
21:23 not_gerd just put #include <stdarg.h> at the top of moarvm.h for a quick fix
21:23 masak oki
21:24 masak it got further.
21:24 jnthn sleep time
21:24 jnthn 'night, #moarvm
21:24 not_gerd o/
21:24 FROGGS gnight
21:25 masak moar build errors: https://gist.github.com/masak/6336419
21:25 masak ah:
21:25 masak src/core/threads.c:150:22: error: ‘APR_SUCCESS’ undeclared (first use in this function)
21:26 masak indeed, that line says 'status = APR_SUCCESS;'
21:26 FROGGS whee ud
21:26 not_gerd probably just 0
21:27 masak ok.
21:27 not_gerd #define APR_SUCCESS 0
21:27 FROGGS apr_errno.h:225:#define APR_SUCCESS 0
21:27 not_gerd from 3rdparty/apr/include/apr_errno.h
21:27 FROGGS yeah
21:27 not_gerd ;)
21:28 masak that's the only mention of APR_SUCCESS in the whole source code.
21:29 not_gerd we still use APR for some random bits
21:29 not_gerd random taking literally
21:29 masak or indeed the only mention of any APR_* constant.
21:29 masak now it builds! \o/
21:29 not_gerd that's why I proposed including TinyMT some ways up
21:29 not_gerd should fail to link
21:30 not_gerd apr_generate_random_bytes will be missing
21:30 dalek MoarVM/libuv5+no_apr_atomic: ed81ae1 | masak++ | src/ (2 files):
21:30 dalek MoarVM/libuv5+no_apr_atomic: slight cleanup after removing APR
21:30 dalek MoarVM/libuv5+no_apr_atomic:
21:30 dalek MoarVM/libuv5+no_apr_atomic: Turned out we were indirectly depending on stdarg.h, so adding that as a direct
21:30 dalek MoarVM/libuv5+no_apr_atomic: dependency instead.
21:30 dalek MoarVM/libuv5+no_apr_atomic:
21:30 dalek MoarVM/libuv5+no_apr_atomic: Also, there was one mention of APR_SUCCESS, which I simply replaced by 0 and
21:30 dalek MoarVM/libuv5+no_apr_atomic: an explanatory comment.
21:30 dalek MoarVM/libuv5+no_apr_atomic: review: https://github.com/MoarVM/MoarVM/commit/ed81ae1b87
21:31 masak not_gerd: well, it didn't fail to link.
21:31 not_gerd that's surprising
21:31 * masak gets back to the macros
21:31 masak not_gerd: build it and see for yourself... :)
21:32 not_gerd actually, it's not surprising as we still link against APR
21:32 masak oh!
21:33 masak that should probably go as well, I guess.
21:33 not_gerd you should get a warning about an implicitly  defined function, though
21:35 masak mebbe.
21:38 dalek MoarVM/apr_to_libatomic_trial_3: 15e451d | masak++ | src/ (5 files):
21:38 dalek MoarVM/apr_to_libatomic_trial_3: introduce a macro
21:38 dalek MoarVM/apr_to_libatomic_trial_3:
21:38 dalek MoarVM/apr_to_libatomic_trial_3: And replace all occurrences of AO_fetch_compare_and_swap, essentially
21:38 dalek MoarVM/apr_to_libatomic_trial_3: hiding them behind a thin layer of sanity.
21:38 dalek MoarVM/apr_to_libatomic_trial_3: review: https://github.com/MoarVM/MoarVM/commit/15e451dc14
21:39 masak it builds! and on the rebased branch, too! :)
21:39 not_gerd \o/
21:39 not_gerd masak++
21:40 dalek MoarVM/libuv5+no_apr_atomic: 1e5b3e1 | masak++ | src/ (5 files):
21:40 dalek MoarVM/libuv5+no_apr_atomic: introduce a macro
21:40 dalek MoarVM/libuv5+no_apr_atomic:
21:40 dalek MoarVM/libuv5+no_apr_atomic: And replace all occurrences of AO_fetch_compare_and_swap, essentially
21:40 dalek MoarVM/libuv5+no_apr_atomic: hiding them behind a thin layer of sanity.
21:40 dalek MoarVM/libuv5+no_apr_atomic: review: https://github.com/MoarVM/MoarVM/commit/1e5b3e1cc5
21:40 benabik left #moarvm
21:40 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 masak the fact that we still link APR is a bit of a loose end.
21:40 not_gerd sockets are still broken there
21:41 not_gerd compiles, but doesn't work
21:41 masak ah.
21:41 not_gerd also, we need a new random generator
21:41 masak well, I'll just leave it like this, then, I think.
21:41 masak I removed the earlier experiment branches.
21:41 masak but I'll leave the above two tips there if anyone wants them.
21:45 diakopter masak: for redundancy.. parens around the args in MVM_cas macro definition
21:46 masak excellent point.
21:46 * masak fixes
21:46 not_gerd actually, should be OK without them
21:46 not_gerd but add them for consistency anyway
21:48 masak hm, they're not in any of the pre-existing macro definitions in that file...
21:48 masak so I dunno about consistency.
21:48 diakopter oh :)
21:49 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
21:49 masak I think I'll leave it as it is.
21:49 not_gerd if you add parens around macro parameters defensively, aou'll never run into the problem of forgetting them where they are necessary
21:49 masak *nod*
21:50 masak I know about the problem it solves :)
21:50 not_gerd of course if you're confident enough in your C knowledge *shrugs*
21:51 * diakopter wonders what this is https://github.com/tokuhirom/Perl6-PVIP
21:51 diakopter jnthn: ^
21:52 masak jnthn just went offline, because teaching tomorrow.
21:52 diakopter masak: have you seen that?
21:52 diakopter also https://github.com/tokuhirom/pvip/
21:53 masak no, I hadn't seen.
21:53 masak looking at it now.
21:53 masak probably deserves a mention on #perl6, as well.
21:54 masak so, it's a yacc grammar for Perl 6.
21:54 masak yeah, well, that's one kind of self-inflicted pain.
21:55 diakopter well no
21:55 diakopter it's a peg/greg grammar generator generator
21:58 diakopter the last two compilers I wrote used greg parsers
21:58 diakopter as does rurban's p2
21:58 diakopter (the two before those two used antlr parsers)
22:00 diakopter the most recent one being a little pir-like language for moarvm
22:00 masak I see.
22:01 diakopter tokuhirom_: ping :)
22:01 colomon joined #moarvm
22:03 dalek MoarVM/noapr: fbdf144 | (Gerhard R)++ | build/ (3 files):
22:03 dalek MoarVM/noapr: No longer build APR
22:03 dalek MoarVM/noapr: review: https://github.com/MoarVM/MoarVM/commit/fbdf1446e8
22:04 not_gerd there's something funny going on with the winsock headers in that branch
22:04 not_gerd so I can't actually test it right now
22:04 not_gerd but *now* it should fail to link ;)
22:05 diakopter not_gerd: what are your thoughts on using assertions [anywhere]?
22:06 not_gerd diakopter: I generally find them rather useful
22:07 BenGoldberg joined #moarvm
22:08 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:09 diakopter not_gerd: so the dll branch can build a .dll? also can it build a static (but not executable) lib?
22:10 not_gerd diakopter: dll branch has landet in master
22:10 diakopter oh ok
22:10 not_gerd you should be able to do Configure.pl --shared
22:10 diakopter oh hm
22:10 diakopter does it build shared in addition to the normal?
22:11 diakopter or just the shared
22:11 not_gerd either static or shared
22:11 diakopter I wish it could build both
22:11 diakopter would it be hard to make it do both?
22:11 not_gerd well, it means putting the .o files somewhere else
22:12 not_gerd one set with and one without -fPIC
22:12 diakopter can you put a prefix on them?
22:12 not_gerd sure
22:12 diakopter (so you don't have to move)
22:13 not_gerd assuming MSVC will just ignore __declspec annotations if we don't build with /dll
22:13 not_gerd otherwise, that needs to be handles as well
22:13 diakopter has someone gone through and marked the public api?
22:14 not_gerd no, just the few functions used by main.c
22:14 diakopter ah
22:14 diakopter which things need marked? functions, macros? structs?
22:15 diakopter includes?
22:15 diakopter or are we just marking the private things and assuming the rest is public?
22:15 diakopter like the includes
22:16 diakopter (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
22:16 diakopter hm, oh
22:16 not_gerd on windows, it's private by default, on *nix, it's public by default
22:17 not_gerd marking stuff MVM_PRIVATE probably will improve load times on non-windows
22:18 not_gerd (if our API ever grows so large it becomes an issue)
22:18 diakopter has jnthn commented on which things he wants private?
22:18 not_gerd no, just that he's fine with making everything either public or private
22:18 diakopter hah, okay
22:18 not_gerd either it's part of the API, or it's not
22:19 diakopter oh, you mean "anything"
22:19 diakopter or "each thing"
22:19 not_gerd yea, that ;)
22:19 not_gerd marking everything with one or the other would fail 50% of the time
22:19 not_gerd (ie when everything is privte ;))
22:20 diakopter is noapr ready to merge?
22:20 not_gerd no
22:20 diakopter what's remaining?
22:20 not_gerd socket failures and we need a new random generator
22:21 diakopter did anyone complain about the one you suggested?
22:21 diakopter if not, just use that :)
22:22 * flussence saw a PRNG mentioned on /r/programming a few days back...
22:23 diakopter our pseudo-randomness is hardly critical at the moment
22:23 diakopter no need to spend much time on it
22:23 diakopter just make a note to revisit it
22:23 not_gerd it needs a bot of adjusting so the algorithm parameters are shared and just the state needs to be thread-local
22:23 not_gerd * bit
22:23 not_gerd to get it to build, just return 42 or whatever
22:24 diakopter our hash library uses its own randomness thing, I think
22:24 diakopter not_gerd: heh.
22:25 dalek MoarVM/serialize: 0e86db8 | (Gerhard R)++ | build/setup.pm:
22:25 dalek MoarVM/serialize: Pass flags for compiling shareable objects down to APR
22:25 dalek MoarVM/serialize: review: https://github.com/MoarVM/MoarVM/commit/0e86db8379
22:25 dalek MoarVM/serialize: 79e015c | (Gerhard R)++ | build/ (2 files):
22:25 dalek MoarVM/serialize: Add . to library search path
22:25 dalek MoarVM/serialize: review: https://github.com/MoarVM/MoarVM/commit/79e015c85e
22:25 dalek MoarVM/serialize: b05527e | (Gerhard R)++ | src/core/interp.h:
22:25 dalek MoarVM/serialize: Make void MVM_interp_enable_tracing() public
22:25 dalek MoarVM/serialize: review: https://github.com/MoarVM/MoarVM/commit/b05527e3d1
22:25 dalek MoarVM/serialize: bad169b | (Gerhard R)++ | / (4 files):
22:25 dalek MoarVM/serialize: Add some make targets - in particular 'help'
22:25 dalek MoarVM/serialize: review: https://github.com/MoarVM/MoarVM/commit/bad169bd5d
22:26 diakopter ok, time to try to unblock jnthn
22:31 diakopter not_gerd: have you thought about an install target? I'd like it to be easy to have the following scenarios:
22:31 diakopter 1. install moarvm executable (as it is currently essentially) in /usr/bin or LSB or whatever
22:31 diakopter 2. same for shared and static libraries
22:32 diakopter 3. install (including nqp executable and dependencies!) to perl5 install tree
22:33 diakopter 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
22:34 not_gerd mor 'interesting' are the headers and how to factor NQP into that
22:34 not_gerd s/mor/moar/
22:35 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 diakopter not_gerd: did you read the docs/extops.markdown? if so, did you have any thoughts/comments?
22:37 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 :()
22:38 not_gerd I wasn't - as far as *I* can remember ;)
22:38 dalek MoarVM/serialize: e9b3089 | diakopter++ | src/6model/serialization.c:
22:38 dalek MoarVM/serialize: nuke trailing whitespace
22:38 dalek MoarVM/serialize: review: https://github.com/MoarVM/MoarVM/commit/e9b3089b56
22:41 * diakopter wonders what PARROT_CALLCONTEXT does
22:42 diakopter strangely, google's no help
22:42 diakopter oh.
22:43 diakopter ergh.
22:43 diakopter need chromatic or someone
22:43 not_gerd just return the attribute structure, doesn't it?
22:43 diakopter yeah
22:43 diakopter well pmc data
22:46 diakopter ah well, I'll just guess
22:47 diakopter I'm not usually horrible at that
22:48 diakopter actually, still ergh
22:53 diakopter golly, this is quite complex
23:01 diakopter hrm
23:01 diakopter actually
23:02 diakopter 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:03 diakopter hrm
23:03 cognominal__ joined #moarvm
23:05 diakopter argh argh argh
23:07 diakopter not_gerd: I'm having trouble discerning jnthn's intent here
23:08 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?
23:12 diakopter (and just every object that's not already in an sc?)
23:12 diakopter b/c I suspect that a lot of this code isn't needed
23:14 diakopter .. and I'm not entirely sure which
23:14 diakopter argh, I'm suspecting only jnthn can do it from here :(
23:15 diakopter .tell yoleaux < diakopter> argh, I'm suspecting only jnthn can do it from here :(
23:15 yoleaux diakopter: Thanks for the message.
23:15 diakopter erm.
23:15 diakopter .tell jnthn < diakopter> argh, I'm suspecting only jnthn can do it from here :(
23:15 yoleaux diakopter: I'll pass your message to jnthn.
23:17 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 not_gerd (if it's not already associated to a sc)
23:17 diakopter well in that case... this can actually be simplified *greatly*
23:17 diakopter by delegating it all to the reprs
23:18 diakopter also I don't see special code to handle compunits
23:18 diakopter ergh
23:19 not_gerd yeah, the if/elsif, switch kinda begs for a refactor
23:19 not_gerd would be interesting to see how the java version looks
23:21 not_gerd interesting - as suspected, the java stuff uses instanceof for that
23:21 not_gerd which is kinda an anti-pattern
23:21 diakopter well, I dunno.
23:23 diakopter hrm.
23:26 diakopter well I can follow the java version better.
23:26 diakopter so I'll just copy that for now
23:30 diakopter well, maybe.
23:32 diakopter .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 #moarvm

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