Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-09-20

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

All times shown according to UTC.

Time Nick Message
00:16 travis-ci joined #moarvm
00:16 travis-ci MoarVM build failed. Samantha McVey 'Merge pull request #694 from ugexe/patch-1
00:16 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/277085019 https://github.com/MoarVM/MoarVM/compare/dfbf9df7b691...eabfc24273f7
00:16 travis-ci left #moarvm
00:53 MasterDuke timotimo: callgrind seems to suggest that using MVM_fixed_size_alloc here https://github.com/MoarVM/MoarVM/blob/master/src/strings/ops.c#L1647 and MVM_fixed_size_free on 1688 and 1776 is faster
01:11 MasterDuke 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:14 MasterDuke .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 ( https://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 #moarvm
01:53 samcv MasterDuke, how does that change how we free it?
01:55 ilbot3 joined #moarvm
01:55 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:04 MasterDuke yeah, i was mainly looking at cases of alloc+free within a single function
02:49 benchable6 joined #moarvm
03:22 Ven`` joined #moarvm
06:02 domidumont joined #moarvm
06:27 nwc10 good SEGV, #moarvm
06:28 nwc10 Stage parse      : src/6model/reprs/P6opaque.c:1362:16: runtime error: member access within null pointer of type 'struct MVMObject'
06:28 nwc10 ...
06:28 nwc10 #0 0x7f5733e4df2c in elems src/6model/reprs/P6opaque.c:1362
06:28 nwc10 #1 0x7f5733e04f7c in MVM_repr_elems src/6model/reprconv.c:500
06:28 nwc10 ...
06:39 brrt joined #moarvm
06:40 samcv nwc10, that was a segv?
06:49 nwc10 yes.
06:49 nwc10 just got to the point of valgrind running it
07:00 krunen_ joined #moarvm
07:02 samcv i've seen that from valgrand before i think
07:02 samcv or maybe it was asan
07:02 nwc10 the paste was the ASAN build
07:02 samcv ah ok that's why it's familiar
07:03 nwc10 The regular build also SEGVd at that point
07:03 samcv p6 code?
07:03 nwc10 now re-running in the tree of the regular build with ASAN
07:03 nwc10 the setting
07:03 nwc10 "Stage parse" of the setting
07:05 brrt joined #moarvm
07:05 nine That line is return REPR(del)->elems(tc, STABLE(del), del, OBJECT_BODY(del)); in elems
07:07 krunen_ joined #moarvm
07:08 nwc10 it hates me. it got past there under gdb
07:09 samcv yeah gdb alters it
07:10 nwc10 but also realised that the two terminals have different environment vars messing about wit things
07:10 nwc10 so, killed the valigrind run (which had not yet failed) and trying with gdb there
07:16 nwc10 bother. sometimes it works
07:18 brrt good *
07:18 brrt broken code is broken :-(
07:26 nine And it's always a null pointer? That would rule out some GC issue I guess.
08:26 Geth ¦ MoarVM: 2f71945d24 | (Samantha McVey)++ | 12 files
08:26 Geth ¦ MoarVM: Fix concat bug with utf8c8 strings, flattening utf8c8 synths
08:26 Geth ¦ MoarVM:
08:26 Geth ¦ MoarVM: There was a bug when a string containing utf8-c8 sythetics was
08:26 Geth ¦ MoarVM: concatenated, it could cause the utf8-c8 synthetics to turn into multiple
08:26 Geth ¦ MoarVM: codepoints instead. Alter the codepoint iterators so they will pass back
08:26 Geth ¦ MoarVM: the utf8-c8 synthetics unchanged if supplied an argument to the init
08:26 Geth ¦ MoarVM: function.
08:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2f71945d24
08:26 Geth ¦ MoarVM: f112fbcff8 | (Samantha McVey)++ | src/strings/utf8_c8.c
08:26 Geth ¦ MoarVM: Fix utfc-c8 enc. for values > 0x10FFFF and surrogates
08:26 Geth ¦ MoarVM:
08:26 Geth ¦ MoarVM: There was a bug where if something was a valid UTF8 storable value,
08:26 Geth ¦ MoarVM: such as a surrogate or a value higher than 0x10FFFF, it would create
08:26 Geth ¦ MoarVM: a Str type with that value, even though it was not valid Unicode.
08:26 Geth ¦ MoarVM: This resolves that issue.
08:26 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f112fbcff8
08:27 samcv \o/ woo
08:43 AlexDaniel joined #moarvm
08:55 nine samcv++
08:59 travis-ci joined #moarvm
08:59 travis-ci MoarVM build failed. Timo Paulssen 'Protect parameterization additions with a mutex
08:59 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/277303286 https://github.com/MoarVM/MoarVM/compare/3dea7dff4bf2...86407034d03a
08:59 travis-ci left #moarvm
09:11 samcv i'm going to test out musl and see if maybe we can add a travis build for musl
09:17 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 ( https://irclog.perlgeek.de/moarvm/2017-09-20#i_15189752 ). any reason not to PR that and find similar opportunities?
09:21 jnthn .tell MasterDuke Sounds reasonable to me
09:21 yoleaux jnthn: I'll pass your message to MasterDuke.
09:23 samcv morning jnthn  :)
09:23 samcv look at all the utf8-c8 issues i fixed :)
09:24 samcv was able to run [tux]'s tests for minutes straight and no issues
09:24 jnthn samcv++
09:24 jnthn Very nice. :-)
09:25 samcv and noticed something
09:25 samcv also interestingly the first change caused things to fail without the second commit
09:25 samcv not 100% sure why yet but
09:25 samcv when i made utf8-c8 not flatten, it broke things. cause synthetics ended up getting where they shouldn't have
09:26 jnthn Hm, weird
09:26 samcv yeah. probably some bug that maybe we know or don't know about yet
09:26 samcv anyway. it is fixed now though
09:27 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
09:32 samcv 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 samcv new screen is 3k ips display. i have 1080p TN display currently. new one is supposed to look nice
09:33 samcv jnthn, see https://github.com/MoarVM/MoarVM/blob/master/src/strings/normalize.h#L78-L95
09:33 samcv i noticed. the comment there. isn't what it does below
09:33 samcv ignore the new conditional i added about if (in < 0) the one below
09:34 samcv we have an if condition test all the Latin-1 controls. and then inside it only checks for in == 0x0D
09:34 samcv so it seems to basically be being useless
09:36 samcv 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 samcv but i didn't change it since i wanted to do one thing at a time
09:43 zakharyas joined #moarvm
10:04 jnthn if (!(MVM_NORMALIZE_GRAPHEME(n->form) && in == 0x0D))
10:04 jnthn It's a negated condition
10:16 dogbert17 samcv++, perhaps you'll be able to close https://github.com/MoarVM/MoarVM/issues/664
10:16 samcv oh i missed the outer ( )
10:17 brrt joined #moarvm
10:18 samcv jnthn, ok if i fix that to be more clear?
10:18 samcv if (in != 0x0D || !MVM_NORMALIZE_GRAPHEME(n->form))
10:20 jnthn More clear to you, perhaps ;)
10:20 jnthn I'm fine with either :)
10:20 samcv heh
10:21 jnthn In Perl 6 I'd have written it unless ... { } :)
10:21 jnthn But no `unless` in C :)
10:21 samcv yeah
10:23 jnthn Man, these supply changes are tricky
10:23 * jnthn nervously stresstests
10:24 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 samcv so instead of (cp >= '0' && cp <= '9'); ('0' <= cp && cp <= '9') . then cp is numerically and literally in between '0' and '9'
10:26 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?
10:26 jnthn Think I skimmed it a while back
10:26 samcv http://llewellynfalco.blogspot.com/2016/02/dont-use-greater-than-sign-in.html here it is
10:27 jnthn I think it makes sense when you're doing a range check like that
10:27 jnthn But the title is clickbait
10:28 jnthn 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:29 jnthn Dammit.
10:30 jnthn Failures and hangs :/
10:30 jnthn And multiple invocations of the same continuation
10:30 jnthn grr
10:30 Ven`` joined #moarvm
10:31 jnthn How does that even happen...
10:31 jnthn Also the test harness didn't show me which tests were hanging when I did Ctrl + C :/
10:32 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 samcv but especially shines when it's a range
10:32 samcv harness5?
10:32 jnthn Yeah
10:33 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 :)
10:33 jnthn Are working with
10:33 jnthn *Or
10:34 samcv yeah
10:34 samcv though i might change ranges to fit that way if i notice them
10:44 samcv jnthn, did you read about MasterDuke thinking about benchmarks for using fixed sized allocator in join?
10:44 jnthn Yeah, I even replied :)
10:44 samcv ah
10:45 samcv ah just saw it heh
10:45 samcv so that is our own allocator on top of the heap yes?
10:45 samcv just because it's faster to request in larger amounts?
10:46 jnthn It's actually faster and more compact for small sizes
10:47 samcv and for larger sizes?
10:52 jnthn It delegates to malloc
11:04 samcv how do we decide when to free?
11:05 jnthn Needs an explicit free call
11:06 jnthn There's a "free now" and a "free at next safepoint"
11:06 jnthn Which today is implemented as "at the next GC run"
11:07 jnthn Since that obviously brings all thread to a safepoint
11:14 samcv ah ok
12:32 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:33 dogbert17 not ok 10 - got the right order
12:33 dogbert17 # Failed test 'got the right order' at t/spec/S17-promise/allof.t line 44
12:33 dogbert17 # expected: '0 1 2 3 4 5 6 7 8 9'
12:33 dogbert17 #      got: '0 1 2 4 3 5 6 7 9 8'
12:34 lizmat jnthn: in case of hanging tests, I do a `ps` and kill all but the main process manually
12:35 lizmat jnthn: that will give you the info of which test-files were hanging
12:37 jnthn lizmat: Yeah, that's what I did :)
12:38 AlexDaniel joined #moarvm
12:44 timotimo dogbert17: the test in allof.t requires timing to be correct. the overhead from asan might be enough to throw it off
12:45 timotimo it's even worse in valgrind because that makes everything run on just one thread
12:47 dogbert17 timotimo: yeah, with valgrind the order was 3 5 0 9 7 2 1 8 4 6 :)
12:47 timotimo yeah
12:47 dogbert17 is that a 'new test'
12:48 dogbert17 can't remember seeing it until quite recently
12:54 AlexDaniel joined #moarvm
13:07 bisectable6 joined #moarvm
13:19 jnthn I think they've been there for ages
13:20 timotimo it was sleeping
13:21 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? %)
13:22 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:23 jnthn Man, continuations...
13:23 * jnthn sets off another stresstest and goes for language class
13:24 jnthn Changing the internals of how supplies manage concurrency - especially supply *blocks* - is as tricky as I suspected.
13:24 dogbert17 Hodně štěstí
13:25 jnthn :)
13:25 jnthn &
14:09 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:11 timotimo aaaaand it crashed. fine.
14:22 timotimo did a little bit of warm-up for the whole profiler grant work :)
14:45 brrt joined #moarvm
14:55 travis-ci joined #moarvm
14:55 travis-ci MoarVM build canceled. Jimmy Zhuo 'Merge pull request #695 from usev6/patch-1
14:55 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/277443905 https://github.com/MoarVM/MoarVM/compare/3b4b0329847d...3a2eab52f7f9
14:55 travis-ci left #moarvm
15:06 domidumont joined #moarvm
15:08 * jnthn back
15:09 jnthn So it seems on the up side the hangs are all gone
15:10 jnthn On the downside, failures in 4 tests
15:33 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?
15:33 japhb ugexe: Our spectest caught their bugs?
15:34 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:35 timotimo ugexe: way cool.
15:35 japhb I'm very happy to hear that.  :-)
15:39 jnthn ugexe++
15:39 ugexe they have an impressive build/ci test matrix at their disposal
15:39 timotimo nooooo how did "git reset --hard origin/master" get into my shell history m(
15:40 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:41 timotimo oh, good, i had everything committed for once
15:43 jnthn Seems I've turned S17-supply/supplier-preserving.t from occasional failure to reliable failure also
15:51 timotimo The profiled code ran for 17.39ms. Of this, 0ms were spent on garbage collection (that's 0%).
15:51 timotimo The dynamic optimizer was active for 114.89% of the program's run time.
15:51 timotimo ^- this is certainly correct!!
15:52 jnthn :P
15:58 AlexDaniel joined #moarvm
16:00 brrt joined #moarvm
16:01 brrt good * #moarvm
16:05 timotimo MoarVM panic: Profiler lost sequence  -  wow, i've never seen this
16:05 timotimo surely this is about continuations
16:07 jnthn Mebbe, though it has code to handle those too
16:08 timotimo what about cross-thread continuations? :D
16:09 jnthn I'd have thought it could handle that too
16:11 timotimo if i get the grant i'll have a bunch of time i can spend on this whole business
16:12 timotimo ever since END got moved into rakudo code (or something?) it's harder to figure out explosions
16:12 timotimo Unhandled exception: getexpayload needs a VMException, got P6opaque (X::AdHoc)
16:13 jnthn If you have a golf that produces that, it'd be interesting
16:14 timotimo it passes a high-level exception to comp.handle_exception i believe
16:14 timotimo m: END { die "oh no" }
16:14 camelia rakudo-moar 78a482: OUTPUT: «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…»
16:14 timotimo oh, that was easy
16:16 timotimo i suspect i'll just have to getattr the exception out of the Exception?
16:16 jnthn Guess so
16:17 jnthn Darn, my changes to react/supply block concurrency control tank performance. :/
16:19 timotimo Don't know how to dump a BOOTCode  -  yikes, that's not so great
16:20 timotimo i wonder if i also have to grab the $!bt in order to see the backtrace in question
16:28 Ven`` joined #moarvm
16:36 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:44 timotimo 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 timotimo that should create many threads, i don't think it joins the threads at all
16:44 jnthn We prepend to the threads list, not append, iirc
16:44 timotimo oh, so main_thread is the wrong place to start?
16:44 jnthn Otherwise we'd have to walk the linked list every thread start
16:44 jnthn Yes
16:45 jnthn instance->threads is the right place
16:45 timotimo ah, yes
16:45 jnthn Also there is a mutex you should acquire if you want to walk it safely
16:46 leont joined #moarvm
16:47 timotimo well, i already forced a GC so that i can grab every thread's data safely
16:50 timotimo oooooh
16:50 timotimo ahahaha
16:52 timotimo that's a step forward. the profiler data somehow gets an NQPMu in it, though
16:52 timotimo wonder how that happens, but AFK first
17:51 samcv joined #moarvm
17:57 leont joined #moarvm
18:29 travis-ci joined #moarvm
18:29 travis-ci MoarVM build failed. Samantha McVey 'Fix utfc-c8 enc. for values > 0x10FFFF and surrogates
18:29 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/277657493 https://github.com/MoarVM/MoarVM/compare/3a2eab52f7f9...f112fbcff806
18:29 travis-ci left #moarvm
18:33 samcv yay now mac builds are broken :(
18:35 samcv i think i see what's happening
18:35 timotimo something about osx 10.11 and 10.12 or something?
18:42 Geth ¦ MoarVM: 523725a300 | (Samantha McVey)++ | build/Makefile.in
18:42 Geth ¦ MoarVM: Only include libuv posix-hrtime on *BSD not Darwin
18:42 Geth ¦ MoarVM:
18:42 Geth ¦ MoarVM: Was causing some MacOS versions to not build.
18:42 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/523725a300
18:43 samcv timotimo, seems like it
18:43 samcv timotimo, what version do you have?
18:43 timotimo i don't have any osx
18:43 samcv oh. i forgot who it was then
18:44 geekosaur joined #moarvm
19:13 vendethiel- joined #moarvm
19:17 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:34 samcv yeah
19:37 samcv i think i'm going to have all in bounds codepoints respond with uniname containing the hex code
19:38 samcv m: 0x10FFF.uniname.say
19:38 camelia rakudo-moar 78a482: OUTPUT: «<reserved>␤»
19:38 samcv like that would say <reserved-10FFFF>
19:38 samcv anything 0..10FFFF will give a unique response
19:50 AlexDaniel samcv: same with private use area maybe?
19:50 AlexDaniel u: U+E000
19:50 unicodable6 AlexDaniel, U+E000 <Private Use> [Co] ()
19:51 AlexDaniel <Private Use E0000> ?
19:52 AlexDaniel but I guess you already know about that
19:57 samcv yes same with everywhere
19:57 samcv anything with < in it
19:57 samcv which essentially is a non unique name identifier
19:57 samcv <Private Use-E0000>
19:58 samcv 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 samcv since names can include numbers
19:59 samcv well names can includes dashes too i suppose
20:01 AelxDnaiel IMO it makes sense, though I hope there is no poor soul out there checking for '<reserved>' exactly...
20:01 AelxDnaiel greppable6: reserved
20:01 greppable6 AelxDnaiel, https://gist.github.com/cb37189a8ee79a81c3ff77d5dd8bf443
20:03 AelxDnaiel greppable6: \<reserved
20:03 greppable6 AelxDnaiel, https://gist.github.com/9821b18a85f383a8c0e00dbb2a87ecc1
20:03 samcv like NUSHU CHARACTER-1B1AB
20:03 samcv but it has a < in it
21:27 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
21:27 yoleaux MasterDuke: I'll pass your message to jnthn.
21:44 travis-ci joined #moarvm
21:44 travis-ci MoarVM build passed. Samantha McVey 'Only include libuv posix-hrtime on *BSD not Darwin
21:44 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/277897868 https://github.com/MoarVM/MoarVM/compare/f112fbcff806...523725a3003a
21:44 travis-ci left #moarvm
22:20 AlexDaniel joined #moarvm
22:43 MasterDuke what's the max size before the fsa just uses regular MVM_malloc? is it less than 4096?
22:44 jnthn Surely
22:44 jnthn See fixedsizealloc.h
22:45 jnthn the multiply the maximum bins by the bin size to get it :)
22:46 jnthn 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:47 timotimo yeah, the bigger the items, the huger the page becomes
22:47 timotimo "The profiled code ran for 18446710383613.7ms."
22:47 timotimo it's getting better and better
22:48 jnthn m: say 18446710383613.7 / (1000 * 3600)
22:48 camelia rakudo-moar 78a482: OUTPUT: «5124086.217670472␤»
22:48 jnthn m: say 18446710383613.7 / (1000 * 3600 * 24 * 365.25)
22:48 camelia rakudo-moar 78a482: OUTPUT: «584.5409785159106␤»
22:48 jnthn 584 years!
22:48 timotimo i was quite patient
22:49 MasterDuke hm, then it looks like MVM_string_join is the only place i can switch to using the FSA
22:49 MasterDuke jnthn: unless you think timotimo++'s idea to use it for string storage is good?
22:49 timotimo i'd expect there's a negative number that's being stored in a unsigned var
22:49 jnthn Well, if you ask it for bigger it just falls back to malloc
22:49 timotimo m: say 184467103836137000.base(16)
22:49 camelia rakudo-moar 78a482: OUTPUT: «28F5BDA84E5E628␤»
22:49 jnthn MasterDuke: I'm not sure; it's one of those cases where we'd need to measure, I think
22:49 timotimo hm, that's not really something
22:50 jnthn Most strings are quite short
22:51 timotimo the number definitely shows up in the json blob
22:52 MasterDuke yeah, i'd definitely measure something
22:55 japhb timotimo: One too many zeros at the end?
22:55 japhb m: say 18446710383613700.base(16)
22:55 camelia rakudo-moar 78a482: OUTPUT: «41892F73B09704␤»
22:56 japhb m: say 18446710383613700000.base(16)
22:56 camelia rakudo-moar 78a482: OUTPUT: «FFFFE15BE9CDE7A0␤»
22:56 timotimo huh
22:56 japhb ^^ If it's microseconds instead of milliseconds
22:56 timotimo yeah
22:56 timotimo but even kicking off the Fs at the beginning ...
22:56 timotimo m: +^0xFFFFE15BE9CDE7A0
22:56 camelia rakudo-moar 78a482: OUTPUT: «WARNINGS for <tmp>:␤Useless use of "+^" in expression "+^0xFFFFE15BE9CDE7A0" in sink context (line 1)␤»
22:56 timotimo m: say +^0xFFFFE15BE9CDE7A0
22:56 camelia rakudo-moar 78a482: OUTPUT: «-18446710383613700001␤»
23:07 Geth ¦ MoarVM: MasterDuke17++ created pull request #698: Use the FSA for a temp alloc in MVM_string_join
23:07 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/698

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