gendl issueshttps://gitlab.common-lisp.net/gendl/gendl/-/issues2023-01-31T13:02:24Zhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/10VRML scene redraw on geometry click2023-01-31T13:02:24ZDave CooperVRML scene redraw on geometry click*Created by: reiniervandijk*
When visualizing geometry in VRML format through BS Contact plugin: any click on geometry, including right-clicks, lead to complete regeneration of VRML scene.
**Imported comments:**
*By genworks on 2015...*Created by: reiniervandijk*
When visualizing geometry in VRML format through BS Contact plugin: any click on geometry, including right-clicks, lead to complete regeneration of VRML scene.
**Imported comments:**
*By genworks on 2015-01-29 21:25:26 UTC*
Opening this up for submission. $200-300. Requires full regression tests using net.aserve.client:do-http-request to simulate browser actions. If possible, tests should be in the style of the tests in gendl/regression/source/ and e.g. gendl/regression/geom-base/source/angle-between-vectors.lisp, so they can be run in automated fashion and the output captured in the regression-test-data slot.
Notes: VRML output should be deprecated and removed from tasty/ta2 etc.
This behavior should be checked and fixed if necessary for X3D and X3DOM output in ta2 and tasty. GDL should standardize on these two output formats, clean them up, verify, document them, and retire VRML format.https://gitlab.common-lisp.net/gendl/gendl/-/issues/9Unable to run Gendl after installing to home directory using Quicklisp2015-03-31T02:16:28ZDave CooperUnable to run Gendl after installing to home directory using Quicklisp*Created by: ackalker*
Using SBCL 1.2.7 (out today, yay!) on Arch Linux, I've managed to install Gendl using Quicklisp (version 2014-12-17, which is installed in my home directory under `~/quicklisp`).
However, I am getting an error wh...*Created by: ackalker*
Using SBCL 1.2.7 (out today, yay!) on Arch Linux, I've managed to install Gendl using Quicklisp (version 2014-12-17, which is installed in my home directory under `~/quicklisp`).
However, I am getting an error when I try to start it.
The steps I've taken come directly from `README.md`:
```lisp
(ql:quickload :gendl)
(gendl:start-gendl!)
```
The first step installs gendl without any apparent problems, but evaluating `(gendl:start-gendl!)` signals the following error:
```
The value NIL
is not of type
(OR (VECTOR CHARACTER) (VECTOR NIL) BASE-STRING PATHNAME
STREAM).
[Condition of type TYPE-ERROR]
Restarts:
0: [RETRY] Retry SLY mREPL evaluation request.
1: [*ABORT] Return to SLY's top level.
2: [ABORT] Abort thread (#<THREAD "sly-channel-1-mrepl-remote-1" RUNNING {1005A92A23}>)
Backtrace:
0: (OPEN NIL) [more,optional]
1: (GENDL::QUICKLISP-COPYRIGHT-STRING)
2: (GENDL::STARTUP-BANNER)
3: (START-GENDL! :FEATURES NIL :BANNER? T :INIT-FILES? T)
4: (SB-INT:SIMPLE-EVAL-IN-LEXENV (START-GENDL!) #<NULL-LEXENV>)
5: (EVAL (START-GENDL!))
[...]
```
As far as I can tell, my Quicklisp installation is working well, i.e. I can use `(ql:quickload :something)` to install other libraries just fine.
EDIT:
From poking around in the debugger, it appears that the form which signals the error is in `~/quicklisp/dists/quicklisp/software/gendl-20141217-git/base/source/start.lisp`:
```lisp
(with-open-file (in (or (probe-file
(merge-pathnames "quicklisp/dists/quicklisp/distinfo.txt"
glisp:*gdl-home*))
(probe-file
(merge-pathnames "quicklisp/dists/quicklisp/distinfo.txt"
glisp:*genworks-source-home*))))
(read-line in)
(string-trim (list #\space) (second (glisp:split-regexp ":" (read-line in)))))
```
Evaluating some tests in this frame, i find that both `probe-file` forms evaluate to NIL. Looking a bit closer to find out why, I find:
```lisp
(merge-pathnames "quicklisp/dists/quicklisp/distinfo.txt"
glisp:*gdl-home*)
;; => #P"/usr/lib/quicklisp/dists/quicklisp/distinfo.txt"
```
This file does not exist (I'm not installing system-wide).
```lisp
(merge-pathnames "quicklisp/dists/quicklisp/distinfo.txt"
glisp:*genworks-source-home*)
;; => #P"/home/miki/quicklisp/dists/quicklisp/software/quicklisp/dists/quicklisp/distinfo.txt"
```
Finally, `glisp:*genworks-source-home*` is bound to: `#P"/home/miki/quicklisp/dists/quicklisp/software/"`.
Ah, here is where the problem appears to be: the pathnames don't merge correctly :-)
**Imported comments:**
*By ackalker on 2015-01-01 14:42:14 UTC*
Quick hackedyhack fix, replace:
```lisp
(merge-pathnames "quicklisp/dists/quicklisp/distinfo.txt"
glisp:*genworks-source-home*)
```
with
```lisp
(merge-pathnames "../distinfo.txt"
glisp:*genworks-source-home*)
```
and recompile. This made the simple test of visiting http://localhost:9000/tasty work for me.
Happy New Year!
*By genworks on 2015-01-15 01:03:00 UTC*
Dear ackalker,
Thank you for looking into this! A similar fix to yours has been pushed and should get picked up in the next Quicklisp.
Thanks again,
The Gendl team
*By ackalker on 2015-01-15 04:28:13 UTC*
You're welcome :-)https://gitlab.common-lisp.net/gendl/gendl/-/issues/8angle-between-vectors does not handle tolerance inputs correctly2015-03-31T02:16:27ZDave Cooperangle-between-vectors does not handle tolerance inputs correctly*Created by: reiniervandijk*
Function ``angle-between-vectors`` has a keyword argument ``(epsilon *zero-epsilon*)`` to give the user control over how small of an angle is considered to be zero. However, the implementation of the code is...*Created by: reiniervandijk*
Function ``angle-between-vectors`` has a keyword argument ``(epsilon *zero-epsilon*)`` to give the user control over how small of an angle is considered to be zero. However, the implementation of the code is such that ``epsilon`` has effectively not effect. Replicate using:
```lisp
gdl-user> (angle-between-vectors (make-vector 1 0 0) (make-vector 1 0.05 0) (make-vector 0 0 1))
0.049958395721943306
gdl-user> (angle-between-vectors (make-vector 1 0 0) (make-vector 1 0.04 0) (make-vector 0 0 1))
0.0
gdl-user> (angle-between-vectors (make-vector 1 0 0) (make-vector 1 0.04 0) (make-vector 0 0 1) :epsilon 1e-9)
0.0
gdl-user>
```
**Imported comments:**
*By reiniervandijk on 2015-01-30 12:44:31 UTC*
The fix to this issue is:
```lisp
(in-package :geom-base)
(defun unitize-vector (vector &key (epsilon *zero-epsilon*)) ;; FIX: extra epsilon
"Unit Vector. Returns the normalized unit-length vector corresponding to <b>vector</b>.
:arguments (vector \"3D Vector\")"
(when (and *zero-vector-checking?* (zero-vector? vector))
(error "~s has Euclidean length zero; cannot unitize." vector))
(if (near-to? (length-vector vector) 1.0 epsilon) ;; FIX: extra epsilon
vector
(scalar*vector (/ (length-vector vector)) vector)))
(defun angle-between-vectors (vector-1 vector-2 &optional reference-vector &key (epsilon *zero-epsilon*) -ve)
"Number. Returns the angle in radians between <b>vector-1</b> and <b>vector-2</b>.
If no <b>reference-vector</b> given, the smallest possible angle is returned.
If a <b>reference-vector</b> is given, computes according to the right-hand rule.
If <b>-ve</b> is given, returns a negative number for angle if it really is
negative according to the right-hand rule.
:arguments (vector-1 \"3D Vector\"
vector-2 \"3D Vector\")
:&optional ((reference-vector nil) \"3D Vector\")
:&key ((epsilon *zero-epsilon*) \"Number. Determines how small of an angle is considered to be zero.\"
(-ve nil) \"Boolean\")"
(let ((vector-1 (unitize-vector vector-1 :epsilon epsilon))
(vector-2 (unitize-vector vector-2 :epsilon epsilon)))
(let ((dot-vector (dot-vectors vector-1 vector-2)))
(when (> dot-vector 1.0d0) (setq dot-vector 1.0d0))
(when (< dot-vector -1.0d0) (setq dot-vector -1.0d0))
(let ((smallest-angle (acos dot-vector)))
(when (< smallest-angle epsilon) (setq smallest-angle 0.0d0))
(let ((try (if (and reference-vector
(minusp (dot-vectors reference-vector (cross-vectors vector-1 vector-2))))
(- (twice pi) smallest-angle)
smallest-angle)))
(if (and -ve (> try pi)) (- try (twice pi)) try))))))
```
Now try:
```lisp
gdl-user> (angle-between-vectors (make-vector 1 0 0) (make-vector 1 0.05 0) (make-vector 0 0 1))
0.049958395721943306
gdl-user> (angle-between-vectors (make-vector 1 0 0) (make-vector 1 0.04 0) (make-vector 0 0 1))
0.0
gdl-user> (angle-between-vectors (make-vector 1 0 0) (make-vector 1 0.04 0) (make-vector 0 0 1) :epsilon 1e-9)
0.03997868712329394
```
*By genworks on 2015-03-11 23:41:29 UTC*
Merged and committed into devo branch. https://gitlab.common-lisp.net/gendl/gendl/-/issues/7define-object-amendment does not check for reserved words override2015-03-31T02:16:27ZDave Cooperdefine-object-amendment does not check for reserved words override*Created by: reiniervandijk*
Macro ``define-object-amendment`` does not check for override of reserved words. Hence, a user can naively break gendl completely by doing something like.
```lisp
(define-object foo ())
```
And then:...*Created by: reiniervandijk*
Macro ``define-object-amendment`` does not check for override of reserved words. Hence, a user can naively break gendl completely by doing something like.
```lisp
(define-object foo ())
```
And then:
```lisp
(define-object-amendment foo ()
:computed-slots
((parent nil)))
```
**Imported comments:**
*By genworks on 2015-01-30 22:30:13 UTC*
Merged with #158. https://gitlab.common-lisp.net/gendl/gendl/-/issues/6YADD documentation error2018-02-21T03:26:53ZDave CooperYADD documentation error*Created by: reiniervandijk*
For user-defined functions, objects, etc, that I document and that I want to visualize inside YADD. I get the following error:
```lisp
[aserve] 13-aserve-worker: 02/01/15 - 11:40:59 - while processing ...*Created by: reiniervandijk*
For user-defined functions, objects, etc, that I document and that I want to visualize inside YADD. I get the following error:
```lisp
[aserve] 13-aserve-worker: 02/01/15 - 11:40:59 - while processing command "GET /assy/geom-base/function-docs/translate.html HTTP/1.1"
got the error Nothing appears after . in list. [file position = 63]
```
The example in my case for replication:
```lisp
(in-package :geom-base)
(defmacro translate (origin direction offset &rest more-translations)
"[Macro] 3D Point. Within the context of a GDL object definition (i.e. a <tt>define-object</tt>),
translate <b>origin</b> by <b>offset</b> over <b>direction</b>. More direction-offset combinations
can be specified in <b>more-translations</b>.
:arguments (origin \"3D Point\"
direction \"keyword. A direction keyword can be one of:
<ul><li><tt>:top</tt> (or <tt>:up</tt>)</li>
<li><tt>:bottom</tt> (or <tt>:down</tt>)</li>
<li><tt>:left</tt></li>
<li><tt>:right</tt></li>
<li><tt>:front</tt></li>
<li><tt>:rear</tt> (or <tt>:back</tt>)</li></ul>.\"
offset \"number. Distance to translate along offset.\")
:&rest (offsets \"Plist consisting of direction keywords and numbers.\")"
(if more-translations
;; recurse
`(translate (translate-along-vector ,origin
(the (:face-normal-vector (ecase ,direction
((:up :top) :top)
((:down :bottom) :bottom)
(:left :left)
(:right :right)
(:front :front)
((:rear :back) :rear))))
,offset)
,@more-translations)
;; don't recurse
`(translate-along-vector ,origin
(the (:face-normal-vector (ecase ,direction
((:up :top) :top)
((:down :bottom) :bottom)
(:left :left)
(:right :right)
(:front :front)
((:rear :back) :rear))))
,offset)))
```
Perhaps it's because at the moment of writing I don't have access to my H: directory, which Gendl takes as the HOME directory for placing temporary files or something? If that's the case (I remember something similar with the boostrapping process), perhaps don't make this assumption inside YADD code and write work-arounds?https://gitlab.common-lisp.net/gendl/gendl/-/issues/5Too many active WebGL contexts.2018-02-21T03:26:53ZDave CooperToo many active WebGL contexts.*Created by: reiniervandijk*
As Gendl is simply regenerating a new X3DOM context on each model update inside Tasty, there is a lot of memory building up. The browser complains after a while:
```
WARNING: Too many active WebGL contex...*Created by: reiniervandijk*
As Gendl is simply regenerating a new X3DOM context on each model update inside Tasty, there is a lot of memory building up. The browser complains after a while:
```
WARNING: Too many active WebGL contexts. Oldest context will be lost.
x3dom.js:562 WARNING: Too many active WebGL contexts. Oldest context will be lost.
```
From performance point of view, it would be wiser to not regenerate a new context every time, but to replace the inner contents of the X3DOM context instead.https://gitlab.common-lisp.net/gendl/gendl/-/issues/4uv-curve not correct2015-03-31T02:16:26ZDave Cooperuv-curve not correct*Created by: reiniervandijk*
Given the iwp file attached in separate e-mail (can't upload in this message dialog), take out the brep and visualize if you need to. Take ``(edges 2)`` or the middle airfoil, confirm that it's on 2 faces, a...*Created by: reiniervandijk*
Given the iwp file attached in separate e-mail (can't upload in this message dialog), take out the brep and visualize if you need to. Take ``(edges 2)`` or the middle airfoil, confirm that it's on 2 faces, and demand the ``uv-curve`` on the first face. Now observe that the curve has a very weird progression in uv-space and start+end points are overlapping, which is impossible. Can you replicate this case and give feedback ASAP, because this is halting a student's graduation work. Thanks.
```lisp
(make-self 'native-reader :file-name "some/path")
(setq brep (the (breps 0)))
(setq crv (the-object brep (edges 2) (uv-curve (the-object brep (faces 0)))))
(the-object crv :start)
(the-object crv :end)
```
**Imported comments:**
*By genworks on 2015-02-09 17:29:13 UTC*
Moved to internal tracking list, following up with reporter by email.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/3segmentation 11 error uv-curve from surface2018-02-21T03:26:53ZDave Coopersegmentation 11 error uv-curve from surface*Created by: reiniervandijk*
When I tried to obtain a uv-curve from a surface object using one of the edges of its brep and passing the surface as the on-surface argument, I get a segmentation 11 error. Passing the brep's first face fix...*Created by: reiniervandijk*
When I tried to obtain a uv-curve from a surface object using one of the edges of its brep and passing the surface as the on-surface argument, I get a segmentation 11 error. Passing the brep's first face fixes the error, but the point is that segmentation 11 errors should never happen. Serious bug, I think. Perhaps test if SMLib returned curve is a null-curve or something. Try to replicate calling seg11 and no-seg11 below.
```lisp
(in-package :gdl-user)
(define-object test-lofted-surface (base-object)
:computed-slots
((curves (list (the curve-1) (the curve-2)))
(seg11 (the lofted-surface brep (edges 2) (uv-curve (the lofted-surface)) :start))
(no-seg11 (the lofted-surface brep (edges 2) (uv-curve (the lofted-surface brep (faces 0))) :start)))
:objects
((lofted-surface :type 'lofted-surface
:curves (the curves))
(curve-1 :type 'b-spline-curve
:display-controls (list :color :red :line-thickness 3)
:control-points (list (make-point 0 0 0)
(make-point 1 1 0)
(make-point 0 1 0)
(make-point 0 0 0)))
(curve-2 :type 'b-spline-curve
:display-controls (list :color :red :line-thickness 3)
:control-points (list (make-point 0 0 1)
(make-point -1 1 1)
(make-point 0 1 1)
(make-point 0 0 1)))
))
```
https://gitlab.common-lisp.net/gendl/gendl/-/issues/2Tasty crash when visualizing sub-shapes of REPL instantiated object.2021-07-23T02:47:42ZDave CooperTasty crash when visualizing sub-shapes of REPL instantiated object.*Created by: reiniervandijk*
When you instantiate an object in REPL, and try to visualize it in Tasty, visualization of sub-shapes makes the application crash. Replicate:
```lisp
gdl-user> (setq box (make-object 'box-solid :width 1 ...*Created by: reiniervandijk*
When you instantiate an object in REPL, and try to visualize it in Tasty, visualization of sub-shapes makes the application crash. Replicate:
```lisp
gdl-user> (setq box (make-object 'box-solid :width 1 :length 2 :height 3))
#<box-solid @ #x2409b7fa>
```
Open Tasty and visualize box (object expression) and try to visualize one of the edges from the inspector window.
```lisp
got the error #<tasty:assembly @ #x243b19ca>, which is the root object, could not handle the :edges message.
```https://gitlab.common-lisp.net/gendl/gendl/-/issues/1Tasty svg line-thickness2021-07-23T02:47:42ZDave CooperTasty svg line-thickness*Created by: reiniervandijk*
The first time an SVG image is drawn, all lines in the wireframe drawing have a certain line-thickness. When the user hovers over it, the line is correctly highlighted, but changes line-thickness afterwards....*Created by: reiniervandijk*
The first time an SVG image is drawn, all lines in the wireframe drawing have a certain line-thickness. When the user hovers over it, the line is correctly highlighted, but changes line-thickness afterwards. Replicate by opening the ``robot:assembly`` in Tasty, draw all nodes in SVG mode. Then note the thickness of all lines, then hover over one, move cursor away from line, and note thickness change.
**Imported comments:**
*By genworks on 2015-02-19 02:12:12 UTC*
What version of GDL/Gendl is this happening in? I believe this issue has been fixed some time ago and should not be there in current codebase or in released 1588. Unless I'm looking at something different.
*By reiniervandijk on 2015-02-19 08:27:22 UTC*
This is 1587p001.
*By genworks on 2015-02-20 03:27:48 UTC*
Closing as already fixed in current version.