Topic: Lua scripting engine in Autocad

[pkohut]

Just kicking some thoughts around. Would there be any interest having Lua¹ available in Autocad? Lua is a very simple, small, and fast programming language, which a lot of game developers use.

Anyway, I was playing around yesterday, hooking up some basic plumbing to bridge Lua and Autocad/AutoLisp. It's surprisingly easy to implement (there's a catch) and I can call basic Lua scripts from visual lisp. Right now it's limited to strings and doubles, and output does not go to the Autocad command line.

So, I'm on the fence about going any further, cause there is lots of coding needed to get it to work and fit right. My thoughts are that it should be portable across platforms, and CAD systems, which means no .Net CLR implemention (there are a couple Lua .Net implementations already).

I saw a company website² that implemented an older version of Lua and Acad back in 2002. It doesn't look like they've kept it up to date though, and I don't know if they would open source the code.

The biggest drawback I can see is Lua does not support Unicode. There are a couple Unicode packages available, but I don't know if they extend Lua to support it, or just convenience functions. Extending Lua to support Unicode would be a big task. For testing purposes I just did a quick wstring to string convert at the bridge.

Next big issue would be to extend Lua to support support Autocad resbuf types, and initially some of the AcGe structures. This task would be much easier than the Unicode one.

Of course it would be nice to have input output at the Autocad command line.

And, since Lua is written in C, all these extensions would touch (to nice a word) Lua's source code. Lua's source code is stable since 2008, with only a small patch issued since then.



[1] http://www.lua.org/
[2] http://www.qsinformatica.it/white_paper03-e.asp

[Crank]

I don't know Lua, but about a month ago Autodesk asked in a survey what scripting languages should be supported and Lua was one of them. I voted for Python, but every language has it's strong and weak points.

[MickD]

It sounds like Lua would have the same problems as Python, ie. you would need to write the interface code to the native acad api, BIG job!
Mind you, if we're talking just acad then I'd imagine Lua could use COM, then you only need to initialise the scripting engine in arx and away you go.

I started writing a Python interface some time back and had a basic framework and examples of how to do it, it's not that hard, just a mammoth task!
For a real smart cookie with heaps of time I'd imagine you could even use your target language (Lua or Python) to write the interface C code for you with a bit of study.

SWIG is another alternative but due to some subtlties with how arx handles db object pointers (ie. it looks after the clean up at the db level 'outside' of the api if you like) it wasn't so straight forward which was a shame, I'd imagine there would be a Lua swig module as well but you would hit the same wall/s I'd imagine.

[pkohut]

It sounds like Lua would have the same problems as Python, ie. you would need to write the interface code to the native acad api, BIG job!
Mind you, if we're talking just acad then I'd imagine Lua could use COM, then you only need to initialise the scripting engine in arx and away you go.

I started writing a Python interface some time back and had a basic framework and examples of how to do it, it's not that hard, just a mammoth task!
For a real smart cookie with heaps of time I'd imagine you could even use your target language (Lua or Python) to write the interface C code for you with a bit of study.

Mammoth task indeed! I came across a C++ to Lua interface generator yesterday, but can't find the link. However, this bindings page http://lua-users.org/wiki/BindingCodeToLua has lots of tools already available to ease the task.

I'll muck around with this for a day or so, getting a few more hooks in place and report back.

[pkohut]

Hm, ICU4Lua was created by IBM, and adds Unicode support to Lua. It's interesting also, because it adds support for a ustring data type without mucking with any of the Lua source code. That means other native ADS types could be implemented in the same manner.

[MickD]

sound cool!

just to elaborate on the arx and pointer issue, the interface generators typically want to create interface classes that clean up for themselves and call (or it gets called as a matter of course) the base class' destructor.
In acad you don't want this to happen as the db holds these pointers and keeps them 'alive' for the editing session, in arx we just grab the pointer and open for read/wrte etc but never 'destroy' them unless deleting from the db all together.

I'm sure an experienced SWIG hacker could resolve this problem with some macro work but I didn't want to go that far into swig university just for one application.

[pkohut]

sound cool!

just to elaborate on the arx and pointer issue, the interface generators typically want to create interface classes that clean up for themselves and call (or it gets called as a matter of course) the base class' destructor.
In acad you don't want this to happen as the db holds these pointers and keeps them 'alive' for the editing session, in arx we just grab the pointer and open for read/wrte etc but never 'destroy' them unless deleting from the db all together.

I'm sure an experienced SWIG hacker could resolve this problem with some macro work but I didn't want to go that far into swig university just for one application.

Ha, read "SWIG" to mean "SWING" and I'm like HUH 

Not totally sure, but Lua communicates with the outside world via pushed and popped stacks, so Lua doesn't try and take ownership of pointers and objects. For the simple object types Lua supports, this isn't really an issue. Heavy objects that ARX/ADS support could be a problem, and that's one of the areas that needs further exploration.

[MickD]

Ha, read "SWIG" to mean "SWING" and I'm like HUH 

    

[JohnK]

* Se7en is watching/lurking this thread intently.

So my lisp passes control to "luna" and it opens and closes ACAD? What happens when the script is done?

[MickD]

Basically you 'embed' the scripting engine into a running instance of acad then from lisp/vba etc. you call the engine passing in a string argument of the script name which the engine locates and runs in its interpreter.
In the Lua script it interfaces back to acad using the api to do the work of the script, when done the engine passes focus back to the main application.

