github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 3 August 2013.
diakopter pretty close to all 00:00
Ben_Goldberg As a rough %
diakopter more than 95% for sure
and the remaining ones are relatively small
Ben_Goldberg Cool :)
diakopter Ben_Goldberg: are you thinking of undertaking a port? 00:05
Ben_Goldberg I wish I had enough time and skill for that... 00:06
I was just curious about what would be needed for someone who was planning on porting
JimmyZ Good morning 00:08
diakopter JimmyZ: hi :) 00:11
JimmyZ hi 00:12
how cc is going :P 00:15
01:36 FROGGS_ joined 03:01 colomon joined
dalek arVM/libuv1: 5d2fce9 | jimmy++ | src/ (7 files):
re-implemented MVM_dir_open/MVM_dir_read function, only for windows now
 04:15
04:27 grondilu joined
dalek arVM/libuv1: 7383cf8 | jimmy++ | / (7 files):
fixed bugs, passed t\\moar\\dirs.t again on windows
 06:05
arVM/mmap: 984b7c6 | jnthn++ | nqp-cc/src/ops/mvmcc.ops:
Make sure we get null-terminated filename.
arVM/configure: 5cdf3b1 | jnthn++ | nqp-cc/src/ops/mvmcc.ops:
Make sure we get null-terminated filename.
 06:06
arVM/libuv1: 32225e4 | jimmy++ | src/io/ (2 files):
improved error message output for file ops and directory ops
 06:14
arVM/libuv1: 6c9d5f3 | jimmy++ | src/io/dirops.c:
removed needless codes in MVM_dir_open
 06:19
arVM/configure: 4c7c21b | (Gerhard R)++ | / (2 files):
put feature detection into build/auto.pm
 06:41
06:56 lizmat joined
dalek arVM/libuv1: fd981c9 | jimmy++ | src/ (3 files):
added a posix version for MVM_dir_open/MVM_dir_read/MVM_dir_close
 07:16
JimmyZ yeah, left part is only socket 07:17
not_gerd: how about split win32/posix codes from src/io/ to src/platform/ ? 07:32
07:44 FROGGS_ joined
FROGGS o/ 07:45
dalek arVM/libuv1: a701803 | jimmy++ | src/io/dirops.c:
small fixes for using Windows GetFullPathNameW API
 08:07
arVM/libuv5: 5d2fce9 | jimmy++ | src/ (7 files):
re-implemented MVM_dir_open/MVM_dir_read function, only for windows now
 08:24
arVM/libuv5: 7383cf8 | jimmy++ | / (7 files):
fixed bugs, passed t\\moar\\dirs.t again on windows
arVM/libuv5: 32225e4 | jimmy++ | src/io/ (2 files):
improved error message output for file ops and directory ops
arVM/libuv5: 6c9d5f3 | jimmy++ | src/io/dirops.c:
removed needless codes in MVM_dir_open
JimmyZ not_gerd: ping 08:49
09:19 not_gerd joined
not_gerd JimmyZ: pong 09:19
JimmyZ not_gerd: for rand(), which one do you suggest? 09:20
I know PHP mt_rand is using www.math.sci.hiroshima-u.ac.jp/~m-m...37ar-cok.c 09:22
and there is a faster www.math.sci.hiroshima-u.ac.jp/~m-m...SFMT/#SFMT
but mt19937ar-cok.c looks like much easy. 09:23
not_gerd JimmyZ: I'd go with the simpler code for now 09:24
JimmyZ thinks so
not_gerd we can always upgrade later on, and crypto stuff needs another implementation anyway 09:25
JimmyZ so which file I'd copy genrand_int32() part to? 09:26
:P
procops.c again? 09:27
not_gerd JimmyZ: procops lives in io/ 09:29
should be in core/ or math/, I'd guess
JimmyZ I'm +1 to math 09:32
not_gerd BabsSeed: did you ever gert around to setting up a testing environment?
JimmyZ wait ask jnthn :P
we need [0,1] or [0,1)? 09:34
I think [0,1]?
not_gerd JimmyZ: I believe [0,1) is more common 09:36
JimmyZ [0,1) means not contains 1? 09:37
not_gerd JimmyZ: yes
I just did a quick check: Javascript, Python, Perl5 both exclude the upper bound 09:38
JimmyZ thanks
not_gerd s/both/all/
JimmyZ great
So I'd leave sockect to others, I really don't want to touch it :P 09:40
grondilu wonders what is the probability of rand returning exactly 0
.oO( got to be 2**(-N) where N is the number of bits in a floating point mantisse or something)
 09:42
