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
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:
- import attached package
- 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.
- the Tree view works fine (I see some visual glitching of arrows, but that doesn't matter)
- switch to Raw view
- (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)
- 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
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 i.uhnak@gmail.com 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:
- import attached package
- 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.
- the Tree view works fine (I see some visual glitching of arrows, but
that doesn't matter)
- switch to Raw view
- (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)
- 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 Moose-dev@list.inf.unibe.ch 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 i.uhnak@gmail.com 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:
- import attached package
- 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.
- the Tree view works fine (I see some visual glitching of arrows, but
that doesn't matter)
- switch to Raw view
- (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)
- 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
On Sat, Apr 15, 2017 at 1:13 AM, Peter Uhnak i.uhnak@gmail.com wrote:
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.
Yes, this feature is still missing.
Cheers, Andrei
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 i.uhnak@gmail.com 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:
- import attached package
- 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.
- the Tree view works fine (I see some visual glitching of arrows,
but
that doesn't matter)
- switch to Raw view
- (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)
- 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 Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev
-
Andrei Chis -
Peter Uhnak