github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 3 August 2013.
benabik diakopter: Well, yes, I'm #defining MAP_ANONYMOUS, I was just being lazy typing into IRC. 00:01
Just wasn't sure if there was some platform abstraction thing I should deal with or just do the quick-and-dirty #defining 00:02
diakopter oh :) 00:11
<- no clue
00:26 benabik joined 00:31 colomon joined
benabik Oh, that's new. threads.t now segfaults instead of giving me that can't GC message. 00:35
dalek arVM: 2b5207c | benabik++ | src/platform/posix/mmap.c:
Fix anonymous mmap for Darwin/BSD

OS X (and probably all BSDs) spell the flag for anonymous mmap MAP_ANON instead of Linux's MAP_ANONYMOUS. Until someone else has a more clever idea of how to abstract out this particular platform gotcha, simply #define MAP_ANONYMOUS as MAP_ANON when the latter is available and the former isn't.		 00:40
Heuristic branch merge: pushed 38 commits to MoarVM/libuv5 by zhuomingliang 01:52
02:20 colomon joined
dalek arVM/libuv5: 5698f25 | jimmy++ | build/ (2 files):
enable libuv build
 03:10
diakopter benabik: the previous error was a fluke anyway 03:11
benabik diakopter: I prefer flukes to segfaults? ;-) 03:12
diakopter well at least it didn't format your hard disk :D
benabik :-P
PSA: Have you backed up your development machine lately? 03:13
diakopter is making compunit loading threadsafe 03:15
and closing a big-ish memory leak
diakopter surmises my patch is ready 04:01
hm, nope 04:02
actually I don't really have a way of telling whether my patch regressed or advanced things 04:04
jnthn will have to englighten me tomorrow :)
meanwhile, this backtrace is some kind of beautiful: 04:05
C:\\Users\\mwilson\\src\\MoarVM\\nqp-cc>ptime ..\\moarvm nqp.moarvm -e "1" 04:06
=== ..\\moarvm nqp.moarvm -e "1" ===
cannot stringify this
in frame_name_733, ./QASTMoar.moarvm
in moarop_mapper, ./QASTMoar.moarvm
in add_core_moarop_mapping, ./QASTMoar.moarvm
in frame_name_0, ./QASTMoar.moarvm
in frame_name_1520, ./QASTMoar.moarvm
in frame_name_38, ModuleLoader.class
in load_module, ModuleLoader.class
in frame_name_1666, ./NQPP6QRegexMoar.moarvm
in frame_name_38, ModuleLoader.class
in load_module, ModuleLoader.class
in frame_name_3744, nqp.moarvm
Execution time: 0.036 s
time to add line numbers and source file names to the backtrace 04:08
grondilu you don't use gdb? 04:15
.oO( though I suppose that even with gdb line numbers and source file names would be useful )
 04:16
diakopter gdb? 04:17
it's... not machine code 04:18
grondilu is confused
diakopter maybe I don't understand what you were suggesting 04:19
grondilu well, moarvm can be debugged with gdb, can't it?
diakopter <- never used gdb (obviously)
I use Visual Studio
grondilu oh
diakopter but it knows nothing about our bytecode
grondilu indeed
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
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.
diakopter oh, no.. line nubmers in .nqp source files
grondilu ok
but moarvm has no visibility on the nqp code, has it? 04:21
diakopter I created QAST::Annotated for that purpose
grondilu ok
diakopter well, jnthn spec'd it, but I implemented it
grondilu that would be very useful, then
diakopter similar to parrot's annotations in pir 04:22
..just .. special AST nodes instead
and stored interestingly in the bytecode 04:23
will need to do some interesting back-resolving
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.
diakopter of the offset
offsets
well this is the first time it's running the nqp compiler (any nqp program of substance, anyway) 04:24
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:25
diakopter nah, it's tiny; around one entry per line in the original file, and it's just an integer 04:27
grondilu ok
diakopter so around 8KB for a 1024-line file.. which seems to make a 200KB .moarvm or so
(total)
grondilu: because nqp's instruction set is so gargantuan, its bytecode will be .. much smaller than, say, the corresponding .jar, even compressed 04:31
each of those nqp ops in the jvm bytecode turns into a static method call 04:32
here, it's effectively the same, just encoded much tinier
dalek arVM: 5657ef8 | diakopter++ | src/ (13 files):
- eliminated traversing chain of all compunits loaded when deserializing a serialization context

  - pre-allocate SCBody objects and store them in the weak hash (which is a little less weak now)
  - make compunit loading from disk (by filename) threadsafe and atomic; add a loaded filename registry
  - factor out some of the SC getting code from the two wval nqp:: ops in interp.c		 04:40
