Re: [matplotlib-devel] [Matplotlib-users] Missing dll in windows build 0.87.4

[Charlie Moad]

On 7/24/06, Chris Fonnesbeck <[EMAIL PROTECTED]> wrote:
> On 7/23/06, Charlie Moad <[EMAIL PROTECTED]> wrote:
> > The mingw/2.4 build still works.  There are instructions at the top of
> > the setupext.py file.  The dll linking error you are getting is
> > something we ran into a lot.  If you have numpy installed distutils
> > will use the numpy\distutils\mingw32ccompiler.py file.  In the
> > Mingw32CCompiler class remove all links to "msvcr71".  In my version
> > of numpy just comment out the whole if block at line 127.
> >
>
> I tried commenting out that very block, but then numpy will not build
> -- it does not see the mingw32 compiler without those lines, it
> appears. I used the --compiler switch on the build, but to no avail.
>
> I'm a bit stuck here, as matplotlib does not build, and the binary
> does not seem to work. I'm trying to put together a package that
> contains numpy, matplotlib and scipy to distribute to some of my
> users.

Try this.  If you are still getting an error, please post it.  I am
moving this to the devel list.

if sys.version[:3] > '2.3':
if libraries:
pass #libraries.append('msvcr71')
else:
libraries = [] #['msvcr71']

The other option is to bundle that dll with matplotlib.  I have seen
other python modules doing this.

- Charlie

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Matplotlib as a separate process

[Bill Baxter]

Matplotlib is quite nice, but I keep running into problems with the
actual display interface.
In some cases the plot window freezes and such when using it from a
debugger, or sometimes pylab.show() just never returns.  Matlab's
plotting interface just never gave me so much trouble.

I think all these problems could be fixed if the display interface
were turned into a separate process that communicates with the Python
program using pipes or some other IPC mechanism.  I used this
technique in a (C/C++) image debugging utility program I wrote
(http://www.billbaxter.com/projects/imdebug) and it works quite well.
The displayer is a separate process using a memory mapped file to
communicate with the main program.  When the user's code calls the
"display_image" function, the data to display is copied to the memory
mapped file, the displayer process is sent a signal, and then the
displayer reads the data from the memory mapped file and displays it.

Because the displayer is a separate process, it never hangs, even if
the main app crashes or gets stuck at a break point or in an infinite
loop.  And the displayer always owns its display loop completely, so
no nasty issues with who gets to run the wx.App event loop and when,
or with the single-gui-thread limitations you have with multithreaded
GUI apps.

Has anyone given thought to making matplotlib work in such a manner?
It would be hell to do in C or C++ I think, but with Python's
RPC libs I bet it wouldn't be so bad.

--bb

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel