Hi,
I have a small GTInspector extension that shows me a tree-like structure of a graph. As the data underneath are graphs, the tree itself is infinite (because there are loops). That by itself works fine (because only roots are expanded), however when I am filtering the elements (in raw pane), GTInspector gets stuck in infinite GLMTreeMorphNodeModel>>pathIn: loop. I've made couple of classes to reproduce the behavior - see attached file. There are two types of nodes: one contains children (items), and the other can contain references to other elements. The extension is written in LLCompositeElement>>gtInspectorTreeIn: To reproduce: 1. import attached package 2. execute the following ``` '<a> <b ref c /> <c ref b /> </a>'. a := LLCompositeElement named: 'a'. b := LLReferenceElement named: 'b'. c := LLReferenceElement named: 'c'. a items: { b . c }. b references: { c }. c references: { b }. a inspect. ``` 3. the Tree view works fine (I see some visual glitching of arrows, but that doesn't matter) 4. switch to Raw view 5. (any of these will trigger the behaivor) 5.a. click on "items" instance variable, or 5.b. "do it and go" any expression (e.g. 1+1) 6. now you are in infinite pathIn: loop Sometimes I've experienced that breaking the loop (meta+.), closing the debugger and redoing the expression worked... but I don't have any details about that. Thanks! Peter _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Sorry, forgot to send the attachment.
Peter On Fri, Apr 14, 2017 at 03:06:55PM +0200, Peter Uhnak wrote: > Hi, > > I have a small GTInspector extension that shows me a tree-like structure of a graph. As the data underneath are graphs, the tree itself is infinite (because there are loops). > > That by itself works fine (because only roots are expanded), however when I am filtering the elements (in raw pane), GTInspector gets stuck in infinite GLMTreeMorphNodeModel>>pathIn: loop. > > I've made couple of classes to reproduce the behavior - see attached file. > > There are two types of nodes: one contains children (items), and the other can contain references to other elements. > The extension is written in LLCompositeElement>>gtInspectorTreeIn: > > > To reproduce: > > 1. import attached package > 2. execute the following > ``` > '<a> > <b ref c /> > <c ref b /> > </a>'. > > a := LLCompositeElement named: 'a'. > b := LLReferenceElement named: 'b'. > c := LLReferenceElement named: 'c'. > > a items: { b . c }. > b references: { c }. > c references: { b }. > > a inspect. > ``` > 3. the Tree view works fine (I see some visual glitching of arrows, but that doesn't matter) > 4. switch to Raw view > 5. (any of these will trigger the behaivor) > 5.a. click on "items" instance variable, or > 5.b. "do it and go" any expression (e.g. 1+1) > 6. now you are in infinite pathIn: loop > > Sometimes I've experienced that breaking the loop (meta+.), closing the debugger and redoing the expression worked... but I don't have any details about that. > > Thanks! > Peter _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev LLPackage.st (2K) Download Attachment |
Hi Peter, Did not check the code but when creating your custom tree view, if you have cycles, can you use the following: aComposite tree shouldValidate: false; allowsRecursiveSearch: false; This is actually a side-effect of another issue from glamour (bidirectional ports in inspector) that we'll need to look at for Pharo 7. Also you can try to use #fastTree instead of #tree. Ideally we'd like to deprecate #tree for Pharo 7 but at the moment the fast table renderer is still missing features. Can post some screenshots with the visual glitches of arrows? Cheers, Andrei On Fri, Apr 14, 2017 at 4:09 PM, Peter Uhnak <[hidden email]> wrote: Sorry, forgot to send the attachment. _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Hi,
disabling the search indeed fixed the issue (I've also disabled the validation, though I am not sure what it does). As for the graphical glitch, it's not occuring right now, but basically the triangle blinked when I opened/closed the same node somewhere else in the tree. I'll let you know if I manage to reproduce it. I've tried fastTree now, but keyboard navigation doesn't seem to work. Thanks! Peter On Fri, Apr 14, 2017 at 11:49:41PM +0300, Andrei Chis wrote: > Hi Peter, > > Did not check the code but when creating your custom tree view, if you have > cycles, can you use the following: > > aComposite tree > shouldValidate: false; > allowsRecursiveSearch: false; > > This is actually a side-effect of another issue from glamour (bidirectional > ports in inspector) that we'll need to look at for Pharo 7. > > Also you can try to use #fastTree instead of #tree. Ideally we'd like to > deprecate #tree for Pharo 7 but at the moment the fast table renderer is > still missing features. > > Can post some screenshots with the visual glitches of arrows? > > Cheers, > Andrei > > On Fri, Apr 14, 2017 at 4:09 PM, Peter Uhnak <[hidden email]> wrote: > > > Sorry, forgot to send the attachment. > > > > Peter > > > > > > On Fri, Apr 14, 2017 at 03:06:55PM +0200, Peter Uhnak wrote: > > > Hi, > > > > > > I have a small GTInspector extension that shows me a tree-like structure > > of a graph. As the data underneath are graphs, the tree itself is infinite > > (because there are loops). > > > > > > That by itself works fine (because only roots are expanded), however > > when I am filtering the elements (in raw pane), GTInspector gets stuck in > > infinite GLMTreeMorphNodeModel>>pathIn: loop. > > > > > > I've made couple of classes to reproduce the behavior - see attached > > file. > > > > > > There are two types of nodes: one contains children (items), and the > > other can contain references to other elements. > > > The extension is written in LLCompositeElement>>gtInspectorTreeIn: > > > > > > > > > To reproduce: > > > > > > 1. import attached package > > > 2. execute the following > > > ``` > > > '<a> > > > <b ref c /> > > > <c ref b /> > > > </a>'. > > > > > > a := LLCompositeElement named: 'a'. > > > b := LLReferenceElement named: 'b'. > > > c := LLReferenceElement named: 'c'. > > > > > > a items: { b . c }. > > > b references: { c }. > > > c references: { b }. > > > > > > a inspect. > > > ``` > > > 3. the Tree view works fine (I see some visual glitching of arrows, but > > that doesn't matter) > > > 4. switch to Raw view > > > 5. (any of these will trigger the behaivor) > > > 5.a. click on "items" instance variable, or > > > 5.b. "do it and go" any expression (e.g. 1+1) > > > 6. now you are in infinite pathIn: loop > > > > > > Sometimes I've experienced that breaking the loop (meta+.), closing the > > debugger and redoing the expression worked... but I don't have any details > > about that. > > > > > > Thanks! > > > Peter > > > > _______________________________________________ > > Moose-dev mailing list > > [hidden email] > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > > > _______________________________________________ > Moose-dev mailing list > [hidden email] > https://www.list.inf.unibe.ch/listinfo/moose-dev _______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
On Sat, Apr 15, 2017 at 1:13 AM, Peter Uhnak <[hidden email]> wrote: Hi, Yes, this feature is still missing. Cheers, Andrei
_______________________________________________ Moose-dev mailing list [hidden email] https://www.list.inf.unibe.ch/listinfo/moose-dev |
Free forum by Nabble | Edit this page |