Are you developing tools to extend the LiveCode environment? This is the place to talk about the nuts and bolts of extending our nuts and bolts. If you want to use a LiveCode or third party Environment extension, visit the Using Evironment Extensions forum.

Hi community members,
because there is not yet an FFI-subForum, I post this here.

I wrote an app (LiveCode standalone) that may go in the direction of what LC will give us soon with it's FFI-interface. It is a GUI to the fastest easy accessible interface I know:

LuaJIT, a jewel of development artwork, the cream of cream in development software.

Most of it is written in "made-to-measure"-Assembler and thus faster than native compiled C. What we use is available JIT (just in time), it has simply to be prepared to very basic Lua and some LuaJIT requirements, see http://luajit.org .

The GUI I wrote using LiveCode, does that for you in a lot of cases, there is only for advanced users a module that allows to script the core of the procedures: Yes, you write it in a field and it is then just in time done by LuaJIT!

The app is still in early beta, only small help is available. It is good to know (but you don't have to) what imagedata is.

hhImageJIT v3b5 (LiveCode-GUI using the LuaJIT-FFI)

It's free, just try.
[The apps are closed source, will become open source when finished.]

[+] On all platforms
hhImageJit = the app, should work by double-click
hhImagesIN = directory of sample images, for later speed comparison
(the WS-images are from a Wilhelm-Sanke-stack, RichMedia-forum).
hhImagesOUT = directory for your saved artwork
hhPrefs = contains templates for personal menus (edit in a TextEditor).

[+] on Linux additionally
= a directory "fonts" containing three ttf-files which the app needs. Please install these fonts if they are not already in your OS.
= directories "Externals" and "Linux" and a file revsecurity.so (don't touch these).

[+] on Windows additionally
= a directory "fonts" that is used by the app (perhaps you have to install the fonts).
= directories "Externals" and "Win32" and a file revsecurity.dll (don't touch these).

[There are also standalones for RaspiB, Raspi2 and Raspi3. The gain in speed is extreme on these machines!
As the source cannot be closed there, the zips are password-protected and I'll give them out under certain conditions to certain persons only. Just ask me via email.
And I'll prepare also versions for iOS and Android later on, but you will never be able to use them or later on my source code via 'official ways', because Apple and Google are very afraid of just-in-time compilation.]

If you mean callbacks with 'communicate': These are *very* expensive and I avoid them if possible.
So I mostly use the ordinary "shell" command which is "blocking" LC, but that's what I want for my "short" jobs.

on mouseUp
put "What I had to do" into job -- just a marker for you
put "io.write("&quote&job&": Job done."&quote&")" into ljEnd
put "luajit" into lj -- if available in $PATH
-- put <fullPathToLuaJIT> into lj -- if not yet in $PATH
put <fullFilePath> into f0 -- f0 must have extension ".lua"
put (fld "myscript") &cr& ljEnd &cr into URL("file:" & f0)
put shell(lj && quote&f0&quote ) into rslt
if rslt is job&": Job done." then
-- use the output file that luaJIT wrote for you
else put rslt into fld "error"
end mouseUp

Split debugging:
If your script fails then try in the CLI directly with file f0
(I prefer Geany, which has a "compile" menu item).
If you succeed then search the LC error.

Thanks for this insight in your solution. My process to be handled by luajit is much more time consuming with continuous status communication and control so a blocking call isn't an option. I'm going to see if "read/write process" or TCP socket communication will suit me better.