Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:05 reportable6 left 01:28 linkable6 left, evalable6 left
[Coke] someone could go through now and find commits like github.com/MoarVM/MoarVM/commit/1003874b2 and start throwing them in the recommended file 01:29
01:29 evalable6 joined 02:04 frost joined 03:30 linkable6 joined 03:58 frost left 05:06 reportable6 joined 06:06 reportable6 left 06:15 frost joined 07:15 evalable6 left, linkable6 left 07:17 evalable6 joined 08:14 frost left 09:07 reportable6 joined
Geth MoarVM: 280c709ce0 | (Stefan Seifert)++ | src/spesh/disp.c
Fix spesh breaking non-int/long rw args of native calls

We only generated code for handling int, long and long long rw args of speshed/jited NativeCalls, not other types, but proceeded with speshing anyway. We really need to abort when encountering unsupported types. Otherwise those rw args won't get updated.
Fixes Rakudo issue #4749		 09:16
lizmat nine++ 09:18
worthy of a bump ?
nine Definitely 09:19
lizmat ok, will do
nine thanks :)
Adding rw support for other integer types is quite trivial. Except for CPointer. We cannot update those via assign_i or assign_u ops as we do for native refs. NativeCall instead calls the set_int box function, but there is no op for doing just that. 09:31
Funny that for precicely this oddity there's a PR to docs from just 2 hours ago: github.com/Raku/doc/pull/402 09:48
It explains that for an rw pointer, one needs to pass an existing Pointer object, so it can get updated by NativeCall. Which is really just not how rw args in general work in Raku
lizmat nine: [Tux] saw a performance drop, not sure it was the latest bump or the commit before 09:53
11:18 linkable6 joined 12:06 reportable6 left 13:06 sena_kun left, sena_kun joined 13:08 reportable6 joined 13:49 Altai-man joined 13:52 sena_kun left 14:00 discord-raku-bot left, discord-raku-bot joined
[Coke] github.com/Raku/doc/pull/4026 #402 is something else 15:44
nine [Coke]: oh, thanks! 16:03
[Coke] it helpfully directed me to issue 402, where I had made a snarky comment in 2016. :) 16:39
nine There is no op for calling a repr's set_int functions. But there is sp_bind_i64 for writing a struct's attribute directly. And quite surprisingly, this seems to have worked on the very first try! 16:45
With that I've got full spesh coverage of rw args in native calls
Geth MoarVM/support_all_kinds_of_rw_args_on_native_calls_in_spesh: 311e099d1f | (Stefan Seifert)++ | src/spesh/disp.c
Support alll kinds of rw args on native calls in spesh

So far, we've only supported the larger integer types for rw args when speshing native calls. Extend this support to all sizes, unsigned integers and pointers.
Since CPointer objects get passed as-is, not as native refs, we need to update them in-place via sp_bind_i64 instead of assigning into the ref.		 16:50
16:58 [Coke] left 17:16 [Coke] joined
jnthnwrthngtn nine: Spesh coverage meaning "we can JIT them all"? 17:18
nine jnthnwrthngtn: yes 17:28
Geth MoarVM/support_all_kinds_of_rw_args_on_native_calls_in_spesh: da649cd208 | (Stefan Seifert)++ | src/spesh/disp.c
Support all kinds of rw args on native calls in spesh

So far, we've only supported the larger integer types for rw args when speshing native calls. Extend this support to all sizes, unsigned integers and pointers.
Since CPointer objects get passed as-is, not as native refs, we need to update them in-place via sp_bind_i64 instead of assigning into the ref.
nine (just fixed the typo in the commit message)
jnthnwrthngtn Cool :) 17:29
nine Btw. if I can somehow get my uint $t = 0; $t = $t + 2; to perform the same as $t = $t + my uint $ = 2; I can get sieve.raku down to 0.79s which is less than a factor of 2 away from Perl's 0.43s 17:37
lizmat perhaps it is time to codegen integer values that are small enough to fit in a native int, as a native int ? 17:39
and if positive, as a uint even ?
nine Thing is....I think it already should. Perl6::World.add_numeric_constant creates a QAST::IVal node and QASTCompilerMAST turns that into a const_i64 instruction. So the question is: why doesn't it work out this way in my case? 17:59
The QAST::Want might get in the way 18:03
18:08 reportable6 left 18:09 reportable6 joined
[Coke] looking at the cleanup branches ticket; there are 37 merged branches in Moarvm - anyone mind if I delete those in the next day or so? 18:31
I can post a list of who last committed to them when, but then include (e.g.) asan_fixes, fix-intern-lookup, etc. 18:32
(there are nearly 200 unmerged branches) 18:37
oldest of which are 8+ years 18:39
is there some standard for what do with old stuff like that we're not ready to delete? move it to origin/archive/ ?
19:31 linkable6 left 19:33 linkable6 joined 19:34 linkable6 left 20:36 linkable6 joined
jnthnwrthngtn I can't imagine anybody objecting to cleaning up merged branches 20:38
[Coke] jnthnwrthngtn: danke 20:39
jnthnwrthngtn: you had one of the oldest unmerged, btw. :)
nine Well merged branches are not of much use. Unmerged ones however can still be useful. E.e. there's the more_asan_fixes branch which I I do intend to get back to, despite the last commit being over a year old
[Coke] jnthnwrthngtn: gen2-frames, set-removal are both 8+ years 20:41
nine Oh, there's my gc_torture branch which is not meant to be merged ever but still useful :) 20:48
[Coke] what about new-disp? 20:58
it's merged, but is it special enough to save or tag?
cleaned up everything merged except new-disp & ryu, which I can see but cannot delete. 21:08
I can't see ryu on the website; weird. 21:11
jnthnwrthngtn [Coke]: I guess I'm the oldest here in moar years :) 21:15
Anything of mine that's unmerged and older than 4 years can be deleted; it'll have surely bitrotted enormously 21:16
[Coke] ok. I'll get that list and see if any of the names stand out for you, though. 21:17
/speculative-calls /nine-try-this-fix /deterministic-ucd2c /slower/elim-take-dispatcher /sync-without-uv /wip-mvmarray-refactor /inlining-exception-fix /frame-gc-opts /spesh-value-prop /set-removal /gen2-frames 21:18
those are jnthn last commit, > 4 years 21:19
nine, did you try that fix? :) 21:22
nine [Coke]: looks like that fix even made it into master :) And has evolved somewhat since 21:42
[Coke] ... ok, not exactly as is, I assume, or my merge check is missing stuff? 21:53
22:08 linkable6 left, evalable6 left
jnthnwrthngtn [Coke]: Also can be that I rebased the branch and merged it locally, put never pushed the update to the branch itself, in which case --merged won't detect it 22:08
[Coke] Oof.
22:09 evalable6 joined 22:10 linkable6 joined
jnthnwrthngtn And then GitHub also has squash merge and rebase merge options even in a PR-based workflow (but mitigates it somewhat with a button to delete the branch, but one has to remember to push it) 22:10
So there's quite a few paths to "--merged doesn't detect it, but it was", alas.
MasterDuke i have a FF plugin/extension that automatically clicks that button when i merge my own PRs 22:13
github.com/refined-github/refined-github 22:14
[Coke] nice 22:15
nice 22:16

Powered by Cro and the Raku® Programming Language.

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

Thank you!