visuallua-devs Mailing List for VisLua

I like the idea of a cross platform IDE for Lua
constructed as much as possible out of Lua itself,
but I suspect that it will not be possible to include
the OS I use, RISC OS. Its approach is too different from
Unix/Windows based systems. Nevertheless, some may find
something of interest in the tools I use for writing Lua
scripts. RISC OS has had practically from the beginning
an editor called StrongED with the following features:

A library of "modes" which extend a "basemode". The user
can create her own modes and modify the basemode. The mode
determines the presence, appearance and functionality of
the "toolbar" and the pop-up menus of the windows displayed
in its mode, how the file is to be presented on screen,
and under what circumstances it is to be used when a new file
is loaded. The mode is a directory containing text files
"modefile", "modewhen", etc, that control these things, written in
StrongED's command language. They are scanned and re-interpreted
when a new file is loaded. The mode directories also contain
resources - graphics, speech, key bindings, help files, etc
that are pertinent to the mode. The mode directories are held
in a configuration application quite separate from the editor
itself, so that upgrading the editor and adding new modes are
orthogonal activities.

The basemode provides an 'apply' tool. The user can "register"
a scripting language to StrongED, so that dragging a script
written in a registered language to the apply tool will cause
the contents of the window to be transformed by the script.
In most cases, the contents of the window are piped to a file
which is presented as a command line argument to the script,
and the standard output from the execution of the script is
piped back into the window, or into a different window, according to
the type of dragging action. This provides a very useful
graphical environment for testing the action of scripts. You can
have two windows open, one for the script, one for the text it
is to act on, and then apply the former to the latter with a
flick of the mouse.

The basemode provides 'folding' of text. Modes for writing
programs can use this to hide function bodies, for example.
Such modes usually provide syntax colouring, and facilities
for creating a list of functions, or other structures, defined by
pattern matching. The list is provided as a scroll down menu.
Clicking on an item instance will scroll the main window to where in
the text it occurs. This feature is useful in conjunction with
the basemode function that splits the window into separately
viewable windows onto the same file.

In short, StrongED provides a huge range of features and is
very easy to configure.

Is this the sort of thing that Vis Lua is expected to provide?


-- 
Gavin Wraith (ga...@wr...)
Home page: http://www.wra1th.plus.com/

> I thought I might make a quick report, seeing
> that Risc OS was kindly mentioned in the list
> of platforms suggested for VisLua. I rather
> suspect that you may have to count it out
> of consideration, because it does things so
> very differently.

I used to have an Archimedes a while ago. I remember it is pretty different.
Not quite sure what RISCOS looks like now. I assume similar, very modular
and clean. I mentioned it because it is a platform that Lua is supported on
(and I liked it ;-). The idea is that VisLua has a simple communication core
which might have a simple console UI or a full blow wxWindows/wxLua GUI
layered on top.

>   There are a number of free text editors
> available on Risc OS, most of which have
> user-definable modes. I use StrongED.

I think I used that one many moons ago. Perhaps you could integrate VisLua
core with that, when I get to spend some more time on it! Currently about to
move job so may happen soon. The new editor LuaIDE is looking quite nice for
the Windows platform, but not open source (I think) and only Windows.

> It would be nice to have a Lua parser written in
> Lua. Syntax colouring of Lua source files is necessarily
> a bit simple minded without a proper parsing of the
> text.

Does StrongED not handle that? Shame you cant use SciTE, its a nice little
editor. The Scintilla control is integrated into wxWindows, and works with
wxLua now. Perhaps you could port wxWindows to RiscOS ;0D  Actually I think
work started on a Lua syntax parser because we wanted one for the Wiki to
start with, but I've dont remember seeing a working version.

Nick

I thought I might make a quick report, seeing
that Risc OS was kindly mentioned in the list
of platforms suggested for VisLua. I rather
suspect that you may have to count it out
of consideration, because it does things so
very differently.

  There are a number of free text editors
