[SPAM] Re: [Envisage-dev] Wierd VTK/wxPython behavior under Linux

Prabhu,

>Now, if I change the order of imports and import pyface before I
>import traits, i.e. in the following order.
>
> from enthought.pyface import GUI
> from enthought.tvtk.tools import ivtk
>
>Then everything works.  Alternatively, if I use a cvs build of VTK
>then things work without changing the import order.  I suspect a clash
>in the libraries that are imported but the error and the solution are
>really wierd.
>
>Has anyone run into an error like this before?
>  
>
While I haven't ever seen this specific error before, I think I know 
what the problem is.  In wx 2.6, fonts (and other things such as colors) 
are not available until a wx.App object is created.  This caused us fits 
in things like Envisage and Traits UI.  We (martin and i) went around 
and around trying to figure out how to make this work.  In the end, we 
decided to just create a bogus wx.App object in Pyface.

It looks like the built version of tvtk tries to get a font from wx, but 
that fails because the App object is not up yet.  If you import Pyface 
first, you get our hack.  In CVS they may have fixed the code to acquire 
the font after import (not during import).

Does this make sense?

Re: [SPAM] Re: [Envisage-dev] Wierd VTK/wxPython behavior under Linux

Hi Brandon,

>>>>> "Brandon" == Brandon DuRette <bdurette@...> writes:

    >> Now, if I change the order of imports and import pyface before
    >> I import traits, i.e. in the following order.
[...]
    >> Has anyone run into an error like this before?
[...]
    Brandon> It looks like the built version of tvtk tries to get a
    Brandon> font from wx, but that fails because the App object is
    Brandon> not up yet.  If you import Pyface first, you get our
    Brandon> hack.  In CVS they may have fixed the code to acquire the
    Brandon> font after import (not during import).
    Brandon> Does this make sense?

Thanks for the response.  I am not sure that this is the issue.
Perhaps more discussion will clear this up.  My main problems with
this theory is that:

 1. TVTK to my knowledge does not try to query for any wx fonts.
    Neither does VTK.  However, TVTK imports a few names from
    enthought.traits.ui (in tvtk/tvtk_base.py).  Thus, if traits.ui
    is trying to lookup a font then this might explain the problem.

 2. If the font error is one from wxPython then you get a different
    error message.  One usually gets a wx.App not started error in
    these cases.  In my case the error is from Pango and occurs at
    library load time (atleast thats what I remember of the strace
    output I looked at).  So this is definitely NOT a normal wxPython

[Envisage-dev] removed some functions from Enable

Hi everyone,

I've removed some DisplayPDF-incompatible drawing methods from the Enable 
drawing layer.  These functions involve clipping and alpha (transparency) 
manipulation.  I've fixed all the references to them that I could find, and 
I've tested CPLab and several Chaco and Enable example programs, but please 
exercise your apps (e.g. ProAVA, pressure, rheology) and let me know if you 
guys find any visual weirdness.

Thanks,
Peter

[Envisage-dev] dynamic trait event listeners

Hey guys,

What is the general strategy for cleaning up dynamic trait event 
listeners?  I was wiring one up today and realized that I would have to 
write a destructor to handle unwiring it when my object is destroyed.  I 
looked elsewhere in our codebase and noticed that people were attaching 
dynamic trait event listeners but never detaching them.  Is there 
something I'm missing?

-peter

[SPAM] Re: [Envisage-dev] dynamic trait event listeners

Peter,

> Is there something I'm missing? 

Dave M., is the arbiter of all things traits, so I'm sure he'll correct 
me if I'm wrong.  But, IIRC, traits keeps the trait listeners in a map 
using weak references.  When the reference goes away (i.e., the object 
was destroyed), traits unwires the listener for you.  IOW, you don't 
have to unwire them directly.

Cheers,
Brandon

Re: [SPAM] Re: [Envisage-dev] dynamic trait event listeners

Brandon DuRette wrote:

> IOW, you don't have to unwire them directly.

Thanks for the info.  We should probably put that in the traits manual 
somewhere, if this is the official and desired behavior.

[Envisage-dev] build_inplace

Hey everyone,

Right now in build_inplace.bat we blow away all existing pyc, pyd, and .o 
files before doing a full build.  I realized today that the mathtext package I 
checked in uses an external, pre-built .pyd file which has been checked into 
SVN.  The assumption that all .pyd files in /enthought can be rebuilt from 
source no longer holds, and we can't safely wipe out *.pyd across the tree.

It seems very hackish to modify build_inplace if what we really need is a 
per-package build_clean and build_inplace...

Thoughts?

-peter

Re: [Envisage-dev] build_inplace

the usual fix for this is to build into a directory other than your 
source directory, that way you don't mix your built files with pre-built 
ones, but they all wind up in the same place. i don't know how this 
usually applies to the python universe, but perhaps we could build all 
.pyd files to some other directory that then gets included in the python 
path?

jason

Peter Wang wrote:

> Hey everyone,
>
> Right now in build_inplace.bat we blow away all existing pyc, pyd, and 
> .o files before doing a full build.  I realized today that the 
> mathtext package I checked in uses an external, pre-built .pyd file 
> which has been checked into SVN.  The assumption that all .pyd files 
> in /enthought can be rebuilt from source no longer holds, and we can't 
> safely wipe out *.pyd across the tree.
>
> It seems very hackish to modify build_inplace if what we really need 
> is a per-package build_clean and build_inplace...
>
> Thoughts?
>
>
> -peter
> _______________________________________________
> Envisage-dev mailing list
> Envisage-dev@...

Re: [Envisage-dev] build_inplace

Peter Wang wrote:
> Hey everyone,
> 
> Right now in build_inplace.bat we blow away all existing pyc, pyd, and
> .o files before doing a full build.  I realized today that the mathtext
> package I checked in uses an external, pre-built .pyd file which has
> been checked into SVN.  The assumption that all .pyd files in /enthought
> can be rebuilt from source no longer holds, and we can't safely wipe out
> *.pyd across the tree.
> 
> It seems very hackish to modify build_inplace if what we really need is
> a per-package build_clean and build_inplace...

build_inplace always was a hack for development and has caused you guys
to *not include data files in the setup.py scripts* causing me and Joe
no end of pain when trying to make installers.  

One possibility for mathtext is to actually build the ft2font module
from source. You probably should be doing this anyways.

You might want to separate out the deleting from the building, since I'm
sure that most times you want to build_inplace, you don't want to build
everything. A build_clean.bat which knows to delete .pyd's from every
directory except mathtext would probably be fine.

build_inplace.bat always was and always will be a hack. You can't make
it worse, and there isn't much point in trying to make it better. If you
want a non-hack, just do a regular build/install.

--

-- 

Re: [Envisage-dev] build_inplace