headers
Danny Shevitz | 15 Jul 19:48

traits update broke my app

>

Howdy, 

I'm not sure how to proceed with this one. I updated to the latest
trunk version of /TUI. It has been a while (read months) since my last update. 
My app, which was working fine, is now broken. 

The breaking happens when drag and dropping an object off my tool palette onto
a tree editor. I went into fbi and tried to figure out what's going on. I think
the issue may be related to the handling of trait list events. IIUC, when you
have TraitListEvents, the calling signature could be
@on_trait_change('sub_contexts')
def prototype(self, object, name, old, new) 

except old never had value if new was a TraitListEvent. This seems to be 
causing problems now, although I don't know why. Any ideas?

thanks,
D

The traceback is:

Exception occurred in traits notification handler.
Please check the log file for details.
Exception occurred in traits notification handler for object: <elm_objects.Exten
dableContext object at 0x02DEAB70>, trait: sub_contexts, old value: <undefined>,
 new value: <enthought.traits.trait_handlers.TraitListEvent object at 0x02F25DF0
>
Traceback (most recent call last):
(Continue reading)

Permalink | Reply |
headers
Danny Shevitz | 15 Jul 21:39

probable bug in @on_trait_change with delegated lists


> I'm not sure how to proceed with this one. I updated to the latest
> trunk version of /TUI. It has been a while (read months) since my last update. 
> My app, which was working fine, is now broken. 

I was able to do some isolation and I managed to locate the source of the
traceback. In either my handler or object code if I put the following block
in my code, I get the error.

@on_trait_change('info:object:root:sub_contexts*') 
def tree_handler_sub_contexts(self, object, name, new): 
  print "fired tree_handler_sub_contexts", object, name, new

I get the traceback:

--------------------------------------------------------
fired tree_handler_sub_contexts <elm_objects.ExtendableContext object at 0x02B63
870> sub_contexts <enthought.traits.trait_handlers.TraitListEvent object at 0x02
D3DF30>
Exception occurred in traits notification handler.
Please check the log file for details.
Exception occurred in traits notification handler for object: <elm_objects.Exten
dableContext object at 0x02B63870>, trait: sub_contexts, old value: <undefined>,
 new value: <enthought.traits.trait_handlers.TraitListEvent object at 0x02D3DF30
>
Traceback (most recent call last):
  File "d:\enthought\checkouts\traits_3.0.0b1\enthought\traits\trait_notifiers.p
y", line 580, in rebind_call_4
    object, trait_name, old, new )
  File "d:\enthought\checkouts\traits_3.0.0b1\enthought\traits\trait_notifiers.p
(Continue reading)

Permalink | Reply |
headers
Danny Shevitz | 15 Jul 22:54

Re: probable bug in @on_trait_change with delegated lists


> The subtlety is that in my code sub_contexts are delegated through a
> LogicElement via:
> context.sub_contexts = context.logic_element.sub_contexts
> 
> I have a similar version of the code that does not use delegation and does not
> show the bug. It would seem that the bug is in the combination of catching 
> changes to a delegated list using the '*' pattern.

More debugging...

If I had to guess, I think that the bug is that the pattern
@on_trait_change('object:list*') 

when 'list' is delegated, is causing the wrong handler in traits_listener
to be used. I think traits_listener.py:522 "handle_list_items" should be used
but traits_listener.py:506 "handle_list" is being used instead. The result
is that handle_list is being handed old=Undefined, new=TraitListObject instead
of old=List, new=List.

I'm not sure why this is happening though...

D
Permalink | Reply |
headers
Danny Shevitz | 16 Jul 00:45

Re: probable bug in @on_trait_change with delegated lists


> I'm not sure why this is happening though...

I have determined that my code worked with rev 18437 and failed with rev 18438.