arVM: b01dba8 | diakopter++ | src/ (2 files):
work around lack of sc descriptions right now
diakopter benabik: better commit message?
benabik diakopter: Yes, thank you. :-) 04:41
diakopter dares to launch moarvm nqp.moarvm -e "1" when SysMon is running..... O_O 04:44
er, procmon
WAT. 04:45
we, um, may want to dynamically link to some windows system dlls 04:46
benabik How many gigs for -e 1? 04:47
04:47 birdwindupbird joined
diakopter no, it's just it queried a few hundred registry keys regarding tcp socket 04:48
well I guess that took only 3 milliseconds 04:49
well anyway from the time it first read nqp.moarvm to exiting, it was 24 ms 04:50
www.perl6.com/run000.csv 05:00
make sure to open it in something that doesn't mangle the first column values into dates without nanosecond resolution
grondilu trying make nqptest: 05:07
SC not yet resolved; lookup failed in frame_name_59, ModuleLoader.class in frame_name_4, temp.moarvm
diakopter hm 05:08
all of them?
diakopter waits for all the things to emit
grondilu: when did you last git pull? 05:11
(make nqptest is clean for me) 05:12
benabik: looks like loading nqp uses ... 12 MB 05:15
benabik diakopter: nice
diakopter that seems... orders of magnitude smaller than on parrot.. 05:17
._._
_._. 05:18
(surely I'm not measuring correctly)
05:21 ggoebel joined
JimmyZ diakopter: btw, I see some repetitive Callsite in .moarvmdump 05:22
diakopter I noticed that too
grondilu diakopter: few minutes ago 05:24
last commit: 2b5207cb84c89a0e09d3e91b95d3f7b4af3c2c6b
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
maybe you just rebuilt the cross compiler
grondilu reconfigure and rbuilts
(and repulls)
JimmyZ merged master into libuv5, and see a lot of "SC not yet resolved" :P 05:42
diakopter hrm 05:43
mis-merge? :)
JimmyZ no :)
diakopter erm, I hope my commit still exists..
JimmyZ diakopter: last commit in libuv5 is Benabik 05:44
diakopter yer missing some
github.com/MoarVM/MoarVM/commits/master 05:45
JimmyZ merge conflict :( 05:47
dalek arVM/libuv5: 5657ef8 | diakopter++ | src/ (13 files):
- eliminated traversing chain of all compunits loaded when deserializing a serialization context

  - pre-allocate SCBody objects and store them in the weak hash (which is a little less weak now)
  - make compunit loading from disk (by filename) threadsafe and atomic; add a loaded filename registry
  - factor out some of the SC getting code from the two wval nqp:: ops in interp.c		 05:56
arVM/libuv5: b01dba8 | diakopter++ | src/ (2 files):
work around lack of sc descriptions right now
MoarVM/libuv5: c98f981 | jimmy++ | src/ (14 files):
MoarVM/libuv5: Merge remote-tracking branch 'remotes/origin/master' into libuv5
JimmyZ t\\qast\\qast_terms.t Failed test: 2 06:00
much better, and a retrogress 06:01
:P 06:02
grondilu ok all test successful now 06:23
06:23 not_gerd joined
not_gerd o/ 06:23
dalek arVM: a1d0502 | (Gerhard R)++ | src/platform/posix/mmap.c:
Make flag detection for anonymous mmap() more robust.

Probably overkill, but arbitrary flag values can now be supported by adding a definition of MVM_MAP_ANON to build/setup.pm.
not_gerd ^ this can be used as template for other custom platform defines 06:25
benabik not_gerd++
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. :-)
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
that's supposedly deprecated, though 06:29
06:36 crab2313 joined
JimmyZ \\o, not_gerd 06:42
06:50 FROGGS joined
JimmyZ hmm, change compunit to uv_fs_open , cause Bytecode stream corrupt (missing magic string) 07:47
memcmp(cu_body->data_start, "MOARVM\\r\\n", 8) != 0) faied 07:48
07:48 crab2313 joined
benabik Does uv do \\r\\n -> \\n conversion? 07:48
JimmyZ should not , I only open 07:49
benabik Some libraries there's a difference between opening text and binary files. *shrug*
JimmyZ How do I open file with binary flag? 07:50
not_gerd JimmyZ: shouldn't be necessary 07:51
JimmyZ: I've also looked into converting compunit, and it mostly worked
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
not_gerd (the latter might be unrelated)
should I push to libuv5 as-is?
JimmyZ not_gerd: yes
I'm curious what's wrong with my code 07:53
dalek arVM/libuv5: e8c535f | (Gerhard R)++ | src/core/compunit.c:
Switch MVM_cu_map_from_file() from APR to libuv
JimmyZ I still don't know what's wrong :( 07:58
not_gerd does this work for you or still fail? 07:59
JimmyZ I didn't try, I compare the code ,almost the same :( 08:00
you works ! 08:02
and I don't know why :( 08:05
dalek arVM/libuv5: 3db5229 | jimmy++ | src/ (3 files):
code cleanups
 08:14
JimmyZ not_gerd: Yeah, I got new nqp t\\moar\\socket_send_recv.t failure 08:20
but that's apr codes
not_gerd JimmyZ: that doesn't fail for me 08:21
it's qast_terms.t here
I think using uv_hrtime() is wrong for MVM_proc_time_*()
JimmyZ not_gerd: this one seems failed on master also
maybe not
I didn't try :( 08:22
not_gerd uv_hrtime() returns CPU time, not date time
JimmyZ oh
not_gerd uses QueryPerformanceCounter() on windows
we might need to add our own version to platform/ 08:23
JimmyZ yeah
I thought it's date time
Yeah, it is for measuring performance 08:24
I'd not split some dirops.c code to src/platform and include src/platform/dir.h in src/io/dirops.h 08:26
s/not//
not_gerd: how do you think about it? 08:27
not_gerd JimmyZ: makes sense - lots of #ifdef in that file... 08:28
JimmyZ not_gerd: aye
not_gerd: and fileops.c 08:29
08:29 cognominal joined
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
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?
not_gerd jnthn: it's just about switching to the libuv versions of open and stat 08:31
jnthn: the mmap() code was already made libuv-compatible with the merge of my branch
JimmyZ jnthn: and how about uv_read_start, patch it to add a args to return buf, or use callback without return anything?
not_gerd JimmyZ: MVM_dir_open() doesn't set result->body.dir_name in the linux version 08:32
jnthn not_gerd: OK, great.
JimmyZ: Yes, I'd prefer platform-specific bits under src/platform/ 08:33
JimmyZ not_gerd: result->body.dir_name only needs for windows 08:34
not_gerd: windows must use it
not_gerd: linux just opendir :P 08:35
not_gerd: only for "FindFirstFileW(handle->body.dir_name, &ffd);" ) 08:37
jnthn JimmyZ: Should we not just be using uv_fs_read? 08:38
oh, maybe not...
JimmyZ uv_fs_read only fd
others are using uv_read_start, and ipc use uv_read2_start 08:39
s/fd/file/ 08:40
tty use uv_read_start also
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:41
JimmyZ jnthn: I just can't get the buf for reading tty ... 08:43
stdin
I mean I must use uv_read_start for reading tty, but uv_read_start can't return what it reads 08:45
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
jnthn OK, I don't have time to dig more deeply into it now. 08:48
08:48 donaldh joined
JimmyZ jnthn: nodejs.org/api/tty.html#tty_class_readstream has some tips, but I can't understand 08:48
jnthn: OK :)
not_gerd jnthn: do we care about windows support prior to Windows 2000? 08:57
jnthn um, that's be, like, 95, 98 and ME? :) 08:58
FROGGS and 3.11
jnthn lol
FROGGS and NT :o)
could be problematic because of just having 32MB ram though
jnthn Yeah, quite...
not_gerd: So long as it's not impossible for somebody to later send us a patch to support them... :) 08:59
JimmyZ some fileops dirops, should be Windows XP.... 09:00
and for server, should be Windows2003
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
I'm all in favour of using more recent versions of the winapi
JimmyZ yes, what I'm using CreateDirectory for dirops, Minimum supported clientWindows XP 09:04
:P
not_gerd: apr_dir_read() Minimum supported client Windows XP 09:06
09:17 grondilu_ joined
dalek arVM/libuv5: c6f0bb0 | jimmy++ | src/ (3 files):
clean up a bit needless code
 09:25
