topic Re: Stupid Lisp bug in Visual LISP, AutoLISP and General Customization Forum

Stupid Lisp bug

honkinberry — Thu, 30 Jul 2020 18:46:51 GMT

This has driven me crazy for years, I can't believe it is still a thing.

(setq _test nil) (setq i -1) (repeat 256 (setq i (1+ i)) (setq _test (append _test (list (cons i i)))) ) ; repeat

That should give you an immediate access violation error.

But better yet, then type FIELD, click on Lisp Variables, and AutoCAD doesn't just crash, it instantly and completely disappears.

Is this the equivalent of saying "Biggie Smalls" three times in the mirror?

--J

Re: Stupid Lisp bug

ronjonp — Thu, 30 Jul 2020 18:52:00 GMT

What version of CAD are you on? Does not crash 2021 here.

Re: Stupid Lisp bug

honkinberry — Thu, 30 Jul 2020 18:55:56 GMT

With 2021 when I go into the FIELD dialog and click on Lisp Variables, I get an immediate Access Violation error at the command line. You don’t?

Re: Stupid Lisp bug

ronjonp — Thu, 30 Jul 2020 19:03:58 GMT

@honkinberry wrote:
With 2021 when I go into the FIELD dialog and click on Lisp Variables, I get an immediate Access Violation error at the command line. You don’t?

Nope.

Re: Stupid Lisp bug

Kent1Cooper — Thu, 30 Jul 2020 19:12:51 GMT

I ran that [Acad2019] just for kicks. For me, it does give an access violation error, though after making the entire list, if timing is part of your issue.

I did the Field thing, and yes, it crashed, but not instantly and completely -- there was the "normal" stopped-working-checking-for-a-solution message, and a box that waited for me to pick on the "Close program" button.

I don't know what the violation is there -- it just makes a list of dotted pairs, and it gets to the end successfully, and returns the result as a completed list, as in lots of AutoLisp routines. Access to what has been violated? Violated by what?

I tried again, and before doing the Field thing, just typed !_test to see whether it had saved it to the variable, at which it returned the list again [so yes, it had saved it], and the access violation message also returned.

In any case, what would you use such a thing for?

Re: Stupid Lisp bug

ronjonp — Thu, 30 Jul 2020 19:22:47 GMT

@honkinberry I was able to replicate the crash opening fields / lispvariables using this:

(setq _test nil) (setq i 256) (repeat i (setq i (1- i)) (setq _test (cons (cons i i) _test))) ; repeat

Re: Stupid Lisp bug

honkinberry — Thu, 30 Jul 2020 19:35:56 GMT

Maintaining a list of color substitutions.

Can’t think of a programming language where you aren’t allowed to create such an array for fear of it crashing the entire system.

Re: Stupid Lisp bug

ronjonp — Thu, 30 Jul 2020 19:44:43 GMT

@honkinberry wrote:
Maintaining a list of color substitutions.

Can’t think of a programming language where you aren’t allowed to create such an array for fear of it crashing the entire system.

@honkinberry Very strange indeed. A quick test and if those values are stored as: (setq _test (cons (list i i) _test)) it does not crash.

Re: Stupid Lisp bug

honkinberry — Thu, 30 Jul 2020 20:12:40 GMT

I've tried many variations including that one that still crash.

I was about to convert it to Reals, which doesn't crash, but your post made me think of something!

(reverse)!

If it's 255 to 0, then it doesn't crash for me, and I can still assoc it.

So that's my temporary solution for now.

But this has been an issue for me since... I'm going to say probably 2004. I originally posted about this around then, maybe it was 2006.

I just can't fathom how a list of this construction could possibly cause such an error.

--J

** edit, no, sorry, reversing it does still crash.

So the temporary solution for now is to have a list of Reals instead of Integers, which definitely does not crash.

Re: Stupid Lisp bug

ronjonp — Thu, 30 Jul 2020 20:19:48 GMT

Did you try the (list i i) ?

Re: Stupid Lisp bug

honkinberry — Thu, 30 Jul 2020 20:21:56 GMT

Yes, that still crashes for me.
As does having the first value be (-1 -1), etc.
The best simple solution I’ve found is reals, storing it as (0.0 0)

—J

Re: Stupid Lisp bug

Kent1Cooper — Thu, 30 Jul 2020 20:31:15 GMT

