Changing Background Color to gradient with multiple panels

Hi, I am trying to change to background color of a frame to a gradient.
However, I also have a couple different panels as section on this frame.
How can I have the background/gradient blend in to those panels as well?

Also, when I change background color, spaces around button stay white. Is
there a way to fill in those spaces?

Thanks in advance.

···

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/Changing-Background-Color-to-gradient-with-multiple-panels-tp5663268p5663268.html
Sent from the wxPython-users mailing list archive at Nabble.com.

Hi, I am trying to change to background color of a frame to a gradient.
However, I also have a couple different panels as section on this frame.
How can I have the background/gradient blend in to those panels as well?

You'll need to set the background for the panels too.

Also, when I change background color, spaces around button stay white. Is
there a way to fill in those spaces?

It depends. Which platform? Which button class? Keep in mind that all widgets are rectangles, whether they look like it or not.

···

On 4/24/12 1:41 PM, Roger C. wrote:

--
Robin Dunn
Software Craftsman

Platform is window 7 and xp, and just the regular wx.button. The button has
a little round on the corner and the space between the round edge and the
rectangle space are white. Is there a way to fill that space with colour?

Also, if I apply gradient on the panel, how do I make that gradient on the
panel matches the main frame?

···

--
View this message in context: http://wxpython-users.1045709.n5.nabble.com/Changing-Background-Color-to-gradient-with-multiple-panels-tp5663268p5666180.html
Sent from the wxPython-users mailing list archive at Nabble.com.

Platform is window 7 and xp, and just the regular wx.button. The button has
a little round on the corner and the space between the round edge and the
rectangle space are white. Is there a way to fill that space with colour?

Not that I know of. The theme assumes that the button is on the default background color and draws those pixels so they match and make it look as if it was transparent.

Also, if I apply gradient on the panel, how do I make that gradient on the
panel matches the main frame?

Use math. IOW calculate what the starting and ending colors for the panel should be based on where the panel starts and ends on the parent's background.

···

On 4/25/12 3:42 PM, Roger C. wrote:

--
Robin Dunn
Software Craftsman

Platform is window 7 and xp, and just the regular wx.button. The button has
a little round on the corner and the space between the round edge and the
rectangle space are white. Is there a way to fill that space with colour?

See ButtonPanel in the wxPython Demo for some ideas about how that can
be done. Andrea did not use a wxButton, though, which *won't* allow
this, I think.

Also, if I apply gradient on the panel, how do I make that gradient on the
panel matches the main frame?

I think to do that perfectly is impossible: when the frame is
resized, the frame's background panel will also resize such that the
gradient will change, so that it even if the subpanels matched it
before (by choosing just the right gradient for each given their
positions), they won't match it after resizing. The difference might
be subtle, though.

I guess it's possible you could trigger a paint event on the frame's
resize that calculates what each subpanel's gradient has to be to
perfectly blend with the background gradient.

I've used gradients but never in this subpanel way. Are you sure you need them?

Che

···

On Wed, Apr 25, 2012 at 6:42 PM, Roger C. <chanhy@vcu.edu> wrote:

I don't want to resurrect a dead thread, but just in case someone will
need it in the future I had this little script sitting on my work PC
for a while. It should be doing what the OP asked.

Just put the module level variable PAINT_GRADIENTS to False to see the
real panels layout, and re-set it to True to get the gradient effects.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

gradient_stuff.py (3.06 KB)

···

On 26 April 2012 01:36, C M wrote:

On Wed, Apr 25, 2012 at 6:42 PM, Roger C. <chanhy@vcu.edu> wrote:

Platform is window 7 and xp, and just the regular wx.button. The button has
a little round on the corner and the space between the round edge and the
rectangle space are white. Is there a way to fill that space with colour?

See ButtonPanel in the wxPython Demo for some ideas about how that can
be done. Andrea did not use a wxButton, though, which *won't* allow
this, I think.

Also, if I apply gradient on the panel, how do I make that gradient on the
panel matches the main frame?

I think to do that perfectly is impossible: when the frame is
resized, the frame's background panel will also resize such that the
gradient will change, so that it even if the subpanels matched it
before (by choosing just the right gradient for each given their
positions), they won't match it after resizing. The difference might
be subtle, though.

