matplotlib-devel Mailing List for matplotlib

--- On Tue, 10/28/08, Christopher Barker <Chr...@no...> wrote:
> > 4) One drawback compared to the existing cocoa-agg
> > backend is that the latter allows easy integration
> > of matplotlib into a larger cocoa application,
> > whereas my backend only cares about matplotlib.
> 
...
> Is there any possibility to embed it in another app? I know
> that wx, for instance, can pass a Window handle to other
> libs, so that you can have that window managed and drawn
> by other code, while wx handles the rest of the app --
> would this kind of thing be possible with your code with 
> wx, and Cocoa, and QT, and ?
That is a good idea. I'll check whether it is possible. Basically, if the embedding app can manage a window by passing it the window handle then it should be possible.
> I'm still curious where all this speed comes from. MPL
> already uses Agg 
> for a lot, and it's generally reported to be as fast as
> many native 
> drawing APIs (though maybe not quartz?)
> 
At this point, most of it is coming from having complete control over the event loop, which allows to avoid superfluous calls to draw().
Best,
--Michiel
 

> I suspect the fix is as simple as twiddling a single line of code, it's 
> just not obvious to me how the image flipping is supposed to work to 
> have consistent behavior across backends -- and I hope another developer 
> here has a clue...
I suspect this is related to the problem described at
http://thread.gmane.org/gmane.comp.python.matplotlib.general/14420
The problem does not seem to be alignment but that the image is rendered
upside down. The PDF backend does
 img.flipud_out()
 # get rgba data of image and write it in the output file
 img.flipud_out()
and if I comment out the flipud_out calls, I get that particular case
right but then the image_origin example is wrong.
Revision 5618 added a flipud_out call to Axes.draw:
 if self.images[0].origin=='upper':
 im.flipud_out()
The log message is:
------------------------------------------------------------------------
r5618 | jdh2358 | 2008年06月20日 20:09:12 +0300 (Pe, 20 Kes 2008) | 1 line
Changed paths:
 M /trunk/matplotlib/examples/api/mathtext_asarray.py
 M /trunk/matplotlib/examples/pylab_examples/figimage_demo.py
 M /trunk/matplotlib/lib/matplotlib/axes.py
 M /trunk/matplotlib/lib/matplotlib/backends/backend_gtkagg.py
 M /trunk/matplotlib/lib/matplotlib/figure.py
 M /trunk/matplotlib/src/_gtkagg.cpp
 M /trunk/matplotlib/src/_image.cpp
added origin support for composite images
------------------------------------------------------------------------
I think this was discussed further in some emails between me, Haibao
Tang, and John Hunter, but at least I have been too busy to spend much
time on matplotlib lately. I hope this helps somebody track the bug
down.
Jouni

No problem. I didn't mean to imply that you should have known you bug 
was a duplicate. I was mainly pointing it out for other developers to 
keep track of the issue, since I suspect your issue and the one in the 
bug are the same, but that's probably not obvious to most users.
I suspect the fix is as simple as twiddling a single line of code, it's 
just not obvious to me how the image flipping is supposed to work to 
have consistent behavior across backends -- and I hope another developer 
here has a clue...
Thanks for your report,
Mike
Arnar Flatberg wrote:
>
>
> On Tue, Oct 28, 2008 at 4:20 PM, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
> There's a bug filed for this. I've looked at it a few times, but
> I'm not sure how the image flipping parameters are "supposed" to
> work. Anyone else want to have a look at this?
>
> https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720
> <https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720>
>
>
> I was not aware of that, thanks Michael. Just to be clear, (in 
> relation to the filed ticket), the screen image is just fine for my 
> part, its *only* after saving in any vector graphic format I get a 
> "flipped" image as a result. In other words, I have an issue with 
> savefig, while the ticket is concerned with imshow. Perhaps they are 
> obviously related ... then Im sorry for the noise :-)
>
> Thanks,
>
> Arnar
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Oct 28, 2008 at 4:20 PM, Michael Droettboom <md...@st...> wrote:
> There's a bug filed for this. I've looked at it a few times, but I'm not
> sure how the image flipping parameters are "supposed" to work. Anyone else
> want to have a look at this?
>
>
> https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720
>
I was not aware of that, thanks Michael. Just to be clear, (in relation to
the filed ticket), the screen image is just fine for my part, its *only*
after saving in any vector graphic format I get a "flipped" image as a
result. In other words, I have an issue with savefig, while the ticket is
concerned with imshow. Perhaps they are obviously related ... then Im sorry
for the noise :-)
Thanks,
Arnar

