00:57 jjatria left 01:10 jjatria joined 02:27 Guest4062 left, Guest693 joined 03:28 apogee_ntv joined 04:41 Techcable left 04:42 Techcable joined 08:51 rakkable left 08:53 rakkable joined
lizmat meh, looking at github.com/Raku/problem-solving/issues/73 thinking I could just assign an int to the $!PIO 12:27
but meh... turns out it needs an MVMOSHandle REPR
and there's no NQP support for creating that from a given int afaics 12:29
so I'm wondering, would a dyncall be possible?
diff so far: gist.github.com/lizmat/a37cbb3978a...dc6e12282d 12:31
12:31 librasteve_ joined 13:18 apogee_ntv left 13:27 greppable6 left, greppable6 joined
librasteve_ rakudoweekly.blog/2026/02/23/2026-...l-adverbs/ 15:15
timo we will probably need a syscall to open a file handle by its ID inside moarvm to create an MVMOSHandle from it? creating multiple handles from the same number will be a fantastic way for a user to shoot themselves in the foot though in terms of locking and such 15:24
17:08 patrickb left, sourceable6 left, Geth left, leont left 17:12 patrickb joined, sourceable6 joined, Geth joined, leont joined 17:29 disbot13 left, disbot14 joined 17:41 sugarbeet left, sugarbeet joined 18:40 nine left, nine joined
lizmat timo: so you're saying we should make it impossible for a numeric file descriptor to be re-used in Raku (unless properly closed) ? 18:42
I guess in reality, the file descriptor most likely is returned from some sort of native library, and is already opened at the OS level ? 18:43
so opening would not be needed / or shouldn't even be done ?
timo you can always open /proc/self/fd/1234 :) 18:47
ugexe can you have a file descriptor for a file that isn't open? 18:51
recycling also happens although i don't think there is anything you can do about it 18:52
so i'm not sure if we should prevent reusing descriptors or not. it might be that if you're working with fds you just have to accept the footgun-ness of them 18:54
lizmat timo: that would only work on Linux, no?
ugexe could probably just copy whatever nodejs did 19:00
lizmat nodejs abstracted /proc/self/fd/1234 ? 19:18
timo i'm sure we can create an uv handle for an existing file descriptor 19:20
ugexe nodejs abstracted using a file descriptor, yes 19:21
did they abstract /proc/self/gd/1234? i would guess no because fds dont exist on windows 19:23
on windows you have HANDLES
a good reason to look at how other languages already do these things is to familiarize oneselves with the problem space 19:24
i imagine some llm could give a decent high level summary of it without having to dig through their code though
s/HANDLES/HANDLEs/ 19:25
lizmat well, what I thought was something simple, is turning into a ginormous yak shave for me... so I'm going to leave what I've done in the gist and move on to something else that I can handle more efficiently 19:27
and yes, I would probably learn from the exercise... but I have plenty of other exercises waiting for me 19:28
ugexe yeah, i imagine there is quite a bit of yak shaving. probably why no one has done it yet :) 19:29
i've been meaning to try and get work to pay for a (non-work) claude code subscription for me to try and get it to solve things that already have well defined solutions in other languages 19:43
i think my main concern would be teaching it to do the build process between raku nqp and moar so it could iterate
lizmat perhaps raku.land/zef:wkusnierczyk/MCP could be of inspiration? 19:44
ugexe i dont think that would be useful for developing on core 19:46
similar to how raku LSP (i.e. raku navigator) aren't useful for developing on core
lizmat also: github.com/wkusnierczyk/aigent-skills 19:47
ugexe yeah i dont want to use raku to interface with AI, there are better tools to do that (e.g. claude code) 19:48
honestly i already know what needs to be done. the problem is describing when/how to build/compile the pieces, where/when the different layers (raku, nqp, moarvm) are used, how to understand the parts of raku that meant to be concated together (i.e. files that don't represent a final soruce file) 19:50
Anyways I put in a request to $work, we'll see 19:58
it has been approved, that was fast 20:00
[Coke] request... to have time to work on raku? 20:02
ugexe no, to pay for a personal claude code subscription for me to work on raku on my own time 20:03
timo I would not appreciate LLM-generated code being submitted to raku core 20:07
i didn't read backlog to see if that's what's being suggested here 20:08
lizmat some AI that would understand all ins/outs of MoarVM / NQP / Rakudo bootstrap would be something that I welcome very much :-)
ugexe there needs to be nuance about putting llm-generated code in the code. I agree no one wants to review a giant slop PR, but i'm also not the type of person who would submit such a thing. i've been using and managing 4 other developers using claude code for over a year now, so i do have some experience with getting real world results out of it as well with dealing with said slop when it does come up 20:30
[Coke] My biggest concern would be around the licensing/copyright of the code. 20:52
I haven't dealt with that on any of my projects yet, I assume you have, though.
ugexe if i read copyrighted code and submit it myself it is no different 20:53
my point being is you have to trust me either way 20:54
[Coke] I'm not just trusting you, though, also trusting Claude, no? (and, to be clear, I do trust you!) 21:04
ugexe in the same way you trust the nodejs authors that i would have copied code or drawn inspiration from
and again, there is nuance involved. what i described earlier was effectively asking an AI to emulate how nodejs handles file descriptors. we can be fairly certain where any copyright may come from. and if i were writing the actual code myself i would be doing what the AI would be asked to do: look at the nodejs source code and emulate what it does. so 1) the problem space doesn't involve 21:05
particularly novel solutions 2) the source of inspiration is known, explicit even 3) the size of the solution shouldn't be particularly large
[Coke] ah, ok, very specific case here. Thanks! 21:06
anything where at work I would say "oh, we'll have to ask the Office of General Counsel" is never the start of a good day, that's all. :)
ugexe also i hope as part of trusting me that people are expecting me to do my own due diligence before submitting something as a PR. i do understand that is now how most AI PRs are currently made though where someone just one-shots a solution and throws it up for someone else to figure out if its correct/valid/etc 21:07
21:08 rba left
ugexe yeah we also had to get various levels of approval, including legal, for AI usage (including what it can be used for/on) 21:08
21:08 rba joined
ugexe an indeed we can't use it on whatever we want 21:09
23:29 Voldenet left, Voldenet joined 23:33 japhb left
ugexe gist.github.com/ugexe/289eddc38621...66880b2c58 - here is the first plan it drafted. i am not yet to the point where it can try and apply changes to the various layers to actually test its assumptions and refine the plan without more input from myself, but it does seem to have a somewhat convincing grasp of what to do 23:33
timo don't make it an op, make it a syscall 23:39
it even points out there's a handle-open-mode syscall already?
what happens when you have an fd already open in :r and you try to open it in :w? 23:41
lizmat also: why add yet another named argument to open?z 23:43
timo why would it suggest self!remember-to-close for a handle opened on an fd?
lizmat what was wrong with treating it as an IO::Special and having a separate method .from-native-descriptor ? 23:44
sleep&
timo and then in the examples it puts a .do-not-close-automatically to un-do that
ugexe yeah there is plenty of stuff to refine. surprisingly it implemented that plan and it all worked as expected (although no other tests i.e. make test or make spectest have been run). but 23:49
a fd already open in :r that is tried to open with :w gives Failed to write 16 bytes to filehandle: Bad file descriptor. "This is the same behavior you'd get on POSIX if you tried to write() to a read-only fd - you get EBADF. 23:52
This is actually the correct behavior - it mirrors what happens in Raku when you try to write to a file opened in read mode:"
i'll direct it towards using a syscall 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!