Re: CGILua vis-a-vis Javascript

[Paul K <paulclinger@...>]

Hi Tim,

> I've never done much lua debugging outside manual print statements and the looking at > stack traces when it crashes.  I can tell you that brozula doesn't contain a browser-side > compiler, so it can only run static pre-compiled bytecode.

That should be fine. The debugging should still work without the browser-side compiler (some functions like EXEC/EVAL won't be available). What happens when you include debug library calls in the compiled bytecode? Specifically, debug.sethook and debug.getinfo. If you don't have those implemented in brozula, I presume the calls will fail at run-time. The question is, would it be difficult to add those if you have a mechanism to emulate a line/call/return hooks and provide access to Lua stack frames.

Paul.

On Wed, Jan 2, 2013 at 2:21 PM, Tim Caswell <tim@creationix.com> wrote:

On Wed, Jan 2, 2013 at 4:17 PM, Paul K <paulclinger@yahoo.com> wrote:

Hi Tim,

> The really time consuming part is finishing the implementation and building proper dev tools.  The built-in tools are _javascript_-centric and not much good for debugging lua code.  Either the abstraction is leaky (debugging at the JS level) or someone needs to write new dev tools that work at the lua level.  This can be done, but it's more work than I am able to do without some form of sponsorship.

I wonder if it's possible to add (even limited) support for debug.sethook and debug.getinfo which would allow using remote debuggers like MobDebug (although those I've seen require coroutine support). I could probably try making it to work over WebSockets, which, if successful, would allow debugging of Lua pages from an IDE (like ZeroBrane Studio).

I've never done much lua debugging outside manual print statements and the looking at stack traces when it crashes.  I can tell you that brozula doesn't contain a browser-side compiler, so it can only run static pre-compiled bytecode.

 

Paul.

On Wed, Jan 2, 2013 at 1:38 PM, Tim Caswell <tim@creationix.com> wrote:

The reason I started (but never finished) brozula was to play around writing a luajit byte interpreter.  But there is no technical reason that a full lua runtime can't be implemented in browser _javascript_.

While working on brozula, I tried a few techniques and I'm confident that a full-featured lua runtime complete with coroutines is not only possible, but will be fast enough for most uses.  (The trick to get good speed is to JIT _javascript_ code on the fly and let the browser's JIT engine chew on that.)  I was able to get over 3 million runs per second of the following lua program:

local data = {"This", "is", "a", "stream?"}

local index = 1

print("before")

while data[index] do

  print(data[index])

  index = index + 1

end

print("after")

The best DOM interface I've come up with so far is allowing lua to call JS functions directly and doing a best effort to translate.  For example, I have to store references to how a function was last looked up (to know the "this" value in js)

I was able to port my dombuilder.js library to lua and run it mostly successfully. https://github.com/creationix/brozula/blob/master/widgets/dombuilder.lua

The really time consuming part is finishing the implementation and building proper dev tools.  The built-in tools are _javascript_-centric and not much good for debugging lua code.  Either the abstraction is leaky (debugging at the JS level) or someone needs to write new dev tools that work at the lua level.  This can be done, but it's more work than I am able to do without some form of sponsorship.

-Tim Caswell

On Wed, Jan 2, 2013 at 2:16 PM, Javier Guerra Giraldez <javier@guerrag.com> wrote:

On Wed, Jan 2, 2013 at 1:05 PM, Tim Mensch <tim-lua-l@bitgems.com> wrote:
> In my opinion, HTML5 is the only cross-platform GUI API that is even halfway
> decent on all platforms. Qt is the next contender

depressing but quite true.  that's why a Lua-DOM bridge can be so
useful regardless of how widely deployed any underlying technology is.
 Extra points if it runs 'real Lua' (or LuaJIT) and doesn't involve
JS.

--
Javier