timotimo jnthn: i think you forgot to push the commit that fixes the i32/i64 problem 00:09
01:25 jnap joined 02:14 colomon joined 02:26 jnap joined 02:44 colomon joined 03:27 jnap joined
dalek arVM: 2890baa | diakopter++ | build/test.txt:
updated test message
 03:53
arVM: fe79f4c | diakopter++ | / (72 files):
Merge branch 'master' of github.com:MoarVM/MoarVM

finished sentence in comment
I think I got it right -- review welcome, though.
diakopter gah.
03:54 dalek joined 04:27 jnap joined 05:28 jnap joined 06:17 ssutch joined 06:29 jnap joined 07:30 jnap joined 08:30 jnap joined 08:52 _ilbot joined
[Coke] moar: "total", 17247, 10877, 285, 790, 28855, 28494? 09:43
timotimo wowza
[Coke] feather.perl6.nl/~coke/moar.out 09:44
several todo passed. 09:45
timotimo what kind? we still have the missing support for continuations/proper coroutines 09:46
[Coke] go to that url, search for "todo passed" 09:47
I'm back to sleepin'.
timotimo most of them are probably false positive
FROGGS [Coke]: sleep well! 09:48
timotimo: yeah, I think so too 09:49
nqp-m: say("abc" ~~ /./)
camelia nqp-moarvm: OUTPUTĀ«aā¤Ā»
FROGGS hmmm, I expected to see "abc" here too 09:50
nqp-m: say("abc" ~~ /^./)
camelia nqp-moarvm: OUTPUTĀ«aā¤Ā»
FROGGS weird
masak diakopter: you can easily avoid that kind of merge commit by doing 'git pull --rebase' 10:36
oops, stale backlog.
the kind like fe79f4c.
hm, 3rdparty/dyncall shows up as being modified in 'git status' all the time, without me having touched it. 11:11
something wrong there with .gitignore settings? 11:12
oh, it's in a submodule.
FROGGS I have that too but I have no idea what might be wrong 11:13
masak enjoys doing small janitorial stuff
11:33 jnap joined 11:51 rurban joined
masak this comment doesn't seem to agree with the code: github.com/MoarVM/MoarVM/blob/mast...tion.c#L46 11:55
I might be wrong, but I expected to see a line of code that zeroes the memory that is returned. 11:56
FROGGS hmmm, I can build and install nqp-m 12:09
arnsholt masak: Yeah, I agree 12:26
12:33 jnap joined
masak submits a moarvmissue 12:57
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:03
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:04
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
masak arnsholt: are you familiar with QuickCheck? 13:06
arnsholt: I want to implement a simple model of the GC in Perl 6, and then run them alongside, looking for discrepancies. 13:07
jnthn: I love how you have C macros to emulate closures in Moar! :) 13:08
arnsholt Oooooh, that's even cleverer! 13:10
I used QuickCheck for a tiny Haskell project I did half a year ago or something 13:11
That was truly neat
diakopter masak: actually the memory is guaranteed already zeroed 13:12
by the last GC run
masak diakopter: interesting. 13:14
diakopter: then why do we have two functions for that? 13:15
can't we just kill off the zeroed one?
oh, and by the way, why does the GC waste time zeroing memory as part of freeing it?
diakopter jnthn said he added those originally to match parot, but then left them in case we noticed that zeroing optionally saves efficiency
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
masak yes, I understand. 13:17
is the memory guaranteed to be zeroed before any GC run?
(and if not, does that matter?)
diakopter yes, I think the first malloc is either calloc or memset 0
masak ok.
masak closes issue
no, wait. 13:18
I still think the comment is *wrong*.
and needs to be changed.
so I'll keep the issue open.
(put pasting this discussion into it)
diakopter well, you could change the issue to "look into whether zeroing can be made optional, once we're bug-free-ish"
masak oki
diakopter and the comment could refer to the issue :) 13:19
masak makes it so 13:21
dalek arVM: 90713bd | masak++ | src/gc/allocation.c:
refer to issue from comment
 13:23
13:34 jnap joined
masak when I was younger, I used to strongly dislike all kinds of reference cycles. 13:58
diakopter I LIKE TREES
masak nowadays, I find them quite OK. I'm just making sure they don't escape beyond some established boundary.
diakopter .. and then you liked trains instead..
masak :) 13:59
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:40
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.
o/ FROGGS
masak jnthn: understood. 14:55
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.
jnthn Well, it *does* give back zeroed memory :)
But yeah, it could be stated much better.
masak anyone, feel free to re-jigger the comment some more. 14:56
dalek arVM: bebea27 | jonathan++ | src/gc/allocation.c:
Comment tweak to better explain current situation.
 15:00
arVM: ad694b6 | jonathan++ | src/gc/wb.h:
Correct another comment.
nwc10 jnthn: what is supposed to update tc->cur_frame->params.args[0].o when the GC moves it? 15:02
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:
MVMObject *box = REPR(type)->allocate(tc, STABLE(type));
15:04 ssutch joined
jnthn as such, it is meant to be updated by roots.c:287 15:04
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
jnthn Right, but params.args points to the frame->args of the caller unless flattening took place.
nwc10 the naughty pointer is in frame->params.args
jnthn And we should certainly walk our way to the caller frame. 15:06
Does frame->caller->args point to the same location as frame->params.args? 15:07
nwc10 yes
jnthn And is frame->cur_args_callsite non-null? 15:08
nwc10 NULL
jnthn oh, ouchy.
argh, I think I see what it may be. 15:09
The calls set up by the CPS mechanism...
15:20 colomon joined 15:36 jnap joined 15:40 colomon joined
jnthn nwc10: Testing a fix here. 15:53
nwc10 cool 15:54
dalek arVM: 80a4be0 | jonathan++ | src/ (6 files):
Factor out C -> interp call; fix callsite mark bug