available on Risc OS, most of which have
user-definable modes. I use StrongED.
Each mode can augment the icons displayed
on the top of the page with its own, and
can bind to them almost any kind of function.
In particular, each mode can have its own
helper-applications, which can take the
file currently displayed in the editor
window, or selected fragments of it, as input,
and can replace the window contents with their
output.

  For example, in my Lua mode for StrongED there
is an icon which when clicked applies Nick Trout's
vmmerge to display the Lua vm opcodes merged
with the source text. It is not an action that
one needs often, but it displays the flexibility
of the text editor.

In fact in any mode you can apply an awk script
displayed in one editor window to the text displayed
in another. Have a look at

http://www.wraith.u-net.com/awk/example/

for screenshots.


 Adding error throwback to a text editor window
for debugging Lua programs can be done by modifying
_ALERT. Single-stepping through a Lua program is
something I have not really thought about yet.

It would be nice to have a Lua parser written in
Lua. Syntax colouring of Lua source files is necessarily
a bit simple minded without a proper parsing of the
text.
   
-- 
Gavin Wraith (ga...@wr...)
Home page: http://www.wraith.u-net.com/

Apologies for the silence only our company went down the pan last week so
I'm currently wondering what to do with myself!

Will try and get what I have organised and into cvs but not my main priority
at the moment! :-)

Cheers,
Nick

> I've written a telnet test app so you can log into a remote Lua
> session and
> run commands. It traps errors and output.
very nice!

i've made some minor enhancements (in lua ;) to the output handling... see
my attached file.

>Works okay with cygwin. MS telnet fouls up unsurprisingly (CR problem I
>assume). If you havent got cygwin and you use Windows, get it now, its
>great!!! :-)
hmm, i used the telnet app that is provided with my Win2K  (Hilgraeve
Hyperterminal)
which works fine if you enable it to send line feeds in the
AscII-Settings...

>Next problem is GUI. May look at getting LuaSWIG working with wxPython
>bindings since wxLua still down.
i have a copy of wxLua if you need it.

but - i think we can focus on the debugger first, who needs a GUI anyway ;)

Regards,
Peter

To save your time, the correct link is:
http://lua-users.org/files/wiki_insecure/users/ntrout/vislua/vlds_test.zip

Peter

I've written a telnet test app so you can log into a remote Lua session and
run commands. It traps errors and output.

Its on the wiki implementation page at the bottom:
http://www.lua-users.org/wiki/wiki_insecure/users/ntrout/vislua/vlds_test.zip
I think

Compile it and run it.

In new shell, on local or remote machine:
telnet [-d] <machine> 8000

Works okay with cygwin. MS telnet fouls up unsurprisingly (CR problem I
assume). If you havent got cygwin and you use Windows, get it now, its
great!!! :-)

Havent tested ldblib yet. I'm off home. Anyway try it out.

Feedback appreciated.

Next problem is GUI. May look at getting LuaSWIG working with wxPython
bindings since wxLua still down.

Have a good weekend everybody. I'm redecorating. No rest for the wicked. May
try and do some more over weekend.

Nick

> > For an application (like VisLua) LGPL is not really suitable, GPL is
> > for standalone applications.
> That's my understanding as well.  The LGPL actually would apply to the
> debug server core, since that is a thing that links with the user's
> application.

But it wouldnt be distributed would it? You could remove the debugging tools
in the release build. I think its what is in the distribution/release build
that counts.

> > I personally would prefer MIT, XFree or LUA style licensing, but
> > I guess I might just prefer an emacs based LUA IDE....
> Me too, I prefer that kind of liberal license.  Partly for selfish
> reasons -- I don't have to get anybody's permission to include the
> code in a project for work.

I think I'd prefer that route as well. I suppose the reason for suggesting
LGPL was to try and ensure its continued development, but if we could get the
Lua community interested in VisLua this may not be a problem.

> I think the debug server core at least must be under the Lua (or
> equivalent) license, since many people will want to embed it in their
> apps, and not have to sweat the licensing issues.
>
> On the client side, I have no problem with either the GPL, or a
> Lua-like license.  The question that's likely to arise in practice
> with the GPL, is whether a game company (for example) could release a
> tweaker/editor tool for their game, based on VisLua code, without also
> releasing source for it.  I can happily go either way on that question.

