github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 3 August 2013.
00:12 cognominal joined 00:22 FROGGS joined 00:23 BenGoldberg joined 00:42 donaldh joined 01:49 FROGGS joined
dalek arVM: 09ecf26 | diakopter++ | / (47 files):
add a few more ops; make compunit and staticframe reprs
 02:23
arVM: f45dafe | diakopter++ | / (66 files):
Merge branch 'master' of github.com:MoarVM/MoarVM
arVM: 1d531d3 | diakopter++ | src/ (5 files):
finish merging
arVM: df6c1e4 | diakopter++ | src/ (3 files):
small fixes
MoarVM: 3e92deb | diakopter++ | src/core/exceptions.c:
MoarVM: more precise labels
diakopter bah
FROGGS: ping 02:24
well, technically I broke the cc build 02:25
I guess I'll just have to fix it! 02:29
02:55 colomon joined
diakopter colomon: hi 02:58
colomon \\o
diakopter colomon: :D 02:59
dalek arVM/libuv1: 47d6cd8 | jimmy++ | src/io/ (2 files):
fixed bugs, passed 77-file-io.t
 03:03
arVM: d8c1a84 | diakopter++ | / (2 files):
bit more debugging
 03:21
TimToady hmm, src/core/interp.c:2898:25: error: lvalue required as unary ā€˜&ā€™ operand 04:10
diakopter TimToady: ? 04:23
TimToady what happens when I try to do make in the top dir 04:24
diakopter after pulling just now?
diakopter goes to linux vm
TimToady yes, up-to-date
diakopter erm, maybe it'd help if I had a linux vm
TimToady: hunh. 04:27
04:29 grondilu joined
dalek arVM: f2af649 | diakopter++ | src/core/interp.c:
TimToady++ bug
 04:29
diakopter TimToady: ^
TimToady src/6model/reprs.o: In function `MVM_repr_initialize_registry': 04:31
/home/larry/MoarVM/src/6model/reprs.c:252: undefined reference to `MVMStaticFrame_initialize'
/home/larry/MoarVM/src/6model/reprs.c:253: undefined reference to `MVMCompUnit_initialize'
diakopter wha
oops
erm 04:32
try make clean 04:33
TimToady did
diakopter weeuhd
are you using clang 04:34
TimToady no, gcc
diakopter hm, me too
.. but those functions are right there in the .h included from reprs.h 04:37
TimToady hmm, there's no MVMStaticFrame.o 04:38
diakopter oh you have to reconfigure
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
grondilu thinks the function should rather be in frame.o, not in MVMStaticFrame.o 04:40
TimToady that appears to have fixed it
diakopter the enormous refactoring at github.com/MoarVM/MoarVM/commit/09...7a14598fd7 and following remove the memory leak of "eval" by making essentially everything garbage collected 04:41
04:42 benabik joined
dalek arVM/libuv1: fd2cb03 | jimmy++ | src/ (12 files):
port all apr threads api to libuv api
 04:43
diakopter JimmyZ: you've been doing amazing work lately; you deserve a gold star 04:44
JimmyZ :P 04:45
diakopter uv_mutex_t is a pointer?
JimmyZ no 04:46
diakopter ok
JimmyZ so it doesn't needs malloc 04:47
diakopter ok
JimmyZ anyway, apr mem_pool is a bit annoying :)
diakopter yes 04:48
JimmyZ: can you see if master merges to libuv1?
I changed ... a lot
I wish github would tell me if master would merge cleanly to a branch
grondilu got a segmentation fault: 04:49
nqp nqp-moar-cc.nqp --target=mbc --setting=NQPCOREMoar --no-regex-lib --output=QASTCompilerMAST.moarvm src/QASTCompilerMAST.nqp
make: *** [QASTCompilerMAST.moarvm] Segmentation fault
diakopter o_O
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...
grondilu: well, at least it's repeatable
grondilu: which OS/compiler
grondilu gcc (Debian 4.8.1-8) 4.8.1 04:52
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
oops, sorry for the long output, I ran /exec -out gcc --version
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
diakopter oh yeah, 32-bit. 04:54
2nd-class citizen
grondilu :(
TimToady make test works here in nqp-cc
diakopter kidding.. I get the same on 64-bit
TimToady: !!!!!!!!!!!
TimToady except for the thread.t
*threads.t
diakopter TimToady: it compiled NQPP6QRegex.moarvm ?? 04:55
grondilu: oh, yes, mine segfaults there too
TimToady: oh, did you reconfigure nqp-cc ?
TimToady trying 04:56
diakopter grondilu: yes, I haven't figured out why that does that yet..
but it shouldn't segfault
I'll fix that first
dalek arVM/libuv5: 61c8396 | jimmy++ | / (53 files):
Merge branch 'master' into libuv5

Conflicts:
  \tsrc/core/interp.c
  \tsrc/core/oplist
  \tsrc/core/ops.c
  \tsrc/core/ops.h
  \tsrc/io/fileops.c		 04:57
JimmyZ diakopter: ^^
diakopter libuv5? :)
JimmyZ based libuv1 branch, with a merge 04:58
libuv1 is for jnthn++ :P
diakopter right 04:59
TimToady kablooey
JimmyZ diakopter: I fixed these Confilicts
diakopter oh ok
TimToady: hint, it's in parrot ;)
TimToady sugoi
maybe you should use JVM instead :P 05:00
diakopter "
Japanese equivalent of either "awesome" or "awful". Most frequently used to mean the former, at least among westerners."
TimToady terrific comes close if you allow the ironic meaning 05:01
diakopter I get all my knowledge from urbandictionary
TimToady well, it's not even ironic in "a terrific explosion" 05:02
dalek arVM: 2317be7 | diakopter++ | src/mast/compiler.c:
less debugging
 05:03
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
er, wakes
TimToady doesn't see anything wrong with "awakens"
"wakes" seems a bit archaic 05:05
grondilu it sounds weird unless jnthn is a Godzilla
diakopter you're thinking of akraken
grondilu (or a zombie)
diakopter that last commit makes it die betterly 05:06
I don't really know how to diagnose it 05:08
TimToady chop out lines until the problem disappears? 05:10
diakopter *whimper*
grondilu os_version=`uname -r | sed -e 's/\\(.\\)\\.\\(.\\)[\\.-]\\(.\\).*/\\1\\2\\3/' 05:11
^this still does not parse my kernel
3.10-0.towo-siduction-686
05:12 FROGGS joined
dalek arVM/libuv1: eac6e83 | jimmy++ | src/io/fileops.c:
added a few comments to MVM_file_readline_fh
 05:12