I guess it's possible you could trigger a paint event on the frame's
resize that calculates what each subpanel's gradient has to be to
perfectly blend with the background gradient.

I've used gradients but never in this subpanel way. Are you sure you need them?

Hello,

In my wx application, that is pretty complex, I'd like to use multiprocessing to do some long running jobs that should be run in parallel.
Attached are 2 pieces of code.
- 'with_wx.py': is using wx, as I do to launch my application.
   This fails with this traceback:

Traceback (most recent call last):
   File "<string>", line 1, in <module>
   File "C:\Python27\Lib\multiprocessing\forking.py", line 374, in main
     self = load(from_parent)
   File "C:\Python27\Lib\pickle.py", line 1378, in load
     return Unpickler(file).load()
   File "C:\Python27\Lib\pickle.py", line 858, in load
     dispatch[key](self)
   File "C:\Python27\Lib\pickle.py", line 880, in load_eof
     raise EOFError
EOFError

- 'without wx.py': is the same code, but it doesn't use wx.
   This works fine.

I understand there may be dome problems running multiprocessing within a wx application, so what's the solution ?

Using Python 2.7.2 and wxPython 2.8.11

Thanks.

Raphael

with_wx.py (663 Bytes)

without_wx.py (658 Bytes)

Hi,

with_wx.py (740 Bytes)

···

On 8 May 2012 10:34, Raphael Mayoraz wrote:

Hello,

In my wx application, that is pretty complex, I'd like to use
multiprocessing to do some long running jobs that should be run in parallel.
Attached are 2 pieces of code.
- 'with_wx.py': is using wx, as I do to launch my application.
This fails with this traceback:

Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Python27\Lib\multiprocessing\forking.py", line 374, in main
self = load(from_parent)
File "C:\Python27\Lib\pickle.py", line 1378, in load
return Unpickler(file).load()
File "C:\Python27\Lib\pickle.py", line 858, in load
dispatch[key](self)
File "C:\Python27\Lib\pickle.py", line 880, in load_eof
raise EOFError
EOFError

- 'without wx.py': is the same code, but it doesn't use wx.
This works fine.

I understand there may be dome problems running multiprocessing within a wx
application, so what's the solution ?

Using Python 2.7.2 and wxPython 2.8.11

Try the attached modified sample, it works for me on Windows Vista 64
bit, wx 2.9.3 (I mean, it doesn't crash like your original sample,
although it does nothing by itself).

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Thanks, I'm getting the same. As you say, it does nothing. Now, I add something to be done before wx.CallAfter:
         wx.App.__init__(self)
         print 'do'
         wx.CallAfter(self.StartProcessing)

and the Mainloop at the end:

if __name__ == "__main__":
     app = App()
     app.MainLoop()

And now, I get the same error on the console + a wxPython stdout/stderr window with this (long) traceback:

Traceback (most recent call last):
   File "C:\Python27\lib\site-packages\wx-2.8-msw-unicode\wx\_core.py", line 14669, in <lambda>
     lambda event: event.callable(*event.args, **event.kw) )
   File "with_wx_andrea.py", line 17, in StartProcessing
     p.start()
   File "C:\Python27\Lib\multiprocessing\process.py", line 130, in start
     self._popen = Popen(self)
   File "C:\Python27\Lib\multiprocessing\forking.py", line 271, in __init__
     dump(process_obj, to_child, HIGHEST_PROTOCOL)
   File "C:\Python27\Lib\multiprocessing\forking.py", line 193, in dump
     ForkingPickler(file, protocol).dump(obj)
   File "C:\Python27\Lib\pickle.py", line 224, in dump
     self.save(obj)
   File "C:\Python27\Lib\pickle.py", line 331, in save
     self.save_reduce(obj=obj, *rv)
   File "C:\Python27\Lib\pickle.py", line 419, in save_reduce
     save(state)
   File "C:\Python27\Lib\pickle.py", line 286, in save
     f(self, obj) # Call unbound method with explicit self
   File "C:\Python27\Lib\pickle.py", line 649, in save_dict
     self._batch_setitems(obj.iteritems())
   File "C:\Python27\Lib\pickle.py", line 681, in _batch_setitems
     save(v)
   File "C:\Python27\Lib\pickle.py", line 286, in save
     f(self, obj) # Call unbound method with explicit self
   File "C:\Python27\Lib\multiprocessing\forking.py", line 66, in dispatcher
     self.save_reduce(obj=obj, *rv)
   File "C:\Python27\Lib\pickle.py", line 401, in save_reduce
     save(args)
   File "C:\Python27\Lib\pickle.py", line 286, in save
     f(self, obj) # Call unbound method with explicit self
   File "C:\Python27\Lib\pickle.py", line 548, in save_tuple
     save(element)
   File "C:\Python27\Lib\pickle.py", line 331, in save
     self.save_reduce(obj=obj, *rv)
   File "C:\Python27\Lib\pickle.py", line 419, in save_reduce
     save(state)
   File "C:\Python27\Lib\pickle.py", line 286, in save
     f(self, obj) # Call unbound method with explicit self
   File "C:\Python27\Lib\pickle.py", line 649, in save_dict
     self._batch_setitems(obj.iteritems())
   File "C:\Python27\Lib\pickle.py", line 681, in _batch_setitems
     save(v)
   File "C:\Python27\Lib\pickle.py", line 331, in save
     self.save_reduce(obj=obj, *rv)
   File "C:\Python27\Lib\pickle.py", line 396, in save_reduce
     save(cls)
   File "C:\Python27\Lib\pickle.py", line 286, in save
     f(self, obj) # Call unbound method with explicit self
   File "C:\Python27\Lib\pickle.py", line 748, in save_global
     (obj, module, name))