09:46 grondilu joined
diakopter benabik: ping 09:47
FROGGS: would you like a mini-project? 09:48
(or anyone)
FROGGS diakopter: tell us first :o)
diakopter it's to update libatomic_ops from the repo
our copy is around a year old 09:49
and lots of improvements since then
but the thing is to strip out the gpl stuff
FROGGS ohh 09:50
diakopter jnthn: ping
JimmyZ github.com/ivmai/libatomic_ops this?
diakopter yes
notice I submitted a couple issues there a long time ago 09:51
JimmyZ decommutes
jnthn diakopter: pong, though I'm distracted 09:52
diakopter jnthn: just to say I think my patch was a success
though I got a different result after clean reconfigure, make
kinda odd
jnthn: but anyway I'm happy with the sc/compunit loading mostly now 09:53
jnthn: did you want to do serialization?
if not, should I port it from the java?
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
diakopter: So I will be most happy to have that task stolen :)
diakopter blink at noddy
oh yeah, we discussed this
jnthn diakopter: Steal it from the C impl on Parrot :) 09:55
diakopter oh
jnthn diakopter: You can take a lot of it "as is" :)
tadzik noddy: www.brownbagfilms.com/images/blog/l..._Noddy.jpg
jnthn diakopter: I did that for deserialization. Serialization should be even easier. :)
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?
tadzik heh
diakopter laughs at the reflection in noddy's tassel bell
jnthn diakopter: For now we can just go with the same approach (treat it as a string)
diakopter jnthn: right, so.. in the string heap?? 09:58
jnthn diakopter: But yeah, we can do better eventually...
diakopter: Yes, that's how I started out on JVM. Then sorear++ came up with something better.
diakopter: We could get that in from the start, though.
We gotta support both ways for deserialization for now.
But it'd be nice to avoid all the base-64 screwery. 09:59
diakopter what? you mean base64 isn't consistent everywhere? ;)
jnthn The tests also rely on getting the thing back as a string...
It is, but when I profiled our startup time on Parrot, 15%-20% of startup time was decoding base-64 :/
diakopter yeah well
jnthn tries to get back to reviewing his SOA slides... 10:00
diakopter jnthn: are the Annotated nodes being created now?
jnthn diakopter: Being created? 10:01
diakopter by the compiler
jnthn As in, in QAST -> MAST? Don't think so.
diakopter to mast
oh ok. that would explain why I'm notn seeing them
diakopter feels on kiev time 10:02
jnthn mmmm....kiev
diakopter jnthn: did you read above nqp seems to load on moarvm to ... 12MB ram? and in 24ms?
jnthn "not bad"
Would be happy to lose a bit more of that. 10:03
diakopter O_O
jnthn Like, by skipping the base-64 decoding ;)
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
timotimo if you write that part in C, the compiler can probably turn that into a SIMD instruction 10:06
diakopter o_O
timotimo well, of course only if they are in one region
diakopter yeah but their addresses are from a list 10:07
though that loop could be unrolled into one huge executable... ;)
not_gerd is there a particular reason why MVM_proc_time_i() returns microseconds? 10:08
diakopter well so it be an integer
and have lots of precision
jnthn Yeah but if it doesn't do what the mapped nqp:: is meant to do... :) 10:09
Of course, we can always transform it :)
not_gerd diakopter: millis and nanos are more common in time APIs, I believe
what does nqp want here?
diakopter just change what nqp wants :P 10:10
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
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
like 12x less or something
grondilu still much enough space in int64 in 2100, I think
grondilu execs date +%N
725773342
grondilu execs perl -e 'print log(qx(date +%N)) /log 2' 10:15
27.9658131609481 10:16
oops, that's not all the ns. Please ignore
timotimo r: say :2(725773342) 10:18
not_gerd anyway signed int64 and ns should be good for another ~250 years
timotimo wait, no that's wrong
how do i do that again?
grondilu perl -e 'print log(qx(date +%s%N))/log(2)'
60.2561373693267
grondilu notices there is camelia here as well 10:19
r: say log(qx{date +%s%N}) / log(2)
timotimo it uses the restricted setting, no qx for you ;)
grondilu oh 10:20
timotimo r: say now.Int
much easier than qx(date +%N) or anything like that
also, camelia is having some trouble it seems
r: now.Int.fmt("%b").chars - would give you the number of bits 10:21
jnthn We don't have a camelia in this channel 10:23
timotimo oh, i'm in moarvm? 10:26
yes, that would explain the trouble i'm having :)
10:26 donaldh joined
dalek arVM: 009d5c2 | (Gerhard R)++ | / (7 files):
Back time_i/time_n by custom MVM_platform_now()
 11:09
