[visionegg] Re: A few quibbles

Dav Clark wrote:
> Seems like I'm gravitating towards issues surrounding ve_types.
> 
> 1) VisionEgg.FlowControl.FunctionController calls during_go_function
> once on line 1222 during initialization to see what type it returns. 
> This is one issue that might be productively addressed by a switch to
> enthought.traits from ve_types.  I start some of my experiments in
> "paused" mode, so I need special logic in my update function to not
> modify graphical state the first time it is called.

Can you use the return_type kwarg? (Which I now see isn't documented in
the docstring for FunctionController.__init__ ... I just now added
documentation and some cleanups for it in r1475.)

> 
> This in turn makes testing a little wonky... there's a cascade of
> accomodation that has to occur if you do things this way.
> 
> I did figure out that a better way to do this would be to pass
> FunctionController an argument of
> 'return_type=VisionEgg.ParameterTypes.NoneType'.  But this was not
> obviously something I should do without reading code (which I don't
> mind, but will dissuade end-users, I recon).

Ahh, I see you can use the return_type kwarg but prefer not to... I'm
afraid I don't see an easy way out of this conundrum: You don't use
return_type to spare users the complexity of specifying return_type but
then are forced to have the complexity of accommodating a function call
to the controller so that it can automatically determine the return_type.

This sounds like a case where the VE attempting to help users through
type checking is actually hurting. I agree that, in the long run, this
kind of issue might be productively dealt with by using enthought.traits
and dropping the entire VisionEggParameterTypes module. Or do you see a
less drastic intermediate ground?

> 
> 2) In a related issue, I am using generator functions, with the "send"
> functionality to implement coroutines.  This is really nice and allows
> for clean presentation logic with a long, complicated sequence of
> stimuli.  However, the way the FunctionController is implemented, I need
> to create a wrapper which takes, for example, "t" as a named argument,
> and then passes it to "send" as a positional argument.

I'm not following you here. Why is that?

> In any case, updating data across classes is a place where Traits is
> quite good, and so this issue would perhaps be better addressed in some
> kind of HasTraitsController or similar.

Ahh, I see -- this is the intermediate ground, perhaps. An interesting
idea. I'm definitely interested.

> I post these to the list as a first-attempt at having these documented,
> but I'm happy to contribute to more formal docs someplace.  Maybe
> something on the wiki?

The best place will be the SVN repo -- either as docstrings or in the
programmer's manual at doc/visionegg.tex. I generate the on-web docs
from there, so that would be most consistent. A wiki page would be a
nice plus. Anyhow, if you send a patch I'll review it for inclusion, and
if it looks like you're going to send me more than one or two patches
that I would include, I'll give you commit rights to the SVN repo.

If you're working on a HasTraitsController, it may be nicest to put that
in its own module, so that we isolate enthought.traits dependencies for
now -- in my experience, the ETS can be a bit of a pain to install, and
if the functionality is not central (yet), I think we shouldn't force
users to install it. That decision could certainly be revisited, but if
it's simple enough not to introduce a new requirement, let's not.

-Andrew
======================================
The Vision Egg mailing list
Archives: http://www.freelists.org/archives/visionegg
Website: http://www.visionegg.org/mailinglist.html

Other related posts: