BLADE function parsing?

MP_

Hi BricsCAD folks!

First post here! I'm excited to be a contributing member here despite many pins in the air at present. I'm brand new to BricsCAD but I've been pounding LISP since the late 80s. O.o

Anyway ... I was working on a little program earlier today when I thought "hey I should install the latest BricsCAD and see if the proggy will work in said CAD program".

Installed BC. Wow, installed fast!

Loaded up the program and presto, works!

Then I thought I'd load the code into the new BLADE IDE.

Looks great and a very decent development environment but it parses my functions into a hierarchy that does not exist.

The code is laid out like this --

(   (lambda ( / safe-ascii random-ascii make-mask offset-mask a b )

        (defun safe-ascii ( )
            ...
        )

        (defun random-ascii ( )
            ...
        )

        (defun make-mask ( code-ceiling )
            ...
        )

        (defun offset-mask ( mask )
            ...
        )

        (eval
            (list 'defun 'obfus '(text)
                (list
                   'vl-string-translate
                    (setq a (make-mask 255))
                    (setq b (offset-mask a))
                   'text
                )
            )
        )
    )
)

But BLADE reports this:

Anyone have insight why it's doing that instead of something like this --

(I don't expect it to be able to pick up the obfus def).

Thanks and cheers!

Michael.

Torsten Moses

Dear Michael,

2 answers for 2 questions :-)
In fact, all those 4 defun blocks are "child" or "local" or "nested" defun objects to the (lambda) statement (and the defuns names are even declared to be local symbols - but that does not really matter for the tree structure) - therefore, those 4 defun names are reported as "nested".

BUT
there seems to be a problem with the "lambda" ... a) such lambda does not have a name, naturally, and b) it misinterpretes the "safe-ascii" then as a defun name, and the tree runs out-of-sync :-(

You might attach that Lisp code file (or a minimum extract, which reproduces this defect) here, or send as SupportRequest, so we can check & fix the parser (anyway, I will try locally as well).

many greetings !

MP_

Thanks for responding Torsten. Your explanation makes sense. I’m exploiting lambda because it sports locals and is executed at runtime - using it as a function factory of sorts - create private functions which generate static data to encapsulate in a public function. Once the public function is defined it's desirable the helper / maker functions are destroyed. Hope that made sense.

Since making this post I changed the program — only 2 local functions. It’s too big to post due to the documentation (the code is rather trivial, written as a demo for a potential article). Can be viewed here.

Thanks for taking time to post & the greets. Loving the new IDE, So thoughfully done — snappy performance — any plans for a stand alone version?

Cheers & thanks.

Michael.

Torsten Moses

Dear Michael,

thanks for reply & kind words
Should be no problem to reproduce the lambda/defun mis-structure locally ... don't worry (and it should work properly, maybe exposing "lambda" as parent entry for the defun blocks)

A standalone version would not really make sense ... too closely related to the core Lisp engine (would have no debugger functionality), and as plain editor, there is i.e. UltraEdit, for which I have added a "Functions" plugin, included in "Lisp Developer Support Package", free download in our ApplicationCatalog, so that UltraEdit also offers some "Lisp context handling".

many greetings !

MP_

I personally don't need debugging in a lisp editor, acknowledging it is very useful. Trivia I'm sure you & others know : VLIDE was a stand alone product back in the '90s before ‘desk bought it from BASIS Software. I was quite happy with it and wish they never sold it. As for UltraEdit I've been a paying customer since '04. :thumbsup: Cheers!

MP_

Ok. Confession time. I never used the debugger in VLIDE. In all my decades of LISP programming I developed my own programming methodology that (seemingly) had no need of step wise debugging etc. But despite my years the old dog wants to learn new tricks. So I tried some BLADE debugging last night. Slick & clever! Couldn't help but think it must have been great fun designing and coding up BLADE. Kudos Torsten & crew!

tl;dr: Well established workflow now under review!

martin@enco.us

My biggest wishes for BLADE are:

1. Add a parser that will list local variables for each function. Lisp-link had this.

2. Allow custom settings for REFORMAT. The defaults aren't bad, but they also aren't quite how I prefer my code to look.

3. Have toggles so the debug window and sidebar so I don't have to manually turn them off every time.

Torsten Moses

Dear MP,

have a look at "Lisp Developer Support Package" (if not yet done), for the UltraEdit extensions there
a) complete wordfiles for AutoLISP + DCL language (the default one are the minimum only)
b) "Function Lisp" addition to show the DEFUN blocks (similar to BLADE)

"Couldn't help but think it must have been great fun designing and coding up BLADE"
I also never used and never needed VLIDE for my Lisp programming (since 1990)
And honestly, the ideas for BLADE mostly grew up during developing it, getting one idea after another, with great support by Martin Drese (CAD Wiesel) as Beta tester ... it was never planned that way.

Dear Martin,

1. "local variables" : yes, it is on my list ... just need a smart idea where to visualise (temporary or permanent)
2. REFORMAT settings - yes, also planned, but not trivial to implement ... but will come some day, to some extents
3. side + debug panels : if you close them, and then save use "Save Preferences" ... preferences are never saved automatically, only "by intention" (just to prevent mis-configurations)

Thanks for all the hints ... definitely those all will be respected !
many greetings !