I think it may all get horrible complicated so we may be better going with a
Lua (or BSD?) license? The current license for Lua seems to work for everyone
already. We dont want to scare people off with licensing issues, after all we
want people to use this tool!

In order to issue a license do we have to claim copyright? Is that how it
works?

Regards,
Nick

[replying to a thread from the lua list on the visuallua-devs list,
since my comments are VisLua-specific]

On Thu, 15 Nov 2001, Eero Pajarre wrote:

> Nick Trout wrote:
>
>  > What happens if you have LGPL copyleft? Can you only have GPL
>  > copyleft? LGPL says you dont have to distribute changes to a
>  > library if you are commercial and dont want to. GPL says you must
>  > always distribute changes.
>
> I am pretty sure you have misunderstood LGPL. With it you still have
> to provide your modifications to the library, if you distribute it.
>
> You are not required to provide the source code of your application,
> but you have to provide the user some means to relink the
> application to the library (for library modifications etc)
>
> For an application (like VisLua) LGPL is not really suitable, GPL is
> for standalone applications.

That's my understanding as well.  The LGPL actually would apply to the
debug server core, since that is a thing that links with the user's
application.

> I personally would prefer MIT, XFree or LUA style licensing, but
> I guess I might just prefer an emacs based LUA IDE....

Me too, I prefer that kind of liberal license.  Partly for selfish
reasons -- I don't have to get anybody's permission to include the
code in a project for work.

I think the debug server core at least must be under the Lua (or
equivalent) license, since many people will want to embed it in their
apps, and not have to sweat the licensing issues.

On the client side, I have no problem with either the GPL, or a
Lua-like license.  The question that's likely to arise in practice
with the GPL, is whether a game company (for example) could release a
tweaker/editor tool for their game, based on VisLua code, without also
releasing source for it.  I can happily go either way on that question.

-Thatcher

----- Original Message -----
From: "Matt Holmes" <ma...@ke...>
To: "VisLua Dev" <vis...@li...>
Sent: Thursday, November 15, 2001 5:10 PM
Subject: Re: [VisLua-Devs] license


> The LGPL is fine, except that it would allow our debugger to be used from
> commercial software. Is this what we want?

This is an interesting article:
http://www.gnu.org/philosophy/why-not-lgpl.html

LGPL allows VisLua to be used in commercial products and any changes hidden.
GPL can only be used on free software, so it may force software to be open, or
it may mean VisLua is avoided.

I think it depends on whether VisLua is distributed with a product, and if it
had been modified. If it has not been modified then the license is not an
issue. If it is modified then the license applies. If GPL you must release any
changes, if LGPL you need not. So the solution may come down to your employer
and whether they will stop you releasing work you have done - despite getting
it free in the first place! - Is that correct?

WRT public domain, I mean the license, which is the wrong context, public
domain is to do with copyright. If VisLua is in the public domain anyone can
do what they like. If we go copyleft (http://www.gnu.org/copyleft/) future
users have access to modified code - To my mind this conflicts with LGPL?

So to be fully open we go copyleft and GPL.
To allow commercial development hiding we go public domain and LGPL.

Mmmm. Thoughts? (or corrections)

Nick

The LGPL is fine, except that it would allow our debugger to be used from
commercial software. Is this what we want?

K.

----- Original Message -----
From: "Nick Trout" <ni...@vi...>
To: "VisLua Dev" <vis...@li...>
Sent: Thursday, November 15, 2001 10:21 AM
Subject: [VisLua-Devs] license


> Well, given the wxLua license issue. Perhaps we ought to clarify what the
> license situation is here.
>
> Is everyone happy to go with an LGPL license?
> http://www.gnu.org/copyleft/lgpl.html
>
> Please raise any issues you have. I dont think the license issue is a
problem.
> The important thing is that we agree the code is not in the "public
domain",
> it is LGPL. I believe that is how it is termed :-)
>
> Nick
>
>
>
>
> _______________________________________________
> Visuallua-devs mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visuallua-devs
>

Well, given the wxLua license issue. Perhaps we ought to clarify what the
license situation is here.

Is everyone happy to go with an LGPL license?
http://www.gnu.org/copyleft/lgpl.html

Please raise any issues you have. I dont think the license issue is a problem.
The important thing is that we agree the code is not in the "public domain",
it is LGPL. I believe that is how it is termed :-)

Nick

As Thatcher said, Telent is really just a catch term for plain text over a
socket ;)

Telnet is actually a good idea, because we can send raw text commands and
simply interpret them in the host VM. Pretty simple actually. A simple
session might look like:

---> is to server
<--- is from server


---> init_debug_session( )
<--- Session Init OK
---> dostring(.....)
<--- <Results>
---> getlocal(x)
<--- <Value of X>

etc etc

If we want to, we can even have the server pass back extra information.
Obviously the response from the server will be formatted under our
specifications, for easy information extraction. Because these connections,
in most cases, will be localhost to localhost, the fact that it is plain
text should not matter. The upside of all this is, that you can debug remote
applications, which is a huge advantage.

K

>
> telnet ~= console + TCP/IP
>
> I think the idea is fairly sound, and not much (if any) different than
> what we've been assuming.
>
> Basically the server accepts connections; when a client connects, it
> sends strings, which the server interprets, and prints out any console
> output back to the client.
>
> In the above paragraph, replace "server" with "lua.exe", "client" with
> "user", and basically that's the same as the lua.exe interactive
> top-level.
>
> So yeah, I guess what we're proposing is to glue lua.exe's interpreter
> loop to a TCP/IP socket (or other replaceable comm link).  That's a
> good way to think of it; as long as there would be a reasonable way
> for a human to get some info out of the lua.exe console, then our
> debugger client should be able to get the same info out of the debug
> server.
>
> -Thatcher
>
>
> _______________________________________________
> Visuallua-devs mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visuallua-devs
>

> This is certainly something we could look into. I havent used
> telnet so I cant
> give any insight. It may save us having to establish our own
> protocol. Perhaps
> you could point us to some docs?

here is a python project that implements not only a telnet server, but also
ftp, web etc:
http://freshmeat.net/projects/twisted/

i guess we can easily convert the needed parts to lua.

Regards,
Peter

On Wed, 14 Nov 2001, Nick Trout wrote:

> > At least as a first step this would be nice i think - no need to
> > implement a client at all - just use a standard telnet client!
>
> I think the idea is that the whole system is flexible. ie. there
> could be multiple methods. The transport format/protocol hasnt been
> discussed yet. eg.  you could configure VisLua to use telnet,
> compile and run a debug session.  This is certainly something we
> could look into. I havent used telnet so I cant give any insight. It
> may save us having to establish our own protocol. Perhaps you could
> point us to some docs?

telnet ~= console + TCP/IP

I think the idea is fairly sound, and not much (if any) different than
what we've been assuming.

Basically the server accepts connections; when a client connects, it
sends strings, which the server interprets, and prints out any console
output back to the client.

In the above paragraph, replace "server" with "lua.exe", "client" with
"user", and basically that's the same as the lua.exe interactive
top-level.

So yeah, I guess what we're proposing is to glue lua.exe's interpreter
loop to a TCP/IP socket (or other replaceable comm link).  That's a
good way to think of it; as long as there would be a reasonable way
for a human to get some info out of the lua.exe console, then our
debugger client should be able to get the same info out of the debug
server.

-Thatcher

> an idea has just struck me:
>
> what if we would implement the debugging server compatible to telnet:
> any text that we enter in the telnet session would be executed using
> dostring() on the client and any output on the server would be directed back
> to the debugging client via the telnet protocol.
>
> At least as a first step this would be nice i think - no need to implement a
> client at all - just use a standard telnet client!

I think the idea is that the whole system is flexible. ie. there could be
multiple methods. The transport format/protocol hasnt been discussed yet. eg.
you could configure VisLua to use telnet, compile and run a debug session.
This is certainly something we could look into. I havent used telnet so I cant
give any insight. It may save us having to establish our own protocol. Perhaps
you could point us to some docs?

