4 Dec 2021
nine That or somehow use mixins or something like that to get the appropriate methods 20:22
MasterDuke sena_kun, jnthnwrthngtn: fyi, the cert for commaide.com expired today 20:33
but i accepted the risk and continued, because i want to try out the heap snapshot viewer 20:37
Geth MoarVM: MasterDuke17++ created pull request #1617:
Alloca the nativecall args that we can		 21:25
lizmat nine: I wouldn't worry about the performance in that respect: we can easily generate the code for using atpos_u vs atpos_i 22:36
timo and put everything spesh has that's already working for atpos_i to work in atpos_u without any change i assume 22:48
sena_kun MasterDuke, not sure if jnthn was that quick, but cannot confirm, it says valid to 5 March to me. 23:14
MasterDuke huh. someone else in #raku got the same message, but i'm not getting it now 23:16
timo it's the difference between www.commaide.com and commaide.com i think 23:17
without www i can access it fine, otherwise i get a security warning
5 Dec 2021
nine This is suprising: 3KLOC in the static optimizer, but what we don't optimize is branches with constant conditions. Thus my constant \debug = 0; if debug { ... } does carry an unexpected runtime cost. 09:57
All the more surprising since it looks kinda trivial to do. It even worked on my very first try (which actually makes me a bit nervous about it) 09:58
dogbert17 nine: are there any noticable improvements? 11:01
nine dogbert17: I have too many half-finished local changes to properly test 11:23
But with "is pure" traits for NQP routines, p6callmethodhow constant folding and conditional constant folding all implemented something like uint.^unsigned ?? nqp::atpos_u(...) !! nqp::atpos_i(...) will now be optimized to just nqp::atpos_u(...) 11:31
So...win? Unfortunately not :/ Because Blob is generic, so instead of uint which is a NativeHOW with a pure unsigned method, the optimizer sees T which is a GenericHOW. 11:32
So while this was a fun exercise, I'll have to go the native_array route with a custom ^parameterize method 11:38
lizmat meh 11:42
nine Huh....after moving methods into appropriate roles and adding $?CLASS.^add_role(T.^unsigned ?? UnsignedBlob[T] !! SignedBlob[T]); to Blob's role body, printing fails with "encode requires a native int array". Apparently we lose the native size along the way 13:21
lizmat meh again 13:22
nine Normally there's a ^set_array_type call on Blob followed by utf8. But now it's Blob followed by UnsignedBlob. It's not set anymore on utf8. 13:58
I don't really understand where things go wrong, but at least I have a fix anyway: teach the RoleToRoleApplier to copy over array_type just like the RoleToClassApplier does 14:22
Next up: Multi method 'AT-POS' with signature :(Buf:D: int \pos, *%_) must be resolved by class Buf because it exists in multiple roles (UnsignedBlob, UnsignedBuf) 14:23
timo time for "is default"?
nine Doesn't seem to help 14:26
FWIW the "is default" trait is not documented for this purpose anyway 14:30
And the docs saying "cause a compile-time error, which can be solved by providing a method of the same name in the class" is rather unhelpful as well. There is a reason for _not_ having these methods in the class in the first place
timo hm, add a proto somewhere? 14:43
nine Replacing ::?CLASS with ::?ROLE seems to help 14:49
Though I'm not sure how Rakudo finds the right method this way. After all the resulting class does both roles 14:52
timo and both are in there? 14:56
nine I guess so. So far it works, so I don't feel like investigating further. 15:21
make test looks good. spectest yields a ton of "MVMArray: atpos U32 expected int register" like errors
Because e.g. class native_i does PredictiveIterator # Class for iterating native int arrays and nqp::list_i 15:25
Yes, int arrays. Not uint arrays which we're also using them for 15:26
# Expected: Cannot unbox 101 bit wide bigint into native integer 16:08
# Got: Cannot unbox 101 bit wide bigint into native integer in mp_get_int64
Ah, yes...
Bad VM, giving more information...
MasterDuke did you make the change to the error message? looks like something i would have done 17:07
nine yes I did 17:08
MasterDuke ah
i'm pretty sure i've done something exactly like that while attempting to debug the gmp branch on windows 17:09
[Coke] I can volunteer to clean up roast if you have a branch for that change. 17:16
(where clean up == make those error checks partial matches instead of exact)
nine I may have gotten a little grumpy earlier due to the numerous road blocks. Luckily that was nothing a few more passing tests and indian cuisine can't fix :) 18:22
[Coke] I'm also happy to buy any core developers a curry whenever they need it. :) 19:08
bartolin just for the record (since Geth the loggers seem to be away): I unfudged one test for the JVM backend: github.com/Raku/roast/commit/3dfb6eb044 19:38
Nicholas \o/ 19:39
good *, JVM
bartolin oops, wrong channel! but good *, MoarVM 19:40
nine .tell jnthnwrthngtn I'm trying to fix our handling of unsigneds (mostly in arrays). So far 20 files changed, 508 insertions(+), 188 deletions(-) in MoarVM, 13 files changed, 1249 insertions(+), 264 deletions(-) in rakudo. New uint box type, several new ops, enough trickery to avoid runtime cost. 21:42
tellable6 nine, I'll pass your message to jnthnwrthngtn
nine .tell jnthnwrthngtn I wonder: am I actually on the right track? So far we've coped by mostly ignoring the signed/unsigned distinction, just like a hardware CPU does. The only difference to the VM is that we're trying to throw appropriate errors for overruns. Is all the added complexity and volume worth that? Or should we maybe push those boundary checks to HLL instead? 21:43
tellable6 nine, I'll pass your message to jnthnwrthngtn
MasterDuke nine: by "push boundary checks to HLL" do you mean in something like AT-POS? 21:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!