arVM/libuv1: 0e63714 | jimmy++ | src/io/procops.c:
port MVM_proc_time_i/MVM_proc_time_n function to libuv api
 05:18
05:25 FROGGS joined
dalek arVM: 0d7c224 | diakopter++ | nqp-cc/tools/build/Makefile.in:
don't build the latest broken thing yet
 05:37
arVM/libuv1: 21a974f | jimmy++ | src/core/interp.c:
re-implemented sleep op
 05:39
JimmyZ left parts: socket, opendir/readdir, mmap 05:42
diakopter JimmyZ++ 05:44
JimmyZ: also a couple cas32 things 05:45
JimmyZ that one just s///
diakopter well the fields it uses need to be 64-bit for the MVM_cas to use it 05:46
(on 64-bit machine anyway)
JimmyZ yeah
and I know nothing about it :P 05:47
diakopter: If you could help, we can merge it much faster :P 05:49
diakopter JimmyZ: just change whatever field you're CAS'ing to a AO_t 05:53
it'll always be wide enough
05:53 FROGGS joined
JimmyZ diakopter: I meant socket and mmap part :P 05:54
diakopter oh 05:55
JimmyZ socket is about 250 lines code 05:56
FROGGS diakopter: pong 06:16
diakopter FROGGS: just letting you know I put in those new ops finally 06:22
who knows whether they work..
FROGGS: could you import the things that test them, if any?
FROGGS diakopter: what are 'those ops'? 06:23
freshcoderef etc? 06:24
diakopter yes
FROGGS I can look for tests, yes
06:25 not_gerd joined
not_gerd o/ 06:25
diakopter not_gerd: howdy
FROGGS hi
not_gerd for the mmap stuff, we need someone who knows the winapi 06:26
msdn.microsoft.com/en-us/library/aa...85%29.aspx
^makes it sound as if you need to keep the file handle around
code.google.com/p/mman-win32/
^immediately closes it
would be nice if the latter could be relied upon
diakopter can't use gpl 06:27
JimmyZ not_gerd: I think we can take a look at mmap api in apr
not_gerd JimmyZ: they keep the file handle around 06:28
diakopter: I don't plan about using mmap-win32
JimmyZ diakopter: repr clones need MVMROOT? I couldn't see clone which may alloc object
not_gerd I just want to know if what they do is right
it simplifies the implementation 06:29
diakopter JimmyZ: which one has MVMROOT
JimmyZ diakopter: freshcoderef 06:30
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...?
JimmyZ diakopter: I can't see the it, though jnthn++ said clone may alloc object 06:32
not_gerd JimmyZ: yes
assuming mmap-win32 is used in practice, it should 06:33
however, this use is not documented 06:34
JimmyZ not_gerd: I thought you said must keep the filehanle to avoid leaks
not_gerd JimmyZ: not closing the filehandle will produce a leak
JimmyZ not_gerd: msdn sometimes is wrong
not_gerd mmap-win32 closes it directly after creating the mapping
so we don't leak an open handle 06:35
just use mappings for a handle that's already been closed
JimmyZ yeah, I want to close it :P
FROGGS diakopter: you forgot to add getstaticcode to QASTOperationsMAST.nqp 06:36
diakopter oops 06:37
FROGGS diakopter: you are going to add it, or should I? 06:38
dalek arVM: 0d93e27 | diakopter++ | nqp-cc/src/QASTOperationsMAST.nqp:
FROGGS++ missing op mapping
 06:42
