Wed Jul 9 11:45:28 CDT 2008
Here is a bit more about how this works. The FURL stuff is new and we
are working on the docs for it. As you can see, you have caught us
right _before_ a stable release ;-)
How are you staring the controller and engines?
When the controller is started (either through ipcontroller or
ipcluster, which calls ipcontroller on localhost), it should write the
furl files to the ~./ipython dir on _that_ machine. If the engines or
clint is running on a different machine, you will need to move the
furl files to the ~./ipython dir on the machine that the client or
engine is running on.
The error you are getting makes it look like the controller is running
on a different machine that the client and that the furl file for the
client has not been moved to the ~./ipython dir of the clients host.
Just to make sure everything is working, can you try to stat the
controller and engines on localhost using:
ipcluster -n 4
And then try to run helloworld.py on that same host?
If that doesn't work, something else is going on and we can help you
figure it out. The other thing to look at is the log files in
~./ipython/log. These should show if there are other odd things going
On Wed, Jul 9, 2008 at 6:26 AM, Darren Dale <firstname.lastname@example.org> wrote:
> I am getting into ipython's parallel execution this morning, but I've run into
> a problem with missing furl files. The docs say:
>> As a user, you don't need to know anything about the details of these
>> FURLs, other than that when the controller starts, it saves a set of FURLs
>> to files named something.furl. The default location of these files is your
>> ~./ipython directory.
> but when I run examples/kernel/helloworld.py, I get:
> ValueError: not a furl or a file containing a
> furl: /home/darren/.ipython/ipcontroller-tc.furl
> Probably it is something simple that broke during the transition from the
> ipython1 branch, and devs who already have furl files wouldnt have run into
> IPython-dev mailing list
More information about the IPython-dev