Nick

Additionally, debugging is kinda like looking in
a telescope, ok, maybe a microscope. ;)

> -----Original Message-----
> From: Nick Trout [mailto:ni...@vi...]
> Sent: Wednesday, November 14, 2001 4:40 AM
> To: VisLua Dev
> Subject: [Visuallua-devs] Fw: name suggestion
>=20
>=20
> > Hi,
> > when I read your email I thought:
> > - Lua (Moon);
> > - Visual (see);
> > - see the Moon;
> >
> > - Luneta!
> >
> > Luneta, in brazilian portuguese, is a simple telescope (I=20
> don=B4t know a thing
> > in astronomy, I may be saying something silly). I supose=20
> this name came from
> > the fact that the first telescopes ever made were used to=20
> see the moon.
> >
> > I realy don=B4t know if there is a similar name in english.
> >
> > Regards,
> > Fred
>=20
> I think this sounds quite a nice name for the debugger? The=20
> project name
> remains unchanged, VisLua, and the GUI debugger is called=20
> "Luneta"? I think a
> Portugese name for the editor would be good as well.
>=20
> see the moon, I like that.
>=20
>=20
>=20
>=20
> _______________________________________________
> Visuallua-devs mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visuallua-devs
>=20

> hmm, while it might be possible to setup lua hooks on the server side that
> wait for dostring()s from the client, this solution seems to be ugly.
> the client would have to poll (using dostring()) regularly to see, if the
> server has run into any of the hooks.

Okay, I'm not a sockets/comms expert so please put me straight if I've made
any mistakes. I'm looking at luasockets docs for a lot of my information.

I think it would probably receive a message to tell it to do something rather
than polling. The only reason I can see for the client having to regularly
poll the server is to see if its still alive?

> i think it would be better to make the communication two-way, i.e.
> dostring() (from client to server)
> and a way for the hooks to signal back from the server to the client that
> something has happened.

I think once the sockets are established, and if they are non blocking, you
are free to talk both ways? We just have to establish a protocol so that the
client and server know whats going on when they receive a message.

> you will also need a way for the debugger client to capture the output of
> the application server.
> (although, even here, you could redirect the output on the server into a
> table and poll that table from the client - yikes)

write() and print() can be redirected, and _ALERT is easy enough to redirect
as well. Again we can signal when there is a message being sent, unless the
client is awaiting one.

> i'm not sure if "client" and "server" are good words to use for our case of
> "application-under-test" and "debugger".

This whole problem does raise the issue of chicken and egg. Should the app
connect to the debugger or should the debugger connect to the app? I think
since we may not have a mechanism to launch a remote app it is better for the
debugger to connect to the app, as we are doing.

Perhaps the way to look at it is that the debugger is the client, or recipient
of the error information in the "debug session" and the application is the
"debug server" or provider of information, rather than client/server model in
the classic sense?

Nick

Replying to my own post:
> hmm, while it might be possible to setup lua hooks on the server side that
> wait for dostring()s from the client, this solution seems to be ugly.
>
> i think it would be better to make the communication two-way, i.e.
> dostring() (from client to server)
> and a way for the hooks to signal back from the server to the client that
> something has happened.
> you will also need a way for the debugger client to capture the output of
> the application server.

an idea has just struck me:

what if we would implement the debugging server compatible to telnet:
any text that we enter in the telnet session would be executed using
dostring() on the client and any output on the server would be directed back
to the debugging client via the telnet protocol.

At least as a first step this would be nice i think - no need to implement a
client at all - just use a standard telnet client!

Regards,
Peter

> > The only other thing we need is a possibility to setup hooks
> for tracing and
> > errorhandling.

> From the manual :
> * getlocal (level, local)
> * setlocal (level, local, value)
> * setcallhook (hook)
> * setlinehook (hook)

> I think you can do this via ldblib through Lua script so the
> client debugger
> can make the appropriate calls to set all this up.
> )))
>
> So I think we can just set this up in Lua from the client, using
> dostring().
> (untested!)