diakopter <- wins
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.
so it's not a issue for loading bytecode 06:43
not_gerd JimmyZ: closing the filehandle without closing the fileviews leaks these views
the uestion is, are these 'leaked' views fully functional?
that's how mmap-win32 uses them 06:44
JimmyZ not sure :(
diakopter we don't care about leaking stuff loaded from disk, I'd think
only eval'd stuff
not_gerd there are 3 options: 06:46
1. keep track of the filehandle like apr
dalek arVM: 59b84b8 | (Tobias Leich)++ | nqp-cc/t/serialization/0 (3 files):
added serialization tests, which segfault
not_gerd 2. close the filehandle like mmap-win32 and use the file views anyway
3. leak the filehandle
FROGGS brb # breakfast 06:47
JimmyZ not_gerd: mman-win32 doesn't close os_handle? 06:49
not_gerd needs to re-read the code 06:53
code.google.com/p/mman-win32/source...mman.c#118 06:58
JimmyZ so, according msdn, I'd like to keep the filemapping handle :)
not_gerd I called it filehandle, but actually it's the handle of the file *mapping*
so s/filehandle/file mapping handle/ in my 1.2.3.
JimmyZ not_gerd: it doesn't close "h" 06:59
not_gerd JimmyZ: correct
that's the caller's responsibility
closing h would close fildes
it closes fm and still uses map 07:00
JimmyZ not_gerd: it doesn't return h :) 07:02
not_gerd: I'd like to +1 to 1. both apr and msdn do 07:03
not_gerd sure, but h is equivalent to fildes 07:04
the caller provides fildes, so it doesn't need h
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
MVM_cu_map_from_file() only puts mmap_handle->mm intu cu 07:06
mmap_handle->mv is lost 07:07
JimmyZ not_gerd: how about add libatomic_ops to configure? 07:08
not_gerd JimmyZ: it's already there
JimmyZ: it's header-only on windows
on other architectures, it shells out to its own configure
JimmyZ oh 07:19
FROGGS diakopter: gist.github.com/FROGGS/111a825365e629f4331c 07:21
ohh, all nqptest fail that way :o( 07:23
JimmyZ we have serialize? 07:24
FROGGS JimmyZ: these tests cover the newly added ops at least 07:25
JimmyZ oh
FROGGS but the cc is broken, like diakopter said
07:31 crab2313 joined
JimmyZ help! anyone knows how let uv_read returns what it reads? 07:36
a thread safe one :) 07:37
FROGGS is it possible that latest changes to nqp itself broke the cc? 07:49
JimmyZ cc works well on my libuv branch 07:50
if you mean nqp-cc
FROGGS yes 07:52
what is your nqp revision?
JimmyZ 2013.07-25-g1541771 07:53
FROGGS thanks
crab2313 2013.07-22-gfb241ae, cc works well too 07:59
on master 08:10
not_gerd diakopter: do you think we ever need to mmap files at an offset different from 0? 08:11
JimmyZ to replace apr_atomic_casptr, which libatomic_ops I should use? 08:32
08:42 cognominal joined
not_gerd JimmyZ: possibly AO_compare_and_swap_full 08:45
I'll need to look some more into libatomic_ops
not quite sure what's the differende between compare_and_swap and compare_and_swap_full 08:49
*difference
JimmyZ not_gerd: thanks, I'm using compare_and_swap
some times compare_and_swap is defined to compare_and_swap_full
at least on windows7 x86 msvc 08:50
I'm confused with apr_atomic_casptr and apr_atomic_cas32 08:51
not_gerd casptr maps to caompare_and_swap 08:56
libatomic_ops operates by default on pointer-sized values
for cas32, you probably should use AO_int_compare_and_swap 08:59
(assuming int is 32-bit, which it is on all platforms moarvm currently supports)
JimmyZ # define AO_int_compare_and_swap(addr, old, new_val) \\ 09:01
AO_compare_and_swap((volatile AO_t *)(addr), \\
(AO_t)(old), (AO_t)(new_val))
not_gerd JimmyZ: on x86, but should not be on x64 09:02
JimmyZ: you might want to preprocess the header and check which defines actually get used 09:03
JimmyZ not_gerd: the same
the same on x64
grep -r 'AO_int_compare_and_swap(' *
only this line :(
I know apr_atomic_casptr sometimes maps to apr_atomic_cas32, ie on gcc 09:04
but not on windows 09:05
I mean msvc
crab2313 weird, got QASTCompilerMAST.moarvm?Šš??? rather than QASTCompilerMAST.moarvm 09:10
diakopter oh! 09:13
crab2313: I'm getting a comma
instead of that
there must be a stray character in the Makefile.in
crab2313 diakopter: but the suffix is always different on my box 09:15
not_gerd JimmyZ: apr_atomic_casptr should be mapped tp AO_compare_and_swap according to documentation 09:17
AO_int_compare_and_swap apparently doesn't exist on windows
diakopter crab2313: weird! 09:18
not_gerd is back from getting rid of jehovah's witnesses at my door ;)
diakopter mace works well 09:19
(kidding)
JimmyZ not_gerd: and apr_atomic_cas32?
not_gerd: where is the doc?
diakopter not_gerd: yes, you need to define WIN98 or something to force it defined
I didn't know how two detect 32-bit 09:20
or else I would've added it
not_gerd JimmyZ: I was reading www.hpl.hp.com/research/linux/atomi...README.txt
JimmyZ: a - I forgot the define
(even though I added it to COnfigure.pl)
diakopter crab2313: it might be an apr error! 09:21
JimmyZ not_gerd: and how about apr_atomic_cas32? 09:22
diakopter JimmyZ: can't get it
I tried
have to use 64
JimmyZ diakopter: no api in libatomic_ops for apr_atomic_cas32? 09:24
diakopter no; have to use somehting size AO_t
JimmyZ I can't follow :( 09:25
not_gerd JimmyZ: libatomic_ops uses AO_t by default, which is a pointer-sized integer type 09:26
for cas32, you'd have to use AO_int_
but apparently they aren't available on windows? 09:27
diakopter yeah.
they should be though
I reported the bug a year ago
on libatomicops github
09:27 cognominal joined
JimmyZ you mean that define? 09:27
diakopter not_gerd: oh, should probably update ours from github.com/ivmai/libatomic_ops/ 09:28
not_gerd diakopter: looks like there's some activity, so might be a good idea 09:30
diakopter my 2nd issue is stil open there 09:31
09:31 colomon joined
not_gerd diakopter: I believe manually adding -DAO_ASSUME_WINDOWS98 is the right thing to do 09:33
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? gist.github.com/zhuomingliang/6256105 , btw, I'm on win32
FROGGS )
JimmyZ x86
not_gerd I wonder if it might be easier to just take the atomic stuff from apr...
diakopter I thought it'd be easier to just use AO_t everywhere 09:35
not_gerd that, too
or switch to C11
they come with nice _Atomic types
diakopter msvc doen't do it 09:36
meesa loves msvc
not_gerd they actually just recently decided to add some more C99 features
compound literals and some other stuff
MS is worse at implementing C than we are at implementing Perl6 ;) 09:37
JimmyZ or we fixed libatomic_ops bug ourself?
not_gerd JimmyZ: your gist isn't correct 09:38
you need to change the types of ->pool_index, ->ref_count etc to AO_t
JimmyZ apr_atomic_cas32 is using InterlockedCompareExchange API on windows 09:41
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:16
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
(not to keep apr)
jnthn ah
Doesn't seem worth it, though?
64-bit AO_t may well be faster on a 64-bit machine anyway...
diakopter yeah 10:19
not_gerd agrees
JimmyZ jnthn: I couldn't see where repr clone alloc object ... 10:21
or maybe in the future?
jnthn JimmyZ: I think KnowHOWREPR, were it ever cloned (and maybe its clone just is NYI) would do so.
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
I thought p6opaque might too
JimmyZ jnthn: KnowHOWREPR didn't
jnthn JimmyZ: Yes, but is its copy_to implemented? :)
JimmyZ yes 10:23
jnthn hm, I wonder what on earth it does... :)
JimmyZ it does MVM_ASSIGN_REF
jnthn um.
Yeah, that'll end up with the two sharing their method table etc. D'oh. :)
diakopter doesn't want to guess whether I did that..
jnthn wonders how widespread the issue is 10:24
Though I'm not sure that code-path is hit.
diakopter wouldn't think so
not_gerd gist.github.com/gerdr/6256243 # totally untested wrapper for mmap/winapi
JimmyZ another thing I wonders the difference copy_to between VMString and P6str
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
jnthn JimmyZ: They look correct.
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
I mean gerdr :P
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.
JimmyZ jnthn: ok, thanks. how about merging gerdr++'s configure system? 10:27
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?
not_gerd jnthn: see github.com/MoarVM/MoarVM/pull/46#i...t-22618300 10:29
we only need these 4 files
either from pr/46 or pr/49
the latter has everything besides libuv commented out
jnthn ok, will look 10:32
JimmyZ jnthn: libuv1 branch is for you :P. A new branch, without patching libuv 10:33
needs review
passed all test
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:35
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
jnthn: +1 to src/platform/
and for error process
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:37
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
JimmyZ I know rakudo is parsing parrot's error message
not_gerd jnthn: if we make these linkable, they'll need to be put into the MVM_ namespace
I don't really care either way
jnthn JimmyZ: Sometimes we need to convey more than just a code, however. 10:40
JimmyZ jnthn: aye
jnthn not_gerd: Aye, I just like to keep "where is X" relatively unsurprising. :)
JimmyZ jnthn: anyway, I'm +1 to src/platform/ 10:41
And I want it :P
dalek arVM: 47eb65b | jimmy++ | src/core/interp.c:
added back missing MVMROOT
 10:42
not_gerd is there an internal namespace?
not_gerd too lazy to look 10:43
these don't really belong in the public API
jnthn Not as of yet.
JimmyZ mvm_ :P
not_gerd MVM_platform_?
jnthn One thing nwc10++ pointed out is that we should be careful what we export and don't, though.
MVM_platform_ is fine
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
I think on Linux that needs some kind of linker script?
FROGGS btw, my nqp-cc seems to work again now, I had to rm nqp's /install, and the rebuilt everything
JimmyZ MVM_internal_ 10:45
jnthn Well, I'd have mark things that are API with MVM_API or some such.
JimmyZ mark MVM_API means exported 10:46
jnthn Yeah.
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
someone might want to link moarvm statically
moarvm seems to consistenly use the mvm prefix, so we're good on that 10:48
jnthn Yes, anything non-static should use that.
bbi15 or so
JimmyZ Maybe we could see how PHP src code does export, since there are many php exts.
# define MVM_API __attribute__ ((visibility("default"))) 10:51
and __attribute__ ((visibility ( internal ))) 10:52
jnthn: gcc.gnu.org/wiki/Visibility
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.
not_gerd JimmyZ: I'm thinking we should create src/platform and put it there 10:59
I can do it after jnthn gets back so we can sicuss factoring
JimmyZ not_gerd: great
not_gerd s/sicuss/discuss/ 11:01
dalek arVM: 0e62fbd | (Tobias Leich)++ | nqp-cc/t/serialization/0 (2 files):
nqpmo is still called nqp-mo
 11:02
