headers
Ateljevich, Eli | 1 May 2008 01:49
Picon
Favicon

Re: development releases of chaco, envisage and traits


Thanks to everyone for the suggestions. I needed to blow away enstaller
and easy_install it again then things worked fine... or at least, I am
on track. 

I have just a few follow-up questions:
1. Each ets checkout using ETSProjectTools of a major package (Chaco,
EnvisageCore...) seems to check out all the dependencies of that tool
and these include Traits. These are redundant between ETS and Chaco and
seem to be mutually compatible judging by version numbers. Is that true?
2. EnvisageCore and EnvisagePlugins seem to omit repository and
single_project, on which I am dependent.
   a. Is there hope of backward compatibility +/- minor modification?
Are the fates of these plugins sketchy?
   b. If the old plugins can't work with the new envisage, is envisage 2
going to play well with chaco 3.0 and traits 3.0 (and their back end
tools)? This would be my second choice, of course.

Thanks!
Eli

> -----Original Message-----
> From: enthought-dev-bounces@... [mailto:enthought-dev-
> bounces@...] On Behalf Of Dave Peterson
> Sent: Tuesday, April 29, 2008 3:54 PM
> To: eli-sava@...; enthought-dev@...
> Subject: Re: [Enthought-dev] development releases of chaco,envisage
and
> traits
>
(Continue reading)

Permalink | Reply | 8 comments |
headers
Gael Varoquaux | 1 May 2008 02:22
Favicon
Gravatar

Re: Installing from svn on Ubuntu 8.04

On Wed, Apr 30, 2008 at 04:42:17PM -0500, jason-enthought@... wrote:
> In addition, one thing that we at Sage have been working on recently is 
> adding interactive controls to the online Sage notebook (in fact, this 
> work was initially done while William was at Enthought in February!).  
> While the current online interactive controls work nicely for what they 
> are, they still are not up to par with the recent competition (the 
> Mathematica dynamic and manipulate functionality).  Of course, chaco and 
> mayavi have been able to do these sorts of things for a long time, 
> thanks to the work done on the traits framework.

Nice to see that you have captured the "big thing" we are excited about
with the ETS.

> Building on the tremendous work that you guys have done hopefully would
> allow us to have the interactivity we have recently been very
> interested in and also eventually build quite a nice notebook frontend
> to Sage.

I can see a difficulty here: all the ETS is GUI-based. You can run it
with a wx backend or a Qt backend, but it is GUI-based, and I think it
won't be easy to keep the interactivity moving to a web-based backend
like it is used in Sage.

I do see one way out, which is to create a GUI notebook interface (as
opposed to web-based). Different people are slowly assembling the
components for that. For instance Ipython1 is very slowly moving towards
being embeddable in a GUI. And it also has a start of a notebook model. I
choose to contribute to the basic tools, like Ipython1 and Mayavi in
order to get them in a right shape to assemble this interface, but
hopefully one day it will be possible effortless.
(Continue reading)

Permalink | Reply | 7 comments |
headers
jason | 1 May 2008 04:07

Re: Installing from svn on Ubuntu 8.04

Gael Varoquaux wrote:
> On Wed, Apr 30, 2008 at 04:42:17PM -0500, jason-enthought@... wrote:
>   
>> In addition, one thing that we at Sage have been working on recently is 
>> adding interactive controls to the online Sage notebook (in fact, this 
>> work was initially done while William was at Enthought in February!).  
>> While the current online interactive controls work nicely for what they 
>> are, they still are not up to par with the recent competition (the 
>> Mathematica dynamic and manipulate functionality).  Of course, chaco and 
>> mayavi have been able to do these sorts of things for a long time, 
>> thanks to the work done on the traits framework.
>>     
>
> Nice to see that you have captured the "big thing" we are excited about
> with the ETS.
>
>   

I got *really* excited about the Mathematica interactivity stuff in
version 6.  Several months later, I found out that you guys had similar
stuff all along.

Actually, I got excited about programming using GLUT a long time ago too
because of the dynamic variables that manipulated the GUI.

>> Building on the tremendous work that you guys have done hopefully would
>> allow us to have the interactivity we have recently been very
>> interested in and also eventually build quite a nice notebook frontend
>> to Sage.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cyril Giraudon | 1 May 2008 09:47
Picon
Favicon

Re: enthought units and decibel

Gael Varoquaux a écrit :
> On Wed, Apr 30, 2008 at 10:20:40AM +0200, cyril giraudon wrote:
>   
>> Yes, i have to do some conversions.
>> In fact, the decibels we use are not guenine decibels.
>> They are not dimensionless.
>>     
>
>   
>> For instance, given a tension v = 1e-6V, then v = 20 log10(1e-6 V/ 1e-6)
>> dBuV = 0 dBuV
>> v = 1e-6 V = 0 dBuV
>> (u = micro = 1e-6)
>>     
>
> What's the difference between this and dBm?
>   
I'm not sur but:

dBm is used for Watt, so dBm = dBmW
dBuV = dBmV + 60
dBuV is in volt, we could think it's dimensionless, but it is used when 
volt are awaited (In electromagnetic compatibility (EMC) for instance).

I don't know how to subclass the volt familly and to add the conversion 
operation.

Thanks,

Cyril.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Prabhu Ramachandran | 1 May 2008 12:12
Picon
Gravatar

Re: Installing from svn on Ubuntu 8.04

jason-enthought@... wrote:
> 
> and now mayavi2 works fine.  I'm still curious how I can get traits 
> 2.0.4 to compile, though.
> 
> Is there any sort of rough timeframe for mayavi2 working under ets 3.0?

I hope to have this done with at least a very crude version by the 
weekend.  My first priority (on the mayavi2 front) is to get the trunk 
running with Envisage3.

cheers,
prabhu
Permalink | Reply | 0 comments |
headers
Martin Chilvers | 1 May 2008 12:48
Picon

Envisage 3.x: Proposal to change/extend service registration...

G'day,

Currently, services are application wide, and plugins register them either manually, or via a trait 
using the 'service=True' metadata:-

e.g.

class MyPlugin(Plugin):
     def register_services(self):
         self.application.register_service(IFoo, Foo())
         return

or

class MyPlugin(Plugin):
     foo = Instance(IFoo, service=True)

     def _foo_default(self):
         return Foo()

etc

There are a number of problems with the current approach:-

- as pointed out by Tony, the first problem is that although the plugin is 'contributing' the 
service, it doesn't use the usual extension point mechanism to do the actual contribution, which 
just adds 'one more thing' to remember...

- when using the workbench (or for any GUI application) services are often used as models that 
coordinate between views. Since the workbench allows multiple top-level windows, we therefore need
(Continue reading)

Permalink | Reply | 14 comments |
headers
Gael Varoquaux | 1 May 2008 12:55
Favicon
Gravatar

Re: Envisage 3.x: Proposal to change/extend service registration...

On Thu, May 01, 2008 at 11:48:37AM +0100, Martin Chilvers wrote:
> Thoughts?

Sounds good. But I can't claim to have much insight on this.

Gaël
Permalink | Reply | 0 comments |
headers
Martin Chilvers | 1 May 2008 13:04
Picon

Envisage 3.x: Sneaky globals...

G'day,

While talking with Gael a while ago, I realised that although Envisage 3.x removed the old blatant 
global (from enthought.envisage.api import get_application), some of the syntactic sugar for 
extension points and services had in fact introduced a sneaky global...

e.g.

class MyPlugin(Plugin):
     foogles = ExtensionPoint(List(IFoogle), id='acme.foogles')

The 'ExtensionPoint' (and the 'Service') trait type work because they have a global reference to a 
global extension/service registry. When an Envisage application is created, it registers itself in 
both of those roles and everything looks just dandy...

Now on the plus side, this means that objects other than plugins can use the trait types without 
having to pass the application around everywhere (the workbench window is one such example), but on 
the other hand it means that there can only be one 'application' per process at any time (you can 
however create new applications oen after another of course otherwise we wouldn't be able to write 
the test cases!)...

I would like to make the 'ExtensionPoint' and 'Service' trait types work by looking up the 
appropriate registry trait on the object they are used in i.e. 'obj.extension_registry' etc. This 
means that they would only work in objects that can get a reference to the registries (usually 
provided by the application), but I don't actually see that as such a big problem since the 
application shouldn't be passed around very deeply into the object model anyway (otherwise you have 
tied your object model to Envisage!)...

So my question is, if I make this change how many people will be effected (i.e. are you using the 
'ExtensionPoint' and/or 'Service' trait types outside of a plugin?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin Chilvers | 1 May 2008 13:06
Picon

Envisage 3.x: Lifecycle events...

G'day,

While working on the window scoped service issue I needed to listen for when a top-level window is 
created. Now the Envisage workbench already fires the necessary 'window_opening', 'window_opened' 
etc events, but that still means that anybody who is interested in these events has to make sure 
that they have a reference to the workbench...

My thought is that important framework lifecycle events like this are great candidates for an 'event 
bus' so that an interested plugin can simply subscribe to the event bus for the appropriate event 
without the need to reference the workbench explicitly...

Thoughts?

Martin
Permalink | Reply | 12 comments |
headers
Gael Varoquaux | 1 May 2008 13:08
Favicon
Gravatar

Re: Envisage 3.x: Lifecycle events...

On Thu, May 01, 2008 at 12:06:09PM +0100, Martin Chilvers wrote:
> My thought is that important framework lifecycle events like this are
> great candidates for an 'event bus' so that an interested plugin can
> simply subscribe to the event bus for the appropriate event without the
> need to reference the workbench explicitly...

> Thoughts?

Sounds interesting. I gather you have studied the DBUS api, to see what
can be learnt from it.

Cheers,

Gaël
Permalink | Reply | 3 comments |

Gmane