Site News :: DSL v4.3



Hi Robert!

Just a quick note following a hunch I got. I checked out k3b.dsl in mydsl repository and found that a change ocurred late last year on everything but the info file. So I guessed it was just conformed to the standards of DSL 4.x. I made an .unc extension (since I'm low on ram) and it works flawlessly in DSL 4.3 with even when gtk+-2.12.9 is set up. Just think I'd let you know. I can see that you are busy with more important things right now. Thanks for your good work!

As always have fun with DSL,
meo
I have a question about the new "open lua fltk" and how separate this is from murgalua. Does it function under murga's muddled licensing or is it completely separate and therefore will function under the sum of (less restrictive and much clearer) licenses of its parts?

Edit: by less restrictive:
lua = MIT license
lua socket and lua filesystem = same (?)
fltk = LGPL (which isn't as restrictive as GPL)
zlib =  free (Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions:
1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the productd ocumentation would be appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.)
sqlite = public domain
etc.

By clearer, see the murgalua "compiler license" which is hardly a license and apparently wasn't written by a lawyer. While DSL users may or may not care about using these tools for commercial purposes, Murga forbids what the sum of his parts allow: "To fit into the filosofy behind murgaLua you may not encrypt, obfuscate or otherwise further restrict the accessibility of code compiled within applications produced by the murgaLua compiler."

He's certainly entitled to his "filosofy" (sic) but so are the authors of the other projects he's built his upon and they don't force users to behave according to certain precepts and conditions like Murga does. Freedom is a two way street, else it's not really freedom.
As each part is now separate, each is under their original license.

Why I call this open lua fltk, is because, one can download the individual parts and use them as most lua libraries are intended.

Many of the parts recently added to murgaLua binary are not used or needed in DSL. zlib for example. I am really only interested in the lua to fltk bindings. John Murga has done this and florian has compiled the fltk bindings into murgalua-0.6.8.so. together with some glue code in /usr/local/share/lua/5.1.fltk.lua.

Other lua supported libraries provide their own bindings, and hence their own license. For example, independently, I was able to compile and use the latest lua-socket and lau-filesystem without  regard to the fltk bindings. Which, is what it should be, IMHO. Why would I need to be burdened with the fltk widget set, if my intended use is for a command line only filesystem and/or socket interface lua script?

Many of the other libraries and hence, bindings embedded in the murgaLua binary are not in the version in DSL. I also have no intention to use or include the murgaLua compiler. It is only the fltk that I have an interest in. That has been the case since I started with Jay Carlson's lua fltk bindings.

Because it is open the developer can choose to "require" only those parts necessary to the task at hand.
Quote
By clearer, see the murgalua "compiler license" which is hardly a license and apparently wasn't written by a lawyer. While DSL users may or may not care about using these tools for commercial purposes, Murga forbids what the sum of his parts allow: "To fit into the filosofy behind murgaLua you may not encrypt, obfuscate or otherwise further restrict the accessibility of code compiled within applications produced by the murgaLua compiler."

He's certainly entitled to his "filosofy" (sic) but so are the authors of the other projects he's built his upon and they don't force users to behave according to certain precepts and conditions like Murga does. Freedom is a two way street, else it's not really freedom.
I think I can see your concern about freedom, but the reason for this license is simply to keep compiled scripts readable after decompiling. It has no weight on any aspect of the package other than the compiler itself.  While I think requiring scripts to be non obfuscated is a bit strange, intentional obfuscation is a silly and selfish thing that should be discouraged.  If you don't want people to read or understand your code, don't use an interpreted language.  That's as basic as the GPL approach to software "property": if you want a non-GPL license, don't use GPL code.

All that said, I've never had any interest in compiling scripts anyway =op

I'm still torn about this open version, but i'll have to reserve judgement until after trying it.  My main concern is how existing murgaLua scripts work (or don't work) with it...whether they all require some level of modification. Switching from Lua-FLTK to murgaLua was ultimately a very good idea, but the transition was a bit of a pain.

Essentially I prefer the concept of a smaller faster runtime, with the option of adding modules since that feature is already part of Lua.  On the other hand, a modular interpreter can theoretically become a bigger pain than a monolith when it comes to dependencies for the end user, as is demonstrated by Perl.
Quote

If you don't want people to read or understand your code, don't use an interpreted language.

Well, in fact it's not anymore a problem for proprietary software to use interpreted language! This is because modern interpreters first compile source into bytecode (which is then run on a virtual machine) and therefore also happily accept some pre-compiled bytecode as input instead of a plain readable script.

Of course, the "valid" reason to use bytecode over source is to make script invocation faster. For example, if a Lua script is to be invoked repeatedly from a shell script's loop, you might want to compile it before the loop, store the bytecode in a tmp directory, and only use the bytecode form from within the loop.

A Lua byte code compiler (luac) is included in the official Lua distribution or one can use the bare bones tiny version below:
Code Sample
#!/bin/lua
if (arg[1]==nil or arg[2]~=nil)
then
 print("usage: luac.lua file.lua")
 os.exit(1)
end
f=assert(io.open("luac.out","wb"))
assert(f:write(string.dump(assert(loadfile(arg[1])))))
assert(f:close())
Next Page...
original here.