Michael Droettboom | 1 Jun 14:51

Re: gtk versions: drop support for less than 2.4?

I'm +1 on dropping support for gtk+ < 2.4 (if even later).  Those 
multiple code paths were a pain, and installing multiple versions of 
gtk+ for testing is also something I'd like to stop doing.

Cheers,
Mike

Eric Firing wrote:
> We still require only gtk 2.2, and consequently carry around some extra 
> chunks of code to support versions before 2.4.  Can we drop this and 
> require 2.4 or later?  Or possibly even a later version?  It looks like 
> 2.4 came out in the fall of 2004.
>
> Eric
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
> is a gathering of tech-side developers & brand creativity professionals. Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
> iPhoneDevCamp as they present alongside digital heavyweights like Barbarian 
> Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel@...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>   

--

-- 
Michael Droettboom
Science Software Branch
(Continue reading)

Eric Firing | 1 Jun 19:17
Favicon
Gravatar

Re: gtk versions: drop support for less than 2.4?

Michael Droettboom wrote:
> I'm +1 on dropping support for gtk+ < 2.4 (if even later).  Those 
> multiple code paths were a pain, and installing multiple versions of 
> gtk+ for testing is also something I'd like to stop doing.
> 
> Cheers,
> Mike

Done.

Eric

> 
> Eric Firing wrote:
>> We still require only gtk 2.2, and consequently carry around some 
>> extra chunks of code to support versions before 2.4.  Can we drop this 
>> and require 2.4 or later?  Or possibly even a later version?  It looks 
>> like 2.4 came out in the fall of 2004.
>>
>> Eric
>>
>> ------------------------------------------------------------------------------ 
>>
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT 
>> is a gathering of tech-side developers & brand creativity 
>> professionals. Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, & 
>> iPhoneDevCamp as they present alongside digital heavyweights like 
>> Barbarian Group, R/GA, & Big Spaceship. 
>> http://p.sf.net/sfu/creativitycat-com 
(Continue reading)

Andrew Straw | 1 Jun 23:56
Picon
Gravatar

Re: arbitrary spine locations in svn trunk

Thanks everyone for the feedback. I have made Spine subclass Patch in
svn r7170, which I just committed.  This resulted in a slight API
change, but addresses most of the more substantial points raised.

The slight API change is that spine.set_color() is now
spine.set_edgecolor().

More below.

> On Thu, May 28, 2009 at 9:18 PM, John Hunter <jdh2358@...> wrote:
>> You do an isinstance(arg, basestring) to check for string input.
>> Typically, we encourage cbook.is_string_like to have a central point
>> of maintenance and consistency for these checks.

fixed in r7169

>> Also, in the example, you appear to turn off a spine by setting the
>> color to 'none'.  My thought it would be more natural to use the
>> "visible" artist property here (or at least support both)

I think this is addressed naturally by the new "Spine is a Patch" behavior.

>> Also, I think the class of strings representing "no color" in mpl is
>> larger -- it should also include self.color.lower()=='none' and the
>> empty string, which I've included in the example code.

Same for this. Now there's a single point of failure in the Patch.draw()
method.

Jae-Joon Lee wrote:
(Continue reading)

Eric Firing | 2 Jun 00:32
Favicon
Gravatar

Re: arbitrary spine locations in svn trunk

Andrew Straw wrote:
> Thanks everyone for the feedback. I have made Spine subclass Patch in
> svn r7170, which I just committed.  This resulted in a slight API
> change, but addresses most of the more substantial points raised.
> 
> The slight API change is that spine.set_color() is now
> spine.set_edgecolor().

But spine.set_color() is much more natural and easy to remember, so 
maybe it can be restored:

Collections have had a set_color() for a long time, and I don't see any 
reason Patch shouldn't have the same, so I added it.  My first thought 
was that this would have no effect on spines except to permit the 
alternative and more natural "spine.set_color()" to work like 
set_edgecolor, but now I see that this is not true--in the case of a 
circular spine, calling set_color(c) would have the unintended effect of 
filling the circle.  I still think having the set_color method in Patch 
and Spine is good, so what I propose is that Spine override the Patch 
version with a simple alias to set_edgecolor.

Eric

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
(Continue reading)

Andrew Straw | 2 Jun 00:40
Picon
Gravatar

Re: arbitrary spine locations in svn trunk

Eric Firing wrote:
> Andrew Straw wrote:
>> The slight API change is that spine.set_color() is now
>> spine.set_edgecolor().
> 
> But spine.set_color() is much more natural and easy to remember, so 
> maybe it can be restored:

Good idea. I just re-added Spine.set_color() and changed the example back.

-Andrew

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
Tom Loredo | 2 Jun 06:49
Picon
Favicon

mplot3d - text3D replacement?


Hi-

I'm sorry if this should be in mpl-users; since mplot3d is a work
in progress and not documented I thought the question might
better fit mpl-devel.

I'm trying to migrate some old code that used matplotlib.axes3d to
use mpl_toolkits.mplot3d.axes3d.  For an axes3d instance ax, it
used the ax.text3D method to place labels on the 3-D axes.  Is
there a counterpart for mplot3d.axes3d?  The only similar method I see
there is text(), which only takes an (x, y) position instead of
an (x,y,z) position.

Thanks,
Tom

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
Fernando Perez | 2 Jun 07:21
Picon
Gravatar

Tutorial topics for SciPy'09 Conference

Hi all,

The time for the Scipy'09 conference is rapidly approaching, and we
would like to both announce the plan for tutorials and solicit
feedback from everyone on topics of interest.

