00:02 TimToady joined
samcv well that's not good. it's a synthetic (non utf-c8 synthetic though it does have a utf8-c8 synthetic later in the string) 00:16
but the issue is a normal synthetic whose first cp is: L and the second one is 0xFFFFFFF9
oops no. the second one is synthetic -7 00:18
got the fprintf wrong. ok so it's a synthetic with a synthetic inside it. that or corruption
the results seem identical each time though 00:19
timotimo getting fprintf wrong is a thing i definitely do routinely 00:23
why isn't there a macro or something for "just output this piece of data correctly" 00:24
samcv synths inside synths!
deeper deeper!
ok i see what's happening. it created a synth which is L + utfc8-synth 00:25
argh
Geth MoarVM: dae72d2fb0 | (Samantha McVey)++ | src/strings/ops.c
If problem NFG_CHECK grapheme is a synth, give detailed info

Shows whether or not it is a utf8-c8 synthetic or not, as well as shows what the first two codepoints inside it as well as the total number of codepoints in the synthetic.		 00:33
samcv ok i think i found the problem :0 00:56
i just have to change a 0 to a 1 and things i think will work. running spectest now
does it count as off by one if a 0 should be a 1
MasterDuke_ definitely. is this something it's easy to add a roast test for? 00:57
samcv if i forget to run make spectest without nice -n 19, my system starts lagging really badly when NFG_CHECK is on
i'm sure the memory pressure must be pretty bad runniig 9 threads
hmm well we ca utf8-c8 synthetic and something else i guess but the problem becomes they're going to probably match fine 00:58
maybe using .NFG on it hm
though .NFG i think will flatten utf8-c8
i can't run t/02-rakudo/08-repeat.t with NFG_CHECK i run out of memory 00:59
anyway gonna run make spectest and make sure no more NFG_CHECK problems 01:02
MasterDuke_ good deal 01:10
Geth MoarVM: a0dc2747c3 | (Samantha McVey)++ | src/strings/normalize.c
Fix bug causing utf8-c8 synthetics to combine with other codepoints