.oO( so it should really not matter if 1 is included or not )
 09:43
not_gerd grondilu: if you want to map to integers, it affects the rounding mode to use 09:44
JimmyZ not_gerd: how about split win32/posix codes from src/io/ to src/platform/ ? 09:46
in libuv5 branch :) 09:47
not_gerd JimmyZ: probably a good idea
JimmyZ :P
jnthn: how about importing www.math.sci.hiroshima-u.ac.jp/~m-m...37ar-cok.c to src/math ? 09:49
not_gerd needs to be changed to use the proper sized types, though 09:51
long can be either 32 or 64 bits
(on common architectures)
JimmyZ is not good at it :(
jnthn What are we importing this for? 09:52
not_gerd jnthn: backing rand() with a mersenne twister
jnthn Why are the rand calls in the C standard library not good enough for us? 09:53
nwc10 ANSI only guarantees 15 bits.
jnthn nwc10: What does Perl 5 do?
nwc10 Perl 5 is likely to switch to using a drand48 (or whatever it is) from *BSD
had been using the best C rand function available, which sucks on Win32 09:54
MT is *probably* also reasonable
but I don't see why Rakudo should be using C code
this is a numeric algorithm - a JIT should love it given type annotated NQP
so, really, my question would be - why does this need to be implemented in C? 09:55
jnthn It doesn't need to be implemented at all if we nab existing code. :)
nwc10 free as in puppies 09:56
JimmyZ mersenne twister is about 4x faster than rand(), and better
nwc10 as in, you pay the maint cost down the line
JimmyZ PHP is using it :)
jnthn I'm not sure "PHP does X" is ever an excuse for anything :P 09:57
nwc10 perl 5 rand() ends up needing state per ithread
and MT has a lot of state
JimmyZ So I just remove MVM_proc_rand API?
jnthn JimmyZ: No, just implement it in terms of the standard C functions for now.
nwc10 so, if you're retrofitting it to Perl 5, you need something without massive state, or you need to decide that each ithread is now bigger
jnthn Right, we've tried hard to avoid static things that mutate in MoarVM. This code introduces 4 static things that mutate. That's bad. 09:59
JimmyZ jnthn: btw, left part is only libatomic_ops and socket for full switching to libuv
nwc10 the second (sort of) Perl 5 observation was "there is no single right answer" combined with "user can supply own RNG function if wanted" 10:00
jnthn JimmyZ: OK. I started on the libatomic_ops switch yesterday. diakopter++ will do a libatomic_ops upgrade that will unblock the rest.
not_gerd ny default, the mt code JimmyZ linked to keeps about ~2.5k bytes of state 10:01
*by
JimmyZ nice 10:05
nwc10 if I understand it correctly, the Mersenne Twister by design does need that sort of amount of state 10:06
jnthn State is never nice...
nwc10 drand48() needs a heck of a lot less
that's one of the axes in the trade off - size of state vs "random"ness 10:07
10:07 crab2313 joined
jnthn It's funny how remembering more things makes you more random in the future :P 10:07
nwc10 :-)
not_gerd well, if #os-threads ~ O(#cpus), it won't be that bad
needs some design decisions, though 10:08
jnthn Well, it's #cores really, and that number will probably continue to grow 10:13
And to put 2.5kb into perspective, if you subtract out the space allocated for the nursery and the system stack space, then the data structures we already keep per thread may be less than 2.5KB :P 10:14
not_gerd on an unrelated note, I pulled out the feature-detection out of my Configure.pl 10:19
I don't see any more obvious improvements there
jnthn not_gerd: Works for me. 10:21
not_gerd: It's the big hash at the top I really wanted out :)
dalek arVM/configure: ec19510 | (Gerhard R)++ | build/setup.pm:
fix search&replace fail
 10:27
11:01 donaldh joined, grondilu joined
not_gerd bye, #moarvm 11:16
11:17 not_gerd left
JimmyZ Is configure branch ready to merge? 11:56
12:15 colomon joined 12:41 birdwindupbird joined 13:47 BenGoldberg joined 14:06 crab2313 joined 14:12 colomon joined 14:43 benabik joined 14:44 colomon joined
jnthn JimmyZ: Maybe; let's see if not_gerd is aware of any outstanding issues. 15:50
JimmyZ jnthn: ok :) 15:59
Good night
jnthn 'night o/ 16:01
16:03 crab2313 joined
diakopter hi 16:03
FROGGS hi diakopter 16:04
jnthn o/ diakopter 16:05
dalek arVM: 3fab09e | jnthn++ | nqp-cc/src/QASTRegexCompilerMAST.nqp:
Fix :dba(...) code generation.
 16:09
