| ShimmerFairy | timo: I didn't check it at the time, but looking now, I think the issue there is that, in general, unassigned codepoints have the XX Line_Break value, but certain ranges of unassigned codepoints *instead* are assigned the value ID. So I think UnipropCheck is saying that MoarVM did (maybe still does?) return XX for unassigned points it should say ID on. | 04:19 | |||||||||||||||||||||||||||||||||||||
| (Ideally, *none* of that %expected-loses workaround would exist, but Rakudo's unicode property handling leaves something to be desired at the moment anyway.) | 04:21 | ||||||||||||||||||||||||||||||||||||||
|
05:50
kjp left
05:51
kjp joined
05:52
kjp left
05:53
kjp joined
|
|||||||||||||||||||||||||||||||||||||||
| ab5tract | ShimmerFairy: I opened a problem solving ticket about uniprop a year or two ago but never managed to get a response :( | 07:34 | |||||||||||||||||||||||||||||||||||||
| or | 07:44 | ||||||||||||||||||||||||||||||||||||||
| I should say I failed to spark a vibrant discussion | 07:45 | ||||||||||||||||||||||||||||||||||||||
| in short, my position is: the uni* family feels like it was designed prior to multiple dispatch, adverbs, and failure objects. At least it fails to utilize any of the above | 08:04 | ||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | Something I've been wondering about is how "outdated" the Unicode handling is in Raku, given the language's age. It's worth remembering that when Perl 6 got its start, Unicode was "only" about 10 years old, and things have definitely changed since then. | 08:24 | |||||||||||||||||||||||||||||||||||||
| One concrete example is that S05 makes reference to NFG strings doing caseless matching as per UTS#18 RL2.4, but if you look that up in modern versions of UTS#18 that rule has been all but gutted, explicitly stating that full case-insensitive matching is too difficult to expect most regex engines to handle. (The modern version of the rule is that the existence of Str.fc() is enough to satisfy.) | 08:26 | ||||||||||||||||||||||||||||||||||||||
|
08:44
librasteve_ joined
|
|||||||||||||||||||||||||||||||||||||||
| Geth | nqp/main: d200536e77 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION Bump MoarVM to get outdated pointer fix, timo++ |
09:13 | |||||||||||||||||||||||||||||||||||||
| patrickb | timo: Can you give me a bit more information regarding src/spesh/disp.c? That's concerned with streamlining / generating byte code for the things in lib/NativeCall/Dispatcher.rakumod, correct? If so I would have thought that no changes are necessary. I probably miss something. Can you clarify? | 09:18 | |||||||||||||||||||||||||||||||||||||
| timo | sure, are you familiar with how the dispatch program mechanism works internally? | 09:21 | |||||||||||||||||||||||||||||||||||||
| the part in spesh/disp.c is concerned with turning what would normally be interpreted by the dispatch program interpreter into bytecode instructions, so that further optimizations as well as the JIT can make things better | 09:23 | ||||||||||||||||||||||||||||||||||||||
| patrickb | I read jnthns blog posts twice. But that's about it. | ||||||||||||||||||||||||||||||||||||||
| timo | i'm thinking if you didn't put anything for handling variadic calls into the jit, we need to at least go through nativecall_dispatch or nativecall_invoke rather than jitting a C function call ourselves | 09:24 | |||||||||||||||||||||||||||||||||||||
| patrickb | Initially the dispatch program is some C structure that is worked through? | ||||||||||||||||||||||||||||||||||||||
| timo | that's right | 09:25 | |||||||||||||||||||||||||||||||||||||
| patrickb | Sidenote: I think nativecall_invoke is entirely unused dead code and could be removed. | ||||||||||||||||||||||||||||||||||||||
| timo | the debugging utilities for dispatch programs and dispatch recordings are a bit crude still | ||||||||||||||||||||||||||||||||||||||
| right, i suspected that that's the implementation we had before dispatch landed and was completely superceded | 09:26 | ||||||||||||||||||||||||||||||||||||||
| patrickb | nativecalls always end up in nativecall_dispatch. There is no not / ops only variant of the code in that function, right? | 09:27 | |||||||||||||||||||||||||||||||||||||
| timo | how do you mean? | ||||||||||||||||||||||||||||||||||||||
| patrickb | s/not/jit/ | ||||||||||||||||||||||||||||||||||||||
| the nativecall_dispatch function does the actual setup and dynamic call using either dyncall or libffi. I can't possibly have missed a separate machinery doing the same thing via ops or jit machine code. Right? | 09:29 | ||||||||||||||||||||||||||||||||||||||
| So in other words I don't have to reproduce the same changes I made to nativecall_dispatch again some place else (as one sometimes has to do for jittable opcodes). | 09:30 | ||||||||||||||||||||||||||||||||||||||
| Geth | rakudo/main: 820a4a94a7 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP to get outdated pointer fix, timo++ |
09:59 | |||||||||||||||||||||||||||||||||||||
| timo | sorry i was AFK for a moment | 10:04 | |||||||||||||||||||||||||||||||||||||
| if the result from speshing the disp that belongs to a native call is still a sp_dispatch_*, src/jit/graph.c:3975 and following will spit out a MVM_JIT_NODE_DISPATCH that src/jit/x64/emit.dasc:3436 will turn into a low-level function call, but the function call goes to the run_dispatch function pointer that's stored in the inline cache entry | 10:08 | ||||||||||||||||||||||||||||||||||||||
| oh, actually, right above that in graph.c is handling for sp_runnativecall_* | 10:09 | ||||||||||||||||||||||||||||||||||||||
| that has a corresponding MVM_jit_emit_runnativecall in emit.dasc:3378 | 10:10 | ||||||||||||||||||||||||||||||||||||||
| the good thing about jitting is that we don't have any need for dyncall or libffi at all | 10:11 | ||||||||||||||||||||||||||||||||||||||
| emit_posix_callargs and emit_win64_callargs would probably be the spot where handling the difference between before and after the `...` in the argument list would have to happen | 10:12 | ||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | By the way, I've always been curious about why we got rid of the Cursor/Match distinction. I just did a bit of digging, and am I right in concluding that it was "just" to avoid expensive copies? (As opposed to a deeper flaw in how the design of the whole system worked with two classes?) | 10:38 | |||||||||||||||||||||||||||||||||||||
| releasable6 | Next release in ≈3 days and ≈7 hours. There are no known blockers. Please log your changes in the ChangeLog: github.com/rakudo/rakudo/wiki/ChangeLog-Draft | 11:00 | |||||||||||||||||||||||||||||||||||||
| patrickb | timo: Oh. I absolutely didn't see that. Thanks for pointing me at that. This means var-args are pretty broken as soon as the jit kicks in, right? | 11:01 | |||||||||||||||||||||||||||||||||||||
| timo | that might be true | 11:09 | |||||||||||||||||||||||||||||||||||||
| lizmat | and that's why I didn't see and breakage on Apple Silicon | 11:12 | |||||||||||||||||||||||||||||||||||||
| timo | the nativecall tests we have are a little weak, i don't think they would show us if nativecall jitting was completely broken | 11:27 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy: i don't know anything more than what you already concluded | |||||||||||||||||||||||||||||||||||||||
| ShimmerFairy | For context, I'm only curious because I've been hacking together a grammar thingy in C++, and I've reached a point where splitting my one cursor class into two could make sense, but I was worried that there was a very good reason Raku went the exact opposite direction. | 11:31 | |||||||||||||||||||||||||||||||||||||
| timo | i assume you already went and read commit logs related to the changes? | 11:32 | |||||||||||||||||||||||||||||||||||||
| lizmat | if I remember correctly, originally there was a Match and a Cursor object ($/ and $cent), but at some point @larry decided that it would be better to have one | 11:33 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy | Yeah, that's how I finally answered my long-standing question. I asked here just to see if there was a second hidden reason. | 11:34 | |||||||||||||||||||||||||||||||||||||
| timo | it's really not trivial to follow such decision processes after the fact, is it? the problem-solving repo is a good thing to have | 11:36 | |||||||||||||||||||||||||||||||||||||
| ShimmerFairy | I still love $¢, even if there's no reason to type it anymore. Having forced myself to go through the steps of implementing a grammar engine, my feeling is that (aside from real-world efficiency concerns), there's no major benefit either way to having separate or joined Match/Cursor objects. | ||||||||||||||||||||||||||||||||||||||
| Personally, I think I prefer having a clean distinction between in-progress and completed searches, but in reality those two concepts are similar enough that smushing them into one class is barely noticeable. | 11:39 | ||||||||||||||||||||||||||||||||||||||
|
11:46
finanalyst joined
|
|||||||||||||||||||||||||||||||||||||||
| [Tux] |
|
12:01 | |||||||||||||||||||||||||||||||||||||
| csv-test-xs 0.014 - 0.014 | |||||||||||||||||||||||||||||||||||||||
| tux.nl/Talks/CSV6/speed4-20.html / tux.nl/Talks/CSV6/speed4.html tux.nl/Talks/CSV6/speed.log | |||||||||||||||||||||||||||||||||||||||