|
00:31
rypervenche left
00:58
ab5tract left
01:01
ab5tract joined
|
|||
| timo | finally looked at the inofficial dynasm documentation for how to spell "i have an integer that refers to a register and i would like to emit an instruction that uses that register" | 12:06 | |
| corsix.github.io/dynasm-doc/instructions.html | |||
| patrickb | I recently started looking into getting PTY support in MoarVM. My plan is to turn github.com/microsoft/node-pty/blob/main/src/ into a tiny C lib and use that in moar. Now I noticed, that github.com/microsoft/node-pty/blob...nix/pty.cc is forking. | 12:40 | |
| I haven't looked deeply if there is an easy way out. But from all I know forking in moar is not something I even want to try, right? | 12:41 | ||
| timo | we did put a little bit of fork safety in moar i think? | 12:55 | |
| does that just provide a function to fork and have a PTY where the fork is attached to it, or does it rely on forking to do the main stuff we need? | 12:56 | ||
| patrickb | It only wraps the OS forkpty function (and not openpty or any of the many others) | 13:01 | |
| I think I might be best off to only steal the windows conpty bits from there and use github.com/yusiwen/libptytty/tree/master for the rest. | 13:02 | ||
| We don't currently have any C++ dependencies in moar, do we? libptytty (which actually lives here: software.schmorp.de/pkg/libptytty.html) is technically CPP, though it pretty much uses no CPP features. I could: | 13:59 | ||
| - Either use it as is (and only convert the buid system for use in moar), with the consequence that moar now requires a CPP compiler. | |||
| - Fork, remove irrelevant bits, convert the rest to plain C, with the consequence that we can't just pull updates from upstream anymore. | 14:00 | ||
| (Hopefully all of this will at some point in the future not be needed anymore once libuv gains PTY support: github.com/libuv/libuv/issues/2640) | 14:02 | ||
| timo | is it important to have it be a moar thing rather than a NativeCall thing? | 14:07 | |
| patrickb | Given that the code bits in libptytty we actually need are pretty small and I need to create a new library anyways (for the windows bits I'll steal from github.com/microsoft/node-pty/blob...onpty.cc), I think I'll go with creating a new library with a Configure.pl style build system that's trivial to embed in moar. | ||
|
14:08
MasterDuke left
|
|||
| patrickb | timo: Yes. I really really want the debugger I'm building to be hastle free. One of the hard goals I have is not requiring a compiler on the users system. Going nativecall would add that dependency. | 14:09 | |
| timo | well, either that or downloading a binary | ||
| you probably don't want to reimplement it using NativeCall against the underlying OS APIs | 14:10 | ||
| patrickb | That's a 90% solution. I want people to be able to `zef install Rad`, and not have to go to some website and follow an installation tutorial. | 14:11 | |
| timo | the Build.rakumod can download the appropriate file, or it could be in the repo and/or tarball(s) | 14:13 | |
| fwiw i'd also like to be able to use PTYs for stuff :) | |||
| it would also be good for the cro tool which currently causes significant delays in output thanks to some buffering somewhere | 14:14 | ||
| patrickb | And then we support a different platform, that module falls out of sync and it'll annoy people. | 14:15 | |
| timo | in an ideal world, the cro cli tool might have a Log::Timeline viewer in its "cro web" frontend and set up a communication channel with the subprocesses to not have to use byte pipes or stdio | ||
| ok that's fair | |||
| patrickb | I'm not fundamentally against having native stuff in modules, but if we want something to absolutely work everywhere without hastle, we'll have to make sure we don't have native code in such modules. | 14:16 | |
| timo | BBL | 14:19 | |
| patrickb | (Recent example: Terminal::Widgets and Terminal::Print depended on term::termios, which added native code to it's module to extract some constants from header files. There have been many cases where this caused hiccups for people wanting to run T::W. I ended up creating raku.land/zef:patrickb/Terminal-MakeRaw simply to get rid of the native dep.) | ||
| cya | |||
| [Coke] | term::termios also is a dep of Terminal::LineEditor which has some weird issue with needing the temp directory it was installed via to keep existing. I have to re-install termios every so often on my mac. Looking forward to that update. :) | 15:42 | |
| ugexe | the latest term::termios fixed that, but Terminal::LineEditor cant use the latest term::termios because a different update breaks it for an unrelated reason | 15:45 | |
| github.com/krunen/term-termios/com...894849e07d | 15:46 | ||
| [Coke] | ugexe: " | 15:49 | |
| Just tested, v0.2.7 works fine for me on Linux, The failure on M2 mac is a different issue, I think. | |||
| " | |||
| I'll see if I can verify. Sorry for the module chat in here. | 15:50 | ||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2024/09/10/2024-...hlighting/ | 15:55 | |
| timo | funny enough i just thought about playing with Terminal::Print again | 15:56 | |
| patrickb | [Coke], ugexe: It's a solved problem! See github.com/japhb/Terminal-LineEditor/pull/6 and github.com/ab5tract/Terminal-Print/pull/85 | 15:57 | |
| [Coke] | patrickb++ | 15:59 | |
| timo | .o( irc bot command that creates a github (or gitlab issue) on a module mentioned by name in the message ) | 16:50 | |
|
21:44
tellable6 left,
tellable6 joined
|
|||