pickle.PicklingError: Can't pickle <type 'PySwigObject'>: it's not found as __builtin__.PySwigObject

Raphael

···

On 5/8/2012 10:39 AM, Andrea Gavana wrote:

Hi,

On 8 May 2012 10:34, Raphael Mayoraz wrote:

Hello,

In my wx application, that is pretty complex, I'd like to use
multiprocessing to do some long running jobs that should be run in parallel.
Attached are 2 pieces of code.
- 'with_wx.py': is using wx, as I do to launch my application.
  This fails with this traceback:

Traceback (most recent call last):
  File "<string>", line 1, in<module>
  File "C:\Python27\Lib\multiprocessing\forking.py", line 374, in main
    self = load(from_parent)
  File "C:\Python27\Lib\pickle.py", line 1378, in load
    return Unpickler(file).load()
  File "C:\Python27\Lib\pickle.py", line 858, in load
    dispatch[key](self)
  File "C:\Python27\Lib\pickle.py", line 880, in load_eof
    raise EOFError
EOFError

- 'without wx.py': is the same code, but it doesn't use wx.
  This works fine.

I understand there may be dome problems running multiprocessing within a wx
application, so what's the solution ?

Using Python 2.7.2 and wxPython 2.8.11

Try the attached modified sample, it works for me on Windows Vista 64
bit, wx 2.9.3 (I mean, it doesn't crash like your original sample,
although it does nothing by itself).

Andrea.

Hi,

Hi,

Hello,

In my wx application, that is pretty complex, I'd like to use
multiprocessing to do some long running jobs that should be run in
parallel.
Attached are 2 pieces of code.
- 'with_wx.py': is using wx, as I do to launch my application.
This fails with this traceback:

Traceback (most recent call last):
File "<string>", line 1, in<module>
File "C:\Python27\Lib\multiprocessing\forking.py", line 374, in main
self = load(from_parent)
File "C:\Python27\Lib\pickle.py", line 1378, in load
return Unpickler(file).load()
File "C:\Python27\Lib\pickle.py", line 858, in load
dispatch[key](self)
File "C:\Python27\Lib\pickle.py", line 880, in load_eof
raise EOFError
EOFError

- 'without wx.py': is the same code, but it doesn't use wx.
This works fine.

I understand there may be dome problems running multiprocessing within a
wx
application, so what's the solution ?

Using Python 2.7.2 and wxPython 2.8.11

Try the attached modified sample, it works for me on Windows Vista 64
bit, wx 2.9.3 (I mean, it doesn't crash like your original sample,
although it does nothing by itself).

Andrea.

Thanks, I'm getting the same. As you say, it does nothing. Now, I add
something to be done before wx.CallAfter:
wx.App.__init__(self)
print 'do'
wx.CallAfter(self.StartProcessing)

and the Mainloop at the end:

