Tree Editor which does not initialize classes

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Tree Editor which does not initialize classes

Adam Hughes
Hey everyone,

I have a series of HasTrait classes that I'd like to open with a tree
editor.  One issue I have is that my objects are hefty in that they
initialize with very large arrays by default.  Therefore, when I run a
program which contains all of these objects, it is very slow.  In practice,
I'd like the user to select 1 or 2 of these objects to be imported, and
only after this selection is made would the objects be instantiated.  The
only solutions I can think of offhand would be either:

   - Rewrite my objects to not initialize until some special condition is
realized, probably in the form of a boolean variable.

   - Create a psuedo-tree which presents a list of choices to the user, and
then when selections are made, it instantiate the corresponding classes.

   - Save each object into a separate file then try to mimic the behavior
of the EPD demos, in which files are opened only upon selection.  (This
would be nice, but I fear I'd have trouble reverse engineering a program as
sophisticated as the demo).

If anyone has a smart solution to this problem, please let me know.  Is it
possible, for example, to override the trait initializations in a HasTraits
object for performance reasons?  I just don't have the expertise to see an
obvious "best" resolution to my quandary.

Thanks.
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tree Editor which does not initialize classes

Brennan Williams
On 29/11/2011 9:55 a.m., Adam Hughes wrote:

> Hey everyone,
>
> I have a series of HasTrait classes that I'd like to open with a tree
> editor.  One issue I have is that my objects are hefty in that they
> initialize with very large arrays by default.  Therefore, when I run a
> program which contains all of these objects, it is very slow.  In practice,
> I'd like the user to select 1 or 2 of these objects to be imported, and
> only after this selection is made would the objects be instantiated.  The
> only solutions I can think of offhand would be either:
>
>     - Rewrite my objects to not initialize until some special condition is
> realized, probably in the form of a boolean variable.
That's what I do. I have a hierachy of objects which like yours have
some fairly big arrays in them or else a substantial child hierarchy
that I don't want loaded immediately. So  I have a "loaded" boolean for
each of my big objects. When you click on the object instance in the
tree it creates the view for that object to display in the right hand
side pane. So the object has a "def create_view(self)" method which not
only creates the view but also loads the data for that object instance
if "loaded" is False.

Instead of using TreeNode in the TreeEditor I use MyTreeNode which
inherits from TreeNode and overrides the get_view(self.object) method.

Brennan

>     - Create a psuedo-tree which presents a list of choices to the user, and
> then when selections are made, it instantiate the corresponding classes.
>
>     - Save each object into a separate file then try to mimic the behavior
> of the EPD demos, in which files are opened only upon selection.  (This
> would be nice, but I fear I'd have trouble reverse engineering a program as
> sophisticated as the demo).
>
> If anyone has a smart solution to this problem, please let me know.  Is it
> possible, for example, to override the trait initializations in a HasTraits
> object for performance reasons?  I just don't have the expertise to see an
> obvious "best" resolution to my quandary.
>
> Thanks.
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tree Editor which does not initialize classes

Adam Hughes
Thanks Brennan.  I'll probably attempt this solution then, unless anyone
else has some input.

On Mon, Nov 28, 2011 at 6:11 PM, Brennan Williams <
[hidden email]> wrote:

> On 29/11/2011 9:55 a.m., Adam Hughes wrote:
> > Hey everyone,
> >
> > I have a series of HasTrait classes that I'd like to open with a tree
> > editor.  One issue I have is that my objects are hefty in that they
> > initialize with very large arrays by default.  Therefore, when I run a
> > program which contains all of these objects, it is very slow.  In
> practice,
> > I'd like the user to select 1 or 2 of these objects to be imported, and
> > only after this selection is made would the objects be instantiated.  The
> > only solutions I can think of offhand would be either:
> >
> >     - Rewrite my objects to not initialize until some special condition
> is
> > realized, probably in the form of a boolean variable.
> That's what I do. I have a hierachy of objects which like yours have
> some fairly big arrays in them or else a substantial child hierarchy
> that I don't want loaded immediately. So  I have a "loaded" boolean for
> each of my big objects. When you click on the object instance in the
> tree it creates the view for that object to display in the right hand
> side pane. So the object has a "def create_view(self)" method which not
> only creates the view but also loads the data for that object instance
> if "loaded" is False.
>
> Instead of using TreeNode in the TreeEditor I use MyTreeNode which
> inherits from TreeNode and overrides the get_view(self.object) method.
>
> Brennan
>
> >     - Create a psuedo-tree which presents a list of choices to the user,
> and
> > then when selections are made, it instantiate the corresponding classes.
> >
> >     - Save each object into a separate file then try to mimic the
> behavior
> > of the EPD demos, in which files are opened only upon selection.  (This
> > would be nice, but I fear I'd have trouble reverse engineering a program
> as
> > sophisticated as the demo).
> >
> > If anyone has a smart solution to this problem, please let me know.  Is
> it
> > possible, for example, to override the trait initializations in a
> HasTraits
> > object for performance reasons?  I just don't have the expertise to see
> an
> > obvious "best" resolution to my quandary.
> >
> > Thanks.
> > _______________________________________________
> > Enthought-Dev mailing list
> > [hidden email]
> > https://mail.enthought.com/mailman/listinfo/enthought-dev
> >
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tree Editor which does not initialize classes

Adam Hughes
For the sake of completeness for the archive, let me put my final solution:

Brennan, I followed your suggestion, and fit it to my needs.  For each of
my objects, I defined an "Adapter Object", basically an intermediate object
which contains an instance of the object in question as well as some
additional information.  Note this is not the Adapter object from
traits.api, so I probably should given it a custom name.  This is nice for
my purposes because:

   1. It doesn't require me to change the source of the object.
   2. It separates ancillary information about the object from the object
itself.

For example, if I had an object A which stores an array:

class A(HasTraits):
   bigarray=Array
   _big_array_default(self): return np.empty( ( 100000), dtype=float)

Then I will define an adapter class:

class A_Adapter(HasTraits):
   obj=Instance(A)
   notes=Str("Here are some notes about this object")
   source=Str("I can provide the source if this object came from a paper,
for example")

   def _populate_object(self):  self.obj=A()
   def _destroy_object(self): self.obj=None

I then present the A_Adapter in the tree to the user, but when a selection
is made, the "populate_object" method is called before returning the object
to whatever routines are going to use it.  The "_destroy_object" method is
useful so that the tree doesn't keep objects open after the selection is
changed.

On Wed, Nov 30, 2011 at 12:34 PM, Adam Hughes <[hidden email]>wrote:

> Thanks Brennan.  I'll probably attempt this solution then, unless anyone
> else has some input.
>
>
> On Mon, Nov 28, 2011 at 6:11 PM, Brennan Williams <
> [hidden email]> wrote:
>
>> On 29/11/2011 9:55 a.m., Adam Hughes wrote:
>> > Hey everyone,
>> >
>> > I have a series of HasTrait classes that I'd like to open with a tree
>> > editor.  One issue I have is that my objects are hefty in that they
>> > initialize with very large arrays by default.  Therefore, when I run a
>> > program which contains all of these objects, it is very slow.  In
>> practice,
>> > I'd like the user to select 1 or 2 of these objects to be imported, and
>> > only after this selection is made would the objects be instantiated.
>>  The
>> > only solutions I can think of offhand would be either:
>> >
>> >     - Rewrite my objects to not initialize until some special condition
>> is
>> > realized, probably in the form of a boolean variable.
>> That's what I do. I have a hierachy of objects which like yours have
>> some fairly big arrays in them or else a substantial child hierarchy
>> that I don't want loaded immediately. So  I have a "loaded" boolean for
>> each of my big objects. When you click on the object instance in the
>> tree it creates the view for that object to display in the right hand
>> side pane. So the object has a "def create_view(self)" method which not
>> only creates the view but also loads the data for that object instance
>> if "loaded" is False.
>>
>> Instead of using TreeNode in the TreeEditor I use MyTreeNode which
>> inherits from TreeNode and overrides the get_view(self.object) method.
>>
>> Brennan
>>
>> >     - Create a psuedo-tree which presents a list of choices to the
>> user, and
>> > then when selections are made, it instantiate the corresponding classes.
>> >
>> >     - Save each object into a separate file then try to mimic the
>> behavior
>> > of the EPD demos, in which files are opened only upon selection.  (This
>> > would be nice, but I fear I'd have trouble reverse engineering a
>> program as
>> > sophisticated as the demo).
>> >
>> > If anyone has a smart solution to this problem, please let me know.  Is
>> it
>> > possible, for example, to override the trait initializations in a
>> HasTraits
>> > object for performance reasons?  I just don't have the expertise to see
>> an
>> > obvious "best" resolution to my quandary.
>> >
>> > Thanks.
>> > _______________________________________________
>> > Enthought-Dev mailing list
>> > [hidden email]
>> > https://mail.enthought.com/mailman/listinfo/enthought-dev
>> >
>>
>> _______________________________________________
>> Enthought-Dev mailing list
>> [hidden email]
>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>
>
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tree Editor which does not initialize classes

Brennan Williams
On 1/12/2011 11:57 a.m., Adam Hughes wrote:

> For the sake of completeness for the archive, let me put my final solution:
>
> Brennan, I followed your suggestion, and fit it to my needs.  For each of
> my objects, I defined an "Adapter Object", basically an intermediate object
> which contains an instance of the object in question as well as some
> additional information.  Note this is not the Adapter object from
> traits.api, so I probably should given it a custom name.  This is nice for
> my purposes because:
>
>     1. It doesn't require me to change the source of the object.
>     2. It separates ancillary information about the object from the object
> itself.
>
> For example, if I had an object A which stores an array:
>
> class A(HasTraits):
>     bigarray=Array
>     _big_array_default(self): return np.empty( ( 100000), dtype=float)
>
> Then I will define an adapter class:
>
> class A_Adapter(HasTraits):
>     obj=Instance(A)
>     notes=Str("Here are some notes about this object")
>     source=Str("I can provide the source if this object came from a paper,
> for example")
>
>     def _populate_object(self):  self.obj=A()
>     def _destroy_object(self): self.obj=None
>
> I then present the A_Adapter in the tree to the user, but when a selection
> is made, the "populate_object" method is called before returning the object
> to whatever routines are going to use it.  The "_destroy_object" method is
> useful so that the tree doesn't keep objects open after the selection is
> changed.

Sounds good to me.

You might want to take a look at...

https://mail.enthought.com/pipermail/enthought-dev/2008-April/013970.html

Your "adapter" object could also be a "viewmodel" object.

In my app I have an object hierarchy of project-ensemble-deck and while
the idea is to work 90% of the time in a project window with its own
tree hierarchy I also want to be able to open each ensemble object in
its own window with its own tree hierarchy. I struggled to do it until
Dave Peterson explained how to create a ThingViewModel on the fly when I
wanted to open a view on a Thing instance (or in my case, an ensemble
instance).

It seems to me that you could kill two birds with one stone here,
solving your performance problem and easily being able to open one of
your objects in a window with its own tree. Note that I only needed to
do it this way because each of my objects had its own hierarchy that I
also wanted to display using TreeNodes and TreeEditor.

Brennan

> On Wed, Nov 30, 2011 at 12:34 PM, Adam Hughes<[hidden email]>wrote:
>
>> Thanks Brennan.  I'll probably attempt this solution then, unless anyone
>> else has some input.
>>
>>
>> On Mon, Nov 28, 2011 at 6:11 PM, Brennan Williams<
>> [hidden email]>  wrote:
>>
>>> On 29/11/2011 9:55 a.m., Adam Hughes wrote:
>>>> Hey everyone,
>>>>
>>>> I have a series of HasTrait classes that I'd like to open with a tree
>>>> editor.  One issue I have is that my objects are hefty in that they
>>>> initialize with very large arrays by default.  Therefore, when I run a
>>>> program which contains all of these objects, it is very slow.  In
>>> practice,
>>>> I'd like the user to select 1 or 2 of these objects to be imported, and
>>>> only after this selection is made would the objects be instantiated.
>>>   The
>>>> only solutions I can think of offhand would be either:
>>>>
>>>>      - Rewrite my objects to not initialize until some special condition
>>> is
>>>> realized, probably in the form of a boolean variable.
>>> That's what I do. I have a hierachy of objects which like yours have
>>> some fairly big arrays in them or else a substantial child hierarchy
>>> that I don't want loaded immediately. So  I have a "loaded" boolean for
>>> each of my big objects. When you click on the object instance in the
>>> tree it creates the view for that object to display in the right hand
>>> side pane. So the object has a "def create_view(self)" method which not
>>> only creates the view but also loads the data for that object instance
>>> if "loaded" is False.
>>>
>>> Instead of using TreeNode in the TreeEditor I use MyTreeNode which
>>> inherits from TreeNode and overrides the get_view(self.object) method.
>>>
>>> Brennan
>>>
>>>>      - Create a psuedo-tree which presents a list of choices to the
>>> user, and
>>>> then when selections are made, it instantiate the corresponding classes.
>>>>
>>>>      - Save each object into a separate file then try to mimic the
>>> behavior
>>>> of the EPD demos, in which files are opened only upon selection.  (This
>>>> would be nice, but I fear I'd have trouble reverse engineering a
>>> program as
>>>> sophisticated as the demo).
>>>>
>>>> If anyone has a smart solution to this problem, please let me know.  Is
>>> it
>>>> possible, for example, to override the trait initializations in a
>>> HasTraits
>>>> object for performance reasons?  I just don't have the expertise to see
>>> an
>>>> obvious "best" resolution to my quandary.
>>>>
>>>> Thanks.
>>>> _______________________________________________
>>>> Enthought-Dev mailing list
>>>> [hidden email]
>>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>>>
>>> _______________________________________________
>>> Enthought-Dev mailing list
>>> [hidden email]
>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
>>>
>>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>

_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev
Reply | Threaded
Open this post in threaded view
|

Re: Tree Editor which does not initialize classes

Adam Hughes
Alright I'll check it out, thanks man.

On Wed, Nov 30, 2011 at 6:29 PM, Brennan Williams <
[hidden email]> wrote:

> On 1/12/2011 11:57 a.m., Adam Hughes wrote:
> > For the sake of completeness for the archive, let me put my final
> solution:
> >
> > Brennan, I followed your suggestion, and fit it to my needs.  For each of
> > my objects, I defined an "Adapter Object", basically an intermediate
> object
> > which contains an instance of the object in question as well as some
> > additional information.  Note this is not the Adapter object from
> > traits.api, so I probably should given it a custom name.  This is nice
> for
> > my purposes because:
> >
> >     1. It doesn't require me to change the source of the object.
> >     2. It separates ancillary information about the object from the
> object
> > itself.
> >
> > For example, if I had an object A which stores an array:
> >
> > class A(HasTraits):
> >     bigarray=Array
> >     _big_array_default(self): return np.empty( ( 100000), dtype=float)
> >
> > Then I will define an adapter class:
> >
> > class A_Adapter(HasTraits):
> >     obj=Instance(A)
> >     notes=Str("Here are some notes about this object")
> >     source=Str("I can provide the source if this object came from a
> paper,
> > for example")
> >
> >     def _populate_object(self):  self.obj=A()
> >     def _destroy_object(self): self.obj=None
> >
> > I then present the A_Adapter in the tree to the user, but when a
> selection
> > is made, the "populate_object" method is called before returning the
> object
> > to whatever routines are going to use it.  The "_destroy_object" method
> is
> > useful so that the tree doesn't keep objects open after the selection is
> > changed.
>
> Sounds good to me.
>
> You might want to take a look at...
>
> https://mail.enthought.com/pipermail/enthought-dev/2008-April/013970.html
>
> Your "adapter" object could also be a "viewmodel" object.
>
> In my app I have an object hierarchy of project-ensemble-deck and while
> the idea is to work 90% of the time in a project window with its own
> tree hierarchy I also want to be able to open each ensemble object in
> its own window with its own tree hierarchy. I struggled to do it until
> Dave Peterson explained how to create a ThingViewModel on the fly when I
> wanted to open a view on a Thing instance (or in my case, an ensemble
> instance).
>
> It seems to me that you could kill two birds with one stone here,
> solving your performance problem and easily being able to open one of
> your objects in a window with its own tree. Note that I only needed to
> do it this way because each of my objects had its own hierarchy that I
> also wanted to display using TreeNodes and TreeEditor.
>
> Brennan
>
> > On Wed, Nov 30, 2011 at 12:34 PM, Adam Hughes<[hidden email]
> >wrote:
> >
> >> Thanks Brennan.  I'll probably attempt this solution then, unless anyone
> >> else has some input.
> >>
> >>
> >> On Mon, Nov 28, 2011 at 6:11 PM, Brennan Williams<
> >> [hidden email]>  wrote:
> >>
> >>> On 29/11/2011 9:55 a.m., Adam Hughes wrote:
> >>>> Hey everyone,
> >>>>
> >>>> I have a series of HasTrait classes that I'd like to open with a tree
> >>>> editor.  One issue I have is that my objects are hefty in that they
> >>>> initialize with very large arrays by default.  Therefore, when I run a
> >>>> program which contains all of these objects, it is very slow.  In
> >>> practice,
> >>>> I'd like the user to select 1 or 2 of these objects to be imported,
> and
> >>>> only after this selection is made would the objects be instantiated.
> >>>   The
> >>>> only solutions I can think of offhand would be either:
> >>>>
> >>>>      - Rewrite my objects to not initialize until some special
> condition
> >>> is
> >>>> realized, probably in the form of a boolean variable.
> >>> That's what I do. I have a hierachy of objects which like yours have
> >>> some fairly big arrays in them or else a substantial child hierarchy
> >>> that I don't want loaded immediately. So  I have a "loaded" boolean for
> >>> each of my big objects. When you click on the object instance in the
> >>> tree it creates the view for that object to display in the right hand
> >>> side pane. So the object has a "def create_view(self)" method which not
> >>> only creates the view but also loads the data for that object instance
> >>> if "loaded" is False.
> >>>
> >>> Instead of using TreeNode in the TreeEditor I use MyTreeNode which
> >>> inherits from TreeNode and overrides the get_view(self.object) method.
> >>>
> >>> Brennan
> >>>
> >>>>      - Create a psuedo-tree which presents a list of choices to the
> >>> user, and
> >>>> then when selections are made, it instantiate the corresponding
> classes.
> >>>>
> >>>>      - Save each object into a separate file then try to mimic the
> >>> behavior
> >>>> of the EPD demos, in which files are opened only upon selection.
>  (This
> >>>> would be nice, but I fear I'd have trouble reverse engineering a
> >>> program as
> >>>> sophisticated as the demo).
> >>>>
> >>>> If anyone has a smart solution to this problem, please let me know.
>  Is
> >>> it
> >>>> possible, for example, to override the trait initializations in a
> >>> HasTraits
> >>>> object for performance reasons?  I just don't have the expertise to
> see
> >>> an
> >>>> obvious "best" resolution to my quandary.
> >>>>
> >>>> Thanks.
> >>>> _______________________________________________
> >>>> Enthought-Dev mailing list
> >>>> [hidden email]
> >>>> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >>>>
> >>> _______________________________________________
> >>> Enthought-Dev mailing list
> >>> [hidden email]
> >>> https://mail.enthought.com/mailman/listinfo/enthought-dev
> >>>
> >>
> > _______________________________________________
> > Enthought-Dev mailing list
> > [hidden email]
> > https://mail.enthought.com/mailman/listinfo/enthought-dev
> >
>
> _______________________________________________
> Enthought-Dev mailing list
> [hidden email]
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
_______________________________________________
Enthought-Dev mailing list
[hidden email]
https://mail.enthought.com/mailman/listinfo/enthought-dev