|
AutoLisp : Lisp immer kränker?
mapcar am 05.08.2005 um 13:04 Uhr (0)
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 erken ...
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
mapcar am 05.08.2005 um 13:20 Uhr (0)
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, gehts in die Hose.Gruß, Axel------------------Meine AutoLisp-Seiten Mein Angriff auf dein Zwerchfell Mein Lexikon der Fotografie Mein gereimtes Gesülze
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
wronzky am 05.08.2005 um 14:56 Uhr (0)
Sehr komisch!Mit dem Speicherplatz hats 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
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
CADmium am 05.08.2005 um 16:38 Uhr (0)
...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."
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
Dabrunz am 05.08.2005 um 16:46 Uhr (0)
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 ProblemDabei spielts keine Rolle, welcher der Zahlen aus [220; 239] am Anfang der Liste steht. Schreibe ich aber:((230.0 1 1 1)) - kein Pro ...
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
Apply2CAD am 05.08.2005 um 16:56 Uhr (0)
Hat REVERSE vielleicht eine Grössenbeschränkung GrussRalph
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
wronzky am 05.08.2005 um 16:59 Uhr (0)
Noch was ganz komisches:Der Fehler ist eigentlich kein Fehler, dennCode:(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
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
Apply2CAD am 05.08.2005 um 17:18 Uhr (0)
REVERSE müßte als copy-func definiert sein. Es kann passieren, das der LispStack dabei überläuft (siehe Fehlermeldungen im "alten" Handbuch Benutzanpassungen).
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
Apply2CAD am 05.08.2005 um 17:30 Uhr (0)
Quelle von Reini Urban
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
Dabrunz am 05.08.2005 um 18:36 Uhr (0)
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------------------
|
| In das Form AutoLisp wechseln |
|
AutoLisp : Lisp immer kränker?
mapcar am 05.08.2005 um 20:09 Uhr (0)
Na, da kommt ja einiges zusammen;-) Dass Listen mit bestimmten Zahleninhalten, die auch Gruppencodes sein *könnten*, Probleme verursachen können, war ja schon länger bekannt. Ich kann mich im Moment aber nicht an Details erinnern.Dass da aber der Schlüssel dieses Problem liegt, halte ich für unwahrscheinlich. Ich denke eher, dass hier zwei ganz verschiedene Bugs zusammentreffen, aber das ist Zufall.Jedenfalls: Eine "Mengengrenze" spielt hier keine Rolle, auch nicht die Anzahl der Unterlisten. Ursprünglich ...
|
| In das Form AutoLisp wechseln |
|
Lisp : Lisp immer kränker?
mapcar am 05.08.2005 um 10:03 Uhr (1)
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 Zwer ...
|
| In das Form Lisp wechseln |
|
Lisp : Lisp immer kränker?
Dabrunz am 05.08.2005 um 11:25 Uhr (1)
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)))_____________________________ ...
|
| In das Form Lisp wechseln |
