gendl issueshttps://gitlab.common-lisp.net/gendl/gendl/-/issues2015-03-31T02:16:43Zhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/41nlib error that I wasn't expecting2015-03-31T02:16:43ZDave Coopernlib error that I wasn't expecting*Created by: reiniervandijk*
Try to visualize trim-2 and see if you get:
```lisp
Warning: Failed to get curve length with routine n_gprcle.
The Nlib error was: `(14) Input data is corrupt.'
```
Source:
```lisp
(define-obje...*Created by: reiniervandijk*
Try to visualize trim-2 and see if you get:
```lisp
Warning: Failed to get curve length with routine n_gprcle.
The Nlib error was: `(14) Input data is corrupt.'
```
Source:
```lisp
(define-object trimmed-closed-curve-samples (base-object)
:objects
((arc :type 'arc-curve :radius 1)
;; case 1 works
(trim-1 :type 'trimmed-closed-curve :built-from (the arc) :u1 0.8 :u2 0.2 :display-controls (list :color :green))
;; case 2 works
(trim-2 :type 'trimmed-closed-curve :built-from (the arc) :u1 0.8 :u2 1.2 :display-controls (list :color :blue))
;; case 3 will signal error (logically)
(trim-3 :type 'trimmed-closed-curve :built-from (the arc) :u1 0.8 :u2 1.9 :display-controls (list :color :red))
))
(define-object trimmed-closed-curve (curve)
:documentation
(:author
"Reinier van Dijk"
:description
"Specialized trimmed-curve object for closed-curves. It allows to travel beyond the curve extreme.")
:input-slots
("GDL Curve Object. The underlying curve from which to build this curve."
built-from
("Number. Specified start parameter. Defaults to the <tt>u1</tt> of the built-from."
u1 (the built-from :u1))
("Number. Specified end parameter. Defaults to the <tt>u2</tt> of the built-from."
u2 (the built-from :u2))
)
:computed-slots
((case (cond ((and (>= (the u2) (the u1))
(<= (the u2) (the built-from :u-max))) :regular)
;; new cases
((> (the u2) (the built-from :u-max))
(if (> (- (the u2) (the built-from :u-max))
(- (the u1) (the built-from :u-min)))
(error "the u1->u2 range provided is larger than the range of a single revolution.")
:split-subtract-max))
(t :split)))
(no-of-trims (if (eq (the case) :regular) 1 2))
(u1s (if (eq (the case) :regular)
(list (the u1))
(list (the u1) (the built-from :u-min))))
(u2s (case (the case)
(:regular (list (the u2)))
(:split (list (the built-from :u-max) (+ (the built-from :u-min) (the :u2))))
(:split-subtract-max (list (the built-from :u-max) (+ (the built-from :u-min) (- (the :u2) (the built-from :u-max)))))))
(native-curve-iw (if (eq (the case) :regular)
(the (trimmed-curves 0) copy-new native-curve-iw)
(the composed-curve copy-new native-curve-iw)))
)
:objects
((trimmed-curves :type 'trimmed-curve
:sequence (:size (the no-of-trims))
:pass-down (built-from)
:u1 (nth (the-child :index) (the u1s))
:u2 (nth (the-child :index) (the u2s)))
(composed-curve :type 'composed-curve :curves (list-elements (the trimmed-curves)))
)
)
```
**Imported comments:**
*By genworks on 2013-08-01 18:54:23 UTC*
I don't get that error. I get the attached output.
![Uploading trim-2.png . . .]()
*By reiniervandijk on 2013-08-01 22:06:59 UTC*
While doing add-node on the trim-2 instance?
Op 1 aug. 2013 om 20:54 heeft Dave Cooper <notifications@github.com> het volgende geschreven:
> I don't get that error. I get the attached output.
> [Uploading trim-2.png . . .]()
>
> —
> Reply to this email directly or view it on GitHub.
*By genworks on 2013-08-01 22:32:40 UTC*
Oo, maybe just did add-leaves. Will try add-node. To be continued.
On Aug 1, 2013, at 5:06 PM, reiniervandijk <notifications@github.com> wrote:
> While doing add-node on the trim-2 instance?
>
> Op 1 aug. 2013 om 20:54 heeft Dave Cooper <notifications@github.com> het volgende geschreven:
>
> > I don't get that error. I get the attached output.
> > [Uploading trim-2.png . . .]()
> >
> > —
> > Reply to this email directly or view it on GitHub.
> —
> Reply to this email directly or view it on GitHub.
*By genworks on 2013-08-02 15:46:40 UTC*
Indeed the add-node on ```trim-1``` threw the error. The issue is that the ```trimmed-closed-curve``` object was having ```u1``` and ```u2``` slots, which interfered with the standard ```u1``` and ```u2``` of ```curve```.
When you specialize a built-in primitive, you have to take care not to override any of its fundamental slots. This is a recurring issue and an area where the GDL compiler probably should be extended to provide warnings or errors in such cases. It's a bit tricky though, because there are cases where (assuming you know what you are doing), you really do want to override fundamental slots of a base class. So the basic rule of thumb is, when in doubt, when you are specializing a built-in class, look at its slots and don't override them (except for input-slots which clearly are intended to be used as such).
Also, we updated this example to override the standard ```built-from``` input within the specialized ```curve``` object, in order to establish what the identity of this actual curve object should be. The ```copy-new``` technique being used previously is not documented/supported. When you want to make a ```curve``` (or ```brep```, or ```surface```) cloned from some other object of the same type, the ```built-from``` input is the standard way of doing this. Our use of ```built-from``` as the input for trimmed-curve is inconsistent in this regard; the input in that case should probably be named ```curve-in``` instead of ```built-from```.
```common-lisp
(in-package :gdl-user)
(define-object trimmed-closed-curve-samples (base-object)
:objects
((arc :type 'arc-curve :radius 1)
;; case 1 works
(trim-1 :type 'trimmed-closed-curve :curve-in (the arc)
:u1-in 0.8 :u2-in 0.2
:display-controls (list :color :green))
;; case 2 works
(trim-2 :type 'trimmed-closed-curve
:curve-in (the arc) :u1-in 0.8 :u2-in 1.2
:display-controls (list :color :blue))
;; case 3 will signal error (logically)
(trim-3 :type 'trimmed-closed-curve
:curve-in (the arc) :u1-in 0.8 :u2-in 1.9
:display-controls (list :color :red))))
(define-object trimmed-closed-curve (curve)
:documentation
(:author
"Reinier van Dijk"
:description
"Specialized trimmed-curve object for closed-curves. It allows to travel beyond the curve extreme.")
:input-slots
("GDL Curve Object. The underlying curve from which to build this curve."
curve-in
("Number. Specified start parameter. Defaults to the <tt>u1</tt> of the curve-in."
u1-in (the curve-in u1))
("Number. Specified end parameter. Defaults to the <tt>u2</tt> of the curve-in."
u2-in (the curve-in u2)))
:computed-slots
((case (cond ((and (>= (the u2-in) (the u1-in))
(<= (the u2-in) (the curve-in :u-max))) :regular)
;; new cases
((> (the u2-in) (the curve-in :u-max))
(if (> (- (the u2-in) (the curve-in :u-max))
(- (the u1-in) (the curve-in :u-min)))
(error "~&the u1->u2 range provided is larger than the range of a single revolution.~%")
:split-subtract-max))
(t :split)))
(no-of-trims (if (eq (the case) :regular) 1 2))
(u1s (if (eq (the case) :regular)
(list (the u1-in))
(list (the u1-in) (the curve-in :u-min))))
(u2s (case (the case)
(:regular (list (the u2-in)))
(:split (list (the curve-in u-max) (+ (the curve-in u-min) (the u2-in))))
(:split-subtract-max (list (the curve-in :u-max) (+ (the curve-in :u-min)
(- (the :u2-in) (the curve-in :u-max)))))))
(built-from (if (eq (the case) :regular)
(the (trimmed-curves 0))
(the composed-curve))))
:objects
((trimmed-curves :type 'trimmed-curve
:sequence (:size (the no-of-trims))
:built-from (the curve-in)
:u1 (nth (the-child :index) (the u1s))
:u2 (nth (the-child :index) (the u2s)))
(composed-curve :type 'composed-curve :curves (list-elements (the trimmed-curves)))))
```
*By reiniervandijk on 2013-08-02 16:01:04 UTC*
Hi Dave, I actually already thought this was the main issue. The slot overriding issue already happened to me on numerous occasions in the past,, so I'm fully aware of the potential consequences. However, I purposely didn't fix my code with a renaming strategy on this occasion and posted it here regardless, since the trimmed-curve object definition inspired me to (stubbornly) keep u1 and u2 as inputs and not renaming them. Why is it then actually not leading to errors for the trimmed-curve object? Seems like a potential issue to me.
*By genworks on 2013-08-02 16:40:59 UTC*
>
> Why is it then actually not leading to errors for this object? Seems like a
> potential issue to me
>
Apparently it was leading to errors for trim-1. For trim-1, the u1 was
ending up greater-than the u2, which I speculate was the cause of the
"corrupt data" error from nlib. That's why I changed these to u1-in and
u2-in, so that the new curve object (derived from the composed-curve in the
case of trim-1) could properly compute its own default u1 and u2.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/39composed-curve strange behavior when used on small curves2015-03-31T02:16:43ZDave Coopercomposed-curve strange behavior when used on small curves*Created by: reiniervandijk*
Try:
```lisp
(define-object composed-curve-error (base-object)
:objects
((curve-1 :type 'linear-curve :start (the center) :end (translate (the center) :right 0.1))
(curve-2 :type 'linear-curv...*Created by: reiniervandijk*
Try:
```lisp
(define-object composed-curve-error (base-object)
:objects
((curve-1 :type 'linear-curve :start (the center) :end (translate (the center) :right 0.1))
(curve-2 :type 'linear-curve :start (the center) :end (translate (the center) :rear 0.001))
(composed :type 'composed-curve :curves (list (the curve-1) (the curve-2)))
(composed-2 :type 'composed-curve :curves (list (the curve-1) (the curve-2)) :coincident-point-tolerance 0.0001)
(composed-3 :type 'composed-curve :curves (list (the curve-1) (the curve-2))
:coincident-point-tolerance 0.00001
:distance-to-create-line 0.00001)
))
```
first composition leads to 1 curve that completely ignores curve-2. This is probably due to the coincident-point tolerance that is rather large by default (0.01). Setting it to a lower value (composed-2), leads to an error "two curves result". What!? Playing around with the distance-to-create-line value even leads to more intuitive errors:
```lisp
!! This section threw error: Attempt to take the car of -106824 which is not listp. !!
```
I personally believe that the composed-curve should detect cases where curves are completely ignored in the end-result or at least be able to predict this will happen and then inform the user. I had several cases with students who couldn't explain their end results because of such things.
**Imported comments:**
*By genworks on 2013-08-08 17:06:37 UTC*
Although this should not be the case, you will get better results from composed-curve if the input curves are already ordered and chained end-to-end. The version below passes the input data with the curves already chained, and gives expected results for composed and composed-2. The distance-to-create-line does not behave well.
There is an unsupported, undocumented function surf::chain-nurbs-curves which can help with chaining the curves end-to-end. This function should probably be documented and supported, and perhaps used by default on the inputs to composed-curve.
```common-lisp
(define-object composed-curve-error (base-object)
:objects
((curve-2 :type 'linear-curve
:start (the center)
:end (translate (the center) :right 0.1))
(curve-1 :type 'linear-curve
:end (the center)
:start (translate (the center) :rear 0.001))
(composed :type 'composed-curve
:curves (list (the curve-1) (the curve-2)))
(composed-2 :type 'composed-curve
:curves (list (the curve-1) (the curve-2))
:coincident-point-tolerance 0.0001)
(composed-3 :type 'composed-curve
:curves (list (the curve-1) (the curve-2))
:coincident-point-tolerance 0.00001
;;:distance-to-create-line 0.00001
)))
```
https://gitlab.common-lisp.net/gendl/gendl/-/issues/38inconsistency in method removal at redefinition2015-03-31T02:16:42ZDave Cooperinconsistency in method removal at redefinition*Created by: reiniervandijk*
At this moment gendl only removes old methods (originating from previous object definitions) from the :gdl-slots package. What about removing the associated methods from the :gdl-inputs package?
Try:
`...*Created by: reiniervandijk*
At this moment gendl only removes old methods (originating from previous object definitions) from the :gdl-slots package. What about removing the associated methods from the :gdl-inputs package?
Try:
```lisp
(define-object reinier ()
:input-slots
((a 2)))
```
associated methods can be found with:
```lisp
(find-method (symbol-function (com.genworks.lisp:intern "a" :gdl-slots)) nil (list (find-class 'reinier)))
(find-method (symbol-function (com.genworks.lisp:intern "a" :gdl-inputs)) nil (list (find-class 'gdl::gdl-basis)
(find-class t)
(find-class 'gdl::gdl-basis)))
```
Then, when redefining:
```lisp
(define-object reinier ()
:input-slots
((b 2)))
```
The gdl-slots methods is removed, however this still returns:
```lisp
(find-method (symbol-function (com.genworks.lisp:intern "a" :gdl-inputs)) nil (list (find-class 'gdl::gdl-basis)
(find-class t)
(find-class 'gdl::gdl-basis)))
```
Practically, only the gdl-slots method should be removed to make sure the object doesn't answer messages that it doesn't hold any longer. One could even argue that it's up to the gc system to clean up old method definitions (it doesn't in ACL). However, it is somewhat inconsistent to not clean up the other methods (be lean) and I therefore consider it an issue. Should be noted that the same story applies to gdl-trickle-downs and other packages.
**Imported comments:**
*By genworks on 2013-10-31 23:36:26 UTC*
There are reasons for keeping these around.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/37is gdl-inputs::<message> always necessary?2015-03-31T02:16:41ZDave Cooperis gdl-inputs::<message> always necessary?*Created by: reiniervandijk*
Looking at the macro-expansion of define-object. Is it actually not undesirable to define a gdl-inputs::\<message\> method for computed-slots or objects (etc)? I fully understand the purpose of these methods...*Created by: reiniervandijk*
Looking at the macro-expansion of define-object. Is it actually not undesirable to define a gdl-inputs::\<message\> method for computed-slots or objects (etc)? I fully understand the purpose of these methods (so, no need to explain in the comments), however I don't see their purpose in the context of :computed-slots or :objects (etc). Unless you foresee situations in which you would like to allow a parent object to also pass on information to the computed or object messages of their children... but isn't that against the nature of the language?
**Imported comments:**
*By genworks on 2013-10-26 03:19:09 UTC*
These are necessary for potential trickle-down-slots to work properly. Maybe some could be filtered out if it is somehow known that they will never occur as trickle-downs, but for now we prefer to err on the side of being conservative.
Note that :objects and :hidden-objects are always trickle-down by default.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/35step import affected by center value2015-03-31T02:16:40ZDave Cooperstep import affected by center value*Created by: reiniervandijk*
Weird: point objects read in using assembly-import are affected by center allocations upstream. In my case I made an object with a center that has an assembly-import type child. Changing the center value ups...*Created by: reiniervandijk*
Weird: point objects read in using assembly-import are affected by center allocations upstream. In my case I made an object with a center that has an assembly-import type child. Changing the center value upstream away from 0,0,0 will offset all points over the same distance. This should never happen.
**Imported comments:**
*By genworks on 2015-01-30 00:51:36 UTC*
Moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/33strings-for-display as input-slot2015-03-31T02:16:39ZDave Cooperstrings-for-display as input-slot*Created by: reiniervandijk*
Consider:
```lisp
(define-object A ()
:input-slots
((strings-for-display "hoi")))
```
If you open this in Tasty, apparently strings-for-display is set by Gendl and doesn't respect user-defined ...*Created by: reiniervandijk*
Consider:
```lisp
(define-object A ()
:input-slots
((strings-for-display "hoi")))
```
If you open this in Tasty, apparently strings-for-display is set by Gendl and doesn't respect user-defined default. Changing strings-for-display to a computed-slot, solves the problem, but not the intrinsic issue.
**Imported comments:**
*By genworks on 2013-10-26 03:08:05 UTC*
This was originally by design --- in tasty, the toplevel part gets input its strings-for-display from tasty, and this is the object type. The intent was so that you could tell what type of object you are looking at (and it is not a named instance because it has no parent to name it).
But if it does have an input-slot defined for strings-for-display, I suppose this shouldn't be overridden by tasty.
Fix will be in a 1585 maintenance update.
Implemented by removing :strings-for-display input to root-object-object in tasty:assembly.
*By genworks on 2013-10-28 02:21:18 UTC*
This has been reverted. If you want to specify the strings-for-display, make it a computed-slot of your root object. Otherwise it gets passed in by tasty as the object type. If this is not input from tasty, and the toplevel part does not specify its own strings-for-display, the name comes out as "root-object-object" which is not desirable.
Original behavior has been restored and will be left this way pending further discussion, if needed.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/32reserved words should be conditionally dependent on use of base-object2015-03-31T02:16:39ZDave Cooperreserved words should be conditionally dependent on use of base-object*Created by: reiniervandijk*
For objects where one doesn't use base-object, but only (implicitly) vanilla-mixin, it is wrong to cast errors for some of the so-called reserved-words that are only meaningful for base-object. For example, ...*Created by: reiniervandijk*
For objects where one doesn't use base-object, but only (implicitly) vanilla-mixin, it is wrong to cast errors for some of the so-called reserved-words that are only meaningful for base-object. For example, this will now throw an error:
```lisp
(define-object A ()
:computed-slots
((vertex nil)))
**Imported comments:**
*By genworks on 2015-01-29 23:49:44 UTC*
Open for submissions: $100
*By reiniervandijk on 2015-01-30 16:00:13 UTC*
Solution rational (code below):
- Constant ``+reserved-words+`` included symbols from the base-object class. So, I took them out and isolated them in a ``+reserved-words-base-object+`` constant.
- For safety, I've now committed code with constant ``+reserved-words-vanilla+``. If you think the list makes sense, rename twice to ``+reserved-words+``.
- It was now required to test at compile-time if ``base-object`` base in the mixin-list explicitly or by inheritance.
- For this purpose, I've added a ``mixin-list`` argument to the ``reserved-word-warning-or-error`` function, which is supplied by the ``%define-object%`` macro.
- Test for ``base-object`` inheritance has been isolated in ``%base-object-subclass?%`` function.
Side note:
The ``+reserved-words+`` parameter seemed to not be up-to-date with ``vanilla-mixin*``. Moreover, I believe ``standard-sequence`` slots should also be protected. I've updated the reserved words list with **all** symbols from ``vanilla-mixin*`` and ``standard-sequence``. Please find some private routines that I made to print all messages at run-time. These functions can be used to update the reserved word constants in the future.
Code in chunks below.
1. updated and new constants
2. updated define-object code and reserved word checking
3. some utilities to generate the reserved symbol lists in the future.
*By reiniervandijk on 2015-01-30 16:00:50 UTC*
new constants:
```lisp
(in-package :gdl)
(glisp:define-constant +reserved-words-vanilla+
;; Use utility function below after bootstrap to obtain current list!
(mapcar #'(lambda(symbol)
(glisp:intern symbol :gdl-acc))
'(active-inputs
aggregate
all-mixins
array
child-types
children
children-uncached
color-hex
direct-mixins
display-controls
documentation
first
first?
follow-root-path
get-member
hidden-children
hidden?
ignore-messages-from
index
instantiated-indices
last
last?
leaf?
leaves
leaves-uncached
list-elements
list-elements-uncached
message-documentation
message-list
message-remarks
mixins
modify-attribute!
modify-attributes!
name-for-display
next
null-part?
number-of-elements
parent
parent-tree
part-documentation
previous
primary?
quantify-box
query-plist
reference-chain
remote-id
restore-all-defaults!
restore-attribute-default!
restore-attribute-defaults!
restore-node!
restore-slot-default!
restore-slot-defaults!
restore-tree!
root
root-path
root-path-local
root-path-string
root?
safe-children
safe-hidden-children
safe-list-elements
set-slot!
set-slot-if-needed!
set-slots!
show-dependency-tree
slot-documentation
slot-source
slot-status
strings-for-display
transitory-slots
type
unbind-remote-slot
update!
viewable-slots
visible-children
write-snapshot
)))
(glisp:define-constant +reserved-words-base-object+
(append +reserved-words-vanilla+
(mapcar #'(lambda(symbol)
(glisp:intern symbol :gdl-acc))
'(color-decimal
edge-center
face-center
face-normal-vector
local-center
obliqueness
vertex
))))
```
*By reiniervandijk on 2015-01-30 16:03:22 UTC*
updated define-object code and reserved word checking
```lisp
(defun %base-object-subclass?% (mixin-list)
(let ((base-object-symbol (find-symbol "base-object" :geom-base)))
(when base-object-symbol
(let ((base-object-class
(find-class base-object-symbol nil)))
(when base-object-class
(some #'(lambda (mixin)
(let ((class (find-class mixin nil)))
(and class
;; RvD: consider using subtypep here
(subtypep class base-object-class))))
mixin-list))))))
(defun reserved-word-warning-or-error (name mixin-list messages)
(unless (and (atom name)
(or (member (symbol-package name) *reserved-word-protected-packages*)))
(let ((reserved-violations
(if (%base-object-subclass?% mixin-list)
(intersection messages +reserved-words-base-object+)
(intersection messages +reserved-words-vanilla+))))
(when reserved-violations
(let ((is-or-are (if (= (length reserved-violations) 1) "is" "are"))
(s-or-blank (if (= (length reserved-violations) 1) "" "s"))
(a-or-blank (if (= (length reserved-violations) 1) "a " "")))
(funcall (if *error-on-reserved-words?*
#'error
#'warn)
"The symbol~a listed below ~a ~areserved word~a and should not be used as ~a
GDL message name~a or child object input name~a.
~a.
~{ ~a~^~%~}
"
s-or-blank
is-or-are
a-or-blank
s-or-blank
a-or-blank
s-or-blank
s-or-blank
(if *error-on-reserved-words?*
"You can override this error (AT YOUR OWN RISK)
by setting *error-on-reserved-words?* to nil."
"NOTE that you are getting a warning instead of an error because
*error-on-reserved-words?* is changed from its default of t and set to nil. This is RISKY
and you should proceed this way only if you really know what you are doing.")
(safe-sort reserved-violations #'string-lessp :key #'string)))))))
(defmacro %define-object% (name mixin-list
&key input-slots
computed-slots
objects
hidden-objects
functions
methods
(no-vanilla-mixin? nil)
documentation
trickle-down-slots
query-slots
)
(with-gdl-message-symbols (:new t)
(reserved-word-warning-or-error name mixin-list messages)
(let ((message-ht (make-hash-table :size (length messages))))
(dolist (message messages)
(push message (gethash message message-ht)))
(let ((duplicates (let (duplicates)
(maphash #'(lambda(key val)(if (consp (rest val)) (push key duplicates))) message-ht) duplicates)))
(let ((duplicates (remove-if #'(lambda(dup) (member dup method-syms)) duplicates)))
(when duplicates
(error "duplicate slot name~p: ~{~a~^, ~}" (length duplicates) (sort duplicates #'string-lessp :key #'symbol-name))))))
`(progn
(defclass ,name ,(if (or no-vanilla-mixin?
(some #'(lambda(mixin)
(let ((class (find-class mixin nil)))
(and class
(member (find-class 'vanilla-mixin)
;; RvD: consider using subtypep here
(all-superclasses class))))) mixin-list))
mixin-list
(append mixin-list (list 'vanilla-mixin)))
(,@(append (make-standard-slots)
(make-accessible-slots computed-slot-syms)
(make-accessible-slots settable-computed-slot-syms)
(make-accessible-slots uncached-computed-slot-syms)
(make-accessible-slots query-slot-syms)
(make-accessible-slots object-syms)
(make-accessible-slots quantified-object-syms)
(make-accessible-slots hidden-object-syms)
(make-accessible-slots quantified-hidden-object-syms)
(make-accessible-slots cached-function-syms)
(make-accessible-slots cached-method-syms)
(make-accessible-slots required-input-slot-syms :inputs? t)
(make-accessible-slots optional-input-slot-syms :inputs? t)
(make-accessible-slots settable-input-slot-syms :inputs? t)
(make-accessible-slots defaulted-input-slot-syms :inputs? t)
(make-accessible-slots settable-defaulted-input-slot-syms :inputs? t))) (:metaclass gdl-class))
(let ((,class-arg (find-class ',name)))
(let ((,old-message-keys (messages ,class-arg))
(,new-message-keys ',messages))
(dolist (key (set-difference ,old-message-keys ,new-message-keys))
(let ((method (ignore-errors
(find-method (symbol-function (glisp:intern (symbol-name key) :gdl-slots)) nil
(list ,class-arg) nil))))
(when method
(when *report-gdl-redefinitions?*
(format t "~%Removing slot: ~a for object definition: ~s~%" key ',name))
(remove-method (symbol-function (glisp:intern (symbol-name key) :gdl-slots)) method)))))
,(when (and *compile-documentation-database?* documentation)
`(when *load-documentation-database?*
(setf (gdl-documentation ,class-arg) ',documentation))))
(when (message-documentation (find-class ',name)) (clrhash (message-documentation (find-class ',name))))
(when (message-source (find-class ',name))(clrhash (message-source (find-class ',name))))
(setf (messages (find-class ',name)) ',messages)
(setf (required-input-slots (find-class ',name)) ',required-input-slot-syms)
(setf (optional-input-slots (find-class ',name)) ',optional-input-slot-syms)
(setf (defaulted-input-slots (find-class ',name)) ',defaulted-input-slot-syms)
(setf (computed-slots (find-class ',name)) ',computed-slot-syms)
(setf (query-slots (find-class ',name)) ',query-slot-syms)
(setf (settable-computed-slots (find-class ',name)) ',settable-computed-slot-syms)
(setf (uncached-computed-slots (find-class ',name)) ',uncached-computed-slot-syms)
(setf (settable-optional-input-slots (find-class ',name)) ',settable-input-slot-syms)
(setf (settable-defaulted-input-slots (find-class ',name)) ',settable-defaulted-input-slot-syms)
(setf (functions (find-class ',name)) ',function-syms)
(setf (methods (find-class ',name)) ',method-syms)
(setf (cached-functions (find-class ',name)) ',cached-function-syms)
(setf (cached-methods (find-class ',name)) ',cached-method-syms)
(setf (objects (find-class ',name)) ',object-syms)
(setf (quantified-objects (find-class ',name)) ',quantified-object-syms)
(setf (hidden-objects (find-class ',name)) ',hidden-object-syms)
(setf (quantified-hidden-objects (find-class ',name)) ',quantified-hidden-object-syms)
(setf (trickle-down-slots (find-class ',name))
',(append object-syms quantified-object-syms hidden-object-syms quantified-hidden-object-syms trickle-down-slot-syms))
(setf (settable-slots (find-class ',name)) ',(append required-input-slot-syms settable-input-slot-syms
settable-defaulted-input-slot-syms settable-computed-slot-syms))
;; FLAG -- consider pre-cooking these expression lists
;;
,@(message-generics (set-difference messages (append method-syms cached-method-syms)))
,(input-slots-generics (append (group-remark-strings (remove-if-not #'(lambda(item)
(or (symbolp item) (stringp item)))
input-slots))
(remove-if-not #'consp input-slots)))
,@(input-slots-section name (group-remark-strings (remove-if-not #'(lambda(item)
(or (symbolp item) (stringp item)))
input-slots)))
,@(optional-input-slots-section
name (remove-if-not #'(lambda(slot) (and (consp slot) (null (rest (rest (strip-strings slot))))))
input-slots))
,@(optional-input-slots-section
name (remove-if-not
#'(lambda(slot)
(and (consp slot)
(member :settable (rest (rest (strip-strings slot))))
(not (member :defaulting (rest (rest (strip-strings slot)))))))
input-slots))
,@(optional-input-slots-section
name (remove-if-not #'(lambda(slot)
(and (consp slot)
(member :defaulting (rest (rest (strip-strings slot))))
(not (member :settable (rest (rest (strip-strings slot)))))))
input-slots) t)
,@(optional-input-slots-section
name (remove-if-not
#'(lambda(slot)
(and (consp slot)
(member :settable (rest (rest (strip-strings slot))))
(member :defaulting (rest (rest (strip-strings slot))))))
input-slots) t)
,@(computed-slots-section
name (remove-if-not #'(lambda(slot) (and (consp slot) (null (rest (rest (strip-strings slot))))))
computed-slots))
,@(computed-slots-section
name (remove-if-not #'(lambda(slot)
(and (consp slot) (eql (first (rest (rest (strip-strings slot))))
:settable)))
computed-slots))
,@(computed-slots-section name query-slots :query? t)
,@(objects-section name (append objects hidden-objects))
,@(functions-section
name (mapcar #'(lambda(slot)
(if (stringp (first slot))
(list (first slot) (second slot) nil (third slot))
(list (first slot) nil (second slot))))
(remove-if-not #'(lambda(slot) (and (consp slot) (eql (first (rest (rest (strip-strings slot))))
:uncached)))
computed-slots)))
,@(functions-section name functions)
,@(methods-section name methods)
,@(trickle-down-slots-section trickle-down-slot-syms)
,@(trickle-down-slots-section (append object-syms quantified-object-syms hidden-object-syms quantified-hidden-object-syms)
:from-objects? t)
#+nil
(defmethod gdl-rule::%object-keywords%
((,self-arg ,name))
(remove-duplicates
(append ',object-syms ',quantified-object-syms
(when (next-method-p) (call-next-method)))))
#+nil
(defmethod gdl-rule::%hidden-object-keywords%
((,self-arg ,name))
(remove-duplicates
(append ',hidden-object-syms ',quantified-hidden-object-syms
(when (next-method-p) (call-next-method)))))
;;
;; FLAG -- maybe some of these others can go away as well.
;;
(let ((,self-arg (find-class ',name nil)))
(when ,self-arg
(setf (trickle-down-effective ,self-arg) nil)))
;;
;; FLAG -- use uiop:list-to-hash-set
;;
(defmethod gdl-rule::%trickle-down-slots%
((,self-arg ,name))
(let ((class (class-of ,self-arg)))
(or (trickle-down-effective class)
(let* ((trickles (remove-duplicates
(mapcar #'make-keyword
(append ',(append object-syms quantified-object-syms hidden-object-syms
quantified-hidden-object-syms trickle-down-slot-syms)
(when (next-method-p) (list-hash (call-next-method)))))))
(ht (glisp:make-sans-value-hash-table :size (length trickles))))
(dolist (trickle trickles ht)
(setf (gethash trickle ht) t))))))
#+nil
(defmethod gdl-rule::%trickle-down-slots%
((,self-arg ,name))
(remove-duplicates
(mapcar #'make-keyword
(append ',(append object-syms quantified-object-syms hidden-object-syms
quantified-hidden-object-syms trickle-down-slot-syms)
(when (next-method-p) (call-next-method))))))
(defmethod gdl-rule::%settable-slot-list%
((,self-arg ,name))
(remove-duplicates
(mapcar #'make-keyword
(append ',(append settable-input-slot-syms
settable-defaulted-input-slot-syms
settable-computed-slot-syms)
(when (next-method-p) (call-next-method))))))
(defmethod gdl-rule::%settable-slots%
((,self-arg ,name))
(let ((,ht-arg (glisp:make-sans-value-hash-table))
(,symbols-arg (gdl-rule::%settable-slot-list% ,self-arg))
(,non-settables-arg (mapcar #'make-keyword
(set-difference (messages (find-class ',name))
(settable-slots (find-class ',name))))))
(dolist (,symbol-arg ,symbols-arg ,ht-arg)
(when (not (member ,symbol-arg ,non-settables-arg))
(setf (gethash ,symbol-arg ,ht-arg) t)))))
(defmethod gdl-rule::%message-source%
((,self-arg ,name) ,message-arg &optional (,depth-arg 0))
(let* ((method (nth ,depth-arg (compute-applicable-methods
#'gdl-rule::%message-source% (list ,self-arg ,message-arg))))
(class (first (glisp:gl-method-specializers method))))
(append (let ((local (let ((ht (message-source class)))
(when ht (gethash ,message-arg ht)))))
(when local (list (glisp:gl-class-name class) local)))
(when (next-method-p) (call-next-method ,self-arg ,message-arg (1+ ,depth-arg))))))
(defmethod gdl-rule::%message-remarks%
((,self-arg ,name) ,message-arg &optional (,depth-arg 0))
(let* ((method (nth ,depth-arg (compute-applicable-methods
#'gdl-rule::%message-remarks% (list ,self-arg ,message-arg))))
(class (first (glisp:gl-method-specializers method))))
(append (let ((local (let ((ht (message-documentation class)))
(when ht (gethash ,message-arg ht)))))
(when local (list (glisp:gl-class-name class) local)))
(when (next-method-p) (call-next-method ,self-arg ,message-arg (1+ ,depth-arg))))))
;;
;; FLAG -- why is this hardcoded to :all when it is first called?
;;
(defmethod gdl-rule::%message-list%
((,self-arg ,name) ,category-arg ,message-type-arg ,base-part-type-arg
&optional (,depth-arg 0))
(append (message-list ,self-arg
;;:all
,category-arg
,depth-arg ,base-part-type-arg)
(when (and (not (eql ,message-type-arg :local)) (next-method-p))
(call-next-method ,self-arg ,category-arg ,message-type-arg ,base-part-type-arg (1+ ,depth-arg)))))
(find-class ',name))))
```
*By reiniervandijk on 2015-01-30 16:04:07 UTC*
some utilities to generate the reserved symbol lists in the future.
```lisp
;;; Some utilities for the updating reserved-words
(defun %print-reserved-words-vanilla% ()
(%print-symbol-list% (%reserved-messages-vanilla%)))
(defun %reserved-messages-vanilla% ()
(let ((messages
(append (gdl::messages (find-class 'vanilla-mixin*))
(gdl::messages (find-class 'standard-sequence)))))
;; filter out those leading "%"
(loop for message in messages
if (not (eq (char (symbol-name message) 0) #\%))
collect message)))
(defun %print-symbol-list% (messages)
"utility to quickly print lisp code for constant definition"
(format t "(mapcar #'(lambda(symbol)
(glisp:intern symbol :gdl-acc))
'(~{~a~% ~}))"
(safe-sort messages #'string< :key 'symbol-name)))
```
*By genworks on 2015-03-18 03:43:44 UTC*
An update has been merged to devo branch which implements a more general approach and does not require maintaining any lists of reserved symbols. https://gitlab.common-lisp.net/gendl/gendl/-/issues/30sudden crash of lisp2015-03-31T02:16:38ZDave Coopersudden crash of lisp*Created by: reiniervandijk*
I don't know if this is 1582 specific, but just in case it isn't: I came across this sudden crash error.
```lisp
dispatch-event: (:emacs-rex (swank:compile-file-for-emacs "d:\\etc\\file.lisp" t) ":materi...*Created by: reiniervandijk*
I don't know if this is 1582 specific, but just in case it isn't: I came across this sudden crash error.
```lisp
dispatch-event: (:emacs-rex (swank:compile-file-for-emacs "d:\\etc\\file.lisp" t) ":materials" t 2322)
close-connection: Attempt to start thread worker gave OS error code 0xc ...
;; Event history end.
;; Backtrace:
;; Connection to Emacs lost. [
;; condition: Attempt to start thread worker gave OS error code 0xc
;; type: simple-error
;; style: :spawn]
```
**Imported comments:**
*By genworks on 2013-10-26 02:49:54 UTC*
Please upgrade to 1585, available now for download.
*By genworks on 2013-10-26 02:50:10 UTC*
if this issue repeats in 1585 please re-open.
*By genworks on 2013-10-26 02:50:15 UTC*
re-closing. https://gitlab.common-lisp.net/gendl/gendl/-/issues/27Clicking node with no graphics gives broken image link2015-03-31T02:16:37ZDave CooperClicking node with no graphics gives broken image link*Created by: genworks*
This should display a useful "no graphics" message instead. *Created by: genworks*
This should display a useful "no graphics" message instead. https://gitlab.common-lisp.net/gendl/gendl/-/issues/26YADD footer contains wrong version number2015-03-31T02:16:36ZDave CooperYADD footer contains wrong version number*Created by: genworks*
version number was hardcoded to 1581p009.
**Imported comments:**
*By genworks on 2013-10-26 02:44:44 UTC*
Fixed in release/gdl1585*Created by: genworks*
version number was hardcoded to 1581p009.
**Imported comments:**
*By genworks on 2013-10-26 02:44:44 UTC*
Fixed in release/gdl1585https://gitlab.common-lisp.net/gendl/gendl/-/issues/25smlib::assembly-import error on point2015-03-31T02:16:36ZDave Coopersmlib::assembly-import error on point*Created by: reiniervandijk*
1585: STEP import fails on points. Error message.
```lisp
!! This section threw error: No methods applicable for generic function #<standard-generic-function gdl-slots::item> with args (nil) of classes (...*Created by: reiniervandijk*
1585: STEP import fails on points. Error message.
```lisp
!! This section threw error: No methods applicable for generic function #<standard-generic-function gdl-slots::item> with args (nil) of classes (null) !!
```
**Imported comments:**
*By reiniervandijk on 2013-11-01 06:53:12 UTC*
Showstopper at the moment.
*By genworks on 2013-11-01 16:57:45 UTC*
Note that this is still officially an unexported/unsupported interface. But we are eager to bring it into production as soon as possible.
By the way, was this actually working in smlib::assembly-import in 1581 and stopped working in 1585?
If it's convenient, can you provide a test case (a simple GDL object with a STEP output, which fails to round-trip back in with smlib::assembly-import)? If this isn't convenient, that's fine we can set one up here -- but it's best to work with an exact case that is failing for you just to eliminate the chance of missing something.
*By genworks on 2013-11-01 21:29:11 UTC*
I think we do need a test case for this. The attached example (containing some curves and two points) is round-tripping out and in through all combinations of the flat and assembly based step writers/readers:
```common-lisp
(in-package :gdl-user)
(defparameter *step-points-path* *load-pathname*)
(define-object smiley (base-object)
:objects
((circle :type 'arc-curve
:radius 10)
(smile :type 'arc-curve
:radius 7
:start-angle (degrees-to-radians 190)
:end-angle (degrees-to-radians 350)
:center (translate (the center) :front (* (the circle radius) 0.05)))
(eyes :type 'point
:sequence (:size 2)
:center (translate (the center)
:rear (* (the circle radius) 0.3)
(ecase (the-child index)
(0 :left)
(1 :right)) (* (the circle radius) 0.42))))
:functions
((step-out!
()
(with-format (step (merge-pathnames "smiley-flat.step" *step-points-path*))
(write-the cad-output-tree)))
(step-out-assy!
()
(with-format (step (merge-pathnames "smiley-assy.step" *step-points-path*)
:assembly? t)
(write-the cad-output-tree)))))
(define-object smiley-in (base-object)
:objects
((native-flat-1 :type 'step-reader
:file-name (merge-pathnames "smiley-flat.step" *step-points-path*))
(native-flat-2 :type 'step-reader
:file-name (merge-pathnames "smiley-assy.step" *step-points-path*))
(native-assy-1 :type 'smlib::assembly-import
:file-name (merge-pathnames "smiley-assy.step" *step-points-path*))
(native-assy-2 :type 'smlib::assembly-import
:file-name (merge-pathnames "smiley-flat.step" *step-points-path*))))
```
![smiley-in](https://f.cloud.github.com/assets/364720/1457274/a1ce2de4-433c-11e3-962a-9dbacc2d421b.png)
*By genworks on 2014-02-11 18:45:19 UTC*
Closing the issue, pending a replicatable example.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/23gdlinit.cl not loaded2015-03-31T02:16:35ZDave Coopergdlinit.cl not loaded*Created by: reiniervandijk*
1585: gdlinit.cl seems to be ignored by run-gdl.bat.
**Imported comments:**
*By genworks on 2013-10-29 13:41:50 UTC*
The one in the (user-homedir-pathname) should be loaded as well as one in
the gdl/ i...*Created by: reiniervandijk*
1585: gdlinit.cl seems to be ignored by run-gdl.bat.
**Imported comments:**
*By genworks on 2013-10-29 13:41:50 UTC*
The one in the (user-homedir-pathname) should be loaded as well as one in
the gdl/ installation directory (the parent of gdl/program/ --- if it
exists).
On Tue, Oct 29, 2013 at 9:18 AM, Reinier van Dijk
<notifications@github.com>wrote:
> 1585: gdlinit.cl seems to be ignored by run-gdl.bat.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/gendl/issues/151>
> .
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By genworks on 2013-10-29 13:44:09 UTC*
Recommended practice is to customize the one in the (user-homedir-pathname)
so it will not be overwritten or need to be re-edited when updating GDL
versions or re-installing GDL. (The recommendation in general is to treat
the installation directory as read-only).
On Tue, Oct 29, 2013 at 9:41 AM, Dave Cooper <david.cooper@genworks.com>wrote:
>
> The one in the (user-homedir-pathname) should be loaded as well as one in
> the gdl/ installation directory (the parent of gdl/program/ --- if it
> exists).
>
>
>
> On Tue, Oct 29, 2013 at 9:18 AM, Reinier van Dijk <
> notifications@github.com> wrote:
>
>> 1585: gdlinit.cl seems to be ignored by run-gdl.bat.
>>
>> —
>> Reply to this email directly or view it on GitHub<https://github.com/genworks/gendl/issues/151>
>> .
>>
>
>
>
> --
> My Best,
>
> Dave Cooper, Genworks Support
> david.cooper@genworks.com, dave.genworks.com(skype)
> USA: 248-327-3253(o), 1-248-330-2979(mobile)
> UK: 0191 645 1699
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By reiniervandijk on 2013-10-29 13:45:02 UTC*
I have a gdlinit.cl in the gdl/program directory, because the installation by default put one there. I'd overwritten that one. Shouldn't you then put the gdlinit.cl in the parent directory, because it was natural for me to customize the one in gdl/program....
*By genworks on 2013-10-29 13:46:04 UTC*
Agreed. The one in the gdl/program directory should be moved up a level in
our installation, and it should be empty (or commented out) by default.
This will be corrected for next release.
On Tue, Oct 29, 2013 at 9:45 AM, Reinier van Dijk
<notifications@github.com>wrote:
> I have a gdlinit.cl in the gdl/program directory, because the
> installation by default put one there. I'd overwritten that one. Shouldn't
> you then put the gdlinit.cl in the parent directory, because it was
> natural for me to customize the one in gdl/program....
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/gendl/issues/151#issuecomment-27303446>
> .
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699https://gitlab.common-lisp.net/gendl/gendl/-/issues/21Tasty tree might disappear on error2015-03-31T02:16:34ZDave CooperTasty tree might disappear on error*Created by: reiniervandijk*
Opening a tree node in Tasty, will lead to the real-time calculation of the children. If for any reason, there is an error in your code that is triggered when calculating the minimum aspects of child nodes (...*Created by: reiniervandijk*
Opening a tree node in Tasty, will lead to the real-time calculation of the children. If for any reason, there is an error in your code that is triggered when calculating the minimum aspects of child nodes (edit: hard to pinpoint exactly what causes the problem, can not replicate in isolated example) that error message will take over the entire tree pane. I guess you should catch these errors in JS and show a pop-up to signal an error or something. Now, one HAS to restart the entire Tasty module because you can never retrieve the original tree and continue navigating. In general catching errors on client-side would mean great improvements to the UI. Same applies (although less severe, because it doesn't render the entire UI useless) to the viewport or inspector.
UPDATE: seems that error happens because Gendl tries to assess from each child node if it has safe-children (to show folder icon or not). Calculating the safe-children, gives the error here...
UPDATE 2: isolated it! Quite a nasty one.
```lisp
(in-package :gdl-user)
(define-object A (base-object)
:objects
((child :type 'B)))
(define-object B (base-object)
:objects
((child :type 'C)))
(define-object C (D)
:computed-slots
((hoi (list 3 4 5))))
(define-object D (base-object)
:objects
((hoi :type (if (/ 0 0) 'null-part 'C))
(dag :type (if (/ 0 0) 'null-part 'C))))
```
Gendl falsely asssumes hoi to still be a object keyword, although it has been overwritten by C.
Try:
```lisp
(the child child :%object-keywords%)
```
I will open a new issue, because this issue is about catching error on client-side, while the afore-mentioned problem is related to fundamental Gendl aspects.
**Imported comments:**
*By genworks on 2013-10-29 16:48:13 UTC*
Indeed quite a subtle and nasty issue. Here is a proposed fix:
```common-lisp
(in-package :gdl)
(#+allegro
excl:without-package-locks
#-allegro progn
(define-object-amendment vanilla-mixin* ()
:computed-slots
((%object-keywords% (safe-sort (append (the (message-list :category :objects))
(the (message-list :category :quantified-objects)))
#'string-lessp))
(%hidden-object-keywords% (safe-sort (append (the (message-list :category :hidden-objects))
(the (message-list :category :quantified-hidden-objects)))
#'string-lessp)))))
```
*By genworks on 2013-10-29 16:51:07 UTC*
One lesson to take from this is to avoid depending on internal, undocumented features whenever possible --- even when implementing internal, undocumented features!
*By genworks on 2013-10-29 16:56:48 UTC*
Regarding the comment about handling errors on the client-side: agreed that it would be nice to be doing more of this.
*By reiniervandijk on 2013-10-29 17:17:18 UTC*
I'm surprised that you've closed the other issue and moved the solution here. The core problem was method overriding. It may manifest itself in several ways, not only in the Tasty GUI. I could've come up with 100 situations were an error surfaces that is the result of it. The issue in this topic is client-side error handling.
The issue in #154 should stay open and the fix should move there. And it has nothing to do with internal, undocumented stuff, that's an invalid argument. As a user, I should be able to just override whatever I want at sub-classing (except of course for the protected symbols). The fact that I traced down the issue to the inner working principles, does not mean that I have relied on undocumented stuff, I just reflects the fact that I understand where the problem came from.
*By genworks on 2013-10-29 17:40:42 UTC*
> I'm surprised that you've closed the other issue and moved the solution
> here. The core problem was method overriding. It may manifest itself in
> several ways, not only in the Tasty GUI. I could've come up with 100
> situations were an error surfaces that is the result of it.
>
As far as I could see, the problem being reported in #154 was
malfunctioning of gdl-rule::%object-keywords%, and consequently the
%object-keywords% message of vanilla mixin. These are both clearly
internal, unsupported, undocumented items.
The only place in the Gendl codebase where the gdl-rule::%object-keywords%
is being used is in %object-keywords% message of vanilla-mixin. The only
place the %object-keywords% message of vanilla-mixin is being used is in
the children-uncached, children, and safe-children of vanilla-mixin. These
last three are documented, so there we have a problem for sure. They are
also related to the tasty failure being reported in this #153.
If you have 100 other situations where you are using children-uncached,
children, or safe-children, those should also fall under the jurisdiction
of this #153. If you have 100 situations where you are using
%object-keywords% or gdl-rule::%object-keywords%, then your usage is
invalid. If you have 100 situations which are in neither of these
categories, then they belong in a separate Issue.
> And it has nothing to do with internal, undocumented stuff, that's an
> invalid argument. As a user, I should be able to just override whatever I
> want at sub-classing (except of course for the protected symbols).
>
If you have problems with subclassing which show up in ways unrelated to
%object-keywords% or children-cached or children or safe-children, then
please open a separate Issue which illuminates those problems.
*By genworks on 2013-10-29 17:47:42 UTC*
Note the proposed fix in previous comment has been updated.
*By genworks on 2013-10-29 18:27:18 UTC*
>
> The fact that I traced down the issue to the inner working principles,
> does not mean that I have relied on undocumented stuff, I just reflects
> the fact that I understand where the problem came from.
>
In my previous comment about "depending on internal, undocumented..." I did
not mean to imply that you were doing that. I was making the observation
that we were doing that, in a situation where we didn't have to.
Thank you again for your thorough and helpful Issue reports!
*By reiniervandijk on 2013-10-29 18:29:32 UTC*
You're welcome! :+1: And you're right in your previous post, only gdl-rule::%object-keywords% is wrong, I extrapolated a bit to far.
*By genworks on 2013-10-31 23:28:49 UTC*
This fix will be in the next 1585 maintenance release and in future releases. Closing here for now. https://gitlab.common-lisp.net/gendl/gendl/-/issues/20Method override not correctly implemented2015-03-31T02:16:33ZDave CooperMethod override not correctly implemented*Created by: reiniervandijk*
Consider:
```lisp
(define-object A (base-object)
:objects
((child :type 'B)))
(define-object B (base-object)
:objects
((child :type 'C)))
(define-object C (D)
:computed-slo...*Created by: reiniervandijk*
Consider:
```lisp
(define-object A (base-object)
:objects
((child :type 'B)))
(define-object B (base-object)
:objects
((child :type 'C)))
(define-object C (D)
:computed-slots
((hoi (list 3 4 5))))
(define-object D (base-object)
:objects
((hoi :type (if (/ 0 0) 'null-part 'C))
(dag :type (if (/ 0 0) 'null-part 'C))))
```
If you evaluate:
```lisp
(make-self 'A)
(the child child %object-keywords%)
```
you'll see the problem.
Strange because this is correct:
```lisp
(gdl::computed-slots (find-class 'C))
;; (gdl-acc::hoi)
(gdl::objects (find-class 'C))
;; nil
(gdl::objects (find-class 'D))
;; (gdl-acc::hoi gdl-acc::dag)
```
However, looking closer at an instance level (retrieved from macro-expansion):
```lisp
(defmethod gdl-rule::%object-keywords% ((#:g1211 C)) (remove-duplicates (append 'nil 'nil (when (next-method-p) (call-next-method)))))
```
You see that the next-method is invoked, that leads to class D (as superclass of C). I guess that this a bit naive.
**Imported comments:**
*By genworks on 2013-10-29 16:46:03 UTC*
This is indeed nasty and we welcome the report, but the behavior as described is affecting only internal, undocumented messages. The bug manifests itself in #153, which does affect documented/supported functionality, so the proposed fix will be posted there, and this issue is being closed. https://gitlab.common-lisp.net/gendl/gendl/-/issues/19offset-point-along should warn2015-03-31T02:16:33ZDave Cooperoffset-point-along should warn*Created by: reiniervandijk*
Unlike other methods, the offset-point-along doesn't warn if the distance is bigger than the distance of the curve and without user notice return the end point of the curve. The "point" method on a curve doe...*Created by: reiniervandijk*
Unlike other methods, the offset-point-along doesn't warn if the distance is bigger than the distance of the curve and without user notice return the end point of the curve. The "point" method on a curve does warn about this and pins u-values to u-extremes. Shouldn't the offset-point-along method do something similar? In my case, it could have helped to find an error in my code.
```lisp
(define-object offset-test (base-object)
:computed-slots
((correct (the my-curve (offset-point-along 0 5)))
(correct-pt (get-3d-point-of (the correct)))
(should-warn (the my-curve (offset-point-along 0 100)))
(should-warn-pt (get-3d-point-of (the should-warn)))
)
:objects
((my-curve :type 'fitted-curve :points (list (the center)
(translate (the center) :rear 5 :right 5)
(translate (the center) :right 10)))))
```
**Imported comments:**
*By genworks on 2015-01-30 00:48:46 UTC*
Moving to internal tracking list.https://gitlab.common-lisp.net/gendl/gendl/-/issues/18inconsistency functions angle-between-vectors and angle-between-vectors-d2015-03-31T02:16:32ZDave Cooperinconsistency functions angle-between-vectors and angle-between-vectors-d*Created by: reiniervandijk*
1581: there is inconsistency between functions geom-base:angle-between-vectors and geom-base:angle-between-vectors-d. They should have the same arglist, however they don't. Names differ, use of optional / ke...*Created by: reiniervandijk*
1581: there is inconsistency between functions geom-base:angle-between-vectors and geom-base:angle-between-vectors-d. They should have the same arglist, however they don't. Names differ, use of optional / key differs, but most importantly: geom-base:angle-between-vectors-d does not have an epsilon input. I guess you won't expect the user to go for let-binding *zero-epsilon* approach, right? :)
**Imported comments:**
*By genworks on 2015-01-29 23:16:15 UTC*
Open for submissions: $100.
Any changes here have to be done in such a way to support legacy code without rewriting it.
*By reiniervandijk on 2015-01-30 12:36:40 UTC*
Code below makes ``angle-between-vectors-d`` compatible with ``angle-between-vectors``. The function still supports legacy code that invokes ``(vector-1 vector-2 &optional reference-vector negative?)``, and prints an optional warning message. Different note, ``angle-between-vectors`` contained a bug on its own, will open (and close) in new thread.
```lisp
(in-package :geom-base)
(defparameter *print-deprecated-warnings?* nil)
(defun angle-between-vectors-d (vector-1 vector-2 &optional reference-vector &rest more)
"Number. This function is identical to angle-between-vectors, but returns the angle in degrees.
Refer to angle-between-vectors for more information.
Technical note: the <b>more</b> argument has been introduced to support both
angle-between-vectors call conventions and the legacy signature:
(vector-1 vector-2 &optional reference-vector negative?)
Optionally, a deprecation warning is printed when code invokes this legacy pattern.."
;; resolve &rest arguments.
(let ((arglist
(let ((L (length more)))
(cond ((= L 1)
;; legacy signature:
;; (vector-1 vector-2 &optional reference-vector negative?)
(when *print-deprecated-warnings?*
(warn "negative? argument for angle-between-vectors-d is deprecated. Use :-ve instead."))
(list vector-1 vector-2 reference-vector :-ve (first more)))
((evenp L)
;; angle-between-vectors signature:
;; (vector-1 vector-2 &optional reference-vector &key (epsilon *zero-epsilon*) -ve)
(nconc (list vector-1 vector-2 reference-vector) more))
(t
;; not allowed.
(error (format nil "angle-between-vectors-d received invalid arguments: ~a"
(nconc (list vector-1 vector-2 reference-vector) more))))))))
(radians-to-degrees
(apply #'angle-between-vectors arglist))
))
```
*By reiniervandijk on 2015-01-30 15:40:58 UTC*
Small remark: use of ``nconc`` is safe here. If you don't want it, use ``append`` instead.
*By genworks on 2015-03-11 19:59:17 UTC*
Merged slightly modified version of this fix into devo branch. https://gitlab.common-lisp.net/gendl/gendl/-/issues/17Downloads website2015-03-31T02:16:32ZDave CooperDownloads website*Created by: reiniervandijk*
Something that struck me right now. If new Gendl releases (like 1585) continue to be backwards-incompatible (and although you might assume they will be fully compatible, experience dictates that they will no...*Created by: reiniervandijk*
Something that struck me right now. If new Gendl releases (like 1585) continue to be backwards-incompatible (and although you might assume they will be fully compatible, experience dictates that they will not. Consider for example also the geometry kernel that might have changed significantly on new releases and for which it's practically impossible for you to assure compatibility although all your test cases might still work).
Shouldn't the downloads page on www.genworks.com show (recent) previous releases for download as well? I'm currently on 1581, and if I proceed to downloads only 1585 shows up. That one, as mentioned, does not serve my purpose, but unfortunately I can not anywhere find 1581-1584 ... anymore.
Also, consider a new student or employee that wants to continue working on legacy apps (something I see happening now with the MMG). If loaded into 1585, we get hundreds of (mostly geometry related) errors, and it's a huge pain to start in debugging mode immediately. If that user could've downloaded an older platform version, he might have at least been able to get things up and running and get some feeling for the capabilities of the application.
Every software provider will offer its users the ability to download previous releases, be it with a limited lifetime (fair enough). But you currently only offer the "trunk" version on your downloads website. In your defense, old versions obviously have a limited lifetime; you obviously don't want to continue providing support indefinitely for old stuff. However, at least notify users of the ending support period for old versions (consider how long Windows XP has been supported and still is). The current situation is opposite and the optimum somewhere in the middle.
I consider this a "bug" and not a "feature enhancement" of the software procurement process.
**Imported comments:**
*By genworks on 2013-11-01 17:07:37 UTC*
We are beginning a policy of LTS ("Long-term Support") releases, with an LTS release approximately every 12 months and interim releases approximately monthly. The specifics of this policy will be communicated separately.
The current gdl1585 is intended to be an LTS release (although a maintenance version of this will probably be made available as a full download).
At this point we ask that you please report (as separate Issues) any and all regressions you are experiencing with 1585 so we can work with you to get them resolved as quickly as possible. For any SMLib-related issues, we are able to run 1585 with the old SMLib kernel, so we should be able to isolate SMLib regressions/differences from GDL issues fairly rapidly.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/15wrong keyword arguments to surf::make-transformed-brep2015-03-31T02:16:31ZDave Cooperwrong keyword arguments to surf::make-transformed-brep*Created by: avodonosov*
In the file surf/source/transformed-solid.lisp there is a call
```common-lisp
(make-transformed-brep *geometry-kernel* (the brep)
:translation (the transform-vector...*Created by: avodonosov*
In the file surf/source/transformed-solid.lisp there is a call
```common-lisp
(make-transformed-brep *geometry-kernel* (the brep)
:translation (the transform-vector)
:x-vector (the coordinate-base (face-normal-vector :right))
:y-vector (the coordinate-base (face-normal-vector :rear))
:sew-and-orient? (the sew-and-orient?)
:shrink? (the shrink?)
:scale-vector (the scale))
```
But the definition in the surf/solid/methods.lisp does not have keywords `:shrink?` and `:sew-and-orient?`
```common-lisp
(defmethod make-transformed-brep ((geometry-kernel vanilla-geometry-kernel) brep &key translation x-vector y-vector scale-vector)
...
```
I don't know how critical it is.
Noticed this when CCL generated a compile time warning, and then failed to print the warning due to a bug in CCL (http://trac.clozure.com/ccl/ticket/1134)
**Imported comments:**
*By genworks on 2013-12-16 16:11:42 UTC*
Thanks for the catch. That doesn't throw errors in production because that
function gets shadowed by one in the :smlib package, for the specific use
with SMLib modeling kernel.
The ones defined in :surf package are essentially prototypes.
Anyway I got it cleaned up now.
On Mon, Dec 16, 2013 at 2:52 AM, Anton Vodonosov
<notifications@github.com>wrote:
> In the file surf/source/transformed-solid.lisp there is a call
>
> (make-transformed-brep *geometry-kernel* (the brep)
> :translation (the transform-vector)
> :x-vector (the coordinate-base (face-normal-vector :right))
> :y-vector (the coordinate-base (face-normal-vector :rear))
> :sew-and-orient? (the sew-and-orient?)
> :shrink? (the shrink?)
> :scale-vector (the scale))
>
> But the definition in the surf/solid/methods.lisp does not have keywords
> :shrink? and :sew-and-orient?
>
> (defmethod make-transformed-brep ((geometry-kernel vanilla-geometry-kernel) brep &key translation x-vector y-vector scale-vector)...
>
> I don't know how critical it is.
> Noticed this when CCL generated a compile time warning, and then failed to
> print the warning due to a bug in CCL (
> http://trac.clozure.com/ccl/ticket/1134)
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/gendl/issues/159>
> .
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699https://gitlab.common-lisp.net/gendl/gendl/-/issues/14regressions on quicklisp 2013-12-132015-03-31T02:16:31ZDave Cooperregressions on quicklisp 2013-12-13*Created by: cl-test-grid*
Hello.
gendl has regressions on quicklisp 2013-12-13.
See gendl test results from the last two quickisp versions:
http://common-lisp.net/project/cl-test-grid/library/gendl.html
**Imported comments:**
*By...*Created by: cl-test-grid*
Hello.
gendl has regressions on quicklisp 2013-12-13.
See gendl test results from the last two quickisp versions:
http://common-lisp.net/project/cl-test-grid/library/gendl.html
**Imported comments:**
*By genworks on 2013-12-26 03:00:01 UTC*
Thank you for being active on Christmas Day!
These regressions appear to be caused by regressions with
portableallegroserve on Allegro CL. I know what the regression is, and I
thought the fix was committed before 2013-12-13.
In any case I will track it down and make sure it gets fixed (I think it's
already fixed in current portableallegroserve trunk).
Regards,
Dave
On Wed, Dec 25, 2013 at 8:04 PM, cl-test-grid <notifications@github.com>wrote:
> Hello.
>
> gendl has regressions on quicklisp 2013-12-13.
>
> See gendl test results from the last two quickisp versions:
> http://common-lisp.net/project/cl-test-grid/library/gendl.html
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/gendl/issues/160>
> .
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By avodonosov on 2013-12-26 05:35:17 UTC*
Ah... It was morning of the next day already in my time zone :)
Merry Christmas to you BTW!https://gitlab.common-lisp.net/gendl/gendl/-/issues/13Some systems fail to build - ROBOT and BUS2015-03-31T02:16:30ZDave CooperSome systems fail to build - ROBOT and BUS*Created by: quicklisp*
They seem to need gdl-user, but it's not available to them. A log is here:
http://report.quicklisp.org/gendl/2014-02-28/failtail.txt
**Imported comments:**
*By genworks on 2014-02-28 14:33:36 UTC*
I know ...*Created by: quicklisp*
They seem to need gdl-user, but it's not available to them. A log is here:
http://report.quicklisp.org/gendl/2014-02-28/failtail.txt
**Imported comments:**
*By genworks on 2014-02-28 14:33:36 UTC*
I know the problem. Will get on it now.
On Fri, Feb 28, 2014 at 9:31 AM, Zach Beane <notifications@github.com>wrote:
> They seem to need gdl-user, but it's not available to them. A log is here:
>
> http://report.quicklisp.org/gendl/2014-02-28/failtail.txt
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/gendl/issues/161>
> .
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699