| 30 Nov 2024 | |||
| lizmat | + has int32 $.filler2; | 12:33 | |
| to the struct fixes the issue | |||
| patrickb | Can we just hard code the different struct layouts? | 12:36 | |
| We'll probably want to access other parts of the structure in the future. | |||
| That's what go is doing, right? | 12:37 | ||
| Ah, lizmat proposed the same. | |||
| lizmat | yeah, yup :-) | 12:38 | |
| japhb | timo++, lizmat++ | 17:07 | |
| 1 Dec 2024 | |||
| timo | is Terminal::LineEditor the right spot to also implement something like a completions menu? or should there merely be an interface that lets the line editor cooperate with a bit of code that renders a menu or "popup" above or below the line? | 16:22 | |
| patrickb | Maybe we could have both, a nice interface to plug something like that into and am impl of that same interface. Then it can be nicely used standalone, but also allow e.g. T-W a custom implementation that matches the rest of the T-W stack. | 17:40 | |
| 2 Dec 2024 | |||
| japhb | Yes, patrickb++'s comment matches my original intent for the Terminal::* stack. | 03:10 | |
| patrickb | NativeCall does not deal with struct padding, correct? So only reproducing the struct I see in some header in nativecall is not enough? | 14:51 | |
| lizmat | afaik NativeCall deals with what it has been handed | 14:52 | |
| patrickb | Moar does all the alignment magic for us: github.com/MoarVM/MoarVM/blob/main...#L339-L344 | 15:40 | |
| So no, we don't need to account for padding in our Raku code. | |||
| lizmat | ok, but it you don' specify a big enough struct, you're doomed as we've seen on MacOS, right ? | 15:56 | |
| patrickb | Yes. The struct was simply wrong. I was just a bit puzzled that the offsets timo posted did not match the struct defs I see on linux and mac. That's the padding. Then I started to wonder if this is in any way relevant. It is not. :-) | 16:12 | |
| So the drill is: Find all the different struct defs out there, convert them to nativecall classes and use the correct one depending on some env detection. | 16:14 | ||
| lizmat | I wonder whether it would make sense to abstract those into a separate set of classes | 16:15 | |
| that would automatically export the correct struct version for the current OS / hardware | 16:16 | ||
| patrickb | This is what I have so far: git.sr.ht/~patrickb/Terminal-API/t...PI.rakumod | ||
| lizmat | I thought ispeed / ospeed where 64bit on MacOS ? | ||
| patrickb | The idea I have with that module is to not leak any OS specifics out. That's why the public API says nothing about termios. (Since there is no such thing on Windows.)- | 16:17 | |
| Ah | |||
| latest changes not pushed yet...- | |||
| pushed | 16:21 | ||
| Sooner or later I'll have to come up with some abstraction to not have all the different struct defs and native functions in a big file. But as long as I don't leak the mess I currently have out via the API, I'm not in a hurry to clean this up. | 16:22 | ||
| Putting in the Windows impl of those APIs is one of the next steps. | 16:23 | ||
| lizmat | As to hiding / maintainability, I was thinking of a CStruct::termios module that would export the correct Ctruct definition | 16:42 | |
| automagically | |||
| wouldn't that be a helpful thing to have ? | 16:43 | ||
| patrickb | Yes! (There already is Term::termios that does this very thing. But that module went down the road of doing some C magic to retrieve the struct layout.) | 16:56 | |
| I started Terminal::MakeRaw only, because I wanted to get rid of Term::termios dependency of a C compiler. (It is actually a copy of that module with all the C compiler stuff removed.) | 16:57 | ||
| lizmat | I would suggest such a CStruct module to *not* need any magic | ||
| patrickb | Fully agreed! | 16:58 | |
| I'd say, let's continue with Terminal::API for now. It's easier to iterate with everything in a single module. Once it's stable and working on all the platforms we care about, we can think about extract the struct defs into their own module. | 17:00 | ||
| Also I wonder if it's possible to write a generic c (maybe + some gdb mixed in) program or a C program generator that can spurt out a suitable NativeCall representation given only the struct name and include file. | 17:01 | ||
| We could either pass that prog to people on platforms we don't support yet to help speed up adding new platforms. | 17:02 | ||
| Also, if me manage to fully automate this, create a generator that just spits out definitions for all sorts of platforms we can get our hands on and create a module from that. | 17:03 | ||
| But I'm unsure if it's technically possible to pull something like this off. | |||
| lizmat | perhaps using the build farm ? | 17:04 | |
| patrickb | Yup. | ||
| lizmat | OTOH, it would generally be a one-time process, right? | 17:05 | |
| patrickb | We already have raku.land/github:Skarsnik/App::GPTrixie | ||
| Yes. And whenever we add a new architecture it's a matter of re running the pipeline and releasing a new version of our module. | 17:06 | ||
| Maybe I'm overthinking this and just doing it manually is what we should do. | |||
| lizmat | :-) | 17:07 | |
| 13 Dec 2024 | |||
| patrickb | I'm trying to put termios behind an API. The tcsetattr() function takes an arg of when to put the changes into effect. NOW, DRAIN and FLUSH. I wonder if I need to forward these options in my API. That's kind of strange, since on Windows there is no way to influence the point changes go into effect. | 11:01 | |
| I'm now looking for opinions if I can just hard code a value and not expose this option. (Which?) | 11:02 | ||
| lizmat | make it a noop on Windows ? | 11:25 | |
| patrickb | That's what I currently do. But just maybe only one of those option makes sense in this context. Then I could simplify the API. | 12:29 | |
| lizmat | I'm not sure what the options, fwiw :-) | 13:15 | |
| *do | |||