Re: Preliminary libffi progress
- Posted by Icy_Viking Sep 29, 2022
- 1385 views
Excellent work Greg! It works! I can help to finish the Raylib wrapper if you'd like.
Thanks! Keep in mind that this was just a proof-of-concept. I don't plan to use libffi externally moving forward. I'd like it to replace the existing C interfacing code in the Euphoria backend. And I'm still unsure of the design for define_c_type(). I'm open to suggestions on that.
I also need to do more work to get callbacks working. Right now we've no way of declaring the incoming type for callback parameters and everything is assumed to be a pointer-sized integer. I want to provide a means of specifying and pre-handling the parameter types. This will be especially helpful when dealing with some of the event handlers in IUP.
include iup.e function action_cb( atom id, atom posX, atom posY ) return IUP_DEFAULT end function constant ACTION_CB = call_back( routine_id("action_cb"), {C_POINTER,C_FLOAT,C_FLOAT} ) function dropfiles_cb( atom id, sequence filename, integer num, integer x, integer y ) return IUP_DEFAULT end function constant DROPFILES_CB = call_back( routine_id("dropfiles_cb"), {C_POINTER,C_STRING,C_INT,C_INT,C_INT} ) procedure main() IupOpen() atom canvas = IupCanvas( NULL ) IupSetCallback( canvas, "ACTION", ACTION_CB ) IupSetCallback( canvas, "DROPFILES", DROPFILES_CB ) -- etc. IupClose() end procedure main()
-Greg
So you want to re-write the C interfacing backend entirely? Is that what I'm understanding? I mean I think the FFI is a good idea. It works and it has made it easier to wrap libraries and especially when dealing with structs. As for the define_c_type, it works for now. I don't mind it. I also like that C_STRING takes care of the memory allocation and such. Oh wait you want to implement FFI into the Euphoria backend, I think I get it now. As it stands using FFI externally works for now. Maybe implementning FFI into the backend would be good for 4.2.0 for now and after that we can work on adding structs/classes to Eu.