| 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 |