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.
Geth MoarVM/main: 2ceba5c87b | (Will Coleda)++ | docs/ChangeLog
Fix Changelog formatting
 01:57
[Coke] nine, timo: ok to redo that merge (though I think it might have to be manual, github says that branch is already in main) 03:06
[Coke] moarvm.org's "fork me" icon is broken. Any thoughts on tholman.com/github-corners/ ? 17:07
(I have a PR in progress for the site if anyone likes)
github.com/MoarVM/moarvm.org/pull/19 17:13
Geth MoarVM/rakperl: 2744dcc71d | (Will Coleda)++ | 9 files
Update many Perl 6 -> Rakudo

Leaving things that are exact quotes or from historical docs		 17:21
MoarVM: coke++ created pull request #1901:
Update many Perl 6 -> Rakudo
MoarVM/rakperl: a0118445e5 | (Will Coleda)++ | docs/release_guide.md
Note convention found during 2025.01 release
 17:54
[Coke] ... crap, that was supposed to go to main. 17:56
timo tbh it's fine to force-push over or delete branches, if you're quick about it :P 18:02
but that's just my opinion
jdv i'd guess that trailing zero is some fix or bandaid for the "ambiguous refspec" issue cause the tag and branch are the same... 18:03
which also happens to allow for "point releases" but i've never had to do one. 18:04
[Coke] we should be using the "release-2025.01" format to avoid the ambiguous issue, then we're also matching rakudo 18:07
(crap) eh - both small changes, they can go in a single release-related PR
ok. I think that's all the tickets (across the websites, moarvm, and rakudo), along with a bunch of small updates to release guides 18:11
releasable6: status
releasable6 [Coke], Next release will happen when it's ready. There are no known blockers. 49 out of 53 commits logged
[Coke], Details: gist.github.com/d1103a3ea6c6e72ca9...3b7544d5eb
MasterDuke any objections to merging github.com/MoarVM/MoarVM/pull/1896 and/or github.com/MoarVM/MoarVM/pull/1897 ? 18:38
anybody taken a look at them?
lizmat no objections, but I'd like to have separate NQP bumps / rakudo bumps for each of them 18:44
I'll merge and bump them shortly, ok?
Geth MoarVM/main: 627650543f | MasterDuke17++ (committed using GitHub Web editor) | 11 files
Use rapidhash instead of siphash for string hashes

It's currently the fastest recommended hash function according to SMHasher.		 18:45
MasterDuke sure, np 18:46
lizmat: fyi, the nqp bump message is backwards, now it's using rapidhash instead of siphash 18:51
lizmat argh
will do correctly for the Rakudo bump, thanks for the headsup 18:52
MasterDuke np 18:53
Geth MoarVM/main: a0b7091877 | MasterDuke17++ (committed using GitHub Web editor) | src/strings/ops.c
Speedup MVM_string_find_cclass by adding cases...

for different string storage_types
It duplicates a bunch of code, but ends up being faster in a bunch of commonly occuring cases.		 18:59
MoarVM/main: 6f19ada9cb | (Timo Paulssen)++ (committed by Elizabeth Mattijsen) | src/6model/reprs/CPointer.c
Optimize passing CPointer to nativecall ever so slightly

We emit an unbox_i operation in a compiled nativecall body in order to get the pointer value to pass to the native function. Without a spesh method on the CPointer repr, this would interpret as, and jit into, a call to CPointer's get_int.
Instead of a call, we just emit a spesh op to do the memory offset and read for us, which the JIT also likes very much.		 19:14
MoarVM/main: 05cc853ee1 | MasterDuke17++ (committed using GitHub Web editor) | 2 files
Turn off vla errors and bump libuv

Don't make VLAs an error any more. This was added when we didn't have working Windows CI (which doesn't support VLAs) and needed the early heads-up from Linux. We need to do this because libuv 1.50 uses VLAs in the Unix code.
Bump libuv to v1.50.0		 19:27
MoarVM/main: 8bc35a9d90 | timo++ (committed using GitHub Web editor) | src/io/timers.c
Counteract drift in timers with repeat

With regular repeating timers in libuv, we accumulate a small but significant amount of extra time with every tick.
We only get to supply millisecond precision values for the timeout and repeat values, so we can only correct the ticks by one millisecond or more, and we only notice when the difference is above that same amount as well.		 19:46
MasterDuke what a bumpy afternoon 19:53
lizmat evening even over here :-) 19:54
MasterDuke hopefully it doesn't effect your sleep 19:57
speaking of bumpy...is there any policy about adding c++ libraries? 19:59
Geth MoarVM/main: 7ff15b3eea | (Nick Logan)++ (committed using GitHub Web editor) | Configure.pl
Enable experimental c11 atomics on MSVC

MSVC requires the /experimental:c11atomics flag to work with c11 atomics. Conditionally add this flag since it would cause an unrecognized option
   error on older MSVCs.		 20:00
