MasterDuke timo: did you see github.com/python/cpython/pull/128718 ? how long would it take you to implement that for moarvm? 02:53
tellable6 2025-02-10T19:17:37Z #moarvm <lizmat> MasterDuke17: with this patch, 2 spectests fail for me
MasterDuke lizmat: fix incoming 02:57
Geth MoarVM: MasterDuke17++ created pull request #1911:
Fix utf8 decoding after mistakes simplifying it		 03:19
Geth MoarVM/main: 474faf87cb | (Daniel Green)++ | src/strings/utf8.c
Oops, accidentally had the conditional backwards
 07:38
MoarVM/main: aa11775c57 | (Daniel Green)++ | src/strings/utf8.c
Reinstate the after-decode-loop bad utf8 check

I somehow missed that `state != UTF8_ACCEPT` is not the same thing as
  `case UTF8_REJECT:`.
MoarVM/main: c637fceac8 | niner++ (committed using GitHub Web editor) | src/strings/utf8.c
Merge pull request #1911 from MasterDuke17/fix_utf8_decoding_after_mistakes_simplifying

Fix utf8 decoding after mistakes simplifying it
patrickb scovit: Can you make that a PR? 08:22
tellable6 patrickb, I'll pass your message to scovit
patrickb Context: I work on getting a PTY setup on Windows. I can't use the libuv process creation facilities. The only way to get a callback on process exit is a separate thread waiting on that process. 14:25
I could either just use a libuv thread (uv_queue_work) or use the Windows wait thread pool. 14:26
The uv thread will lock up a thread of the pool. I'm unsure if that's cool. Windows wait thread pool gives no guarantees as to which thread runs the callback and it's not synced with libuv whatsoever. 14:28
Any pointers as to which direction to take best?
Just for reference, I'm not the first one hitting this mess: github.com/libuv/libuv/issues/3100 14:29
For reference: node-pty creates and locks up a thread manually: github.com/microsoft/node-pty/blob...ty.cc#L111 14:36
Are there any "make me a thread for internal use" facilities in moar or do I just use libuv directly? 14:38
timo oh cool you're back on pty stuff? 16:18
check how the async io thread and the spesh worker thread are created and launched 16:19
i'm not sure if we can get away without an MVMThreadContext for the process wait thread
but the thread context doesn't have to be "full", for example doesn't have to have a full-sized nursery 16:20
patrickb Yes, with rakudo working on Windows again and the Terminal::* stack gaining Windows support, the stage is now set to implement PTY support on Windows. Yay! 16:45
timo terrifying.
lizmat PSA: rakkable is now also running here 21:29
and has some added features related to search Rakudo / NQP / MoarVM 21:30
rakkable: help
rakkable lizmat, Help sections available:
lizmat, eco-code eco-doc eco-provides eco-scripts eco-tests rakudo-all rakudo-c rakudo-java
lizmat, rakudo-js rakudo-nqp rakudo-perl rakudo-raku rakudo-shell rakudo-test rakudo-yaml
lizmat, unicode version.
lizmat rakkable: help rakudo-c
rakkable lizmat, Search all of the C files in Rakudo
lizmat rakudo-c strcmp
rakkable: rakudo-c strcmp
rakkable lizmat, Looking for 'strcmp' using 'rakudo-c', please be patient!
lizmat, Found 48 lines in 15 files:
lizmat, gist.github.com/f827ea7d5aaefe4295...4e52aae583
lizmat afk& 21:43

Powered by Cro and the Raku® Programming Language.

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

Thank you!