FROGGS uhhh, I love to see commits from jnthn++ here :D 16:11
16:14 Guest____ joined
dalek arVM: ad4275a | jnthn++ | nqp-cc/tools/build/Makefile.in:
Add NQPP6QRegex.moarvm to build.
 16:15
jnthn diakopter: OK, that's that next piece taken care of :)
16:25 Guest1337 joined 16:30 dalek joined
jnthn diakopter: Good news: MoarVM seems a good bit more stable on long-running things since your changes, or perhaps other people's changes... :) 16:31
FROGGS cool 16:43
16:48 crab2313 joined 16:50 not_gerd joined
not_gerd o/ 16:50
jnthn: I'm not aware of any issues with the configuration system 16:51
(the mmap stuff could need testing on osx, bsd)
dalek arVM: 8fc69a1 | jnthn++ | src/gc/ (4 files):
Avoid resizing/copying if many gen2 roots.
 17:17
arVM: 940c5bb | jnthn++ | src/6model/reprs/MVMCompUnit.c:
MVMCompUnit doesn't (directly) ref MVMFrames.
diakopter hi 18:05
18:06 crab2313 joined
jnthn hi again :) 18:06
diakopter can't find how to type pgup to this android keyboard, so can't backscroll 18:07
bah; bbiab 18:08
re stable, *whew* 18:18
jnthn: yes a bunch of missing MVMROOT and MVM_ASSIGN_REF 18:21
also in that giant commit
well not a bunch. a few, at least.
jnthn Yeah, that'll need a good review later 18:22
lizmat diakopter++ for delivering code :-)
jnthn I discovered an algorithmic problem in the gen2 roots handling
We don't currently detect the case where all the items an gen2 thing points to are also promoted, so it no longer needs to remain in the roots list. 18:23
diakopter jnthn: I meant I fixed a few I found :)
jnthn diakopter: To clarify, I meant that I think at some point I want to look over All The Code for such things. :)
diakopter jnthn: simply count down from 2 generations and reset it to 2 when it finds another one in the nursery it points to
jnthn hmm 18:24
diakopter er, record the latest gneration in which it found a nursery ref
then on a major collection if it's more than 2 prior, de root it
de-root 18:25
lizmat++ thanks :)
jnthn: I mean, it's ok to last until the next major collection, right?
that would add a word to the size of each gen2 object but that's ok 18:27
jnthn - also the gen2 roots list could be a doubly -linked list through the gen2 area 18:28
or a two-level array with one of your in-line freelists 18:29
actually yeah that's the way to do it
wait, NQPP6QRegex.nap builds !?! 18:30
wow
jnthn yes :) 18:31
I think it's easier to just do the "what just went into the worklist" trick in the process_worklist loop
Same as we do for write-barriering if we promote to gen2 and object that points to nursery 18:32
diakopter oh hm
oh, speaking of which
need to clear the frames worklist before that check at the end 18:33
hm, is compunit->body.pool used at all? 18:35
jnthn Possibly not any more...
18:36 crab2313 joined
diakopter blinks at p6l 18:38
jnthn: can I convert the sc_to_resolve rechanism to another level of indirection 18:51
to eliminate all the linear searches
scs_to_resolve
wait, there's already a weakhash; why not just link to those members, but have their targets null until resolved 18:52
(that is, have an entry in the hash for all sc named handles waiting for resolution) 18:53
jnthn: ^ when you get a chance 18:54
18:59 colomon joined
jnthn How would that cause the compunit tables to get updated? 19:12
diakopter they wouldn't; they'd link through to the corresponding entries in the hash directly 19:15
seem ok? 19:16
jnthn wval resolution is relatively hot-path, which is why I kept a table of resolved SCs to quickly index into there...do you mean a named lookup in the hash or a direct reference? 19:21
diakopter direct pointer to the hash entry struct
jnthn quess that's only one extra LOI 19:22
diakopter saves a bunch of time on deserialization I'd guess
makes the weakhash entries permanent though
well, I suppose they could be GC'd actually; that'd be interesting 19:23
heh. 19:24
actually.
do SCs have only one handle each?
nm, too hard to make sure those never move 19:25
ok, I'll take that as a tentative "ok" 19:33
jnthn Saves a bunch of time? 19:40
We only do the looking up once per module we load... 19:41
The main thing is that SCs can get GC'd when all compunits that refer to them are. 19:42
So long as we end up with that, it's OK
We make sure they don't go away too early by anchoring them right away on creation to compunits that need them.
diakopter saves the time of updating the scs_to_resolve in all the compunits 19:43
jnthn The weakhash is just so compunits loaded later on can find an SC
Yes, I'd be very, very surprised if that's a measurable cost :)
diakopter oh
how many entries in that hash can a given SC have 19:44
jnthn Like, comapred to the rest of deserialization.
diakopter max 1?
jnthn Yes, it's handle -> SC.
dalek arVM: 5e82dad | diakopter++ | src/ (3 files):
implement compunit repr gc_free (doh)
 19:45
