I thought you guys might like to see what I'm actually working on...

14 views
Skip to first unread message

ShortWave

unread,
May 15, 2009, 4:48:57 PM5/15/09
to lua-alchemy-dev
http://skitch.com/sh0rtwave/bxxj6/skitch

This is a lua script that's running inside of my Kodiak application
(http://www.bluebear.org/Kodiak/ )

The important bit here is that it's spawned a window within the
application to receive arguments for processing inside the lua script.

Alexander Gladysh

unread,
May 18, 2009, 6:01:45 PM5/18/09
to lua-alc...@googlegroups.com

> http://skitch.com/sh0rtwave/bxxj6/skitch

Looks impressive, thanks for sharing!

Have you solved your problem with debug output?

Alexander.

ShortWave

unread,
May 19, 2009, 11:37:08 AM5/19/09
to lua-alchemy-dev
Yes, I am actually, and it's going to become an issue for people using
the script engine. Here's some exhaustive background on my case
(apologies in advance):

For a given data model type (interpret that as "vendor", ala VMWare),
I'm loading in a series of lua scripts to provide support for various
things.

I've separated the logic to communicate with the host application into
a "libKodiak.lua" file, and provided metatable support for a couple of
my major VO types (libManagedObject.lua, and libDynamicElement.lua).

The dataModel type itself will load its own support file with routines
to do various things. In the VMWare case, it loads "libVMware.lua".

My general architecture and approach is to, for each "type" of
ManagedObject (say, a VirtualMachine or Datastore) there's a set of
scripts that apply to it. I've provided for a class inheritance system
to allow operations that affect ALL ManagedObjects (say, Rename ) be
available to everything that "extends" that class.

So the idea is that in my UI, a list of scripts is provided for the
user to invoke. Since each script is primarily intended to perform
remote operations, it's going to require that the lua environment be
previously populated with the support libraries neeeded.

This is what that looks like: http://skitch.com/sh0rtwave/bk37s/kodiak-rule-your-virtual-empire

All of that aside, I'm basically loading a lua file from disk, and
running it via doString() for a given task.

All of my lua tasks are executed in this coroutine wrapper:
http://www.pastie.org/private/id4m7jp6zw9lutdbp4shpa

The issue arises when I encounter an error that crashes the script
engine.

stack traceback:
[C]: in function 'assert'
luaDoString:87: in function <luaDoString:75>

Since everything's in the doString, in an environment that's
constantly running, error messages are less than intuitive, and doubly-
so if it's in the script, since I have to do math (because of the
coroutine wrapper) to find the offending line, and if the line happens
to be in my support libraries...well you get the idea :)

So the question becomes, is it more sensible to use the virtual
filesystem so I at least have an idea of the failing module?
Or...well, I'm really at a loss for workable alternatives at the
moment. Suggestions?

On May 18, 6:01 pm, Alexander Gladysh <aglad...@gmail.com> wrote:

Alexander Gladysh

unread,
May 22, 2009, 3:39:02 PM5/22/09
to lua-alc...@googlegroups.com
Sorry for the late reply.

> Yes, I am actually, and it's going to become an issue for people using
> the script engine. Here's some exhaustive background on my case
> (apologies in advance):

<...>

Thank you for the description. It is important to know the actual
usage patterns for our library.

> All of that aside, I'm basically loading a lua file from disk, and
> running it via doString() for a given task.

> All of my lua tasks are executed in this coroutine wrapper:
> http://www.pastie.org/private/id4m7jp6zw9lutdbp4shpa

> The issue arises when I encounter an error that crashes the script
> engine.

> stack traceback:
>       [C]: in function 'assert'
>       luaDoString:87: in function <luaDoString:75>

> Since everything's in the doString, in an environment that's
> constantly running, error messages are less than intuitive, and doubly-
> so if it's in the script, since I have to do math (because of the
> coroutine wrapper) to find the offending line, and if the line happens
> to be in my support libraries...well you get the idea :)

> So the question becomes, is it more sensible to use the virtual
> filesystem so I at least have an idea of the failing module?
> Or...well, I'm really at a loss for workable alternatives at the
> moment. Suggestions?

1. doString() really should have an optional chunkname argument. This
would be added in the next release (patches or github pull requests
are welcome).

See lua_wrapper.gg:192

http://github.com/lua-alchemy/lua-alchemy/blob/3915434e5500930481d3517a5dbf90fe2aeecbcd/alchemy/wrapper/lua_wrapper.gg#L192

As an option, you may instead call Lua loadstring manually inside your
script and pass it filename, prefixed with "@" (like '@myfile.lua') to
imitate error-in-the-file stacktrace. But this would be an unnecessary
overhead (see below for better options).

2. It is good idea to wrap user's code into Lua pcall (or, better,
xpcall) to get better error reporting. You can use something like this
(code not verified):

local res, err = xpcall(function()
--%%KODIAK-SCRIPT%%--
end,
function(msg) -- Error handler
print(
"%%KODIAK-SCRIPT-NAME%% error:", -- You may want to escape
script name with %q
debug.traceback(msg) -- This gives a nice stacktrace
)
return msg -- Note you can adjust error message here.
end)

if not res then
error(err) -- You may want to handle error more gracefully.
end

This should give you nicer error messages.

3. For some other loading file from disk ideas, see

http://github.com/lua-alchemy/lua-alchemy/blob/3915434e5500930481d3517a5dbf90fe2aeecbcd/alchemy/lua-lib/assets/lua_alchemy/lua/dofile.lua

and

http://github.com/lua-alchemy/lua-alchemy/blob/3915434e5500930481d3517a5dbf90fe2aeecbcd/alchemy/lua-lib/assets/lua_alchemy/as3/filegetcontents.lua

This is broken though, as as3.flyield() does not work as expected. You
may want to replace it (in filegetcontents.lua) with actual
coroutine.yield() back to the core AS3 level (which would call
coroutine.resume when file is loaded).

I may explain this better if you're interested. This is a mere
convenience feature though, if you've got working doString
implementation, it may be enough.

HTH,
Alexander.

Alexander Gladysh

unread,
May 23, 2009, 2:42:50 PM5/23/09
to lua-alc...@googlegroups.com
I've forgot to add: please keep us informed on your progress. :-)

Alexander.

Reply all
Reply to author
Forward
0 new messages