Newbie How-to Request: Finding mismatched parens using BLADE

chillme1

I am interested in finding the steps to locate an extra right parenthesis in the attached custom "on_start.lsp" code.
In addition to any typed responses or review, a web link to BLADE learning or BricsCAD-based LISP would be appreciated if found.

CODE FOLLOWS

; ----- Error around expression -----
; (PROGN)
;
; error : extra right parenthesis on input

CODE END

I appreciate your time and interest!

• Clint

chillme1

My pardons! I posted to the wrong forum list.

martin@enco.us

The file you posted does no show any unbalanced parentheses in Blade on my computer. The error message points to the text (progn) but that text does not appear in the file. Are you sure that the error message is for the file you posted?

Blade will highlight pairs of parentheses if you move the cursor to a paren. Checking whether the logic is as you intended is not something Blade can do by itself. It is a manual process.

Torsten Moses

Hello,

as far as I tested, there is no extra parenthesis :-) And I don't get that error message.
But, the code uses (load "AcetUtil.des") as time of loading, so the error could originate from the AcetUtil.des ...
So maybe re-install the ExpressTools (be careful to use the correct version of ET, one version for each BricsCAD version).

For BLADE :
multiple ways :-)
a) use code folding ("View" menu") and collapse all - then you will see extra ) out of match
b) or use "Check Syntax & Variables", it will immediately point you to such an error

But as mentioned, likely the (load "AcetUtil.des") is the problem here ... you can comment that line (for testing), then you will get it loaded without error (just as I did).

Hint :
as you use "on_start.lsp", make sure that ACADLSPASDOC setting is always 1 ... better to use on_doc_load.lsp instead of on_start.lsp as that is always loaded "per-drawing".

hope this explains & helps a bit ?
many greetings !

chillme1

Hi Torsten,

Many thanks, it does!
I will be sure to check the version of the AcetUtil.des.

Also, I am watching a series on BLADE with Heid Hewlett and others on Youtube.
With BLADE, I am now very enthusiastic in picking up where I left off learning LISP programming.

• C.

James Maeding

The easiest way was not mentioned - double click before a paren, it will select the code to closing paren.
Simply hovering by one is not bold enough for me, especially if the code goes to next page down.

That .des thing is a problem IMO. The BLADE reads code in .des files, and then does things as if its not compiled.
I actually need the .des to only run functions in a .des if called, not break in them and other things.

Torsten Moses

Dear James,
some issues in BLADE (showing .des files in editor - which is nonsens) have been fixed;
but debugging .des files has been significantly improved (when using latest DEScoder.exe v2.9) - if the original source file is available (on your local machine) then debugging into such DES functions will automatically load the original LSP source, to enable debugging.

Using "StepOver" or "SingleStep" does not automatically goes into such DES sources.

Usually, on customers' machines, those LSP source file(s) for the .des are not present, then nothing special happens there ...
So depending on your debug operation, it should proceed debugging as intended.

hope this clarifies a bit ?
many greetings !

James Maeding

Hi Torsten,
Thanks as always for the reply. So nice to have access to the master.
There are a couple issues here that I likely tangled.
My workflows started using the acad vlide, and I do separate workspaces for the .vlx files.
My typical processs in acad would be:
1) start acad to blank dwg - this loads my "main custom program" (called MCP here) .vlx using the acaddoc.lsp.
2) start VLIDE, which has a "project" set up for my MCP.
3) Load all the MCP files using the single button on the project window. Takes about 4 seconds.
4) set a break point, load the file, and run some function that will break at the point. debug as needed...

In that workflow, even though my .vlx is loaded with the same function names, it never interacts. May be because they are separate namespace, or may be the acad vlide only debugs into loaded lisp files, not .vlx.
It does not even know where a .vlx came from.

I'm finding the BLADE does interact quite a bit with my .des functions. I'm on 20.2.03, so likely a bit behind.
The part about loading all the project files is still the biggest hurdle in BLADE, it takes over a minute. I run that about every 5th debug to be sure all functions come fresh from my code.
There is so much in the BLADE though, and I so miss the navigation ease it offers compared to the VLIDE...

Torsten Moses

Dear James,
many thanks for explanations and feedback ...
In fact (and if I do not totally misunderstand), the redesigned debugging in BLADE is even much easier than you described with VLIDE :-)

Only condition - create the .des file (from your VLX project) with latest DEScoder 2.9 (in latest BC, but also in LDSP package) ...
that new DEScoder fixes some issues (code compression bugs), but most important, it adds debugging support ...

In your scenarion :

• load your .des file
• enable "AutoBreak", and/or just open the main LSP source file (where you want to stop + debug) in editor, maybe set a breakpoint as well ...

Now, the main advantage is, that BLADE knows the original sources for the code, as included in the .des file ...
it is not even necessary to have such VLX project attached in BLADE (of course, possible) ...
whenever you use "StepInto", or when a breakpoint is set (in original LSP source), BLADE will automatically post-load the related LSP source file - and only the (defun ...) blocks, neither the load-time code is executed, not global variables are overwritten, as such would mess-up the entire Lisp then;
just the plain (defun) definitions are loaded.

All other (defun) from a .des file remain as DES, inside Lisp engine ... just when debugging such a (defun) is required/requested, then BLADE will try to detect the related source, and load all the (defun) functions from that Lisp file.

Btw., you can watch that in the "Loaded Lisp Files" and "Debug Functions" tabs on the bottom-right panels ...
So in all, it is even easier than in VLIDE, as you will no longer need to manually load all the required sources - BLADE will automatically recognise from the .des file
(for non-DES file, BLADE will also automatically load LSP sources from attached project, aka "known files" ... if multiple LSP files have same (defun), then a small window will appear to chosse which one)

So in fact, you should really try with latest V20.2.09 :-) imho, a real step ahead (meanwhile, I wonder why I didn't apply this new logic right from beginning :-)

many greetings !

P.S. maybe you already know : right-click contex menu on the "project root" item also allows to "Load All Files" ...

James Maeding

oh wow, more goodies.
I will spend some time on this to see if I get it.
I keep forgetting the BLADE only allows one project attached at a time. That is how it gets the .des code files.
will try, thanks!

ALANH

Just a suggestion your 18 (If (/= getvars could be replaced with a simple foreach using list of variables and correct value. A couple of lines of code. Also why check if your forcing to say 0 anyway just set to 0.

I use notepad++ has a lisp option so shows bracket pairing as you create. Or if old like me have Chkbrk.lsp that does just that checks the brackets way before Blade and Vlide.