Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-01-01

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

All times shown according to UTC.

Time Nick Message
00:09 timotimo jnthn: i think you forgot to push the commit that fixes the i32/i64 problem
01:25 jnap joined #moarvm
02:14 colomon joined #moarvm
02:26 jnap joined #moarvm
02:44 colomon joined #moarvm
03:27 jnap joined #moarvm
03:53 dalek MoarVM: 2890baa | diakopter++ | build/test.txt:
03:53 dalek MoarVM: updated test message
03:53 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2890baa84a
03:53 dalek MoarVM: fe79f4c | diakopter++ | / (72 files):
03:53 dalek MoarVM: Merge branch 'master' of github.com:MoarVM/MoarVM
03:53 diakopter gah.
03:54 dalek joined #moarvm
04:27 jnap joined #moarvm
05:28 jnap joined #moarvm
06:17 ssutch joined #moarvm
06:29 jnap joined #moarvm
07:30 jnap joined #moarvm
08:30 jnap joined #moarvm
08:52 _ilbot joined #moarvm
08:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
09:43 [Coke] moar: "total",     17247, 10877,   285,   790, 28855, 28494?
09:43 timotimo wowza
09:44 [Coke] http://feather.perl6.nl/~coke/moar.out
09:45 [Coke] several todo passed.
09:46 timotimo what kind? we still have the missing support for continuations/proper coroutines
09:47 [Coke] go to that url, search for "todo passed"
09:47 [Coke] I'm back to sleepin'.
09:47 timotimo most of them are probably false positive
09:48 FROGGS [Coke]: sleep well!
09:49 FROGGS timotimo: yeah, I think so too
09:49 FROGGS nqp-m: say("abc" ~~ /./)
09:49 camelia nqp-moarvm: OUTPUT«a␤»
09:50 FROGGS hmmm, I expected to see "abc" here too
09:50 FROGGS nqp-m: say("abc" ~~ /^./)
09:50 camelia nqp-moarvm: OUTPUT«a␤»
09:50 FROGGS weird
10:36 masak diakopter: you can easily avoid that kind of merge commit by doing 'git pull --rebase'
10:36 masak oops, stale backlog.
10:36 masak the kind like fe79f4c.
11:11 masak hm, 3rdparty/dyncall shows up as being modified in 'git status' all the time, without me having touched it.
11:12 masak something wrong there with .gitignore settings?
11:12 masak oh, it's in a submodule.
11:13 FROGGS I have that too but I have no idea what might be wrong
11:16 dalek MoarVM: ee51669 | masak++ | src/gc/wb.h:
11:16 dalek MoarVM: finished sentence in comment
11:16 dalek MoarVM:
11:16 dalek MoarVM: I think I got it right -- review welcome, though.
11:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ee51669698
11:16 * masak enjoys doing small janitorial stuff
11:33 jnap joined #moarvm
11:51 rurban joined #moarvm
11:55 masak this comment doesn't seem to agree with the code: https://github.com/MoarVM/MoarVM/blob/master/src/gc/allocation.c#L46
11:56 masak I might be wrong, but I expected to see a line of code that zeroes the memory that is returned.
12:09 FROGGS hmmm, I can build and install nqp-m
12:26 arnsholt masak: Yeah, I agree
12:33 jnap joined #moarvm
12:57 * masak submits a moarvmissue
13:03 masak I have this plan where I want to build a subset of MoarVM -- just the allocation and GC parts -- and instrument them from the outside.
13:04 masak basically sending in commands like "allocate an object in the nursery", "create a refernce between object X and object Y", "sever all references to object Y", "force a GC run".
13:05 masak my C is not so strong, so I don't know how far I will get. but I look forward to trying.
13:05 arnsholt That sounds interesting. And then we could make a MoarVM torture chamber of sorts, seeing how weird workloads perform and so on
13:06 masak arnsholt: are you familiar with QuickCheck?
13:07 masak arnsholt: I want to implement a simple model of the GC in Perl 6, and then run them alongside, looking for discrepancies.
13:08 masak jnthn: I love how you have C macros to emulate closures in Moar! :)
13:10 arnsholt Oooooh, that's even cleverer!
13:11 arnsholt I used QuickCheck for a tiny Haskell project I did half a year ago or something
13:11 arnsholt That was truly neat
13:12 diakopter masak: actually the memory is guaranteed already zeroed
13:12 diakopter by the last GC run
13:14 masak diakopter: interesting.
13:15 masak diakopter: then why do we have two functions for that?
13:15 masak can't we just kill off the zeroed one?
13:15 masak oh, and by the way, why does the GC waste time zeroing memory as part of freeing it?
13:15 diakopter jnthn said he added those originally to match parot, but then left them in case we noticed that zeroing optionally saves efficiency
13:16 masak also, what about allocation before any GC run? are things still guaranteed to be zeroed?
13:16 diakopter it zeroes as part of freeing currently to help catch errors of referring to poniters in the old space
13:17 masak yes, I understand.
13:17 masak is the memory guaranteed to be zeroed before any GC run?
13:17 masak (and if not, does that matter?)
13:17 diakopter yes, I think the first malloc is either calloc or memset 0
13:17 masak ok.
13:17 * masak closes issue
13:18 masak no, wait.
13:18 masak I still think the comment is *wrong*.
13:18 masak and needs to be changed.
13:18 masak so I'll keep the issue open.
13:18 masak (put pasting this discussion into it)
13:18 diakopter well, you could change the issue to "look into whether zeroing can be made optional, once we're bug-free-ish"
13:18 masak oki
13:19 diakopter and the comment could refer to the issue :)
13:21 * masak makes it so
13:23 dalek MoarVM: 90713bd | masak++ | src/gc/allocation.c:
13:23 dalek MoarVM: refer to issue from comment
13:23 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/90713bd7ca
13:34 jnap joined #moarvm
13:58 masak when I was younger, I used to strongly dislike all kinds of reference cycles.
13:58 diakopter I LIKE TREES
13:58 masak nowadays, I find them quite OK. I'm just making sure they don't escape beyond some established boundary.
13:58 diakopter .. and then you liked trains instead..
13:59 masak :)
14:40 jnthn The comment could convey it better, but the overall idea is that there's one way to get a piece of memory that promises to be zeroed, and another way to get a piece of memory when you don't care what it's state is, 'cus you're going to populate it all anyway.
14:41 FROGGS hi jnthn
14:41 jnthn At present, allocation happens in nursery tospace, which is pre-zeroed. That did make debugging a bunch easier in the earlier days *but* is less cache friendly, so I can imagine us moving the memset to allocation time once we're happy with overall stability.
14:41 jnthn o/ FROGGS
14:55 masak jnthn: understood.
14:55 masak jnthn: for someone reading the source code, it was confusing coming across a comment that said the function did something different, when in fact it didn't.
14:55 jnthn Well, it *does* give back zeroed memory :)
14:55 jnthn But yeah, it could be stated much better.
14:56 masak anyone, feel free to re-jigger the comment some more.
15:00 dalek MoarVM: bebea27 | jonathan++ | src/gc/allocation.c:
15:00 dalek MoarVM: Comment tweak to better explain current situation.
15:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bebea2773a
15:00 dalek MoarVM: ad694b6 | jonathan++ | src/gc/wb.h:
15:00 dalek MoarVM: Correct another comment.
15:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ad694b6228
15:02 nwc10 jnthn: what is supposed to update tc->cur_frame->params.args[0].o when the GC moves it?
15:03 jnthn nwc10: iirc, that just points into the caller's arg buffer
15:03 nwc10 because this line in box_s can trigger a GC run, and that pointer isn't being updated:
15:03 nwc10 MVMObject *box  = REPR(type)->allocate(tc, STABLE(type));
15:04 ssutch joined #moarvm
15:04 jnthn as such, it is meant to be updated by roots.c:287
15:05 jnthn Hmm...it really should be being caught by the thing I just mentioned...unless flattening took place, in whcih case the code at line 312 should do it.
15:05 nwc10 that's adding frame->args
15:05 jnthn Right, but params.args points to the frame->args of the caller unless flattening took place.
15:05 nwc10 the naughty pointer is in frame->params.args
15:06 jnthn And we should certainly walk our way to the caller frame.
15:07 jnthn Does frame->caller->args point to the same location as frame->params.args?
15:07 nwc10 yes
15:08 jnthn And is frame->cur_args_callsite non-null?
15:08 nwc10 NULL
15:08 jnthn oh, ouchy.
15:09 jnthn argh, I think I see what it may be.
15:09 jnthn The calls set up by the CPS mechanism...
15:20 colomon joined #moarvm
15:36 jnap joined #moarvm
15:40 colomon joined #moarvm
15:53 jnthn nwc10: Testing a fix here.
15:54 nwc10 cool
16:01 dalek MoarVM: 80a4be0 | jonathan++ | src/ (6 files):
16:01 dalek MoarVM: Factor out C -> interp call; fix callsite mark bug
16:01 dalek MoarVM:
16:01 dalek MoarVM: This will hopefully deal with a fail-to-mark issue found by nwc10++,
16:01 dalek MoarVM: and factors out some repeated logic.
16:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/80a4be01d5
16:02 jnthn nwc10: Hopefully that helps. Lemme know if not.
16:02 jnthn nwc10: What nursery size are we down to now? :)
16:03 nwc10 oh, 1K built in not-sure-how-long
16:03 nwc10 but most of a day
16:03 jnthn NQP, or Rakudo too?
16:03 nwc10 NQP
16:03 nwc10 this was a hacked-about MoarVM trying to build Rakudo
16:04 nwc10 nursery size 64K, IIRC, but 256 nursery collections before gen2
16:04 nwc10 and 256 * 64K allocated, but all but 64K mapped as no read, no write
16:05 nwc10 so was starting to torture the Rakudo build
16:05 jnthn :)
16:06 nwc10 1K was 17 hours
16:07 jnthn Wow
16:07 nwc10 All tests successful.Files=85, Tests=1909, 3453 wallclock secs ( 0.73 usr  0.22 sys + 10694.21 cusr 19.74 csys = 10714.90 CPU)
16:07 nwc10 gah, terminal eats newlines :-(
16:07 FROGGS newyears, newlines, whatever
16:11 jnthn Well, the inter-generational roots list must get huge with such a small nursery...
16:24 FROGGS jnthn: btw, here are some absurdities I've hit... https://gist.github.com/FROGGS/cbdcd4054a450d0faa22
16:24 FROGGS I tried to hunt them down but without luck so far
16:37 jnap joined #moarvm
17:10 [Coke] FROGGS: here's another one:
17:10 [Coke] r-m: my $a is dynamic; say $a.VAR.dynamic;
17:11 [Coke] (that one segfaults)
17:12 [Coke] the say isn't needed, but the last .dynamic is.
17:13 jnthn Yeah, got some progress on that one here.
17:13 [Coke] jnthn++
17:17 jnthn Arrgh...why does building latest NQP give me "Unhandled exception: Missing or wrong version of dependency 'gen\moar\stage1\QRegex.nqp'"?
17:19 [Coke] here's another segfault: 'Any.exists("a")'
17:19 moritz jnthn: missing dependency, afaict
17:19 moritz jnthn: a 'make clean'
17:19 jnthn I did make clean...
17:19 moritz huh.
17:20 moritz or maybe you need to clean the install location too
17:20 jnthn Reverting 41debf4170 fixes it for me
17:20 jnthn FROGGS?
17:22 [Coke] Another segfault: $/.VAR.default
17:25 jnthn FROGGS: Removing my installed version helped
17:26 jnthn FROGGS: But then building after another make install breaks the build again.
17:28 jnthn FROGGS: Yeah, just adding that path in unconditionally during the bootstrap will bust it. :(
17:32 [Coke] Another segfault: +Mu
17:35 FROGGS huh?
17:36 jnthn FROGGS: It relies on falling back to --libpath=...
17:36 jnthn FROGGS: Whcih no longer happens.
17:36 FROGGS did you reconfigure?
17:36 jnthn Yes.
17:36 FROGGS hmpf
17:36 FROGGS I dont find commit 41debf4170 btw... which repo is that?
17:37 jnthn NQP
17:37 jnthn oops
17:37 jnthn oh, I did get it right
17:37 jnthn commit 41debf41705d3979edaeffb47b804c1d15a1015e
17:37 jnthn Author: Tobias Leich <email@froggs.de>
17:37 jnthn Date:   Tue Dec 31 12:41:18 2013 +0100
17:37 jnthn add nqp language diretory to search path
17:38 FROGGS I meant reconfigure in rakudo...
17:38 FROGGS why does it work for me? ó.ò
17:38 jnthn 'cus you don't have an existing install, maybe?
17:39 FROGGS I have... like always
17:40 jnthn OK, then...I dunno
17:40 jnthn I'm surprised you don't get breakage too
17:40 jnthn for me, a make install of NQP, then make clean, then make, and it blows up after a bit
17:47 FROGGS I'll check in a bit
18:05 diakopter hi
18:38 jnap joined #moarvm
18:53 colomon joined #moarvm
19:53 cognominal joined #moarvm
20:03 [Coke]_ joined #moarvm
20:05 FROGGS_ joined #moarvm
20:07 cognominal__ joined #moarvm
20:09 sorear_ joined #moarvm
20:40 jnap joined #moarvm
20:56 harrow joined #moarvm
21:00 dalek MoarVM: 560c0b4 | jonathan++ | src/ (2 files):
21:00 dalek MoarVM: Clean up bogus container-related code.
21:00 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/560c0b4cae
21:28 jnap joined #moarvm
21:29 jnap1 joined #moarvm
22:09 dalek MoarVM: 2568495 | jonathan++ | src/core/ (2 files):
22:09 dalek MoarVM: Bring getlexrel in line with expected behavior.
22:09 dalek MoarVM:
22:09 dalek MoarVM: Fixes PseudoStash.exists_key in some cases, and thus the spectests
22:09 dalek MoarVM: that depend on it.
22:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2568495316
22:18 dalek MoarVM: 99cc82d | jonathan++ | src/core/args.h:
22:18 dalek MoarVM: Expose MVM_args_setup_thunk.
22:18 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/99cc82dc6d
22:53 arnsholt joined #moarvm
23:01 jnap joined #moarvm
23:55 * grondilu tries to compile moarkudo
23:55 grondilu Unhandled exception: While looking for 'ModuleLoader.moarvm': no such file or directory
23:55 grondilu ^what am I missing?
23:56 timotimo that's why froggs has been working on supplying multiple --libpath commandline args
23:57 FROGGS_ grondilu: just make sure you pulled MoarVM, nqp and rakudo
23:57 FROGGS_ and reconfigure, to get proper makefiles
23:58 timotimo i'm almost finished getting my p6sort for moarvm finished
23:58 FROGGS_ very cool
23:58 grondilu I ran 'perl Configure.pl --gen-nqp --backends=moar --gen-moar', shouldn't that pull everything?
23:58 timotimo tomorrow, i may implement timsort instead of mergesort
23:59 timotimo afaict, that's the "state of the art" for merge-sort-like sorting
23:59 FROGGS_ grondilu: perl Configure.pl --gen-nqp=master --backends=moar --gen-moar=master

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