After trapping, I was expecting to see the app work in the earlier version and
drag and drop fail in the later version, but that is not what happened. In fact
the app aborts immediately in rev 18438. The gui never even opens. Then in rev
18441 the app opens but my drag and drop fails in the way documented. So to
summarize (revs):
18437 is good
18438 app fails to run
18441 app runs but @on_trait_change('object.delegate_list*') fails.

The traceback at rev 18438 is:

Traceback (most recent call last):
  File "D:\logicModels\code\logicModels\ELMTree2.py", line 28, in <module>
    ui = the_app.configure_traits(view = app_view, handler=AppHandler(model=the_
app))
  File "d:\enthought\checkouts\traits_3.0.0b1\enthought\traits\has_traits.py", l
ine 2396, in configure_traits
    kind, handler, id, scrollable, args )
  File "d:\enthought\checkouts\traitsbackendwx_3.0.0b1\enthought\traits\ui\wx\to
olkit.py", line 197, in view_application
    id, scrollable, args )
  File "d:\enthought\checkouts\traitsbackendwx_3.0.0b1\enthought\traits\ui\wx\vi
ew_application.py", line 73, in view_application
    scrollable, args ).ui.result
  File "d:\enthought\checkouts\traitsbackendwx_3.0.0b1\enthought\traits\ui\wx\vi
(Continue reading)

Permalink | Reply |
headers
David C. Morrill | 16 Jul 00:47

Re: probable bug in @on_trait_change with delegated lists

Danny Shevitz wrote:
>> The subtlety is that in my code sub_contexts are delegated through a
>> LogicElement via:
>> context.sub_contexts = context.logic_element.sub_contexts
>>
>> I have a similar version of the code that does not use delegation and does not
>> show the bug. It would seem that the bug is in the combination of catching 
>> changes to a delegated list using the '*' pattern.
>>     
>
> More debugging...
>
> If I had to guess, I think that the bug is that the pattern
> @on_trait_change('object:list*') 
>
> when 'list' is delegated, is causing the wrong handler in traits_listener
> to be used. I think traits_listener.py:522 "handle_list_items" should be used
> but traits_listener.py:506 "handle_list" is being used instead. The result
> is that handle_list is being handed old=Undefined, new=TraitListObject instead
> of old=List, new=List.
>
> I'm not sure why this is happening though...
>
>   

I'm not sure why you think that is the wrong handler, especially when 
the 'new' value is a TraitListObject? If 'new' were a TraitListEvent 
object, then your conjecture would have some merit. See my previous post 
about setting a default Property value...
(Continue reading)

Permalink | Reply |
headers
Danny Shevitz | 16 Jul 00:59

Re: probable bug in @on_trait_change with delegated lists


> I'm not sure why you think that is the wrong handler, especially when 
> the 'new' value is a TraitListObject? If 'new' were a TraitListEvent 
> object, then your conjecture would have some merit. See my previous post 
> about setting a default Property value...
> 
> Dave Morrill
> 

my bad, new *is* a TraitListEvent, not a TraitListObject as written, so I
believe my comment has merit.

As for sub_contexts, it is defined via

class ExtendableGate(HasStrictTraits):
  sub_contexts = List

class ExtendableContext(HasStrictTraits):
  logic_element= Instance('ExtendableGate')
  sub_contexts = Delegate('logic_element', modify=True)

D
Permalink | Reply |
headers
David C. Morrill | 16 Jul 01:13

Re: probable bug in @on_trait_change with delegated lists

Danny Shevitz wrote:
>> I'm not sure why you think that is the wrong handler, especially when 
>> the 'new' value is a TraitListObject? If 'new' were a TraitListEvent 
>> object, then your conjecture would have some merit. See my previous post 
>> about setting a default Property value...
>>
>> Dave Morrill
>>
>>     
>
> my bad, new *is* a TraitListEvent, not a TraitListObject as written, so I
> believe my comment has merit.
>  
> As for sub_contexts, it is defined via
>
> class ExtendableGate(HasStrictTraits):
>   sub_contexts = List
>
> class ExtendableContext(HasStrictTraits):
>   logic_element= Instance('ExtendableGate')
>   sub_contexts = Delegate('logic_element', modify=True)
>
>   

