On Mon, Nov 02, 2009 at 08:14:40PM +0000, corvid wrote:
Jorge wrote:
On Mon, Nov 02, 2009 at 07:26:49PM +0000, corvid wrote:
Jorge wrote:
On Mon, Nov 02, 2009 at 03:07:29PM -0300, Jorge Arellano Cid wrote:
On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote:
[...] I tried putting the pieces under ~/.dillo/, similar to how I'd had them before, and got error msgs instead of working dpis. Would it make more sense for me to dig in now to understand what is happening, or are the docs and patches coming very soon?
I should write Docs soon (before Friday). There were no changes regarding dpis in ~/.dillo/. I haven't tested them though. Let me check here...
After changing the table colors in file.dpi, more or less it worked with:
make dpidc stop mkdir -p ~/.dillo/dpi/file cp file.dpi ~/.dillo/dpi/file dillo .
It may be that you already have dpis there, and those will not work with the new code. They need convertion to the new dsh API. If this is the case, you can wait a bit for the docs, or give a look to the respective "convert to dsh API" patch in the repo.
When dillo tries to talk to dpid: After connect(), lsof -i shows me ESTABLISHED for both sides After write(), the dpid side is gone and dillo says CLOSE_WAIT After shutdown(), both sides are gone. Then Dpi_get_server_port: can't read server port from dpid. and ** ERROR **: dpi.c: can't start dpi daemon
There may be an old dpid binary around. Try this in two terminal windows:
1.- 2.- cd src/dpid cd src/dpid ./dpid ./dpidc stop
If dpid stops, it's OK. Most probably an old dpid is started.
Is anybody else seeing this problem?
But that dpid had been listening on the port advertised in dpid_comm_keys, which an old dpid wouldn't have been doing.
OK. The error looks like a problem in the authentication phase, but I'm not sure. Does the above test work for you? Are you testing on GNU/Linux or other OS? Is there a chance of another app trying to talk to the same port (DPID_BASE_PORT)? Are you trying to run all from ~/.dillo, or a global install? -- Cheers Jorge.-