00:16 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Merge pull request #694 from ugexe/patch-1 00:16
travis-ci.org/MoarVM/MoarVM/builds/277085019 github.com/MoarVM/MoarVM/compare/d...bfc24273f7
00:16 travis-ci left
MasterDuke timotimo: callgrind seems to suggest that using MVM_fixed_size_alloc here github.com/MoarVM/MoarVM/blob/mast...ps.c#L1647 and MVM_fixed_size_free on 1688 and 1776 is faster 00:53
timotimo: 13.8 million instructions fewer to run this code `my $s; my $a = "a" x 50; my $aa = $a x 20; my $b = "b" x 50; my $bb = $b x 20; my $cc; for ^10_000 { $cc = join $aa, $bb; $s = $cc.chars }; say $s`, 2.4 million fewer if you make the 'x' values 5 and 2 (all with MVM_SPESH_BLOCKING=1) 01:11
.ask jnthn i had asked timotimo about using the FSA for string ops, here's a quick benchmark result of making a change to MVM_string_join ( irclog.perlgeek.de/moarvm/2017-09-20#i_15189752 ). any reason not to PR that and find similar opportunities? 01:14
yoleaux MasterDuke: I'll pass your message to jnthn.
01:36 zakharyas joined
samcv MasterDuke, how does that change how we free it? 01:53
01:55 ilbot3 joined
MasterDuke yeah, i was mainly looking at cases of alloc+free within a single function 02:04
02:49 benchable6 joined 03:22 Ven`` joined 06:02 domidumont joined
nwc10 good SEGV, #moarvm 06:27
Stage parse : src/6model/reprs/P6opaque.c:1362:16: runtime error: member access within null pointer of type 'struct MVMObject' 06:28
...
#0 0x7f5733e4df2c in elems src/6model/reprs/P6opaque.c:1362
#1 0x7f5733e04f7c in MVM_repr_elems src/6model/reprconv.c:500
...
06:39 brrt joined
samcv nwc10, that was a segv? 06:40
nwc10 yes. 06:49
just got to the point of valgrind running it
07:00 krunen_ joined
samcv i've seen that from valgrand before i think 07:02
or maybe it was asan
nwc10 the paste was the ASAN build
samcv ah ok that's why it's familiar
nwc10 The regular build also SEGVd at that point 07:03
samcv p6 code?
nwc10 now re-running in the tree of the regular build with ASAN
the setting
"Stage parse" of the setting
07:05 brrt joined
nine That line is return REPR(del)->elems(tc, STABLE(del), del, OBJECT_BODY(del)); in elems 07:05
07:07 krunen_ joined
nwc10 it hates me. it got past there under gdb 07:08
samcv yeah gdb alters it 07:09
nwc10 but also realised that the two terminals have different environment vars messing about wit things 07:10
so, killed the valigrind run (which had not yet failed) and trying with gdb there
bother. sometimes it works 07:16
brrt good * 07:18
broken code is broken :-(
nine And it's always a null pointer? That would rule out some GC issue I guess. 07:26
Geth MoarVM: 2f71945d24 | (Samantha McVey)++ | 12 files
Fix concat bug with utf8c8 strings, flattening utf8c8 synths

There was a bug when a string containing utf8-c8 sythetics was concatenated, it could cause the utf8-c8 synthetics to turn into multiple codepoints instead. Alter the codepoint iterators so they will pass back the utf8-c8 synthetics unchanged if supplied an argument to the init function.		 08:26
MoarVM: f112fbcff8 | (Samantha McVey)++ | src/strings/utf8_c8.c
Fix utfc-c8 enc. for values > 0x10FFFF and surrogates

There was a bug where if something was a valid UTF8 storable value, such as a surrogate or a value higher than 0x10FFFF, it would create a Str type with that value, even though it was not valid Unicode. This resolves that issue.
samcv \o/ woo 08:27
08:43 AlexDaniel joined
nine samcv++ 08:55
08:59 travis-ci joined
travis-ci MoarVM build failed. Timo Paulssen 'Protect parameterization additions with a mutex 08:59
travis-ci.org/MoarVM/MoarVM/builds/277303286 github.com/MoarVM/MoarVM/compare/3...407034d03a
08:59 travis-ci left
samcv i'm going to test out musl and see if maybe we can add a travis build for musl 09:11
jnthn morning o/ 09:17
yoleaux 01:14Z <MasterDuke> jnthn: i had asked timotimo about using the FSA for string ops, here's a quick benchmark result of making a change to MVM_string_join ( irclog.perlgeek.de/moarvm/2017-09-20#i_15189752 ). any reason not to PR that and find similar opportunities?
jnthn .tell MasterDuke Sounds reasonable to me 09:21
yoleaux jnthn: I'll pass your message to MasterDuke.
samcv morning jnthn :) 09:23
look at all the utf8-c8 issues i fixed :)
was able to run [tux]'s tests for minutes straight and no issues 09:24
jnthn samcv++
Very nice. :-)
samcv and noticed something 09:25
also interestingly the first change caused things to fail without the second commit
not 100% sure why yet but
when i made utf8-c8 not flatten, it broke things. cause synthetics ended up getting where they shouldn't have
jnthn Hm, weird 09:26
samcv yeah. probably some bug that maybe we know or don't know about yet
anyway. it is fixed now though
jnthn :) 09:27
samcv it was pretty puzzling to me though. couldn't figure out where it came from. but it stopped doing it when i fixed the utf8-c8 encoder
i'm excited my new laptop screen is coming tomorrow. my current one is dying. right 1/3 keeps turning into a distorted single colored square, and getting harder and more moving for it to go back to normal 09:32
new screen is 3k ips display. i have 1080p TN display currently. new one is supposed to look nice
jnthn, see github.com/MoarVM/MoarVM/blob/mast....h#L78-L95 09:33
i noticed. the comment there. isn't what it does below
ignore the new conditional i added about if (in < 0) the one below
we have an if condition test all the Latin-1 controls. and then inside it only checks for in == 0x0D 09:34
so it seems to basically be being useless
i think it means to say if (in != 0x0D || !to_NFG_form). so if has to be not \r, unless we are not converting it to nfg form 09:36
but i didn't change it since i wanted to do one thing at a time
09:43 zakharyas joined
jnthn if (!(MVM_NORMALIZE_GRAPHEME(n->form) && in == 0x0D)) 10:04
It's a negated condition
dogbert17 samcv++, perhaps you'll be able to close github.com/MoarVM/MoarVM/issues/664 10:16
samcv oh i missed the outer ( )
10:17 brrt joined
samcv jnthn, ok if i fix that to be more clear? 10:18
if (in != 0x0D || !MVM_NORMALIZE_GRAPHEME(n->form))
jnthn More clear to you, perhaps ;) 10:20
I'm fine with either :)
samcv heh
jnthn In Perl 6 I'd have written it unless ... { } :) 10:21
But no `unless` in C :)
samcv yeah
jnthn Man, these supply changes are tricky 10:23
jnthn nervously stresstests
samcv i really like using < instead of > sign after reading an article about it. especially with || or && it makes it so much clearer. and much less ways to write it 10:24
so instead of (cp >= '0' && cp <= '9'); ('0' <= cp && cp <= '9') . then cp is numerically and literally in between '0' and '9'
jnthn Hm, I can buy it in that case :) 10:26
samcv i find i make less conditional mistakes and it's faster for me to read them when it's consistent like that. have you seen the articele?
jnthn Think I skimmed it a while back
samcv llewellynfalco.blogspot.com/2016/02...gn-in.html here it is
jnthn I think it makes sense when you're doing a range check like that 10:27
But the title is clickbait
I don't think I'd write if (thingy > SOME_LIMIT) { ... } as if (SOME_LIMIT <= thingy) { ... } because the first one just communicates what we are about better, and it's thingy that is the dynamic part that we're asking about 10:28
Dammit. 10:29
Failures and hangs :/ 10:30
And multiple invocations of the same continuation
grr
10:30 Ven`` joined
jnthn How does that even happen... 10:31
Also the test harness didn't show me which tests were hanging when I did Ctrl + C :/
samcv well personally after using it, it becomes very quick everything on the right is bigger than things on the left. and you can easily tell which is static and which isn't. 10:32
but especially shines when it's a range
harness5?
jnthn Yeah
samcv i wish harness 6 showed more output of which files were being run 10:33
jnthn Well, -1 to taking a pass through the codebase and changing 'em all, but I've no objection to you using that style in stuff you're adding :)
Are working with
*Or
samcv yeah 10:34
though i might change ranges to fit that way if i notice them
jnthn, did you read about MasterDuke thinking about benchmarks for using fixed sized allocator in join? 10:44
jnthn Yeah, I even replied :)
samcv ah
ah just saw it heh 10:45
so that is our own allocator on top of the heap yes?
just because it's faster to request in larger amounts?
jnthn It's actually faster and more compact for small sizes 10:46
samcv and for larger sizes? 10:47
jnthn It delegates to malloc 10:52
samcv how do we decide when to free? 11:04
jnthn Needs an explicit free call 11:05
There's a "free now" and a "free at next safepoint" 11:06
Which today is implemented as "at the next GC run"
Since that obviously brings all thread to a safepoint 11:07
samcv ah ok 11:14
dogbert17 interesting, when running spectest with ASAN two Promise related test files has failures but ASAN does not complain. If I remove ASAN the failures disappear. 12:32
not ok 10 - got the right order 12:33
# Failed test 'got the right order' at t/spec/S17-promise/allof.t line 44
# expected: '0 1 2 3 4 5 6 7 8 9'
# got: '0 1 2 4 3 5 6 7 9 8'
lizmat jnthn: in case of hanging tests, I do a `ps` and kill all but the main process manually 12:34
jnthn: that will give you the info of which test-files were hanging 12:35
jnthn lizmat: Yeah, that's what I did :) 12:37
12:38 AlexDaniel joined
timotimo dogbert17: the test in allof.t requires timing to be correct. the overhead from asan might be enough to throw it off 12:44
it's even worse in valgrind because that makes everything run on just one thread 12:45
dogbert17 timotimo: yeah, with valgrind the order was 3 5 0 9 7 2 1 8 4 6 :) 12:47
timotimo yeah
dogbert17 is that a 'new test'
can't remember seeing it until quite recently 12:48
12:54 AlexDaniel joined 13:07 bisectable6 joined
jnthn I think they've been there for ages 13:19
timotimo it was sleeping 13:20
dogbert17 it's odd that I haven't noticed that behavior before 13:21
timotimo well, the result was almost correct, so maybe it accidentally worked often enough? %)
dogbert17 true, but the test is a bit strange in the sense that we're testing behaviour that can't be relied upon. Perhaps I'm misunderstanding something here. 13:22
jnthn Man, continuations... 13:23
jnthn sets off another stresstest and goes for language class
Changing the internals of how supplies manage concurrency - especially supply *blocks* - is as tricky as I suspected. 13:24
dogbert17 Hodně Å”těstĆ­
jnthn :) 13:25
&
timotimo that feeling when you changed a tiny bit of the profiler and are waiting for a 17 meg profile to show up in your browser 14:09
aaaaand it crashed. fine. 14:11
did a little bit of warm-up for the whole profiler grant work :) 14:22
14:45 brrt joined 14:55 travis-ci joined
travis-ci MoarVM build canceled. Jimmy Zhuo 'Merge pull request #695 from usev6/patch-1 14:55
travis-ci.org/MoarVM/MoarVM/builds/277443905 github.com/MoarVM/MoarVM/compare/3...2eab52f7f9
14:55 travis-ci left 15:06 domidumont joined
jnthn back 15:08
So it seems on the up side the hangs are all gone 15:09
On the downside, failures in 4 tests 15:10
ugexe libuv has 2 bugfixes to their copyfile api courtesy of spectest/moarvm 15:33
yoleaux 10:47Z <tbrowder> ugexe: will zef install a man page? if so, how should a module author provide the sources?
japhb ugexe: Our spectest caught their bugs?
ugexe japhb: yes. i swapped in their new copyfile api and it was failing to copy 0 byte files and failed to truncate destination file if it used the slow (sendfile api) path 15:34
timotimo ugexe: way cool. 15:35
japhb I'm very happy to hear that. :-)
jnthn ugexe++ 15:39
ugexe they have an impressive build/ci test matrix at their disposal
timotimo nooooo how did "git reset --hard origin/master" get into my shell history m(
jnthn Turns out one of the test regressions I ran into after supply refactors was because of a bug in Supply.zip that we got lucky enough in spectest to never shake out 15:40
timotimo oh, good, i had everything committed for once 15:41
jnthn Seems I've turned S17-supply/supplier-preserving.t from occasional failure to reliable failure also 15:43
timotimo The profiled code ran for 17.39ms. Of this, 0ms were spent on garbage collection (that's 0%). 15:51
The dynamic optimizer was active for 114.89% of the program's run time.
^- this is certainly correct!!
jnthn :P 15:52
15:58 AlexDaniel joined 16:00 brrt joined
brrt good * #moarvm 16:01
timotimo MoarVM panic: Profiler lost sequence - wow, i've never seen this 16:05
surely this is about continuations
jnthn Mebbe, though it has code to handle those too 16:07
timotimo what about cross-thread continuations? :D 16:08
jnthn I'd have thought it could handle that too 16:09
timotimo if i get the grant i'll have a bunch of time i can spend on this whole business 16:11
ever since END got moved into rakudo code (or something?) it's harder to figure out explosions 16:12
Unhandled exception: getexpayload needs a VMException, got P6opaque (X::AdHoc)
jnthn If you have a golf that produces that, it'd be interesting 16:13
timotimo it passes a high-level exception to comp.handle_exception i believe 16:14
m: END { die "oh no" }
camelia Unhandled exception: getexpayload needs a VMException, got P6opaque (X::AdHoc)
at <unknown>:1 (/home/camelia/rakudo-m-inst-1/share/perl6/runtime/CORE.setting.moarvm:)
from <unknown>:1 (/home/camelia/rakudo-m-inst-1/share/perl6/runtime/CORE.settā€¦
timotimo oh, that was easy
i suspect i'll just have to getattr the exception out of the Exception? 16:16
jnthn Guess so
Darn, my changes to react/supply block concurrency control tank performance. :/ 16:17
timotimo Don't know how to dump a BOOTCode - yikes, that's not so great 16:19
i wonder if i also have to grab the $!bt in order to see the backtrace in question 16:20
16:28 Ven`` joined
timotimo i now manage to apparently throw an exception while trying to dump_profile_data which immediately causes the END phasers to run including the one that's supposed to take the profile ... or something like that 16:36
i'm not sure why the main thread's "next" pointer is a null pointer at the end of S17-promise/start.t 16:44
that should create many threads, i don't think it joins the threads at all
jnthn We prepend to the threads list, not append, iirc
timotimo oh, so main_thread is the wrong place to start?
jnthn Otherwise we'd have to walk the linked list every thread start
Yes
instance->threads is the right place 16:45
timotimo ah, yes
jnthn Also there is a mutex you should acquire if you want to walk it safely
16:46 leont joined
timotimo well, i already forced a GC so that i can grab every thread's data safely 16:47
oooooh 16:50
ahahaha
that's a step forward. the profiler data somehow gets an NQPMu in it, though 16:52
wonder how that happens, but AFK first
17:51 samcv joined 17:57 leont joined 18:29 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Fix utfc-c8 enc. for values > 0x10FFFF and surrogates 18:29
travis-ci.org/MoarVM/MoarVM/builds/277657493 github.com/MoarVM/MoarVM/compare/3...12fbcff806
18:29 travis-ci left
samcv yay now mac builds are broken :( 18:33
i think i see what's happening 18:35
timotimo something about osx 10.11 and 10.12 or something?
Geth MoarVM: 523725a300 | (Samantha McVey)++ | build/Makefile.in
Only include libuv posix-hrtime on *BSD not Darwin

Was causing some MacOS versions to not build.		 18:42
samcv timotimo, seems like it 18:43
timotimo, what version do you have?
timotimo i don't have any osx
samcv oh. i forgot who it was then
18:44 geekosaur joined 19:13 vendethiel- joined
ugexe maybe one day the build process can be further improved to just use the libuv makefile so there is no need to mess with duplicating the right changes from upstream 19:17
samcv yeah 19:34
i think i'm going to have all in bounds codepoints respond with uniname containing the hex code 19:37
m: 0x10FFF.uniname.say 19:38
camelia <reserved>
samcv like that would say <reserved-10FFFF>
anything 0..10FFFF will give a unique response
AlexDaniel samcv: same with private use area maybe? 19:50
u: U+E000
unicodable6 AlexDaniel, U+E000 <Private Use> [Co] (ī€€)
AlexDaniel <Private Use E0000> ? 19:51
but I guess you already know about that 19:52
samcv yes same with everywhere 19:57
anything with < in it
which essentially is a non unique name identifier
<Private Use-E0000>
can't use a space. since spaces are allowed in the spec. essentially if someone wanted the original unicode data, they just need to know to remove from '-' to the '>' 19:58
since names can include numbers
well names can includes dashes too i suppose 19:59
AelxDnaiel IMO it makes sense, though I hope there is no poor soul out there checking for '<reserved>' exactly... 20:01
greppable6: reserved
greppable6 AelxDnaiel, gist.github.com/cb37189a8ee79a81c3...d5dd8bf443
AelxDnaiel greppable6: \<reserved 20:03
greppable6 AelxDnaiel, gist.github.com/9821b18a85f383a8c0...bb2a87ecc1
samcv like NUSHU CHARACTER-1B1AB
but it has a < in it
MasterDuke .ask jnthn cool, i'll work up a PR for using the FSA within strings/opc.c functions. what about using it for strings in general (i.e., body.storage.strands)? 21:27
yoleaux 09:21Z <jnthn> MasterDuke: Sounds reasonable to me
MasterDuke: I'll pass your message to jnthn.
21:44 travis-ci joined
travis-ci MoarVM build passed. Samantha McVey 'Only include libuv posix-hrtime on *BSD not Darwin 21:44
travis-ci.org/MoarVM/MoarVM/builds/277897868 github.com/MoarVM/MoarVM/compare/f...3725a3003a
21:44 travis-ci left 22:20 AlexDaniel joined
MasterDuke what's the max size before the fsa just uses regular MVM_malloc? is it less than 4096? 22:43
jnthn Surely 22:44
See fixedsizealloc.h
the multiply the maximum bins by the bin size to get it :) 22:45
That number has been tuned some in the past to try and be a good trade-off between things that can win from using the FSA and not ending up with a bunch of rarely used and mostly vacant pages 22:46
timotimo yeah, the bigger the items, the huger the page becomes 22:47
"The profiled code ran for 18446710383613.7ms."
it's getting better and better
jnthn m: say 18446710383613.7 / (1000 * 3600) 22:48
camelia 5124086.217670472
jnthn m: say 18446710383613.7 / (1000 * 3600 * 24 * 365.25)
camelia 584.5409785159106
jnthn 584 years!
timotimo i was quite patient
MasterDuke hm, then it looks like MVM_string_join is the only place i can switch to using the FSA 22:49
jnthn: unless you think timotimo++'s idea to use it for string storage is good?
timotimo i'd expect there's a negative number that's being stored in a unsigned var
jnthn Well, if you ask it for bigger it just falls back to malloc
timotimo m: say 184467103836137000.base(16)
camelia 28F5BDA84E5E628
jnthn MasterDuke: I'm not sure; it's one of those cases where we'd need to measure, I think
timotimo hm, that's not really something
jnthn Most strings are quite short 22:50
timotimo the number definitely shows up in the json blob 22:51
MasterDuke yeah, i'd definitely measure something 22:52
japhb timotimo: One too many zeros at the end? 22:55
m: say 18446710383613700.base(16)
camelia 41892F73B09704
japhb m: say 18446710383613700000.base(16) 22:56
camelia FFFFE15BE9CDE7A0
timotimo huh
japhb ^^ If it's microseconds instead of milliseconds
timotimo yeah
but even kicking off the Fs at the beginning ...
m: +^0xFFFFE15BE9CDE7A0
camelia WARNINGS for <tmp>:
Useless use of "+^" in expression "+^0xFFFFE15BE9CDE7A0" in sink context (line 1)
timotimo m: say +^0xFFFFE15BE9CDE7A0
camelia -18446710383613700001
Geth MoarVM: MasterDuke17++ created pull request #698:
Use the FSA for a temp alloc in MVM_string_join		 23:07

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!