Apps :: DSL PanelI



OK, thank you guys for the attention. I really appreciate it. I'll try the lua/fltk later.
Quote
Or hopefully will be backward compatible.
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.
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.

Quote
What is typically is a module choice is no longer such
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.
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).
I recently played around with Xdialog, and gotta recommend it. It's a whole lot easier than Lua, but not of course as suitable for many cases.
I believe some of murga's choices is because his Lua language system is supporting multiple operating systems, i.e., the inclusion of lfs. Supporting only Linux one can get by with much less than supporting Windows and Mac.

Like I said I cannot find fault with that it is just on a 300Mhz machine the latest version is noticeable slower. I no longer use murga.isDirectory or lfs, but instead popen to access file system features. I use similiar syntax to support isDir readDir and getDirs. I am aware that popen is not supported on all other OS and thus the need for lfs

Personally I would agree that focus should remain on implementing the fltk bindings and not importing other third party libraries.

mikshaw, perhaps a custom build (Linux only) could be achieved using the documented build process? That way we could have just the fltk bindings?
Quote
Supporting only Linux one can get by with much less
I fully agree. It's a whole lot easier to write your scripts when doing only Linux, too. As you said, you can rely a lot on pre-existing programs to do things that would waste a lot of space and time in Lua script

Quote
perhaps a custom build (Linux only) could be achieved using the documented build process?
I had never thought of that, but I suppose it would probably work. I haven't looked at the bindings at all, but I suspect it could be cut down a bit without having to study it to the finest detail.  Hmmm...a new distraction =o)
Maybe I'll look at it after the sox game.
Next Page...
original here.