Eric Firing wrote:
> Michael Droettboom wrote:
>> This may not be necessary if we can get a Windows box, but I thought 
>> I'd mention it.
>>
>> I wrote a distutils extension a couple of years ago to build Windows 
>> installers on a Linux box with Mingw32. This has been working 
>> perfectly for nightly builds on my home machine since around 
>> September 2007 for a project with much the same build requirements as 
>> matplotlib. It's really easy to install Mingw32 on Debian 
>> derivatives (maybe other dists as well.)
>
> Mike,
>
> Thank you! I had no idea that mingw32 was available as an ubuntu 
> package, for example, and never would have thought to look for it. 
> Now I will have to try it out. Do you know if there is an scons 
> builder that uses it? That might be the sticking point for my non-mpl 
> C code, which is now all built with scons.
No idea. Haven't spent much time with scons myself.
>
> I think that if your distutils extension works for building mpl for 
> Win on a Linux box, then we should use it. Anything that reduces 
> dependence o having an actual Windows machine around is a win.
>
> On second thought, there is one disadvantage: an automated build on a 
> Win box could also run an automated test.
True. But there is always wine -- though I fear my head would start to 
spin. I'll admit that the advantages of cross-compiling can quickly be 
outweighed by the complexity of debugging and testing.
>
> I have some dim impression of having seen a caution regarding 
> compatibility between mingw extensions and present or future official 
> python.org Python builds. Does this ring any bells?
It does. I haven't had problems up to Py2.5 -- but I don't know what's 
coming in that respect, and I don't closely follow Python-on-Windows 
development.
Mike
>
> Eric
>
>>
>> See here:
>>
>> http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup 
>>
>>
>> Mike
>>
>> John Hunter wrote:
>>> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> 
>>> wrote:
>>>
>>> 
>>>> None that I know of. It would certainly be nice if we had the release
>>>> package-building completely automated; or automated daily svn 
>>>> builds of the
>>>> Win and OSX packages. Since I don't work with either Win or OSX, I 
>>>> don't
>>>> know how hard this would be to set up.
>>>> 
>>>
>>> Nightly builds would be excellent -- Charlie, to what extent do you
>>> think this is feasible from a scripting perspective? Ie, ignoring the
>>> hardware side for a minute, and assuming we had access to a build farm
>>> with OS X and win32, how hard would it be to setup a build bot for
>>> nightly builds?
>>>
>>> JDH
>>>
>>> ------------------------------------------------------------------------- 
>>>
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win 
>>> great prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in 
>>> the world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>> 
>>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I've finally gotten around to addressing a long-standing pet peeve of 
mine. The font lookup is now performed with a nearest neighbor search, 
so if an exact font match can not be found for what the user specifies, 
the best available match is used, rather than dropping down to Vera 
Sans. This is particularly important with fonts we don't distribute 
(particularly high-end commercial fonts) that have unusual values for 
"bold" etc.
All the examples in the docs and backend_driver seem to pass (with no 
required changes), so I've committed my patch. But I wouldn't be 
surprised if some external usage may behave differently, particularly if 
it was relying on the old broken behavior. Please test any scripts you 
may have that use different fonts (those not included with matplotlib 
especially) and report any regressions.
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tue, Oct 28, 2008 at 12:24 PM, Eric Bruning <eri...@gm...> wrote:
> Nice work ... and an ambitious effort.
>
> I've gotten it running, and am a bit perplexed by some of the
> performance I'm seeing. Specifically, the following bit takes well
> over twice as long to run as does WxAgg. Does this align with others'
> testing?
I haven't had a chance to look at the code yet, but I suspect he
hasn't implemented the path collection draw method. If it's not
implemented, we fall back on drawing each path separately, which is a
lot slower. scatter ultimately triggers a call to
Renderer.draw_path_collection which has a default implementation and a
specialization in backend_agg.
JDH