<added>
basically it's like calling a vba routine from lisp

[pkohut]

So far it excepts strings and reals from autolisp. The Lua test script has 2 functions. One to print a string to the std console (Autocad doesn't have one so you can't see the string), and one to return a squared number.

(setq val (luaCallFunction "square" 12.0)) 
(luaCallFunction "print" "Hello world")

The bridge transforms the resbuf to Lua function parameters by pushing each item in the resbuf to Lua's stack.  So far in the test phase, it's proving to be embarrassingly simple with these 2 simple data types. Other data types will probably present a challenge.

[JohnK]

huh? cool.

So what you guys are saying is that stuff like the "open dwg" example ( http://www.qsinformatica.it/white_papers/OpenDwg.html ) would work fine but my lisp would get a quick return val then loose control.

[It's Alive!]

Neat idea 

but IMO, it should not be tied to Autolisp via resbuf, there are too many instances where translations can get messed up,   I.e. '(1 2 3)  may get resolved as a point instead of three integers in a list. That's not to say that they can't communicate via some sort of invoke method, but It should be a totally separate interface with its own command prompt, IDE, debugger etc.

[pkohut]

Neat idea 

but IMO, it should not be tied to Autolisp via resbuf, there are too many instances where translations can get messed up,   I.e. '(1 2 3)  may get resolved as a point instead of three integers in a list. That's not to say that they can't communicate via some sort of invoke method, but It should be a totally separate interface with its own command prompt, IDE, debugger etc.

It's not tied to Autolisp. There is a bridge class that transforms C data to and from Lua data, so it is also callable from C++. To interface the ADS side I inherited the bridge class and adding support for resbuf's there.

Lua has a interactive command mode built in, just needs to be exposed to Autocad's command line. It also has it's own debug facility and stack inspection, so a debugger isn't needed, however there is a standalone debugger which apparently works with any Lua enabled app(?) and can be hooked up with the VS debugger.

IDE? Might already be something available, otherwise NP++ or some other decent text editor is more than enough.

[pkohut]

huh? cool.

So what you guys are saying is that stuff like the "open dwg" example ( http://www.qsinformatica.it/white_papers/OpenDwg.html ) would work fine but my lisp would get a quick return val then loose control.

If the "open dwg example" is called in the context of autolisp then control is returned when the function finishes.

[JohnK]

whoa that ...wait a minute?! If SDI =1 then the drawing that "contained" (I cant think of a better word) the lisp that launched the Luna script would die right?

This sounds cool.

[pkohut]

whoa that ...wait a minute?! If SDI =1 then the drawing that "contained" (I cant think of a better word) the lisp that launched the Luna script would die right?

This sounds cool.

Probably.

DocShells.h

Code: [Select]

#pragma once
#include "LuaScript.h"
namespace LuaScriptExtension
{
class LuaScript;
class CDocShells
{
public:
CDocShells(void);
virtual ~CDocShells(void);
LuaScript * GetLuaScript(void);

protected:
LuaScript m_luaScript;
};
extern AcApDataManager<CDocShells> docLuaShells; // makes CDocShells MDI aware in Autocad.
}

[It's Alive!]

how about instead of adding yet another scripting language, extend AutoLisp a bit?  Wouldn't it be the bomb to have goodies like defclass and defstruct, maybe borrow stuff  from CLISP

[pkohut]

how about instead of adding yet another scripting language, extend AutoLisp a bit?  Wouldn't it be the bomb to have goodies like defclass and defstruct, maybe borrow stuff  from CLISP

Last August I did some preliminary investigation into using Lisp Plus Plus or XLisp-Plus as a replacement for VLisp, http://www.theswamp.org/index.php?topic=30070.msg356592#msg356592, with the intent of making a better IDE/debugger. While probably doable, lost interest because of some technical hurdles and lack of personal interest in Lisp.

Having a scripting language not tied to .Net CLR, com, platform, or The Desk, would have many benefits. Lua is small, extensible, fast, and LuaJit is as fast as Javascript. Beyond that, I think the goals are easily obtainable, much more so than extending or replacing VLisp. There is also a clear distinction between 'pick your non-lisp scripting language' and Auto/Visual Lisp. A cleaner, simpler, scripting language would also appeal to users that find the Lisp syntax daunting.

Most important to me, is personal interest, curiosity, and fun, cause nobody is going to open up their checkbook and be an open source sponsor for the project.

Anyways, I'd be more than happy to chat about extending or replacing Autolisp in a new thread, share what I learned last year, along with the code gathered and written.

[It's Alive!]

I know, and It's your right to have a little fun. I guess after seeing several of these projects come and go half complete (guilty here too), I thought I might make the suggestion. Anyway Lua does look neato 

[pkohut]

Nothing there yet, but created a project "LuaAzul" on Google Code yesterday. Late next week will be the soonest any code can be posted, which will be some glue and initial foundation code.  See were it goes from there.

http://code.google.com/p/luaazul/

[pkohut]

Had a nice, restful, long weekend, yeah, and started work on the code again Monday.

Had to get over a hurdle with the Unicode extension (read as 'It was kicking my ***'), but I think it's figured out. Still looking towards the end of the week before first code is posted.