if __name__ == "__main__":
app = App()
app.MainLoop()

And now, I get the same error on the console + a wxPython stdout/stderr
window with this (long) traceback:

Traceback (most recent call last):

<snip>

I have never used multiprocessing in this way. What I normally do is
the following:

1) From the main wx thread, start a separate thread (a background one);
2) This background thread will be responsible to start, monitor and
clean up the various processes you start;
3) Once all the processes are finished, the background thread simply terminates.

I have managed to build complex interactions between threads and
multiple processes with this architecture, actually spawning processes
to read massive output files with Fortran+f2py+numpy and plotting the
results with matplotlib, everything in parallel, while keeping the
main GUI thread responsive.

The actual advantage you will see depends on how many processors you
have available and how much RAM you can spare for them, together with
your system architecture (32 bit/64 bit). Just keep in mind that, at
least on Windows, sharing big objects between processes is likely
going to be very slow. I have found that going through temporary
pickle files on disk to share data between processes is much faster if
your data is big.

Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

···

On 8 May 2012 11:28, Raphael Mayoraz wrote:

On 5/8/2012 10:39 AM, Andrea Gavana wrote:

On 8 May 2012 10:34, Raphael Mayoraz wrote:

Do you mean you've never use the 'multiprocessing' module, but the 'threading' one
instead. If yes, that's what I've done so far. But I got a problem that may have to do
with shared memory and was hoping 'multiprocessing' would be safer in that domain.

various
Popen subprocesses jobs that run various computation program (sometimes through gmake).
And in the middle of the computation one gmake job stops saying it cannot find a piece
of software it needs.

In other words:
Background_thread(threading.Thread):
     newThread1 = ComputeThis(args1):
     newThread2 = ComputeThis(args2):
     ...
     newThread1.start()
     newThread2.start()
     ...
     # Than I use the join() method to wait that newThread1, newThread2, ... are finished.

ComputeThis(threading.Thread):
     ...
     def run():
         ...
         cmd = 'gmake -f myMakeFile.make'
         proc = subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE, stderr=subprocess.PIPE, stdout=subprocess.PIPE)
         proc.communicate()
...

And in 'myMakeFile.make' there are various calls to other software and sometimes
I get a gmake error saying one of those software could be found.

Raphael

···

On 5/8/2012 11:41 AM, Andrea Gavana wrote:

Hi,

On 8 May 2012 11:28, Raphael Mayoraz wrote:

On 5/8/2012 10:39 AM, Andrea Gavana wrote:

Hi,

On 8 May 2012 10:34, Raphael Mayoraz wrote:

Hello,

In my wx application, that is pretty complex, I'd like to use
multiprocessing to do some long running jobs that should be run in
parallel.
Attached are 2 pieces of code.
- 'with_wx.py': is using wx, as I do to launch my application.
  This fails with this traceback:

Traceback (most recent call last):
  File "<string>", line 1, in<module>
  File "C:\Python27\Lib\multiprocessing\forking.py", line 374, in main
    self = load(from_parent)
  File "C:\Python27\Lib\pickle.py", line 1378, in load
    return Unpickler(file).load()
  File "C:\Python27\Lib\pickle.py", line 858, in load
    dispatch[key](self)
  File "C:\Python27\Lib\pickle.py", line 880, in load_eof
    raise EOFError
EOFError

- 'without wx.py': is the same code, but it doesn't use wx.
  This works fine.

I understand there may be dome problems running multiprocessing within a
wx
application, so what's the solution ?

Using Python 2.7.2 and wxPython 2.8.11

Try the attached modified sample, it works for me on Windows Vista 64
bit, wx 2.9.3 (I mean, it doesn't crash like your original sample,
although it does nothing by itself).

Andrea.

Thanks, I'm getting the same. As you say, it does nothing. Now, I add
something to be done before wx.CallAfter:
        wx.App.__init__(self)
        print 'do'
        wx.CallAfter(self.StartProcessing)

and the Mainloop at the end:

if __name__ == "__main__":
    app = App()
    app.MainLoop()

And now, I get the same error on the console + a wxPython stdout/stderr
window with this (long) traceback:

Traceback (most recent call last):

<snip>

I have never used multiprocessing in this way. What I normally do is
the following:

1) From the main wx thread, start a separate thread (a background one);
2) This background thread will be responsible to start, monitor and
clean up the various processes you start;
3) Once all the processes are finished, the background thread simply terminates.

I have managed to build complex interactions between threads and
multiple processes with this architecture, actually spawning processes
to read massive output files with Fortran+f2py+numpy and plotting the
results with matplotlib, everything in parallel, while keeping the
main GUI thread responsive.

Andrea.

From my 'background' thread, I start several threads. Those are running

Hi,

Hi,

Hi,

Hello,

In my wx application, that is pretty complex, I'd like to use
multiprocessing to do some long running jobs that should be run in
parallel.
Attached are 2 pieces of code.
- 'with_wx.py': is using wx, as I do to launch my application.
This fails with this traceback:

Traceback (most recent call last):
File "<string>", line 1, in<module>
File "C:\Python27\Lib\multiprocessing\forking.py", line 374, in main
self = load(from_parent)
File "C:\Python27\Lib\pickle.py", line 1378, in load
return Unpickler(file).load()
File "C:\Python27\Lib\pickle.py", line 858, in load
dispatch[key](self)
File "C:\Python27\Lib\pickle.py", line 880, in load_eof
raise EOFError
EOFError

- 'without wx.py': is the same code, but it doesn't use wx.
This works fine.

I understand there may be dome problems running multiprocessing within
a
wx
application, so what's the solution ?

Using Python 2.7.2 and wxPython 2.8.11

Try the attached modified sample, it works for me on Windows Vista 64
bit, wx 2.9.3 (I mean, it doesn't crash like your original sample,
although it does nothing by itself).

Andrea.

Thanks, I'm getting the same. As you say, it does nothing. Now, I add
something to be done before wx.CallAfter:
wx.App.__init__(self)
print 'do'
wx.CallAfter(self.StartProcessing)

and the Mainloop at the end:

if __name__ == "__main__":
app = App()
app.MainLoop()

And now, I get the same error on the console + a wxPython stdout/stderr
window with this (long) traceback:

Traceback (most recent call last):

<snip>

I have never used multiprocessing in this way. What I normally do is
the following:

1) From the main wx thread, start a separate thread (a background one);
2) This background thread will be responsible to start, monitor and
clean up the various processes you start;
3) Once all the processes are finished, the background thread simply
terminates.

I have managed to build complex interactions between threads and
multiple processes with this architecture, actually spawning processes
to read massive output files with Fortran+f2py+numpy and plotting the
results with matplotlib, everything in parallel, while keeping the
main GUI thread responsive.

Andrea.

Do you mean you've never use the 'multiprocessing' module, but the
'threading' one
instead. If yes, that's what I've done so far.

No, what I mean is that I use threading *and* multiprocessing at the
same time, pretty much as you are doing (from your description below).

But I got a problem that may
have to do
with shared memory and was hoping 'multiprocessing' would be safer in that
domain.

From my 'background' thread, I start several threads. Those are running
various
Popen subprocesses jobs that run various computation program (sometimes
through gmake).
And in the middle of the computation one gmake job stops saying it cannot
find a piece
of software it needs.

In other words:
Background_thread(threading.Thread):
newThread1 = ComputeThis(args1):
newThread2 = ComputeThis(args2):
...
newThread1.start()
newThread2.start()
...
# Than I use the join() method to wait that newThread1, newThread2, ...
are finished.

ComputeThis(threading.Thread):
...
def run():
...
cmd = 'gmake -f myMakeFile.make'
proc = subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE,
stderr=subprocess.PIPE, stdout=subprocess.PIPE)
proc.communicate()
...

And in 'myMakeFile.make' there are various calls to other software and
sometimes
I get a gmake error saying one of those software could be found.

Well, this has nothing to do with multiprocessing shared
memory/objects. You are simply starting a separate process to run
gmake, you don't share anything between your parallel process. But
then again, what would you share? And, even if you get an error from
gmake, I doubt this error will bring down your GUI.

···

On 8 May 2012 12:01, Raphael Mayoraz wrote:

On 5/8/2012 11:41 AM, Andrea Gavana wrote:

On 8 May 2012 11:28, Raphael Mayoraz wrote:

On 5/8/2012 10:39 AM, Andrea Gavana wrote:

On 8 May 2012 10:34, Raphael Mayoraz wrote:

