I'd like to try to use MacRuby with CoreAudio on OS X, but most of these APIs are C functions. Do I have to use Ruby DL, or does MacRuby offer another way?
According to the Macruby site, you should be able to call C functions directly
Accessing Static APIs
Many Mac OS X framework APIs are not introspectable because they are static, but thanks to the BridgeSupport project, static APIs can be called from MacRuby.
The following API types are available:
List item
CoreFoundation types (CFType)
C structures
C opaque types
C enumerations
C and Objective-C constants (including preprocessor-defined constants)
C functions (including inline functions)
Objective-C informal protocols
http://www.macruby.org/documentation/tutorial.html
Related
I want to do basic statistics with Vlang.
Can I use C libraries? For example, Apophenia: http://apophenia.info/
Or IMSL C stat library: https://docs.roguewave.com/en/imsl/c/8.6/pdf/C_Stat_library.pdf
Thanks for your help.
Yes, you can call C libraries from V.
You need to make the C library's structs, typedefs and functions known to V by defining them in V first - before calling/using them.
For structs you conveniently only need to define the fields you need to use.
Here's some examples:
via 2D game framework wrapping several C libs
sokol in vlib
v-miniaudio wrapper (disclaimer: my own module)
Generally you can find a lot of C wrapper code in vlib itself. (We're working on replacing C with pure V)
How one can include his/her own programming functions to standard C (ANSI C) library? And any one who is learning or working on C language able to use those functions anywhere anytime, no need of development in general.
Example : someone developed function named "FunFun()" and assume it does fantastic work for most programmers. so how anyone can access this "FunFun" function without developing and just including standard library?
The sane way to approach it would be to develop a 3rd party library and make it available over the internet through open source, Github etc.
The GNU C dialect is one such example, which is a collection of non-standard compiler extensions used by the GCC compiler. One could join the GCC open source group and try to get the new function added there. It would still not be standard library C, but the GCC extensions are often an inspiration to the C standard and several of them (designated initializers, flexible array members, anonymous struct/union etc) have been adopted into the language itself with the C99 and C11 standards. One of the purposes for GNU C is actually to serve as an experimental playground where new languages features can be tried out live.
If you truly wish to add a new function to the actual C standard library, you would have to join the ISO working group and convince them that the function should be added to the language. Or alternatively find a member of the committee and convince them to speak in favour of the new function.
All this of course assuming you are a C programming veteran, or otherwise nobody will likely take you seriously.
Your question can't be answered because it's based on several wrong assumptions.
Things like stdlib.h are not libraries. They are header files intended to be included in your program. Including means the contents are literally pasted into your program at the point of inclusion before the actual compilation happens. They are typically used for declaring functions, types, global variables etc a library provides. The actual library is then linked against after compilation.
There's no such thing as the C library as well as there's no such thing as the C compiler. c is a language that is specified in an open standard (if you're interested, here's the last draft of the latest standard version C11). There are many actual implementations and a complete implementation consists of at least a compiler and a standard library. You can of course implement your own standard library. It's a lot of work to have it really conform to the standard (you would have to implement printf() and scanf() correctly, for example). With your own standard library, you can also include your own extensions, but this would only mean people using your standard library (instead of e.g. glibc on a GNU system) could directly use them.
For having a function available on any implementation of C, it would be necessary to have the C Standard specify it. You won't get a new function in the standard without some very good reasoning.
So if you want to make your own function available to others, do what everyone does and just implement it in your own library. Users can download it, include its headers and link against it.
I am trying to come up with a solution for yielding a Luajit coroutine from a C function that immediately creates a tasklet to be processed on another OS thread.
According to various Lua documentations, and things began to heavily contradict each other, this isn't entirely possible? The documentations are not very clear, and they don't explain the reasoning.
Lua 5.1 states that each each coroutine had a stack. However, there was only one global C stack. I am not entirely sure why that is a hindrance.
Lua 5.2 apparently fixes this with lua_pcallk and lua_yieldk. But the explanations are very confusing.
But none of these states the VM that I am using... which is LuaJIT 2.0.4 and LuaJIT 2.1.0.
A google search told me that Luajit 1.x had CoCo implemented, which apparently used true C stacks for each lua thread (coroutine). Which allows yielding from anywhere.
And only one search lead me to see that apparently LuaJIT 2.x does not implement coco, as each coroutine uses a C stack.
Could anyone please tell me what the problem is for yielding a coroutine from C? And verify whether or not I can safely yield/resume a luajit 2.x coroutine from c?
In the reference Lua implementation, each Lua coroutine has its own Lua stack, which is just an array inside of the lua_State and has no relation to the C stack. Lua is unable to save the C stack (because that's impossible in standard C), so it is unable to yield a coroutine if a C function is currently executing.
For example, if you have Lua function a calling C function b calling Lua function c, and c tries to yield, Lua will be unable to save the local variables for b (since it's a C function) and will fail.
This also applies to a lot of built-in Lua functions. As you alluded to, in Lua 5.1, the implementation did not support yielding across pcall, until Lua 5.2 apparently added special functions to make it work.
Coco is a patch to the standard Lua implementation that implements separate C stacks in coroutines, so that Lua can now "save" the C function variables. Apparently LuaJit 1.x also includes it. It won't apply to LuaJit 2.x because it's a completely different implementation of Lua.
LuaJit 2.x has the following paragraph in the Extensions page:
Fully Resumable VM
The LuaJIT VM is fully resumable. This means you can yield from a coroutine even across contexts, where this would not possible with the standard Lua 5.1 VM: e.g. you can yield across pcall() and xpcall(), across iterators and across metamethods.
So apparently yielding across built-in functions should work, though it's still ambiguous if it applies to arbitrary Lua C API functions. It's easy to test however; write a simple C API function that takes a Lua function and calls it, then pass it a function that yields. If it doesn't work, it should throw an error.
Note that plain C functions loaded with the FFI are not allowed to touch the Lua state at all. This includes trying to yield.
I'm able to share the same "namespace" for two different libraries using LuaJit in Linux
A = ffi.load(ffi.os == "Windows" and "opengl32" or "GLESv2")
B = ffi.load(ffi.os == "Windows" and "glfw3" or "glfw")
C = B,A
Doing this allows me to call functions from either library from the C variable
However in windows functions in the last library A can't be found (I'm using the LuaJit binary from https://luapower.com/)
I guess both platforms should behave the same (if it can't be done on both platforms (which would be odd) then neither platform should allow it?)
Is this a bug or is there a more robust method to do what I'm attempting?
If I'm reading the documentation correctly, then you cannot generally access all libraries through the same namespace.
On POSIX (Linux, BSD, etc.) systems, you can call ffi.load( name, true ) to make the symbols available from within ffi.C. There's no mention of this working or not working on windows, so I assume this won't work there.
That means that this is not a bug and the more robust method that you're looking for is to access symbols from different libraries through their respective library namespaces. (For your example that would mean accessing opengl functions through A and glfw functions through B.)
I guess both platforms should behave the same (if it can't be done on both platforms (which would be odd) then neither platform should allow it?)
There's tons of stuff that can be done in some way on Windows/Linux/Mac OS/BSD/…, but works completely different on some or all of them. Dynamic linking is just one of these. There's many more, including simple things like the concept of a "directory" containing files – the concept exists on all of these platforms but there's no common API, and a low-level wrapper (like LuaJIT's FFI is for dynamic linking) would likely expose some of the differences.
I am currently learning C. I understand that many common functions, like printf and scanf are not actually part of the C language -- they are part of the "standard library" of functions.
My question is, why aren't such functions built into the language? Is it a philosophical/design consideration? A matter of efficiency when compiling programs? A necessity in order to act as a "middle layer" to ensure compatibility with different operating systems? Something else entirely?
They are part of C. A C implementation consists of a compiler and a library (and other components, like a linker).
The C core language includes facilities that make it possible to write library code that can be used by other programs. The standard library portion of the standard specifies a library that can be implemented using the facilities defined in the core language.
Some languages do have things like a print command built into the language. C's facilities for writing and invoking library code written in C are powerful enough that that's not necessary.
Furthermore, most of the library is optional for "freestanding" implementations (mostly for embedded systems). There are implementations that support the full core language but that don't provide most of the C standard library.
And a compiler and library can be provided separately. For example, gcc is a compiler; it's commonly used with different library implementations on different systems (GNU libc on Linux, "newlib" on Cygwin, the Microsoft library on Windows with MinGW, and so forth). Mixing and matching like that would be much more difficult if the library were integrated into the core language.
The C language standard (the link is to the newest freely available draft) defines C. Section 6 defines the core language; section 7 defines the standard library.
The thing is that standard allows two kinds of conforming implementation: hosted and freestading, see N1570 4/p6:
The two forms of conforming implementation are hosted and
freestanding. A conforming hosted implementation shall accept any
strictly conforming program. A conforming freestanding implementation
shall accept any strictly conforming program that does not use complex
types and in which the use of the features specified in the library
clause (clause 7) is confined to the contents of the standard headers
<float.h>, <iso646.h>, <limits.h>, <stdalign.h>, <stdarg.h>, <stdbool.h>,
<stddef.h>, <stdint.h>, and <stdnoreturn.h>. A conforming implementation may have
extensions (including additional library functions), provided they do
not alter the behavior of any strictly conforming program.
By such design, where the libraries are organized as standard headers it's convienent to simply "cut-off" some header if it is not supported.
Note that C standard defines all headers along with function for standard C library. It's included in C standard indeed, not separate thing somewhere else.
They're part of the language, they're just not part of the grammar.
Factoring I/O out into a separate function library buys you the following:
The grammar becomes easier to parse;
You can target a wider range of platforms; any I/O foibles are handled by the library functions, not by hacking the code generator;
You can implement only as much as is needed to support the platform (i.e., an embedded controller probably doesn't need to read or write formatted output);