lizmat MasterDuke: ok as long as it doesn't inhibit platforms, I guess ?
MasterDuke oh, i guess mimalloc is already c++
lizmat which lib are you thinking about ? 20:04
MasterDuke simdutf 20:05
it doesn't currently do any normalization, but maybe we can use it's fast validators to add a fast path to our current decoding functions 20:06
lizmat right, looks cool
Latin1 to UTF-32 transcoding could be useful as is ? with :encoding<latin1> ? 20:07
or is that already optimized?
MasterDuke dunno if/how optimized it is. but i doubt many people are using utf-32 20:08
Geth MoarVM/main: fc2d31f32f | timo++ (committed using GitHub Web editor) | 3 files
Debugserver loaded file notifications (#1865)

add LoadedFilesRequest / FileLoadedNotification allows you to get all filenames moar already knows about, and to be notified when new filenames are encountered.
Optionally, you can ask the thread that encounters a new filename suspends itself so you can set up breakpoints ASAP. You can also get a stack trace immediately in the notification.
Document new parts of debug protocol, bump version in docs		 20:10
MasterDuke timo: did you see my question on github.com/MoarVM/MoarVM/pull/1713 ? 20:20
timo oh, i did not 20:21
i can try rebasing and then have a look if it's good
MasterDuke cool, looked pretty straightforward
timo i'd love someone™ to check how best to bring generalized integer division optimizations into rakudo 20:22
MasterDuke like libdivide does? 20:23
timo that's right 20:25
divide by power of two is already nice and simple, but i assume there's more real-world cases where the other kinds of division crop up 20:27
but we can of course only use the improved division after precomputing the details
MasterDuke i guess spesh could use libdivide to generate a division function if it notices a hot division with a constant divisor? 20:28
timo yes, that is one possible spot where that can go 20:29
i'm also thinking it could be something we try to do in rakudo's static optimizer
MasterDuke huh. implement/port libdivide in/to raku or nqp? 20:30
lizmat please don't invest any work in the static optimizer anymore... it's going to be moot in RakuAST
timo if we want to use libdivide directly, it can become a syscall inside moarvm so nqp and rakudo can use it too
MasterDuke hm. to return a callable? or to somehow get the values it uses in its generated function? 20:32
timo without good example code that actually uses division in a "realistic" setting, it will be very difficult to balance all the possible trade-offs we could do
i'd ask it to fill the details into a little array or something
which algo to use, and the constant that goes along with it
and then there'd be an op or syscall that divides a number using the algo in question
if the algo is constant at jit-time, we can directly emit the correct ops immediately 20:33
though with raku code, it's quite likely that much of the time, it's going to be _I division rather than _i. on the other hand, we have the special mode where 32bit numbers can directly be in an Int
MasterDuke it looks like it generates a struct with the necessary information, though it would require some interpreting 20:35
Geth MoarVM: timo++ created pull request #1903:
Make accesses to spesh arg guard atomic		 20:39
timo we can be silly and put the struct into a buf8 20:40
MasterDuke timo: two comments on #1903 20:44
timo the comment about atomically exchanging is mostly that we don't have to make sure load and store can't be "interrupted" 20:51
MasterDuke ah
timo it looks like the discard function for spesh guards is only used when we toss a whole spesh candidate 20:53
MasterDuke one more question 20:55
timo same reason as the one just above it 20:58
the stuff stored at the "other end" of that pointer has to be visible to other cores first
MasterDuke ?
timo it's not important whether we replace the null pointer by a new pointer, or replace the old pointer with a new pointer 21:08
not sure i'm understanding the question correctly though 21:11
MasterDuke i thought the barrier on the one branch of the if/else was needed because there was both a load and a store 21:15
but since the other branch only has a store, i wasn't sure why the barrier is needed?
timo the stores that we are worried about are all the stores to the tree->nodes[i] further above 21:16
MasterDuke ah
huh, lots of fails on that pr 21:17
looks like all in t/02-rakudo/99-misc.t and t/09-moar/01-profilers.t 21:18
timo is it all the fails caused by bumps?
oh
MasterDuke but one success 21:19
Geth MoarVM/atomic_accesses_to_spesh_arg_guard: e410e191fd | (Timo Paulssen)++ | 8 files
Make accesses to spesh arg guard atomic

On ARM and other platforms with less strict memory ordering guarantees than x86, the step that spesh does to switch the pointer around to the newly created spesh arg guard can be seen by another thread before the contents of the arg guard are seen, causing the thread to jump into uninitialised "code". Until recently, this just caused freezing or ... (10 more lines)		 21:21
timo i removed the comment in the discard function because it's probably more confusing than helpful
finished the comment that was cut off in the middle
MasterDuke nice, and that'll let us see how flappy those fails are 21:22
timo with the finished comment, is it clearer?
MasterDuke yep 21:23
looks like they're failing again 21:30
timo huh
not ok 2 - profiler does not crash 21:33
oh, huh. 21:38
but it kinda does look like the profiler crashes now, yeah 21:40
i blame having had to make all my pointers into AO_t 21:41
i might have turned something into one dereference too many or too few
hmpf, does that mean that my debian package of moarvm with those changes also b0rken >_> 21:44
Geth MoarVM/atomic_accesses_to_spesh_arg_guard: 2f1f74890c | (Timo Paulssen)++ | src/spesh/arg_guard.c
Fix incorrect write to spesh_arg_guard pointer
 21:47
timo that should be better
i'm not 100% sure if it worked or not but i clicked "re-run" on the azure ci improvements pull request 21:54
maybe it needs more than just a click on the re-run button 21:55
Geth MoarVM/faster_dev_powershell_in_azure_pipelines: 23 commits pushed by (Timo Paulssen)++
review: github.com/MoarVM/MoarVM/compare/5...fc9b1d36f7		 22:00
timo let's see if this rebase helps
MasterDuke the re-run button only works for a couple days after the pr is created/updated 22:05
timo and after that it just says "successfully requested a re-run"? lmao 22:06
MasterDuke you successfully requested the re-run. they choose not to honor the request
afk for a while 22:07
timo thanks

Powered by Cro and the Raku® Programming Language.

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

Thank you!