jnthn JimmyZ: src/platform/memmap.[ch] 11:03
FROGGS diakopter: here is the proper output of the tests your newly added ops: gist.github.com/FROGGS/111a825365e629f4331c
JimmyZ not_gerd: ^^ :) 11:04
not_gerd jnthn: should we split that into src/platform/posix/mmap.c and src/platform/win32/mmap.c
JimmyZ jnthn: not src/platform/win32/memap.[ch] or something?
not_gerd and compile the right one via Configure.pl
or just one file with #ifdef?
JimmyZ aye
I'd like to separate 11:05
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.
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 :)
not_gerd jnthn: my Configure.pl should support that relatively hassle-free
jnthn not_gerd: OK. :)
not_gerd goes food-hunting 11:08
dalek arVM: 55b9e0f | jimmy++ | build/config.h.in:
added reference link for MVM_API exporting
JimmyZ grondilu: ^^
not_gerd if no one beats me to it, I'll do the mmap stuff after I get back
JimmyZ I'd suggest to add not_gerd to MoarVM :P 11:11
if not_gerd does not object... 11:12
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
It does seem a bunch more flexible, however. 11:23
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
* having
if the configuration logic gets more complex (automatic feature detection), that might be worth putting into a separate file 11:33
11:35 colomon joined
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:40
not_gerd that's certainly an option 11:42
the same goes for automatic feature detection
right now, we only detect if we're on x64 in case of windows, though
jnthn I think I'd prefer it that way 11:43
(the data split out) 11:44
JimmyZ We need detect whether support %lld or not ..
in the future
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:46
not_gerd jnthn: sure 11:47
I don't really need it, but it might make testing easier for you guys
jnthn not_gerd: aye, my thought too. It's not hard to pull from your fork, but laziness is nice... :)
ok, done :) 11:48
Of course, for obviously right things, just go ahead and commit in master. :) 11:49
shopping &
not_gerd I'll try not to make amess ;) 11:50
jnthn Well, in the worst case, git provides ways to cope with that :)
FROGGS .oO( git stalk not_gerd ) 11:55
12:03 birdwindupbird joined
not_gerd any one knows how to get the file descriptor/handle out of apr_file_t? 12:22
JimmyZ can't follow you 12:26
not_gerd JimmyZ: my mmap wrappers need a filr descriptor, which is hidden in an apr_file_t structure 12:27
I'll have to pull in some APR internal headers to get at it 12:28
the switch to libuv will fix that
*headdesk* 12:42
what is wrong with the following line:
writable ? FILE_MAP_READ | FILE_MAP_WRITE : FILE_MAP_WRITE
12:42 cognominal joined
JimmyZ where is the code? 12:46
I don't know ..
not_gerd JimmyZ: the last FILE_MAP_WRITE should read FILE_MAP_READ
if not writable, make it writable is not sound logic 12:47
12:50 cognominal joined
JimmyZ we don't need writeable 12:51
diakopter not_gerd: I thought you needed parens there 12:52
not_gerd diakopter: the ?: act as parens 12:56
dalek arVM/mmap: 4af81af | (Gerhard R)++ | / (5 files):
import new build system
arVM/mmap: 7a66dea | (Gerhard R)++ | build/Makefile.in:
add missing objects ot Makefile.in
arVM/mmap: fdc7214 | (Gerhard R)++ | Configure.pl:
disable libuv build
arVM/mmap: 1e64add | (Gerhard R)++ | src/platform/ (3 files):
add platform-specific mmap wrappers
arVM/mmap: efce9cb | (Gerhard R)++ | / (2 files):
build platform-specific files