This will hopefully deal with a fail-to-mark issue found by nwc10++, and factors out some repeated logic.		 16:01
jnthn nwc10: Hopefully that helps. Lemme know if not. 16:02
nwc10: What nursery size are we down to now? :)
nwc10 oh, 1K built in not-sure-how-long 16:03
but most of a day
jnthn NQP, or Rakudo too?
nwc10 NQP
this was a hacked-about MoarVM trying to build Rakudo
nursery size 64K, IIRC, but 256 nursery collections before gen2 16:04
and 256 * 64K allocated, but all but 64K mapped as no read, no write
so was starting to torture the Rakudo build 16:05
jnthn :)
nwc10 1K was 17 hours 16:06
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)
gah, terminal eats newlines :-(
FROGGS newyears, newlines, whatever
jnthn Well, the inter-generational roots list must get huge with such a small nursery... 16:11
FROGGS jnthn: btw, here are some absurdities I've hit... gist.github.com/FROGGS/cbdcd4054a450d0faa22 16:24
I tried to hunt them down but without luck so far
16:37 jnap joined
[Coke] FROGGS: here's another one: 17:10
r-m: my $a is dynamic; say $a.VAR.dynamic;
(that one segfaults) 17:11
the say isn't needed, but the last .dynamic is. 17:12
jnthn Yeah, got some progress on that one here. 17:13
[Coke] jnthn++
jnthn Arrgh...why does building latest NQP give me "Unhandled exception: Missing or wrong version of dependency 'gen\moar\stage1\QRegex.nqp'"? 17:17
[Coke] here's another segfault: 'Any.exists("a")' 17:19
moritz jnthn: missing dependency, afaict
jnthn: a 'make clean'
jnthn I did make clean...
moritz huh.
or maybe you need to clean the install location too 17:20
jnthn Reverting 41debf4170 fixes it for me
FROGGS?
[Coke] Another segfault: $/.VAR.default 17:22
jnthn FROGGS: Removing my installed version helped 17:25
FROGGS: But then building after another make install breaks the build again. 17:26
FROGGS: Yeah, just adding that path in unconditionally during the bootstrap will bust it. :( 17:28
[Coke] Another segfault: +Mu 17:32
FROGGS huh? 17:35
jnthn FROGGS: It relies on falling back to --libpath=... 17:36
FROGGS: Whcih no longer happens.
FROGGS did you reconfigure?
jnthn Yes.
FROGGS hmpf
I dont find commit 41debf4170 btw... which repo is that?
jnthn NQP 17:37
oops
oh, I did get it right
commit 41debf41705d3979edaeffb47b804c1d15a1015e
Author: Tobias Leich [email@hidden.address]
Date: Tue Dec 31 12:41:18 2013 +0100
add nqp language diretory to search path
FROGGS I meant reconfigure in rakudo... 17:38
why does it work for me? Ć³.Ć²
jnthn 'cus you don't have an existing install, maybe?
FROGGS I have... like always 17:39
jnthn OK, then...I dunno 17:40
I'm surprised you don't get breakage too
for me, a make install of NQP, then make clean, then make, and it blows up after a bit
FROGGS I'll check in a bit 17:47
diakopter hi 18:05
18:38 jnap joined 18:53 colomon joined 19:53 cognominal joined 20:03 [Coke]_ joined 20:05 FROGGS_ joined 20:07 cognominal__ joined 20:09 sorear_ joined 20:40 jnap joined 20:56 harrow joined
dalek arVM: 560c0b4 | jonathan++ | src/ (2 files):
Clean up bogus container-related code.
 21:00
21:28 jnap joined 21:29 jnap1 joined
dalek arVM: 2568495 | jonathan++ | src/core/ (2 files):
Bring getlexrel in line with expected behavior.

Fixes PseudoStash.exists_key in some cases, and thus the spectests that depend on it.		 22:09
arVM: 99cc82d | jonathan++ | src/core/args.h:
Expose MVM_args_setup_thunk.
 22:18
22:53 arnsholt joined 23:01 jnap joined
grondilu tries to compile moarkudo 23:55
Unhandled exception: While looking for 'ModuleLoader.moarvm': no such file or directory
^what am I missing?
timotimo that's why froggs has been working on supplying multiple --libpath commandline args 23:56
FROGGS_ grondilu: just make sure you pulled MoarVM, nqp and rakudo 23:57
and reconfigure, to get proper makefiles
timotimo i'm almost finished getting my p6sort for moarvm finished 23:58
FROGGS_ very cool
grondilu I ran 'perl Configure.pl --gen-nqp --backends=moar --gen-moar', shouldn't that pull everything?
timotimo tomorrow, i may implement timsort instead of mergesort
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

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!