Camelia, the Perl 6 bug

IRC log for #moarvm, 2013-08-19

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

All times shown according to UTC.

Time Nick Message
00:01 benabik diakopter: Well, yes, I'm #defining MAP_ANONYMOUS, I was just being lazy typing into IRC.
00:02 benabik Just wasn't sure if there was some platform abstraction thing I should deal with or just do the quick-and-dirty #defining
00:11 diakopter oh :)
00:11 diakopter <- no clue
00:26 benabik joined #moarvm
00:31 colomon joined #moarvm
00:35 benabik Oh, that's new.  threads.t now segfaults instead of giving me that can't GC message.
00:40 dalek MoarVM: 2b5207c | benabik++ | src/platform/posix/mmap.c:
00:40 dalek MoarVM: Fix anonymous mmap for Darwin/BSD
00:40 dalek MoarVM:
00:40 dalek MoarVM: OS X (and probably all BSDs) spell the flag for anonymous mmap
00:40 dalek MoarVM: MAP_ANON instead of Linux's MAP_ANONYMOUS.  Until someone else has a
00:40 dalek MoarVM: more clever idea of how to abstract out this particular platform
00:40 dalek MoarVM: gotcha, simply #define MAP_ANONYMOUS as MAP_ANON when the latter is
00:40 dalek MoarVM: available and the former isn't.
00:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2b5207cb84
01:52 dalek Heuristic branch merge: pushed 38 commits to MoarVM/libuv5 by zhuomingliang
02:20 colomon joined #moarvm
03:10 dalek MoarVM/libuv5: 5698f25 | jimmy++ | build/ (2 files):
03:10 dalek MoarVM/libuv5: enable libuv build
03:10 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/5698f25e4e
03:11 diakopter benabik: the previous error was a fluke anyway
03:12 benabik diakopter: I prefer flukes to segfaults?  ;-)
03:12 diakopter well at least it didn't format your hard disk :D
03:12 benabik :-P
03:13 benabik PSA: Have you backed up your development machine lately?
03:15 * diakopter is making compunit loading threadsafe
03:15 diakopter and closing a big-ish memory leak
04:01 * diakopter surmises my patch is ready
04:02 diakopter hm, nope
04:04 diakopter actually I don't really have a way of telling whether my patch regressed or advanced things
04:04 diakopter jnthn will have to englighten me tomorrow :)
04:05 diakopter meanwhile, this backtrace is some kind of beautiful:
04:06 diakopter C:\Users\mwilson\src\MoarVM\nqp-cc>ptime ..\moarvm nqp.moarvm -e "1"
04:06 diakopter ===  ..\moarvm nqp.moarvm -e "1" ===
04:06 diakopter cannot stringify this
04:06 diakopter in frame_name_733, ./QASTMoar.moarvm
04:06 diakopter in moarop_mapper, ./QASTMoar.moarvm
04:06 diakopter in add_core_moarop_mapping, ./QASTMoar.moarvm
04:06 diakopter in frame_name_0, ./QASTMoar.moarvm
04:06 diakopter in frame_name_1520, ./QASTMoar.moarvm
04:06 diakopter in frame_name_38, ModuleLoader.class
04:06 diakopter in load_module, ModuleLoader.class
04:06 diakopter in frame_name_1666, ./NQPP6QRegexMoar.moarvm
04:06 diakopter in frame_name_38, ModuleLoader.class
04:06 diakopter in load_module, ModuleLoader.class
04:06 diakopter in frame_name_3744, nqp.moarvm
04:06 diakopter Execution time: 0.036 s
04:08 diakopter time to add line numbers and source file names to the backtrace
04:15 grondilu you don't use gdb?
04:16 grondilu .oO( though I suppose that even with gdb line numbers and source file names would be useful )
04:17 diakopter gdb?
04:18 diakopter it's... not machine code
04:18 * grondilu is confused
04:19 diakopter maybe I don't understand what you were suggesting
04:19 grondilu well, moarvm can be debugged with gdb, can't it?
04:19 diakopter <- never used gdb (obviously)
04:19 diakopter I use Visual Studio
04:19 grondilu oh
04:19 diakopter but it knows nothing about our bytecode
04:19 grondilu indeed
04:20 diakopter how would we tell any debugger (including gdb or vs) about our bytecode invocation callstack?
04:20 grondilu but since you were talking about "line numbers" I thought you were talking about C code
04:20 benabik I'd say gdb can't be used to debug bytecode, but you can really hack gdb's concept of functions and data and such, so maybe you can.
04:20 diakopter oh, no.. line nubmers in .nqp source files
04:20 grondilu ok
04:21 grondilu but moarvm has no visibility on the nqp code, has it?
04:21 diakopter I created QAST::Annotated for that purpose
04:21 grondilu ok
04:21 diakopter well, jnthn spec'd it, but I implemented it
04:21 grondilu that would be very useful, then
04:22 diakopter similar to parrot's annotations in pir
04:22 diakopter ..just .. special AST nodes instead
04:23 diakopter and stored interestingly in the bytecode
04:23 diakopter will need to do some interesting back-resolving
04:23 grondilu I recently tried to use gdb to see why moarvm failed on 24-modules.t and I got completely lost in the code.  (too complicated for me)  A backtrace to the NQP code might help.
04:23 diakopter of the offset
04:23 diakopter offsets
04:24 diakopter well this is the first time it's running the nqp compiler (any nqp program of substance, anyway)
04:25 grondilu "and stored interestingly in the bytecode"  wouldn't that increase the size of the bytecode?  Hopefully it would be a debugging option, not default, right?
04:27 diakopter nah, it's tiny; around one entry per line in the original file, and it's just an integer
04:27 grondilu ok
04:27 diakopter so around 8KB for a 1024-line file.. which seems to make a 200KB .moarvm or so
04:27 diakopter (total)
04:31 diakopter grondilu: because nqp's instruction set is so gargantuan, its bytecode will be .. much smaller than, say, the corresponding .jar, even compressed
04:32 diakopter each of those nqp ops in the jvm bytecode turns into a static method call
04:32 diakopter here, it's effectively the same, just encoded much tinier
04:40 dalek MoarVM: 5657ef8 | diakopter++ | src/ (13 files):
04:40 dalek MoarVM: - eliminated traversing chain of all compunits loaded when deserializing a serialization context
04:40 dalek MoarVM:
04:40 dalek MoarVM: - pre-allocate SCBody objects and store them in the weak hash (which is a little less weak now)
04:40 dalek MoarVM: - make compunit loading from disk (by filename) threadsafe and atomic; add a loaded filename registry
04:40 dalek MoarVM: - factor out some of the SC getting code from the two wval nqp:: ops in interp.c
04:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5657ef87c7
04:40 dalek MoarVM: b01dba8 | diakopter++ | src/ (2 files):
04:40 dalek MoarVM: work around lack of sc descriptions right now
04:40 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b01dba8348
04:40 diakopter benabik: better commit message?
04:41 benabik diakopter: Yes, thank you.  :-)
04:44 * diakopter dares to launch moarvm nqp.moarvm -e "1"  when SysMon is running..... O_O
04:44 diakopter er, procmon
04:45 diakopter WAT.
04:46 diakopter we, um, may want to dynamically link to some windows system dlls
04:47 benabik How many gigs for -e 1?
04:47 birdwindupbird joined #moarvm
04:48 diakopter no, it's just it queried a few hundred registry keys regarding tcp socket
04:49 diakopter well I guess that took only 3 milliseconds
04:50 diakopter well anyway from the time it first read nqp.moarvm to exiting, it was 24 ms
05:00 diakopter http://www.perl6.com/run000.csv
05:00 diakopter make sure to open it in something that doesn't mangle the first column values into dates without nanosecond resolution
05:07 grondilu trying make nqptest:
05:07 grondilu SC not yet resolved; lookup failed in frame_name_59, ModuleLoader.class in frame_name_4, temp.moarvm
05:08 diakopter hm
05:08 diakopter all of them?
05:08 * diakopter waits for all the things to emit
05:11 diakopter grondilu: when did you last git pull?
05:12 diakopter (make nqptest is clean for me)
05:15 diakopter benabik: looks like loading nqp uses ... 12 MB
05:15 benabik diakopter: nice
05:17 diakopter that seems... orders of magnitude smaller than on parrot..
05:17 diakopter ._._
05:18 diakopter _._.
05:18 diakopter (surely I'm not measuring correctly)
05:21 ggoebel joined #moarvm
05:22 JimmyZ diakopter: btw, I see some repetitive Callsite in .moarvmdump
05:22 diakopter I noticed that too
05:24 grondilu diakopter: few minutes ago
05:24 grondilu last commit:  2b5207cb84c89a0e09d3e91b95d3f7b4af3c2c6b
05:25 diakopter grondilu: I got that error before my last two commits; are you sure you reconfigured and rebuilt both moarvm and the cross compiler?
05:25 diakopter maybe you just rebuilt the cross compiler
05:25 * grondilu reconfigure and rbuilts
05:25 grondilu (and repulls)
05:42 JimmyZ merged master into libuv5, and see a lot of "SC not yet resolved" :P
05:43 diakopter hrm
05:43 diakopter mis-merge? :)
05:43 JimmyZ no :)
05:43 diakopter erm, I hope my commit still exists..
05:44 JimmyZ diakopter: last commit in libuv5 is Benabik
05:44 diakopter yer missing some
05:45 diakopter https://github.com/MoarVM/MoarVM/commits/master
05:47 JimmyZ merge conflict :(
05:56 dalek MoarVM/libuv5: 5657ef8 | diakopter++ | src/ (13 files):
05:56 dalek MoarVM/libuv5: - eliminated traversing chain of all compunits loaded when deserializing a serialization context
05:56 dalek MoarVM/libuv5:
05:56 dalek MoarVM/libuv5: - pre-allocate SCBody objects and store them in the weak hash (which is a little less weak now)
05:56 dalek MoarVM/libuv5: - make compunit loading from disk (by filename) threadsafe and atomic; add a loaded filename registry
05:56 dalek MoarVM/libuv5: - factor out some of the SC getting code from the two wval nqp:: ops in interp.c
05:56 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/5657ef87c7
05:56 dalek MoarVM/libuv5: b01dba8 | diakopter++ | src/ (2 files):
05:56 dalek MoarVM/libuv5: work around lack of sc descriptions right now
05:56 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/b01dba8348
05:56 dalek MoarVM/libuv5: c98f981 | jimmy++ | src/ (14 files):
05:56 dalek MoarVM/libuv5: Merge remote-tracking branch 'remotes/origin/master' into libuv5
06:00 JimmyZ t\qast\qast_terms.t Failed test:  2
06:01 JimmyZ much better, and a retrogress
06:02 JimmyZ :P
06:23 grondilu ok all test successful now
06:23 not_gerd joined #moarvm
06:23 not_gerd o/
06:23 dalek MoarVM: a1d0502 | (Gerhard R)++ | src/platform/posix/mmap.c:
06:23 dalek MoarVM: Make flag detection for anonymous mmap() more robust.
06:23 dalek MoarVM:
06:23 dalek MoarVM: Probably overkill, but arbitrary flag values can now be supported by adding
06:23 dalek MoarVM: a definition of MVM_MAP_ANON to build/setup.pm.
06:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a1d050293d
06:25 not_gerd ^ this can be used as template for other custom platform defines
06:25 benabik not_gerd++
06:27 not_gerd I don't think there's an OS that uses anything other than MAP_ANON and MAP_ANONYMOUS, but I did it anyway ;)
06:27 benabik I figured that the eventual failure on MAP_ANONYMOUS would be enough of a hint.  :-)
06:28 benabik Although I was also just too busy to get any further than just getting it working.
06:28 not_gerd the other fix would have been to just use MAP_ANON on linux as well
06:29 not_gerd that's supposedly deprecated, though
06:36 crab2313 joined #moarvm
06:42 JimmyZ \o, not_gerd
06:50 FROGGS joined #moarvm
07:47 JimmyZ hmm, change compunit to uv_fs_open , cause Bytecode stream corrupt (missing magic string)
07:48 JimmyZ memcmp(cu_body->data_start, "MOARVM\r\n", 8) != 0) faied
07:48 crab2313 joined #moarvm
07:48 benabik Does uv do \r\n -> \n conversion?
07:49 JimmyZ should not , I only open
07:49 benabik Some libraries there's a difference between opening text and binary files.  *shrug*
07:50 JimmyZ How do I open file with binary flag?
07:51 not_gerd JimmyZ: shouldn't be necessary
07:51 not_gerd JimmyZ: I've also looked into converting compunit, and it mostly worked
07:52 not_gerd I did not push anything yet because there's some error handling missing and I got a new test failure
07:52 JimmyZ not_gerd: great
07:52 not_gerd (the latter might be unrelated)
07:52 not_gerd should I push to libuv5 as-is?
07:52 JimmyZ not_gerd: yes
07:53 JimmyZ I'm curious what's wrong with my code
07:53 dalek MoarVM/libuv5: e8c535f | (Gerhard R)++ | src/core/compunit.c:
07:53 dalek MoarVM/libuv5: Switch MVM_cu_map_from_file() from APR to libuv
07:53 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/e8c535f071
07:58 JimmyZ I still don't know what's wrong :(
07:59 not_gerd does this work for you or still fail?
08:00 JimmyZ I didn't try, I compare the code ,almost the same :(
08:02 JimmyZ you works !
08:05 JimmyZ and I don't know why :(
08:14 dalek MoarVM/libuv5: 3db5229 | jimmy++ | src/ (3 files):
08:14 dalek MoarVM/libuv5: code cleanups
08:14 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/3db5229f1f
08:20 JimmyZ not_gerd: Yeah, I got new nqp t\moar\socket_send_recv.t failure
08:20 JimmyZ but that's apr codes
08:21 not_gerd JimmyZ: that doesn't fail for me
08:21 not_gerd it's qast_terms.t here
08:21 not_gerd I think using uv_hrtime() is wrong for MVM_proc_time_*()
08:21 JimmyZ not_gerd: this one seems failed on master also
08:21 JimmyZ maybe not
08:22 JimmyZ I didn't try :(
08:22 not_gerd uv_hrtime() returns CPU time, not date time
08:22 JimmyZ oh
08:22 not_gerd uses QueryPerformanceCounter() on windows
08:23 not_gerd we might need to add our own version to platform/
08:23 JimmyZ yeah
08:23 JimmyZ I thought it's date time
08:24 JimmyZ Yeah, it is for measuring performance
08:26 JimmyZ I'd not split some dirops.c code to src/platform and include src/platform/dir.h in src/io/dirops.h
08:26 JimmyZ s/not//
08:27 JimmyZ not_gerd: how do you think about it?
08:28 not_gerd JimmyZ: makes sense - lots of #ifdef in that file...
08:28 JimmyZ not_gerd: aye
08:29 JimmyZ not_gerd: and fileops.c
08:29 cognominal joined #moarvm
08:30 jnthn Note that bytecode files should be mmap'd; please don't lose that in the libuv changes.
08:30 yoleaux 03:09Z <ruoso> jnthn: I thikn we need to move the entire threading support to nqp, because the scheduler needs to start earlier and all actual code need to move to one of the scheduled threads, otherwise we won't be able to switch context in the main thread
08:30 JimmyZ jnthn: Are you fine to split some dirops.c code to src/platform and include src/platform/dir.h in src/io/dirops.h?
08:31 not_gerd jnthn: it's just about switching to the libuv versions of open and stat
08:31 not_gerd jnthn: the mmap() code was already made libuv-compatible with the merge of my branch
08:31 JimmyZ jnthn: and how about uv_read_start, patch it to add a args to return buf, or use callback without return anything?
08:32 not_gerd JimmyZ: MVM_dir_open() doesn't set result->body.dir_name in the linux version
08:32 jnthn not_gerd: OK, great.
08:33 jnthn JimmyZ: Yes, I'd prefer platform-specific bits under src/platform/
08:34 JimmyZ not_gerd: result->body.dir_name only needs for windows
08:34 JimmyZ not_gerd: windows must use it
08:35 JimmyZ not_gerd: linux just opendir :P
08:37 JimmyZ not_gerd: only for "FindFirstFileW(handle->body.dir_name, &ffd);" )
08:38 jnthn JimmyZ: Should we not just be using uv_fs_read?
08:38 jnthn oh, maybe not...
08:38 JimmyZ uv_fs_read only fd
08:39 JimmyZ others are using uv_read_start, and ipc use uv_read2_start
08:40 JimmyZ s/fd/file/
08:40 JimmyZ tty use uv_read_start also
08:41 jnthn OK, but I'm confused by what you're asking. There's never ambiguity whether we're meant to produce a buffer or a string...
08:43 JimmyZ jnthn: I just can't get the buf for reading  tty  ...
08:43 JimmyZ stdin
08:45 JimmyZ I mean I must use uv_read_start for reading tty, but uv_read_start can't return what it reads
08:47 jnthn Right, it takes callbacks. So...there's no synchronous/blocking way to read from a tty?!
08:47 JimmyZ jnthn: I couldn't find one
08:48 jnthn OK, I don't have time to dig more deeply into it now.
08:48 donaldh joined #moarvm
08:48 JimmyZ jnthn: http://nodejs.org/api/tty.​html#tty_class_readstream has some tips, but I can't understand
08:48 JimmyZ jnthn: OK :)
08:57 not_gerd jnthn: do we care about windows support prior to Windows 2000?
08:58 jnthn um, that's be, like, 95, 98 and ME? :)
08:58 FROGGS and 3.11
08:58 jnthn lol
08:58 FROGGS and NT :o)
08:58 FROGGS could be problematic because of just having 32MB ram though
08:58 jnthn Yeah, quite...
08:59 jnthn not_gerd: So long as it's not impossible for somebody to later send us a patch to support them... :)
09:00 JimmyZ some fileops dirops, should be Windows XP....
09:00 JimmyZ and for server, should be Windows2003
09:02 not_gerd jnthn: I'm asking specifically because the APR time code is more portable than what I'm going to replace it with
09:02 not_gerd I'm all in favour of using more recent versions of the winapi
09:04 JimmyZ yes, what I'm using CreateDirectory for dirops, Minimum supported clientWindows XP
09:04 JimmyZ :P
09:06 JimmyZ not_gerd: apr_dir_read()  Minimum supported client Windows XP
09:17 grondilu_ joined #moarvm
09:25 dalek MoarVM/libuv5: c6f0bb0 | jimmy++ | src/ (3 files):
09:25 dalek MoarVM/libuv5: clean up a bit needless code
09:25 dalek MoarVM/libuv5: review: https://github.com/MoarVM/MoarVM/commit/c6f0bb08cd
09:46 grondilu joined #moarvm
09:47 diakopter benabik: ping
09:48 diakopter FROGGS: would you like a mini-project?
09:48 diakopter (or anyone)
09:48 FROGGS diakopter: tell us first :o)
09:48 diakopter it's to update libatomic_ops from the repo
09:49 diakopter our copy is around a year old
09:49 diakopter and lots of improvements since then
09:49 diakopter but the thing is to strip out the gpl stuff
09:50 FROGGS ohh
09:50 diakopter jnthn: ping
09:50 JimmyZ https://github.com/ivmai/libatomic_ops this?
09:50 diakopter yes
09:51 diakopter notice I submitted a couple issues there a long time ago
09:51 * JimmyZ decommutes
09:52 jnthn diakopter: pong, though I'm distracted
09:52 diakopter jnthn: just to say I think my patch was a success
09:52 diakopter though I got a different result after clean reconfigure, make
09:52 diakopter kinda odd
09:53 diakopter jnthn: but anyway I'm happy with the sc/compunit loading mostly now
09:53 diakopter jnthn: did you want to do serialization?
09:53 diakopter if not, should I port it from the java?
09:54 jnthn diakopter: No, I've already written the serialization code like a gazillion times in my life. It's relatively noddy compared to the deserialization.
09:54 jnthn diakopter: So I will be most happy to have that task stolen :)
09:54 * diakopter blink at noddy
09:54 diakopter oh yeah, we discussed this
09:55 jnthn diakopter: Steal it from the C impl on Parrot :)
09:55 diakopter oh
09:55 jnthn diakopter: You can take a lot of it "as is" :)
09:55 tadzik noddy: http://www.brownbagfilms.com/images/blo​g/legacy-files/2009/08/David_Noddy.jpg
09:55 jnthn diakopter: I did that for deserialization. Serialization should be even easier. :)
09:56 jnthn tadzik: yes, that's the character, but the word just means "simple" :)
09:56 diakopter so it'll have its own new area in .moarvm?
09:56 tadzik heh
09:56 * diakopter laughs at the reflection in noddy's tassel bell
09:56 jnthn diakopter: For now we can just go with the same approach (treat it as a string)
09:58 diakopter jnthn: right, so.. in the string heap??
09:58 jnthn diakopter: But yeah, we can do better eventually...
09:58 jnthn diakopter: Yes, that's how I started out on JVM. Then sorear++ came up with something better.
09:58 jnthn diakopter: We could get that in from the start, though.
09:58 jnthn We gotta support both ways for deserialization for now.
09:59 jnthn But it'd be nice to avoid all the base-64 screwery.
09:59 diakopter what? you mean base64 isn't consistent everywhere? ;)
09:59 jnthn The tests also rely on getting the thing back as a string...
09:59 jnthn It is, but when I profiled our startup time on Parrot, 15%-20% of startup time was decoding base-64 :/
09:59 diakopter yeah well
10:00 * jnthn tries to get back to reviewing his SOA slides...
10:00 diakopter jnthn: are the Annotated nodes being created now?
10:01 jnthn diakopter: Being created?
10:01 diakopter by the compiler
10:01 jnthn As in, in QAST -> MAST? Don't think so.
10:01 diakopter to mast
10:01 diakopter oh ok. that would explain why I'm notn seeing them
10:02 * diakopter feels on kiev time
10:02 jnthn mmmm....kiev
10:02 diakopter jnthn: did you read above nqp seems to load on moarvm to ... 12MB ram? and in 24ms?
10:02 jnthn "not bad"
10:03 jnthn Would be happy to lose a bit more of that.
10:03 diakopter O_O
10:03 jnthn Like, by skipping the base-64 decoding ;)
10:04 * jnthn wonders how much of that 12MB is deserialized NFAs...
10:04 diakopter I wonder how long it takes to += an offset to 100,000 pointers in 15MB
10:06 timotimo if you write that part in C, the compiler can probably turn that into a SIMD instruction
10:06 diakopter o_O
10:06 timotimo well, of course only if they are in one region
10:07 diakopter yeah but their addresses are from a list
10:07 diakopter though that loop could be unrolled into one huge executable... ;)
10:08 not_gerd is there a particular reason why MVM_proc_time_i() returns microseconds?
10:08 diakopter well so it be an integer
10:08 diakopter and have lots of precision
10:09 jnthn Yeah but if it doesn't do what the mapped nqp:: is meant to do... :)
10:09 jnthn Of course, we can always transform it :)
10:09 not_gerd diakopter: millis and nanos are more common in time APIs, I believe
10:09 not_gerd what does nqp want here?
10:10 diakopter just change what nqp wants :P
10:13 * grondilu notices that MVM_proc_time_i is stored in int64, so it's kind of a waste of space to only store microseconds
10:13 diakopter but apr provided only microsecond precision, I think
10:14 not_gerd grondilu: but what will happen in 2038?
10:14 diakopter but i know windows provides nanosecond resolution, but somewhat less than nanosecond precision
10:14 diakopter like 12x less or something
10:14 grondilu still much enough space in int64 in 2100, I think
10:14 * grondilu execs date +%N
10:14 grondilu 725773342
10:15 * grondilu execs perl -e 'print log(qx(date +%N)) /log 2'
10:16 grondilu 27.9658131609481
10:16 grondilu oops, that's not all the ns.  Please ignore
10:18 timotimo r: say :2(725773342)
10:18 not_gerd anyway signed int64 and ns should be good for another ~250 years
10:18 timotimo wait, no that's wrong
10:18 timotimo how do i do that again?
10:18 grondilu perl -e 'print log(qx(date +%s%N))/log(2)'
10:18 grondilu 60.2561373693267
10:19 * grondilu notices there is camelia here as well
10:19 grondilu r: say log(qx{date +%s%N}) / log(2)
10:19 timotimo it uses the restricted setting, no qx for you ;)
10:20 grondilu oh
10:20 timotimo r: say now.Int
10:20 timotimo much easier than qx(date +%N) or anything like that
10:20 timotimo also, camelia is having some trouble it seems
10:21 timotimo r: now.Int.fmt("%b").chars  -  would give you the number of bits
10:23 jnthn We don't have a camelia in this channel
10:26 timotimo oh, i'm in moarvm?
10:26 timotimo yes, that would explain the trouble i'm having :)
10:26 donaldh joined #moarvm
11:09 dalek MoarVM: 009d5c2 | (Gerhard R)++ | / (7 files):
11:09 dalek MoarVM: Back time_i/time_n by custom MVM_platform_now()
11:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/009d5c27c2
11:09 not_gerd benabik: could you test that on OSX?
11:26 JimmyZ not_gerd: I'd like move MVM_proc_time_[i|n] to src/platform/time.h
11:28 not_gerd JimmyZ: I'd like to keep the factoring as it is in master right now
11:28 not_gerd otherwise, we'd have to back on op by an MVM_platform_ function
11:30 not_gerd on second thought: MVM_proc_time is never stored anywhere, but called directly in core/interp.c
11:31 not_gerd so we could just get rid of MVM_proc_time_* completely and call MVM_platform_now() directly
11:34 JimmyZ not_gerd: I'd like to keep #include "platform/time.h", but move MVM_proc_time_[i|n] to src/platform. Well, I just hate wrap :)
11:34 dalek MoarVM: 4a202fd | (Gerhard R)++ | src/platform/ (2 files):
11:34 dalek MoarVM: Fix whitespace fail: No, Sir, of course I did not use tabs...
11:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4a202fd55a
11:34 JimmyZ #include "platform/time.h" in src/procops.h
11:35 not_gerd I think jnthn will be sad if something called MVM_proc_* is defined in platform/
11:39 jnthn He may just :)
11:39 colomon joined #moarvm
11:40 jnthn Note that there's time_i and time_n ops, but they may well source their informatoin from the same call.
11:48 not_gerd then I'll just remove MVM_proc_time_[in] after I've prepared some food
11:48 JimmyZ \o/, may time_i and time_n call MVM_platform_now directly :P
11:49 not_gerd JimmyZ: exactly
11:49 jnthn Maybe, or they call functions that use the single MVM_platform_ call.
11:49 not_gerd jnthn: that's what they do right now, but JimmyZ doesn't like the indirection
11:49 * not_gerd is off hunting and gathering
11:53 JimmyZ We can call MVM_platform_ everywhere in MoarVM :)
11:55 jnthn It's desirable that ops in the interpreter stay simple.
11:58 not_gerd jnthn: it's about `MVM_proc_time_n(tc)` vs `MVM_platform_now() / 1e9`
12:15 cognominal joined #moarvm
12:39 donaldh joined #moarvm
12:43 JimmyZ diakopter: ping?
12:47 lizmat JimmyZ: I would hope for diakopter that he's asleep (at 5:45am his time)
12:48 JimmyZ oh
12:49 jnthn With diakopter, you can never be sure... :)
12:49 JimmyZ aye
12:49 JimmyZ so I just copy https://github.com/ivmai/libatomic_ops to Moar
12:49 JimmyZ MoarVM master?
12:50 jnthn No
12:50 jnthn You have to strip out the GPL bits...
12:51 JimmyZ GPL ?
12:52 jnthn The stuff in the repo is under different licenses.
12:52 jnthn Please wait for diakopter to provide details rather than guessing
12:53 JimmyZ ok :)
13:06 brrt joined #moarvm
13:08 lizmat that's why I said "I would hope"  :-)
13:09 lizmat having been a person who used to burn the candle at both ends, I know what a burnout is like
13:09 brrt hey #moarvm… i was reading the yapc::eu talk of jnthn about moarvm
13:09 brrt and i saw something of which i thought i could be of some help
13:10 brrt long story short: earlier this year, i outlined (in some detail) a way to make the GC of pypy (which is similar to the moarvm in concept at least) multi-threaded
13:11 brrt by an algorithm that is in core very similar to the concept of VCGC, but adapted for a nursery - and - generation system
13:11 jnthn Are we talking parallel or concurrent here? :)
13:11 brrt both (muhahaha)
13:11 brrt doesn't really matter jnthn
13:12 jnthn Parallel is fine, but we're already kinda doing that (but it needs improvements!) Concurrent, I don't want the complexity of this for a good while.
13:12 jnthn It does really matter. :)
13:12 brrt noted. but this isn't a complex algorithm we are talking about
13:13 brrt anyway, proof of pudding = eating, innit? so rather than talk about it, i'd better just do it
13:13 TimToady that's what branches are for, after all :)
13:15 TimToady I guess the other question is not whether the GC itself is simple, but whether it induces difficulties in the rest of the code, such as reasoning about optimizability
13:15 brrt hmmm
13:15 jnthn Well, yeah. We already have write barriers to worry about.
13:15 brrt fair point
13:15 brrt oh, but if you already have write barriers
13:15 jnthn Concurrent GC algos can also add read barriers to the mix.
13:15 brrt then it complicates nothing further
13:15 jnthn Which I'm fairly keen to avoid.
13:16 brrt because it in fact relies solely on write barriers for consistency
13:16 flussence_ joined #moarvm
13:16 jnthn The other thing about concurrent is it *tends to* give lower pause time at the cost of lower throughput...
13:16 hoelzro_ joined #moarvm
13:17 TimToady could be better for RT stuff though
13:17 jnthn (Which is why the CLR comes with multiple GCs, a client one and a server one)
13:17 brrt that is true, but, as far as i know, nobody has ever tried a generational-concurrent hybrid
13:17 colomon joined #moarvm
13:17 TimToady would be fun if P6 became the language of choice for game writers :)
13:17 jnthn (But going the way of pluggable GC is crazy this early in the project, pre-JIT)
13:19 lizmat TimToady: and why not ?  :-)
13:19 nwc10 Yes, first implement all Rosetta Code examples, and *then* make them run fast. :-)
13:19 TimToady gamers don't like the GC pausing their game at random times
13:20 eternaleye_ joined #moarvm
13:21 lizmat TimToady: but game developers really need more -Ofun!  http://games.slashdot.org/story/13/08/16/163204/b​iggest-headache-for-game-developers-abusive-fans
13:21 * TimToady hates loud fans too :)
13:22 TimToady my current machine is pretty quiet though :)
13:28 benabik joined #moarvm
13:32 colomon joined #moarvm
13:32 dalek joined #moarvm
13:33 nwc10 TimToady: this does make me think of http://dilbert.com/strips/comic/1995-04-03/
13:51 benabik joined #moarvm
14:45 cognominal joined #moarvm
14:55 FROGGS joined #moarvm
15:28 benabik joined #moarvm
16:51 benabik joined #moarvm
17:28 donaldh joined #moarvm
17:48 donaldh joined #moarvm
17:48 TimToady is there any reason the executable for moarvm shouldn't just be 'moar'?
17:51 PerlJam http://www.giantbomb.com/images/1300-1278370
17:51 jnthn moarvm is just a lot less likely to accidentally name-collide with something and it's not something I expect people to type directly very often so being shorten doesn't seem immediately important
17:52 jnthn Is there any reason why it should just be 'moar'? lolz aside :P
17:53 TimToady lolz are important too :)
17:53 TimToady but yes, I'd expect it'd usually get invoked as 'perl6' or some such :)
17:54 TimToady maybe we should grab p6 while we can :)
17:55 FROGGS and if you need google's help, searching for "moar" won't be that helpful
17:56 TimToady well, if someone later grabs 'moar' as a command, will we be unhappy?
17:56 PerlJam FROGGS: sure it will!  How do you think I found that image?  ;)
17:57 FROGGS PerlJam: yeah, if you are searching for funny images :o)
17:58 * grondilu runs 'apt-cache search moar' out of curiosity
17:58 * grondilu got nothing
18:00 TimToady just that once a name in command space is grabbed, it's gone
18:01 flussence_ yeah, same thing happened to ack in debian :(
18:01 grondilu jnthn made a good point when saying in the end we will rarely use moarvm directly.  The name of the executable will be perl6, right?
18:02 grondilu (it's actually "perl6" which is kind of annoying to type, especially with european keyboards where numbers are not directly available)
18:03 TimToady if you want to recompile, sure.  if you have a precompiled executable, maybe not
18:03 TimToady we need to get a little more out of interpreter-think here, I suspect
18:04 * grondilu hadn't thought about that
18:06 grondilu kind of with java.  perl6 would be to moarvm what javac is to java?
18:06 TimToady yeah, and they're runner is 1 char shorter than their compiler :)
18:06 TimToady *thjeir
18:06 TimToady *their
18:06 TimToady *grr
18:27 donaldh joined #moarvm
18:34 jnthn hm, good points
18:34 grondilu if not the excecutable, maybe the file extension could be moar and not moarvm?
18:35 grondilu (or maybe .mvm)
18:36 jnthn Keeping the extension and executable symmetric could be nice...
18:36 jnthn I suspect any 3-letter one will conflict with something else for sure...
18:36 jnthn moar foo.moar
18:36 jnthn Guess that doesn't look so bad :)
18:37 grondilu but then people out of #perl6 will think we're just fooling around.
18:37 * TimToady already got tired of typing moarvm nqp.moarvm :)
18:40 FROGGS how is that goind btw?
18:40 jnthn So create yourself an nqp.bat
18:40 jnthn uh, I mean... :)
18:42 lizmat .moa does not seem taken
18:43 grondilu moa is the name of a giant extinct bird.  would sound weird.
18:43 TimToady but .mvm is already "MAGIX PhotoStory Slideshow"
18:43 TimToady whatever that is...
18:45 jnthn Oh, MAGIX spam me sometimes, I dont' mind trampling on them :P
18:45 TimToady do you really want to be confused with them then?
18:45 FROGGS grondilu: why not take the name of a bird? :P
18:46 TimToady that doesn't seem like a rhea good idea
18:46 TimToady .oO(emu-lation)
18:47 grondilu .moa seems really unfair to the left-out 'r'
18:47 grondilu (if you see what I mean.)
18:47 not_gerd .oO( change .pbc to .dodo )
18:47 TimToady use .mⶊr
18:49 lizmat not_gerd: ;-)
18:50 TimToady .norweiganblue
18:51 TimToady *norwegian even
19:32 jnthn .tell diakopter in SCRef there's an empty void MVM_sc_gc_mark_body(MVMThreadContext *tc, MVMSerializationContextBody *sc, MVMGCWorklist *worklist) { } that looks like accidental leftbehind?
19:33 jnthn ...aww, no msgbot?
19:38 jnthn diakopter: It's in the .h too
19:39 diakopter ?
19:39 diakopter oopsie.
19:40 diakopter fossil of an intermediate form that didn't quite make it
19:47 * jnthn works on the hash_iter thing
19:52 * FROGGS pulls and compiles moarvm while waiting for spectests to swed^Wfinish
19:52 FROGGS (I know that this was lame :o)
19:53 jnthn There's nor way you're making such bad puns on this channel!
19:54 FROGGS *baduum tsss*
19:54 FROGGS :P
20:14 dalek MoarVM: aedb0b1 | jnthn++ | src/ (2 files):
20:14 dalek MoarVM: Enable HLL-configured hash/array iterator types.
20:14 dalek MoarVM:
20:14 dalek MoarVM: Gets hash iteration with .key working.
20:14 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/aedb0b120f
20:15 dalek MoarVM: 034a0b0 | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
20:15 dalek MoarVM: Revert "Don't rely on a Parrotism."
20:15 dalek MoarVM:
20:15 dalek MoarVM: It wasn't one after all, just missing hash iterator setup.
20:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/034a0b093e
20:19 jnthn Hm, having the line numbers really would start being handy now :)
20:20 diakopter yes
20:21 jnthn Now somewhere in moarop_mapper I get "This representation (VMArray) does not support associative access" :)
20:21 diakopter whee :)
20:23 jnthn um, and I think it may be a legit error
20:23 diakopter legit meaning..
20:23 diakopter the source is wrong?
20:24 jnthn oh, no
20:24 jnthn hmm
20:25 jnthn Not immediately sure what's wrong
20:25 diakopter yeah we need line numbers
20:25 diakopter if you make the compiler inject 'em I can do the resolution/backtracing
20:26 jnthn Hm, I probably can do that.
20:26 jnthn (injecting 'em)
20:26 diakopter k. I don't remember if bytecode.c is even parsing them
20:28 crab2313 joined #moarvm
20:30 jnthn We'll find out soon enough :)
20:31 diakopter oh yeah, that's what I was going to do..
20:31 diakopter hm, I had some complex lazy back-resolution system planned out for these offsets
20:32 diakopter I guess the bytecode verifier will have to resolve them since it's the only thing that knows the instruction offsets anyway
20:32 diakopter also, it needs to validate the annotation anyway
20:32 jnthn Well, but we only need them if there's an error
20:32 jnthn Not really?
20:32 jnthn I'd rather not waste cycles on them as in the common case we never use them.
20:33 diakopter yeah they could be out of bounds
20:33 lizmat callframe may need them ?
20:33 diakopter I guess, but the resolver is going to look an awful lot like the verifier
20:33 jnthn lizmat: My "common case" argument still stands :P
20:33 diakopter well the verifier can at least cache the instruction offsets; no loss there
20:33 lizmat true, just wanted to point out that they could be needed in cases other than errors
20:34 jnthn Sure. :)
20:34 jnthn diakopter: Well, memory loss :)
20:34 jnthn diakopter: But maybe we want those for other things...
20:34 diakopter yeah prob
20:35 diakopter or as all my west indies compadres are wanton to say, prolly
20:35 diakopter er, wonton, even
20:35 * diakopter cracks himself up
20:36 dalek MoarVM: 1256560 | jnthn++ | nqp-cc/src/QASTCompilerMAST.nqp:
20:36 dalek MoarVM: Start annotating line numbers.
20:36 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1256560953
20:36 jnthn diakopter: Your turn :)
20:36 diakopter ack
20:36 jnthn (yes, I used --dump to verify they make it in there :))
20:36 diakopter guess I should launch an editor
20:36 diakopter wait, I didn't know dump showed those
20:36 diakopter who added that
20:36 jnthn You :P
20:36 diakopter WAT.
20:36 diakopter no way..
20:37 TimToady denmark who really did it
20:37 jnthn I guess you wrote t/moar/annotated.t too? :)
20:37 diakopter F.
20:37 diakopter sure enough, it resolves the instruction offsets and everything.
20:38 diakopter quadratic algorithm, but still
20:38 diakopter *facepalm*
20:38 jnthn Oh, that's why the dump took less than a second to produce it's 4MB output :P
20:38 TimToady just don't facepalm and headdesk at the same time
20:39 diakopter *kneetableleg*
20:40 TimToady that might be quadralytic
20:41 dalek MoarVM: 5862ca4 | (Tobias Leich)++ | nqp-cc/t/nqp/75-curcode.t:
20:41 dalek MoarVM: run t/nqp/75.t, because we can
20:41 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5862ca4685
20:42 jnthn ...what more excuse do we need? :)
20:43 diakopter hunh.. my naive implementation of that seems to "work"
20:43 TimToady btw, is it expected that threads.t segfault?  been doing it consistently here
20:43 diakopter maybe I should write (or at least run) a test one of these days
20:43 jnthn TimToady: Well, we didn't exactly plan for it... :)
20:43 jnthn TimToady: But yes, you're not the only one seeing that.
20:43 diakopter the previous non-segfault error was just a flue anyway
20:43 diakopter er, grue.
20:43 diakopter er, flukeworm
20:43 diakopter er, fluke
20:45 TimToady It is dark.  If you proceed, you are likely to be eaten by a flue^Wgrue^Wflukeworm^?^?^?^?.
20:45 diakopter (it should've segfaulted before; it's only an accident of memory corruption it dien't)
20:45 dalek MoarVM: 7da6551 | jnthn++ | nqp-cc/src/QASTCompilerMAST.nqp:
20:45 dalek MoarVM: Annoate filename too.
20:45 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7da6551214
20:46 diakopter jnthn: I really am working on this. I sewar.
20:47 * TimToady is feeling drained
20:47 diakopter at least you're not feeling sepsis
20:47 diakopter er.
20:47 diakopter you get it.
20:47 TimToady is that one after sexsis?
20:48 lizmat octis? nonis?
20:48 diakopter oh gosh. I was thinking of another connotation
20:49 TimToady Only French is allowed to have double entendres.
20:49 tadzik hahaha
20:49 tadzik 'make install' will install MoarVM Cross Compiler.
20:49 tadzik make: *** No rule to make target `install'.  Stop.
20:49 diakopter yeah that's a cake
20:50 jnthn nqp-cc will go away eventually :)
20:50 TimToady you'll need a better portal gun for that
20:50 TimToady or a helpful computer
20:51 diakopter jnthn: visual studio always shows the *next* line of execution in stacktraces. which do we do
20:52 diakopter well I guess I'm thinking of the debugger
20:52 diakopter so, nm
20:52 jnthn Current line
20:53 diakopter do we show phantom call frames such as fake ones injected by the continuation mechanism
20:55 jnthn The cont mechanism doesn't make fake frames iirc
20:55 jnthn Just attaches the return handler thingy
20:55 jnthn oh, I think I tracked down the problem...
20:59 diakopter jnthn++
20:59 jnthn Parrot is a bit laxer than Moar or JVM on hash vs array indexing...
21:01 jnthn ...so we got lucky. Got a patch I think...
21:06 dalek MoarVM: bd38509 | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
21:06 dalek MoarVM: Avoid trying to existskey the $allops array.
21:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bd38509b47
21:06 jnthn And now we...segfault!
21:06 benabik \o/
21:07 benabik wait....  /o\
21:07 diakopter ergh
21:07 diakopter well, that's better than.. not making it to the code that segfaults?
21:08 TimToady /o/
21:08 jnthn aye
21:08 FROGGS jnthn: didnt you mix up $bankish and $bank?
21:09 FROGGS (just from reading the snippit I see in the commit)
21:09 jnthn FROGGS: no
21:09 FROGGS good :o)
21:09 jnthn bizzarely when I run it under the debugger it complains about the apr_file_close(file_handle); call
21:09 FROGGS ahh, now I see
21:09 jnthn In the initial MVM_cu_map_from_file
21:09 diakopter that's a heisencat for you
21:10 diakopter need to warm up the heisenberg compensators
21:12 benabik Do heisencats hunt heisenbugs?
21:12 jnthn no, it's a double-close, it seems
21:12 jnthn Oh, it doesn't segfault, it apparently just does nothing...
21:12 diakopter oh actdually
21:12 diakopter I've seen that
21:12 diakopter on msvc
21:13 dalek MoarVM: 799a294 | jnthn++ | src/core/compunit.c:
21:13 dalek MoarVM: Avoid an apparently double-close.
21:13 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/799a29400a
21:13 jnthn s/y//
21:13 diakopter if you double close stdout it segfaults if you're in the console, but not in the VS GUI
21:13 diakopter IDE
21:13 jnthn heh
21:16 jnthn oh...
21:16 jnthn MAIN doesn't get called :)
21:16 jnthn That'd explain why it does nothing.
21:16 diakopter o_O
21:16 diakopter are we about to birth Actual Software?
21:17 jnthn probably not :P
21:17 jnthn I mean, I don't think the actual compile infrastructure is hooked up yet.
21:17 diakopter heh, no. and serialization.
21:17 jnthn You don't need that for self-host
21:17 jnthn Only for bootstrap
21:18 jnthn That is, you only need it when you want it to compile to a bytecode file, not just in memory.
21:18 diakopter oh
21:18 jnthn So we can go some way without that.
21:18 jnthn But will block on it at some point of course
21:19 jnthn Anyway, it's quite exciting that we manage to load and initialize all of NQP, even if we don't land up in MAIN
21:19 diakopter I need to go tot he movie theater to get some MinuteMade strawberry frozen lemonade, aka. my weakness.
21:19 diakopter since my usual source (local hotel) is out of them
21:25 diakopter jnthn: did you review my patch about the SC/compunit loading, or are you prefering not to look :)
21:26 diakopter .oO( or should I not have reminded you? )
21:28 jnthn diakopter: Yes, I whined about that empty leftover function :)
21:29 diakopter o yeah
21:29 diakopter <- surprised no other complaints. it's kinda.. "clever", you might say
21:29 jnthn So was the original thing I did... :S
21:30 diakopter whew, I think
21:30 diakopter lizmat: u feeling better yet? I got over my cold Saturday or so
21:30 jnthn Well, we'll really know when we start eval'in' :)
21:33 lizmat I got over mine more or less today
21:33 lizmat woolfy is still down, but then it only kicked in with her on Sunday
21:43 diakopter wtf did I do in this code
21:44 diakopter somehow I'm using various bytes in this table for different values on different indexes... on different things.
21:44 diakopter er, bits.
21:46 diakopter well I guess it sorta makes sense
21:46 diakopter *shakes head*
21:46 diakopter oh yeah, this was the first thing I ever coded...
21:46 diakopter in this project
21:46 diakopter er, also, in C.
21:51 diakopter jnthn: okay, how do I trigger a stack trace
21:51 lizmat nqp::die ?
21:51 jnthn yes
21:56 donaldh joined #moarvm
22:00 diakopter donaldh: did you find your socks?
22:22 jnthn Will look at the MAIN thing tomorrow
22:22 jnthn 'night
22:23 TimToady o/
22:31 donaldh joined #moarvm
22:39 not_gerd left #moarvm
22:45 eternaleye joined #moarvm
23:00 colomon joined #moarvm
23:15 BenGoldberg joined #moarvm
23:16 Ben_Goldberg joined #moarvm
23:25 dalek MoarVM: 9ad92ba | diakopter++ | src/ (8 files):
23:25 dalek MoarVM: put some of annotations into backtrace.  kinda works, kinda doesn't; not looking into it today.
23:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9ad92ba313

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