reorder header inclusion order
not_gerd \\o/ 12:57
needs testing on non-windows 12:58
jnthn not_gerd: Does it remove the linenoise bits too? That's not in master yet, yes? 13:00
13:00 crab2313 joined
not_gerd jnthn: that's master + mmap - no additional 3rdparty libs 13:01
jnthn OK, I see a reference to linenoise in there, is all. 13:02
not_gerd jnthn: the important bit should be behing a comment 13:03
jnthn ok
not_gerd github.com/MoarVM/MoarVM/blob/mmap...ure.pl#L81 13:04
that's where we decide what to build
jnthn not_gerd: Hm, it auto-detects the x64 toolchain, and then /DAO_ASSUME_WINDOWS98 is in the compile line.
I *thought* (may be totally misremembering) that one was just needed on 32-bit... 13:05
crab2313 not_gerd: -osrc/main.o
not_gerd jnthn: it's needed on 32-bit, but I don't think it hurts on x64
jnthn ok
not_gerd I wouldn't know how to detect if it does, though ;)
jnthn builds mmap branch 13:07
not_gerd crab2313: the old system didn't build that?
well, it only becomes relevant once we start generatinc libmoarvm
crab2313 not_gerd: I'm on mmap
not_gerd crab2313: what's the problem with -osrc/main.o 13:08
crab2313 not_gerd: not just that
not_gerd: gist.github.com/crab2313/6256778 13:09
not_gerd crab2313: gist the generated Makefile? 13:10
diakopter I've gotten that before 13:12
crab2313 not_gerd: gist.github.com/crab2313/6256785 13:13
not_gerd crab2313: does `make -j1` help? 13:16
I'm not yet seeing anything wrong with the makefile...
crab2313 not_gerd: I should try it again 13:19
JimmyZ not_gerd: gist.github.com/zhuomingliang/6248474 13:22
I'm on centos x64
crab2313 not_gerd: I think it forget to build apr 13:24
not_gerd JimmyZ: the header inclusion order is wrong
alternatively, mmap.h needs to pull in stddef.h
jnthn: should I add an inclusion guard + dependency headers in mmap.h or reorder header inclusion order in mmap.c? 13:25
other internal moarvm headers don't use inclusion guards...
jnthn not_gerd: I prefer to avoid those. 13:26
crab2313 not_gerd: build apr manually 13:27
crab2313 not_gerd: and got the same issue
not_gerd oO
does the file 3rdparty/apr/include/apr.h exist? 13:28
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?
if so, *that* should have generated the header 13:30
crab2313 not_gerd: yes, I built it manually,
not_gerd crab2313: remove 3rdparty/apr/.libs/libapr-1.a and try a simple `make` again 13:31
JimmyZ not_gerd: gist.github.com/zhuomingliang/6248474 upated
not_gerd if that doesn't work, no idea what will
JimmyZ crab2313: which OS? 13:32
crab2313 not_gerd: I have solved the problem, and got the same issue as JimmyZ
dalek arVM/mmap: f4f5611 | (Gerhard R)++ | src/platform/posix/mmap.c:
pull in stddef.h in platform/posix/mmap.c
not_gerd crab2313, JimmyZ: ^^ 13:33
JimmyZ builds
crab2313 not_gerd: just think it should build apr automatically
not_gerd crab2313: it should
jnthn It did here for me, fwiw 13:34
crab2313 JimmyZ: gentoo x86
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
that *should* trigger the build
(except if you cleaned your apr dir but kept libapr-1.a around)
JimmyZ X86 is LibR, not .lib on windows 13:36
crab2313 not_gerd++
not_gerd JimmyZ: as far as I know, on linux it's always .lib 13:37
or .libs, rather 13:38
crab2313 it works on my box
grondilu on debian x86 notices apr libs in ./MoarVM/3rdparty/apr/.libs 13:40
JimmyZ good, not_gerd++, works on windows x86 13:41
13:45 donaldh joined
JimmyZ not_gerd: make test passed on CentOS X64 13:46
not_gerd: make test passed on Window X86 with msvc 13:51
jnthn Want me to retest on x64 windows? 13:52
not_gerd jnthn: shouldn't be necessary 13:53
jnthn just kicked one off anyway :) 13:54
JimmyZ so left part is atomic, diropen/dirread and socket for switching to libuv 13:55
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?
JimmyZ jnthn: yes
TimToady (on linux/64)
JimmyZ I tried, but failed
jnthn JimmyZ: OK, I can take that one on.
JimmyZ jnthn: and I have problem to get uv_read bufs ... 13:58
uv_read calls cb, and I don't know how to get its read
jnthn not_gerd: Things looked good 13:59
JimmyZ \\o/, merge !!
not_gerd ;) 14:00
I can pull out the config data from Configure.pl before that
jnthn Yes, please.
not_gerd hardest part is the naming
jnthn That's nothing new... :)
not_gerd what should the .pm be called? 14:01
jnthn gah! :P
BuildData perhaps?
JimmyZ ConfigMap.pm
jnthn map? :)
JimmyZ ConfigHash.pm 14:02
:P
or ConfigData.pm ?
jnthn ConfigData is also OK, but the data is mostly about how to build :)
JimmyZ the data is about configs :P 14:03
not_gerd the old name was Config::BuildEnvironment
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...
not_gerd oO( Configure::Data ) 14:09
JimmyZ oO 14:18
dalek arVM/configure: 23927ed | (Gerhard R)++ | build/Config/ (4 files):
get rid of old build system
 14:42
