Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-07-09

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

All times shown according to UTC.

Time Nick Message
00:27 Geth ¦ MoarVM: fa5158a38c | (Samantha McVey)++ | src/strings/normalize.c
00:27 Geth ¦ MoarVM: Don't break after ZWJ for Emoji=True + GCB=Other
00:27 Geth ¦ MoarVM:
00:27 Geth ¦ MoarVM: With this change we are now counting 100% of the Emoji v4.0
00:27 Geth ¦ MoarVM: emoji as a single grapheme. Since ascii numbers and the pound
00:27 Geth ¦ MoarVM: symbol are also counted as Emoji, disregard any codepoints in the
00:27 Geth ¦ MoarVM: ASCII range.
00:27 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fa5158a38c
00:28 geekosaur "..are also counted as emoji". I don't even.
00:29 Geth ¦ MoarVM: bef5802bda | (Samantha McVey)++ | tools/UCD-download.p6
00:29 Geth ¦ MoarVM: Make some fixes to the Unicode data file downloader
00:29 Geth ¦ MoarVM:
00:29 Geth ¦ MoarVM: Update it to the version from my Unicode Grant repo and
00:29 Geth ¦ MoarVM: fix an additional problem downloading the UCA files.
00:29 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bef5802bda
00:29 samcv yep
00:30 samcv they have an emoji presentation with variation selector
00:30 samcv probably...
00:30 samcv no clue. it's not on the emoji list but they're listed as emoji. the only i know they're a part of are the keypad ones
00:31 samcv now that Unicode 9.0 is effectively done... i will have a party
00:31 samcv hehe
00:33 * timotimo offers high-files before going to bed
00:33 * samcv updates moarvm readme to show unicode 9.0 support
00:33 Geth ¦ MoarVM: 89a9999fc1 | (Samantha McVey)++ | README.markdown
00:33 Geth ¦ MoarVM: Update the README to indicate Unicode 9.0 support
00:33 Geth ¦ MoarVM:
00:33 Geth ¦ MoarVM: With the recent fix to all the Unicode 9.0 era Emoji
00:33 Geth ¦ MoarVM: (though technically part of Emoji v4.0 standard), list
00:33 Geth ¦ MoarVM: that we support Unicode 9.0.
00:33 Geth ¦ MoarVM:
00:34 samcv ^5 :)
00:34 Geth ¦ MoarVM: Other changes which contributed to this were fairly recent
00:34 Geth ¦ MoarVM: full support of Prepend codepoints and Regional Indicators
00:34 Geth ¦ MoarVM: as well as various other Grapheme related things.
00:34 samcv high files?
00:34 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/89a9999fc1
00:34 samcv heh
00:34 * timotimo o/⁵o samcv
00:35 timotimo we can totes 3dprint a big 5 that has handles on each side btw
00:35 samcv hehe
00:37 timotimo and if that's not "high five" enough, i'm sure we can get a glassblower (maybe a student) to make us a ... specific device ... shaped like a 5
00:47 timotimo sleep time
01:48 ilbot3 joined #moarvm
01:48 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:10 samcv what's the best way to make strands. just concatting things?
02:24 AlexDaniel joined #moarvm
03:19 vendethiel joined #moarvm
08:09 domidumont joined #moarvm
08:53 sivoais joined #moarvm
11:23 jnthn samcv: Waht's the context on "make strands"? But yeah, concating two simple strings will potentially make strands, though if it detects it has to tweak with the ends of them for normalizations reasons you'll get a flat string again
11:23 jnthn samcv++ # emoji tests passing \o/
11:26 nine Funny. I get "Code ref '' does not exist in serialization context", with "finish_code_object" being the outer according to gdb, but giving all the anonymous subs in method finish_code_object names does not change the result
11:29 nine Btw. my current strategy is to bite the bullet and write all the debug helpers I need to make debugging this rather trivial. Though it seems like finding out what those tools could do is rather non-trivial by itself.
11:30 timotimo i can try to offer guidance
11:30 nine In essence all my troubles are caused by serialization context confusions in situations where we do nested compilation (BEGIN time EVAL or in-process precompilation).
11:31 nine I get various "does not exist in serialization context" errors and one testcase shows repossession issues. I guess they are all related.
11:32 nine timotimo: so if you were to debug such issues. What information would you seek?
11:35 timotimo oh lord, i haven't looked into serialization related things in a long time
11:37 timotimo maybe trace the creation of objects that get a SC set, and when repossession happens, what gets repossessed?
11:37 timotimo not sure :\
11:38 timotimo i wonder if it's a good idea to turn off GC so that pointers don't move
11:38 jnthn I suspect something that can dump what's actually in a serialization context would be somewhat useful
11:38 timotimo mhm
11:38 jnthn Given we have debug_name that should be possible
11:38 nine Both sound quite useful to me.
11:39 nine And given MVM_dump_p6opaque's warm reception, spending time on such debug tools could be good for the soul :)
11:40 timotimo i've experienced it crash on me
11:40 timotimo dump p6opaque i mean
11:42 nine Yeah, me, too. I'm not that surprised given how little I actually know about these internals. I'm sure to have missed a couple of cases.
11:42 timotimo heh.
11:42 timotimo i ought to look into it a bit
11:43 timotimo among other things it'll just dump a string even if the object in question isn't even a string at all
11:43 timotimo i wonder if i committed that piece of code that puts a decision tree there
12:07 nine Already looks a bit odd: https://gist.github.com/niner/062b873d56fef55b2cec1edc1962a3ef
12:17 nine And objects appear to be listed multiple times in root_objects
13:00 domidumont joined #moarvm
13:05 domidumont joined #moarvm
13:18 nine A VMNull object in an SC's root_codes array? Sounds odd, but I guess its nothing out of the ordinary.
13:22 nine With this SCRoot dumper I can now confirm that the code ref in question does indeed not appear in the SC or its dependencies. Could be that it was in an SC of a comp unit that has already been serialized
13:25 nine OTOH the object itself thinks it belongs to the writer's root sc
13:31 MasterDuke fyi, just updated https://github.com/MoarVM/MoarVM/pull/590
13:31 timotimo have you tried working with rr yet, nine?
13:54 nine timotimo: what's rr?
13:57 nine rr-project.org? That does sound useful :) As I could just set a data-watch at the object's sc field's address
14:00 Geth ¦ MoarVM/even-moar-jit: 3e0c0881df | (Bart Wiegmans)++ | src/jit/core.expr
14:00 Geth ¦ MoarVM/even-moar-jit: Add return_o expression op
14:00 Geth ¦ MoarVM/even-moar-jit:
14:00 Geth ¦ MoarVM/even-moar-jit: Rather common, presents no problems, did indicate that our template
14:00 Geth ¦ MoarVM/even-moar-jit: correctness checks aren't great.
14:00 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/3e0c0881df
14:00 Geth ¦ MoarVM/even-moar-jit: b81cd68142 | (Bart Wiegmans)++ | docs/jit/todo.org
14:00 Geth ¦ MoarVM/even-moar-jit: Plan JIT stack walker
14:00 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/b81cd68142
14:01 nine The choice of name is kinda idiotic though. How is any search for that name supposed to come up with something useful?
14:06 buggable joined #moarvm
14:25 nine How can I disable the GC?
14:25 nine timotimo: you were spot on. Disabling the GC would make this easier
14:25 jnthn nine: Easiest way is to force everything to be allocated in gen2
14:25 jnthn Only way, probably :)
14:25 jnthn There's a function you can call to achieve taht, I forget the exact name, but I think it's in src/gc/allocate.h
14:27 nine MVM_gc_allocate_gen2_default_set(tc)
14:30 jnthn That's the one
14:30 jnthn Oh, I should note a caveat: it does it for per thread
14:31 jnthn So if you're going to have multiple threads being spawned then you'll want to stick a call to that into both moar.c where we make the VM instance and thread.c where a new thread is spawned.
14:36 nine jnthn++ # works like a charm
14:36 AlexDaniel joined #moarvm
14:36 nine timotimo++ # I now got the place where the object is put into SC #27 :)
14:37 jnthn nine: fwiw if you want to add an env var MOAR_GC_NEVER or something I'm fine with that
14:37 jnthn I don't think you'll be the last person who wants it :)
14:37 dogbert17 is it correct that Metamodel::C3MRO.^mro returns types even though they are marked as hidden?
14:38 timotimo what does hidden mean?
14:38 nine jnthn: will do. Still have to commit yesterday's debug_name fixes, too.
14:39 timotimo if something's not in the mro, methods from it won't be available at all
14:39 timotimo at least in theory?
14:39 jnthn dogbert17: Yes, there's an mro_unhidden for the other thing
14:39 dogbert17 timotimo: a trait called 'is hidden'
14:39 jnthn nine++
14:40 dogbert17 cool, will tweak the doc, the ^mro method has two explanations, I intend to remove the one that is less detailed
14:41 nine Ok, the unnamed code ref is a comp unit's mainline. Which isn't that surprising considering that we're compiling a module.
14:46 timotimo don't forget that whenever you call some code from a running rr session it will clone the program, run the code, then destroy the clone
14:48 nine The code object is actually right. It should still be in SC #27. That's where we added it and that's where we are now failing to find it. So somehow it had to be removed from the SC.
14:48 nine actually "has to have been removed" I think...
15:07 dogbert17 timotimo: would you be terribly upset if I closed RT #123434
15:07 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=123434
15:10 timotimo please go ahead
15:13 dogbert17 timotimo: done
15:29 FROGGS joined #moarvm
15:32 FROGGS o/
15:38 domidumont joined #moarvm
16:34 vendethiel joined #moarvm
17:00 dogbert17 if you run helgrind on a script, is there an 'easy' way to know if something is a real problem or just something irrelevant?
17:02 * dogbert17 perhaps not the easiest question to answer
17:03 timotimo that is one of the hardest things :)
17:03 dogbert17 to be more specific, I'm running the second code example in RT #130796
17:03 synopsebot6 Link:  https://rt.perl.org/rt3/Public/Bug/Display.html?id=130796
17:04 dogbert17 m: my $c = 0; my @a = lazy gather { take 1; loop { take rand } }; my @b = lazy gather { take 1; loop { take rand } }; for ^10 -> $i { await start { $ = @a[^$i] }, start { $ = @b[^$i] } }; say @a[^10] eqv @b[^10]; say $c; say @a[^10]
17:04 camelia rakudo-moar 4894a7: OUTPUT: «False␤0␤(1 0.999299666130502 0.53503705328689 0.294035244642186 0.67976963144181 0.86719035238592 0.867675113551506 0.362186164002754 0.80890451131411 0.839907669840518)␤»
17:04 dogbert17 I get a bunch of output but how do I make heads or tails of it?
17:06 dogbert17 stuff like:
17:06 dogbert17 ==29592== Possible data race during read of size 4 at 0x6B4E834 by thread #11
17:06 dogbert17 ==29592== Locks held: none
17:06 dogbert17 ==29592== This conflicts with a previous write of size 4 by thread #1
17:06 dogbert17 ==29592== Locks held: 1, at address 0x6B412C8
17:11 dogbert17 I gisted the output here: https://gist.github.com/dogbert17/b774a3bccb2896de0c89c98d89ee27cd
17:17 timotimo i expect the helgrind output of just an empty program (well, maybe two start blocks and an await or something) could look similarly gigantic
17:18 timotimo we can turn off lazy deserialization of SCs, that'd probably eliminate a few pieces of output
17:23 dogbert17 timotimo: there's some stuff at the top which seems to show up in each and every program, I added a few carriage returns in the output after that stuff
17:24 timotimo 9:#define MVM_SERIALIZATION_LAZY 1
17:24 timotimo you can flip this to 0
17:28 dogbert17 timotimo: I'll give it a shot
17:35 dogbert17 the output went from 2300 lines to 2100 lines
17:43 dogbert17 gist updated
17:44 timotimo bleh :(
17:46 dogbert17 :)
17:46 dogbert17 can you see anything suspicious?
17:50 timotimo couldn't look closely yet, sorry
17:51 dogbert17 I decreased the number of iterations, no the output is ~800 lines
17:51 dogbert17 *now
18:18 dogbert17 timotimo: switched to a longer gist, the reason I did that is that the run in question actually failed with 'Cannot call method 'push' on a null object'. The other runs did not fail.
18:38 timotimo this log doesn't speak to me :<
18:45 dogbert17 it was worth a shot  :)
18:49 dogbert17 this caught my eye but I guess it's nothing ... https://gist.github.com/dogbert17/b774a3bccb2896de0c89c98d89ee27cd#file-gistfile1-txt-L4055
18:57 timotimo it doesn't help that the granularity of allocation info there is super bad
18:57 timotimo however
18:57 timotimo we can get those to become better by enabling the FSA debug mode
18:57 timotimo the size debug one
18:58 timotimo it'll use malloc for every allocation, so we'll get the code that actually grabbed the data rather than the code that caused the whole page to be allocated
18:58 timotimo that'd be worth a try
19:00 dogbert17 do you mean #define FSA_SIZE_DEBUG 0
19:00 dogbert17 set to 1 ofc
19:08 timotimo that's the one
19:09 dogbert17 trying to get the code example to fail
19:24 domidumont joined #moarvm
19:32 zakharyas joined #moarvm
20:02 dogbert17 finally, gist updated, the error 'This continuation has already been invoked' is not at the bottom though
20:09 colomon joined #moarvm
20:22 timotimo hmpf
20:40 samcv i need to decide when i want to convert needles from 8bit to 32bit before searching the haystack for them. i found for big documents i can get a pretty big speedup by doing so
20:40 yoleaux 13:46Z <Zoffix> samcv: You're listed as stakeholder for Formal Rules for Defining Matched Delimiters/Brackets. When can you start working on that? Would you include approximate time required to complete it it? https://github.com/perl6/6.d-prep/blob/master/TODO/FEATURES.md#time-required-to-implement-2
21:07 colomon joined #moarvm
21:14 colomon joined #moarvm
21:29 colomon joined #moarvm
21:50 Geth ¦ MoarVM: e13c30b705 | (Samantha McVey)++ | 2 files
21:50 Geth ¦ MoarVM: Use MVMint64 for MVM_string_chr (oplist/function mismatch)
21:50 Geth ¦ MoarVM:
21:50 Geth ¦ MoarVM: The oplist showed chr using int64 but its function had MVMCodepoint
21:50 Geth ¦ MoarVM: which is a 32 bit integer. Change the functions so it accepts a
21:50 Geth ¦ MoarVM: 64 bit integer.
21:50 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e13c30b705
22:11 colomon joined #moarvm
22:27 colomon joined #moarvm
22:53 colomon joined #moarvm
23:32 MasterDuke timotimo: how difficult would it be to make num_graphs a MVMuint64 instead of MVMuint32?
23:46 timotimo probably easy
23:50 MasterDuke i figure some places all that's needed is changing the type of e.g., an index variable, but some places might need a little more attention
23:52 MasterDuke if i managed it, how do you think a PR to make that change would be accepted?

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