nlib error that I wasn't expecting
Created by: reiniervandijk
Try to visualize trim-2 and see if you get:
Warning: Failed to get curve length with routine n_gprcle.
The Nlib error was: `(14) Input data is corrupt.'
Source:
(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.
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
.
(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.