arVM/configure: 6d441fd | (Gerhard R)++ | / (2 files):
pull out build config data into build/setup.pm
not_gerd if it were my pet project, I'D totally do it like that
please tell me if it's too ugly for production and I should hide it away somewhere ;)
jnthn This branch is based off mmap one? 14:43
not_gerd jnthn: yes
jnthn k 14:44
exporting the symbols might'a saved some ::'s :
:P
JimmyZ tomorrow I will do opendir/readdir part :P 14:46
jnthn k
JimmyZ the left socket \\o/
not_gerd jnthn: configure branch needs a fix 14:54
jnthn JimmyZ: Are you just implementing synchronous stuff with libuv at the moment, or some async stuff also? 14:55
JimmyZ jnthn: nope
jnthn Which is the nope to? :)
JimmyZ jnthn: I needs read tty
tty use uv_read
14:55 benabik joined
JimmyZ jnthn: I know nothing about sync or async 14:56
dalek arVM/configure: ef6b17f | (Gerhard R)++ | Configure.pl:
fix backslash substitution
 14:57
JimmyZ jnthn: getstd may be tty or pipe or file, both tty and pipe use uv_read, but file uses uv_fs_read 14:58
uv_read_stat 14:59
jnthn Oh?
JimmyZ uv_read_start
jnthn So you can't get a standard handle and always read from it in the same way?
JimmyZ jnthn: yeah, see MVM_file_get_stdstream/MVM_file_read_fhs/MVM_file_write_fhs in github.com/MoarVM/MoarVM/blob/libu.../fileops.c 15:01
jnthn: libuv mostly uses uv_handle_t, execpt uv_fs_ part 15:02
*except
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:04
jnthn: so uv_fs_ will be using uv_handle_t in the future... 15:05
jnthn hm, ok 15:07
JimmyZ good night 15:42
not_gerd good night 15:43
jnthn 'night, JimmyZ 15:44
dalek arVM/libuv5: 2317be7 | diakopter++ | src/mast/compiler.c:
less debugging
 16:11
MoarVM/libuv5: eac6e83 | jimmy++ | src/io/fileops.c:
MoarVM/libuv5: added a few comments to MVM_file_readline_fh
JimmyZ jnthn: btw, libuv5 branch is better working branch than libuv1
16:12 dalek joined
JimmyZ master merged into libuv5 16:12
diakopter howdy 16:19
not_gerd bye, #moarvm 16:27
16:27 not_gerd left 17:38 benabik joined
benabik There are quite a few libuv\\d? branches. 17:40
jnthn benabik: Tell me about it! 17:42
o/ diakopter
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
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
</gripeing>
18:10 donaldh joined
dalek arVM: bfdfebd | jnthn++ | src/core/frame. (2 files):
Switch frame ref-count to libatomic_ops.
 19:03