Raphael

--
To unsubscribe, send email to wxPython-users+unsubscribe@googlegroups.com
or visit http://groups.google.com/group/wxPython-users?hl=en

--
Andrea.

"Imagination Is The Only Weapon In The War Against Reality."
http://xoomer.alice.it/infinity77/

Thanks for your patience and explanations. Before dealing with the gmake error,
and possibly in order to fix it, I want to switch from 'threading' to 'multiprocessing'.
So in what I describe above, the 'ComputeThis' class would be a
'multiprocessing.Process' class. Now, back to the original problem, I tried
following your suggestion to use wx.CallAfter, but I'm still getting the pickle
error. So, I can't make multiprocessing work at all.

Raphael

···

On 5/8/2012 12:25 PM, Andrea Gavana wrote:

Hi,

On 8 May 2012 12:01, Raphael Mayoraz wrote:

On 5/8/2012 11:41 AM, Andrea Gavana wrote:

Hi,

On 8 May 2012 11:28, Raphael Mayoraz wrote:

On 5/8/2012 10:39 AM, Andrea Gavana wrote:

Hi,

On 8 May 2012 10:34, Raphael Mayoraz wrote:

Hello,

In my wx application, that is pretty complex, I'd like to use
multiprocessing to do some long running jobs that should be run in
parallel.
Attached are 2 pieces of code.
- 'with_wx.py': is using wx, as I do to launch my application.
  This fails with this traceback:

Traceback (most recent call last):
  File "<string>", line 1, in<module>
  File "C:\Python27\Lib\multiprocessing\forking.py", line 374, in main
    self = load(from_parent)
  File "C:\Python27\Lib\pickle.py", line 1378, in load
    return Unpickler(file).load()
  File "C:\Python27\Lib\pickle.py", line 858, in load
    dispatch[key](self)
  File "C:\Python27\Lib\pickle.py", line 880, in load_eof
    raise EOFError
EOFError

- 'without wx.py': is the same code, but it doesn't use wx.
  This works fine.

I understand there may be dome problems running multiprocessing within
a
wx
application, so what's the solution ?

Using Python 2.7.2 and wxPython 2.8.11

Try the attached modified sample, it works for me on Windows Vista 64
bit, wx 2.9.3 (I mean, it doesn't crash like your original sample,
although it does nothing by itself).

Andrea.

Thanks, I'm getting the same. As you say, it does nothing. Now, I add
something to be done before wx.CallAfter:
        wx.App.__init__(self)
        print 'do'
        wx.CallAfter(self.StartProcessing)

and the Mainloop at the end:

if __name__ == "__main__":
    app = App()
    app.MainLoop()

And now, I get the same error on the console + a wxPython stdout/stderr
window with this (long) traceback:

Traceback (most recent call last):

<snip>

I have never used multiprocessing in this way. What I normally do is
the following:

1) From the main wx thread, start a separate thread (a background one);
2) This background thread will be responsible to start, monitor and
clean up the various processes you start;
3) Once all the processes are finished, the background thread simply
terminates.

I have managed to build complex interactions between threads and
multiple processes with this architecture, actually spawning processes
to read massive output files with Fortran+f2py+numpy and plotting the
results with matplotlib, everything in parallel, while keeping the
main GUI thread responsive.

Andrea.

Do you mean you've never use the 'multiprocessing' module, but the
'threading' one
instead. If yes, that's what I've done so far.

No, what I mean is that I use threading *and* multiprocessing at the
same time, pretty much as you are doing (from your description below).

But I got a problem that may
have to do
with shared memory and was hoping 'multiprocessing' would be safer in that
domain.

From my 'background' thread, I start several threads. Those are running
various
Popen subprocesses jobs that run various computation program (sometimes
through gmake).
And in the middle of the computation one gmake job stops saying it cannot
find a piece
of software it needs.

In other words:
Background_thread(threading.Thread):
    newThread1 = ComputeThis(args1):
    newThread2 = ComputeThis(args2):
    ...
    newThread1.start()
    newThread2.start()
    ...
    # Than I use the join() method to wait that newThread1, newThread2, ...
are finished.

