MasterDuke huh. reading a 10k line csv file results in ~600k MVM_string_equal calls with a and b both equal to 'note', and ~600k MVM_string_equal calls with a and b both equal to 'sink' 03:24
MasterDuke whoops, when b is equal to 'note' a is equal to 'sink' 04:28
i don't understand the backtrace i'm looking at 04:31
i added `if (strcmp(MVM_string_utf8_encode_C_string(tc, b), "note") == 0) fprint(...)` and set a breakpoint on the fprintf 04:32
#0 MVM_string_equal (tc=tc@entry=0x555555758c40, a=a@entry=0x5555561fe110, b=0x55555617c980) at src/strings/ops.c:1321 04:33
#1 0x00007ffff76a0961 in at_key (tc=0x555555758c40, st=<optimized out>, root=<optimized out>, data=0x555556b562c8, key_obj=0x5555561fe110, result=0x7fffffffd5a0, kind=8) at src/6model/reprs/MVMHash.c:74
but github.com/MoarVM/MoarVM/blob/mast...Hash.c#L74 doesn't have a call to MVM_string_equal, even if you decend into the MVM_HASH_GET macro 04:34
samcv would people mind reading my RFC and commenting on it? github.com/MoarVM/MoarVM/pull/798 06:53
and that my approach is right. even if you don't read the diff i made, the summary would be nice to hear your thoughts on if i should rework anything, or ideas for the names
nine samcv: I couldn't find out the reason for the configuration flags you add. If there's decode and decoderep (decode with replacement?) what's left to configure? 07:36
nine samcv: but don't read too much into it, I'm in a bit of a hurry and very much preoccupied :) 07:36
samcv nine: currently it doesn't throw when you encode/decode codepoint swith no mapping 07:37
like codepoint 129 is invalid in windows-1252 and most programs will refuse to decode it. including perl 5 and python
so we can create invalid output
and read something that may not even be windows-1252
brrt i'll read it as well :-) 07:38
good * #moarvm
samcv so the configuration is to allow you to make it strict, how basically all other programming languages operate
brrt: good *
also we were missing encoderep
so my proposal to make 6.d default to strict encoding of text, so we don't create output that can't be read using other programs 07:39
so these new ops will semi-replace the old ones in the code and when 6.d is enabled we will default to only decoding/encoding valid data 07:40
brrt that seems like a pretty valid goal, yeah 07:42
nine samcv: ok. I guess what threw me off is that there's a code path ending up in throwing "Error encoding Latin-1 string: could not encode codepoint %d" 07:43
samcv nine: ah. that only throws if you try and encode lets say 0x19999 which has no mapping
but if it's codepoint 129 or the other 12 or so ones that have no mapping in windows-1252, it will put them in there anyway 07:44
nine Couldn't we just use an empty replacement string as flag?
samcv but then we still need to make replacement strict. because atm it only replaces when it would normally throw 07:45
so even with encoderep it will still encode invalid codepoints like 129 and not do a replacement 07:46
but i may want the new ops to default to strict, instead of having to set the flag as `1` to get strict 07:49
though i made it the current way so they operated the same if you gave the flag as 0. i'm not sure which is a better idea.
samcv can we make libatomic_ops into a submodule? 12:29
either we should fork their repo or just link straight to theirs 12:30
it's not totally clear exactly what changes were made or not made 12:33
when it was first commited it says it is modified, but not how 12:34
" Import modified f38b2904 of ivmai/libatomic_ops"
brrt hmm when did that happen? 14:39
japhb nine: empty replacement string is not a flag that you want laxity or strictness. If any thing, it really would mean "ignore/drop/delete any non-conforming codepoints" 18:38
nine japhb: excellent point! 18:40
geekosaur samcv, my irc log suggests that upstream was being slow about incorporating bug fixes that moarvm needed 18:42
[Coke] we could fork and maintain a copy, I suppose? 19:02
(ah, samcv just said that!)
sorry, should review better
geekosaur that's what we are doing now 19:03
if upstream is actually tracking stuff now then it could be changed... until next time they lag
nine Geth seems to be asleep 21:13
Remove superfluous DEOPT_ONE_INS annotation on some deconts
In general decont may invoke, thus it carries a DEOPT_ONE_INS annotation.
However in cases were we know from the container spec, that it doesn't invoke,
we can remove that annotation again to keep the spesh graph a little cleaner.
Review: github.com/MoarVM/MoarVM/commit/4f...31520b6d62
MasterDuke anyone see my comments/questions from last night? irclog.perlgeek.de/moarvm/2018-02-08#i_15791778 21:27
jnthn Heard today that news.perlfoundation.org/2018/01/gra...l-6-1.html is being voted on in TPF, so hopefully approved soon. Which is nice 'cus I'll have some time to spend on it soon also. :) 21:43
samcv geekosaur: they've released new versions since then it seems 21:58
what i did is i extracted 3rdparty/libatomic_ops's commits into its own repo. then i merged that repo into the official libatomic_ops repo. so then we will have a repo based on both ours and their branch 22:00
but ours is mostly the same
just some minor changes
should let us make it easier to merge in new versions as they come out 22:01
it didn't merge cleanly originall, but i merged our version and their version at the last time we updated it to an actual release of theirs. and then after that I merged again with the latest release of theirs. which made it much easier 22:06
many less merge conflicts
samcv jnthn: I get a failure with NativeCall and uint32 i think it is 22:34
but not when using --has-libffi
this has been an issue for a long while, but i'm not sure how to diagnose since i'm not familiar with that section of the codebase 22:35
jnthn Hm, then it's probably something in either dyncall itself or (more likely) in our use of it (in nativecall_dyncall.c iirc) 22:36
gotta go for a bit
samcv o/ 22:38
Geth MoarVM: samcv++ created pull request #799:
Add libatomic_ops as a submodule instead of in-tree		 23:26

Powered by Cro and the Raku® Programming Language.

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

Thank you!