Fixes a bug in MVM_unicode_normalize_should_break() where it returned 0 incorrectly when it should have been returning 1 to indicate NO break.		 01:18
samcv fixed. and all is good with the world once again :)
m: use nqp; (nqp::indexingoptimized('L' ~ Buf.new(255).decode(<utf8-c8>))).chars.say 01:22
camelia 1
samcv MasterDuke: this triggers it
but we can't use indexingoptimized in roast
and just concatting by itself doesn't trigger it
MasterDuke so run a regex on the string, that calls indexingoptimized 01:23
samcv good point 01:24
well. no. it doesn't return the string
though it won't match now
timotimo maybe put it into t/rakudo or nqp's test suite instead?
samcv say ('L' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/
evalable6 Nil
samcv m: say ('L' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/
camelia Nil
samcv m: say ('LL' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/ 01:25
camelia ļ½¢Lļ½£
samcv m: say ('L' ~ Buf.new(255).decode(<utf8-c8>)) ~~ /L/
camelia Nil
samcv yeah so that shows it
ok i found where to put it 01:29
MasterDuke cool, more tests are good 01:30
Geth MoarVM/in-situ-strings: e8f01d9c0f | (Timo Paulssen)++ | 6 files
store short strings inside string's body

uses the 8 bytes that the pointer to a buffer usually takes and puts up to 8 8-bit characters into it.
Currently causes trouble with regex matches.		 01:31
MoarVM/in-situ-strings: 8caa9736ab | (Timo Paulssen)++ | src/strings/ops.c
teach string_char_at_in_string about in_situ
timotimo (a rebase and one extra commit)
MasterDuke timotimo: did you see my comment the first time you pushed? 01:32
timotimo it looks like string_char_at_in_string was what caused regexes to be unhappy in nqp's test suite
cool, it survives stresstest 01:56
MasterDuke timotimo: it looks like the ` char *result_c;` at line 48 in latin1.c can be removed 01:59
timotimo oh, that's left over from debugging 02:01
Geth MoarVM/in-situ-strings: 1c4aba109d | (Timo Paulssen)++ | src/strings/latin1.c
remove left-over debugging, MasterDuke++
MasterDuke very cool. what sort of savings are you seeing? 02:06
timotimo depends strongly on the workload
samcv timotimo: will we be able to store 2 32 bit graphemes in the poniter too? 02:07
timotimo 50 megs saved in combing the core setting into an array 02:08
yes, that needs more code though :)
samcv combing it?
timotimo yeah, my @foo = "CORE.setting".IO.comb
samcv also the reason you are doing this is to reduce memory usage or allocations?
timotimo so it keeps all the strings around
samcv ah
timotimo saves an allocation for very short strings, one less pointer deref you have to do if you operate on it 02:09
lots of reasons
samcv yeah
for sure
with comb i can *totally* see the benefit
timotimo need to adjust lots of fastpaths that don't know about the new storage type
these 50 megs of savings were about 25 bytes per character in the file combed 02:15
that was only a little piece of total memory usage though 02:16
Geth MoarVM/in-situ-strings: 1afd45e895 | (Timo Paulssen)++ | src/strings/ops.c
create in situ for nqp::chr if it fits into 8bit.
 02:18
MasterDuke timotimo: just curious, but in the changes you made to MVM_string_latin1_decode and iterate_gi_into_string, would it be beneficial to use the fsa for *old (since you know it's going to be small) 02:26
timotimo that would require MVMString to learn about fsa in general 02:30
as old is just the pointer stolen from the blob_8
MasterDuke oh, duh, of course 02:32
hm, maybe need to work on my fsa_for_strings_storage branch some more 02:33
timotimo hm, i added in situ 32 but my gc_mark code still points out a big amount of 32bit strings with 2 or fewer graphemes 02:43
anyway, bedtime. 02:54
MasterDuke later...
02:56 ilbot3 joined
samcv timotimo: sounds fun 05:41
06:47 ilbot3 joined 06:51 domidumont joined
nine timotimo: doesn't this cause a lot of branching in string handling code? 07:22
07:46 brrt joined 07:59 lizmat joined 08:24 domidumont joined 08:57 zakharyas joined 09:12 zakharyas joined 10:14 AlexDaniel joined 10:25 robertle joined
brrt good * #moarvm 11:11
yoleaux 14 Nov 2017 17:15Z <jnthn> brrt: the branch inline-lastexpayload fails t/02-rakudo/repl.t but works without the expr JIT. The problem is in the code at Proc.pm:73 in Rakudo; the try thunk is inlined into the enclosing block (not new, I think), but now the .receive method was inlined into the thunk with my branch. So it seems to have needed the nested inline to trigger it.
brrt thanks jnthn 11:20
i will try and debug it
13:31 zakharyas joined 14:07 lizmat joined 14:42 zakharyas joined
timotimo nine: we already branch a bunch for the other storage strategies 15:15
15:24 robertle joined 16:05 brrt joined 17:32 releasable6 joined 17:41 domidumont joined
samcv good * 17:52
Zoffix \o 18:01
18:16 zakharyas joined 18:25 zakharyas joined 18:32 zakharyas joined, nwc10 joined 18:56 dogbert17 joined 18:59 AlexDaniel joined
dogbert17 o/ 18:59
.seen samcv 19:01
yoleaux I saw samcv 18:07Z in #perl6-dev: <samcv> i mean select them on my amazon smile profile that is
dogbert17 .tell samcv have a SEGV which might be of interest, gist.github.com/dogbert17/52ce8a69...b6114a379a 19:02
yoleaux dogbert17: I'll pass your message to samcv.
samcv gcc should remove conditionals that can never be triggered right 19:03
yoleaux 19:02Z <dogbert17> samcv: have a SEGV which might be of interest, gist.github.com/dogbert17/52ce8a69...b6114a379a
samcv dogbert17: are you using the latest MVM?
dogbert17 yes 19:06
MoarVM version 2017.10-80-ga0dc2747 19:07
samcv well that runs out of memory for me at least with strict on 19:08
not sure about without strict
dogbert17 valgrind says the following before the SEGV 19:12
==17656== Invalid write of size 4
==17656== at 0x41C6A97: re_nfg (ops.c:287)
==17656== by 0x41C5F22: NFG_checker (ops.c:80)
==17656== by 0x41C615E: NFG_check_concat (ops.c:120)
==17656== Address 0xa5f5140 is 0 bytes after a block of size 0 alloc'd
the last line feels a bit strange 19:13
samcv i will check that in a bit. thanks 19:17
dogbert17 yay :) 19:21
samcv dogbert17: we can't throw inside MVMROOT right? 19:31
dogbert17 I don't know :( 19:32
timotimo probably problematic to do that 19:41
but since it's equivalent to a return, and the end of the mvmroot block is just a pop or pop_n, you can probably get away with putting a pop in place before the throw 19:42
i'd probably convert the whole mvmroot macro into push and pop instructions instead, though
samcv i mean can't it throw inside another function you call 19:46
you have an MVMROOT and then inside it you call a function. which happens to throw
then what
i'm sure that happens
Geth MoarVM: samcv++ created pull request #753:
collapse_strands with memcpy if all strands are same type 4x faster		 20:23
samcv sadly with this PR compliing the core setting is slower 21:06
not sure why yet
going to try working to reduce the branching 21:12
ok i believe i fixed the issue 21:48
timotimo hmm. if that happens, that's probably kinda bad 22:13
because then there'd be pointers pointing at random locations in stackframes 22:14
or maybe we have a baseline of temp roots that we just restore to when an exception jumps things around 22:16
ah yes 22:17
throw_adhoc_free_va does MVM_gc_root_temp_pop_all near the end 22:18
samcv ah ok timotimo 22:23
so i don't have to worry about it then?
timotimo looks like no 22:45
jnthn Yeah, I designed it so you can throw and not worry about what's on the temp root stack 22:59
The problem isn't so much local throwing, but you'd have to never *call* something in MVMROOT that might throw, and that'd be...very awkward. :)
23:37 lizmat joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!