[EDIT: now I see @ronjonp beat me to it in suggesting this....]

Here's an alternative that doesn't crash AutoCAD [for me], and still uses integers instead of your workaround with real numbers [so in the case of color numbers, you won't need to convert back]: Do little two-item "plain" lists instead of dotted pairs:
....

(setq _test (append _test (list (list i i))))

....

You would simply need to use either:

(cadr (assoc somenumber _test))

or:

(last (assoc somenumber _test))

to get the second number from a given sub-list, rather than using (cdr) as you would with a dotted-pair sub-list.

Re: Stupid Lisp bug

honkinberry — Thu, 30 Jul 2020 20:59:00 GMT

That was actually the first thing I tried, and it still crashes on me.

Both that, and reversing the list, seem to crash *less*, but still crash.

Only by switching the index of each element to a Real, have I consistently seen no issues.

--J

Re: Stupid Lisp bug

john.uhden — Thu, 30 Jul 2020 23:15:14 GMT

Yep, does for me too in 2002.

I see no reason for it, except I thought maybe 256 was an unpassable limit. So I tried it with 255... same error. Even with 100, it errored out. Nice work!

Yet, this does work (when localizing variables)...

(defun c:test (/ test i) (setq i -1) (repeat 256 (setq i (1+ i)) (setq test (append test (list (cons i i)))) ) (princ test) (princ) )

I really don't get it.

Re: Stupid Lisp bug

CADaSchtroumpf — Fri, 31 Jul 2020 09:24:40 GMT

Indeed it is a very strange limitation ...

To me it seems to be 103, at 104 I have a violation!

((lambda ( / tmp i) (repeat (setq i 103) (setq i (1- i) tmp (cons (cons i i) tmp) ) ) ))

Re: Stupid Lisp bug

dbroad — Fri, 31 Jul 2020 12:58:30 GMT

Thanks for reporting this bug. I hope the forum manager is passing this information up to the AutoCAD development team as I know they have had recent interest in improving LISP.

This suggestion for a workaround is essentially the same as @ronjonp but it seems to work for me. It works faster and the field dialog opens faster and doesn't report any errors. Closing drawings and closing AutoCAD isn't a problem either. (Tested with 2017 on Windows 7 with 32GB Ram)

(setq _test nil) (setq i 256) (repeat 256 (setq i (1- i)) (setq _test (cons (cons i (cons i nil)) _test)) ) ; repeat

Unfortunately, you would need to use (cadr(assoc key# _test)) to get the value#

Re: Stupid Lisp bug

honkinberry — Fri, 31 Jul 2020 15:55:01 GMT

Apologies for not doing proper testing of this.

My best guess is that I still had a variable set as a dotted pairs when I tested the (list value value) method, hence why I kept getting access violation errors.

So agreed, this is the simplest workaround.

--J

Re: Stupid Lisp bug

ronjonp — Fri, 31 Jul 2020 19:41:01 GMT

@honkinberry ~~What is your application for this list?~~ Is it really made up of equal dotted pairs?

I see you answered HERE.

This is a very strange bug indeed...

Re: Stupid Lisp bug

honkinberry — Fri, 31 Jul 2020 20:00:47 GMT

It’s a color substitution list.
There are 255 indexed colors. So this is the control list for converting from our standard to the user’s. The default has all values the same.
So when creating a layer, it checks this to see what color it should be made to match the user’s preferences.

But again, does that matter?
If I had a JavaScript array of the letters of the alphabet and it crashed a web browser, would you seriously ask me why I was creating such an array?
Come on man, this is an egregious and inexcusable bug.

Re: Stupid Lisp bug

cadffm — Fri, 31 Jul 2020 20:24:39 GMT

There is a problem with the output to Textscreen, min. 18 years, i guess 21years or longer.

Adesk know about the issue and nothing changed for 2 decades.

Important is that it is just an output problem,

output to vlide console or to an external file is not a problem.

A simpler sample:

!'((105 . 1)(106 . 2))

(setq a '((105 . 1)(106 . 2)))

One did a big mistake, perhaps im hurry, but nobody fixed it.

Report bugs, post ideas?

You can read well sounding posts from Adesk workers, but .. if you can not laugh, then cry.

And we could talk about it hours, weeks and years, Adesk will not fix the problems.

😞