Hmm...might bear some looking into. I'm still not clear what is 
happening in your app when the notification error occurs. Which trait is 
being modified, and how? I probably won't have time to look into it 
today, but will try and do so tomorrow...

Dave Morrill
(Continue reading)

Permalink | Reply |
headers
Danny Shevitz | 16 Jul 04:34

Re: probable bug in @on_trait_change with delegated lists


> Hmm...might bear some looking into. I'm still not clear what is 
> happening in your app when the notification error occurs. Which trait is 
> being modified, and how? I probably won't have time to look into it 
> today, but will try and do so tomorrow...

I'm out of the office tomorrow, so I won't be able to help again until thursday.

Here's the story.
1) The tree is displayed with a hidden root and is visually empty.
2) I drag an extendable gate off my gate palette onto the empty tree.
3) that's it. The error appears there after this initial append to
the root operation. Visually, the new gate appears on the screen but there is
a subsequent exception.

I am trying to modify the sub_contexts of the root. 

The error is in any handler of the form
@on_trait_change('x:sub_contexts*:y') including x in ['self.info', 'tree', 
'object'] or y in ['','is_terminated',...] as long as it includes :sub_contexts*

the exception is not in the handler. The code can be 'pass' and the error 
appears. The error is caused by the *existence* of the handler, not the handler
code.

The stack frame in fbi is conceptually (bottom first...)
1)trait_listener: handle_list (should be handle_list_item, I think)
1.5) catch change to sub_contexts (lots of callbacks here)
2)node.append_child
3)tree_editor._undoable_append
(Continue reading)

Permalink | Reply |
headers
David C. Morrill | 16 Jul 00:41

Re: traits update broke my app

Danny Shevitz wrote:
>
> Howdy, 
>
> I'm not sure how to proceed with this one. I updated to the latest
> trunk version of /TUI. It has been a while (read months) since my last update. 
> My app, which was working fine, is now broken. 
>   

Try doing an svn unupdate :-)

On a more serious note...as written, you would not be receiving 
TraitListEvent objects for 'new', since those are only generated for the 
'foo_items' pseudo trait. Also, it's hard to tell from just two lines of 
code, but how is 'sub_contexts' defined? Is it a List, or a property 
whose value is a list? If it's the later, you may have a problem dealing 
with the pre-default value (i.e. Undefined). One of the changes that has 
occurred in the last month or so is the ability to define default values 
for Properties. Setting a default value of an empty list will probably 
fix your problem in this case...

Dave Morrill
> The breaking happens when drag and dropping an object off my tool palette onto
> a tree editor. I went into fbi and tried to figure out what's going on. I think
> the issue may be related to the handling of trait list events. IIUC, when you
> have TraitListEvents, the calling signature could be
> @on_trait_change('sub_contexts')
> def prototype(self, object, name, old, new) 
>
> except old never had value if new was a TraitListEvent. This seems to be
(Continue reading)

Permalink | Reply |
headers
Danny Shevitz | 17 Jul 17:11

Re: traits update broke my app

I'm back in the office. Have you had a chance to look at this? What can I do
to help?

D
Permalink | Reply |
headers
David C. Morrill | 18 Jul 01:54

Re: traits update broke my app

Danny Shevitz wrote:
> I'm back in the office. Have you had a chance to look at this? What can I do
> to help?
>
> D
>
> _______________________________________________
> Enthought-dev mailing list
> Enthought-dev@...
> https://mail.enthought.com/mailman/listinfo/enthought-dev
>
>   
I've been working on closing Traits 3.0 tickets. Hopefully, I'll get to 
your problem sometime tomorrow...

Dave Morrill
Permalink | Reply |

Gmane