Hi, Today the big work on DPI/DPIP was committed! The new framework and API is easier to use and more powerful. Lots of bugs and constraints were removed in the process. It was a lot of work but now is easier to fix and implement new things. After all the DPI framework was growing as new needs arose and it needed a rewrite since long ago. There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less). One of them is the new select() based file dpi. It should be faster and use less resources (all happens in a single process now). Note: currently the code uses Internet Domain sockets instead of Unix domain sockets. This was initially meant for MINIX, but in the process several bugs were fixed, the code restructured, added more error handling and improved in general. In the future we may go back to UDS, but the cleanup gains will remain. Please test and enjoy. ...and remember to "dpidc stop" before "make install-strip". -- Cheers Jorge.-
Hi. I got compiling problem on FreeBSD 6.4. if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDPIDRC_SYS='"/usr/local/etc/dillo/dpidrc"' -I/usr/local/include -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -W -Wno-unused-parameter -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" -c -o dpid.o dpid.c; \ then mv -f ".deps/dpid.Tpo" ".deps/dpid.Po"; else rm -f ".deps/dpid.Tpo"; exit 1; fi dpid.c: In function `init_ids_srs_socket': dpid.c:615: error: `IPPORT_USERRESERVED' undeclared (first use in this function) dpid.c:615: error: (Each undeclared identifier is reported only once dpid.c:615: error: for each function it appears in.) dpid.c: In function `init_dpi_socket': dpid.c:637: error: `IPPORT_USERRESERVED' undeclared (first use in this function) Because FreeBSD 6.4 doesn't have IPPORT_USERRESERVED. Regards, furaisanjin
On Mon, Nov 02, 2009 at 10:57:00AM +0900, furaisanjin wrote:
Hi.
I got compiling problem on FreeBSD 6.4.
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -DDPIDRC_SYS='"/usr/local/etc/dillo/dpidrc"' -I/usr/local/include -g -O2 -DD_DNS_THREADED -D_REENTRANT -D_THREAD_SAFE -Wall -W -W -Wno-unused-parameter -Waggregate-return -MT dpid.o -MD -MP -MF ".deps/dpid.Tpo" -c -o dpid.o dpid.c; \ then mv -f ".deps/dpid.Tpo" ".deps/dpid.Po"; else rm -f ".deps/dpid.Tpo"; exit 1; fi dpid.c: In function `init_ids_srs_socket': dpid.c:615: error: `IPPORT_USERRESERVED' undeclared (first use in this function) dpid.c:615: error: (Each undeclared identifier is reported only once dpid.c:615: error: for each function it appears in.) dpid.c: In function `init_dpi_socket': dpid.c:637: error: `IPPORT_USERRESERVED' undeclared (first use in this function)
Because FreeBSD 6.4 doesn't have IPPORT_USERRESERVED.
Thanks for the report. Please try the latest repo and send feedback! -- Cheers Jorge.-
That's a lot of code! Jorge wrote:
There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less).
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?
On Mon, Nov 02, 2009 at 04:16:53PM +0000, corvid wrote:
That's a lot of code!
Yes. I made the partial diffstats but have no idea on how much the whole pack was in the end. :)
Jorge wrote:
There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less).
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... -- Cheers Jorge.-
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. -- Cheers Jorge.-
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
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? -- Cheers Jorge.-
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.
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.-
Jorge wrote:
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)?
The test starts and stops dpid. GNU/Linux. lsof -i doesn't show anything else doing anything.
Are you trying to run all from ~/.dillo, or a global install?
All from ~/.dillo
dillo-dev wrote:
Jorge wrote:
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)?
The test starts and stops dpid. GNU/Linux. lsof -i doesn't show anything else doing anything.
Are you trying to run all from ~/.dillo, or a global install?
All from ~/.dillo
I removed the dpidrc and was looking at things, wasn't enlightened, wrote a new one, and now it's working. Evidently there was something wrong in the first one. Hurray! I did notice that dpid was making 8 dpi service entries from local, and then 8 more because it's regarding (perhaps rightly) my dpi_dir line as pointing to system dpis even though it's just pointing to the local ones. The 16 entries didn't seem to be harming anything, though.
On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote:
Hi,
Today the big work on DPI/DPIP was committed!
The new framework and API is easier to use and more powerful. Lots of bugs and constraints were removed in the process. It was a lot of work but now is easier to fix and implement new things. After all the DPI framework was growing as new needs arose and it needed a rewrite since long ago.
There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less).
One of them is the new select() based file dpi. It should be faster and use less resources (all happens in a single process now).
Note: currently the code uses Internet Domain sockets instead of Unix domain sockets. This was initially meant for MINIX, but in the process several bugs were fixed, the code restructured, added more error handling and improved in general. In the future we may go back to UDS, but the cleanup gains will remain.
Please test and enjoy.
For now I can just confirm that it works nice on DragonFly :-) Do you think it would be a good time now, to look into the view source dpi thing again? Cheers, Johannes
On Sat, Nov 07, 2009 at 07:23:43PM +0100, Johannes Hofmann wrote:
On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote:
Hi,
Today the big work on DPI/DPIP was committed!
The new framework and API is easier to use and more powerful. Lots of bugs and constraints were removed in the process. It was a lot of work but now is easier to fix and implement new things. After all the DPI framework was growing as new needs arose and it needed a rewrite since long ago.
There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less).
One of them is the new select() based file dpi. It should be faster and use less resources (all happens in a single process now).
Note: currently the code uses Internet Domain sockets instead of Unix domain sockets. This was initially meant for MINIX, but in the process several bugs were fixed, the code restructured, added more error handling and improved in general. In the future we may go back to UDS, but the cleanup gains will remain.
Please test and enjoy.
For now I can just confirm that it works nice on DragonFly :-)
Excellent.
Do you think it would be a good time now, to look into the view source dpi thing again?
The buffer size constraint and atomicity transfer hope (left to the OS) were removed. DPIP implementation handles it internally now. I was planning to work on the view source dpi a bit and at least advance it until the dpi gets the whole file so you can do the funny part. I can't but feel a bit guilty by the work you have put on it only to discover the framework was not up to the task. The DPIP framework grew by extending it to each new dpi needs, and there were constraints. This rewrite was necessary to make it more reliable in the concept, and not ad-hoc to the task. BTW, I still have to turn https into a server dpi to remove the dialog-storm bug, and to give a look into the cookies dpi to make it distinguish among different instances of dillo. View source is the first on the list, so if I were you I'd keep working on the scrolling patch and wait until Jorge commits. :) Or at your own choice let him finish the whole view source thing! -- Cheers Jorge.-
On Sun, Nov 08, 2009 at 10:15:43AM -0300, Jorge Arellano Cid wrote:
On Sat, Nov 07, 2009 at 07:23:43PM +0100, Johannes Hofmann wrote:
On Sun, Nov 01, 2009 at 06:24:18PM -0300, Jorge Arellano Cid wrote:
Hi,
Today the big work on DPI/DPIP was committed!
The new framework and API is easier to use and more powerful. Lots of bugs and constraints were removed in the process. It was a lot of work but now is easier to fix and implement new things. After all the DPI framework was growing as new needs arose and it needed a rewrite since long ago.
There're still pending patches and docs. Details are in the Changelog and Mercurial repo (hg log -v|less).
One of them is the new select() based file dpi. It should be faster and use less resources (all happens in a single process now).
Note: currently the code uses Internet Domain sockets instead of Unix domain sockets. This was initially meant for MINIX, but in the process several bugs were fixed, the code restructured, added more error handling and improved in general. In the future we may go back to UDS, but the cleanup gains will remain.
Please test and enjoy.
For now I can just confirm that it works nice on DragonFly :-)
Excellent.
Do you think it would be a good time now, to look into the view source dpi thing again?
The buffer size constraint and atomicity transfer hope (left to the OS) were removed. DPIP implementation handles it internally now.
I was planning to work on the view source dpi a bit and at least advance it until the dpi gets the whole file so you can do the funny part. I can't but feel a bit guilty by the work you have put on it only to discover the framework was not up to the task. The DPIP framework grew by extending it to each new dpi needs, and there were constraints. This rewrite was necessary to make it more reliable in the concept, and not ad-hoc to the task.
No problem at all. I'm glad if things get simpler.
BTW, I still have to turn https into a server dpi to remove the dialog-storm bug, and to give a look into the cookies dpi to make it distinguish among different instances of dillo. View source is the first on the list, so if I were you I'd keep working on the scrolling patch and wait until Jorge commits. :) Or at your own choice let him finish the whole view source thing!
I have updated the scrolling patch, but came to the conclusion, that it is not a good idea - at least not in the way I did it originally: I have made the scrollbars part of the UI and ripped out the code that deals with scrollbar widths in layout.cc. But then I thought about frames, and there we potentially need scrollbars for every frame. So for now will leave things as they are and focus on fixing real bugs. Cheers, Johannes
participants (4)
-
corvid＠lavabit.com -
furaisanjin＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de