matplotlib-devel Mailing List for matplotlib

John Hunter schrieb:
> There have been enough new features and bug fixes in CVS that I think
> it's time to roll out another release, target date Monday. Man, we're
> getting stodgy around here, no releases since Sept 27th. Oh well,
> I'll blame it on the baby :-)
Well, I was also planning on releasing ipython 0.6.4 (nice numbering 
coincidence :) on Monday, and it includes a number of enhancements for 
matplotlib use. Mainly, better handling of Ctrl-C and an improved %run which 
doesn't open spurious windows, plus a few other small fixes.
Perhaps you might want to mention that the matplotlib+ipython 0.64+0.6.4 combo 
is now a pretty usable toolset (and that matplotlib carries within all of 
ipython's numutils, which some existing ipython users were accustomed to).
I'll certainly highlight the improved matplotlib support as one of the 
interesting improvements of this new ipython version.
Cheers,
f

There have been enough new features and bug fixes in CVS that I think
it's time to roll out another release, target date Monday. Man, we're
getting stodgy around here, no releases since Sept 27th. Oh well,
I'll blame it on the baby :-)
So if you have any changes you want to commit before then, or any
reasons why I should hold off, fire away.
JDH

>>>>> "Thane" == Thane <th...@ma...> writes:
 Thane> Source is attached. --tkp
OK, many thanks. zip file is available at 
http://matplotlib.sf.net/backend_dotnet.zip
JDH

Thanks John, I'll be forwarding the source separately. Now to your
questions:
1. [JDH] It's still the case, isn't it, that matplotlib itself will not
work on a general .Net machine? 
[TKP] No. Matplotlib DOES work on a general .Net machine. I've run
successful -- but not exhaustive -- tests of the "DotNet" backend on
("normal") CPython 2.3, and PythonNet.
2. [JDH] In particular, it won't work on IronPython because it uses numerix
extension code as well as it's own, right?
[TKP] Yes and no. Matplotlib doesn't work on IronPython (yet) as the
supporting libraries are not yet there. (With some effort, this might be
feasible with PyPy.) However, the "DotNet" backend (DLL) works just fine.
Output from the session below creates a graphic window and draws a blue line
on it. This isn't too useful except to note that once the libraries are in
place, matplotlib will indeed work on IronPython.
C:\Python\IronPython-0.6\bin>IronPythonConsole
>>> import sys
>>> sys.LoadAssemblyFromFile("./_backend_dotnet.pyd")
>>> foo = backend_dotnet.GraphicsForm(640, 480)
IronPython.Objects.PythonNameError: name 'backend_dotnet' is not defined
 at IronPython.Objects.Frame.GetGlobal(String name)
 at input_2.Run(Frame frame)
 at IronPythonConsole.IronPython.DoInteractive()
>>> import backend_dotnet
>>> foo = backend_dotnet.GraphicsForm(640, 480)
>>> from System.Drawing import *
>>> bar = Color.Blue
>>> bar
Color [Blue]
>>> pen = Pen(bar)
>>> pen
<System.Drawing.Pen object at 0x00000021>
>>> foo.draw_line(pen, 0, 0, 100, 100)
>>> foo.Repaint()
>>>
3. [JDH] How does PythonNet handle this problem, and is it fair to say that
matplotlib with your backend currently work only on PythonNet?
[TKP] That was the case, but isn't any longer. A bit of history... I
originally wrote the backend in PythonNet, and consequently it would only
work with the PythonNet distribution. However, (foolishly) encouraged by my
success, I wrote a DLL so that this backend could work with any .Net
machine. I say foolishly, because the DLL took about 5 times as long to
write as the Python version! It now works also with the "regular" Python
(aka CPython) distribution.
> -----Original Message-----
> From: John Hunter [mailto:jdh...@ac...]
> Sent: Friday, November 05, 2004 9:30 AM
> To: th...@ma...
> Cc: 'Andrew Straw'; mat...@li...
> Subject: Re: [matplotlib-devel] .NET backend
> 
> >>>>> "Thane" == Thane <th...@ma...> writes:
> 
> Thane> My source code posting seems to have bounced. I got the
> Thane> following message: host mail.sourceforge.net
> Thane> [66.35.250.206]: 550-"For the time being, we are blocking
> Thane> all mail with the .zip extension....
> 
> If you email it to me, I'll post it on the matplotlib web site, and
> follow-up here with a link to it. Best if you include all the code
> (*.py and *.c) in one zip along with the pyd and any examples since
> the sf archives won't include your previous plain text)attachments,
> and it will be easiest for people searching the archives to get
> everything in one bundle.
> 
> Can you clarify something for me? In the backend comments you wrote
> 
> 0.2.0 11/01/04 Created a DLL for the backend. Should work with any
> .NET machine.
> 
> It's still the case, isn't it, that matplotlib itself will not work on
> a general .Net machine? In particular, it won't work on IronPython
> because it uses numerix extension code as well as it's own, right?
> How does PythonNet handle this problem, and is it fair to say that
> matplotlib with your backend currently work only on PythonNet?
> 
> Thanks!
> JDH
> 
> 
> 

>>>>> "Thane" == Thane <th...@ma...> writes:
 Thane> My source code posting seems to have bounced. I got the
 Thane> following message: host mail.sourceforge.net
 Thane> [66.35.250.206]: 550-"For the time being, we are blocking
 Thane> all mail with the .zip extension....
If you email it to me, I'll post it on the matplotlib web site, and
follow-up here with a link to it. Best if you include all the code
(*.py and *.c) in one zip along with the pyd and any examples since
the sf archives won't include your previous plain text)attachments,
and it will be easiest for people searching the archives to get
everything in one bundle.
Can you clarify something for me? In the backend comments you wrote
 0.2.0 11/01/04 Created a DLL for the backend. Should work with any .NET machine.
It's still the case, isn't it, that matplotlib itself will not work on
a general .Net machine? In particular, it won't work on IronPython
because it uses numerix extension code as well as it's own, right?
How does PythonNet handle this problem, and is it fair to say that
matplotlib with your backend currently work only on PythonNet?
Thanks!
JDH

My source code posting seems to have bounced. I got the following message:
host mail.sourceforge.net [66.35.250.206]: 550-"For the time being, we are
blocking all mail with the .zip extension....
What's the best way to distribute a project?
> -----Original Message-----
> From: mat...@li... [mailto:matplotlib-
> dev...@li...] On Behalf Of Andrew Straw
> Sent: Thursday, November 04, 2004 9:57 PM
> To: th...@ma...; mat...@li...
> Subject: Re: [matplotlib-devel] .NET backend
> 
> Thane wrote:
> 
> > Attached are the files needed for running a .NET backend. This code
> > still needs a lot of work, but this should demonstrate the feasibility
> > of a .NET backend, for those interested.
> >
> Dear Thane,
> 
> This looks very interesting, but what about the source to
> _backend_dotnet.pyd? Did you forget to include that?
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

Hello,
On Tue, Nov 02, 2004 at 12:41:03PM -0600, John Hunter wrote:
> >>>>> "Jochen" =3D=3D Jochen Voss <vo...@se...> writes:
> Jochen> Is there a reason for storing the PostScript data in a
> Jochen> string first? Otherwise I could just pass the real file
> Jochen> handle to RendererPS and it would write all the stuff
> Jochen> directly into the output file.
>=20
> The reason I did it (I think) was for efficiency, (wrongly) thinking
> it would be faster to write to StringIO than to a file object. Of
> course, file objects buffer their output, so this is not a real
> consideration. I think its fine to make the change you suggested -
I found a good reason for storing the PS in a string first:
we have to process all of the figure before we write the PostScript
prologue. Otherwise there is no good way to know which fonts
to include in the PostScript file :-(
I reverted my change for now, we are back to storing the PostScript
data temporarily in a string.
All the best,
Jochen
--=20
http://seehuhn.de/

Thane wrote:
> Attached are the files needed for running a .NET backend. This code 
> still needs a lot of work, but this should demonstrate the feasibility 
> of a .NET backend, for those interested.
>
Dear Thane,
This looks very interesting, but what about the source to 
_backend_dotnet.pyd? Did you forget to include that?