Topic: AutoLisp IDE Question

[pkohut]

The IDE that comes with AutoCAD gets the job done, but not without showing its age and
some glaring problems.  For most of us VLIDE is used by default, even when better editors
exist, mainly because of the debugging capabilities VLIDE have.

So, assume you've built the best IDE ever, bar none, VS is a distant 2nd place runner up
compared to your IDE.  There is just one problem, if it can't interactively debug lisp applications
NO ONE will ever use it.  How would you go about implementing the debugging features?

I'm guessing there are just 2 methods that would work -

• Interface with the VL.arx API?  It's not an open API so this would require some reverse engineering.
• Implement a full VLisp stack via your own interpreter?

I'm just brainstorming a bit and leaning towards the second item.  Would really like to get the thoughts
of others on how they would approach the problem.  FWIW, I have no IDE or written *any* code.  However,
if someone has already started such a project and it is open sourced, I'd like to work on it.

The graphic is some thoughts I had today.

Thanks,
Paul

[It's Alive!]

I was thinking about this when I was playing around with this
http://www.theswamp.org/index.php?topic=29985.msg355644#msg355644

A lisp editor that would support a lisp 'solutions' with 'projects', that would create the necessary .PRV files for the vlisp compiler.  But the coffee buzz faded and I realized, I already have one
http://www.caelink.com/lisplink.htm It's not open source, but it's really cheap. It still would be fun though, I would like to help if the project gets off the ground

A standalone interpreter would be difficult to create as it would need to support COM functionality as well. I might start with using the VLISP engine, BTY which can be used to evaluate expressions via COM.

[Spike Wilbury]

Maybe something like this, could be a great addition to the OpenDCL project and a way great deal for lispers.

[pkohut]

I was thinking about this when I was playing around with this
http://www.theswamp.org/index.php?topic=29985.msg355644#msg355644

Ya, that looks pretty good and I'm all in favor of a VS stylized IDE.  To me the
most important thing about an IDE is that it doesn't get in your way.  With
dockable windows that can be accomplished, by getting ride of shifting window
positions, excess dialog boxes, etc.

A lisp editor that would support a lisp 'solutions' with 'projects', that would create the necessary .PRV files for the vlisp compiler.  But the coffee buzz faded and I realized, I already have one
http://www.caelink.com/lisplink.htm It's not open source, but it's really cheap. It still would be fun though, I would like to help if the project gets off the ground

I saw that the other day (website only) and it just didn't pull my finger, but know looking at the feature list it is
something I need to look into further.

A standalone interpreter would be difficult to create as it would need to support COM functionality as well. I might start with using the VLISP engine, BTY which can be used to evaluate expressions via COM.

Can you elaborate on the COM support a bit?  I'm not fully following. 

I thought about using VL but could not come up with a clean interface without a documented API.  Going the roll
your own lisp interpreter is about the best I could come up with.  Up front it's a lot of work, but gained would be
flexibility and interoperability.

[pkohut]

Maybe something like this, could be a great addition to the OpenDCL project and a way great deal for lispers.

Having never seen OpenDCL and hearing only great things about it, I'd be inclined to let it continue to do
what it does best.  If it has functionality that allows other programmers to access then that might be
something that could be leveraged.  Otherwise I a big fan of plugin software.

[Kerry]

Maybe something like this, could be a great addition to the OpenDCL project and a way great deal for lispers.

Having never seen OpenDCL and hearing only great things about it, I'd be inclined to let it continue to do
what it does best.  ............

I agree.

[Kerry]

Paul,
Is your goal stand alone debugging ?

.. Due to the interactive nature of the VLIDE with AutoCAD objects (graphics and tables), that would be an enormous task.

[It's Alive!]

Can you elaborate on the COM support a bit?  I'm not fully following. 

Just saying that it would be a lot of work writing an interpreter that can evaluate expressions like
 (vlax-create-object "ADODB.Connection") , (vla-get-ModelSpace ActiveDocument) . etc

[pkohut]

Paul,
Is your goal stand alone debugging ?

.. Due to the interactive nature of the VLIDE with AutoCAD objects (graphics and tables), that would be an enormous task.

Debugging would definitely be done via an ARX module *some how*.  If a new lisp interpreter was called for, also written
in ARX, then the debugging capabilities would just be an extension of the interpreter.  That's the big question, how to
go about the plumbing?

[Spike Wilbury]

Is this project someone else just started? and to provide a replacement of this old Vital Lisp IDE... sound like a great task.

All the luck to you!

[It's Alive!]

call acedEvaluateLisp and put the result on the stack 

[pkohut]

Is this project someone else just started? and to provide a replacement of this old Vital Lisp IDE... sound like a great task.

All the luck to you!

Nothing started, was just thinking to myself kind of low level about what it would take to implement debugging hooks.
The swamp collective can come up with many more ideas and maybe someone, or a group can pick it up as a project
to persue.  If it was open source then all the better 

[pkohut]

call acedEvaluateLisp and put the result on the stack 

That's a thought  Setting and triggering break points could be an issue.

[Spike Wilbury]

call acedEvaluateLisp and put the result on the stack 

I bet that's what the guys from basis did ... no reinventing the wheel....

[pkohut]

call acedEvaluateLisp and put the result on the stack 

Hmm, you might be on to something there, a little further digging...
http://www.intellicad.net/forum/topics/intellicad-lisp-debugger?page=1&commentId=2285825%3AComment%3A3361&x=1#2285825Comment3361
and that's your 'noggin / avatar

Now go up 2 messages to the post made by iCadSalescom Jan 27, 2009 at 11:28am.
He gives 2 links to lisp debuggers, these things are OLD, but they shed some light on
a possible approach.

Wheels are turning.

[pkohut]

call acedEvaluateLisp and put the result on the stack 

Hmm, you might be on to something there, a little further digging...
http://www.intellicad.net/forum/topics/intellicad-lisp-debugger?page=1&commentId=2285825%3AComment%3A3361&x=1#2285825Comment3361
and that's your 'noggin / avatar

Now go up 2 messages to the post made by iCadSalescom Jan 27, 2009 at 11:28am.
He gives 2 links to lisp debuggers, these things are OLD, but they shed some light on
a possible approach.

Wheels are turning.

Ok, given this some more thought and I'm not feeling it for acedEvaluateLisp.  It was worth the mental
exercise, but I keep coming up with scenarios that would break the process and have no easy fix.
As for the 2 files mentioned from the Intellicad board, it's kind of a neat trick from what I can understand,
however, the user debugging a lisp app will not have fine control with stepping into and out of code.

For VLIdE, here is my best "birds eye view" guess on implementation
1) I think it implements its own lisp interpreter, some functionality may be passed along to VL.arx and VLLib.dll.
  A) When a file is pushed to AutoCAD it is probably.
    a) building a linked list of s-expressions, also provides paren matching and checking.
    b) builds a stack of break points.
    c) calcs a hash on the file in the editor.
  B) From the AutoCAD command line, the command entered is intercepted and control given to the VLisp interpreter
      where it then -
    a) calcs a new hash and comparing against the old.  If they match then the file is clean (unmodified).
    b) tracks the current s-expression pointer to be evaluated.
        If pointer matches a break point in the stack then the run loop is paused.
