|
05:45
[Coke]_ left
05:59
[Coke]_ joined
06:03
[Coke]_ left
06:15
[Coke]_ joined
06:20
[Coke]_ left
|
|||
| patrickb | I can't use software.schmorp.de/pkg/libptytty.html It's purely GPL licenced. I guess I'll do it entirely from scratch. Ugh. | 06:39 | |
|
06:49
[Coke]_ joined
06:54
[Coke]_ left
07:23
[Coke]_ joined
07:52
[Coke]_ left
08:03
sena_kun joined
08:21
[Coke]_ joined
08:26
[Coke]_ left
08:57
[Coke]_ joined
|
|||
| lizmat | knowing schmorp's history in another community, I probably wouldn't want to touch their code with a pole anyway | 09:10 | |
|
10:07
[Coke]_ left
|
|||
| ab5tract | patrickb: what’s your use case again? | 10:11 | |
|
10:13
[Coke]_ joined
|
|||
| patrickb | I'm working on a raku debugger. I want an embedded stdio window. | 10:25 | |
| schmorp writes great software, no question. But he's a bit difficult to interact with. I've made my experiences as well. | 10:41 | ||
| ab5tract | o the idea is that it would launch a tty in a GUi window | 12:16 | |
|
12:57
patrickb left
14:07
patrickb joined
|
|||
| patrickb | TUI, but yes. :-) | 14:17 | |
| ab5tract | Now I’m confused (not that this is an exceptional state for me) | 14:37 | |
| Within a user’s existing terminal, you would like to spawn a new TTY in a specific region of the terminal, as part of a larger TUI? | 14:39 | ||
| I’m just trying to understand the scope the conundrum. The above sounds much simpler than spawning a GUI window | 14:44 | ||
| timo | the tricky thing is to give the program that is invoked a true TTY (well, true pseudo TTY) to control all on their own, instead of just giving them a pipe for stdout and stderr | 19:37 | |
| patrickb: at some point i might just say "include tmux in the mix and let it handle all the tricky shit" | 19:38 | ||
| patrickb | timo: I'm happy with the progress I make. Up until now I have been expanding my understanding. I feel I'm approaching the point where I know enough to have a good idea of what I'll have to implement. | 20:12 | |
| ab5tract: Yes, embed a small terminal window in a bigger terminal window. Pretty much what tmux or screen also do. | 20:13 | ||
| ab5tract | But with the full functionality of (pseudo) tty behind it. If that were not a requirement than it would (naively) seem like you already have everything you need with Process::Async + Terminal::Print (or Terminal::Widgets, if it is ready for it) | 20:16 | |
| patrickb | ab5tract: The obvious failure mode of a process pipe instead of a pty is that Rakudo will default to buffering the output which has the effect that you won't see output instantly. | 20:41 | |
| I'm actually building the debugger on Terminal::Widgets. It's not ready yet, but the missing bits are well documented and japhb has signalled that he'll try to unblock me where ever he can. | 20:45 | ||
| But since I'm not blocked yet (I want to finish the PTY work, then I need to extend the moar debugger protocol a little and only then I'll move back to the debugger itself), I'm all good. | 20:47 | ||
| ab5tract | patrickb++ | 20:54 | |
|
21:18
sena_kun left
21:19
sena_kun joined
21:33
sena_kun left
21:35
sena_kun joined
21:54
sena_kun left
21:55
sena_kun joined
21:59
[Coke]_ left
22:00
sena_kun left
22:26
[Coke]_ joined
22:31
[Coke]_ left
23:14
[Coke]_ joined
23:21
[Coke]_ left
|
|||