| patrickb | I wonder whether it might make more sense to have a generic Terminal::API module or some such. Having separate modules for each bit of functionality feels a bit inflationary. | 08:40 | |
| japhb | patrickb: ab5tract and I discussed at one point doing a T::P 2.x, taking everything we'd learned and redesigning it. But I realized that I had a *lot* more to learn about terminals at the time, so I built up the functionality layer by layer as I managed to grok each new thing. | 17:38 | |
| That way I didn't break anything anyone depended on when I went "Dang it, I'm going to have to do that differently." Which indeed happened when I realized I needed a real ANSI parser to handle terminal queries correctly, for instance. Faking it as T::P does only gets you so far. | 17:40 | ||
| I figure however that when T-W gets to "mostly there" status, it might be time to go and do that, with an opportunity to put afterburners on the performance. | 17:41 | ||
| (T::P isn't by any means slow for a pure-Raku module, but that doesn't make it near as fast as it could be.) | 17:42 | ||
| patrickb | Hm. That puts a bit of a different perspective on my current project. | 18:07 | |
| But I guess tackling a T-W rewrite now is a bit too big bite for me at the moment given that my actual goal is "only" to create a decent TUI debugger. | 18:09 | ||
| I got into a lot more deep holes than I expected... | |||
| already | |||
| What would you think is a good way forward for me currently? | 18:10 | ||
| Just continue getting the current stack into a workable shape and Delay the rewrite for later? | 18:11 | ||
| (I'm not implicating *who* is doing any rewrites, only when.) | 18:12 | ||
|
18:42
timo joined
|
|||
| japhb | Oh, definitely delay. Rewriting the stack will almost certainly derail the actual app you're working on. It's a much deeper hole than I thought when I started on all this. | 22:16 | |