Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-08-17

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

All times shown according to UTC.

Time Nick Message
00:12 cognominal joined #moarvm
00:22 FROGGS joined #moarvm
00:23 BenGoldberg joined #moarvm
00:42 donaldh joined #moarvm
01:49 FROGGS joined #moarvm
02:23 dalek MoarVM: 09ecf26 | diakopter++ | / (47 files):
02:23 dalek MoarVM: add a few more ops; make compunit and staticframe reprs
02:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/09ecf26421
02:23 dalek MoarVM: f45dafe | diakopter++ | / (66 files):
02:23 dalek MoarVM: Merge branch 'master' of github.com:MoarVM/MoarVM
02:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f45dafebac
02:23 dalek MoarVM: 1d531d3 | diakopter++ | src/ (5 files):
02:23 dalek MoarVM: finish merging
02:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1d531d326f
02:23 dalek MoarVM: df6c1e4 | diakopter++ | src/ (3 files):
02:23 dalek MoarVM: small fixes
02:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/df6c1e4b20
02:23 dalek MoarVM: 3e92deb | diakopter++ | src/core/exceptions.c:
02:23 dalek MoarVM: more precise labels
02:23 diakopter bah
02:24 diakopter FROGGS: ping
02:25 diakopter well, technically I broke the cc build
02:29 diakopter I guess I'll just have to fix it!
02:55 colomon joined #moarvm
02:58 diakopter colomon: hi
02:58 colomon \o
02:59 diakopter colomon: :D
03:03 dalek MoarVM/libuv1: 47d6cd8 | jimmy++ | src/io/ (2 files):
03:03 dalek MoarVM/libuv1: fixed bugs, passed 77-file-io.t
03:03 dalek MoarVM/libuv1: review: https://github.com/MoarVM/MoarVM/commit/47d6cd880f
03:21 dalek MoarVM: d8c1a84 | diakopter++ | / (2 files):
03:21 dalek MoarVM: bit more debugging
03:21 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d8c1a84422
04:10 TimToady hmm, src/core/interp.c:2898:25: error: lvalue required as unary ‘&’ operand
04:23 diakopter TimToady: ?
04:24 TimToady what happens when I try to do make in the top dir
04:24 diakopter after pulling just now?
04:24 * diakopter goes to linux vm
04:24 TimToady yes, up-to-date
04:24 diakopter erm, maybe it'd help if I had a linux vm
04:27 diakopter TimToady: hunh.
04:29 grondilu joined #moarvm
04:29 dalek MoarVM: f2af649 | diakopter++ | src/core/interp.c:
04:29 dalek MoarVM: TimToady++ bug
04:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f2af649a5f
04:29 diakopter TimToady: ^
04:31 TimToady src/6model/reprs.o: In function `MVM_repr_initialize_registry':
04:31 TimToady /home/larry/MoarVM/src/6model/reprs.c:252: undefined reference to `MVMStaticFrame_initialize'
04:31 TimToady /home/larry/MoarVM/src/6model/reprs.c:253: undefined reference to `MVMCompUnit_initialize'
04:31 diakopter wha
04:31 diakopter oops
04:32 diakopter erm
04:33 diakopter try make clean
04:33 TimToady did
04:33 diakopter weeuhd
04:34 diakopter are you using clang
04:34 TimToady no, gcc
04:34 diakopter hm, me too
04:37 diakopter .. but those functions are right there in the .h included from reprs.h
04:38 TimToady hmm, there's no MVMStaticFrame.o
04:38 diakopter oh you have to reconfigure
04:39 diakopter lol, should make Makefile rewrite itself using Configure if Makefile.in changes ;D
04:39 TimToady would be nice if it could say so, dunno how rakueo does it
04:40 * grondilu thinks the function should rather be in frame.o, not in MVMStaticFrame.o
04:40 TimToady that appears to have fixed it
04:41 diakopter the enormous refactoring at https://github.com/MoarVM/MoarVM/commit/​09ecf264213409c1719f09afbfa9fc7a14598fd7 and following remove the memory leak of "eval" by making essentially everything garbage collected
04:42 benabik joined #moarvm
04:43 dalek MoarVM/libuv1: fd2cb03 | jimmy++ | src/ (12 files):
04:43 dalek MoarVM/libuv1: port all apr threads api to libuv api
04:43 dalek MoarVM/libuv1: review: https://github.com/MoarVM/MoarVM/commit/fd2cb03957
04:44 diakopter JimmyZ: you've been doing amazing work lately; you deserve a gold star
04:45 JimmyZ :P
04:45 diakopter uv_mutex_t is a pointer?
04:46 JimmyZ no
04:46 diakopter ok
04:47 JimmyZ so it doesn't needs malloc
04:47 diakopter ok
04:47 JimmyZ anyway, apr mem_pool is a bit annoying :)
04:48 diakopter yes
04:48 diakopter JimmyZ: can you see if master merges to libuv1?
04:48 diakopter I changed ... a lot
04:48 diakopter I wish github would tell me if master would merge cleanly to a branch
04:49 * grondilu got a segmentation fault:
04:49 grondilu nqp nqp-moar-cc.nqp --target=mbc --setting=NQPCOREMoar --no-regex-lib --output=QASTCompilerMAST.moarvm src/QASTCompilerMAST.nqp
04:49 grondilu make: *** [QASTCompilerMAST.moarvm] Segmentation fault
04:49 diakopter o_O
04:51 * grondilu tried again and got the same seg. fault
04:51 diakopter I guess I should try things on linux too after pushing from windows...
04:51 diakopter grondilu: well, at least it's repeatable
04:51 diakopter grondilu: which OS/compiler
04:52 grondilu gcc (Debian 4.8.1-8) 4.8.1
04:52 grondilu Copyright (C) 2013 Free Software Foundation, Inc.
04:52 grondilu This is free software; see the source for copying conditions.  There is NO
04:52 grondilu warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
04:52 grondilu oops, sorry for the long output, I ran /exec -out gcc --version
04:53 diakopter I don't warrant my own fitness either :D
04:53 grondilu Linux redkey 3.10-0.towo-siduction-686 #1 SMP PREEMPT Wed Jul 3 10:05:10 UTC 2013 i686 GNU/Linux
04:54 diakopter oh yeah, 32-bit.
04:54 diakopter 2nd-class citizen
04:54 grondilu :(
04:54 TimToady make test works here in nqp-cc
04:54 diakopter kidding.. I get the same on 64-bit
04:54 diakopter TimToady: !!!!!!!!!!!
04:54 TimToady except for the thread.t
04:54 TimToady *threads.t
04:55 diakopter TimToady: it compiled NQPP6QRegex.moarvm ??
04:55 diakopter grondilu: oh, yes, mine segfaults there too
04:55 diakopter TimToady: oh, did you reconfigure nqp-cc ?
04:56 TimToady trying
04:56 diakopter grondilu: yes, I haven't figured out why that does that yet..
04:56 diakopter but it shouldn't segfault
04:56 diakopter I'll fix that first
04:57 dalek MoarVM/libuv5: 61c8396 | jimmy++ | / (53 files):
04:57 dalek MoarVM/libuv5: Merge branch 'master' into libuv5
04:57 dalek MoarVM/libuv5:
04:57 dalek MoarVM/libuv5: Conflicts:
04:57 dalek MoarVM/libuv5: src/core/interp.c
04:57 dalek MoarVM/libuv5: src/core/oplist
04:57 dalek MoarVM/libuv5: src/core/ops.c
04:57 dalek MoarVM/libuv5: src/core/ops.h
04:57 dalek MoarVM/libuv5: src/io/fileops.c
04:57 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/61c83960e1
04:57 JimmyZ diakopter: ^^
04:57 diakopter libuv5? :)
04:58 JimmyZ based libuv1 branch, with a merge
04:58 JimmyZ libuv1 is for jnthn++ :P
04:59 diakopter right
04:59 TimToady kablooey
04:59 JimmyZ diakopter: I fixed these Confilicts
04:59 diakopter oh ok
04:59 diakopter TimToady: hint, it's in parrot ;)
04:59 TimToady sugoi
05:00 TimToady maybe you should use JVM instead :P
05:00 diakopter "
05:00 diakopter Japanese equivalent of either "awesome" or "awful". Most frequently used to mean the former, at least among westerners."
05:01 TimToady terrific comes close if you allow the ironic meaning
05:01 diakopter I get all my knowledge from urbandictionary
05:02 TimToady well, it's not even ironic in "a terrific explosion"
05:03 dalek MoarVM: 2317be7 | diakopter++ | src/mast/compiler.c:
05:03 dalek MoarVM: less debugging
05:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2317be7cac
05:04 TimToady 'course, rakudo/jvm doesn't even *build* right now :(
05:04 diakopter methinks jnthn will fix that when he awakens in a few hours
05:04 diakopter er, wakes
05:04 * TimToady doesn't see anything wrong with "awakens"
05:05 TimToady "wakes" seems a bit archaic
05:05 grondilu it sounds weird unless jnthn is a Godzilla
05:05 diakopter you're thinking of akraken
05:05 grondilu (or a zombie)
05:06 diakopter that last commit makes it die betterly
05:08 diakopter I don't really know how to diagnose it
05:10 TimToady chop out lines until the problem disappears?
05:10 diakopter *whimper*
05:11 grondilu os_version=`uname -r | sed -e 's/\(.\)\.\(.\)[\.-]\(.\).*/\1\2\3/'
05:11 grondilu ^this still does not parse my kernel
05:11 grondilu 3.10-0.towo-siduction-686
05:12 FROGGS joined #moarvm
05:12 dalek MoarVM/libuv1: eac6e83 | jimmy++ | src/io/fileops.c:
05:12 dalek MoarVM/libuv1: added a few comments to MVM_file_readline_fh
05:12 dalek MoarVM/libuv1: review: https://github.com/MoarVM/MoarVM/commit/eac6e83aac
05:18 dalek MoarVM/libuv1: 0e63714 | jimmy++ | src/io/procops.c:
05:18 dalek MoarVM/libuv1: port MVM_proc_time_i/MVM_proc_time_n function to libuv api
05:18 dalek MoarVM/libuv1: review: https://github.com/MoarVM/MoarVM/commit/0e63714695
05:25 FROGGS joined #moarvm
05:37 dalek MoarVM: 0d7c224 | diakopter++ | nqp-cc/tools/build/Makefile.in:
05:37 dalek MoarVM: don't build the latest broken thing yet
05:37 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0d7c2241c6
05:39 dalek MoarVM/libuv1: 21a974f | jimmy++ | src/core/interp.c:
05:39 dalek MoarVM/libuv1: re-implemented sleep op
05:39 dalek MoarVM/libuv1: review: https://github.com/MoarVM/MoarVM/commit/21a974f0ca
05:42 JimmyZ left parts: socket, opendir/readdir, mmap
05:44 diakopter JimmyZ++
05:45 diakopter JimmyZ: also a couple cas32 things
05:45 JimmyZ that one just s///
05:46 diakopter well the fields it uses need to be 64-bit for the MVM_cas to use it
05:46 diakopter (on 64-bit machine anyway)
05:46 JimmyZ yeah
05:47 JimmyZ and I know nothing about it :P
05:49 JimmyZ diakopter: If you could help, we can merge it much faster :P
05:53 diakopter JimmyZ: just change whatever field you're CAS'ing to a AO_t
05:53 diakopter it'll always be wide enough
05:53 FROGGS joined #moarvm
05:54 JimmyZ diakopter: I meant socket and mmap part :P
05:55 diakopter oh
05:56 JimmyZ socket is about 250 lines code
06:16 FROGGS diakopter: pong
06:22 diakopter FROGGS: just letting you know I put in those new ops finally
06:22 diakopter who knows whether they work..
06:22 diakopter FROGGS: could you import the things that test them, if any?
06:23 FROGGS diakopter: what are 'those ops'?
06:24 FROGGS freshcoderef etc?
06:24 diakopter yes
06:24 FROGGS I can look for tests, yes
06:25 not_gerd joined #moarvm
06:25 not_gerd o/
06:25 diakopter not_gerd: howdy
06:25 FROGGS hi
06:26 not_gerd for the mmap stuff, we need someone who knows the winapi
06:26 not_gerd http://msdn.microsoft.com/en-us/l​ibrary/aa366532%28v=vs.85%29.aspx
06:26 not_gerd ^makes it sound as if you need to keep the file handle around
06:26 not_gerd http://code.google.com/p/mman-win32/
06:26 not_gerd ^immediately closes it
06:26 not_gerd would be nice if the latter could be relied upon
06:27 diakopter can't use gpl
06:27 JimmyZ not_gerd: I think we can take a look at mmap api in apr
06:28 not_gerd JimmyZ: they keep the file handle around
06:28 not_gerd diakopter: I don't plan about using mmap-win32
06:28 JimmyZ diakopter: repr clones need MVMROOT? I couldn't see clone which may alloc object
06:28 not_gerd I just want to know if what they do is right
06:29 not_gerd it simplifies the implementation
06:29 diakopter JimmyZ: which one has MVMROOT
06:30 JimmyZ diakopter: freshcoderef
06:31 JimmyZ not_gerd: so you want whether mmap on windows that close the file handle works well or not?
06:31 diakopter JimmyZ: I think p6opaque copy_to can allocate...?
06:32 JimmyZ diakopter: I can't see the it, though jnthn++ said clone may alloc object
06:32 not_gerd JimmyZ: yes
06:33 not_gerd assuming mmap-win32 is used in practice, it should
06:34 not_gerd however, this use is not documented
06:34 JimmyZ not_gerd: I thought you said must keep the filehanle to avoid leaks
06:34 not_gerd JimmyZ: not closing the filehandle will produce a leak
06:34 JimmyZ not_gerd: msdn sometimes is wrong
06:34 not_gerd mmap-win32 closes it directly after creating the mapping
06:35 not_gerd so we don't leak an open handle
06:35 not_gerd just use mappings for a handle that's already been closed
06:35 JimmyZ yeah, I want to close it :P
06:36 FROGGS diakopter: you forgot to add getstaticcode to QASTOperationsMAST.nqp
06:37 diakopter oops
06:38 FROGGS diakopter: you are going to add it, or should I?
06:42 dalek MoarVM: 0d93e27 | diakopter++ | nqp-cc/src/QASTOperationsMAST.nqp:
06:42 dalek MoarVM: FROGGS++ missing op mapping
06:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0d93e27ae2
06:42 diakopter <- wins
06:42 JimmyZ not_gerd: msdn said:  These calls to CloseHandle succeed even when there are file views that are still open. However, leaving file views mapped causes memory leaks.
06:43 JimmyZ so it's not a issue for loading bytecode
06:43 not_gerd JimmyZ: closing the filehandle without closing the fileviews leaks these views
06:43 not_gerd the uestion is, are these 'leaked' views fully functional?
06:44 not_gerd that's how mmap-win32 uses them
06:44 JimmyZ not sure :(
06:44 diakopter we don't care about leaking stuff loaded from disk, I'd think
06:44 diakopter only eval'd stuff
06:46 not_gerd there are 3 options:
06:46 not_gerd 1. keep track of the filehandle like apr
06:46 dalek MoarVM: 59b84b8 | (Tobias Leich)++ | nqp-cc/t/serialization/0 (3 files):
06:46 dalek MoarVM: added serialization tests, which segfault
06:46 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/59b84b8451
06:46 not_gerd 2. close the filehandle like mmap-win32 and use the file views anyway
06:46 not_gerd 3. leak the filehandle
06:47 FROGGS brb # breakfast
06:49 JimmyZ not_gerd: mman-win32 doesn't close os_handle?
06:53 * not_gerd needs to re-read the code
06:58 not_gerd http://code.google.com/p/mman-win​32/source/browse/trunk/mman.c#118
06:58 JimmyZ so, according msdn, I'd like to keep the filemapping handle :)
06:58 not_gerd I called it filehandle, but actually it's the handle of the file *mapping*
06:58 not_gerd so s/filehandle/file mapping handle/ in my 1.2.3.
06:59 JimmyZ not_gerd: it doesn't close "h"
06:59 not_gerd JimmyZ: correct
06:59 not_gerd that's the caller's responsibility
06:59 not_gerd closing h would close fildes
07:00 not_gerd it closes fm and still uses map
07:02 JimmyZ not_gerd: it doesn't return h :)
07:03 JimmyZ not_gerd: I'd like to +1 to 1. both apr and msdn do
07:04 not_gerd sure, but h is equivalent to fildes
07:04 not_gerd the caller provides fildes, so it doesn't need h
07:05 JimmyZ I mean +1 to 1. keep track of the filehandle like apr :P
07:05 not_gerd looking at the moarvm code, right now we do leak the mapping handle
07:06 not_gerd MVM_cu_map_from_file() only puts mmap_handle->mm intu cu
07:07 not_gerd mmap_handle->mv is lost
07:08 JimmyZ not_gerd: how about add libatomic_ops to configure?
07:08 not_gerd JimmyZ: it's already there
07:08 not_gerd JimmyZ: it's header-only on windows
07:08 not_gerd on other architectures, it shells out to its own configure
07:19 JimmyZ oh
07:21 FROGGS diakopter: https://gist.github.com/FR​OGGS/111a825365e629f4331c
07:23 FROGGS ohh, all nqptest fail that way :o(
07:24 JimmyZ we have serialize?
07:25 FROGGS JimmyZ: these tests cover the newly added ops at least
07:25 JimmyZ oh
07:25 FROGGS but the cc is broken, like diakopter said
07:31 crab2313 joined #moarvm
07:36 JimmyZ help! anyone knows how let uv_read returns what it reads?
07:37 JimmyZ a thread safe one :)
07:49 FROGGS is it possible that latest changes to nqp itself broke the cc?
07:50 JimmyZ cc works well on my libuv branch
07:50 JimmyZ if you mean nqp-cc
07:52 FROGGS yes
07:52 FROGGS what is your nqp revision?
07:53 JimmyZ 2013.07-25-g1541771
07:53 FROGGS thanks
07:59 crab2313 2013.07-22-gfb241ae, cc works well too
08:10 crab2313 on master
08:11 not_gerd diakopter: do you think we ever need to mmap files at an offset different from 0?
08:32 JimmyZ to replace apr_atomic_casptr, which libatomic_ops I should use?
08:42 cognominal joined #moarvm
08:45 not_gerd JimmyZ: possibly AO_compare_and_swap_full
08:45 not_gerd I'll need to look some more into libatomic_ops
08:49 not_gerd not quite  sure what's the differende between compare_and_swap and compare_and_swap_full
08:49 not_gerd *difference
08:49 JimmyZ not_gerd: thanks, I'm using compare_and_swap
08:49 JimmyZ some times compare_and_swap is defined to compare_and_swap_full
08:50 JimmyZ at least on windows7 x86 msvc
08:51 JimmyZ I'm confused with apr_atomic_casptr and  apr_atomic_cas32
08:56 not_gerd casptr maps to caompare_and_swap
08:56 not_gerd libatomic_ops operates by default on pointer-sized values
08:59 not_gerd for cas32, you probably should use AO_int_compare_and_swap
08:59 not_gerd (assuming int is 32-bit, which it is on all platforms moarvm currently supports)
09:01 JimmyZ #  define AO_int_compare_and_swap(addr, old, new_val) \
09:01 JimmyZ AO_compare_and_swap((volatile AO_t *)(addr), \
09:01 JimmyZ (AO_t)(old), (AO_t)(new_val))
09:02 not_gerd JimmyZ: on x86, but should not be on x64
09:03 not_gerd JimmyZ: you might want to preprocess the header and check which defines actually get used
09:03 JimmyZ not_gerd: the same
09:03 JimmyZ the same on x64
09:03 JimmyZ grep -r 'AO_int_compare_and_swap(' *
09:03 JimmyZ only this line :(
09:04 JimmyZ I know apr_atomic_casptr sometimes maps to apr_atomic_cas32, ie on gcc
09:05 JimmyZ but not on windows
09:05 JimmyZ I mean msvc
09:10 crab2313 weird, got QASTCompilerMAST.moarvm?К??? rather than QASTCompilerMAST.moarvm
09:13 diakopter oh!
09:13 diakopter crab2313: I'm getting a comma
09:13 diakopter instead of that
09:13 diakopter there must be a stray character in the Makefile.in
09:15 crab2313 diakopter: but the suffix is always different on my box
09:17 not_gerd JimmyZ: apr_atomic_casptr should be mapped tp AO_compare_and_swap according to documentation
09:17 not_gerd AO_int_compare_and_swap apparently doesn't exist on windows
09:18 diakopter crab2313: weird!
09:18 * not_gerd is back from getting rid of jehovah's witnesses at my door ;)
09:19 diakopter mace works well
09:19 diakopter (kidding)
09:19 JimmyZ not_gerd: and apr_atomic_cas32?
09:19 JimmyZ not_gerd: where is the doc?
09:19 diakopter not_gerd: yes, you need to define WIN98 or something to force it defined
09:20 diakopter I didn't know how two detect 32-bit
09:20 diakopter or else I would've added it
09:20 not_gerd JimmyZ: I was reading http://www.hpl.hp.com/researc​h/linux/atomic_ops/README.txt
09:20 not_gerd JimmyZ: a - I forgot the define
09:20 not_gerd (even though I added it to COnfigure.pl)
09:21 diakopter crab2313: it might be an apr error!
09:22 JimmyZ not_gerd: and how about apr_atomic_cas32?
09:22 diakopter JimmyZ: can't get it
09:22 diakopter I tried
09:22 diakopter have to use 64
09:24 JimmyZ diakopter: no api in libatomic_ops for apr_atomic_cas32?
09:24 diakopter no; have to use somehting size AO_t
09:25 JimmyZ I can't follow :(
09:26 not_gerd JimmyZ: libatomic_ops uses AO_t by default, which is a pointer-sized integer type
09:26 not_gerd for cas32, you'd have to use AO_int_
09:27 not_gerd but apparently they aren't available on windows?
09:27 diakopter yeah.
09:27 diakopter they should be though
09:27 diakopter I reported the bug a year ago
09:27 diakopter on libatomicops github
09:27 cognominal joined #moarvm
09:27 JimmyZ you mean that define?
09:28 diakopter not_gerd: oh, should probably update ours from https://github.com/ivmai/libatomic_ops/
09:30 not_gerd diakopter: looks like there's some activity, so might be a good idea
09:31 diakopter my 2nd issue is stil open there
09:31 colomon joined #moarvm
09:33 not_gerd diakopter: I believe manually adding -DAO_ASSUME_WINDOWS98 is the right thing to do
09:34 FROGGS I get the weird filenames too since two weeks or so? (since I last did something with moarvm
09:34 JimmyZ does it looks right? https://gist.github.com/zhuomingliang/6256105 , btw, I'm on win32
09:34 FROGGS )
09:34 JimmyZ x86
09:34 not_gerd I wonder if it might be easier to just take the atomic stuff from apr...
09:35 diakopter I thought it'd be easier to just use AO_t everywhere
09:35 not_gerd that, too
09:35 not_gerd or switch to C11
09:35 not_gerd they come with nice _Atomic types
09:36 diakopter msvc doen't do it
09:36 diakopter meesa loves msvc
09:36 not_gerd they actually just recently decided to add some more C99 features
09:36 not_gerd compound literals and some other stuff
09:37 not_gerd MS is worse at implementing C than we are at implementing Perl6 ;)
09:37 JimmyZ or we fixed libatomic_ops bug ourself?
09:38 not_gerd JimmyZ: your gist isn't correct
09:38 not_gerd you need to change the types of ->pool_index, ->ref_count etc to AO_t
09:41 JimmyZ apr_atomic_cas32 is using InterlockedCompareExchange API on windows
10:16 * jnthn agrees with diakopter - let's see if we can't use libatomic_ops everywhere we currently use APR for atomic ops. A frothy mix will only lead to confusion...
10:17 jnthn If we have to use 64-bit integers for the ref counts of frames, so be it.
10:17 diakopter I think he meant to import some of apr's code
10:17 diakopter (not to keep apr)
10:17 jnthn ah
10:17 jnthn Doesn't seem worth it, though?
10:17 jnthn 64-bit AO_t may well be faster on a 64-bit machine anyway...
10:19 diakopter yeah
10:19 * not_gerd agrees
10:21 JimmyZ jnthn: I couldn't see where repr clone alloc object ...
10:21 JimmyZ or maybe in the future?
10:21 jnthn JimmyZ: I think KnowHOWREPR, were it ever cloned (and maybe its clone just is NYI) would do so.
10:22 jnthn JimmyZ: But yeah, it's partly a future thing. It's just not a very surprising thing to do.
10:22 * diakopter thought that way too
10:22 diakopter I thought p6opaque might too
10:22 JimmyZ jnthn: KnowHOWREPR didn't
10:22 jnthn JimmyZ: Yes, but is its copy_to implemented? :)
10:23 JimmyZ yes
10:23 jnthn hm, I wonder what on earth it does... :)
10:23 JimmyZ it does MVM_ASSIGN_REF
10:23 jnthn um.
10:23 jnthn Yeah, that'll end up with the two sharing their method table etc. D'oh. :)
10:23 * diakopter doesn't want to guess whether I did that..
10:24 * jnthn wonders how widespread the issue is
10:24 jnthn Though I'm not sure that code-path is hit.
10:24 * diakopter wouldn't think so
10:24 not_gerd https://gist.github.com/gerdr/6256243 # totally untested wrapper for mmap/winapi
10:24 JimmyZ another thing I wonders the difference copy_to between VMString and P6str
10:25 not_gerd I'm assuming our use-case for mmap is mapping byte-code files and allocating executable pages for the JIT (someday)
10:25 diakopter well first just getting .moarvm files to memory
10:25 jnthn JimmyZ: They look correct.
10:26 not_gerd if the API sounds sane, I'll see if these actually compile ;)
10:26 JimmyZ I had found gerd is a fan of inline a years ago, though I'm too :P
10:26 JimmyZ I mean gerdr :P
10:26 jnthn JimmyZ: VMString is the actual low-level string. P6Str is just a boxing type that knows to flatten away if a P6opaque contains one.
10:27 JimmyZ jnthn: ok, thanks. how about merging gerdr++'s configure system?
10:28 not_gerd well, have we decided yet on which libraries to ship?
10:28 jnthn Which branch, or is that the one in the pull request?
10:29 not_gerd jnthn: see https://github.com/MoarVM/MoarV​M/pull/46#issuecomment-22618300
10:29 not_gerd we only need these 4 files
10:29 not_gerd either from pr/46 or pr/49
10:29 not_gerd the latter has everything besides libuv commented out
10:32 jnthn ok, will look
10:33 JimmyZ jnthn: libuv1 branch is for you :P. A new branch, without patching libuv
10:33 JimmyZ needs review
10:33 JimmyZ passed all test
10:35 jnthn not_gerd: On the mmap thing...we didn't tend to put so much code into header files so far, and this doesn't seem like something where we'd be doing a load of calls, so inline doesn't seem so helpful.
10:36 * jnthn wonders if it'd be a good idea to have a src/platform/ where we keep these platform-abstraction things.
10:36 JimmyZ jnthn: just copy it to compunit.c
10:36 JimmyZ jnthn: +1 to src/platform/
10:36 JimmyZ and for error process
10:37 jnthn JimmyZ: Well, I think it being in a separate file is a good thing, we'll probably want it in places becides memmap.h
10:38 JimmyZ we may just throw error cod in MoarVM, so perl6 and other languages shouldn't parse our error message
10:38 not_gerd jnthn: on posix systems, the functions wrap a single function call, so it seemed like a good idea
10:38 JimmyZ I know rakudo is parsing parrot's error message
10:38 not_gerd jnthn: if we make these linkable, they'll need to be put into the MVM_ namespace
10:38 not_gerd I don't really care either way
10:40 jnthn JimmyZ: Sometimes we need to convey more than just a code, however.
10:40 JimmyZ jnthn: aye
10:40 jnthn not_gerd: Aye, I just like to keep "where is X" relatively unsurprising. :)
10:41 JimmyZ jnthn: anyway, I'm +1 to src/platform/
10:41 JimmyZ And I want it :P
10:42 dalek MoarVM: 47eb65b | jimmy++ | src/core/interp.c:
10:42 dalek MoarVM: added back missing MVMROOT
10:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/47eb65b275
10:42 not_gerd is there an internal namespace?
10:43 * not_gerd too lazy to look
10:43 not_gerd these don't really belong in the public API
10:43 jnthn Not as of yet.
10:43 JimmyZ mvm_ :P
10:43 not_gerd MVM_platform_?
10:43 jnthn One thing nwc10++ pointed out is that we should be careful what we export and don't, though.
10:43 jnthn MVM_platform_ is fine
10:44 jnthn On Windows that's easy, as the default is "not exported" so we have to mark the things we want to expose specifically.
10:44 jnthn I think on Linux that needs some kind of linker script?
10:44 FROGGS btw, my nqp-cc seems to work again now, I had to rm nqp's /install, and the rebuilt everything
10:45 JimmyZ MVM_internal_
10:45 jnthn Well, I'd have mark things that are API with MVM_API or some such.
10:46 JimmyZ mark MVM_API means exported
10:46 jnthn Yeah.
10:47 jnthn So for now, nothing is exported. At least, not portably. But given we don't yet have a way to build a libmoar...unless some productive person sneaked it in while I wasn't watching. :)
10:47 not_gerd note that we also need to careful about non-api externals
10:47 not_gerd someone might want to link moarvm statically
10:48 not_gerd moarvm seems to consistenly use the mvm prefix, so we're good on that
10:48 jnthn Yes, anything non-static should use that.
10:48 jnthn bbi15 or so
10:48 JimmyZ Maybe we could see how PHP src code does export, since there are many php exts.
10:51 JimmyZ # define MVM_API __attribute__ ((visibility("default")))
10:52 JimmyZ and __attribute__ ((visibility ( internal )))
10:52 JimmyZ jnthn: http://gcc.gnu.org/wiki/Visibility
10:58 JimmyZ not_gerd: I'd like to add your code to src/core/memmap.h
10:58 grondilu JimmyZ: I hope you'll put this link in the source code for reference.
10:59 not_gerd JimmyZ: I'm thinking we should create src/platform and put it there
10:59 not_gerd I can do it after jnthn gets back so we can sicuss factoring
10:59 JimmyZ not_gerd: great
11:01 not_gerd s/sicuss/discuss/
11:02 dalek MoarVM: 0e62fbd | (Tobias Leich)++ | nqp-cc/t/serialization/0 (2 files):
11:02 dalek MoarVM: nqpmo is still called nqp-mo
11:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0e62fbd104
11:03 jnthn JimmyZ: src/platform/memmap.[ch]
11:03 FROGGS diakopter: here is the proper output of the tests your newly added ops: https://gist.github.com/FR​OGGS/111a825365e629f4331c
11:04 JimmyZ not_gerd: ^^ :)
11:04 not_gerd jnthn: should we split that into src/platform/posix/mmap.c and src/platform/win32/mmap.c
11:04 JimmyZ jnthn: not src/platform/win32/memap.[ch] or something?
11:04 not_gerd and compile the right one via Configure.pl
11:04 not_gerd or just one file with #ifdef?
11:04 JimmyZ aye
11:05 JimmyZ I'd like  to separate
11:06 JimmyZ there will may be aix/ solaris/
11:06 jnthn Seaparating it out like that will need more build system work and effort, but will scale better in the end.
11:07 JimmyZ I'm +1 to will scale better in the end
11:07 jnthn So if there's energy/motivation to do it, it's probably the way to go :)
11:07 not_gerd jnthn: my Configure.pl should support that relatively hassle-free
11:07 jnthn not_gerd: OK. :)
11:08 * not_gerd goes food-hunting
11:08 dalek MoarVM: 55b9e0f | jimmy++ | build/config.h.in:
11:08 dalek MoarVM: added reference link for MVM_API exporting
11:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/55b9e0f025
11:08 JimmyZ grondilu: ^^
11:08 not_gerd if no one beats me to it, I'll do the mmap stuff after I get back
11:11 JimmyZ I'd suggest to add not_gerd to MoarVM :P
11:12 JimmyZ if not_gerd does not object...
11:22 jnthn The Configure refactor sure puts a heck of a lot into Configure.pl itself...
11:22 * jnthn woulda preferred a slightly more modular factoring
11:23 jnthn It does seem a bunch more flexible, however.
11:31 not_gerd jnthn: the question is, what's worse - a monolithic file or hacing to hunt through files all over the place if something doesn't work
11:31 not_gerd * having
11:33 not_gerd if the configuration logic gets more complex (automatic feature detection), that might be worth putting into a separate file
11:35 colomon joined #moarvm
11:40 jnthn not_gerd: Hm, fair point. Maybe pulling the bunch of hashes at the start of the file, which are essentially data, out of Configure.pl into a module that exports them would help make it feel less of an epic. :)
11:42 not_gerd that's certainly an option
11:42 not_gerd the same goes for automatic feature detection
11:42 not_gerd right now, we only detect if we're on x64 in case of windows, though
11:43 jnthn I think I'd prefer it that way
11:44 jnthn (the data split out)
11:44 JimmyZ We need detect whether support %lld or not ..
11:44 JimmyZ in the future
11:46 jnthn not_gerd: Would you like a commit bit, btw? I'd like large refactors/changes like this one be done in branches still, but it'd perhaps make your life easier... :)
11:47 not_gerd jnthn: sure
11:47 not_gerd I don't really need it, but it might make testing easier for you guys
11:47 jnthn not_gerd: aye, my thought too. It's not hard to pull from your fork, but laziness is nice... :)
11:48 jnthn ok, done :)
11:49 jnthn Of course, for obviously right things, just go ahead and commit in master. :)
11:49 jnthn shopping &
11:50 not_gerd I'll try not to make amess ;)
11:50 jnthn Well, in the worst case, git provides ways to cope with that :)
11:55 * FROGGS .oO( git stalk not_gerd )
12:03 birdwindupbird joined #moarvm
12:22 not_gerd any one knows how to get the file descriptor/handle out of apr_file_t?
12:26 * JimmyZ can't follow you
12:27 not_gerd JimmyZ: my mmap wrappers need a filr descriptor, which is hidden in an apr_file_t structure
12:28 not_gerd I'll have to pull  in some APR internal headers to get at it
12:28 not_gerd the switch to libuv will fix that
12:42 not_gerd *headdesk*
12:42 not_gerd what is wrong with the following line:
12:42 not_gerd writable ? FILE_MAP_READ | FILE_MAP_WRITE : FILE_MAP_WRITE
12:42 cognominal joined #moarvm
12:46 JimmyZ where is the code?
12:46 JimmyZ I don't know ..
12:46 not_gerd JimmyZ: the last FILE_MAP_WRITE should read FILE_MAP_READ
12:47 not_gerd if not writable, make it writable is not sound logic
12:50 cognominal joined #moarvm
12:51 JimmyZ we don't need writeable
12:52 diakopter not_gerd: I thought you needed parens there
12:56 not_gerd diakopter: the ?: act as parens
12:56 dalek MoarVM/mmap: 4af81af | (Gerhard R)++ | / (5 files):
12:56 dalek MoarVM/mmap: import new build system
12:56 dalek MoarVM/mmap: review: https://github.com/MoarVM/MoarVM/commit/4af81af7a9
12:56 dalek MoarVM/mmap: 7a66dea | (Gerhard R)++ | build/Makefile.in:
12:56 dalek MoarVM/mmap: add missing objects ot Makefile.in
12:56 dalek MoarVM/mmap: review: https://github.com/MoarVM/MoarVM/commit/7a66dea46e
12:56 dalek MoarVM/mmap: fdc7214 | (Gerhard R)++ | Configure.pl:
12:56 dalek MoarVM/mmap: disable libuv build
12:56 dalek MoarVM/mmap: review: https://github.com/MoarVM/MoarVM/commit/fdc721415d
12:56 dalek MoarVM/mmap: 1e64add | (Gerhard R)++ | src/platform/ (3 files):
12:56 dalek MoarVM/mmap: add platform-specific mmap wrappers
12:56 dalek MoarVM/mmap: review: https://github.com/MoarVM/MoarVM/commit/1e64add2b6
12:56 dalek MoarVM/mmap: efce9cb | (Gerhard R)++ | / (2 files):
12:56 dalek MoarVM/mmap: build platform-specific files
12:57 not_gerd \o/
12:58 not_gerd needs testing on non-windows
13:00 jnthn not_gerd: Does it remove the linenoise bits too? That's not in master yet, yes?
13:00 crab2313 joined #moarvm
13:01 not_gerd jnthn: that's master + mmap - no additional 3rdparty libs
13:02 jnthn OK, I see a reference to linenoise in there, is all.
13:03 not_gerd jnthn: the important bit should be behing a comment
13:03 jnthn ok
13:04 not_gerd https://github.com/MoarVM/Moar​VM/blob/mmap/Configure.pl#L81
13:04 not_gerd that's where we decide what to build
13:04 jnthn not_gerd: Hm, it auto-detects the x64 toolchain, and then /DAO_ASSUME_WINDOWS98 is in the compile line.
13:05 jnthn I *thought* (may be totally misremembering) that one was just needed on 32-bit...
13:05 crab2313 not_gerd: -osrc/main.o
13:05 not_gerd jnthn: it's needed on 32-bit, but I don't think it hurts on x64
13:05 jnthn ok
13:05 not_gerd I wouldn't know how to detect if it does, though ;)
13:07 * jnthn builds mmap branch
13:07 not_gerd crab2313: the old system didn't build that?
13:07 not_gerd well, it only becomes relevant once we start generatinc libmoarvm
13:07 crab2313 not_gerd: I'm on mmap
13:08 not_gerd crab2313: what's the problem with -osrc/main.o
13:08 crab2313 not_gerd: not just that
13:09 crab2313 not_gerd: https://gist.github.com/crab2313/6256778
13:10 not_gerd crab2313: gist the generated Makefile?
13:12 diakopter I've gotten that before
13:13 crab2313 not_gerd: https://gist.github.com/crab2313/6256785
13:16 not_gerd crab2313: does `make -j1` help?
13:16 not_gerd I'm not yet seeing anything wrong with the makefile...
13:19 crab2313 not_gerd: I should try it again
13:22 JimmyZ not_gerd: https://gist.github.com/zhuomingliang/6248474
13:22 JimmyZ I'm on centos x64
13:24 crab2313 not_gerd: I think it forget to build apr
13:24 not_gerd JimmyZ: the header inclusion order is wrong
13:24 not_gerd alternatively, mmap.h needs to pull in stddef.h
13:25 not_gerd jnthn: should I add an inclusion guard + dependency headers in mmap.h or reorder header inclusion order in mmap.c?
13:25 not_gerd other internal moarvm headers don't use inclusion guards...
13:26 jnthn not_gerd: I prefer to avoid those.
13:27 crab2313 not_gerd: build apr manually
13:27 dalek MoarVM/mmap: 291c8c0 | (Gerhard R)++ | src/platform/ (2 files):
13:27 dalek MoarVM/mmap: reorder header inclusion order
13:27 dalek MoarVM/mmap: review: https://github.com/MoarVM/MoarVM/commit/291c8c08fb
13:27 crab2313 not_gerd: and got the same issue
13:27 not_gerd oO
13:28 not_gerd does the file 3rdparty/apr/include/apr.h exist?
13:29 crab2313 not_gerd: there is a apr.h.in, and it didn't build apr automatically
13:29 not_gerd crab2313: I thought you built apr manually?
13:30 not_gerd if so, *that* should have generated the header
13:30 crab2313 not_gerd: yes, I built it manually,
13:31 not_gerd crab2313: remove 3rdparty/apr/.libs/libapr-1.a and try a simple `make` again
13:31 JimmyZ not_gerd: https://gist.github.com/zhuomingliang/6248474 upated
13:31 not_gerd if that doesn't work, no idea what will
13:32 JimmyZ crab2313: which OS?
13:32 crab2313 not_gerd: I have solved the problem, and got the same issue as JimmyZ
13:32 dalek MoarVM/mmap: f4f5611 | (Gerhard R)++ | src/platform/posix/mmap.c:
13:32 dalek MoarVM/mmap: pull in stddef.h in platform/posix/mmap.c
13:32 dalek MoarVM/mmap: review: https://github.com/MoarVM/MoarVM/commit/f4f5611bc3
13:33 not_gerd crab2313, JimmyZ: ^^
13:33 JimmyZ builds
13:33 crab2313 not_gerd: just think it should build apr automatically
13:33 not_gerd crab2313: it should
13:34 jnthn It did here for me, fwiw
13:34 crab2313 JimmyZ: gentoo x86
13:35 not_gerd $(OBJECTS) depend on $(HEADERS), 3rdparty/apr/include/apr.h is part of $(HEADERS) and depends on 3rdparty/apr/.libs/libapr-1.a
13:35 not_gerd that *should* trigger the build
13:35 not_gerd (except if you cleaned your apr dir but kept libapr-1.a around)
13:36 JimmyZ X86 is LibR, not .lib on windows
13:36 crab2313 not_gerd++
13:37 not_gerd JimmyZ: as far as I know, on linux it's always .lib
13:38 not_gerd or .libs, rather
13:38 crab2313 it works on my box
13:40 * grondilu on debian x86 notices apr libs in ./MoarVM/3rdparty/apr/.libs
13:41 JimmyZ good, not_gerd++, works on windows x86
13:45 donaldh joined #moarvm
13:46 JimmyZ not_gerd: make test passed on CentOS X64
13:51 JimmyZ not_gerd: make test passed on Window X86 with msvc
13:52 jnthn Want me to retest on x64 windows?
13:53 not_gerd jnthn: shouldn't be necessary
13:54 jnthn just kicked one off anyway :)
13:55 JimmyZ so left part is atomic, diropen/dirread and socket for switching to libuv
13:57 TimToady as usual, I just get a coredump from threads.t now
13:57 jnthn Is that, getting rid of the use of atomic stuff from APR?
13:57 JimmyZ jnthn: yes
13:57 TimToady (on linux/64)
13:57 JimmyZ I tried, but failed
13:57 jnthn JimmyZ: OK, I can take that one on.
13:58 JimmyZ jnthn: and I have problem to get uv_read bufs ...
13:58 JimmyZ uv_read calls cb, and I don't know how to get its read
13:59 jnthn not_gerd: Things looked good
13:59 JimmyZ \o/, merge !!
14:00 not_gerd ;)
14:00 not_gerd I can pull out the config data from Configure.pl before that
14:00 jnthn Yes, please.
14:00 not_gerd hardest part is the naming
14:00 jnthn That's nothing new... :)
14:01 not_gerd what should the .pm be called?
14:01 jnthn gah! :P
14:01 jnthn BuildData perhaps?
14:01 JimmyZ ConfigMap.pm
14:01 jnthn map? :)
14:02 JimmyZ ConfigHash.pm
14:02 JimmyZ :P
14:02 JimmyZ or ConfigData.pm ?
14:02 jnthn ConfigData is also OK, but the data is mostly about how to build :)
14:03 JimmyZ the data is about configs :P
14:03 not_gerd the old name was Config::BuildEnvironment
14:04 JimmyZ +1 to Config::BuildEnvironment :P
14:04 jnthn That works, it just doesn't capture the fact it's most just a load of data...
14:09 not_gerd oO( Configure::Data )
14:18 JimmyZ oO
14:42 dalek MoarVM/configure: 23927ed | (Gerhard R)++ | build/Config/ (4 files):
14:42 dalek MoarVM/configure: get rid of old build system
14:42 dalek MoarVM/configure: review: https://github.com/MoarVM/MoarVM/commit/23927ed06a
14:42 dalek MoarVM/configure: 6d441fd | (Gerhard R)++ | / (2 files):
14:42 dalek MoarVM/configure: pull out build config data into build/setup.pm
14:42 dalek MoarVM/configure: review: https://github.com/MoarVM/MoarVM/commit/6d441fd73f
14:42 not_gerd if it were my pet project, I'D totally do it like that
14:42 not_gerd please tell me if it's too ugly for production and I should hide it away somewhere ;)
14:43 jnthn This branch is based off mmap one?
14:43 not_gerd jnthn: yes
14:44 jnthn k
14:44 jnthn exporting the symbols might'a saved some ::'s :
14:44 jnthn :P
14:46 JimmyZ tomorrow I will do opendir/readdir part :P
14:46 jnthn k
14:46 JimmyZ the left socket \o/
14:54 not_gerd jnthn: configure branch needs a fix
14:55 jnthn JimmyZ: Are you just implementing synchronous stuff with libuv at the moment, or some async stuff also?
14:55 JimmyZ jnthn: nope
14:55 jnthn Which is the nope to? :)
14:55 JimmyZ jnthn: I needs read tty
14:55 JimmyZ tty use uv_read
14:55 benabik joined #moarvm
14:56 JimmyZ jnthn: I know nothing about sync or async
14:57 dalek MoarVM/configure: ef6b17f | (Gerhard R)++ | Configure.pl:
14:57 dalek MoarVM/configure: fix backslash substitution
14:57 dalek MoarVM/configure: review: https://github.com/MoarVM/MoarVM/commit/ef6b17f37b
14:58 JimmyZ jnthn: getstd may be tty or pipe or file, both tty and pipe use uv_read, but file uses uv_fs_read
14:59 JimmyZ uv_read_stat
14:59 jnthn Oh?
14:59 JimmyZ uv_read_start
14:59 jnthn So you can't get a standard handle and always read from it in the same way?
15:01 JimmyZ jnthn: yeah, see MVM_file_get_stdstream/MVM_fil​e_read_fhs/MVM_file_write_fhs in https://github.com/MoarVM/MoarV​M/blob/libuv1/src/io/fileops.c
15:02 JimmyZ jnthn: libuv mostly uses uv_handle_t, execpt uv_fs_ part
15:02 JimmyZ *except
15:04 JimmyZ jnthn: according to uv.h , uv_stream_t is the parent class of uv_tcp_t, uv_pipe_t, uv_tty_t, and* soon uv_file_t
15:05 JimmyZ jnthn: so uv_fs_ will be using uv_handle_t in the future...
15:07 jnthn hm, ok
15:42 JimmyZ good night
15:43 not_gerd good night
15:44 jnthn 'night, JimmyZ
16:11 dalek MoarVM/libuv5: 2317be7 | diakopter++ | src/mast/compiler.c:
16:11 dalek MoarVM/libuv5: less debugging
16:11 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/2317be7cac
16:11 dalek MoarVM/libuv5: eac6e83 | jimmy++ | src/io/fileops.c:
16:11 dalek MoarVM/libuv5: added a few comments to MVM_file_readline_fh
16:11 JimmyZ jnthn: btw, libuv5 branch is better working branch than libuv1
16:12 dalek joined #moarvm
16:12 JimmyZ master merged into libuv5
16:19 diakopter howdy
16:27 not_gerd bye, #moarvm
16:27 not_gerd left #moarvm
17:38 benabik joined #moarvm
17:40 benabik There are quite a few libuv\d? branches.
17:42 jnthn benabik: Tell me about it!
17:42 jnthn o/ diakopter
17:43 benabik Also, minor gripe:  Please write commit messages as if the person reading them has no idea what you're doing.  "Fixes" or "added opcodes" are not useful to someone browsing commits.  What did you fix?  What opcodes did you add?
17:43 jnthn +1
17:44 benabik This is one thing I love about git.git's mailing list approach.  Your commit messages has to convince jch that it's worthwhile.  So many git.git commit messages are longer than the patch itself.
17:44 benabik </gripeing>
18:10 donaldh joined #moarvm
19:03 dalek MoarVM: bfdfebd | jnthn++ | src/core/frame. (2 files):
19:03 dalek MoarVM: Switch frame ref-count to libatomic_ops.
19:03 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bfdfebd993
19:13 diakopter who's jch
19:13 jnthn #define MVM_cas(addr, old, new)
19:13 jnthn has the comment
19:13 jnthn /* returns non-zero for success. Use for both AO_t numbers and pointers. */
19:13 jnthn really?
19:13 jnthn CAS usually returns what was seen...
19:13 diakopter yeah
19:15 jnthn grr
19:15 jnthn I'd rather we'd called that MVM_trycas
19:15 jnthn And used MVM_cas for the normal definition of CAS
19:15 diakopter so change it :P
19:15 jnthn yeah, doing so
19:16 diakopter jnthn: I don't know how you'll do it though
19:16 diakopter without making it read it again on failure
19:17 jnthn AO_t fetch_compare_and_swap(volatile AO_t * addr, AO_t old_val, AO_t new_val)
19:17 jnthn It's defined by libatomic_ops
19:18 jnthn I *think* that is actually the primitive one, and that the int-returning one is implemented in terms of it, at least on Windows...
19:18 diakopter oh; that must be new
19:20 diakopter did someone update lao from the repo?
19:20 jnthn oh, I was looking at the docs in the lao repo...hm
19:20 diakopter no I think fetch means add a fetch fence
19:20 diakopter er, that's read
19:20 diakopter I don't remember
19:21 jnthn Nope, "returns the original value of *addr"
19:21 jnthn but...hmm...seems our repo copy is behind..
19:21 diakopter yeah by a year
19:21 jnthn odd
19:21 jnthn ok
19:21 jnthn Think I'd rather update it than hack something myself
19:21 diakopter :)
19:21 diakopter now... it's significantly modified
19:22 diakopter had to strip out all the GPL stuff
19:22 * diakopter watches jnthn's yak shave grow to a lawn mowing
19:24 diakopter jnthn: perhaps I should do the lao refresh since I mangled it previously
19:24 diakopter and surprisingly I somewhat remember it
19:24 jnthn OK
19:25 diakopter and you have better things to do :)
19:25 diakopter more jnthn-y things
19:26 jnthn ok, will push the MVM_cas => MVM_trycas rename since I did that.
19:27 jnthn Getting an MVM_cas that does the return-seen thing will make it easier to deal with the leftover apr_atomic_*
19:27 diakopter well, this "extra random character" at the end of the QASTCompilerMAST.moarvm feels like a parrot bug
19:27 diakopter *filename, I mean
19:28 jnthn oh, is that why I've a funny named file?
19:28 jnthn eek, now I've more of them
19:28 diakopter yeah I get it too; I can't find a problem with the Makefile
19:29 jnthn hmm :)
19:29 diakopter makes me think it's a parrot thing
19:29 diakopter or nqp, I guess
19:30 dalek MoarVM: 72a9fd4 | jnthn++ | src/core/ (2 files):
19:30 dalek MoarVM: Switch frame_pool_num to libatomic_ops.
19:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/72a9fd4467
19:30 dalek MoarVM: 06ae890 | jnthn++ | src/ (4 files):
19:30 dalek MoarVM: Rename MVM_cas => MVM_trycas.
19:30 dalek MoarVM:
19:30 dalek MoarVM: The traditional cas definition is to return what was seen. We'll make
19:30 dalek MoarVM: MVM_cas mean that in the future, so rename the bool-returning one to
19:30 dalek MoarVM: MVM_trycas.
19:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/06ae890347
19:32 jnthn diakopter: uh, it may be me to blame :)
19:36 dalek MoarVM: 7ce6050 | jnthn++ | nqp-cc/src/ops/mvmcc.ops:
19:36 dalek MoarVM: Make sure we get null-terminated filename.
19:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7ce6050a9a
19:36 jnthn diakopter: ^^ fixes it
19:36 jnthn afaict
19:37 diakopter oh
19:42 jnthn diakopter: gc_free in MVMCompUnit seems to have some unrelated leftover code?
19:43 diakopter if so, oops
19:44 diakopter oh, not completed
19:44 jnthn In copy_to of MVMStaticFrame, I think the static_env should be copied from old to new
19:45 jnthn With a loop and MVM_ASSIGN_REF for the appropriate things
19:45 jnthn Is it better if I issues these?
19:45 diakopter oh, it's not?
19:46 jnthn oh, hang on...lemme check latest source in case if differs from the patch
19:46 diakopter oh oops
19:46 diakopter no
19:46 diakopter you're right
19:46 diakopter wait
19:46 diakopter those aren't objects
19:46 jnthn no, it doesn't
19:46 jnthn /* XXX start out with blank static env? */
19:46 jnthn dest_body->static_env = calloc(1, src_body->env_size);
19:47 diakopter oh, that
19:47 jnthn Right, it's a bunch of registers; it goes by lexical_types as to what's in there
20:00 * jnthn is happy to see MVM_gc_worklist_add_frame
20:04 colomon joined #moarvm
20:20 dalek joined #moarvm
21:19 benabik diakopter: Junio C Hamano, git maintainer
21:44 colomon joined #moarvm
22:26 diakopter jnthn: any other things need fixing?
22:27 jnthn diakopter: Not that I could see right off.
22:27 diakopter yay, I think :)
22:31 jnthn What blocks on me in terms of NQP on Moar, ooc? Or, what is it most helpful for me to do?
22:31 * jnthn should look more closely at what's going on with libuv also :)
22:32 jnthn Otherwise, I can just take pot shots at whatever I find stopping NQP on Moar... :)
22:32 diakopter nqp-cc\> make NQPP6QRegex.nqp
22:32 diakopter nqp-cc\> make NQPP6QRegex.moarvm
22:32 diakopter nqp-cc\> nmake NQPP6QRegex.moarvm
22:33 diakopter er, also https://gist.github.com/FR​OGGS/111a825365e629f4331c
22:33 jnthn gotcha
22:33 diakopter ^ my completely naive attempts at those opcodes
22:33 jnthn oh...serialization ain't even implemetned yet
22:34 diakopter well, those prereq opcodes
22:34 jnthn So I'd have been surprised if the tests got anywhere :)
22:34 jnthn ok
22:34 diakopter the 4 added in that bit commit
22:34 diakopter big
22:34 jnthn yeah, noticed those...
22:34 * diakopter wonders where lizmat
22:34 jnthn OK, will see how my tuits/brane are tomorrow
22:34 diakopter 'nite
22:36 jnthn about for 10 mins more...
22:36 diakopter frankfurt flight is $1337 each for me and Melanie
22:37 diakopter ...
22:37 jnthn 1337!
22:58 cognominal joined #moarvm
23:17 colomon joined #moarvm
23:27 BenGoldberg joined #moarvm
23:31 BenGoldberg .ping
23:31 yoleaux There is no ping command; nor can this be construed as a response.
23:37 diakopter .
23:37 diakopter .yoleaux
23:37 diakopter .yolo
23:37 diakopter .ping response
23:37 yoleaux There is no ping command; nor can this be construed as a response.
23:40 BenGoldberg So I've got this silly question about NQP...
23:43 BenGoldberg The perl5 language is defined by the implementation, any "specification" of it merely describes one particular impl.  The perl6 language is defined by the perl6 specification -- implementations do their best to follow the spec.  NQP, which the rakudo implementation of perl6 is written in, doesn't currently seem to have a specification.  Is NQP simply defined by how rakudo uses it, or will there
23:43 BenGoldberg be a formal spec?
23:45 Ben_Goldberg joined #moarvm
23:46 diakopter Ben_Goldberg: more important than the syntax of NQP (which is very close to a subset of Perl 6) is the nqp:: opcode set
23:49 Ben_Goldberg Is there (will there be) a document somewhere which states precisely which nqp:: opcodes must be defined, in order for rakudo to compile and run?
23:52 diakopter no; for MoarVM we just looked at the implementations for Parrot and the JVM
23:52 colomon joined #moarvm
23:52 Ben_Goldberg Ok
23:52 diakopter (you'd have to do a lot of that anyway, so a document wouldn't help much)
23:54 Ben_Goldberg So someone writing an implementation for LLVM or Adobe Flash would also look other implementations to see how to go.
23:54 diakopter yes, definitely
23:57 Ben_Goldberg Approximately how many nqp:: ops are there?
23:58 diakopter 4-500?
23:58 diakopter some dramatically huger than others
23:59 Ben_Goldberg Wow!  That's a lot! :)
23:59 Ben_Goldberg And approximately how many does MoreVM have implemented?

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