Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-19

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

All times shown according to UTC.

Time Nick Message
00:26 vendethiel joined #moarvm
01:45 colomon joined #moarvm
04:26 quester joined #moarvm
04:46 vendethiel joined #moarvm
06:25 vendethiel joined #moarvm
06:43 FROGGS joined #moarvm
06:58 Ven joined #moarvm
07:07 zakharyas joined #moarvm
07:26 vendethiel joined #moarvm
07:41 Ven joined #moarvm
07:44 quester left #moarvm
09:00 FROGGS joined #moarvm
10:36 vendethiel joined #moarvm
11:10 vendethiel joined #moarvm
11:50 colomon joined #moarvm
11:50 Ven joined #moarvm
11:58 FROGGS[mobile] joined #moarvm
12:00 vendethiel joined #moarvm
12:13 Ven joined #moarvm
12:46 nwc10 jnthn: http://paste.scsys.co.uk/480344 -- GC managed to deadlock itself, with just one thread
12:46 nwc10 sorry, have now killed the process
12:52 masak isn't that a real achievement, deadlocking on one thread?
12:52 masak sounds like a koan or something
12:52 nwc10 it does seem to be a bit special.
12:53 * masak .oO( we have invented new groundbreaking single-thread deadlocking technology )
12:58 lizmat m: 1 until Promise.new
12:58 masak good point.
12:58 camelia rakudo-moar 8ab32b: OUTPUT«(timeout)»
12:59 masak I guess that can be seen as a kind of zero-resource degenerate case of deadlocking.
12:59 lizmat :-)
13:08 vendethiel joined #moarvm
13:12 * masak .oO( kind of like a sphere is a generalized torus with 0 handles )
13:22 dalek joined #moarvm
15:42 TimToady joined #moarvm
15:59 lizmat joined #moarvm
16:09 vendethiel joined #moarvm
16:58 vendethiel joined #moarvm
17:30 vendethiel joined #moarvm
17:45 FROGGS joined #moarvm
17:54 dalek MoarVM: 5220f52 | FROGGS++ | / (8 files):
17:54 dalek MoarVM: add scdisclaim op
17:54 dalek MoarVM:
17:54 dalek MoarVM: This way we can deserialize an serialization context (SC), throw the SC away, and then serialize
17:54 dalek MoarVM: the obtained object to another SC.
17:54 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5220f52435
17:54 FROGGS that won't hurt (when it is not used)
18:22 timotimo sounds good to have it early
18:23 timotimo what's your status? is the "segfaults with eval" problem still a thing?
18:24 FROGGS it is sadly, though that only happens in the rakudo/curly branch of course
18:24 timotimo yeah, i figured
18:24 timotimo did you capture a backtrace?
18:24 FROGGS no
18:25 FROGGS looked at it, yes, but did not record it
18:25 timotimo OK
18:25 FROGGS was a WORKLIST_ADD in SCRef.c
18:26 lizmat FROGGS: did you look at loading_and_symbol_setup in World?
18:26 FROGGS lizmat: not yet, gimme a sec
18:26 timotimo ah, so something's referring to a null value
18:26 timotimo so we're wrongfully adding a reference to an SC'd thing that has had its SC disclaimed?
18:27 FROGGS timotimo: something along these lines probably, yes
18:27 lizmat it has different code paths for EVAL and loading a setting
18:27 timotimo my suggestion is adding a log output or exception when we take an SCref to something that has a null SC, so that we can figure out  where it originates
18:27 timotimo do you want to postpone any further work on curly for a few weeks?
18:29 FROGGS timotimo: not a few weeks, but days... it is very unlikely to get it right until Thursday
18:29 FROGGS lizmat: I'm looking at it
18:30 FROGGS lizmat: that code was in Grammar.comp_unit before?
18:30 timotimo i definitely know the feeling
18:31 FROGGS the code after the line '# initialize %?INC if not in an eval' is interesting... I'll play with it
18:31 lizmat ok
18:31 FROGGS though there is nothing obvious...
18:47 lizmat I'm just realizing that the code for -M is executed for each EVAL ????
18:53 FROGGS hmmm
18:54 FROGGS m: use Test; ok 1; EVAL 'ok 2'
18:54 camelia rakudo-moar 27e531: OUTPUT«ok 1 - ␤ok 2 - ␤»
18:54 FROGGS ahh, that#s not -M
18:54 FROGGS m: use Test; ok 1; EVAL 'use Test; ok 2'
18:54 camelia rakudo-moar 27e531: OUTPUT«ok 1 - ␤ok 2 - ␤»
18:55 FROGGS hmmm, not easily checkable
18:56 timotimo yeah, not with camelia
18:58 lizmat also not locally, as the mainline is not run a second time
18:58 lizmat anyway, I made it conditional and it didn't break any spectest
18:58 timotimo oh
18:58 timotimo the mainline is not run? phew
18:58 timotimo i thought it was and that'd have been disastrous :)
18:59 lizmat yeah... but in any case, it is not needed  :-)
18:59 [Coke] FROGGS: +#?v6.0.0+ skip 'isn\'t the iterator exhausted already, since it\'s been used previously?'
19:00 [Coke] That can be written with "" on the outside instead of '' so you can avoid the quoting of ' inside the string.
19:00 [Coke] (crap, wrong tab.)
19:02 timotimo i had misunderstood what an SCRef is
19:03 timotimo FROGGS: you don't remember which of the worklist_add ones was the one that bombed?
19:03 FROGGS [Coke]: ahh, I was under the impression that fudge checked for ' explicitly
19:05 FROGGS timotimo: I'm pretty sure it was this: MoarVM/src/6model/reprs/SCRef.c:75:        MVM_gc_worklist_add(tc, worklist, &(sc->sr->root.sc));
19:06 timotimo oh, so perhaps the reader was "damaged" during the disclaim?
19:07 FROGGS it looked alright when inspecting it via gdb
19:07 FROGGS but maybe it is not meant to be reused or so, dunno
19:08 timotimo well, there had to be *some* address that refered to a non-mapped region or something
19:14 FROGGS maybe the string heap it points to?
19:15 timotimo isn't gc_worklist_add super simple?
19:16 timotimo like, wouldn't that only segv if sc->sr->root.sc was broken somehow?
19:16 timotimo directly, i mean
19:16 timotimo all worklist_add does is maybe grow the worklist allocation array and put the item in there
19:18 FROGGS but I was able to access sc->sr->root.sc
19:19 timotimo huh
19:19 timotimo and the worklist wasn't broken either, surely
19:19 timotimo maybe optimization shuffled some things around?
19:20 timotimo is it right that disclaim_sc doesn't do anything at all about the dependent_sc's of the reader?
19:20 timotimo hm, probably is; though disclaiming an sc forces the reader to read in everything everywhere
19:20 timotimo so it might be a good idea to kill off the reader, too?
19:20 timotimo if only to save the space it used
19:21 FROGGS I dunno :o(
19:24 dalek MoarVM/cunion: 1e7f1ac | FROGGS++ | / (13 files):
19:24 dalek MoarVM/cunion: add support for CUnion repr
19:24 dalek MoarVM/cunion: review: https://github.com/MoarVM/MoarVM/commit/1e7f1acc8b
19:24 dalek MoarVM/cunion: 2dacf16 | FROGGS++ | src/6model/reprs/CUnion. (2 files):
19:24 dalek MoarVM/cunion: allow to inline CStructs in CUnions
19:24 dalek MoarVM/cunion: review: https://github.com/MoarVM/MoarVM/commit/2dacf16023
19:24 dalek MoarVM/cunion: 29ea746 | FROGGS++ | src/6model/reprs/CStruct.c:
19:24 dalek MoarVM/cunion: align inlined CUnions to their size
19:24 dalek MoarVM/cunion: review: https://github.com/MoarVM/MoarVM/commit/29ea7460f3
19:24 timotimo this is just a rebase?
19:24 FROGGS a rebase and another commit
19:24 timotimo ah
19:24 timotimo i seem to recall someone complained that something about them wasn't working recently
19:24 FROGGS them?
19:25 timotimo c unions
19:25 FROGGS ahh, you probably mean the PR that adds tests
19:25 timotimo perhaps
19:25 FROGGS yes, IMO only the 'is inlined' trait is missing there
19:25 timotimo cool
19:26 FROGGS I want to fix another issue on windows and then I'll look at the PR
19:33 FROGGS okay... last issue was a bogus test
19:34 timotimo for cunion?
19:35 FROGGS aye
19:35 FROGGS struct a was: long, double, char; struct b was long, float, float, char
19:35 FROGGS the intend was to check that both chars are at the same position
19:35 timotimo ah
19:36 timotimo but float and double have the same alignment, no?
19:36 FROGGS but they are not due to alignment
19:36 FROGGS it aligns the long in a to 8 bytes too
19:36 FROGGS and it aligns to 4 in b
19:37 timotimo oh?
19:37 timotimo i suppose i don't really know the rules of structs and stuff
19:38 timotimo not by heart anyway
19:38 FROGGS yeah, one can easily get confuddled
19:38 timotimo if you have the rules in front of you and you can go at it systematically, it's surely fine
19:38 FROGGS it is like: the double in a wants to start at an 8 byte alignment
19:38 timotimo ideally, you'd be using a tool :)
19:46 brrt joined #moarvm
19:47 dalek MoarVM: 1e7f1ac | FROGGS++ | / (13 files):
19:47 dalek MoarVM: add support for CUnion repr
19:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1e7f1acc8b
19:47 dalek MoarVM: 2dacf16 | FROGGS++ | src/6model/reprs/CUnion. (2 files):
19:47 dalek MoarVM: allow to inline CStructs in CUnions
19:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2dacf16023
19:47 dalek MoarVM: 29ea746 | FROGGS++ | src/6model/reprs/CStruct.c:
19:47 dalek MoarVM: align inlined CUnions to their size
19:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/29ea7460f3
19:51 brrt \o
19:52 timotimo o/ brrt
19:53 brrt hey timotimo :-)
19:53 timotimo your funding has been accepted \o/
19:53 timotimo when can you start? :P
19:54 brrt its on the interwebs now? i start mid june
19:55 timotimo that's almost a month of waiting for the goods to start pouring in :S
19:57 brrt oh, you'll wait longer than that before you see any benefits :-P
19:57 brrt but yes
19:58 brrt i intend to take the time to study up :-)
19:59 timotimo well, right :)
20:00 brrt uhm, if you wish, you can put it in a weekly i guess
20:01 brrt but i really should probably get around to publishing it myself
20:01 timotimo aye
20:01 brrt (the fact that i'll be working on the JIT again)
20:07 brrt (compilers are exciting :-o)
20:07 timotimo :)
20:23 brrt luajit source code should not be known for being easy to read
22:31 vendethiel joined #moarvm

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