hmm, while it might be possible to setup lua hooks on the server side that
wait for dostring()s from the client, this solution seems to be ugly.
the client would have to poll (using dostring()) regularly to see, if the
server has run into any of the hooks.

i think it would be better to make the communication two-way, i.e.
dostring() (from client to server)
and a way for the hooks to signal back from the server to the client that
something has happened.
you will also need a way for the debugger client to capture the output of
the application server.
(although, even here, you could redirect the output on the server into a
table and poll that table from the client - yikes)

Regards,
Peter.

P.S.
i'm not sure if "client" and "server" are good words to use for our case of
"application-under-test" and "debugger".

> I am not sure that I am convinced that writing the debugging server/client
> in Lua is the greatest idea. How can you possibly trust a VM to debug
> itself? Thats generally dangerous. I would feel much more comfortable if the
> debugging sections were written in C, hooking in to the VM that the code is
> running in.
>
> I know many of you want to do this in pure Lua, but lets try and remember
> that Lua is a scripting and application extension language, and writing
> parts of the IDE logic and GUI in Lua are wonderful, but sometimes its just
> smarter to write certain sections of the code in the native language we
> choose.

I cant see a good reason not to do it all in Lua yet. If we encounter a
problem we'll deal with it. This may mean more code moving over to C, or extra
features being added and bound to Lua. The debugger is to debug Lua code, not
problems with the app or bindings, for this you should still use a C debugger.

So far, I think the current discussion is leaning towards componentizing the
entire suite of tools. Basically, the IDE, debug client, debug server and
all other tools involved should be components, and essentially independant
of each other.

To this end, I think we need to break everything in three easy to use
sections, for discussions purposes:

IDE - This is the GUI part of the suite. This should use the debug client
for debugging ,but that debugging client should be able to be used by any
IDE really. Our IDE will basically become a "reference" implementation for
our debugging scheme.

Debug Client - This is the debugging client that acts as middleware between
the IDE and the debugging server. This extra layer of abstraction allows the
debugger to be completely untied from the IDE, allowing any IDE to
theoratically hook in to the debugger (choice is always good :)

Debug Server - This is the meat and potatoes of what we are doing. This is
what runs, monitors, and provides feedback on the script, or application,
that the developer is attempting to debug.

So, what we have is the IDE, DC and DS. This should make the conversations
easier to follow in the end. The entire suite of apps is called VisLua, but
each sub-component can have its own name or development code name as well (I
am a big fan of development code names, I think they give software
personality :)

I beleive we already had a code name suggested for the debugging portion?
Luneta or something along those lines?

K

I am not sure that I am convinced that writing the debugging server/client
in Lua is the greatest idea. How can you possibly trust a VM to debug
itself? Thats generally dangerous. I would feel much more comfortable if the
debugging sections were written in C, hooking in to the VM that the code is
running in.

I know many of you want to do this in pure Lua, but lets try and remember
that Lua is a scripting and application extension language, and writing
parts of the IDE logic and GUI in Lua are wonderful, but sometimes its just
smarter to write certain sections of the code in the native language we
choose.

k

----- Original Message -----
From: "Nick Trout" <ni...@vi...>
To: "VisLua Dev" <vis...@li...>
Sent: Wednesday, November 14, 2001 12:03 PM
Subject: Re: [VisLua-Devs] Inspector