Michael Droettboom wrote:
> This may not be necessary if we can get a Windows box, but I thought I'd 
> mention it.
> 
> I wrote a distutils extension a couple of years ago to build Windows 
> installers on a Linux box with Mingw32. This has been working perfectly 
> for nightly builds on my home machine since around September 2007 for a 
> project with much the same build requirements as matplotlib. It's 
> really easy to install Mingw32 on Debian derivatives (maybe other dists 
> as well.)
Mike,
Thank you! I had no idea that mingw32 was available as an ubuntu 
package, for example, and never would have thought to look for it. Now 
I will have to try it out. Do you know if there is an scons builder 
that uses it? That might be the sticking point for my non-mpl C code, 
which is now all built with scons.
I think that if your distutils extension works for building mpl for Win 
on a Linux box, then we should use it. Anything that reduces dependence 
o having an actual Windows machine around is a win.
On second thought, there is one disadvantage: an automated build on a 
Win box could also run an automated test.
I have some dim impression of having seen a caution regarding 
compatibility between mingw extensions and present or future official 
python.org Python builds. Does this ring any bells?
Eric
> 
> See here:
> 
> http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup 
> 
> 
> Mike
> 
> John Hunter wrote:
>> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> wrote:
>>
>> 
>>> None that I know of. It would certainly be nice if we had the release
>>> package-building completely automated; or automated daily svn builds 
>>> of the
>>> Win and OSX packages. Since I don't work with either Win or OSX, I don't
>>> know how hard this would be to set up.
>>> 
>>
>> Nightly builds would be excellent -- Charlie, to what extent do you
>> think this is feasible from a scripting perspective? Ie, ignoring the
>> hardware side for a minute, and assuming we had access to a build farm
>> with OS X and win32, how hard would it be to setup a build bot for
>> nightly builds?
>>
>> JDH
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's 
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great 
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the 
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>> 
> 

Nice work ... and an ambitious effort.
I've gotten it running, and am a bit perplexed by some of the
performance I'm seeing. Specifically, the following bit takes well
over twice as long to run as does WxAgg. Does this align with others'
testing?
The only difference I detect is that the Mac backend puts up a window
on the call to plt.figure, while WxAgg waits until the call to show().
Thanks,
Eric
# for testing macosx backend only
import matplotlib
matplotlib.use('macosx')
import matplotlib.pyplot as plt
f=plt.figure()
import numpy as np
x=np.arange(1e4)
y=np.sin(x)
ax=f.add_subplot(111)
sc=ax.scatter(x,y,c=x**2.0)
plt.show()
On Tue, Oct 28, 2008 at 12:13 PM, Christopher Barker
<Chr...@no...> wrote:
> Michiel de Hoon wrote:
>> I wrote a backend for matplotlib on Mac OS X. This is a native
>> backend for Mac OS X
>
> very nice!
>
>> 4) One drawback compared to the existing cocoa-agg backend is that
>> the latter allows easy integration of matplotlib into a larger cocoa
>> application, whereas my backend only cares about matplotlib.
>
> well, as far as many of us are concerned, matplotlib IS an embeddable
> plotting package. I suppose you could say that your backend only cares
> about pylab.
>
> Is there any possibility to embed it in another app? I know that wx, for
> instance, can pass a Window handle to other libs, so that you can have
> that window managed and drawn by other code, while wx handles the rest
> of the app -- would this kind of thing be possible with your code with
> wx, and Cocoa, and QT, and ? I imagine GTK would be off the table as it
> is using X11, though I suppose if you are using Apple's X11, it could
> even be possible there.
>
>> Whereas matplotlib has a vastly superior range of high-level plotting
>> capabilities, pygist excelled at sheer speed. This was achieved by
>> having three backends (Windows, Mac OS X, X11) written in C for
>> optimal performance,
>
> I'm still curious where all this speed comes from. MPL already uses Agg
> for a lot, and it's generally reported to be as fast as many native
> drawing APIs (though maybe not quartz?)
>
> -Chris
>
>
>
> --
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R (206) 526-6959 voice
> 7600 Sand Point Way NE (206) 526-6329 fax
> Seattle, WA 98115 (206) 526-6317 main reception
>
> Chr...@no...
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Michiel de Hoon wrote:
> I wrote a backend for matplotlib on Mac OS X. This is a native
> backend for Mac OS X
very nice!
> 4) One drawback compared to the existing cocoa-agg backend is that
> the latter allows easy integration of matplotlib into a larger cocoa
> application, whereas my backend only cares about matplotlib.
well, as far as many of us are concerned, matplotlib IS an embeddable 
plotting package. I suppose you could say that your backend only cares 
about pylab.
Is there any possibility to embed it in another app? I know that wx, for 
instance, can pass a Window handle to other libs, so that you can have 
that window managed and drawn by other code, while wx handles the rest 
of the app -- would this kind of thing be possible with your code with 
wx, and Cocoa, and QT, and ? I imagine GTK would be off the table as it 
is using X11, though I suppose if you are using Apple's X11, it could 
even be possible there.
> Whereas matplotlib has a vastly superior range of high-level plotting
> capabilities, pygist excelled at sheer speed. This was achieved by 
> having three backends (Windows, Mac OS X, X11) written in C for 
> optimal performance,
I'm still curious where all this speed comes from. MPL already uses Agg 
for a lot, and it's generally reported to be as fast as many native 
drawing APIs (though maybe not quartz?)
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