19:51 not_gerd left
dalek arVM: cb25b48 | diakopter++ | src/gc/collect.c:
oops, this needs to be before the trick reconciliation
 19:53
arVM: 6806716 | diakopter++ | src/gc/ (2 files):
macro-ize that frame marking thing and add it to another place it needs to be
 20:08
arVM: 2f8b49c | jnthn++ | nqp-cc/nqp-src/NQP.nqp:
Tweak NQP.nqp to get it to mostly build.

Took the JVM-based version rather than the Parrot-based one, which gets rid of the pir::. Tweaked the NQP::Ops bit, but still some bits to add back in the future. Also commented out a section missing an nqp:: op. And with that, we get a NQP.moarvm out.		 20:18
jnthn diakopter: Does that really have to be a macro when a function is probably OK? 20:19
diakopter yeah a function's fine.. 20:20
jnthn: so, have you dared to run NQP.moarvm ? 20:21
jnthn While looking for './QRegex.moarvm': The system cannot find the file specified.
:)
diakopter easily fixed with a Makefile tweak.. 20:22
jnthn yeah, looking into those things at the moment...
diakopter oopsie I broke it 20:23
ergh
jnthn broke...what?
ah, this cross-comp has gone wonky... :)
oh, hmmm... 20:25
dalek arVM: 9dd8b39 | diakopter++ | src/gc/worklist. (2 files):
unbreak the build
diakopter I'm waiting for you guys to merge the configure refactor for me to put in my makefile refactor and dyncall building 20:27
jnthn diakopter: Feel free to give it a test on Windows and merge it if you're happy. 20:28
diakopter: It's only not merged by me 'cus I didn't do that yet.
diakopter which pull request is it anyway
jnthn It's already in the branch
*repo
configure branch
So just git merge configure, then test.
or git checkout configure, test it, git checkout master, then merge... :) 20:29
dalek arVM: 4af81af | (Gerhard R)++ | / (5 files):
import new build system
 20:33
arVM: 7a66dea | (Gerhard R)++ | build/Makefile.in:
add missing objects ot Makefile.in

Start fixing up later part of NQP build a bit.
diakopter dalek: we hardly knew ye
20:34 donaldh joined, dalek joined
diakopter lol; oh; you're already made the sc body objects the hash members 20:43
so, simply need to pre-allocate them 20:44
jnthn: the real problem I'm trying to fix is the chain of compunits, which doesn't really work anymore since they're GC'd
jnthn diakopter: Yes, the original design before they became GC-able is if one never got it's seq number incremented, we'd know it was dead and then just rip it out of the linked list as we traversed it. 20:48
That's a pain now.
diakopter right
jnthn: can I delete the mmap branch? 20:51
jnthn diakopter: Is it merged? 20:52
diakopter I think 20:53
github UI says it's only 1 ahead, and that one ahead I thought was already merged
jnthn Check with not_gerd maybe...
I can't remember if configure included the mmap patches...
diakopter it did have a bunch of mmap stuff 20:54
dalek arVM: 984b7c6 | jnthn++ | nqp-cc/src/ops/mvmcc.ops:
Make sure we get null-terminated filename.
 20:57
arVM: 6605b1a | (Matthew Wilson)++ | /:
Merge pull request #51 from MoarVM/mmap