> > > Right so if we can execute strings on the server we can debug our Lua
app.
> >
> > The only other thing we need is a possibility to setup hooks for tracing
and
> > errorhandling.
>
> From the manual :
> (((
> * getlocal (level, local)
> This function returns the name and the value of the local variable with
index
> local of the function at level level of the stack. (The first parameter or
> local variable has index 1, and so on, until the last active local
variable.)
> The function returns nil if there is no local variable with the given
index,
> and raises an error when called with a level out of range. (You can call
> getinfo to check whether the level is valid.)
>
> * setlocal (level, local, value)
> This function assigns the value value to the local variable with index
local
> of the function at level level of the stack. The function returns nil if
there
> is no local variable with the given index, and raises an error when called
> with a level out of range.
>
> * setcallhook (hook)
> Sets the function hook as the call hook; this hook will be called every
time
> the interpreter starts and exits the execution of a function. The only
> argument to the call hook is the event name ("call" or "return"). You can
call
> getinfo with level 2 to get more information about the function being
called
> or returning (level 0 is the getinfo function, and level 1 is the hook
> function). When called without arguments, this function turns off call
hooks.
> setcallhook returns the old hook.
>
> * setlinehook (hook)
> Sets the function hook as the line hook; this hook will be called every
time
> the interpreter changes the line of code it is executing. The only
argument to
> the line hook is the line number the interpreter is about to execute. When
> called without arguments, this function turns off line hooks. setlinehook
> returns the old hook.
> I think you can do this via ldblib through Lua script so the client
debugger
> can make the appropriate calls to set all this up.
> )))
>
> So I think we can just set this up in Lua from the client, using
dostring().
> (untested!)
>

> > Right so if we can execute strings on the server we can debug our Lua app.
>
> The only other thing we need is a possibility to setup hooks for tracing and
> errorhandling.

From the manual :
(((
* getlocal (level, local)
This function returns the name and the value of the local variable with index
local of the function at level level of the stack. (The first parameter or
local variable has index 1, and so on, until the last active local variable.)
The function returns nil if there is no local variable with the given index,
and raises an error when called with a level out of range. (You can call
getinfo to check whether the level is valid.)

* setlocal (level, local, value)
This function assigns the value value to the local variable with index local
of the function at level level of the stack. The function returns nil if there
is no local variable with the given index, and raises an error when called
with a level out of range.

* setcallhook (hook)
Sets the function hook as the call hook; this hook will be called every time
the interpreter starts and exits the execution of a function. The only
argument to the call hook is the event name ("call" or "return"). You can call
getinfo with level 2 to get more information about the function being called
or returning (level 0 is the getinfo function, and level 1 is the hook
function). When called without arguments, this function turns off call hooks.
setcallhook returns the old hook.

* setlinehook (hook)
Sets the function hook as the line hook; this hook will be called every time
the interpreter changes the line of code it is executing. The only argument to
the line hook is the line number the interpreter is about to execute. When
called without arguments, this function turns off line hooks. setlinehook
returns the old hook.
I think you can do this via ldblib through Lua script so the client debugger
can make the appropriate calls to set all this up.
)))

So I think we can just set this up in Lua from the client, using dostring().
(untested!)

> > What about poking around with an apps values? Lets say I have
> i don't think it would be a good idea to support anything like this. let's
> keep it simple.
> if you need to manipulate/inspect that colour array, provide a lua interface
> for it!
> (for example tolua would do fine)
>
> or convert it to lua tables and back, something like:
> t = GL_GetColourArray();
> foreach(t,function(i,v) t[i]=v/2 end) -- halfbright mode ;)
> GL_SetColourArray(t);

Mmm. Okay. I think this shouldnt be too difficult to put in later on. I think
it should follow similar principles to the debugger. ie. you are just
connecting to a remote Lua State and and passing values back and forth.

> > > Exactly!  I think that works.  So, our debug client core API
> is mostly:
> > >
> > > vlcc_dostring(...);
>
> Right so if we can execute strings on the server we can debug our Lua app.

The only other thing we need is a possibility to setup hooks for tracing and
errorhandling.

> What about poking around with an apps values? Lets say I have
> polygon that I
> want to change the colour of. Lets assume a GL colour array
> float[4], ie. raw
> data. How could I edit the value of this? Should this be a seperate tool?

i don't think it would be a good idea to support anything like this. let's
keep it simple.
if you need to manipulate/inspect that colour array, provide a lua interface
for it!
(for example tolua would do fine)

or convert it to lua tables and back, something like:
t = GL_GetColourArray();
foreach(t,function(i,v) t[i]=v/2 end) -- halfbright mode ;)
GL_SetColourArray(t);

Regards,
Peter