not_gerd benabik: could you test that on OSX?
JimmyZ not_gerd: I'd like move MVM_proc_time_[i|n] to src/platform/time.h 11:26
not_gerd JimmyZ: I'd like to keep the factoring as it is in master right now 11:28
otherwise, we'd have to back on op by an MVM_platform_ function
on second thought: MVM_proc_time is never stored anywhere, but called directly in core/interp.c 11:30
so we could just get rid of MVM_proc_time_* completely and call MVM_platform_now() directly 11:31
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 arVM: 4a202fd | (Gerhard R)++ | src/platform/ (2 files):
Fix whitespace fail: No, Sir, of course I did not use tabs...
JimmyZ #include "platform/time.h" in src/procops.h
not_gerd I think jnthn will be sad if something called MVM_proc_* is defined in platform/ 11:35
jnthn He may just :) 11:39
11:39 colomon joined
jnthn Note that there's time_i and time_n ops, but they may well source their informatoin from the same call. 11:40
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
not_gerd JimmyZ: exactly 11:49
jnthn Maybe, or they call functions that use the single MVM_platform_ call.
not_gerd jnthn: that's what they do right now, but JimmyZ doesn't like the indirection
not_gerd is off hunting and gathering
JimmyZ We can call MVM_platform_ everywhere in MoarVM :) 11:53
jnthn It's desirable that ops in the interpreter stay simple. 11:55
not_gerd jnthn: it's about `MVM_proc_time_n(tc)` vs `MVM_platform_now() / 1e9` 11:58
12:15 cognominal joined 12:39 donaldh joined
JimmyZ diakopter: ping? 12:43
lizmat JimmyZ: I would hope for diakopter that he's asleep (at 5:45am his time) 12:47
JimmyZ oh 12:48
jnthn With diakopter, you can never be sure... :) 12:49
JimmyZ aye
so I just copy github.com/ivmai/libatomic_ops to Moar
MoarVM master?
jnthn No 12:50
You have to strip out the GPL bits...
JimmyZ GPL ? 12:51
jnthn The stuff in the repo is under different licenses. 12:52
Please wait for diakopter to provide details rather than guessing
JimmyZ ok :) 12:53
13:06 brrt joined
lizmat that's why I said "I would hope" :-) 13:08
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
and i saw something of which i thought i could be of some help
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:10
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? :)
brrt both (muhahaha)
doesn't really matter jnthn
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
It does really matter. :)
brrt noted. but this isn't a complex algorithm we are talking about
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 :)
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
jnthn Well, yeah. We already have write barriers to worry about.
brrt fair point
oh, but if you already have write barriers
jnthn Concurrent GC algos can also add read barriers to the mix.
brrt then it complicates nothing further
jnthn Which I'm fairly keen to avoid.
brrt because it in fact relies solely on write barriers for consistency 13:16
13:16 flussence_ joined
jnthn The other thing about concurrent is it *tends to* give lower pause time at the cost of lower throughput... 13:16
13:16 hoelzro_ joined
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)
brrt that is true, but, as far as i know, nobody has ever tried a generational-concurrent hybrid
13:17 colomon joined
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)
lizmat TimToady: and why not ? :-) 13:19
nwc10 Yes, first implement all Rosetta Code examples, and *then* make them run fast. :-)
TimToady gamers don't like the GC pausing their game at random times
13:20 eternaleye_ joined
lizmat TimToady: but game developers really need more -Ofun! games.slashdot.org/story/13/08/16/1...usive-fans 13:21
TimToady hates loud fans too :)
my current machine is pretty quiet though :) 13:22
13:28 benabik joined 13:32 colomon joined, dalek joined
nwc10 TimToady: this does make me think of dilbert.com/strips/comic/1995-04-03/ 13:33
13:51 benabik joined 14:45 cognominal joined 14:55 FROGGS joined 15:28 benabik joined 16:51 benabik joined 17:28 donaldh joined 17:48 donaldh joined
TimToady is there any reason the executable for moarvm shouldn't just be 'moar'? 17:48
PerlJam 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
Is there any reason why it should just be 'moar'? lolz aside :P 17:52
TimToady lolz are important too :) 17:53
but yes, I'd expect it'd usually get invoked as 'perl6' or some such :)
maybe we should grab p6 while we can :) 17:54
FROGGS and if you need google's help, searching for "moar" won't be that helpful 17:55
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? ;)
FROGGS PerlJam: yeah, if you are searching for funny images :o) 17:57
grondilu runs 'apt-cache search moar' out of curiosity 17:58
grondilu got nothing
TimToady just that once a name in command space is grabbed, it's gone 18:00
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?
(it's actually "perl6" which is kind of annoying to type, especially with european keyboards where numbers are not directly available) 18:02
TimToady if you want to recompile, sure. if you have a precompiled executable, maybe not 18:03
we need to get a little more out of interpreter-think here, I suspect
grondilu hadn't thought about that 18:04
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 :)
*thjeir
*their
*grr
18:27 donaldh joined
jnthn hm, good points 18:34
grondilu if not the excecutable, maybe the file extension could be moar and not moarvm?
(or maybe .mvm) 18:35
jnthn Keeping the extension and executable symmetric could be nice... 18:36
I suspect any 3-letter one will conflict with something else for sure...
moar foo.moar
Guess that doesn't look so bad :)
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 :)
FROGGS how is that goind btw? 18:40
jnthn So create yourself an nqp.bat
uh, I mean... :)
lizmat .moa does not seem taken 18:42
grondilu moa is the name of a giant extinct bird. would sound weird. 18:43
TimToady but .mvm is already "MAGIX PhotoStory Slideshow"
whatever that is...
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?
FROGGS grondilu: why not take the name of a bird? :P
TimToady that doesn't seem like a rhea good idea 18:46
.oO(emu-lation)
grondilu .moa seems really unfair to the left-out 'r' 18:47
(if you see what I mean.)
not_gerd
.oO( change .pbc to .dodo )
TimToady use .mā¶Šr
lizmat not_gerd: ;-) 18:49
TimToady .norweiganblue 18:50
*norwegian even 18:51
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:32
...aww, no msgbot? 19:33
diakopter: It's in the .h too 19:38
diakopter ? 19:39
oopsie.
fossil of an intermediate form that didn't quite make it 19:40
jnthn works on the hash_iter thing 19:47
FROGGS pulls and compiles moarvm while waiting for spectests to swed^Wfinish 19:52
(I know that this was lame :o)
jnthn There's nor way you're making such bad puns on this channel! 19:53
FROGGS *baduum tsss* 19:54
:P
dalek arVM: aedb0b1 | jnthn++ | src/ (2 files):
Enable HLL-configured hash/array iterator types.