Make sure we get null-terminated filename.
diakopter meh, merged it anyway
C:\\Users\\mwilson\\src\\MoarVM\\nqp-cc>..\\moarvm nqp.moarvm 21:04
Method operations not found in cache, and late-bound dispatch NYI in frame_name_0, <ephemeral file> in frame_name_3752, <ephemeral file>
jnthn yes, that's the latest error :) 21:05
diakopter woohoo :D
it runneth
jnthn May be a step or so further in a bit
diakopter yeah but it takes 60ms to get to that error
jnthn It basically loads everything except QAST -> MAST 21:06
diakopter parrot nqp takes 74ms to run "1" 21:07
this will be an "interesting" profile in Visual Studio :D :D :D 21:08
21:08 BenGoldberg joined
diakopter oh, that's unoptimized 21:08
jnthn Yeah, default build is unoptimized. 21:09
It makes a fair difference.
diakopter 38ms to get that error, optimized \\o/
jnthn: fyi, I'm fixing that compunit chain thing 21:11
jnthn diakopter: +1 21:12
timotimo my lord, moarvm will be *so fast* 21:24
jnthn Some day... :)
diakopter timotimo: maybe 21:26
I doubt it beats parrot nqp initially 21:27
dalek arVM: 4a11514 | jnthn++ | / (7 files):
Get QAST -> MAST properly into the build.

This pulls it all together into a single QASTMoar.nqp and builds the
  .pbc and then .moarvm. Added code to load it; doesn't survive being
loaded yet, however.		 21:31
arVM: 685bc4b | diakopter++ | src/moarvm.c:
add filename to compunit
 21:44
arVM: 8f05914 | diakopter++ | src/core/compunit.c:
begin fixing the compunit chain
arVM: fd6c056 | diakopter++ | / (7 files):
Merge branch 'master' of github.com:MoarVM/MoarVM
diakopter jnthn: that might help debugging (add filename to compunit) 21:45
dalek arVM: 98efde5 | jnthn++ | nqp-cc/src/QASTOperationsMAST.nqp:
Don't rely on a Parrotism.
jnthn diakopter: Yeah...at some point we'll want line numbers too :)
diakopter jnthn: that op idiom is copy/pasted a couple places 21:46
the one you just patched
jnthn OK 21:47
The next issue I hit is that the HLL configured hash_iter isn't yet respected; it always created BOOTIter.
diakopter I guess it should use the hll of the current compunit? 21:48
jnthn Yeah
Anyway, at least we now have an nqp.moarvm that attempts to start :) 21:49
diakopter wat.
jnthn At this rate we might make self-hosted "hello, world" on Moar before the month is out... 21:54
japhb \\o/ 21:55
diakopter jnthn: can I add the sc handle to the SC not yet resolved error? 21:56
FROGGS that would be awesome :o)
jnthn diakopter: yes]
Probably would help with tracking down such things :) 21:57
diakopter oh, well I'll integrate that into this larger change, so probably won't help you 21:59
jnthn Well, I don't have the problem now... 22:00
I just mean if it comes up in the future it's a better error
diakopter oh; I got that error 22:01
jnthn congrats...
jnthn wonders how :)
diakopter C:\\Users\\mwilson\\src\\MoarVM\\nqp-cc>..\\moarvm nqp.moarvm 22:03
SC not yet resolved; lookup failed in frame_name_59, ModuleLoader.class in frame_name_3744, nqp.moarvm
jnthn With your local patches? 22:04
Here it's "Missing method cache; late-bound dispatch NYI" 22:05
diakopter don't have local patches really 22:08
jnthn Hmm 22:09
You re-configure'd?
jnthn didn't re-build latest moar 22:10
lemme try that
uh
on latest Moar I get that error too :(
I guess that counts as a regression
22:11 donaldh joined
jnthn yeah, you stopped building the compunit chain, so now resolution fails. 22:11
Reverting 8f05914f0c00b9f8bb5082ba01b6c134d6b39945 gets it back to the normal error again 22:12
diakopter oh ok :)
oops
not too far from fixed 22:13
jnthn OK. I'm done hacking Moar for today anyways :)
22:51 donaldh joined 23:14 benabik joined 23:26 colomon joined
benabik Some change to mmap fails on Darwin. 23:48
OS X has MAP_ANON, not MAP_ANONYMOUS
Is there a better way to do it than just #if !def(ANONYMOUS) & def(ANON) #define ANONYMOUS ANON ? 23:51
diakopter benabik: remap MAP_ANONYMOUS instead? 23:59

Powered by Cro and the Raku® Programming Language.

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

Thank you!