matplotlib-users Mailing List for matplotlib

Hi,
I tried following the instructions at the py2exe site and I have also
uncommeneted and made it include the matplotlib.numerix package. Still it
doesnt seem to work. Is there any other way of compiling it into an
executable?
Thanks,
Archana.
On 4/1/07, Werner F. Bruhin <wer...@fr...> wrote:
>
> Hi Archana,
>
> Sometimes py2exe can't figure out what needs to be included. In these
> cases one creates entries in the packages section to force the inclusion
> of one or multiple packages.
>
> Archana Ganesan wrote:
> > Hi all,
> > ...
> >
> > options = {"py2exe": {"compressed": 1,
> > "optimize": 2,
> > "packages": ["encodings",
> > ## "kinterbasdb",
> > "pytz.zoneinfo.UTC",
> > #" matplotlib.numerix",
> >
>
> You need to activate/un-comment the matplotlib.numerix line. Also note
> that if you only include UTC and you use the timezone stuff in matplot
> then a user NOT using UTC, i.e. another timezone will have a problem, it
> is therefore better to just include all of pytz.
>
> Werner
>

On 3/30/07, Richard Brown <rg...@gm...> wrote:
> On 30/03/07, bre...@un...
> <bre...@un...> wrote:
> >
> > Not sure what region[:] is supposed to achieve. You are creating a copy
> > with the same name, so you are over-riding the original variable.
> >
>
> That doesn't seem to be the case - it returns the right thing on the
> first call - i.e. region got changed, but on subsequent calls the
> figure is displayed and the function returns array([0,0,0,0]). I
> thought taking the slice just gave access to the internals of region
> ...
>
> How does one assign a new value to a variable in a containing scope?
You can declare the "region" variable as global in keypressed():
def keypressed(event):
 global region
 region = ...
and "region" does not need to get initialized in the containing scope.
Cheers,
 ~ Antonio

On 4/1/07, Antonino Ingargiola <tri...@gm...> wrote:
> On 3/29/07, Ken McIvor <mc...@ii...> wrote:
[cut]
> > > The last think I'm not yet able to do is to update the colorbar to
> > > autoscale with the new incoming data. The the script that follows
> > > tries to update the colorbar too but it does not work (on matplotlib
> > > 0.87 at least).
> >
> > I have no idea if this will help, but you might need to call
> > AxesImage.changed() after calling AxesImage.set_data().
>
> That doesn't help :(. I'm not jet able to update the colorbar once the
> image has changed.
I've found a way to update the colorbar after the image has changed:
 image = imshow(data)
 colr_bar = colorbar()
 ...
 image.set_data(new_data)
 image.changed()
 color_bar.set_clim(vmax=newdata.max())
 draw()
The autoscale() colorbar method does not work to update a colorbar,
but with the above code I can acheive the same result.
Thanks again.
 ~ Antonio

Sorry for the late answer...
On 3/29/07, Ken McIvor <mc...@ii...> wrote:
> On Mar 28, 2007, at 6:03 PM, Antonino Ingargiola wrote:
> > On 3/28/07, Ken McIvor <mc...@ii...> wrote:
> >> You should probably do the acquisition asynchronously by running it
> >> in a separate thread.
> <snip>
> >
> > That's exactly what I'd like to do. The problem is that if I run
> > gtk.main() (the gtk main GUI loop) in a separate thread the program
> > stops until I do something on the GUI (for example passing the mouse
> > on it).
>
> Does it do this if you run gtk.main() in the main thread (e.g. the
> interpreter prompt) while doing something else in a background thread?
Good idea. I will try it next time I'll do something with GUI and thread.
> > My understanding so far is the following. When the function
> > that execute gtk.main() is executed, python doesn't switch thread
> > until either 100 bytecode instructions are executed or since an I/O
> > (potentially) blocking operation in executed.
>
> I think you're more or less correct but are unaware of one important
> factor. Here's my understanding of how multithreading works in
> Python...
>
> Thread switching is controlled by something called the Global
> Interpreter Lock, which is implemented in an abstract way on top of
> an OS lock/mutex object. Only one Python thread runs at a time
> because the Python interpreter requires a thread to hold the GIL
> before it can execute bytecode instructions. The running thread
> holds the GIL while is executes 100 instructions. During this time
> other Python threads block waiting to acquire the GIL. After it has
> executed its 100 instructions, the running thread releases the GIL
> and then attempts to reacquire it. The OS ensures that things are
> fair by preventing one thread from reacquiring the GIL over and over
> again when other threads are also waiting for it.
>
> Python doesn't actually detect you do something that will block the
> thread, like an I/O operation. Instead, the C code implementing an I/
> O operation like file.write() releases the GIL before performing the
> operation. This allows a different thread to acquire it and run some
> more bytecode instructions while the first thread performs its I/O
> operation.
Thanks for the explanation, it's clear now :).
> > BTW, the timer idea is good and eliminates the need to call
> > asynchronously the GUI thread to update the plot, which seems (the
> > latter case) not very simple to do.
>
> Yep. It's impossible to inject arbitrary code into a Python thread;
> the thread has to figure out what it's supposed to do by periodically
> polling something or retrieving some kind of message by blocking on a
> queue. Blocking on a queue isn't an option for the GUI thread.
>
> You might be able to trigger Gtk signals from a separate thread but
> in my experience tricks like that can be, well, tricky.
Good to know that this way is too tricky (at least).
> > The last think I'm not yet able to do is to update the colorbar to
> > autoscale with the new incoming data. The the script that follows
> > tries to update the colorbar too but it does not work (on matplotlib
> > 0.87 at least).
>
> I have no idea if this will help, but you might need to call
> AxesImage.changed() after calling AxesImage.set_data().
That doesn't help :(. I'm not jet able to update the colorbar once the
image has changed.
I will open a new thread to discuss this problem.
> Ken
 ~ Antonio

Hi Archana,
Sometimes py2exe can't figure out what needs to be included. In these 
cases one creates entries in the packages section to force the inclusion 
of one or multiple packages.
Archana Ganesan wrote:
> Hi all,
> ...
>
> options = {"py2exe": {"compressed": 1,
> "optimize": 2,
> "packages": ["encodings",
> ## "kinterbasdb",
> "pytz.zoneinfo.UTC",
> #" matplotlib.numerix",
> 
You need to activate/un-comment the matplotlib.numerix line. Also note 
that if you only include UTC and you use the timezone stuff in matplot 
then a user NOT using UTC, i.e. another timezone will have a problem, it 
is therefore better to just include all of pytz.
Werner