There's a bug filed for this. I've looked at it a few times, but I'm 
not sure how the image flipping parameters are "supposed" to work. 
Anyone else want to have a look at this?
https://sourceforge.net/tracker2/?func=detail&aid=2160909&group_id=80706&atid=560720
Mike
Arnar Flatberg wrote:
> Hi
>
> The gradient_bar example flips the bars using svg, pdf and eps backends.
>
> Add
> fig.savefig("gradient_bar.png")
> fig.savefig("gradient_bar.pdf")
> fig.savefig("gradient_bar.eps")
> fig.savefig("gradient_bar.svg")
>
> to gradient_bar.py to reproduce.
>
> Tested with TkAgg backend (pylab: 1.3.0.dev5867 on python 2.5.2).
>
> Arnar
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi
The gradient_bar example flips the bars using svg, pdf and eps backends.
Add
fig.savefig("gradient_bar.png")
fig.savefig("gradient_bar.pdf")
fig.savefig("gradient_bar.eps")
fig.savefig("gradient_bar.svg")
to gradient_bar.py to reproduce.
Tested with TkAgg backend (pylab: 1.3.0.dev5867 on python 2.5.2).
Arnar

This may not be necessary if we can get a Windows box, but I thought I'd 
mention it.
I wrote a distutils extension a couple of years ago to build Windows 
installers on a Linux box with Mingw32. This has been working perfectly 
for nightly builds on my home machine since around September 2007 for a 
project with much the same build requirements as matplotlib. It's 
really easy to install Mingw32 on Debian derivatives (maybe other dists 
as well.)
See here:
http://gamera.svn.sourceforge.net/viewvc/gamera/trunk/gamera/mingw32_cross_compile.py?revision=1066&view=markup
Mike
John Hunter wrote:
> On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> wrote:
>
> 
>> None that I know of. It would certainly be nice if we had the release
>> package-building completely automated; or automated daily svn builds of the
>> Win and OSX packages. Since I don't work with either Win or OSX, I don't
>> know how hard this would be to set up.
>> 
>
> Nightly builds would be excellent -- Charlie, to what extent do you
> think this is feasible from a scripting perspective? Ie, ignoring the
> hardware side for a minute, and assuming we had access to a build farm
> with OS X and win32, how hard would it be to setup a build bot for
> nightly builds?
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi everybody,
About two years ago, I wrote a backend for matplotlib on Mac OS X. This is a native backend for Mac OS X, meaning that most of it is implemented in C (Objective-C, to be precise) to fully make use of Apple's Quartz graphics-rendering technology. I have been using this backend for my own work for the past two years, and recently I updated it for use with matplotlib 0.98.3. To make this backend available to other matplotlib users, I submitted it as a patch to sourceforge (patch 2179017 on the matplotlib issue tracker):
http://sourceforge.net/tracker/index.php?func=detail&aid=2179017&group_id=80706&atid=560722
I'd be interested in any feedback on this backend from matplotlib users and developers.
Some information about this backend:
1) No 3rd party library is needed other than Python and NumPy.
2) The backend is interactive both with python and with ipython.
3) The backend was written in C for optimal performance, and depending on the application it can be much, much faster than existing backends.
4) One drawback compared to the existing cocoa-agg backend is that the latter allows easy integration of matplotlib into a larger cocoa application, whereas my backend only cares about matplotlib.
Some history about this backend:
I used to be one of the developers of pygist, a scientific visualization package for Python that was written about ten years ago and is still in use. About two years ago I switched to matplotlib
(http://bonsai.ims.u-tokyo.ac.jp/~mdehoon/software/python/gist).
Whereas matplotlib has a vastly superior range of high-level plotting capabilities, pygist excelled at sheer speed. This was achieved by having three backends (Windows, Mac OS X, X11) written in C for optimal performance, which at the same time avoided the need for external 3rd party libraries for drawing. I believe that matplotlib can achieve the same speed and performance by similarly having a native backend.
Enjoy!
--Michiel.
 

This is now fixed in SVN r6341.
Sorry for the inconvenience.
Mike
John Hunter wrote:
> On Mon, Oct 27, 2008 at 8:49 PM, Fernando Perez <fpe...@gm...> wrote:
>
> 
>> src/_tkagg.cpp: In function 'int PyAggImagePhoto(void*, Tcl_Interp*,
>> int, char**)':
>> src/_tkagg.cpp:134: error: no match for 'operator*' in
>> '*aggRenderer->RendererAgg::renderingBuffer'
>> error: command 'gcc' failed with exit status 1
>>
>> John, this is on bic, in case you want to have a look.
>> 
>
> I saw this too, and emailed Michael off list earlier. He committed a
> significant cleanup earlier of backend agg to reduce the number of
> heap allocations, and somehow tkagg got out of whack, at least on some
> platforms.
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Mon, Oct 27, 2008 at 8:49 PM, Fernando Perez <fpe...@gm...> wrote:
> src/_tkagg.cpp: In function 'int PyAggImagePhoto(void*, Tcl_Interp*,
> int, char**)':
> src/_tkagg.cpp:134: error: no match for 'operator*' in
> '*aggRenderer->RendererAgg::renderingBuffer'
> error: command 'gcc' failed with exit status 1
>
> John, this is on bic, in case you want to have a look.
I saw this too, and emailed Michael off list earlier. He committed a
significant cleanup earlier of backend agg to reduce the number of
heap allocations, and somehow tkagg got out of whack, at least on some
platforms.
JDH

