gendl issueshttps://gitlab.common-lisp.net/gendl/gendl/-/issues2017-08-21T19:04:22Zhttps://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/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/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/54Tasty errors on quick-save when given object expression2018-02-21T03:26:53ZDave CooperTasty errors on quick-save when given object expression*Created by: genworks*
When you give an Object Expression (instead of package::class) to browse in Tasty, the automatic quick-save which happens with every Ajax call throws an error:
```
got the error #<some-package::some-type @ #...*Created by: genworks*
When you give an Object Expression (instead of package::class) to browse in Tasty, the automatic quick-save which happens with every Ajax call throws an error:
```
got the error #<some-package::some-type @ #x29012eb2> appears to be a GDL
object from a different object hierarchy from the current
object #<tasty:assembly @ #x2902d21a>. GDL currently does not support
writing out and reading back in GDL objects from
a separate object hierarchy.
```
This error will not happen if you instantiate the object via tasty by specifying a package::class.
But Tasty and/or the quick-save and readable-expression functions have to be fixed so as not to incur this error (it is because the root-object is indeed from a different tree hierarchy when you specify a pre-instantiated object to tasty, so this requires a fundamental re-working of the way the readable-expression works for this case).
In the meantime the following patch will turn this into a Warning instead of an Error:
```common-lisp
(in-package :gwl)
(defun quick-save (self &key (snap-folder (glisp:snap-folder)))
(let ((snap-file
(merge-pathnames
(make-pathname :name (format nil "~a" (the instance-id))
:type "snap") snap-folder)))
(with-error-handling ()
(the (write-snapshot :filename snap-file)))))
```
https://gitlab.common-lisp.net/gendl/gendl/-/issues/47Not evident how to change on-change submit behavior in Tasty2018-02-21T03:26:53ZDave CooperNot evident how to change on-change submit behavior in Tasty*Created by: reiniervandijk*
It is often undesirable to have automatic on-change -> submit behavior for settable slot forms in Tasty. Especially with large amounts of object on the canvas, a user would like to set a batch of inputs befo...*Created by: reiniervandijk*
It is often undesirable to have automatic on-change -> submit behavior for settable slot forms in Tasty. Especially with large amounts of object on the canvas, a user would like to set a batch of inputs before triggering any updates. By default, an HTML event that changes a single form element, will lead to an AJAX request. It is not evident to the user how to change this behavior. I see that as an significant shortcoming of the documentation leading to unnecessary frustration and time spent on waiting for re-visualization.
Moreover, consider that fact that the "working..." status at the bottom of the screen often goes unnoticed to newbies, in which case they happily change many settable form elements sequentially, unaware of triggering many sequential updates and eventually the risk of having a "hanging" Tasty. In the current KBE exams, easily 5-10 minutes of an hour-long session are now spent on struggling with Tasty.
**Imported comments:**
*By genworks on 2015-01-30 00:08:33 UTC*
Open for submissions: $100
https://gitlab.common-lisp.net/gendl/gendl/-/issues/46Instances don't trigger tree updates in Tasty on topology changes2018-02-21T03:26:53ZDave CooperInstances don't trigger tree updates in Tasty on topology changes*Created by: reiniervandijk*
On 1581, consider example
```lisp
(define-object my-sequence (base-object)
:input-slots
((no 2 :settable))
:objects
((boxes :type 'box
:sequence (:size (the no)))))
```
When inst...*Created by: reiniervandijk*
On 1581, consider example
```lisp
(define-object my-sequence (base-object)
:input-slots
((no 2 :settable))
:objects
((boxes :type 'box
:sequence (:size (the no)))))
```
When instantiating this object with Tasty using "Class Package:Type" everything is fine. However, when I go for the object expression option, we have strange behavior.
```lisp
(make-self 'my-sequence)
```
fill out self in Tasty object expression box. Then try to alter the :no input message and (hopefully) replicate that an update in the tree is not happening. ONLY when clicking the update button in the interface or restarting Tasty with the same instance will cause an update. It's also leading to errors: when you decrease the number of sequence elements, non-existing sequence members (old-timers) are still shown and drawing these will give errors (obviously).https://gitlab.common-lisp.net/gendl/gendl/-/issues/34Tasty tree pane horizontal scrolling2018-02-21T03:26:54ZDave CooperTasty tree pane horizontal scrolling*Created by: reiniervandijk*
The tree pane in the Tasty interface is currently not scrollable in horizontal direction. It can happen when you double-click some long text string of a tree node that the focus of the pane moves to the end ...*Created by: reiniervandijk*
The tree pane in the Tasty interface is currently not scrollable in horizontal direction. It can happen when you double-click some long text string of a tree node that the focus of the pane moves to the end of the string. It is then impossible to slide back to the left again, because the current resizer handle does not affect the horizontal position. Only F5 solves the problem.
**Imported comments:**
*By genworks on 2015-01-29 23:50:48 UTC*
Open for submissions: $100
This should be fixable with a CSS update.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/28Tasty remember inspector state2018-02-21T03:26:54ZDave CooperTasty remember inspector state*Created by: reiniervandijk*
Tasty inspector remembers slot-status, but doesn't remember view status, i.e. once a user expanded a list of (say) points and navigates to another node and finally returns to this node, this viewing state is...*Created by: reiniervandijk*
Tasty inspector remembers slot-status, but doesn't remember view status, i.e. once a user expanded a list of (say) points and navigates to another node and finally returns to this node, this viewing state is not remember and the list will be collapsed again. This is quite annoying if you want to quickly inspect and compare list values while hopping over tree nodes.
**Imported comments:**
*By genworks on 2013-10-22 15:04:38 UTC*
Agreed this needs to be fixed. It will require a bit of additional data structures around the inspector since the inspector is currently a single object which keeps getting bashed when you change object.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/24Tasty tree branch closes on inspect2018-02-21T03:26:54ZDave CooperTasty tree branch closes on inspect*Created by: reiniervandijk*
1585: when one tries to inspect certain nodes in a Tasty tree, every now and then the complete tree branch closes. Then the user has to navigate his way down the tree structure again...*Created by: reiniervandijk*
1585: when one tries to inspect certain nodes in a Tasty tree, every now and then the complete tree branch closes. Then the user has to navigate his way down the tree structure again...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/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.
```