martin@enco.us

Torsten,

For local variables my preference would be to have a temporary list so I can cut and paste. The list could be added to the debug panel. Having BLADE create a complete header for a defun rather than just a list of local variables would be my choice. If BLADE could do a complete set of defun headers for a routine that has nested defuns that would be ideal.

MP_

@Torsten Moses said:
Dear MP,

have a look at "Lisp Developer Support Package" (if not yet done), for the UltraEdit extensions there

Have done, thanks!

@Torsten Moses said:
I also never used and never needed VLIDE for my Lisp programming (since 1990)

Lemme guess, edlin was your first IDE? lol

@Torsten Moses said:
And honestly, the ideas for BLADE mostly grew up during developing it, getting one idea after another, with great support by Martin Drese (CAD Wiesel) as Beta tester ... it was never planned that way.

Kudos & thanks to you both!

Cheers.

MP

MP_

@H Martin Shoemaker said:
My biggest wishes for BLADE are:

1. Add a parser that will list local variables for each function. Lisp-link had this.

2. Allow custom settings for REFORMAT. The defaults aren't bad, but they also aren't quite how I prefer my code to look.

3. Have toggles so the debug window and sidebar so I don't have to manually turn them off every time.

Good ideas, especially agree with 2 -- I'm very fussy!!

Torsten Moses

Dear Martin,

I'm not sure, whether I understood correctly :

"The list could be added to the debug panel. Having BLADE create a complete header for a defun rather than just a list of local variables would be my choice."

Do you mean, BLADE should analyse the body of a DEFUN or LAMBDA block, and "detect" all variables, to have them declared as local variables ?
If so, that can quickly go wrong - such a not-yet-declared variable could be a global one ...
I will see what LispLink does here - maybe I get a better idea

many greetings !

MP_

Agree — auto local declaration for me would be somewhere between “highly undesirable” and “cant use this IDE”.

If it were an option that’s off by default I could probably live with it.

Listing of locals on the other hand would be ubertastic.

martin@enco.us

I certainly don't want automatic local declaration, but a tool that provides a listing of probable local variables would help catch misspelled variable names and would be a huge step up over going through code manually trying to find all the local variable names. From a practical standpoint I think there would always have to be human interaction due to things like "a not-yet-declared variable could be a global one".

My thought was to take this

(defun enco_dtext_boundary (#object / 2points a b c d angle1 origin point1 point2
                                    point3 point4)

  (if (vle-enamep #object)
    (setq object1 #object)
    (setq object1 (vlax-object->ename #object))
  )
  (setq origin  (vle-entget 10 object1)
        angle1  (vle-entget 50 object1)
        height  (vle-entget 40 object1)
        2points (textbox (entget object1))
        point1  (polar origin angle1 (car (car 2points)))
        point2  (polar origin angle1 (car (cadr 2points)))
        point3  (polar point2 (+ angle1(/ pi 2.0)) height)
        point4  (polar point1 (+ angle1(/ pi 2.0)) height)
  )
  (list point1 point2 point3 point4)
)  

and return this

(defun enco_dtext_boundary (#object / 2points angle1 height object1 origin point1 point2 point3 point4)

Note that unused locals in the header are removed and locals that are in the code but not in the header are added. This approach lets me visually compare variables passed in with local variables in one place. For a function with nested functions a separate header would be provided for each defun. I can edit the returned string to take out global variables, or cut and paste if I like what I see.

As I recall LispLink had a pop-up window that showed a list of local variables for the selected function. LispLink seems to have been discontinued so I can't verify.

I tried to keep this brief. I tend to either post too much or not enough. Please let me know if this is not clear.

Postscript: Markdown is frustrating to use, in part because it is very poorly explained in the link the editor provides. Using [code] and [/code] and similar tags, plus maintaining paragraphs as seen in the editor without having to add spaces (that you can't see are there) would be much more user friendly.

Torsten Moses

Dear Martin,

thank you - now I understand better

And your comment exposes 2 problems ...

1. "... that unused locals in the header are removed ...."
   for example, what will happen, if local variables are declared upfront (when editing), and the actual defun block is not functionally completed ?
   The intended check will remove those locals ... but my intention was to continue editing, and to add usage of some locals later on ...
   But I see, if such functionality is used at the end of editing, it can help ...
   At least, technically possible to have such test, and show a small window, listing the (potentially) unused local variables ...

2. "... and locals that are in the code but not in the header are added. ..."
   that is what I meant before - how can such analysis know, whether a particular variable shall be a local one ? It could be a global one as well ...
   That means, the intended functionality (using a kind of popup window) could list both :
   a) potentially unused locals
   b) potentially missing locals declaration

Then, it might offer to select (multiple) list items, and do the action - removing resp. adding as local declaration ..
likely, such functionality will be added, a bit later, after the other, more urgent features (HotKey assignment/editor) are implemented
At least, I also see the value & advantage of such a "per-defun varaibles lookup & check"

many greetings !

James Maeding

for @H Martin Shoemaker, the display of line numbers and things will stay off if you use "save settings" in the pulldown. I ran into that too.

Ian Johnson

Where do I find the BLADE lisp editor?

Austrobass

Start Bricscad 18.2x, type BLADE and the magic begins.