I've checked its manuals and haven't found much to say that it does, but neither have I found anything to the contrary.
MIT/GNU Scheme - Foreign function interface
18.2 Foreign Function Interface
The Win32 foreign function interface (FFI) is a primitive and fairly
simple system for calling procedures written in C in a dynamically
linked library (DLL). Both user's procedures from a custom DLL and
system procedures (e.g. MessageBox) are called using the same
mechanism.
Warning: The FFI as it stands has several flaws which make it
difficult to use reliably. It is expected that both the interface to
and the mechanisms used by the FFI will be changed in the future. We
provide it, and this documentation, only to give people an early start
in accessing some of the features of Win32 from Scheme. Should you use
it in an experiment we welcome any feedback.
The FFI is designed for calling C procedures that use C data types
rather than Scheme data objects. Thus it is not possible to write and
call a C procedure that returns, for example, a Scheme list. The
object returned will always be an integer (which may represent the
address of a C data structure).
Warning: It is extremely dangerous to try to pass Scheme callback
procedures to C procedures. It is only possible by passing integer
`handles' rather than the actual procedures, and even so, if a garbage
collection occurs during the execution of the callback procedure
objects in Scheme's heap will have moved. Thus in a foreign procedure
that has a callback and a string, after calling the callback the
string value may no longer be valid. Playing this game requires a
profound knowledge of the implementation.
The interface to the FFI has two main components: a language for
declaring the types of values passed to and returned from the foreign
procedures and a form for declaring foreign procedures.
The reference to Win32 in this documentation, I believe refers to calling Windows NT/3.1 functions from GNU/Linux. At least the 18.2 Foreign Function Interface section is a subsection of the 18 Win32 Package Reference section.
Related
A swift app, will convert its dynamic frameworks into binaries. And once something is a binary, then it's no longer Swift/Ruby/Python, etc. It's machine code.
Same thing happens for a Python binary. So why aren't the machine codes compatible with each other out of the box?
Is it just that a simple mapping is required to bridge one language to the other?
Like if I needed to use a binary created from the Swift language — into a Python based app, then do I need to expose the Swift Headers to Python for it to work? Or something else is required?
I assume you're talking about making calls in one language to a library compiled in a different language.
At the assembly language level, there are standards (ABI, for Application Binary Interface) that define how function parameters are passed in registers, how values are returned, the behavior of the stack, etc. ABIs are architecture and operating-system-dependent. Usually any function that is exported in a library will follow the ABI.
It is plain that ABIs basically expect a C language model for functions: a single return value, a well-defined data type for each function parameter as well as the return value, the possibility of using pointers, etc.
Problems start to arise once you move to a higher level language. C++ already introduces complications: whereas the name of a C function is the same in assembly (often a _ character is prepended), in C++ function names must encode data types due to the possibility of overloaded functions with the same name but different parameters. Thus, names must be mangled and demangled -- this is why a prototype for a C function must be declared as extern "C" in C++. Then there are issues of the classes (this pointer, vtables), namespaces and so on, which complicate matters further.
Then you have dynamically typed languages like Python. In truth, there is no such thing as dynamic typing at the assembly language levels: the instruction encodings in machine language (i.e. binary codes as they're read by the CPU when executed) implicitly determine whether you're using an integer or floating-point or SIMD instruction (and the width of operands), which also determines which of the different register banks are accessed. Although the language makes dynamic typing transparent to you, at the assembly code level, the interpreter/JIT/compiler must resolve them somehow, because ultimately the CPU must be told exactly what data type to operate on.
This is why you can't directly call a C function (or in general any library function) from Python -- unlike a pure Python function which can disregard the types of its parameters, library functions must know the exact types of each parameter and the return type. Thus, you must use something like ctypes for Python, explicitly specifying the types in question for each function that needs to be called -- in a way, this is similar to function prototypes usually found in C headers. It is possible to write functions in C that are directly callable from Python (and, in that case, essentially from Python alone), but you'll have to jump through a few hoops.
As for the particular language pairing you're interested in (Python/Swift), a cursory search came up with this thread in the Swift forums (this one, linked from there, may also be interesting. Reading the thread, there appears to be two feasible solutions at this time: first, use the #_cdecl attribute (which isn't officially supported) to make a C function, and then call it from Python using ctypes. But the second and apparently more promising one is to use the #objc attribute in Swift, and use PyObjC in Python. I assume this will allow using some of the higher-level features of Swift, at least those that intersect with what Objective-C offers.
I have a C function, that calls a lua function, that in turn initiate a long chain of async callbacks that hop between C and lua. And I want all of the C functions involved to be able to access some specific userdata, that I created in the original C function. But the tricky part is: all of this should be thread-safe, and also I can't change API, so passing a reference value throughout callbacks is not an option.
So is there a way to somehow put userdata inside lua_State, in a way that only "my" chain of callbacks could access it?
Because Lua has no thread safety guarantees for data races within the same lua_State instance, I'll assume your C code ensures that only one piece of code is communicating with the same lua_State at any one time.
The usual way to handle this is through the Lua registry. It is a special table that is part of the lua_State, accessible from any C code. You designate some key in the registry table to be your special value.
Lua code cannot access the Lua registry unless some C code gives them access to it (BTW: don't do this). So as long as you maintain the integrity of this table, you don't have to worry about a Lua script reaching out and breaking it.
I am writing some R simulation code, but want to leverage Fortran's swift Linear Algebra libraries to replace the core iteration loops. So far I was looking primarily at the obvious option of using .Fortran to call linked F95 subroutines; I figured I should optimize memory use (I am passing very large arrays) and set DUP=FALSE but then I read the warning in manual about the dangers of this approach and of its depreciation in R 3.1.0 and disablement in R 3.2.0. Now the manual recommends switching to .Call, but this function offers no Fortran support natively.
My googling has yielded a stackoverflow question which explores an approach of linking the Fortran subroutine through C code and the calling it using .Call. This seems to me the kind of thing that could either work like a charm or a curse. Hence, my questions:
Aiming for speed and robustness, what are the risks and benefits of calling Fortran via .Fortran and via .Call?
Is there a more elegant/efficient way of using .Call to call Fortran subroutines?
Is there another option altogether?
Here's my thoughts on the situation:
.Call is the generally preferred interface. It provides you a pointer to the underlying R data object (a SEXP) directly, and so all of the memory management is then your decision to make. You can respect the NAMED field and duplicate the data if you want, or ignore it (if you know that you won't be modifying the data in place, or feel comfortable doing that for some other reason)
.Fortran tries to automagically provide the appropriate data types from an R SEXP object to a Fortran subroutine; however, its use is generally discouraged (for reasons not entirely clear to me, to be honest)
You should have some luck calling compiled Fortran code from C / C++ routines. Given a Fortran subroutine called fortran_subroutine, you should be able to provide a forward declaration in your C / C++ code as e.g. (note: you'll need a leading extern "C" for C++ code):
void fortran_subroutine_(<args>);
Note the trailing underscore on the function name -- this is just how Fortran compilers (that I am familiar with, e.g. gfortran) 'mangle' symbol names by default, and so the symbol that's made available will have that trailing underscore.
In addition, you'll need to make sure the <args> you choose map to from the corresponding C types to the corresponding Fortran types. Fortunately, R-exts provides such a table.
In the end, R's R CMD build would automatically facilitate the compilation + linking process for an R package. Because I am evidently a glutton for punishment, I've produced an example package which should provide enough information for you to get a sense of how the bindings work there.
3. Is there another option altogether? YES
The R package dotCall64 could be an interesting alternative. It provides .C64() which is an enhanced version of the Foreign Function Interface, i.e., .C() and .Fortran().
The interface .C64() can be used to interface both Fortran and C/C++ code. It
has a similar usage as .C() and .Fortran()
provides a mechanism to avoid unnecessary copies of read-only and write-only arguments
supports long vectors (vectors with more then 2^31-1 elements)
supports 64-bit integer type arguments
Hence, one can avoid unnecessary copies of read-only arguments while avoiding the .Call() interface in combination with a C wrapper function.
Some links:
The R package dotCall64: https://CRAN.R-project.org/package=dotCall64
Description of dotCall64 with examples: https://doi.org/10.1016/j.softx.2018.06.002
An illustration where dotCall64 is used to make the sparse matrix algebra R package spam compatible with huge sparse matrices (more than 2^31-1 non-zero elements): https://doi.org/10.1016/j.cageo.2016.11.015
I am one of the authors of dotCall64 and spam.
We are working on a game engine written in C and currently we are using the following naming conventions.
ABClass object;
ABClassMethod(object, args)
AB Being our prefix.
Our API, even if working on objects, does not have inheritance, polymorphism or anything. All we have is data types and methods working on them.
Our Constants are named alike: AB_ConstantName and Preprocessor macros are named like AB_API_BEGIN. We don't use function like macros.
I was wondering how this was fitting as a C API. Also, you may note that the entire API is wrapper into lua, and you can either use the API from C or lua. Most of the time the engine will be used from lua.
Whatever the API you'll come out with, for your users' mental sanity (and for yours), ensure that it's consistent throughout the code.
Consistency, to me, includes three things:
Naming. Case and use of the underscore should be regulated. For example: ABClass() is a "public" symbol while AB_Class() is not (in the sense that it might be visible (for whatever reason) to other modules but it's reserved for internal use.
If you have "ABClass()", you should never have "abOtherClass()" or "AbYet_anotherClass()"
Nouns and verbs. If something is called "point" it must always be "point" and not "pnt" or "p" or similar.
Standard C library, for example, has both putc() and putchar() (yes, they are different but the name doesn't tell which one writes on stdout).
Also verbs should be consistent: avoid having "CreateNewPoint()", "BuildCircle()" and "NewSquareMake()" at the same time!
Argument position. If a set of related function takes similar arguments (e.g. a string or a file) ensure they have the same position. Again the C standard library do a poor job with fwrite() and fprintf(): one has the file as the last argument, the other as the first one.
The rest is much up to your taste and any other constraint you might have.
For example, you mentioned you're using Lua: Following a convention that is similar to the Lua one could be a plus if programmers have to be exposed to both API at the same time.
This seems standard enough. OpenGL did it with a gl prefix, so you can't be that far off. :)
There is a lot of C APIs. If you are creative enough to invent a new one, there's no "majority" to blame you. On the other hand, no matter which way you go there are enough zealots of other standards to get mad at you.
See, for example, here
https://stackoverflow.com/questions/139299/difference-between-dependency-injection-di-inversion-of-control-ioc
to remind yourself what IoC and DI are.
The question and answer here
Is Inversion of Control specific to OO languages?
suggests that it does not require an OO language.
Now, my question: Anyone doing this in C?
I am asking because we write embedded C and are considering applying these methods, without changing our programming language.
Doing it in C all the time. The hint is given in the answer from Azder in your second link:
"When you give a Windows API function a pointer to a callback function, you give them the control of calling your function with their own parameters."
From this point of view, the concept is already used in the Standard library for the functions qsort() and bsearch().
On windows, you have COM which does something similar. You have an interface and provide an implementation in a DLL. You register the DLL and that process of registration makes an entry in the registry mapping the interface (UUID) and the DLL which provides the implementation. Based on this information, when you execute QueryInterface(), the COM service will load the corresponding DLL and create an instance of the implementation object, typecast it to the requested interface type and return.
This is IoC using COM. Since COM is implemented in 'C', I am sure it is just working out the details to get this working on your embedded system. Instead of registry, you will need a file to store that mapping between interface, implementation and DLL. This is done in Catia (from Dassault Systemes) in their CNext (V5/V6) architecture. It is called the Object modeler framework.
Steps to achieve this:
Define a naming convention for function that returns a pointer to an interface
Create a file with interface and DLL in which it is implemented
Implement the interface in a DLL and update the file in #2
In the main code, read the file and create a map of interface and DLL
When you need an interface, load the DLL if not loaded and get the address of the function that returns the pointer to interface (based on defined naming convention)
Ex: For IDoSomething interface, your function might be Get_IDoSomething().
Since we get the address of function based on name, it is done at runtime and not at compile time.
Invoke the function at the address you get from #5. You now have a pointer to the interface based on the implementation in DLL as specified in #3
You therefore tie the interface to its implementation at runtime.