2) It is built with and relies heavily on LPP, http://www.interhack.net/projects/lpp/

Again this is skimpy on details, more just gathering / posting thoughts and ideas.

[Spike Wilbury]

Another alternative could be if you could convince Tony to use his: LispPad: A nice Windows Lisp Editor by Tony Tanzillo, accompanied in the forthcoming recommendable book "Maximizing AutoLISP" - and ask him for the source code too....

 

[Spike Wilbury]

Also...

There was a lisp beautificator and another for parenthesis match (if I recall way before the arrival of Vital Lisp) - these two were part of a CD addition on release 12 - don't know where I left that CD, maybe still it is in one of my boxes on my wherehouse..... or others here know about them.

[Spike Wilbury]

I found them here - among many other old stuff too:

http://www.cadinfo.net/scripts/LISPlib-software.cfm?StartRow=21&areano=45

Also...

There was a lisp beautificator and another for parenthesis match (if I recall way before the arrival of Vital Lisp) - these two were part of a CD addition on release 12 - don't know where I left that CD, maybe still it is in one of my boxes on my wherehouse..... or others here know about them.

[pkohut]

Since my last post Friday I've made lots of discoveries, written a lots of code that crashes, and
finally talking with VL via late binding.  Here a list of things accomplished this weekend, pretty
much in order.

• Wrote some c++ com code with vl16.tlb imported.  Got no where.
• Downloaded and played with the original XLisp in the public domain.
• Checked out Openlisp, open as in accessable not open source
• Ported LPP version 1.21.2 to Windows. I think VLisp is actually using version 1.19
  which is public domain.  Lots had to be done to get this to work, compile and pass
  the regression test.  There is still 1 function in the "big number" library that is
  computing wrong with certain combinations of negative numbers, otherwise everything
  works
• Checked out VLS (vanilla lisp shell) for emacs.  Pretty much just looked at the code
  and read most of the documentation.
• Played with XLisp-Plus.  This is a pretty good darn lisp package (UI blows) and is
  extreamly fast.  I did the same test both in it and vlisp.  The vlisp function took
  about 18 seconds to run, and the XLisp-Plus version took about 5.
• Started working with com code again, only this time doing late binding.  Finally getting
  somewhere with this stuff.  Also found some VBA code from way back by Frank O,  so
  switched to VBA and doing more experiments.
• Have and idea to try for VL.arx and its exported functions.  I'm thinking that some of
  these have wrappers for the late binding com stuff.  If it's true, then might be able
  to just create a test app using the LPP code and ask VL to hand over some of its
  data, without having to go through com.  If nothing more it might provide information
  about the late binding methods and parameter data.

The goals for the next test is to see a lisp app can be pushed into VL and run.  I know
it can be evaluated, but I'd like to have the app go directly to the lisp app list.  Then
figure out how to attach break points and get some sort of notification back when
triggered.

If anyone has information about any (all) of the late binding functions available in
vl.application.16, that would be very helpful.

TIA,
Paul

[Spike Wilbury]

>>•Wrote some c++ com code with vl16.tlb imported.  Got no where.

Just played a little earlier by trying to access into that table, with little luck... not far as it is shown on the attached image... might give it a try later or any other day.