|
02:00
statisfiable6 joined
02:07
colomon_ joined
02:56
ilbot3 joined
|
|||
| 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 | |
|
04:11
reportable6 joined,
coverable6 joined
04:12
bloatable6 joined,
bisectable6 joined,
notable6 joined,
quotable6 joined,
greppable6 joined
|
|||
| 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 | ||
|
06:43
domidumont joined
06:49
domidumont joined
|
|||
| 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 | |||
|
07:23
domidumont joined
|
|||
| 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 | |
|
07:36
brrt joined
|
|||
| 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. | |||
|
09:16
zakharyas joined
09:20
zakharyas joined
09:24
Ven`` joined
09:48
zakharyas1 joined
09:54
AlexDaniel joined
10:39
zakharyas joined
11:17
zakharyas joined
11:25
Ven`` joined,
brrt joined
|
|||
| 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" | |||
|
13:44
zakharyas joined
|
|||
| brrt | hmm when did that happen? | 14:39 | |
|
14:43
zakharyas joined
14:52
zakharyas joined
15:26
Ven`` joined
15:37
colomon_ joined
15:42
colomon_ joined
17:42
brrt joined
17:57
domidumont joined
18:15
zakharyas joined
|
|||
| 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 | |||
|
19:54
bloatable6 joined,
squashable6 joined,
quotable6 joined,
zakharyas joined
20:23
Kaiepi joined
|
|||
| 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 | |
|
21:31
ChanServ joined
|
|||
| 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 | |||
|
22:14
brrt joined
22:18
dalek joined,
Geth joined,
p6lert joined,
synopsebot joined,
SourceBaby joined
|
|||
| 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 | |
|
22:45
evalable6 joined
23:11
jnthn joined
|
|||
| Geth | MoarVM: samcv++ created pull request #799: Add libatomic_ops as a submodule instead of in-tree |
23:26 | |