ComputeThis(threading.Thread):
    ...
    def run():
        ...
        cmd = 'gmake -f myMakeFile.make'
        proc = subprocess.Popen(cmd, shell=True, stdin=subprocess.PIPE,
stderr=subprocess.PIPE, stdout=subprocess.PIPE)
        proc.communicate()
...

And in 'myMakeFile.make' there are various calls to other software and
sometimes
I get a gmake error saying one of those software could be found.

Well, this has nothing to do with multiprocessing shared
memory/objects. You are simply starting a separate process to run
gmake, you don't share anything between your parallel process. But
then again, what would you share? And, even if you get an error from
gmake, I doubt this error will bring down your GUI.

Sorry -- I haven't looked at your code, but may have a hint:

multiprocessing uses pickling to exchange data between processes -- it
looks here like you are using a wx object in your sub-process -- wx
objects are not picklable, hence this error.

If you need that wx object, you
ll need to re-factor -- if you don't need it, and it's just getting
passed in with globals or something, you'll need to be more explicite
about what state you're passing to the sub-process.

HTH,

-Chris

···

On Tue, May 8, 2012 at 2:28 AM, Raphael Mayoraz <maygeo@netplus.ch> wrote:

File "C:\Python27\Lib\pickle.py", line 748, in save_global
(obj, module, name))
pickle.PicklingError: Can't pickle <type 'PySwigObject'>: it's not found as
__builtin__.PySwigObject

--

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

Chris.Barker@noaa.gov

Agreed. You need to try and keep the child processes separated from the wx code, including the initialized state of wx if possible[1]. Andrea suggested one way to do this, by launching the child processes from a thread that is already separate from the wx thread. Another way would be to create your child processes before creating the wx.App object, perhaps using a multiprocessing.Pool object so you can send them tasks to do later if needed.

[1] Since multiprocessing uses fork() on *nix then the children are essentially copys of the parent process, including wx if it was imported and initialized when the children were created. But since they all think they are essentially the same instance of wx then it can cause problems with the native UI if they try to use wx in any way.

···

On 5/8/12 8:27 AM, Chris Barker wrote:

On Tue, May 8, 2012 at 2:28 AM, Raphael Mayoraz<maygeo@netplus.ch> wrote:

  File "C:\Python27\Lib\pickle.py", line 748, in save_global
    (obj, module, name))
pickle.PicklingError: Can't pickle<type 'PySwigObject'>: it's not found as
__builtin__.PySwigObject

Sorry -- I haven't looked at your code, but may have a hint:

multiprocessing uses pickling to exchange data between processes -- it
looks here like you are using a wx object in your sub-process -- wx
objects are not picklable, hence this error.

If you need that wx object, you
ll need to re-factor -- if you don't need it, and it's just getting
passed in with globals or something, you'll need to be more explicite
about what state you're passing to the sub-process.

--
Robin Dunn
Software Craftsman

Many thanks Robin, Chris, Andrea,

Got it, works fine!

Raphael

···

On 5/8/2012 6:11 PM, Robin Dunn wrote:

On 5/8/12 8:27 AM, Chris Barker wrote:

On Tue, May 8, 2012 at 2:28 AM, Raphael Mayoraz<maygeo@netplus.ch> >> wrote:

  File "C:\Python27\Lib\pickle.py", line 748, in save_global
    (obj, module, name))
pickle.PicklingError: Can't pickle<type 'PySwigObject'>: it's not found as
__builtin__.PySwigObject

Sorry -- I haven't looked at your code, but may have a hint:

multiprocessing uses pickling to exchange data between processes -- it
looks here like you are using a wx object in your sub-process -- wx
objects are not picklable, hence this error.

If you need that wx object, you
ll need to re-factor -- if you don't need it, and it's just getting
passed in with globals or something, you'll need to be more explicite
about what state you're passing to the sub-process.

Agreed. You need to try and keep the child processes separated from the wx code, including the initialized state of wx if possible[1]. Andrea suggested one way to do this, by launching the child processes from a thread that is already separate from the wx thread. Another way would be to create your child processes before creating the wx.App object, perhaps using a multiprocessing.Pool object so you can send them tasks to do later if needed.

[1] Since multiprocessing uses fork() on *nix then the children are essentially copys of the parent process, including wx if it was imported and initialized when the children were created. But since they all think they are essentially the same instance of wx then it can cause problems with the native UI if they try to use wx in any way.