gendl issueshttps://gitlab.common-lisp.net/gendl/gendl/-/issues2015-03-31T02:17:07Zhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/100Performance bogs down with huge sequences2015-03-31T02:17:07ZDave CooperPerformance bogs down with huge sequences*Created by: genworks*
Huge sequence will bog performance because of list operations during dependency tracking.
```common-lisp
(in-package :gdl-user)
;;
;; Submitted by Hermen de Jong of KE-works
;;
(define-object huge-box...*Created by: genworks*
Huge sequence will bog performance because of list operations during dependency tracking.
```common-lisp
(in-package :gdl-user)
;;
;; Submitted by Hermen de Jong of KE-works
;;
(define-object huge-boxes-sequence (base-object)
:input-slots
((number-of-boxes 100 :settable))
:computed-slots
((wall-width (floor (sqrt (the number-of-boxes)))))
:objects
((boxes :type 'box
:sequence (:size (the number-of-boxes))
:height 10
:width 20
:length 30
:display-controls (list :color :red :transparency .5)
:center (translate (make-point 0 0 0)
:right (* (rem (the-child index)
(the wall-width))
(the-child width))
:top (* (floor (the-child index)
(the wall-width))
(the-child height))))))
```
```common-lisp
gdl-user> (make-self 'huge-boxes-sequence)
#<huge-boxes-sequence @ #x25ab80da>
gdl-user> (the (set-slot! :number-of-boxes 20000))
nil
gdl-user> (time (progn (mapsend (the boxes) :center) nil))
; While compiling #'(:internal (:anonymous-lambda 51) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 11.716732 sec user, 0.000000 sec system
; cpu time (gc) 0.676043 sec user, 0.000000 sec system
; cpu time (total) 12.392775 sec user, 0.000000 sec system
; real time 11.031462 sec (112.3%)
; space allocation:
; 1,680,343 cons cells, 27,958,896 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 2585), minor: 4786 (gc: 2585)
nil
gdl-user>
```
**Imported comments:**
*By genworks on 2013-02-01 03:14:08 UTC*
Fixed with more efficient data structure in place of large dependency tracking lists:
```common-lisp
gdl-user> (make-self 'huge-boxes-sequence)
#<huge-boxes-sequence @ #x2527a892>
gdl-user> (the (set-slot! :number-of-boxes 20000))
nil
gdl-user> (time (progn (mapsend (the boxes) :center) nil))
; While compiling #'(:internal (:anonymous-lambda 52) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 1.288081 sec user, 0.000000 sec system
; cpu time (gc) 0.744046 sec user, 0.000000 sec system
; cpu time (total) 2.032127 sec user, 0.000000 sec system
; real time 1.843707 sec (110.2%)
; space allocation:
; 1,604,168 cons cells, 35,065,232 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 599), minor: 1041 (gc: 599)
nil
gdl-user>
```https://gitlab.common-lisp.net/gendl/gendl/-/issues/99Sequence elements not garbage-collected when number-of-elements is modified2015-03-31T02:17:06ZDave CooperSequence elements not garbage-collected when number-of-elements is modified*Created by: genworks*
(Please see code example from Issue #68)
```common-lisp
(make-self 'huge-boxes-sequence)
```
```common-lisp
gdl-user> (pprint (glisp:room-report))
(:new-free-cons 1019 :new-used-cons 1613 :new-free-oth...*Created by: genworks*
(Please see code example from Issue #68)
```common-lisp
(make-self 'huge-boxes-sequence)
```
```common-lisp
gdl-user> (pprint (glisp:room-report))
(:new-free-cons 1019 :new-used-cons 1613 :new-free-other 29936272
:new-used-other 119776 :old-free-cons 736 :old-used-cons 1029473
:old-free-other 33451536 :old-used-other 32475008)
```
```common-lisp
gdl-user> (dotimes (n 20) (the (set-slot! :number-of-boxes 20000))
(mapsend (the boxes) :center)
(the (set-slot! :number-of-boxes 10000))
(mapsend (the boxes) :center))
```
```common-lisp
gdl-user> (pprint (glisp:room-report))
(:new-free-cons 1019 :new-used-cons 6505370 :new-free-other 107370384
:new-used-other 72025632 :old-free-cons 514 :old-used-cons 19165857
:old-free-other 1371136 :old-used-other 211685968)
```
**Imported comments:**
*By genworks on 2013-02-01 04:04:41 UTC*
Fixed by enhancing dependency-tracking to track elements of sequences with respect to the sequence's number-of-elements.
```common-lisp
(make-self 'huge-boxes-sequence)
```
```common-lisp
gdl-user> (glisp:room-report)
(:new-free-cons 1019 :new-used-cons 1565 :new-free-other 231540304
:new-used-other 145248 :old-free-cons 483 :old-used-cons 1030745
:old-free-other 326332808 :old-used-other 32518200)
```
```common-lisp
gdl-user> (dotimes (n 20) (the (set-slot! :number-of-boxes 20000))
(mapsend (the boxes) :center)
(the (set-slot! :number-of-boxes 10000))
(mapsend (the boxes) :center))
```
```common-lisp
gdl-user> (glisp:room-report)
(:new-free-cons 1019 :new-used-cons 450260 :new-free-other 222520136
:new-used-other 5552744 :old-free-cons 236 :old-used-cons 1032011
:old-free-other 326276256 :old-used-other 32566560)
```
*By genworks on 2013-08-13 14:36:20 UTC*
This issue is being re-opened because the "fix" can cause a subtle issue in rare circumstances. A child object can become spuriously "orphaned" after doing a set-slot! --- that is, it will become unbound, and a new object will be instantiated on-demand, losing any bashing which happened in the child. The "fix" will be reverted in devo branch which will be merged into master branch for next release. https://gitlab.common-lisp.net/gendl/gendl/-/issues/98fitted-curve 2 points and 2 end-vectors gives wrong result2015-03-31T02:17:06ZDave Cooperfitted-curve 2 points and 2 end-vectors gives wrong result*Created by: reiniervandijk*
If user makes fitted-curve with 2 points as input and 2 vectors controlling directions at start and end, object falsely assumes a linear curve. Instead, a curve of degree 3 can be fitted that gives perfect r...*Created by: reiniervandijk*
If user makes fitted-curve with 2 points as input and 2 vectors controlling directions at start and end, object falsely assumes a linear curve. Instead, a curve of degree 3 can be fitted that gives perfect results. In the legacy ICAD platform I remember using this a lot.
Issue is in native-curve slot, this is the solution:
```lisp
(native-curve
(progn
(when (and (the vectors)
(member (the vector-type) (list :tangents :normals))
(not (= (length (the points)) (length (the vectors)))))
(error "For fitted-curve ~s, points and vectors must be lists of the same length.~%"
(cons 'the (reverse (the root-path)))))
;; RvD: new condition
(cond ((and (= (length (the points)) 2)
(the vectors))
(interpolate-curve
*geometry-kernel* (the effective-points) 3 (the parameterization) :vectors (the effective-vectors)
:vector-type (the vector-type) :interpolant? (the interpolant?)
:knot-multiplicity (the knot-multiplicity)
:tolerance (the tolerance)))
((> (length (the points)) 2)
(let ((degree-ok? (<= (the degree) (1- (length (the points))))))
(unless degree-ok?
(error "The degree of a fitted-curve must be less than or equal to the number of control points."))
(interpolate-curve
*geometry-kernel* (the effective-points) (the degree) (the parameterization) :vectors (the effective-vectors)
:vector-type (the vector-type) :interpolant? (the interpolant?)
:knot-multiplicity (the knot-multiplicity)
:tolerance (the tolerance))))
(t (the linear-curve native-curve)))))
```
Try now the following test object and see the result:
```lisp
(define-object fitted-curve-test (base-object)
:computed-slots
((points '(#(0.0 0.0 0.0)
#(1.0 0.0 0.0)))
)
:objects
((straight :type 'fitted-curve
:pass-down (points))
(works :type 'fitted-curve
:pass-down (points)
:vector-type :tangents
;;:degree 1
:vectors '(#(0.0 1.0 0.0)
#(0.0 -1.0 0.0)))
(works2 :type 'fitted-curve
:pass-down (points)
:degree 3
:vector-type :tangents
:vectors '(#(0.0 1.0 0.0)
#(0.0 -1.0 0.0)))))
```
**Imported comments:**
*By genworks on 2013-02-07 06:38:10 UTC*
There are actually several issues similar to this, where curve operations degenerate for curves with only two control points and/or degree of 1. Typically the problems show up with simple linear curves. For example the minimum-distance-to-curve function of curve will fail if one or both of the arguments is a curve with only two control points.
The workaround (as you refer to above) is to make an equivalent degree-3 curve with the missing control-points explicitly added. For linear-curves it is enough to make a b-spline-curve with the start and end control-points repeated, i.e. (start start end end).
We will leave this issue open until we have a general solution which makes the issue transparent.
*By reiniervandijk on 2013-02-07 10:16:19 UTC*
I understand. Beware though that I was not touching upon this general issue, but upon the current fitted-curve implementation that falsely makes a linear-curve object if there are 2 points given. It's about this part:
```lisp
(if (not (> (length (the points)) 2)) (the linear-curve native-curve)))))
```
I hope I made clear that there exists a perfectly possible input from the user where he/she gives only two points plus two tangency conditions. I personally wanted to use this feature to blend some curves between other curves, satisfying continuity. Hence, my message does not provide a work-around, but provides a solution to an issue in the fitted-curve object.
*By genworks on 2015-01-30 23:04:39 UTC*
moving to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/97transformed-solid rotation point of reference defaulted to #(0.0 0.0 0.0)?2015-03-31T02:17:05ZDave Coopertransformed-solid rotation point of reference defaulted to #(0.0 0.0 0.0)?*Created by: reiniervandijk*
Is transformed-solid working normally? I can translate geometry as expected, but rotation gives strange results, although I’m quite sure that I’m giving all the right inputs. Seems like the rotation point of...*Created by: reiniervandijk*
Is transformed-solid working normally? I can translate geometry as expected, but rotation gives strange results, although I’m quite sure that I’m giving all the right inputs. Seems like the rotation point of reference defaults to #(0.0 0.0 0.0), maybe you need to pass that input to smlib as well? Otherwise, work-around is to translate things back afterwards. To illustrate the principle, see attachment and look at both rotated boxes and compare. Clearly, the "box-rotated" object is not rotated around the center of the provide brep.
```lisp
(define-object transformed-solid-tests (base-object)
:objects
((box-at-origin :type 'box-solid :width 3 :length 4 :height 5)
(box-at-origin-translated :type 'transformed-solid
:brep (the box-at-origin)
;;:from-location (the box-at-origin :center)
:to-location (translate (the box-at-origin :center) :right 10))
(box-at-origin-rotated :type 'transformed-solid
:brep (the box-at-origin)
:to-orientation (alignment :rear (the (face-normal-vector :rear))
:top (rotate-vector-d (the (face-normal-vector :top))
10
(the (face-normal-vector :rear)))))
(box :type 'box-solid :width 3 :length 4 :height 5 :center (make-point 2 2 2))
(box-translated :type 'transformed-solid
:brep (the box)
;;:from-location (the box :center)
;;:from-location (the box-at-origin :center)
:to-location (translate (the box :center) :right 10))
(box-rotated :type 'transformed-solid
:brep (the box)
;;:from-location (the box :center)
:from-location (the box :center)
:to-orientation (alignment :rear (the (face-normal-vector :rear))
:top (rotate-vector-d (the (face-normal-vector :top))
10
(the (face-normal-vector :rear)))))
```
**Imported comments:**
*By reiniervandijk on 2013-08-09 08:15:14 UTC*
Any news on this issue? It is pretty clear at this stage that transformed-solid rotates around #(0.0 0.0 0.0) no matter what user provides as input center. In the meantime, I use a work-around:
```lisp
(define-object rotated-solid (brep)
:input-slots
((rotation-point (the brep :center))
(to-orientation (the brep :orientation))
brep-in)
:computed-slots
((built-from (the brep3)))
:hidden-objects
((brep1 :type 'transformed-solid
:brep (the brep-in)
:from-location (the rotation-point)
:to-location (make-point 0 0 0))
(brep2 :type 'transformed-solid
:brep (the brep1)
:to-orientation (the to-orientation))
(brep3 :type 'transformed-solid
:brep (the brep2)
:from-location (make-point 0 0 0)
:to-location (the rotation-point))
)
)
```
*By genworks on 2013-08-11 01:47:14 UTC*
This is currently an unfortunate limitation of transformed-solid -- indeed the orientation is always taken relative to the global origin (geom-base:+nominal-origin+).
Your workaround (moving the object to origin, applying transform, then moving it back) is reasonable, although it creates three times as many breps as should be necessary for this operation (but necessary in practice currently because of this limitation of GDL's transformed-solid primitive).
Our intention is to establish a boxed-brep primitive (to supersede transformed-solid) which will work analogously to boxed-surface and boxed-curve, with the orientation-center input, and which does not create superfluous breps in the process. Internally, this will require integration with additional smlib operations. This Issue remains open until the boxed-brep primitive is complete.
*By genworks on 2015-01-30 22:59:41 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/96trimmed-surface edges no uv-curve?2015-03-31T02:17:05ZDave Coopertrimmed-surface edges no uv-curve?*Created by: reiniervandijk*
A trimmed-surface has edges, however they miss a uv-curve representation. Weird, because the on-surface argument should obviously be the basis-surface provided.
**Imported comments:**
*By genworks on 201...*Created by: reiniervandijk*
A trimmed-surface has edges, however they miss a uv-curve representation. Weird, because the on-surface argument should obviously be the basis-surface provided.
**Imported comments:**
*By genworks on 2013-02-08 18:07:41 UTC*
Try the face of the brep of the trimmed-surface. I'm not totally sure about this, not at computer at the moment, will look at it as soon as possible.
On Feb 8, 2013, at 11:01 AM, reiniervandijk <notifications@github.com> wrote:
> A trimmed-surface has edges, however they miss a uv-curve representation. Weird, because the on-surface argument should obviously be the basis-surface provided.
>
> —
> Reply to this email directly or view it on GitHub..
>
*By reiniervandijk on 2013-02-08 18:21:00 UTC*
nope, also hasn't. Replicate with surf::test-trimmed-surface-3.
*By genworks on 2013-02-18 19:55:00 UTC*
Edges of a brep (or of a brep face) do have a uv-curve message. Note that that is a function (not a slot) and (as documented) you have to pass in the surface relative to which you want the uv-curve. This is because an edge can be shared by two faces (in a manifold solid) or more than two faces (in a non-manifold brep), so it is ambiguous simply to ask for the uv-curve for an edge.
With that said, we should be able to enhance the uv-curve message for edges of _face_ (as opposed to _brep_), because for each face, the basis-surface is not ambiguous. This Issue will remain open until this enhancement is complete.
*By AliAbedian on 2013-03-14 15:11:25 UTC*
I am trying to work with this uv-curve message, but I have some problems in visualizing the curve.
I am getting a curve as a result of calling that function but when I try to visualize it on tasty, I get such an error:
In # "trimmed-curve" (built-from #), u2 is not greater than u1. Cannot Trim. !!
Note that I am testing on a simple box-solid as follows:
```lisp
(test-brep :type 'box-solid
:length 30
:width 30
:height 20)
```
and the way I am calling the function is:
```lisp
(the test-brep (faces 0) (edges 1) (uv-curve (the test-brep (faces 0) basis-surface)))
```
or
```lisp
(the test-brep (edges 1) (uv-curve (the test-brep (faces 0) basis-surface)))
```
Both of these give the same error! ONLY when visualizing. So I should make a new curve out of that to be able to visualize it.
*By genworks on 2015-01-30 22:57:37 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/95recursive behavior in trimmed-surface face's face's face2015-03-31T02:17:04ZDave Cooperrecursive behavior in trimmed-surface face's face's face*Created by: reiniervandijk*
It this logical? the trimmed-surface is a face. It's basis-surface is obviously potentially bigger that the trimmed region. However, the brep of the object has another face, this face on it's turn has a basi...*Created by: reiniervandijk*
It this logical? the trimmed-surface is a face. It's basis-surface is obviously potentially bigger that the trimmed region. However, the brep of the object has another face, this face on it's turn has a basis-surface. But, that one is exactly the same. And so we can go on to the next brep in the tree and again and again. Is this behavior as marketed?
**Imported comments:**
*By genworks on 2013-02-08 18:46:06 UTC*
The face of the brep of the trimmed-surface should be identical object to the trimmed-surface itself.
Does it have a different object ID? If so, then perhaps this should be "fixed" so that it resolves to the same object.
On Feb 8, 2013, at 11:27 AM, reiniervandijk <notifications@github.com> wrote:
> It this logical? the trimmed-surface is a face. It's basis-surface is obviously potentially bigger that the trimmed region. However, the brep of the object has another face, this face on it's turn has a basis-surface. But, that one is exactly the same. And so we can go on to the next brep in the tree and again and again. Is this behavior as marketed?
>
> —
> Reply to this email directly or view it on GitHub..
>
*By genworks on 2015-01-30 22:55:24 UTC*
Moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/94stack overflow on brep :edges-sequence message2015-03-31T02:17:04ZDave Cooperstack overflow on brep :edges-sequence message*Created by: reiniervandijk*
stack overflow on brep :edges-sequence message.
Try:
```lisp
(define-object stitching-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(clean-surfaces ...*Created by: reiniervandijk*
stack overflow on brep :edges-sequence message.
Try:
```lisp
(define-object stitching-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(clean-surfaces :type 'surface
:sequence (:size 6)
:built-from (the box (faces (the-child index)) :basis-surface))
(stitched :type 'stitched-solid :faces-in (list-elements (the clean-surfaces)))
(stitched-alternative :type 'stitched-solid :faces-in (list-elements (the box :faces) (the-element :basis-surface)))
(stitched-manifold :type 'manifold-solid :brep (the stitched))
)
)
```
And visualize for example
```lisp
(the (clear-surfaces 0) :brep :edges-sequence)
```
**Imported comments:**
*By genworks on 2015-01-30 01:28:43 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/93dependency tracking not working properly?2015-03-31T02:17:03ZDave Cooperdependency tracking not working properly?*Created by: reiniervandijk*
Consider these two objects:
```lisp
(define-object test ()
:computed-slots
((a 0)
(b (prog1 (the a)
(the (set-slot! :a (+ (the a) 1)))))))
(define-object test2 ()
:computed-slots
((a...*Created by: reiniervandijk*
Consider these two objects:
```lisp
(define-object test ()
:computed-slots
((a 0)
(b (prog1 (the a)
(the (set-slot! :a (+ (the a) 1)))))))
(define-object test2 ()
:computed-slots
((a 0)
(b (prog1 (the a)
(the (set-slot! :c (+ (the a) 1)))))
(c 2)))
```
In the first case, the dependency of :b to :a is lost. In the latter case, it still works. This seems an issue or please explain why it isn't. I encountered this when I tried to make a computed-slot in the tasty inspector remain :unbound forever, as to imitate a function that runs on every click again and again.
```lisp
> (make-self 'test)
#<test @ #x24d54b5a>
> (the a)
0
> (the b)
0
> (the a)
1
> (the (set-slot! :a 33))
nil
> (the (slot-status :b))
:evaluated
> (make-self 'test2)
#<test2 @ #x24d9c422>
> (the a)
0
> (the b)
0
> (the c)
1
> (the (set-slot! :a 33))
nil
> (the (slot-status :b))
:unbound
```
**Imported comments:**
*By genworks on 2013-02-12 15:22:16 UTC*
It is not, has never been, and probably never will be supported to call
set-slot! from within the body of a cached computed-slot.
This issue will remain open until this "feature" is better documented or
maybe even protected against by the compiler.
On Tue, Feb 12, 2013 at 10:03 AM, reiniervandijk
<notifications@github.com>wrote:
> Consider these two objects:
>
> (define-object test ()
> :computed-slots
> ((a 0)
> (b (prog1 (the a)
> (the (set-slot! :a (+ (the a) 1)))))))
> (define-object test2 ()
> :computed-slots
> ((a 0)
> (b (prog1 (the a)
> (the (set-slot! :c (+ (the a) 1)))))
> (c 2)))
>
> In the first case, the dependency to a is lost. In the latter case, it
> still works. This seems an issue or please explain why it isn't.
>
> move> (make-self 'test)#<test @ #x24d54b5a>> (the a)0> (the b)0> (the a)1> (the (set-slot! :a 33))nil> (the (slot-status :b)):evaluatedmove> (make-self 'test2)
> #<test2 @ #x24d9c422>> (the a)0> (the b)0> (the c)1> (the (set-slot! :a 33))nil> (the (slot-status :b)):unbound
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/75>.
>
>
--
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-02-12 15:40:58 UTC*
This answer is clear, but not really addressing the issue pointed out here. Then please consider
```
(define-object test3 ()
:functions
((foo
()
(the (set-slot! :a (+ (the a) 1)))))
:computed-slots
((a 0)
(b (prog1 (the a)
(the foo)))))
```
and try the same. If I read you correctly, a function is allowed to set-slot! something. I know we use it often here.
*By genworks on 2013-02-12 16:04:49 UTC*
Let's be more general here: it is not supported to do side-effecting within
the body of a cached computed-slot.
The above form implies a side-effect by calling (the foo), which is a
side-effecting function (because itself calls set-slot!), within the body
of the computed slot.
One practical effect of this is that it never makes sense to use progn,
prog1, etc in the body of a computed-slot. The computed slot is intended to
contain exactly one expression, and only to use the return-value of that
expression, and without side-effects. Although in the above example, even
without the prog1, if it were just
```
...
:computed-slots
((a 0)
(b (the foo)))
```
the principle would be violated because (the foo) is a side-effecting
function being called from within the body of a computed-slot.
On Tue, Feb 12, 2013 at 10:40 AM, reiniervandijk
<notifications@github.com>wrote:
> This answer is clear, but not really addressing the issue pointed out
> here. Then please consider
>
> (define-object test3 ()
>
> :functions
> ((foo
> ()
> (the (set-slot! :a (+ (the a) 1)))))
>
> :computed-slots
> ((a 0)
> (b (prog1 (the a)
> (the foo)))))
>
> and try the same. If I read you correctly, a function is allowed to
> set-slot! something. I know we use it often here.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/75#issuecomment-13438267>.
>
>
--
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-02-12 16:32:48 UTC*
Alright. Do you feel this (rather important) aspect is clearly documented somewhere? It basically defines the main paradigm behind programming slots.
*By genworks on 2013-02-12 21:12:02 UTC*
It definitely needs to be documented in the new tutorial.pdf.
Moreover, your second example (with the indirect call to set-slot!) could never be picked up at compile-time. But, it will be possible to add a low-cost runtime check which will throw an error if an operation like this is attempted.
This Issue will remain open until the documentation is made clear, and the runtime check is in place.
On Feb 12, 2013, at 9:32 AM, reiniervandijk <notifications@github.com> wrote:
> Alright. Do you feel this (rather important) aspect is clearly documented somewhere? It basically defines the main paradigm behind programming slots.
>
> —
> Reply to this email directly or view it on GitHub.
>
*By genworks on 2013-02-18 19:46:03 UTC*
The development version of Gendl now throws a runtime Warning if a set-slot! is attempted anywhere (dynamically) from within the body of a cached slot.
Any opinion on whether this should be an Error instead of a Warning? Or it could be configurable between Error and Warning using a parameter such as *cached-side-effecting-behavior* (possible values of :warn, :error, or nil).
*By reiniervandijk on 2013-02-18 21:40:05 UTC*
The latter option would be best. Default to :error perhaps (because it's not supported) and give error message with cause and solution approach. Maybe also a explanation of how to set this setting in gdlinit. Are you not also using side-effecting in GWL base-ajax sheet, to register sheet-sections? In that case don't forget to locally bind parameter value to nil...
Verstuurd vanaf mijn iPad
Op 18 feb. 2013 om 20:46 heeft Dave Cooper <notifications@github.com> het volgende geschreven:
> The development version of Gendl now throws a runtime Warning if a set-slot! is attempted anywhere (dynamically) from within the body of a cached slot.
>
> Any opinion on whether this should be an Error instead of a Warning? Or it could be configurable between Error and Warning using a parameter such as cached-side-effecting-behavior (possible values of :warn, :error, or nil).
>
> —
> Reply to this email directly or view it on GitHub.
>
*By genworks on 2013-04-11 23:15:57 UTC*
In current codebase and currently released Genworks-GDL 1582 release candidate, this is Warning and not an Error. We have started receiving feedback from the field on it. For safety sake we will consider changing the default to be an Error, after most existing codebase have had a chance to be audited for the Warnings. The issue remains open until it is documented.
*By genworks on 2013-04-11 23:17:32 UTC*
The current version also allows for a keyword argument for set-slot of :warn-on-non-toplevel?
This defaults to t but if you have a case which you know is benign, you can do
(the ... (set-slot! ... :warn-on-non-toplevel? nil))
*By genworks on 2013-04-11 23:20:22 UTC*
One case where this is probably benign is when the bashee is in a separate tree (e.g. constructed with a raw make-object rather than as child :object). The runtime machinery can probably be made to detect these cases and automatically suppress the warning. But for the time being it will be necessary to use the :warn-on-non-toplevel? nil keyword argument in order to suppress warnings in these cases.
Note that the :warn-on-non-toplevel? keyword argument is not documented and subject to change, so any use of it in production code should be flagged.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/92merge-display-control on self2023-01-31T13:04:11ZDave Coopermerge-display-control on self*Created by: reiniervandijk*
Consider:
```lisp
(define-object color-test (base-object)
:computed-slots
((display-controls (list :color :red)))
:objects
((box1 :type 'box-solid :width 1 :length 1 :height 1
:displ...*Created by: reiniervandijk*
Consider:
```lisp
(define-object color-test (base-object)
:computed-slots
((display-controls (list :color :red)))
:objects
((box1 :type 'box-solid :width 1 :length 1 :height 1
:display-controls (merge-display-controls (list :transparency 0.5)))
(box2 :type 'box-solid :width 1 :length 1 :height 1
:display-controls (merge-display-controls (list :color :blue)))))
```
Now, I would expect that my box1 would merge the color of self (:red) with a new transparency, instead it will look for the parent that obviously does not exists in the context of color-test, hence losing color information. Why not actually use self instead of parent?
**Imported comments:**
*By genworks on 2013-02-18 19:40:20 UTC*
The issue with using self is if you have
...
:computed-slots
((display-controls (merge-display-controls (list :color :red))))
...
then you end up with a circularity.
I guess the question is whether display-controls is more likely to be specified as a computed-slot in the current object, or as an input to a child object.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/91Connection to Emacs lost2016-11-02T23:49:06ZDave CooperConnection to Emacs lost*Created by: reiniervandijk*
Occasionally, the connection of the lisp console to Emacs goes lost. Hard to replicate. For me it happened during compilation of a file and having Tasty open with reasonably sized X3D model.
```lisp
disp...*Created by: reiniervandijk*
Occasionally, the connection of the lisp console to Emacs goes lost. Hard to replicate. For me it happened during compilation of a file and having Tasty open with reasonably sized X3D model.
```lisp
dispatch-event: (:return #<multiprocessing:process worker @ #x29772fc2> (:ok "t") 1504)
encode-message
decode-message
dispatch-event: (:emacs-rex (swank:autodoc (quote ()) <User Code> swank::%cursor-marker%))) :print-right-margin 155) ":move" t 1505)
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-02-18 19:41:53 UTC*
We are going to upgrade to the latest swank/slime in the next release (by end of this month, including full Enterprise 1582), and see if this continues to be an issue.
This Issue will remain open until the problem is clearly resolved.
In the meantime be aware that the Franz ELI is always available as an alternative to Slime - with packaged Gendl releases you can start ELI with
M-x gdl
instead of
M-x gendl
https://gitlab.common-lisp.net/gendl/gendl/-/issues/89cad-assembly not external in surf package2015-03-31T02:17:01ZDave Coopercad-assembly not external in surf package*Created by: reiniervandijk*
It's documented, visible in YADD, but not external? Isn't that contradicting?
**Imported comments:**
*By genworks on 2015-01-30 01:27:18 UTC*
It's still not officially supported, therefore unexported. *Created by: reiniervandijk*
It's documented, visible in YADD, but not external? Isn't that contradicting?
**Imported comments:**
*By genworks on 2015-01-30 01:27:18 UTC*
It's still not officially supported, therefore unexported. https://gitlab.common-lisp.net/gendl/gendl/-/issues/88[experimental] assembly-import misses object names2015-03-31T02:17:01ZDave Cooper[experimental] assembly-import misses object names*Created by: reiniervandijk*
When importing a step file, names for points and curves are properly extracted. However, names for breps (i.e. advanced-faces / open-shells in STEP) are not captured. Is this hard-coded on Gendl side or is i...*Created by: reiniervandijk*
When importing a step file, names for points and curves are properly extracted. However, names for breps (i.e. advanced-faces / open-shells in STEP) are not captured. Is this hard-coded on Gendl side or is it the SMLib reader that doesn’t extract that info?
It would be quite nice to have the breps names showing up properly, because I need that level of semantics to select the correct objects in a tree.
**Imported comments:**
*By genworks on 2015-01-30 01:24:40 UTC*
moved to internal tracking list.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/81check-continuity function on curve2015-03-31T02:16:59ZDave Coopercheck-continuity function on curve*Created by: reiniervandijk*
This returns nils, not expected.
```lisp
(define-object continuity-sample (base-object)
:input-slots
((curves (list (the default-1) (the default-2))))
:objects
((default-1 :type 'linear-c...*Created by: reiniervandijk*
This returns nils, not expected.
```lisp
(define-object continuity-sample (base-object)
:input-slots
((curves (list (the default-1) (the default-2))))
:objects
((default-1 :type 'linear-curve :start (the center) :end (translate (the center) :right 10))
(default-2 :type 'linear-curve :start (the default-1 :end) :end (translate (the-child :start) :right 5 :rear 5))
(curve :type 'composed-curve :pass-down (curves))
)
)
```
in REPL:
```
> (the check-continuity)
(:distance nil :angle 0.7853981633974484 :length nil)
```
**Imported comments:**
*By genworks on 2015-01-30 01:11:48 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/80rational/integer number gives error in extended-curve object2015-03-31T02:16:59ZDave Cooperrational/integer number gives error in extended-curve object*Created by: reiniervandijk*
Try 1/3 value or try 1.
```lisp
(define-object extended-curve-sample2 ()
:input-slots
((distance 1/3 :settable))
:objects
((b-spline-curve :type 'arc-curve
:center (make-point 0 0 0...*Created by: reiniervandijk*
Try 1/3 value or try 1.
```lisp
(define-object extended-curve-sample2 ()
:input-slots
((distance 1/3 :settable))
:objects
((b-spline-curve :type 'arc-curve
:center (make-point 0 0 0)
:radius 1.5
:start-angle 0
:end-angle pi)
(extended-curve-G2 :type 'extended-curve
:curve-in (the b-spline-curve)
:distance (the distance)
:distance-type :relative
:continuity :g2
:display-controls (list :color :red))))
**Imported comments:**
*By genworks on 2015-01-30 01:10:58 UTC*
moved to internal tracking list.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/79write-snapshot doesn't work2015-03-31T02:16:58ZDave Cooperwrite-snapshot doesn't work*Created by: reiniervandijk*
``` lisp
(define-object write-snapshot-test (base-object)
:input-slots
((a 2 :settable))
)
```
Then try:
```lisp
gdl-user> (make-self 'write-snapshot-test :a 5)
#<write-snapshot-test @ #...*Created by: reiniervandijk*
``` lisp
(define-object write-snapshot-test (base-object)
:input-slots
((a 2 :settable))
)
```
Then try:
```lisp
gdl-user> (make-self 'write-snapshot-test :a 5)
#<write-snapshot-test @ #x23b5f4aa>
gdl-user> (the (write-snapshot :filename "D:/test.gdl"))
; No value
```
And the output is according to:
```lisp
(in-package :gdl-user)
(write-snapshot-test)
```
**Imported comments:**
*By genworks on 2013-03-06 17:47:32 UTC*
This is fixed in github. Use the following to preview the fix:
```common-lisp
(in-package :gdl)
(excl:without-package-locks
(define-object-amendment vanilla-mixin* ()
:functions
((active-inputs
()
(let ((inputs (append (the (message-list :category :optional-input-slots))
(the (message-list :category :settable-optional-input-slots))
(the (message-list :category :settable-defaulted-input-slots))
(the (message-list :category :required-input-slots))
(the (message-list :category :defaulted-input-slots)))) result)
(mapc #'(lambda (slot)
(let ((contents (funcall (read-from-string (format nil "gdl-acc::~a" slot)) self)))
(when (and (not (member slot '(:%name% :%parent% :%aggregate% :%index% :$$tatu-object)))
(consp contents) (third contents))
(push slot result) (push (readable-expression (first contents) self) result)))) inputs)
(nreverse result))))))
```
https://gitlab.common-lisp.net/gendl/gendl/-/issues/77approximated curve not working2015-03-31T02:16:58ZDave Cooperapproximated curve not working*Created by: reiniervandijk*
Try the default example object approximated-curve-test and find the error:
!! This section threw error: iwcurve_approximatecurve failed. !!
**Imported comments:**
*By genworks on 2013-03-08 17:33:...*Created by: reiniervandijk*
Try the default example object approximated-curve-test and find the error:
!! This section threw error: iwcurve_approximatecurve failed. !!
**Imported comments:**
*By genworks on 2013-03-08 17:33:09 UTC*
This is a long-standing issue and will be fixed asap in our new release, which will include SMLib 8.6.1 (the current release has 8.5.1 which is now just about a year old, and has had recurring issues with approximated-curve).
*By reiniervandijk on 2013-03-08 17:37:51 UTC*
Okay. If these are long-term issues, where can a user find them? This
object is available in the YADD documentation without any side-notes.
Moreover, it worked for previous releases.
2013/3/8 Dave Cooper <notifications@github.com>
> This is a long-standing issue and will be fixed asap in our new release,
> which will include SMLib 8.6.1 (the current release has 8.5.1 which is now
> just about a year old, and has had recurring issues with
> approximated-curve).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/91#issuecomment-14632471>
> .
>https://gitlab.common-lisp.net/gendl/gendl/-/issues/75stack overflow with-format vrml2023-01-31T13:04:11ZDave Cooperstack overflow with-format vrml*Created by: reiniervandijk*
```lisp
(gdl::with-format (vrml \"/tmp/box.vrml\")
(write-the-object (make-instance 'box :length 100 :width 100 :height 100) cad-output))
```
**Imported comments:**
*By genworks on 2013-03-09 17:45...*Created by: reiniervandijk*
```lisp
(gdl::with-format (vrml \"/tmp/box.vrml\")
(write-the-object (make-instance 'box :length 100 :width 100 :height 100) cad-output))
```
**Imported comments:**
*By genworks on 2013-03-09 17:45:24 UTC*
This is user error but for sure we can give a better error message, so it can still be considered a bug.
The user error is that in Gendl, GDL objects need `make-object` rather than the standard CLOS `make-instance` in order to behave as expected.
Two ways of handling this - we might be able to customize the `make-instance` behavior for class definitions with meta-class `gdl-class` (this has been tried in the past and we ran into complications, but can look at it again) --- or at least we should give a clear error message when normal `make-instance` is called on these definitions. So this Issue will remain open until resolved in one of these ways.
In the meantime a working version of the example would be:
```common-lisp
(with-format (vrml "/tmp/box.vrml")
(write-the-object (make-object 'box :length 100 :width 100 :height 100) cad-output))
```
The style notes from Issue #92 also apply. If you were to call this from a package not defined with gdl:define-package or gwl:define-package, the correct symbol package prefixes would look like this (note the exclusive use of single-colons):
```common-lisp
(gdl:with-format (geom-base:vrml "/tmp/box.vrml")
(gdl:write-the-object (gdl:make-object 'geom-base:box :length 100 :width 100 :height 100) cad-output))
```
Note that the output-function `cad-output` behaves like any normal message name in Gendl, and does not need any package prefix because message names are immune to package. If you want to avoid "polluting" the current `*package*` with the symbol `cad-output` then you can use the keyword package, and write `:cad-output`, with the same effect (this still "pollutes" the keyword package with the symbol "cad-output" but according to many folks, that's what the keyword package is there for in the first place).https://gitlab.common-lisp.net/gendl/gendl/-/issues/73list-of-numbers influenced by tolerances2015-03-31T02:16:56ZDave Cooperlist-of-numbers influenced by tolerances*Created by: reiniervandijk*
The current implementation of list-of-numbers is naive and leads to several complications. Consider:
```lisp
(setq u1 8.875776655249117e-4)
(setq u2 3.7043572627844927)
(setq lst (list-of-numbers u1 u2...*Created by: reiniervandijk*
The current implementation of list-of-numbers is naive and leads to several complications. Consider:
```lisp
(setq u1 8.875776655249117e-4)
(setq u2 3.7043572627844927)
(setq lst (list-of-numbers u1 u2 (/ (- u2 u1) (1- 100))))
```
Now you would assume the list-of-numbers to have a length of 100, since I defined the step size like that. However:
```lisp
> (length lst)
99
```
This is due to tolerances, I understand. However, now consider the function equi-spaced-points in the curve object. You provide a number of points, say 100. Since the internal code uses the aforementioned method to calculate all (assumingly) 100 parametric values in the range of u1 - u2, it actually returns 99 points. This gave me errors, because I anticipated the same number of points that I've asked for.
Looking at body of list-of-numbers, erroneous line is:
```lisp
(dotimes (i (1+ (floor (/ (- num2 num1) increment))) ...
```
Because this gives:
```lisp
> (/ (- u2 u1) (/ (- u2 u1) (1- 100)))
98.99999999999999
```
Documentation of list-of-numbers says: "Returns a list of incrementing numbers starting from
num1 and ending with num2, inclusive." That's actually not true, as shown.
**Imported comments:**
*By reiniervandijk on 2013-03-11 12:35:55 UTC*
Proposed fix:
```lisp
(defun list-of-numbers (num1 num2 &optional (increment 1) (tolerance (/ increment 10)))
"List of Numbers. Returns a list of incrementing numbers starting from
<b>num1</b> and ending with <b>num2</b>, inclusive.
:arguments (num1 \"Number\"
num2 \"Number\")
:&optional ((increment 1) \"Number. The distance between the returned listed numbers.\")"
(cond ((= increment 0.0) (error "increment of zero is not allowed"))
((and (< increment 0.0) (> num2 num1)) (error "increment is negative, while difference between num2 and num1 is positive."))
((and (> increment 0.0) (< num2 num1)) (error "increment is positive, while difference between num2 and num1 is negative."))
(t (let ((predicate (if (> increment 0.0) #'>= #'<=))
(result-list nil))
(do ((num num1 (+ num increment)))
((or (funcall predicate num num2) (< (abs (- num2 num)) tolerance)) (nreverse (cons num2 result-list)))
(push num result-list))))))
```
*By reiniervandijk on 2015-02-18 17:16:11 UTC*
This fix is now pending for almost two years and has manifested itself again in student code while working with the MMG. Is this issue representative indicative for the speed with which user-contributions are merged into the language? If so, we, TUD, will manage our own set of fixes to the language that we will circulate among students.
*By reiniervandijk on 2015-02-18 17:17:02 UTC*
Another contribution to the language (name of the function can be subject to change):
```lisp
(defun list-of-n-numbers (num1 num2 n)
"returns a list of n numbers between bounds num1 and num2. Bounds are inclusive"
(let ((increment (/ (- num2 num1) (- n 1)))
(result-list nil))
(dotimes (i (- n 1) (nreverse (cons num2 result-list)))
(push (+ num1 (* i increment)) result-list))))
```
*By genworks on 2015-02-20 03:32:26 UTC*
The fixes will be rolled into next major release, slated for January 2016, including clear release notes. This will not be included in an interim patch, due to risk of breaking existing code (even though the current function indeed can produce incorrect results, some production applications may be depending on these results).
Indeed, applications which require the fixed behavior can and should carry the code for the fix locally, which code can be retired when it moves to the next major release which includes the fix.
*By genworks on 2015-02-20 03:33:35 UTC*
The issue will be closed when it is committed into current development work-in-progress. Work-in-progress builds are also expected to be made available between now and January 2016.
*By genworks on 2015-03-18 20:09:07 UTC*
updated list-of-numbers and list-of-n-numbers have been rolled into current "devo" branch. https://gitlab.common-lisp.net/gendl/gendl/-/issues/72equi-spaced-points affected by list-of-numbers2015-03-31T02:16:56ZDave Cooperequi-spaced-points affected by list-of-numbers*Created by: reiniervandijk*
while previous issue is worth an issue on itself, for sake of completeness I list this issue here as well. See issue #95.
**Imported comments:**
*By genworks on 2015-01-30 22:52:43 UTC*
merged with #96.*Created by: reiniervandijk*
while previous issue is worth an issue on itself, for sake of completeness I list this issue here as well. See issue #95.
**Imported comments:**
*By genworks on 2015-01-30 22:52:43 UTC*
merged with #96.https://gitlab.common-lisp.net/gendl/gendl/-/issues/71gdlAjax does not restore after session timeout2015-03-31T02:16:55ZDave CoopergdlAjax does not restore after session timeout*Created by: genworks*
Normally a session should be able to auto-save its snapshot file and restore transparently if the session has expired and a new request comes in for that session. We have to enable this functionality in gdlAjax.
...*Created by: genworks*
Normally a session should be able to auto-save its snapshot file and restore transparently if the session has expired and a new request comes in for that session. We have to enable this functionality in gdlAjax.
**Imported comments:**
*By genworks on 2015-01-30 01:03:33 UTC*
Open for submissions: $100.