Gets hash iteration with .key working.		 20:14
arVM: 034a0b0 | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
Revert "Don't rely on a Parrotism."

It wasn't one after all, just missing hash iterator setup.		 20:15
jnthn Hm, having the line numbers really would start being handy now :) 20:19
diakopter yes 20:20
jnthn Now somewhere in moarop_mapper I get "This representation (VMArray) does not support associative access" :) 20:21
diakopter whee :)
jnthn um, and I think it may be a legit error 20:23
diakopter legit meaning..
the source is wrong?
jnthn oh, no 20:24
hmm
Not immediately sure what's wrong 20:25
diakopter yeah we need line numbers
if you make the compiler inject 'em I can do the resolution/backtracing
jnthn Hm, I probably can do that. 20:26
(injecting 'em)
diakopter k. I don't remember if bytecode.c is even parsing them
20:28 crab2313 joined
jnthn We'll find out soon enough :) 20:30
diakopter oh yeah, that's what I was going to do.. 20:31
hm, I had some complex lazy back-resolution system planned out for these offsets
I guess the bytecode verifier will have to resolve them since it's the only thing that knows the instruction offsets anyway 20:32
also, it needs to validate the annotation anyway
jnthn Well, but we only need them if there's an error
Not really?
I'd rather not waste cycles on them as in the common case we never use them.
diakopter yeah they could be out of bounds 20:33
lizmat callframe may need them ?
diakopter I guess, but the resolver is going to look an awful lot like the verifier
jnthn lizmat: My "common case" argument still stands :P
diakopter well the verifier can at least cache the instruction offsets; no loss there
lizmat true, just wanted to point out that they could be needed in cases other than errors
jnthn Sure. :) 20:34
diakopter: Well, memory loss :)
diakopter: But maybe we want those for other things...
diakopter yeah prob
or as all my west indies compadres are wanton to say, prolly 20:35
er, wonton, even
diakopter cracks himself up
dalek arVM: 1256560 | jnthn++ | nqp-cc/src/QASTCompilerMAST.nqp:
Start annotating line numbers.
 20:36
