| 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 | ||