Joined: July 2004
||Posted: Sep. 22 2007,13:25
Sadly, it's not entirely backward compatible. This was known when the latest was released, and it seems that the decision was to bite the bullet in order to make use of lua filesystem without including redundant features.
|Or hopefully will be backward compatible.|
It is possible to do checks within your script that will enable the script to be run on either version, but existing scripts may not work...if it expects murgaLua.readDirectory it won't work in 0.5 and if it expects lfs.dir it won't work in 0.4.
I haven't noticed any performance hit myself, but then I haven't booted up the older box since before 0.5 was released. I wonder if Mr. Murga is aware of this, and if there is any optimization that could repair the slowdown. I haven't got a clue how toolkit bindings work, but maybe the method he's using is in need of some performance tweaks. I undertstand that it is fairly common practice for some developers to use the same techniques on a growing project that they used when it was a tiny project, and often these techniques do not scale well.
My own personal wish for its development includes what some may consider creeping featurism, but as long as there are important (?) parts of FLTK that are not implemented, or only partially implemented, the project seems incomplete to me. After all, it is essentially Lua+FLTK.
I have only looked briefly into the possibility of using Lua modules in murgaLua, but so far have had no success understanding the process. I suppose it will become easy enough eventually, but the documentation on this subject is vague.
|What is typically is a module choice is no longer such|
If modules can be loaded into murgaLua as they are in Lua proper, it might be silly to include them, but I think it depends on what modules they are. Some things, such as lfs, are things that I consider vital for any task that involves working with files (which is nearly everything i've ever done). And then I think modules themselves can contribute to their own form of bloat, in that the number of modules a user needs seems to grow at a greater rate than the number of scripts using those modules (see Perl, Python).