jnthn diakopter: Your turn :)
diakopter ack
jnthn (yes, I used --dump to verify they make it in there :))
diakopter guess I should launch an editor
wait, I didn't know dump showed those
who added that
jnthn You :P
diakopter WAT.
no way..
TimToady denmark who really did it 20:37
jnthn I guess you wrote t/moar/annotated.t too? :)
diakopter F.
sure enough, it resolves the instruction offsets and everything.
quadratic algorithm, but still 20:38
*facepalm*
jnthn Oh, that's why the dump took less than a second to produce it's 4MB output :P
TimToady just don't facepalm and headdesk at the same time
diakopter *kneetableleg* 20:39
TimToady that might be quadralytic 20:40
dalek arVM: 5862ca4 | (Tobias Leich)++ | nqp-cc/t/nqp/75-curcode.t:
run t/nqp/75.t, because we can
 20:41
jnthn ...what more excuse do we need? :) 20:42
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
diakopter maybe I should write (or at least run) a test one of these days
jnthn TimToady: Well, we didn't exactly plan for it... :)
TimToady: But yes, you're not the only one seeing that.
diakopter the previous non-segfault error was just a flue anyway
er, grue.
er, flukeworm
er, fluke
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)
dalek arVM: 7da6551 | jnthn++ | nqp-cc/src/QASTCompilerMAST.nqp:
Annoate filename too.
diakopter jnthn: I really am working on this. I sewar. 20:46
TimToady is feeling drained 20:47
diakopter at least you're not feeling sepsis
er.
you get it.
TimToady is that one after sexsis?
lizmat octis? nonis? 20:48
diakopter oh gosh. I was thinking of another connotation
TimToady Only French is allowed to have double entendres. 20:49
tadzik hahaha
'make install' will install MoarVM Cross Compiler.
make: *** No rule to make target `install'. Stop.
diakopter yeah that's a cake
jnthn nqp-cc will go away eventually :) 20:50
TimToady you'll need a better portal gun for that
or a helpful computer
diakopter jnthn: visual studio always shows the *next* line of execution in stacktraces. which do we do 20:51
well I guess I'm thinking of the debugger 20:52
so, nm
jnthn Current line
diakopter do we show phantom call frames such as fake ones injected by the continuation mechanism 20:53
jnthn The cont mechanism doesn't make fake frames iirc 20:55
Just attaches the return handler thingy
oh, I think I tracked down the problem...
diakopter jnthn++ 20:59
jnthn Parrot is a bit laxer than Moar or JVM on hash vs array indexing...
...so we got lucky. Got a patch I think... 21:01
dalek arVM: bd38509 | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
Avoid trying to existskey the $allops array.
 21:06
jnthn And now we...segfault!
benabik \\o/
wait.... /o\\ 21:07
diakopter ergh
well, that's better than.. not making it to the code that segfaults?
TimToady /o/ 21:08
jnthn aye
FROGGS jnthn: didnt you mix up $bankish and $bank?
(just from reading the snippit I see in the commit) 21:09
jnthn FROGGS: no
FROGGS good :o)
jnthn bizzarely when I run it under the debugger it complains about the apr_file_close(file_handle); call
FROGGS ahh, now I see
jnthn In the initial MVM_cu_map_from_file
diakopter that's a heisencat for you
need to warm up the heisenberg compensators 21:10
benabik Do heisencats hunt heisenbugs? 21:12
jnthn no, it's a double-close, it seems
Oh, it doesn't segfault, it apparently just does nothing...
diakopter oh actdually
I've seen that
on msvc
dalek arVM: 799a294 | jnthn++ | src/core/compunit.c:
Avoid an apparently double-close.
 21:13
jnthn s/y//
diakopter if you double close stdout it segfaults if you're in the console, but not in the VS GUI
IDE
jnthn heh
oh... 21:16
MAIN doesn't get called :)
That'd explain why it does nothing.
diakopter o_O
are we about to birth Actual Software?
jnthn probably not :P 21:17
I mean, I don't think the actual compile infrastructure is hooked up yet.
diakopter heh, no. and serialization.
jnthn You don't need that for self-host
Only for bootstrap
That is, you only need it when you want it to compile to a bytecode file, not just in memory. 21:18
diakopter oh
jnthn So we can go some way without that.
But will block on it at some point of course
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.
since my usual source (local hotel) is out of them
jnthn: did you review my patch about the SC/compunit loading, or are you prefering not to look :) 21:25
.oO( or should I not have reminded you? )
 21:26
jnthn diakopter: Yes, I whined about that empty leftover function :) 21:28
diakopter o yeah 21:29
<- surprised no other complaints. it's kinda.. "clever", you might say
jnthn So was the original thing I did... :S
diakopter whew, I think 21:30
lizmat: u feeling better yet? I got over my cold Saturday or so
jnthn Well, we'll really know when we start eval'in' :)
lizmat I got over mine more or less today 21:33
woolfy is still down, but then it only kicked in with her on Sunday
diakopter wtf did I do in this code 21:43
somehow I'm using various bytes in this table for different values on different indexes... on different things. 21:44
er, bits.
well I guess it sorta makes sense 21:46
*shakes head*
oh yeah, this was the first thing I ever coded...
in this project
er, also, in C.
jnthn: okay, how do I trigger a stack trace 21:51
lizmat nqp::die ?
jnthn yes
21:56 donaldh joined
diakopter donaldh: did you find your socks? 22:00
jnthn Will look at the MAIN thing tomorrow 22:22
'night
TimToady o/ 22:23
22:31 donaldh joined 22:39 not_gerd left 22:45 eternaleye joined 23:00 colomon joined 23:15 BenGoldberg joined 23:16 Ben_Goldberg joined
dalek arVM: 9ad92ba | diakopter++ | src/ (8 files):
put some of annotations into backtrace. kinda works, kinda doesn't; not looking into it today.
 23:25

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!