Hi folks,
I don't see anything in the archives, but today mpl won't build on any
of my boxes:
building 'matplotlib.backends._tkagg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC
-fPIC -I/usr/include -I/usr/include -I/usr/local/include
-I/usr/include -I.
-I/home/fperez/usr/opt/lib/python2.5/site-packages/numpy/core/include
-Isrc -Iagg24/include -I.
-I/home/fperez/usr/opt/lib/python2.5/site-packages/numpy/core/include
-I/usr/include/freetype2 -I/usr/local/include -I/usr/include -I.
-I/usr/include/python2.5 -c src/_tkagg.cpp -o
build/temp.linux-x86_64-2.5/src/_tkagg.o
src/_tkagg.cpp: In function 'int PyAggImagePhoto(void*, Tcl_Interp*,
int, char**)':
src/_tkagg.cpp:134: error: no match for 'operator*' in
'*aggRenderer->RendererAgg::renderingBuffer'
error: command 'gcc' failed with exit status 1
John, this is on bic, in case you want to have a look.
Cheers,
f

On Mon, Oct 27, 2008 at 4:09 PM, Eric Firing <ef...@ha...> wrote:
> None that I know of. It would certainly be nice if we had the release
> package-building completely automated; or automated daily svn builds of the
> Win and OSX packages. Since I don't work with either Win or OSX, I don't
> know how hard this would be to set up.
Nightly builds would be excellent -- Charlie, to what extent do you
think this is feasible from a scripting perspective? Ie, ignoring the
hardware side for a minute, and assuming we had access to a build farm
with OS X and win32, how hard would it be to setup a build bot for
nightly builds?
JDH