Nathaniel Smith wrote:
> On Thu, Mar 12, 2009 at 9:51 AM, Mark Larsen wrote:
>> I took your advice and implemented using "Parallel Python". Can you comment
>> on your choice of pyprocessing? It seems like a simple re-write to switch
>> over.
>
> I use pyprocessing partly because it gave me the
On Thu, Mar 12, 2009 at 9:51 AM, Mark Larsen wrote:
> I took your advice and implemented using "Parallel Python". Can you comment
> on your choice of pyprocessing? It seems like a simple re-write to switch
> over.
I use pyprocessing partly because it gave me the impression that it
was more tune
>> After trying to upgrade to Python 2.6, I found that Numpy requires
>> Python 2.4 or 2.5. Since rpy requires Numpy, this seems an impasse.
Yes, on Windows, Numpy does not yet support Python 2.6 - although it
works fine on Linux and Mac. The good news is that NumPy 1.3 will
work on Windows, the
Gary Smith wrote:
> I thought I had established a new Python session subsequent to reboot,
> but I guess I was dreaming. Today I apparently had a new session,
> because the unittest errors declined to 6. Your suggestion that a new
> session would improve things
Running the unittests could be
I thought I had established a new Python session subsequent to reboot, but I
guess I was dreaming. Today I apparently had a new session, because the
unittest errors declined to 6. Your suggestion that a new session would
improve things and that Python 2.5 may be a problem seemed verified.
After
Thanks Nathaniel!
> Spawn multiple Python processes, each of which uses rpy2 to load
R, and talk to them over any Python-level IPC library.
The latter is really a huge improvement over the former, because there
are great IPC libraries for python -- e.g., the pyprocessing library
(included by defau
