Tasty tree might disappear on error
Created by: reiniervandijk
Opening a tree node in Tasty, will lead to the real-time calculation of the children. If for any reason, there is an error in your code that is triggered when calculating the minimum aspects of child nodes (edit: hard to pinpoint exactly what causes the problem, can not replicate in isolated example) that error message will take over the entire tree pane. I guess you should catch these errors in JS and show a pop-up to signal an error or something. Now, one HAS to restart the entire Tasty module because you can never retrieve the original tree and continue navigating. In general catching errors on client-side would mean great improvements to the UI. Same applies (although less severe, because it doesn't render the entire UI useless) to the viewport or inspector.
UPDATE: seems that error happens because Gendl tries to assess from each child node if it has safe-children (to show folder icon or not). Calculating the safe-children, gives the error here...
UPDATE 2: isolated it! Quite a nasty one.
(in-package :gdl-user)
(define-object A (base-object)
:objects
((child :type 'B)))
(define-object B (base-object)
:objects
((child :type 'C)))
(define-object C (D)
:computed-slots
((hoi (list 3 4 5))))
(define-object D (base-object)
:objects
((hoi :type (if (/ 0 0) 'null-part 'C))
(dag :type (if (/ 0 0) 'null-part 'C))))
Gendl falsely asssumes hoi to still be a object keyword, although it has been overwritten by C.
Try:
(the child child :%object-keywords%)
I will open a new issue, because this issue is about catching error on client-side, while the afore-mentioned problem is related to fundamental Gendl aspects.
Imported comments:
By genworks on 2013-10-29 16:48:13 UTC
Indeed quite a subtle and nasty issue. Here is a proposed fix:
(in-package :gdl)
(#+allegro
excl:without-package-locks
#-allegro progn
(define-object-amendment vanilla-mixin* ()
:computed-slots
((%object-keywords% (safe-sort (append (the (message-list :category :objects))
(the (message-list :category :quantified-objects)))
#'string-lessp))
(%hidden-object-keywords% (safe-sort (append (the (message-list :category :hidden-objects))
(the (message-list :category :quantified-hidden-objects)))
#'string-lessp)))))
By genworks on 2013-10-29 16:51:07 UTC
One lesson to take from this is to avoid depending on internal, undocumented features whenever possible --- even when implementing internal, undocumented features!
By genworks on 2013-10-29 16:56:48 UTC
Regarding the comment about handling errors on the client-side: agreed that it would be nice to be doing more of this.
By reiniervandijk on 2013-10-29 17:17:18 UTC
I'm surprised that you've closed the other issue and moved the solution here. The core problem was method overriding. It may manifest itself in several ways, not only in the Tasty GUI. I could've come up with 100 situations were an error surfaces that is the result of it. The issue in this topic is client-side error handling.
The issue in #154 (closed) should stay open and the fix should move there. And it has nothing to do with internal, undocumented stuff, that's an invalid argument. As a user, I should be able to just override whatever I want at sub-classing (except of course for the protected symbols). The fact that I traced down the issue to the inner working principles, does not mean that I have relied on undocumented stuff, I just reflects the fact that I understand where the problem came from.
By genworks on 2013-10-29 17:40:42 UTC
I'm surprised that you've closed the other issue and moved the solution here. The core problem was method overriding. It may manifest itself in several ways, not only in the Tasty GUI. I could've come up with 100 situations were an error surfaces that is the result of it.
As far as I could see, the problem being reported in #154 (closed) was malfunctioning of gdl-rule::%object-keywords%, and consequently the %object-keywords% message of vanilla mixin. These are both clearly internal, unsupported, undocumented items.
The only place in the Gendl codebase where the gdl-rule::%object-keywords% is being used is in %object-keywords% message of vanilla-mixin. The only place the %object-keywords% message of vanilla-mixin is being used is in the children-uncached, children, and safe-children of vanilla-mixin. These last three are documented, so there we have a problem for sure. They are also related to the tasty failure being reported in this #153 (closed).
If you have 100 other situations where you are using children-uncached, children, or safe-children, those should also fall under the jurisdiction of this #153 (closed). If you have 100 situations where you are using %object-keywords% or gdl-rule::%object-keywords%, then your usage is invalid. If you have 100 situations which are in neither of these categories, then they belong in a separate Issue.
And it has nothing to do with internal, undocumented stuff, that's an invalid argument. As a user, I should be able to just override whatever I want at sub-classing (except of course for the protected symbols).
If you have problems with subclassing which show up in ways unrelated to %object-keywords% or children-cached or children or safe-children, then please open a separate Issue which illuminates those problems.
By genworks on 2013-10-29 17:47:42 UTC
Note the proposed fix in previous comment has been updated.
By genworks on 2013-10-29 18:27:18 UTC
The fact that I traced down the issue to the inner working principles, does not mean that I have relied on undocumented stuff, I just reflects the fact that I understand where the problem came from.
In my previous comment about "depending on internal, undocumented..." I did not mean to imply that you were doing that. I was making the observation that we were doing that, in a situation where we didn't have to.
Thank you again for your thorough and helpful Issue reports!
By reiniervandijk on 2013-10-29 18:29:32 UTC
You're welcome!
By genworks on 2013-10-31 23:28:49 UTC
This fix will be in the next 1585 maintenance release and in future releases. Closing here for now.