Site News :: DSL v4.3

I compiled fltk toolkit as shared libs (~500Kb), a plain-vanilla lua interpreter (~100Kb), and I also compiled the fltk binding from murgaLua as its own separate extension to lua (argh! it's 700+ Kb)

Running a C app with those fltk shared libs worked well. But when it comes to lua, the interpreter doesn't let me load modules with the loadlib function for some reason (maybe i didn't compile lua with right options), so I can't check yet if the fltk bindings works well or not.

Well, it's bed time here. If I have time I'll continue tomorrow.

I have finally managed to invoke the bindings from some scripts in a standard lua interpeter. I have tried three scripts from DSL: calculator.lua, editor.lua, and stats.lua. The editor script is having problems; I don't know why. So it still needs to be checked if most other DSL scripts are able to run this way or not.

I have posted a tarball here:
http://florian.cauvin.free.fr/tmp/lua_fltk.tar.gz

This archive contains the standard lua interpreter and the needed shared libs for fltk and for the separated murgaLua bindings to fltk.
Also included:
- header files and tools useful for compilation of C/C++ programs using lua or fltk
- examples of compiled fltk program and of lua scripts using the libraries. (make sure to set up a correct LD_LIBRARY_PATH)

Everything is compiled with compile-3.3.5.uci under DSL.

WOW! What an improvement in runtime. Now even simple (non-gui) lua scripts run fast. And the GUI Fltk scripts are much faster as well. And the added bonus is to have the Fltk library for C++ programmers.

Note: libhistory was not used in murgaLua and is therefore not in core DSL. I had to mydsl-load compile-3.3.5.uci to get the missing library. After that it was smooth sailing. libhistory provides command history within the Lua interpreter.

I have tested several scripts with no problems so far.

Nice job!

Which version of fltk is there?

The only issues I have found are:

1. Fltk menu as already noted. Only concerns two programs, editor.lua and iconView.lua. For the second a work-around is possible. If we have to for go editor.lua for now, then that is OK.

2. Some Lua scripts are using lfs. Personally I don't use lfs, as I have written isDir, readDir, and getDirs using standard Lua and popen (see functions5.lua). So, I am sure that lfs could be dropped and the standard functions be used.

3. We do use Lua sockets. There is no work-around for sockets. So we need to have a lua sockets be able to be "require"d or loadlib'ed.

Next Page...
original here.