gendl issueshttps://gitlab.common-lisp.net/groups/gendl/-/issues2023-05-18T18:44:59Zhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/171Need method to align host SLIME to Docker version2023-05-18T18:44:59ZMark EvensonNeed method to align host SLIME to Docker versionThe user should have a way to quickly and precisely get a version of the SLIME packaged in Docker image.
Attempting to connect to `release-1868` via a contemporary SLIME in the host Emacs results in warning like
``` ...The user should have a way to quickly and precisely get a version of the SLIME packaged in Docker image.
Attempting to connect to `release-1868` via a contemporary SLIME in the host Emacs results in warning like
```
Versions differ: 2014-06-17 (slime) vs. 2.28 (swank). Continue? (y or n) y
```
After accepting the warning, swank fails to load missing classes referenced in the Docker SLIME.
Possibilties:
1. Somehow introspect and use the actual SLIME source in the Docker image
2. Provide a tag from <https://github.com/slime/slime> that may be precisely reproduced on the hostMark EvensonMark Evenson2023-05-11https://gitlab.common-lisp.net/gendl/gendl/-/issues/170Title unexpectedly refers to FreeNode2022-01-15T12:20:21ZErik HuelsmannTitle unexpectedly refers to FreeNode@dcooper The title of the project says "#gendl on irc.freenode.net"...
I'd expect it to refer to libera?@dcooper The title of the project says "#gendl on irc.freenode.net"...
I'd expect it to refer to libera?https://gitlab.common-lisp.net/gendl/gendl/-/issues/168Include sbcl in standard build pipeline.2021-07-23T02:40:03ZDave CooperInclude sbcl in standard build pipeline.Prolly best to use one of etimmons' docker images for this.Prolly best to use one of etimmons' docker images for this.Dave CooperDave Cooperhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/162Custom User Interface chapter needs expansion2017-08-21T19:04:22ZDave CooperCustom User Interface chapter needs expansionThe chapter [here](documentation/tutorial/source/custom-user-interfaces.lisp) needs to be expanded upon.
If you start looking through it in the Lisp source and the HTML tutorial you can try to spin up the simple examples.
In the next ...The chapter [here](documentation/tutorial/source/custom-user-interfaces.lisp) needs to be expanded upon.
If you start looking through it in the Lisp source and the HTML tutorial you can try to spin up the simple examples.
In the next day or so I will provide instructions for getting a testbed going with the Stripe payments app and other examples.Gail ZachariasGail Zachariashttps://gitlab.common-lisp.net/gendl/gendl/-/issues/160Tags missing from HTML output2017-08-21T19:04:22ZDave CooperTags missing from HTML outputThis Issue presents a simple initial exercise, and as a side-effect it's intended for getting up to speed on how the Tutorial is being generated.
If it will help to have more explanation of what is actually going on to generate the m...This Issue presents a simple initial exercise, and as a side-effect it's intended for getting up to speed on how the Tutorial is being generated.
If it will help to have more explanation of what is actually going on to generate the manual, then please say the word and I'll provide more description here in the comments.
As a first exercise, please load and generate the tutorial as follows:
```
GDL-USER> (ql:quickload :tutorial)
GDL-USER> (gendl-doc::make-html-and-css)
```
Notice all the warnings various markup tags "not recognized."
Find where these warnings are coming from and try to add the missing markup tags.Dave CooperDave Cooperhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/144geom-base leader-line display error.2017-08-21T19:04:22ZDave Coopergeom-base leader-line display error.*Created by: teodor-gelu*
Leader-line is not displayed in SVG/VML format. This object is not exported as a VRML object.
!!! The .png and .jpg format is Ok.!!!
*Created by: teodor-gelu*
Leader-line is not displayed in SVG/VML format. This object is not exported as a VRML object.
!!! The .png and .jpg format is Ok.!!!
Dave CooperDave Cooperhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/121html-sections are not unregistered2017-08-21T19:04:22ZDave Cooperhtml-sections are not unregistered*Created by: reiniervandijk*
In GWL base-ajax-sheet, a dynamic sequence of sheet-section elements may cause problems. In case sheet-sections are dynamically removed, the html-sections list does not update. Sheet-sections can be added dy...*Created by: reiniervandijk*
In GWL base-ajax-sheet, a dynamic sequence of sheet-section elements may cause problems. In case sheet-sections are dynamically removed, the html-sections list does not update. Sheet-sections can be added dynamically, because the recursive register! strategy will work. However, when removing sections, there is not unregister! strategy in place. It may be argued that this is a limitation of GWL as it stands today, however since this is never documented anywhere, the user can not assume differently than this being a bug (one is allowed to assume that dependency tracking will be properly set-up). A working example will be provided.
**Imported comments:**
*By genworks on 2013-01-14 16:02:24 UTC*
Along the same lines, we want to extend the sheet-section concept with gdlAjax to:
* allow for gdlAjax to work with the toplevel page, without need for child sheet-sections
* allow for sheet-sections within sheet-sections, where the smallest affected unit gets tracked & updated
*By genworks on 2013-01-14 16:07:31 UTC*
But first things first, let's address the reported Bug.
Here is the submitted code example by @reiniervandijk:
http://paste.lisp.org/display/134625
Note that these Github issues allow for attaching an image but not text files. For text files (e.g. code examples), it's possible to use http://paste.lisp.org (as was used above), or something like http://gist.github.com, then include a link here in the Issue.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/120Tasty casting 2 resize events and associated server traffic2017-08-21T19:04:22ZDave CooperTasty casting 2 resize events and associated server traffic*Created by: reiniervandijk*
One window resize event results in 2 identical gdlAjax requests being sent to the server. Resulting in twice the data traffic. This is unnecessary and should be corrected inside the initlayout JS code.*Created by: reiniervandijk*
One window resize event results in 2 identical gdlAjax requests being sent to the server. Resulting in twice the data traffic. This is unnecessary and should be corrected inside the initlayout JS code.https://gitlab.common-lisp.net/gendl/gendl/-/issues/110tasty viewport insensible to color changes2017-08-21T19:04:22ZDave Coopertasty viewport insensible to color changes*Created by: reiniervandijk*
Color changes or line-thickness changes do not have an effect anymore in the viewport. At least for gdl1582-windows-2012113000 it hasn't. Note that the tree node does behave appropriately.
**Imported comme...*Created by: reiniervandijk*
Color changes or line-thickness changes do not have an effect anymore in the viewport. At least for gdl1582-windows-2012113000 it hasn't. Note that the tree node does behave appropriately.
**Imported comments:**
*By genworks on 2013-01-30 20:56:15 UTC*
The color and line-thickness selection appear to be functional currently for SVG mode at least.
Color selection is broken for VRML, X3D, and X3DOM. This needs to be fixed.
*By reiniervandijk on 2013-01-30 21:17:46 UTC*
For me, SVG, PNG and JPEG are also insensitive to this. Are you replicating it on gdl1582-windows-2012113000?https://gitlab.common-lisp.net/gendl/gendl/-/issues/108Need a documented, convenient way to delete fasls from a system2023-01-31T13:29:28ZDave CooperNeed a documented, convenient way to delete fasls from a system*Created by: genworks*
*Created by: genworks*
https://gitlab.common-lisp.net/gendl/gendl/-/issues/90DOM nodes garbage collected?2017-08-21T19:04:22ZDave CooperDOM nodes garbage collected?*Created by: reiniervandijk*
Each time user visualizes something in Tasty in X3D format (true for other formats as well), Gendl server responds with a new wrl file to embed. What happens to the previous embedded DOM elements? Are they g...*Created by: reiniervandijk*
Each time user visualizes something in Tasty in X3D format (true for other formats as well), Gendl server responds with a new wrl file to embed. What happens to the previous embedded DOM elements? Are they garbage collected in the browser, or do they stay alive? I know a DOM by default preserves all DOM nodes, even if they have been removed from the DOM tree itself. Only a page refresh would drive the browser to gc. See:
http://stackoverflow.com/questions/3785258/how-to-remove-dom-elements-without-memory-leaks
After using Tasty for extended periods of time, it usually get's slower and slower. I'm wondering whether this aspect has something to do with it.https://gitlab.common-lisp.net/gendl/gendl/-/issues/87Positioning general-note2017-08-21T19:04:22ZDave CooperPositioning general-note*Created by: reiniervandijk*
Replicate with:
```lisp
(define-object general-note-sample (base-object)
:objects
((x-axis :type 'line :start (make-point 0 0 0) :end (make-point 1 0 0))
(origin-text :type 'general-note :sta...*Created by: reiniervandijk*
Replicate with:
```lisp
(define-object general-note-sample (base-object)
:objects
((x-axis :type 'line :start (make-point 0 0 0) :end (make-point 1 0 0))
(origin-text :type 'general-note :start (make-point 0 0 0) :outline-shape-type :rectangle :strings "O" :character-size 0.1)))
```
and see where the text ends up... Am I doing something wrong or what?
**Imported comments:**
*By genworks on 2013-02-23 16:54:50 UTC*
Text still acts a bit flakey in non top views. What view are you using, and what output format?
Text output has recently been improved for 3d output in x3d format. Other formats need work for 3d output and non top views for raster and vector output formats.
.
On Feb 23, 2013, at 9:02 AM, reiniervandijk <notifications@github.com> wrote:
> Replicate with:
>
> (define-object general-note-sample (base-object)
>
> :objects
> ((x-axis :type 'line :start (make-point 0 0 0) :end (make-point 1 0 0))
> (origin-text :type 'general-note :start (make-point 0 0 0) :outline-shape-type :rectangle :strings "O" :character-size 0.1)))
> and see where the text ends up... Am I doing something wrong or what?
>
> —
> Reply to this email directly or view it on GitHub.
>
*By reiniervandijk on 2013-02-23 23:21:02 UTC*
I was using top view and SVG. Text is positioned far from input location. Just replicate wih code provided.
Op 23 feb. 2013 om 17:54 heeft Dave Cooper <notifications@github.com> het volgende geschreven:
>
> Text still acts a bit flakey in non top views. What view are you using, and what output format?
>
> Text output has recently been improved for 3d output in x3d format. Other formats need work for 3d output and non top views for raster and vector output formats.
>
> .
>
> On Feb 23, 2013, at 9:02 AM, reiniervandijk <notifications@github.com> wrote:
>
> > Replicate with:
> >
> > (define-object general-note-sample (base-object)
> >
> > :objects
> > ((x-axis :type 'line :start (make-point 0 0 0) :end (make-point 1 0 0))
> > (origin-text :type 'general-note :start (make-point 0 0 0) :outline-shape-type :rectangle :strings "O" :character-size 0.1)))
> > and see where the text ends up... Am I doing something wrong or what?
> >
> > —
> > Reply to this email directly or view it on GitHub.
> >
> —
> Reply to this email directly or view it on GitHub.
>
*By genworks on 2013-02-25 00:22:05 UTC*
Yep this is an SVG/Raphael bug. PNG output looks correct. Partial fix for SVG is available in
https://github.com/genworks/Genworks-GDL/blob/master/gdl/gwl-graphics/raphael/source/lenses.lisp
Text sizing, font, positioning still need tweaking for SVG so this issue will remain open.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/86display-controls global-polyline2017-08-21T19:04:22ZDave Cooperdisplay-controls global-polyline*Created by: reiniervandijk*
global-polyline object ignores line-thickness attribute:
```lisp
(define-object SVG-display-controls (base-object)
:objects
((line1 :type 'line :start #(0.0 0.0 0.0) :end #(1.0 0.0 0.0) :display-...*Created by: reiniervandijk*
global-polyline object ignores line-thickness attribute:
```lisp
(define-object SVG-display-controls (base-object)
:objects
((line1 :type 'line :start #(0.0 0.0 0.0) :end #(1.0 0.0 0.0) :display-controls (list :color :red :line-thickness 1))
(line2 :type 'line :start #(0.0 0.0 0.0) :end #(0.0 1.0 0.0) :display-controls (list :color :green :line-thickness 5))
(line3 :type 'global-polyline :vertex-list (list #(0.0 0.0 0.0) #(1.0 1.0 0.0)) :display-controls (list :color :green :line-thickness 5))
))
```https://gitlab.common-lisp.net/gendl/gendl/-/issues/85Tasty inspection error2017-08-21T19:04:22ZDave CooperTasty inspection error*Created by: reiniervandijk*
Often, when inspecting attributes in the tree and drawing some center points or other things, then when inspecting the root node, Gendl will throw an error that is can not find a certain member of a sequence...*Created by: reiniervandijk*
Often, when inspecting attributes in the tree and drawing some center points or other things, then when inspecting the root node, Gendl will throw an error that is can not find a certain member of a sequence. I saw exactly the same error occuring on the program of a student this morning when we were visualizing his work. There's definitely an issue here, but it's still hard to replicate with an isolated example, because I don't understand the root cause yet.https://gitlab.common-lisp.net/gendl/gendl/-/issues/84Tasty replaces center point2017-08-21T19:04:22ZDave CooperTasty replaces center point*Created by: reiniervandijk*
Use the code below. Open in Tasty, visualize child1 node and it's center. Now inspect child2 or root object and see how center is disappearing (when :center is unbound) or replaced with center of new object....*Created by: reiniervandijk*
Use the code below. Open in Tasty, visualize child1 node and it's center. Now inspect child2 or root object and see how center is disappearing (when :center is unbound) or replaced with center of new object. This is very unwanted behavior, because it doesn't allow for inspection of multiple center points (which is important for debugging/inspection in general).
```lisp
(define-object tasty-center-test (base-object)
:objects
((child1 :type 'box-solid
:center (make-point 1 0 0) :width 1 :length 1 :height 1)
(child2 :type 'box-solid :width 1 :length 1 :height 1))
)
```
**Imported comments:**
*By genworks on 2013-02-26 03:12:04 UTC*
Indeed that should not be the desired behavior. I see what the problem is but I don't see an instant fix for it. What is happening is that the root-path of the displayed object (i.e. the point) is coming from the inspector itself, rather than from the actual object whose center (or any other 3d point) is supposedly being displayed.
We will have to come up with a different strategy for containing the Gendl point object to be displayed, corresponding to the 3d point (i.e. 3d vector) which is the actual value of the center or other 3d point which is listed in the inspector.
For the time being, it should simply be noted that the points display is limited to the object currently being inspected in the inspector.
*By genworks on 2013-02-27 03:37:25 UTC*
As mentioned this is partially fixed for PDF, PNG, JPEG, SVG. The fix involved a deeper change to the Gendl display machinery than I had anticipated so it needs to be tracked carefully. X3D and VRML still need proper display of points (probably as a tiny sphere).
Also the dynamic display-controls (imposed by the line-thickness and color controls in tasty) still need to be implemented for the new way of displaying points. Also, scaling control.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/83stack overflow through tasty takes forever2017-08-21T19:04:22ZDave Cooperstack overflow through tasty takes forever*Created by: reiniervandijk*
A stack overflow problem that occurs through interaction with Tasty, will generally take forever (status ...working until after a long while an error pops up in the lisp console). In contrast, on the REPL th...*Created by: reiniervandijk*
A stack overflow problem that occurs through interaction with Tasty, will generally take forever (status ...working until after a long while an error pops up in the lisp console). In contrast, on the REPL the user gets immediate feedback and may continue. Moreover, Tasty doesn't only hang forever but will also tend to consume all resources. As a consequence, Gendl becomes slow and doens't respond anymore. Only through (net.aserve:start :port XXXX) things get better, but don't really go back to natural state. It seems this behavior qualifies as another issue, because it happens quite often during developing (assuming error-free coding is a utopia). Can't these types of errors be caught in a leaner way, similar to what happens in the REPL?https://gitlab.common-lisp.net/gendl/gendl/-/issues/82tasty update throwing errors when child object are renamed in source code2017-08-21T19:04:22ZDave Coopertasty update throwing errors when child object are renamed in source code*Created by: reiniervandijk*
Almost always Tasty updates will handle source code changes correctly (that is, after compiling), except when the viewport displays object that aren't there anymore. For example, when the child object has be...*Created by: reiniervandijk*
Almost always Tasty updates will handle source code changes correctly (that is, after compiling), except when the viewport displays object that aren't there anymore. For example, when the child object has been renamed or when an aggregate holds less member than before. I understand where the error comes from (out of experience), however a starting user would not understand the root cause of this error.
```lisp
!! This section threw error: Neither XXX nor any of its ancestor instances could handle the XXX message The path to the containing object is: (the :root :root-object-object) !!
```
Why isn't the update functionality set-up in a more robust way, by for example throwing away "old-timers" from the display-list?https://gitlab.common-lisp.net/gendl/gendl/-/issues/78ajax-timeout has no effect, default remains 2 seconds2017-08-21T19:04:22ZDave Cooperajax-timeout has no effect, default remains 2 seconds*Created by: reiniervandijk*
gwl:*ajax-timout* doesn't have any effect. Default of 2 seconds is used consistently no matter the value of the former. Possibly with-error-handling macro overwrites value.*Created by: reiniervandijk*
gwl:*ajax-timout* doesn't have any effect. Default of 2 seconds is used consistently no matter the value of the former. Possibly with-error-handling macro overwrites value.https://gitlab.common-lisp.net/gendl/gendl/-/issues/76pdf drawing empty2017-08-21T19:04:22ZDave Cooperpdf drawing empty*Created by: reiniervandijk*
Using the YADD example to generate a PDF, results in an empty drawing
```lisp
(gdl::with-format (pdf "/tmp/box.pdf" :view-transform (getf *standard-views* :trimetric))
(write-the-object (make-insta...*Created by: reiniervandijk*
Using the YADD example to generate a PDF, results in an empty drawing
```lisp
(gdl::with-format (pdf "/tmp/box.pdf" :view-transform (getf *standard-views* :trimetric))
(write-the-object (make-instance 'box :length 100 :width 100 :height 100) cad-output))
```
**Imported comments:**
*By genworks on 2013-03-09 17:11:45 UTC*
Thanks for this. This example needs to be fixed, since PDF output-format is only supported for 2D objects such as drawings. The box would have to be contained in a view of a drawing first, then the
```common-lisp
(with-format (pdf ...) (write-the cad-output))
```
would be called on the drawing.
This issue will remain open until the documentation is fixed, or until the PDF output-format is upgraded to produce a default drawing with default view when called on a 3D object (if we were to do that, what would make sense for the default view? I would hesitate to put a bunch of view options into the PDF output-format, because at that point it would be better simply to make a drawing and specify the viewing details).
Stylistic note: use of double-colon is not recommended unless going for unexported symbols in an unused package for experimental purposes. In this case you would likely be in-package :gdl-user or another package created with gdl:define-package or gwl:define-package, so the prefix is not necessary. If you are working in a package which does not use the GDL packages, then you should prefix with a single-colon, and you would have to prefix the name of the output format as well, e.g.
```common-lisp
(gdl:with-format (geom-base:pdf ... ) ... )
```
*By reiniervandijk on 2013-03-09 17:41:39 UTC*
Note that I'd just copied the example from YADD. The example uses the double-colon notation, I personally wouldn't do such a thing. Default view can be trimetric, like you've done before.https://gitlab.common-lisp.net/gendl/gendl/-/issues/74YADD apparently spewing out superfluous package prefixes2017-08-21T19:04:22ZDave CooperYADD apparently spewing out superfluous package prefixes*Created by: genworks*
As seen in Issue #92 and Issue #93, it looks like YADD is sometimes emitting unecessary package prefixes such as `gdl::with-format``
*Created by: genworks*
As seen in Issue #92 and Issue #93, it looks like YADD is sometimes emitting unecessary package prefixes such as `gdl::with-format``