[03:10] Yes, patrickb++'s comment matches my original intent for the Terminal::* stack. [14:51] NativeCall does not deal with struct padding, correct? So only reproducing the struct I see in some header in nativecall is not enough? [14:52] afaik NativeCall deals with what it has been handed [15:40] Moar does all the alignment magic for us: https://github.com/MoarVM/MoarVM/blob/main/src/6model/reprs/CStruct.c#L339-L344 [15:40] So no, we don't need to account for padding in our Raku code. [15:56] ok, but it you don' specify a big enough struct, you're doomed as we've seen on MacOS, right ? [16:12] 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:14] 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:15] I wonder whether it would make sense to abstract those into a separate set of classes [16:16] that would automatically export the correct struct version for the current OS / hardware [16:16] This is what I have so far: https://git.sr.ht/~patrickb/Terminal-API/tree/main/item/lib/Terminal/API.rakumod [16:16] I thought ispeed / ospeed where 64bit on MacOS ? [16:17] 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 [16:17] latest changes not pushed yet...- [16:21] pushed [16:22] 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:23] Putting in the Windows impl of those APIs is one of the next steps. [16:42] As to hiding / maintainability, I was thinking of a CStruct::termios module that would export the correct Ctruct definition [16:42] automagically [16:43] wouldn't that be a helpful thing to have ? [16:56] 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:57] 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] I would suggest such a CStruct module to *not* need any magic [16:58] Fully agreed! [17:00] 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:01] 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:02] We could either pass that prog to people on platforms we don't support yet to help speed up adding new platforms. [17:03] 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. [17:04] perhaps using the build farm ? [17:04] Yup. [17:05] OTOH, it would generally be a one-time process, right? [17:05] We already have https://raku.land/github:Skarsnik/App::GPTrixie [17:06] 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. [17:07] :-)