TheSwamp
Code Red => AutoLISP (Vanilla / Visual) => Topic started by: squirreldip on October 14, 2016, 01:58:16 PM
-
I have a .cmd script which creates a .lsp file to write .dcl files by reading a folder containing source .dcl files. I'm getting an error when using VLIDE to create a vlx from the .lsp :
; error: too many arguments: (PROGN (SETQ OUTFILE ( ... )) (PRINC "DUALCAR : dialog {\n" OUTFILE) (PRINC " label = \"RFL Dual Carriageway 3DPoly Creator\";\n" OUTFILE) ... )
The .lsp loads fine and executes correctly.
If anyone has any ideas it would be greatly appreciated.
-
Is there a limit to how many lines can be contained within a (progn) block?
Edit:
Answer is yes (here) (https://www.theswamp.org/index.php?topic=48883.0)
-
I have a .cmd script which creates a .lsp file to write .dcl files by reading a folder containing source .dcl files. I'm getting an error when using VLIDE to create a vlx from the .lsp :
; error: too many arguments: (PROGN (SETQ OUTFILE ( ... )) (PRINC "DUALCAR : dialog {\n" OUTFILE) (PRINC " label = \"RFL Dual Carriageway 3DPoly Creator\";\n" OUTFILE) ... )
The .lsp loads fine and executes correctly.
If anyone has any ideas it would be greatly appreciated.
I did not look your attached code. But can you replace the portion (princ "label = \"RFL…) with this:
(princ (strcat "label = \"RFL Dual Carriageway 3DPoly Creator\""
"\n"
OUTFILE
); end of strcat
)
(princ)
Note: take care of using ";" in a single line because ";" breaks the rest in the line.
Then you may be able to fix (princ "DUALCAR : dialog {\n" OUTFILE).
Please also have a look "strcat" function in help.
HTH
-
Thanks MeasureUp - the suggestion should work.
I think the big issue for me was just not realizing that there is a limit. I solved my problem by temporarily storing a list then iterating through that list. Yours is probably better as no variable needs to be stored.
-
See: https://www.theswamp.org/index.php?topic=48883.0
-
See: https://www.theswamp.org/index.php?topic=48883.0
I've never attempted to compile to VLX, but after reading this I thought would (repeat 1) can be an alternative of a loooong (progn).
-
I was about to ask does anyone know limit of (setq var1 value1 var2 value2 ... )? I know this can be simplified by separating setq-es, but just for an info...
-
Could the length of a progn issue be eliminated by creating a sub-function and simply calling it?
-
IMO, if you start to run up against the argument limits inherent in AutoLISP, you really need to take a step back and restructure your program; in the hundreds of thousands of lines of code I've written, I've never been troubled by the maximum number of arguments afforded by functions such as progn, cond etc.
-
IMO, if you start to run up against the argument limits inherent in AutoLISP, you really need to take a step back and restructure your program; in the hundreds of thousands of lines of code I've written, I've never been troubled by the maximum number of arguments afforded by functions such as progn, cond etc.
Thats what"the List Manipulator" said. :wink:
-
You can add DCL to your VLX app. Making DCL on the fly is very bad idea. :uglystupid2:
-
You can add DCL to your VLX app. Making DCL on the fly is very bad idea. :uglystupid2:
DCL as part of a VLX application is still unencrypted and merely appended as plain text to the VLX file.
-
Making DCL on the fly is very bad idea. :uglystupid2:
Support this assertion please.
-
I was about to ask does anyone know limit of (setq var1 value1 var2 value2 ... )? I know this can be simplified by separating setq-es, but just for an info...
I've successfully loaded lisp with 10MB size, containing 1000000 variables setq-ed in one line... So if I may conclude (setq) has no such issues with limitations... Note that in lisp that I used to create lisp (10MB) (load) function isn't quite thankful for checking... So as soon as first loop was over I terminated CAD and started it again when I used copy+paste method with lisp (10MB) into CAD interface for loading that setq... It was success and I still had to wait for loading 10MB lisp for a while... Here is my (c:testsetq) for creation of ttt.lsp (10MB), so that you can experiment on your own if you want, but I warn you if you have more important thing to do, please ignore this test...
(defun c:testsetq ( / f )
(setq k 1000000)
(while t
(setq f (open "c:/SHARED FOLDER/ttt.lsp" "w"))
(write-line "(eval (setq" f)
(repeat (setq k (+ k 1000000))
(write-line "a 1" f)
)
(write-line "))" f)
(close f)
(load "c:/SHARED FOLDER/ttt.lsp")
)
)
P.S. "k" variable is global in order to be checked upon load failure (but this won't happen at least according to my testings)...
-
Making DCL on the fly is very bad idea. :uglystupid2:
Support this assertion please.
Ok, if you write dynamic DCL you have to
1) Write more code and read much longer bumf;
2) Check more errors and every slash around strings;
3) Check if DCL is created/exist/loaded. Some paranoiac antivirus software and latest versions of windows can prevent file I/O operations.
4) Rewrite your code every time then Autodesk fails with codepages...
-
Ok, if you write dynamic DCL you have to
1) Write more code and read much longer bumf;
2) Check more errors and every slash around strings;
3) Check if DCL is created/exist/loaded. Some paranoiac antivirus software and latest versions of windows can prevent file I/O operations.
4) Rewrite your code every time then Autodesk fails with codepages...
I've been using the technique for 2 decades and none of the reasons you cite have ever been an issue. My experience is contrary to what you suggest -- coding overhead nominal and has more reliable and secure than shipping a companion dcl file or packaging one via the vlisp compiler (which doesn't encrypt packaged dcl). tl;dr: I've never had one of my users or customers report an issue. Not once.
-
You can add DCL to your VLX app. Making DCL on the fly is very bad idea. :uglystupid2:
there could be issues with dcls
read here https://www.theswamp.org/index.php?topic=47908.msg541261#msg541261
-
You can add DCL to your VLX app. Making DCL on the fly is very bad idea. :uglystupid2:
there could be issues with dcls
read here https://www.theswamp.org/index.php?topic=47908.msg541261#msg541261
Wow, multylanguage apps is realy butthurt... When you going to support multiple languages you have to make multiple
* menu
* prompts (in lisp)
* help system
Better way is to do all in English.
Then you have problem with codepages you may just translate codepage one to another. When revert back if need. When dialogs are in separate files it is much easier to do and not changes lisp staff.
When you want to rearrange DCL within LISP you need to rewrite LISP. It is hard to do, because DCL stored in separate strings. This is good chance to get error as result.
Finally, DCL in LISP seems very very ugly :sick:
-
I've never attempted to compile to VLX, but after reading this I thought would (repeat 1) can be an alternative of a loooong (progn).
(repeat 1) is behaving exactly like (progn)... Check for 255 lines and fails in VLIDE; check for 254 lines and it passes test...
-
On "making dcl on the fly" ... maintaining code and packaging code are distinctly different activities. Both are easy, enjoyable -- fun even. My maintained code is miles from ugly. On the other hand packaged code does not get scrutinized for aesthetics but for reliability, robustness ease of distribution etc. But alas, I evangelize fruitlessly.
-
Almost all of my dialogs are purpose built and centrally referenced from a network location, so there isn't much point in building them on the fly from code. But as noted, any differences are mostly stylistic rather than technical.
-
Almost all of my dialogs are purpose built and centrally referenced from a network location, so there isn't much point in building them on the fly from code. But as noted, any differences are mostly stylistic rather than technical.
Using network is the worse than creating a dialogue on the fly, because the server may be down or any update have bugs. Then stop the work of an entire workgroup. In my opinion, it is best to install the application locally and to enable its users to update their own. You can also divide users into groups depending on their experience. More experienced users will be the first to try out new features of the application, test the application performance and send error reports. Thus, it can safely carry out testing of the new features and their implementation. Finally, most of user not need any updates.They may get angry when something suddenly changes in their usual work.