Broadly speaking, the plan is something along the lines of  what we
had last year: one continuous 2-day tutorial  aimed at introductory
users, starting from the very basics, and in parallel a set of
'advanced' tutorials, consisting of a series of 2-hour sessions on
specific  topics.

We will request that the presenters for the advanced tutorials keep
the 'tutorial' word very much in mind, so that the sessions really
contain hands-on learning work and not simply a 2-hour long slide
presentation.  We will  thus require that all the tutorials will be
based on tools that the attendees can install at least 2 weeks in
advance on all  platforms (no "I released it last night" software).

With that in mind, we'd like feedback from all of you on possible
topics for the advanced tutorials.  We have space for 8 slots total,
and here are in no particular order some possible topics.  At this
point there are no guarantees yet that we can get presentations for
these, but we'd like to establish a first list of preferred topics to
try and secure the presentations as soon as possible.

This is simply a list of candiate topics that various people have
informally suggested so far:

- Mayavi/TVTK
(Continue reading)

Charlie Moad | 2 Jun 14:59
Picon

Re: Sourceforge - lost windows binaries

I can't say that I have them.  Petr, you can use 98.5.3 binaries found
here, "http://drop.io/tvuqe3o".  Just keep in mind that png operations
will fail.

On Sat, May 30, 2009 at 2:14 PM, John Hunter <jdh2358@...> wrote:
> On Fri, May 29, 2009 at 9:44 PM, Petr Marhoun
<petr.marhoun@...> wrote:
>> Hello,
>>
>> Few days ago there were new windows binaries on Sourceforge - version
>> 0.98.5.3. Yesterday I also found them in Google cache (see the
>> attachment - I am interested mainly in Python 2.6).
>>
>> But they are not now on Sourceforge. Is there a good reason for it
>> (for example there could be problematic)? Or is it a Sourceforge
>> mistake (I am not sure but I think that design of the Sourceforge
>> download page was different)?
>>
>> Maybe there is another explanation - but if it is possible, could
>> windows binaries be uploaded again?
>
> The 0.98.5.3 binaries have a problem with the PNG output, so I pulled
> them.  Charile, do you still have the 0.98.5.2 win32 binaries to
> reupload while we are sorting out this problem?
>
> JDH
>

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
(Continue reading)

John Hunter | 2 Jun 18:17
Picon
Gravatar

Re: Sourceforge - lost windows binaries

On Tue, Jun 2, 2009 at 7:59 AM, Charlie Moad <cwmoad@...> wrote:
> I can't say that I have them.  Petr, you can use 98.5.3 binaries found
> here, "http://drop.io/tvuqe3o".  Just keep in mind that png operations
> will fail.

I've done some digging on this -- the segfault is happening in
_png.cpp on the line

  png_write_info(png_ptr, info_ptr);

and the error is

  Unhandled exception at 0x7c91b1fa in python.exe: 0xC0000005: Access
violation writing location 0x00000010.

when I paste this part of the message into google "python.exe:
0xC0000005: Access violation writing location 0x00000010" I find all
kinds of matches.  Eg, this page

  http://stackoverflow.com/questions/391917/jpeg-support-with-ijg-getting-access-violation

suggests that there could be a problem in trying to pass FILE *
pointers to shared libraries.  It seems we've done what is necessary
to compile these statically, but I'm just throwing this out there in
case it stimulates some ideas.  I'm stuck so far in trying to fix
this.

JDH

------------------------------------------------------------------------------
(Continue reading)

Daniel | 2 Jun 23:52

FltkAgg Patch

Hello All,

I have attached a patch that updates backend_fltkagg.py to use the new Transform APIs for 0.98.0 (http://matplotlib.sourceforge.net/api/api_changes.html#notes-about-the-transforms-refactoring). Without these changes, trying to use FLTKAgg causes a crash with a very cryptic error.

Thanks for all your work on matplotlib!

Daniel

Index: lib/matplotlib/backends/backend_fltkagg.py
===================================================================
--- lib/matplotlib/backends/backend_fltkagg.py	(revision 7174)
+++ lib/matplotlib/backends/backend_fltkagg.py	(working copy)
@@ -115,6 +115,7 @@
     window = Fltk.Fl_Double_Window(10,10,30,30)
     canvas = FigureCanvasFltkAgg(figure)
     window.end()
+    #Fltk.Fl.visual(Fltk.FL_DOUBLE)
     window.show()
     window.make_current()
     figManager = FigureManagerFltkAgg(canvas, num, window)
@@ -157,7 +158,7 @@
     def handle(self, event):
         x=Fltk.Fl.event_x()
         y=Fltk.Fl.event_y()
-        yf=self._source.figure.bbox.height() - y
+        yf=self._source.figure.bbox.height - y
         if event == Fltk.FL_FOCUS or event == Fltk.FL_UNFOCUS:
             return 1
         elif event == Fltk.FL_KEYDOWN:
@@ -230,7 +231,7 @@
     def resize(self,size):
         w, h = size
         # compute desired figure size in inches
-        dpival = self.figure.dpi.get()
+        dpival = self.figure.dpi
         winch = w/dpival
         hinch = h/dpival
         self.figure.set_size_inches(winch,hinch)
@@ -405,7 +406,7 @@
     """

     def __init__(self, canvas, figman):
-        #xmin, xmax = canvas.figure.bbox.intervalx().get_bounds()
+        #xmin, xmax = canvas.figure.bbox.intervalx
         #height, width = 50, xmax-xmin
         self.canvas = canvas
         self.figman = figman
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@...
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Gmane