matplotlib-devel Mailing List for matplotlib

> From: Andrew Straw [mailto:str...@as...] 
> Sent: Thursday, September 03, 2009 13:50
> 
> I am interested in getting the buildbot infrastructure to 
> build automatic nightly binaries for Windows (XP was my 
> thought, but 7 would also be good). If you you'd be willing 
> to perform the work to automate build and installation from 
> the svn repo on either your own machine or a virtual machine 
> running in my linux box (presuming I could get Windows 7 
> running in VirtualBox), you could itch your own scratch as 
> well as help the MPL community.
 . . . .
> Regardless of whether you can help with the buildbot 
> automation part, if you take notes about what you did, I'm 
> sure it will help whomever comes after you in the process.
> 
> -Andrew
Hi, Andrew. I'm happy to share what I learn along the way. At this point,
I'm trying to get clear about the various build approaches that are in play.
The impression I'm forming is that what I called method (a) is the legacy
method, if you will, and the developers are trying to implement two automated
build systems: one for releases -- method (b) -- and one for the buildbot, and
apparently there are some distinctions between those two. Is that right?
By the way, my XP partition is still bootable, so I'm not restricted to Win 7
and may be able to help with an XP buildbot.

> From: Andrew Straw [mailto:str...@as...] 
> Sent: Thursday, September 03, 2009 14:26
>
> Hmm, it seems MS disabled Windows 7 RC downloads. So I'm 
> unable to create such a virtual machine.
One alternative is the 90-day trial of Windows 7 Enterprise:
http://technet.microsoft.com/en-us/evalcenter/cc442495.aspx.

Jae-Joon Lee wrote:
> On Fri, Sep 4, 2009 at 4:10 PM, Jae-Joon Lee<lee...@gm...> wrote:
> 
>> Yes, this should be my fault. I didn't expect that importing a
>> texmager would raise an exception. I'll fix it soon.
>>
>> 
>
> I just committed a changeset that I think would fix this (the
> textpath.py imports texmanager only when required). But I couldn't
> test it as I don't have a machine w/o dvipng at this time.
> 
OK, I added a buildslave without dvipng and the latest svn passes.
Thanks Jae-Joon.
Chalk another one up for the buildbot -- even with only 17 tests, we're
catching a lot of interesting things. Still to be resolved is the empty
datetime issue:
https://sourceforge.net/tracker/?func=detail&aid=2850075&group_id=80706&atid=560720
-Andrew

Hi,
I refactored the textpath class as a separate module (textpath.py).
Now, it supports mathtext and also usetex mode.
The example, demo_text_path.py, also is updated (figure attached).
You may use this module to improve the visibility of the text.
Or you may use it to create your own mpl logo :)
What I'm actually planning to do is to implement the "draw_text" and
the "draw_tex" method of the RendererBase using the textpath so that a
new backend may only implement the draw_path and draw_image. The
usetex-mode will be supported in most of the backend (e.g., usetex in
svg). Of course, the quality of the rendered text will not be ideal,
especially for low dpi screen display, and it should be best if
backend-specific draw_text method is eventually implemented.
I must confess that I don't have much clue about the font rendering.
Most of the code in the textpath.py are borrowed from backed_svg.py
and backend_pdf.py, and it is highly likely that there are things
that I didn't get right. So, it would be great if those who knows
better (e.g., the original authors of the svg and pdf backend) review
my code.
The current code does not take care of "dpi", "rotation" and
"baseline", and also not well optimized. My plan is to improve these
as I incorporate textpath into the RendererBase. Any comments or
suggestion will be welcomed.
Regards,
-JJ

On Fri, Sep 4, 2009 at 4:10 PM, Jae-Joon Lee<lee...@gm...> wrote:
> Yes, this should be my fault. I didn't expect that importing a
> texmager would raise an exception. I'll fix it soon.
>
I just committed a changeset that I think would fix this (the
textpath.py imports texmanager only when required). But I couldn't
test it as I don't have a machine w/o dvipng at this time.
Regards,
-JJ

On Fri, Sep 4, 2009 at 4:06 PM, John Hunter<jd...@gm...> wrote:
> On Fri, Sep 4, 2009 at 2:54 PM, Andrew Straw<str...@as...> wrote:
>
>> Should I remove dvipng from the buildslaves to check for this kind of
>> thing in the future, or should I keep it installed so we can test
>> functionality that uses it?
>
> I think we should have at least one build slave with dvipng and one
> w/o. This is a real bug that the buildbot caught since we do not
> require dvipng for a normal mpl install.
>
Yes, this should be my fault. I didn't expect that importing a
texmager would raise an exception. I'll fix it soon.
Regards,
-JJ
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Fri, Sep 4, 2009 at 2:54 PM, Andrew Straw<str...@as...> wrote:
> Should I remove dvipng from the buildslaves to check for this kind of
> thing in the future, or should I keep it installed so we can test
> functionality that uses it?
I think we should have at least one build slave with dvipng and one
w/o. This is a real bug that the buildbot caught since we do not
require dvipng for a normal mpl install.

mpl...@co... wrote:
> STATUS: Failure
> revision: 7635 ( http://matplotlib.svn.sourceforge.net/matplotlib/?view=rev&rev=7635 )
> 
I just installed dvipng on the test machines, which I think will make
them pass this test next time.
But it looks from the traceback
http://mpl-buildbot.code.astraw.com/builders/Ubuntu%208.04%2C%20Python%202.5%2C%20amd64/builds/78/steps/test/logs/stdio
that the new textpath module is importing texmanager, which will fail if
dvipng is not installed. Will this cause similar breakage on people's
machines if we they don't have dvipng installed?
Should I remove dvipng from the buildslaves to check for this kind of
thing in the future, or should I keep it installed so we can test
functionality that uses it?

It looks like we may be on the hook for some c++ ABI breakage with
Apple's latest OS (Snow Leopard). See the attached email forwarded from
the numpy mailing list.
-Andrew

On Thu, Sep 3, 2009 at 8:05 PM, <jas...@cr...> wrote:
> This is just a friendly ping about the issue in this thread. I'm
> delaying the patch that shifts Sage's graphics to using the new
> matplotlib and spines, and I think resolving this issue would probably
> resolve the remaining big problem (placing axes labels, as mentioned in
> the thread "setting axis label offset from end of spine").
To make sure this doesn't get misplaced, please post it on the bug tracker:
 https://sourceforge.net/tracker/?group_id=80706&atid=560720
and I'll make sure it gets assigned to Andrew :-)
JDH

Andrew Straw wrote:
> jas...@cr... wrote:
> 
>> Do the right and top spines display correctly when the position is set 
>> using 'axes' coordinates?
>> 
>> 
> Jason,
>
> This looks like a bug. I'll look into it. Please ping me in a few days
> if you haven't heard back.
> 
This is just a friendly ping about the issue in this thread. I'm 
delaying the patch that shifts Sage's graphics to using the new 
matplotlib and spines, and I think resolving this issue would probably 
resolve the remaining big problem (placing axes labels, as mentioned in 
the thread "setting axis label offset from end of spine").
Thanks,
Jason