diakopter who's jch 19:13
jnthn #define MVM_cas(addr, old, new)
has the comment
/* returns non-zero for success. Use for both AO_t numbers and pointers. */
really?
CAS usually returns what was seen...
diakopter yeah
jnthn grr 19:15
I'd rather we'd called that MVM_trycas
And used MVM_cas for the normal definition of CAS
diakopter so change it :P
jnthn yeah, doing so
diakopter jnthn: I don't know how you'll do it though 19:16
without making it read it again on failure
jnthn AO_t fetch_compare_and_swap(volatile AO_t * addr, AO_t old_val, AO_t new_val) 19:17
It's defined by libatomic_ops
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
did someone update lao from the repo? 19:20
jnthn oh, I was looking at the docs in the lao repo...hm
diakopter no I think fetch means add a fetch fence
er, that's read
I don't remember
jnthn Nope, "returns the original value of *addr" 19:21
but...hmm...seems our repo copy is behind..
diakopter yeah by a year
jnthn odd
ok
Think I'd rather update it than hack something myself
diakopter :)
now... it's significantly modified
had to strip out all the GPL stuff 19:22
diakopter watches jnthn's yak shave grow to a lawn mowing
jnthn: perhaps I should do the lao refresh since I mangled it previously 19:24
and surprisingly I somewhat remember it
jnthn OK
diakopter and you have better things to do :) 19:25
more jnthn-y things
jnthn ok, will push the MVM_cas => MVM_trycas rename since I did that. 19:26
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
*filename, I mean
jnthn oh, is that why I've a funny named file? 19:28
eek, now I've more of them
diakopter yeah I get it too; I can't find a problem with the Makefile
jnthn hmm :) 19:29
diakopter makes me think it's a parrot thing
or nqp, I guess
dalek arVM: 72a9fd4 | jnthn++ | src/core/ (2 files):
Switch frame_pool_num to libatomic_ops.
 19:30
arVM: 06ae890 | jnthn++ | src/ (4 files):
Rename MVM_cas => MVM_trycas.

The traditional cas definition is to return what was seen. We'll make MVM_cas mean that in the future, so rename the bool-returning one to MVM_trycas.
jnthn diakopter: uh, it may be me to blame :) 19:32
dalek arVM: 7ce6050 | jnthn++ | nqp-cc/src/ops/mvmcc.ops:
Make sure we get null-terminated filename.
 19:36
jnthn diakopter: ^^ fixes it
afaict
diakopter oh 19:37
jnthn diakopter: gc_free in MVMCompUnit seems to have some unrelated leftover code? 19:42
diakopter if so, oops 19:43
oh, not completed 19:44
jnthn In copy_to of MVMStaticFrame, I think the static_env should be copied from old to new
With a loop and MVM_ASSIGN_REF for the appropriate things 19:45
Is it better if I issues these?
diakopter oh, it's not?
jnthn oh, hang on...lemme check latest source in case if differs from the patch 19:46
diakopter oh oops
no
you're right
wait
those aren't objects
jnthn no, it doesn't
/* XXX start out with blank static env? */
dest_body->static_env = calloc(1, src_body->env_size);
diakopter oh, that 19:47
jnthn Right, it's a bunch of registers; it goes by lexical_types as to what's in there
jnthn is happy to see MVM_gc_worklist_add_frame 20:00
20:04 colomon joined 20:20 dalek joined
benabik diakopter: Junio C Hamano, git maintainer 21:19
21:44 colomon joined
diakopter jnthn: any other things need fixing? 22:26
jnthn diakopter: Not that I could see right off. 22:27
diakopter yay, I think :)
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 :)
Otherwise, I can just take pot shots at whatever I find stopping NQP on Moar... :) 22:32
diakopter nqp-cc\\> make NQPP6QRegex.nqp
nqp-cc\\> make NQPP6QRegex.moarvm
nqp-cc\\> nmake NQPP6QRegex.moarvm
er, also gist.github.com/FROGGS/111a825365e629f4331c 22:33
jnthn gotcha
diakopter ^ my completely naive attempts at those opcodes
jnthn oh...serialization ain't even implemetned yet
diakopter well, those prereq opcodes 22:34
jnthn So I'd have been surprised if the tests got anywhere :)
ok
diakopter the 4 added in that bit commit
big
jnthn yeah, noticed those...
diakopter wonders where lizmat
jnthn OK, will see how my tuits/brane are tomorrow
diakopter 'nite
jnthn about for 10 mins more... 22:36
diakopter frankfurt flight is $1337 each for me and Melanie
... 22:37
jnthn 1337!
22:58 cognominal joined 23:17 colomon joined 23:27 BenGoldberg joined
BenGoldberg .ping 23:31
yoleaux There is no ping command; nor can this be construed as a response.
diakopter . 23:37
.yoleaux
.yolo
.ping response
yoleaux There is no ping command; nor can this be construed as a response.
BenGoldberg So I've got this silly question about NQP... 23:40
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
be a formal spec?
23:45 Ben_Goldberg joined
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:46
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:49
diakopter no; for MoarVM we just looked at the implementations for Parrot and the JVM 23:52
23:52 colomon joined
Ben_Goldberg Ok 23:52
diakopter (you'd have to do a lot of that anyway, so a document wouldn't help much)
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
Ben_Goldberg Approximately how many nqp:: ops are there? 23:57
diakopter 4-500? 23:58
some dramatically huger than others
Ben_Goldberg Wow! That's a lot! :) 23:59
And approximately how many does MoreVM have implemented?

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!