---

Bin eben mal wieder auf ein sehr merkwürdiges Verhalten in VLisp gestoßen:

Code:

---

(defun c:bugtest( / i rl)
  (setq i 0)
  (repeat 256
    (setq rl(cons(list i i i)rl))
    (setq i(1+ i))
  )
  (setq *result* (reverse rl))
)

---

Hat jemand eine Erklärung für diesen Quatsch? Die globale Variable *result* ist völlig gesund!

(length *result*) => 256
(car *result*) => (0 0 0)
(last *result*) => (255 255 255)

Aber bei der Ausgabe tritt der Fehler auf.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hi Axel.. is ja tricky..
Hmm .. vielleicht wird für den Rückgabewert der Funktion bloß ein gewisser Speicherplatz reserviert, und deine Liste ist zu lang?
Bis (repeat 220 ... ist nämlich alles ok .. und wenn man einen anderen Rückgabewert setzt auch...
z.B.
(defun c:bugtest( / i rl)
  (setq i 0)
  (repeat 250
    (setq rl(cons(list i i i)rl))
    (setq i(1+ i))
  )
  (setq *result*(reverse rl))
  'T
)

Du bist dran.
 

------------------
- Thomas -
"Bei 99% aller Probleme ist die umfassende Beschreibung des Problems bereits mehr als die Hälfte der Lösung desselben."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Tag zusammen.

 

Zitat:

---

Hat jemand eine Erklärung für diesen Quatsch? Die globale Variable *result* ist völlig gesund!

---

Keine wirklich fachlich fundierte und belegbare, aber weitere Beobachtungen kann ich ergänzen:

1. Das Autocad-Textfenster hat eine Begrenzung, die die größte mögliche Ausgabe auf 4095 Zeichen beschrankt. Danach wird gnadenlos abgeschnitten:

Code:

---

(defun c:bugtest( / i rl)
  (setq i 0)
  (repeat 701
    (setq rl(cons(list i)rl))
    (setq i(1+ i))
  )
  (setq *result* (reverse rl))
)
__________________________________
(c:bugtest)
(strlen(vl-princ-to-string *result*)) -> 4097

---

Aber die Ausgabe im Textfenster bricht mit "..(700" ab. Allerdings wir in deinem Beispiel diese Grenze nicht erreicht ..

2. Dieses Problem tritt nur im AutoCAD-Textfenster auf. Im VLisp-Konsolenfenster gibt es diese Problem nicht. Allerdings existiert dort ebenfalls eine Obgrenze für die Anzahl der anzeigbaren Zeichen, wie ich unlängst beim Versuch eine 130MB fassende Lisp-Datei zu laden leidvoll erfahren musste.

3. Das Problem hat eine äußerst gut versteckte Ursache, die mit der Darstellung des letzten Listen-Elements in den Unterlisten zusammenhängt. Hierzu eine winzige Modifikation, die aber keinen internen Fehler verursacht:

Code:

---

(defun c:bugtest( / i rl)
  (setq i 0)
  (repeat 256
    (setq rl(cons(list i i (itoa i))rl))
    (setq i(1+ i))
  )
  (setq *result* (reverse rl))
)

---

Jetzt gebe ich den Staffelstab weiter, auf dass wir weitere Erkenntnisse gewinnen mögen.

Achim Dabrunz

--
PS: Warum werden eigendlich die schließenden CODE-Tags ignoriert und die Formatierung nicht wieder in den Normal-Modus versetzt?

------------------
   

[Diese Nachricht wurde von Dabrunz am 05. Aug. 2005 editiert.]

[Diese Nachricht wurde von Dabrunz am 05. Aug. 2005 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von CADmium:
Bis (repeat 220 ... ist nämlich alles ok .. und wenn man einen anderen Rückgabewert setzt auch...

---

Das Problem liegt ja nicht im Rückgabewert, es liegt an der Ausgabe. Das 'T am Ende deiner Version verhindert den Ausdruck im Textfenster, aber das Problem ist dadurch nicht weg: Gibt man !*result* oder (princ *result*) ein, hat man es ja immer wieder am Backen.

Achims Version mit dem String ist natürlich auch sehr interessant. Aber irgendein System dahinter erkenne ich nach wie vor nicht:-(((

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Dabrunz:
Warum werden eigendlich die schließenden CODE-Tags ignoriert und die Formatierung nicht wieder in den Normal-Modus versetzt?

---

Diese Frage hat mich auch schon interessiert: Wenn der Code eine Leerzeile enthält, geht's in die Hose.

Gruß, Axel

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Sehr komisch!
Mit dem Speicherplatz hat's nichts zu tun:
- setz mal i als anfangswert auf -1000 und repeat auf 1000 -> kein Problem.
- anders bei:

Code:

---

(list (list 220 220 220))

---

ergibt schon BAD ARGUMENT TYPE. Aber nur, wenn die erste Zahl zwischen 220 und 239 liegt...????????

Grüsse, Henning

------------------
VoxelManufaktur Computer-Dienstleistungen für Architekten und Ingenieure

  http://www.voxelman.de

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

...is ja echt krank...

------------------
- Thomas -
"Bei 99% aller Probleme ist die umfassende Beschreibung des Problems bereits mehr als die Hälfte der Lösung desselben."

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

- anders bei:

Code:

---

(list (list 220 220 220))

---

ergibt schon BAD ARGUMENT TYPE. Aber nur, wenn die erste Zahl zwischen 220 und 239 liegt...????????

---

Wirklich abgefahren, aber das ist wohl der Schlüssel des Problems! Ich habe noch ein paar Beispiele angesehen und siehe da:

'((230 1)) -> kein Problem
'((230 1 1)) -> ein Problem
'((230 1 1 1)) -> ein Problem
'((230 1 1 1 1)) -> kein Problem

Dabei spielt's keine Rolle, welcher der Zahlen aus [220; 239] am Anfang der Liste steht. Schreibe ich aber:

'((230.0 1 1 1)) -> kein Problem

Auch, wenn in der Liste auf einer Position irgend ein Eintrag auftaucht, der keine Zahl darstellt, gibt es nix Außergewöhnliches zu sehen:

'((230 1 t 1)) -> kein Problem

Was ist also an denen so bsonders? -> Da liegen die GruppenCodes für Y- und Z-Koordinaten-Darstellung im DXF. Jetzt spekuliere ich mir eine fehlerhafte Prüffunktion zusammen, die Amok läuft wenn eine ListenStruktur - auch außerhalb des GC-Kontextes - zur Erzeugung oder Anzeige der Beteiligten Werte (z.B. Extrusion: GC 210) im ACAD-Textfenster (resp. der Befehlszeile) auftaucht.

Wenn's so ist, dann hat jedenfalls jemand mit 'ner heißen Nadel diese Prüfung noch schnell in den Code rein-gefix, weil sie wohl fehlte und dabei was übersehen ..

Achim Dabrunz

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hat REVERSE vielleicht eine Grössenbeschränkung 

Gruss
Ralph

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Noch was ganz komisches:
Der Fehler ist eigentlich kein Fehler, denn

Code:

---

(vl-catch-all-apply 'list '((220 220 220)))

---

liefert korrekt ((220 220 220)) zurück und kein #<%catch-all-apply-error%>. Und erst nach der Rückgabe kommt BAD ARGUMENT TYPE, allerdings ohne die sonst übliche Erläuterung, welches Argument denn nun falsch ist.

Grüsse, Henning

------------------
VoxelManufaktur Computer-Dienstleistungen für Architekten und Ingenieure

  http://www.voxelman.de

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

REVERSE müßte als copy-func definiert sein. Es kann passieren, das der LispStack dabei überläuft (siehe Fehlermeldungen im "alten" Handbuch Benutzanpassungen).

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

lispStack.pdf

Quelle von Reini Urban

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

REVERSE müßte als copy-func definiert sein. Es kann passieren, das der LispStack dabei überläuft (siehe Fehlermeldungen im "alten" Handbuch Benutzanpassungen).

---

Das hat aber gar nix mit dem hier beschr. Problem zu tun.

Achim

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Irgendwie war eben kurz ein Beitrag von mapcar zu sehen - nun zumindest findet man bei commonlisp folgende Hinweise:
http://www.lispworks.com/documentation/HyperSpec/Body/f_revers.htm#reverse

Wenn mit REVERSE in diesem Fall eine neue Liste erzeugt wird, dann sollten die "Programmwerte" eigentlich im Stack liegen.

Vielleicht hat der vlisp-interpreter hier andere Ansichten.

Wahrscheinl. treffen wie mapcar beschreibt, mehrere Bugs zusammen.

So langsam hebt sich Vorhang.

Gruss
Ralph

[Diese Nachricht wurde von Apply2CAD am 05. Aug. 2005 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

[..]
Wenn mit REVERSE in diesem Fall eine neue Liste erzeugt wird, dann sollten die "Programmwerte" eigentlich im Stack liegen.

Vielleicht hat der vlisp-interpreter hier andere Ansichten.
[..]

---

Lieber Ralph;

nur, um nochmal sicher zu gehen, dass ich nix übersehe:

Wo ist hier ein reverse zu sehen?

Code:

---

(list (list 220 1 1))

---

Achim Dabrunz

------------------

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Nee, es geht überhaupt nicht um die Listen an sich, sondern nur um deren Ausgabe am Bildschirm, sonst nix! Es hat also gar nichts mit der Länge der Listen usw. zu tun, und es handelt sich keineswegs um einen neuentdeckten bug, sondern um einen alten Hut. Bin nur nicht gleich drauf gekommen.

Code:

---

Befehl: (cons'(220 220 220)nil)
((220 220 220))
AnwendungsFEHLER: Bad argument type
---
Befehl: !'((220 220 220))
((220 220 220))
AnwendungsFEHLER: Bad argument type
---
Befehl: !'((220 220 219))
((220 220 219))
AnwendungsFEHLER: Bad argument type
---
Befehl: !'((219 220 220))
((219 220 220))

---

Dass es nur um die Bildschirmausgabe geht, beweist die folgende Modifikation meines Testprogramms:

Code:

---

(defun c:bugtest2( / fh i rl)
  (setq i 0)
  (repeat 256
    (setq rl(cons(list i i i)rl))
    (setq i(1+ i))
  )
  (setq *result* (reverse rl))
  (if(setq fh(open "c:/temp/bugtestout.lsp" "w"))
    (progn
      (princ *result* fh)
      (close fh)
    )
  )
)

---

Beim Schreiben in eine Datei tritt keinerlei Fehler auf.

Der Fehler ist also als "nicht gravierend" einzustufen, er behindert den Programmablauf nicht. Ätzend ist er trotzdem, denn er hat mich erst einmal ein paar Stunden Suche an ganz anderer Stelle gekostet: Die Listen kamen bei mir aus einem ADS-Programm und wurden von dort an Lisp zurückgegeben. Ich habe natürlich erstmal gründlichst in meinem C-Code gesucht und bin gar nicht erst auf die Idee gekommen, dass es an der Lisp-Ausgabe liegen könnte.

Wenn ich mich recht erinnere, wurde dieser Fehler schon vor Jahren einmal in den Autodesk-NGs diskutiert, allerdings mehr unter dem Titel "Fehler in (cons)" oder ähnlichem. Ich konnte jetzt aber nichts mehr dazu finden. Beschämend für Autodesk, dass so etwas nicht behoben wird, wenn es schon jahrelang bekannt ist.

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Inzwischen habe ich mein Hirnschmalz sowie Google angestrengt und den alten Thread in der Customization NG gefunden, er ist vom 25.1.2002 und betrifft Acad 2002. Es ging tatsÀchlich um (cons), die kritischen GCs waren hier allerdings 97 - 105.

Echt spaßig z.B. dieser hier:

Code:

---

Befehl: !'((105 . 1)(106 . 2))
; Fehler:  Ausnahmebedingung aufgetreten: 0xC0000005 (Zugriffsverletzung)

---

Dieser Bug wurde also auch in 2006 noch nicht beseitigt. Da kann ich nur wiederholen: Liest A. die eigenen NGs nicht mit, oder sind denen die Anwender sooooooo wurscht?

Gruß, Axel Strube-Zettler

------------------
Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze

[Diese Nachricht wurde von mapcar am 08. Aug. 2005 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Tja, da dieses Thema gerade mal wieder an anderer Stelle diskutiert wurde, ein Update.
(damit ich es selbst in ein paar Jahren hier wieder nachlesen kann)

Version 2021, auch nach zwei Jahrzehnten, das Problem besteht weiterhin.

Die Aussage von Axel(RIP)
>>Dass es nur um die Bildschirmausgabe geht, beweist die folgende Modifikation meines Testprogramms:<<

ist wohl nicht (mehr?) haltbar und damit auch deutlich gewichtiger wie hier noch angenommen.

1. Der Schriftfeld Dialog, jo - den gab es 2002 noch nicht, aber egal.
  Statt diesen Dialog kann man auch ein (gc) aufrufen - gleiches Ergebnis.

Führt man so eine problematische Auswertung aus,
egal ob mit Error endend (also Ausgabe im Textfenster/Befehlszeile) oder auch in der Vlide(ohne Error),

a) startet danach den Schriftfeld Dialog und wählt Anderer/Lispvariable =Programmcrash!

Gut, hier könnte man noch die Theorie basteln "es werden alle Variablen ausgewertet, auch ohne direkte Anzeige im Programm ist es immerhin "nah dran" am Geschriebenen hier.

b) oder aber anstatt Schriftfeld, startet man danach den Befehl NEU und wählt eine Vorlage.
Programmcrash!

Spätestens der Crash bei Befehl Neu zeigt:
Es hat in keinem Fall nur mit der Ausgabe zutun.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,

Zitat:

---

(damit ich es selbst in ein paar Jahren hier wieder nachlesen kann)

---

dann ist das wohl nur für dich :D ein Problem hab ich aber nur mir Axels !(doppelliste)

Code:

---

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

---

Der Rest scheint zu gehen und "!" habe ich nie wirklich verwendet hätte da jetzt so wirklich keine Verwendung für aber vielleich gibt mir da jemand eine Erleutung. Aber ich meine ich habe hier auch schonmal einen ausgiebigen Beitrag über abgeschittene und verkürzte Ausgaben gelesen.

------------------
Gruß Wolfgang

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Es geht hier im Thema ausschließlich um Listen oder Liste in Listen bei denen die erste eine für Entitie Eigenschaften gültige Liste darstellt.

Von daher überprüfe es vielleicht noch einmal, ganz sicher ist es zumindest nicht nur für mich, das ist bereits geklärt.

Ob du nun ! oder (setq a... verwendest, völlig egal.
Selbst wenn man es in der Vlide ausführt und kein Fehler angezeigt wird
sollte es bei SchriftFeld/LispVariable oder auch Befehl: Neu <Vorlage wählen> zu Problemen kommen.

Wenn nicht bei jedem, wovon ich aber ausgehe, dann wenigsten bei Vielen.

?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Ja, es ist so wie auch schon von mir festgestellt dotted pairs gehen nicht durch egal wie.
Die Frage beibt aber immer noch wann und für wen macht ein Lisp ausdruck in der Acad Befehlszeile Sinn damit man über so einen Fehler stolpert.

------------------
Gruß Wolfgang

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Meldin:

Die Frage beibt aber immer noch wann und für wen macht ein Lisp ausdruck in der Acad Befehlszeile Sinn damit man über so einen Fehler stolpert.

---

Das mache ich reöativ häufig beim Debuggen. Beim  Ablauf von AutoCAD Befehlen gebe ich dann auf Optionsanfragen gerne mal direkt einen Lisp-Ausdruck in der Befehlszeile ein.

Andere Verwendung ist ähnlich wie die transparente Eingabe des 'CAL Befehls, den ich mal in Lisp nachprogrammiert habe.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP