News : The level of daily SPAM has reached insane proportions, all registrations are now manual.
I ask you to send me an e-mail (john (at) murga (dot) org), to confirm that you want me to create an account for you.
Beta 2 is now available. This version doesn't have many changes, but I particularly wanted to fix that edit preview problem as soon as possible. It now uses a separate instance of murgaLua (using murgaLua_ExePath), and includes the global variables that are used in some of the widget demos. This of course won't work in murgaLua prior to 0.6, but with an earlier version the user can still export script changes and/or edit in the external editor. By the time the beta stage has passed I'll have rewritten the menu system anyway, so support for 0.5.5 will have to be dropped.
This post was last modified: 02-02-2008 06:51 AM by mikshaw.
I knew I should have posted my changes as I went along.
Everytime I edit this thing, you come out with a new version.
In order for the compiled and/or script version to run equally
I changed the code last night to this
Code:
-- set directory separator according to operating system
if murgaLua.getHostOsName() == "windows" then demo_sep="\\" else demo_sep="/" end
arg={}
--default to current directory, works after cd in scripting, not in standalone
CurDir = lfs.currentdir().."/"
-- find murgalua folder, or the script as compiled binary
pathToMurgaLua = string.gsub(murgaLua_ExePath,"(.*)/.*","%1").."/"
-- test for presence of demo scripts folder
if lfs.attributes(pathToMurgaLua.."script") ~= nil then CurDir = pathToMurgaLua end
-- in script mode the argument is received when executing this script
if arg[0] ~= nil then CurDir = arg[0] end
-- Get the dirname and basename of the current script or binary
if string.find(CurDir,demo_sep) then
demo_appdir=string.gsub(CurDir,"(.*)"..demo_sep..".*","%1") -- data directory
demo_title=string.gsub(CurDir,".*"..demo_sep.."(.*)","%1")
else
demo_appdir="."
demo_title=CurDir
end
arg throws an error in the compiled version unless it gets some data.
My changes manage to kill this bug.
Code:
/bin/murgaLua/examples/widgets: [string "--#!/bin/murgaLua..."]:236: attempt to index global 'arg' (a nil value)
stack traceback:
[string "--#!/bin/murgaLua..."]:236: in function 'newFunc'
[string "murgaLua"]:268: in function 'decompileMurgaLua'
[string ""]:1: in main chunk
[C]: ?
Also have to comment out "#!/bin/murgaLua" in the first line for compile.
It will throw a false error at line 268 for some reason.
I just made the code changes and recompiled it works on my side at least.
See what happens over there.
Also have to comment out "#!/bin/murgaLua" in the first line for compile
I couldn't say why, unless maybe the interpreter is checked against murgaLua_ExePath or something?
I'm going to continue using it in the releases, though (should be easy enough to remove before compiling). It's just my preference to make scripts executable and run them directly, and is common practice in Unix/Linux. Using a script as an argument to an interpreter is an unnecessary pain in my butt.
It looks like it needs more work to be used in both script and binary format. The arg={} line breaks the script...arg[0] no longer works after that, and therefore all paths are searched for in the current directory. That's definitely NOT acceptable...I need it to find the proper demo_appdir no matter what the current directory is, and I'm not going to force a change of directory in order to do this. Also, if arg[0] doesn't work in the binary there are at least two other places it needs fixing, in demo_menu_callback() and demo_show_readme().
I don't understand why the arg table doesn't work in the binary, since it's standard Lua. Perhaps there is a problem with the compiler.
Quote:
Before starting to run the script, lua collects all arguments in the command line in a global table called arg. The script name is stored at index 0, the first argument after the script name goes to index 1, and so on. Any arguments before the script name (that is, the interpreter name plus the options) go to negative indices. For instance, in the call
$ lua -la b.lua t1 t2
the interpreter first runs the file a.lua, then creates a table
and finally runs the file b.lua. The script is called with arg[1], arg[2], as arguments; it can also access these arguments with the vararg expression '...'.
The compiled version doesn't get any arguments since it doesn't require an external script, arg will be nil unless the binary itself is sent an argument.
Sending the binary an argument of the original script does the trick.
No need to change any of the code I mentioned earlier.
Except that first line.
This post was last modified: 02-02-2008 03:08 PM by iGame3D.
I'm looking forward to seeing what you might find, but if there is no available pointer to the path of the executable I don't intend to support the binary version of this package. I'm not going to rely on the user being in the application directory.
EDIT: Okies, then. I spoke too soon. When you say "sending an argument" do you mean sending it when you compile, or the enduser sending an argument to the compiled package?
This post was last modified: 02-02-2008 03:20 PM by mikshaw.
The Applescript script that launches the executable sends the argument.
Its an applescript bundle with the murgaLua compiled binary "widgets" in a directory thus:
widgets.app/Contents/MacOS/widgets
The content of your widget stuff, images, scripts, etc is thrown into widgets.app/Contents/Resources/lua/
When the program bundle is double clicked it activates the following script,
which cd's to the bundle directory and launches the widgets binary with the
widgets.lua script acting as argument.
Code:
set murgaBinary to "Contents/MacOS/widgets"
set luascript to "Contents/Resources/lua/widgets.lua"
set bundlepath to path to me as string
-- cd and launch binary
set s to "cd '" & the POSIX path of bundlepath & "'; " & murgaBinary & " " & luascript
do shell script (s)
It could work with just a murgaLua executable instead of the compiled widgets binary,
which is how I ran it a long time ago, but this was a test of the compile process.
The benefit: no install, no authorization, no chmod, no command line
Just unzip + double click = widgets!
This post was last modified: 02-02-2008 06:21 PM by iGame3D.
Search
Member List
Calendar
Help
