On Wednesday 07 November 2007 3:54:36 pm Darren Dale wrote:
> On Wednesday 07 November 2007 03:34:18 pm Eric Firing wrote:
> > Darren Dale wrote:
> > > I have been working on updating the trunk to provide enthought.traits
> > > version 2.6b1. backend_driver.py is running without exceptions using
>
On Wednesday 07 November 2007 03:34:18 pm Eric Firing wrote:
> Darren Dale wrote:
> > I have been working on updating the trunk to provide enthought.traits
> > version 2.6b1. backend_driver.py is running without exceptions using the
> > traited config package with the internal traits package.
> >
>
On Wed, Nov 07, 2007 at 10:34:18AM -1000, Eric Firing wrote:
> 1) If an internal version of traits is to be used, how hard would it be
> to patch it in such a way that it *could* be used externally?
I think pretty hard, but you would have to ask enthought's dev.
> 2) Does Gael's version already
On Wednesday 07 November 2007 09:25:51 am John Hunter wrote:
> On Nov 7, 2007 1:52 AM, Gael Varoquaux <[EMAIL PROTECTED]>
wrote:
> > On Tue, Nov 06, 2007 at 09:00:23PM -0500, Darren Dale wrote:
> > > I have not committed my work to svn yet. I wanted to get some feedback
> > > on points 1 and 2 fir
Darren Dale wrote:
> I have been working on updating the trunk to provide enthought.traits version
> 2.6b1. backend_driver.py is running without exceptions using the traited
> config package with the internal traits package.
>
> Issues:
>
> 1) there are lots of absolute package imports scattere
On Wednesday 07 November 2007 02:31:47 pm Christopher Barker wrote:
> Darren Dale wrote:
> > Does the way matplotlib handles pytz and datetime present significant
> > complications as well?
>
> not too bad, but pytz and datetime are already pretty easy to install,
> self-contained packages.
>
> > B
On Wednesday 07 November 2007 02:19:25 pm Eric Firing wrote:
> > But not all systems have a package manager, and not all package managers
> > have support for traits.
>
> Does *anything* or does *anyone* outside of enthought actually support
> traits now? I know Fernando has said he is sold on it
On Nov 7, 2007, at 12:08 PM, Darren Dale wrote:
>> I don't see the check-then-tarball as a feature, but as a significant
>> complication that I have to be aware of when I'm building MatPlotLib.
>
> Does the way matplotlib handles pytz and datetime present significant
> complications as well?
>
>>
Darren Dale wrote:
> Does the way matplotlib handles pytz and datetime present significant
> complications as well?
not too bad, but pytz and datetime are already pretty easy to install,
self-contained packages.
> But not all systems have a package manager, and not all package managers have
>
On Nov 7, 2007, at 12:04 PM, John Hunter wrote:
On Nov 7, 2007 12:01 PM, Boyd Waters <[EMAIL PROTECTED]> wrote:
Tell them they need a "real" enthought traits package. Then they can
use their package management to make it right.
This is of course assuming their package management has
enthoug
> But not all systems have a package manager, and not all package managers have
> support for traits.
Does *anything* or does *anyone* outside of enthought actually support
traits now? I know Fernando has said he is sold on it for ipython, but
I did not see it in the latest release.
While I
On Wednesday 07 November 2007 10:08:01 am william ratcliff wrote:
> And again, if MPL becomes "traitified", how will that effect users
> that need to roll executables for distribution?
We are considering changes that would require testing before we actually made
a release that would effect users.
On Wednesday 07 November 2007 01:01:52 pm Boyd Waters wrote:
> On Nov 7, 2007, at 7:25 AM, John Hunter wrote:
> > Is there a reason not to treat
> > traits like we do dateutil and pytz: check at runtime if it is
> > installed and if not install it as enthought.traits using Gael's
> > tarball?
>
> I
On Nov 7, 2007 12:01 PM, Boyd Waters <[EMAIL PROTECTED]> wrote:
> Tell them they need a "real" enthought traits package. Then they can
> use their package management to make it right.
This is of course assuming their package management has
enthought.traits, which by and large, it won't.
I am sym
On Nov 7, 2007, at 7:25 AM, John Hunter wrote:
> Is there a reason not to treat
> traits like we do dateutil and pytz: check at runtime if it is
> installed and if not install it as enthought.traits using Gael's
> tarball?
I don't see the check-then-tarball as a feature, but as a significant
On Wed, Nov 07, 2007 at 08:25:51AM -0600, John Hunter wrote:
> I am not wild on the idea of an "internal dependency". Since this is
> the first step in providing traitified mpl properties, and users will
> presumably want to be able to set event handlers on these properties,
> etc, it seems best t
And again, if MPL becomes "traitified", how will that effect users
that need to roll executables for distribution?
On Nov 7, 2007 9:39 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 07, 2007 at 08:25:51AM -0600, John Hunter wrote:
> > I am not wild on the idea of an "internal depende
On Nov 7, 2007 1:52 AM, Gael Varoquaux <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 06, 2007 at 09:00:23PM -0500, Darren Dale wrote:
> > I have not committed my work to svn yet. I wanted to get some feedback on
> > points 1 and 2 first. Is it acceptable to use traits internally, but not
> > expose it t
I have done some preliminary testing with the new changes to
mathtext. The STIX fonts and Arev Sans fonts (still my favorite)
both work well and produce pdf files that are readable by standard
readers (e.g., Preview) and Illustrator. I am using Mac OS X, with
the TkAgg backend.
Nice wo
Hi,
I'm sorry to ask for help as a new user by this maillist. I sent a message
to user list, but there is no answer over one week.
The problem is: for my code, If I press 'x' or 'y' while panning, the
motion still don't be constrained to the x or y axis respectively. The
feature is important to
20 matches
Mail list logo
