- Dillo-dev - lists.mailman3.com

weird font

by marc＠marcengelhardt.com

Jorge wrote: If I remove "MS Courier New", it works OK. Any clues? I think the problem is the missing quote signs ("") before and after the font name (MS Courier New). I can be wrong, but I think that Dillo doesn't recognizes that the three words (MS, Courier, New), which normally builds the font, must be combined to build a valid font. The problem can be fixed if you add a feature to Dillo, which let Dillo recognizes that a string in a CSS rule (before a comma) represents a valid font and should be applied to the elements on the page, which are affected by the CSS rule. So, Dillo should be recognizes fonts, which are one, two or three words in length. Please keep in mind, that font names, which are between the quote signs, must also be recognized by Dillo.

Nov. 10, 2009

weird font

by Johannes.Hofmann＠gmx.de

Hi Jorge, On Tue, Nov 10, 2009 at 06:46:45PM -0300, Jorge Arellano Cid wrote: > Hi, > > On some sites I get weird fonts. Today I got to isolate the > problem. See attached file. Here it displays like this: > > http://www.dillo.org/test/xmp2.png > > The embedded CSS says: > > pre { font-family: MS Courier New, Courier, monospace; } > > If I remove "MS Courier New", it works OK. > Any clues? There are multiple issues with font selection: * The CSS parser only returns the part until the first blank ('MS' in this case). * StyleEngine currently does not handle comma separated font name lists (see \todo comment). * ::fltk::font(name, fa); in fltkplatform.cc does not offer a way to determine whether a font with that name actually exists on the system. Instead if no exact match can be found, it guesses a replacement font. This makes it impossible for dillo to choose the right one from a given list. In your specific case, fltk gets the string 'MS' and on your system it seems to find some funny font that has a similar name. Cheers, Johannes

Nov. 10, 2009

weird font

by jcid＠dillo.org

Hi, On some sites I get weird fonts. Today I got to isolate the problem. See attached file. Here it displays like this: http://www.dillo.org/test/xmp2.png The embedded CSS says: pre { font-family: MS Courier New, Courier, monospace; } If I remove "MS Courier New", it works OK. Any clues? -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Tue, Nov 10, 2009 at 05:51:08PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 08:27:23PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > > > the problem happens. There isn't any specific page either. > > > > > > > > > > The point is we have massive changes in the DPI area, not in > > > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > > > equation. If it happens with HTTPS, DPI participates. > > > > > > > > > > I'd expect you not being able to trigger the bug by using the > > > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > > > going to the bookmark page and then keep Ctrl-r pressed so that it > > > > reloads continiously. After a while I get a segmentation fault, but > > > > no proper stack unfortunately. > > > > > > Was the crash possible before the DPI changes? > > > > One more thing. There is a file descriptor leak you can see with > > > > diff -r 8535113920b1 src/IO/dpi.c > > --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 > > +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 > > @@ -90,7 +90,7 @@ > > static void Dpi_close_fd(int fd) > > { > > int st; > > - > > +fprintf(stderr, "===> close %d\n", fd); > > dReturn_if (fd < 0); > > do > > st = close(fd); > > @@ -432,6 +432,7 @@ > > if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { > > ret = fd; > > } > > +fprintf(stderr, "===> socket %d\n", fd); > > return ret; > > } > > > > > > Each time one accesses the bookmarks page one fd is leaked. I think > > there is also some close()'s missing in the error cases. > > No FD leak here, the respective FD is closed by IO, although > there were a couple of FD leaks elsewhere (fixed in repo). Yes, problem is gone, nice! Cheers, Johannes

Nov. 10, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Tue, Nov 10, 2009 at 05:48:12PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 08:00:43PM +0100, Johannes Hofmann wrote: > > > > PS: While looking at the code I found that Dpi_make_socket_fd() > > could be simplified to just: > > > > return socket(AF_INET, SOCK_STREAM, 0); > > Yes, it was coded that way to set socket options from a single > function easily. When those proved unnecessary, the skeleton was > left just in case. Understood, but I thought the body of the function could be simplified like this: static int Dpi_make_socket_fd() { return socket(AF_INET, SOCK_STREAM, 0); } Cheers, Johannes

Nov. 10, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 08:27:23PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > > the problem happens. There isn't any specific page either. > > > > > > > > The point is we have massive changes in the DPI area, not in > > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > > equation. If it happens with HTTPS, DPI participates. > > > > > > > > I'd expect you not being able to trigger the bug by using the > > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > > going to the bookmark page and then keep Ctrl-r pressed so that it > > > reloads continiously. After a while I get a segmentation fault, but > > > no proper stack unfortunately. > > > > Was the crash possible before the DPI changes? > > One more thing. There is a file descriptor leak you can see with > > diff -r 8535113920b1 src/IO/dpi.c > --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 > +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 > @@ -90,7 +90,7 @@ > static void Dpi_close_fd(int fd) > { > int st; > - > +fprintf(stderr, "===> close %d\n", fd); > dReturn_if (fd < 0); > do > st = close(fd); > @@ -432,6 +432,7 @@ > if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { > ret = fd; > } > +fprintf(stderr, "===> socket %d\n", fd); > return ret; > } > > > Each time one accesses the bookmarks page one fd is leaked. I think > there is also some close()'s missing in the error cases. No FD leak here, the respective FD is closed by IO, although there were a couple of FD leaks elsewhere (fixed in repo). BTW, in the process I learnt this trick (GNU/Linux): ls -l /proc/`pgrep dillo`/fd -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 08:00:43PM +0100, Johannes Hofmann wrote: > > PS: While looking at the code I found that Dpi_make_socket_fd() > could be simplified to just: > > return socket(AF_INET, SOCK_STREAM, 0); Yes, it was coded that way to set socket options from a single function easily. When those proved unnecessary, the skeleton was left just in case. -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. Yes, a FD leak was responsible. -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. OK, I found the bug! Patch commit soon... -- Cheers Jorge.-

Nov. 10, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > the problem happens. There isn't any specific page either. > > > > > > The point is we have massive changes in the DPI area, not in > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > equation. If it happens with HTTPS, DPI participates. > > > > > > I'd expect you not being able to trigger the bug by using the > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > going to the bookmark page and then keep Ctrl-r pressed so that it > > reloads continiously. After a while I get a segmentation fault, but > > no proper stack unfortunately. > > Was the crash possible before the DPI changes? One more thing. There is a file descriptor leak you can see with diff -r 8535113920b1 src/IO/dpi.c --- a/src/IO/dpi.cgiMon Nov 09 14:22:27 2009 -0300 +++ b/src/IO/dpi.cgiMon Nov 09 20:25:34 2009 +0100 @@ -90,7 +90,7 @@ static void Dpi_close_fd(int fd) { int st; - +fprintf(stderr, "===> close %d\n", fd); dReturn_if (fd < 0); do st = close(fd); @@ -432,6 +432,7 @@ if ((fd = socket(AF_INET, SOCK_STREAM, 0)) != -1) { ret = fd; } +fprintf(stderr, "===> socket %d\n", fd); return ret; } Each time one accesses the bookmarks page one fd is leaked. I think there is also some close()'s missing in the error cases. Cheers, Johannes

Nov. 9, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Mon, Nov 09, 2009 at 03:40:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > > I dont't know any trigger yet. I just browse pages and occasionally > > > > the problem happens. There isn't any specific page either. > > > > > > The point is we have massive changes in the DPI area, not in > > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > > equation. If it happens with HTTPS, DPI participates. > > > > > > I'd expect you not being able to trigger the bug by using the > > > file dpi, but if you can with plain HTTP it's a surprise. > > > > Not 100% sure if it is the same issue, but I can crash dillo by > > going to the bookmark page and then keep Ctrl-r pressed so that it > > reloads continiously. After a while I get a segmentation fault, but > > no proper stack unfortunately. > > Was the crash possible before the DPI changes? No. BTW. I can now reproduce it on Linux under valgrind. Things seem to be ok for a while until suddenly: [bookmarks dpi]: (v.13): accepting connections... [bookmarks dpi]: (v.13): accepting connections... ==21677== Warning: invalid file descriptor 1019 in syscall socket() ==21677== Warning: invalid file descriptor 1019 in syscall pipe() ==21677== Invalid read of size 4 ==21677== at 0x8059D48: a_Url_str (url.c:71) ==21677== by 0x8059F22: a_Url_dup (url.c:425) ==21677== by 0x80552D7: a_Bw_add_url (bw.c:210) ==21677== by 0x805B9E0: Nav_open_url (nav.c:240) ==21677== by 0x8050AB4: UI::handle(int) (ui.cc:803) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80DEF20: fltk::TabGroup::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x8054C48: CustTabGroup::handle(int) (uicmd.cc:315) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80BBAFC: fltk::Group::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80F26A3: fltk::Window::handle(int) (in /home/hofmann/soft/bin/dillo) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) ==21677== Address 0x447a4d0 is 0 bytes inside a block of size 60 free'd ==21677== at 0x4022B8A: free (vg_replace_malloc.c:323) ==21677== by 0x805B6B2: a_Nav_cancel_expect (nav.c:252) ==21677== by 0x805F91D: a_Capi_ccc (capi.c:610) ==21677== by 0x805A352: a_Chain_fcb (chain.c:113) ==21677== by 0x8081B11: a_Dpi_ccc (dpi.c:713) ==21677== by 0x8081A3A: a_Dpi_ccc (dpi.c:689) ==21677== by 0x805A3D2: a_Chain_bcb (chain.c:136) ==21677== by 0x806012B: a_Capi_dpi_send_cmd (capi.c:493) ==21677== by 0x8060AB9: a_Capi_open_url (capi.c:365) ==21677== by 0x805B9B9: Nav_open_url (nav.c:238) ==21677== by 0x8050AB4: UI::handle(int) (ui.cc:803) ==21677== by 0x80F04AA: fltk::Widget::send(int) (in /home/hofmann/soft/bin/dillo) and so on. Cheers, Johannes PS: While looking at the code I found that Dpi_make_socket_fd() could be simplified to just: return socket(AF_INET, SOCK_STREAM, 0);

Nov. 9, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 07:24:45PM +0100, Johannes Hofmann wrote: > On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > > I dont't know any trigger yet. I just browse pages and occasionally > > > the problem happens. There isn't any specific page either. > > > > The point is we have massive changes in the DPI area, not in > > dillo. If you trigger it while browsing HTTP, DPI is out of the > > equation. If it happens with HTTPS, DPI participates. > > > > I'd expect you not being able to trigger the bug by using the > > file dpi, but if you can with plain HTTP it's a surprise. > > Not 100% sure if it is the same issue, but I can crash dillo by > going to the bookmark page and then keep Ctrl-r pressed so that it > reloads continiously. After a while I get a segmentation fault, but > no proper stack unfortunately. Was the crash possible before the DPI changes? -- Cheers Jorge.-

Nov. 9, 2009

EAGAIN loop in IO_read

by Johannes.Hofmann＠gmx.de

On Mon, Nov 09, 2009 at 11:34:36AM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > > I dont't know any trigger yet. I just browse pages and occasionally > > the problem happens. There isn't any specific page either. > > The point is we have massive changes in the DPI area, not in > dillo. If you trigger it while browsing HTTP, DPI is out of the > equation. If it happens with HTTPS, DPI participates. > > I'd expect you not being able to trigger the bug by using the > file dpi, but if you can with plain HTTP it's a surprise. Not 100% sure if it is the same issue, but I can crash dillo by going to the bookmark page and then keep Ctrl-r pressed so that it reloads continiously. After a while I get a segmentation fault, but no proper stack unfortunately. Cheers, Johannes

Nov. 9, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 12:05:30PM +0900, furaisanjin wrote: > I dont't know any trigger yet. I just browse pages and occasionally > the problem happens. There isn't any specific page either. The point is we have massive changes in the DPI area, not in dillo. If you trigger it while browsing HTTP, DPI is out of the equation. If it happens with HTTPS, DPI participates. I'd expect you not being able to trigger the bug by using the file dpi, but if you can with plain HTTP it's a surprise. -- Cheers Jorge.-

Nov. 9, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

I dont't know any trigger yet. I just browse pages and occasionally the problem happens. There isn't any specific page either. Regards, furaisanjin 2009/11/9, Jorge Arellano Cid <jcid(a)dillo.org>: > On Mon, Nov 09, 2009 at 07:59:20AM +0900, furaisanjin wrote: >> Hi all. >> >> This might be FreeBSD specific issue but I have EAGAIN loop in >> IO_read. I don't know anything yet why this happens but at some point >> read function keeps returning EAGAIN in IO_read and nothing is read. >> Do you have any idea how to investigate this further? I think this >> happens after DPI big change. > > How do you trigger the problem? > > It's possible that something weird is happening. Linux behavior > differs from BSD socket implementations. If you isolate a way to > reproduce the bug, we may ask other *BSD users to test, and I'd > have a hint of the code path. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Nov. 9, 2009

EAGAIN loop in IO_read

by jcid＠dillo.org

On Mon, Nov 09, 2009 at 07:59:20AM +0900, furaisanjin wrote: > Hi all. > > This might be FreeBSD specific issue but I have EAGAIN loop in > IO_read. I don't know anything yet why this happens but at some point > read function keeps returning EAGAIN in IO_read and nothing is read. > Do you have any idea how to investigate this further? I think this > happens after DPI big change. How do you trigger the problem? It's possible that something weird is happening. Linux behavior differs from BSD socket implementations. If you isolate a way to reproduce the bug, we may ask other *BSD users to test, and I'd have a hint of the code path. -- Cheers Jorge.-

Nov. 9, 2009

EAGAIN loop in IO_read

by furaisanjin＠gmail.com

Hi all. This might be FreeBSD specific issue but I have EAGAIN loop in IO_read. I don't know anything yet why this happens but at some point read function keeps returning EAGAIN in IO_read and nothing is read. Do you have any idea how to investigate this further? I think this happens after DPI big change. Regards, furaisanjin

Nov. 9, 2009

Big changes in DPI framework and API

by Johannes.Hofmann＠gmx.de

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

Nov. 8, 2009

Big changes in DPI framework and API

by jcid＠dillo.org

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.-

Nov. 8, 2009

Dillo package for Ubuntu 9.10

by Hole.destructor＠gmx.de

Dear Dillo developers, could anyone be so kind and build a Dillo package (with ssl enabled) and a FLTK2 package for the new Ubuntu version 9.10 Karmic Koala? Many thanks in advance, Alexander Voigt

Nov. 7, 2009

Big changes in DPI framework and API

by Johannes.Hofmann＠gmx.de

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

Nov. 7, 2009

[patch]: fix the default <th> style to match <td>

by Johannes.Hofmann＠gmx.de

On Sat, Nov 07, 2009 at 04:50:24PM +0000, Jeremy Henty wrote: > > I had assumed that the <th> style would be the same as the <td> style > but with bold and centering added, so I was surprised to see that it's > not. The <td> style has some border styling and padding that the <th> > style does not, which seems wrong to me. I'm attaching a patch that > brings the <th> style in line with my expectations, plus a test file > and before/after screenshots. Please comment! Agreed. I committed a slightly adjusted fix. Thanks, Johannes PS: There may be more glitches in the default user-agent style. Please report any strangeness.

Nov. 7, 2009

[patch]: fix the default <th> style to match <td>

by onepoint＠starurchin.org

I had assumed that the <th> style would be the same as the <td> style but with bold and centering added, so I was surprised to see that it's not. The <td> style has some border styling and padding that the <th> style does not, which seems wrong to me. I'm attaching a patch that brings the <th> style in line with my expectations, plus a test file and before/after screenshots. Please comment! Regards, Jeremy Henty

Nov. 7, 2009

Style sheet question (centering and list-style-type)

by furaisanjin＠gmail.com

2009/11/5 corvid <corvid(a)lavabit.com>: > It should be fixed now. Thank you. Now pages look better. Regards, furaisanjin

Nov. 5, 2009

Style sheet question (centering and list-style-type)

by corvid＠lavabit.com

It should be fixed now.

Nov. 5, 2009

Style sheet question (centering and list-style-type)

by furaisanjin＠gmail.com

Hi all. I'm wondering how this web page will be rendered. <HTML> <HEAD> <style></style> <TITLE>test</TITLE> </HEAD> <BODY> <div id="menu"> <ul> <li><a href="http://xxx.xxx.xxx/1">first second</a> </ul> </div> </BODY> </HTML> Recent dillo splits "first" and "second" words above and the first one is aligned on the left. Regards, furaisanjin

Nov. 4, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

2009/11/4 Jorge Arellano Cid <jcid(a)dillo.org>: > ?Please try Hg tip and report. OK, now the problem is solved. > ?BTW, are you using some BSD? Yes, I'm using FreeBSD as I reported in compilation problem. Regards, furaisanjin

Nov. 4, 2009

Crashes at bizmakoto.jp

by jcid＠dillo.org

On Tue, Nov 03, 2009 at 03:10:31PM +0000, corvid wrote: > Jorge wrote: > > On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > > > Hi. > > > > > > I don't try all pages but at least there are several pages where dillo > > > keeps crashing. One example is > > > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > > > shows something like this. > > > > It doesn't crash here... :P > > > > The were a couple of patches for cleanup_at_close, please > > try from the repository without them (upto 1404:d4a8309dc63c), > > and let us know how it goes. > > I don't see where the tag variable is set to anything at all in tip. > I don't get a crash, but I get gibberish in the page bugs. Right, I made hurried modifications to a good patch and that bug slipped in. -- Cheers Jorge.-

Nov. 4, 2009

Crashes at bizmakoto.jp

by jcid＠dillo.org

On Wed, Nov 04, 2009 at 09:04:40PM +0900, furaisanjin wrote: > 2009/11/4 corvid <corvid(a)lavabit.com>: > > I don't see where the tag variable is set to anything at all in tip. > > Agree. > > > I don't get a crash, but I get gibberish in the page bugs. > > That's interesting aspect in Linux, isn't it? How can you access to > memory pointed by none-initialized variable in Linux? Please try Hg tip and report. BTW, are you using some BSD? -- Cheers Jorge.-

Nov. 4, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

2009/11/4 corvid <corvid(a)lavabit.com>: > I don't see where the tag variable is set to anything at all in tip. Agree. > I don't get a crash, but I get gibberish in the page bugs. That's interesting aspect in Linux, isn't it? How can you access to memory pointed by none-initialized variable in Linux? Regards, furaisanjin

Nov. 4, 2009

PATCH: don't force selection of first element in multi-select input.

by dtikhonov＠yahoo.com

> It looks like that would change the behaviour for size > 1 even if > multiple is not set. I see what you mean, there's a bug in my patch. I did not see that rows == 1 && multi == false in Html_tag_open_select(). I will try to come up with a new one... I need to save the 'multi' somewhere and then be able to check it in Html_tag_close_select(). C++ is not my forte. - Dmitri.

Nov. 4, 2009

PATCH: don't force selection of first element in multi-select input.

by corvid＠lavabit.com

Dmitri wrote: > Hi all, Hi Dmitri > Great job on dillo! :) > Below is a patch that prevents the browser from selecting the first element of a multi-select input. It looks like that would change the behaviour for size > 1 even if multiple is not set. *digs into the spec a little* Technically, section 17.6.1 just says that "If no OPTION element has the selected attribute set, user agent behavior for choosing which option is initially selected is undefined", as opposed to coming out and saying that we don't have to preselect _any_ for the multiple case if we don't want to. Checking good old firefox, let's see... If size is 1 and multiple is not set, one has to be selected in the option menu, of course. If size > 1, it does not force a selection, regardless of whether multiple is set. For some reason, that seems more reasonable to me in the multiple case than in the non-multiple case. But if we want to simply copy firefox here and we know that it doesn't break websites, I'd be all right with that.

Nov. 3, 2009

PATCH: don't force selection of first element in multi-select input.

by dtikhonov＠yahoo.com

Hi all, Great job on dillo! Below is a patch that prevents the browser from selecting the first element of a multi-select input. Thanks, - Dmitri. --- a/src/form.cc Mon Nov 02 13:41:37 2009 -0300 +++ b/src/form.cc Tue Nov 03 12:57:02 2009 -0500 @@ -767,8 +767,8 @@ void Html_tag_close_select(DilloHtml *ht DilloHtmlInput *input = Html_get_current_input(html); DilloHtmlSelect *select = input->select; - // BUG(?): should not do this for MULTI selections - select->ensureSelection (); + if (DILLO_HTML_INPUT_SEL_LIST != input->type) + select->ensureSelection (); SelectionResource *res = (SelectionResource*)input->embed->getResource(); select->addOptionsTo (res);

Nov. 3, 2009

Big changes in DPI framework and API

by corvid＠lavabit.com

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.

Nov. 3, 2009

Big changes in DPI framework and API

by corvid＠lavabit.com

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

Nov. 3, 2009

Crashes at bizmakoto.jp

by corvid＠lavabit.com

Jorge wrote: > On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > > Hi. > > > > I don't try all pages but at least there are several pages where dillo > > keeps crashing. One example is > > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > > shows something like this. > > It doesn't crash here... :P > > The were a couple of patches for cleanup_at_close, please > try from the repository without them (upto 1404:d4a8309dc63c), > and let us know how it goes. I don't see where the tag variable is set to anything at all in tip. I don't get a crash, but I get gibberish in the page bugs.

Nov. 3, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

2009/11/3 Jorge Arellano Cid <jcid(a)dillo.org>: > ?The were a couple of patches for cleanup_at_close, please > try from the repository without them (upto 1404:d4a8309dc63c), > and let us know how it goes. I did hg update -C 1404, this looks OK. Regards, furaisanjin

Nov. 3, 2009

Crashes at bizmakoto.jp

by jcid＠dillo.org

On Tue, Nov 03, 2009 at 09:19:50AM +0900, furaisanjin wrote: > Hi. > > I don't try all pages but at least there are several pages where dillo > keeps crashing. One example is > http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace > shows something like this. It doesn't crash here... :P The were a couple of patches for cleanup_at_close, please try from the repository without them (upto 1404:d4a8309dc63c), and let us know how it goes. -- Cheers Jorge.-

Nov. 3, 2009

Big changes in DPI framework and API

by jcid＠dillo.org

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.-

Nov. 3, 2009

Crashes at bizmakoto.jp

by furaisanjin＠gmail.com

Hi. I don't try all pages but at least there are several pages where dillo keeps crashing. One example is http://bizmakoto.jp/bizid/articles/0911/02/news082.html. gdb backtrace shows something like this. #0 0x28554687 in __vfprintf () from /lib/libc.so.6 #1 0x284e1fe0 in vsnprintf () from /lib/libc.so.6 #2 0x0807a16f in dStr_vsprintfa (ds=0x83cad40, format=0x80fd314 "unexpected closing tag: </%s> -- expected </%s>.\n", argp=0xbfbfe318 "$B!&(B216\017\b") at dlib.c:362 #3 0x08065f94 in DilloHtml::bugMessage (this=0x847f400, format=0x80fd314 "unexpected closing tag: </%s> -- expected </%s>.\n") at html.cc:144 #4 0x0806bed5 in Html_tag_cleanup_at_close (html=0x847f400, new_idx=8) at html.cc:1338 #5 0x0806ce4f in Html_write_raw (html=0x847f400, buf=0x861e000 "\n\n<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\" \"http://www.w3.org/TR/html4/loose.dtd\">\n<html id=\"/bizid/articles/0911/02/news082.html\">\n<head>\n<meta http-equiv=\"Content-Type\" content"..., bufsize=59935, Eof=0) at html.cc:3514 #6 0x0806dca5 in DilloHtml::write (this=0x847f400, Buf=0x0, BufSize=59935, Eof=0) at html.cc:556 #7 0x0806ddbe in Html_callback (Op=0, Client=0x8502380) at html.cc:3673 #8 0x0805b862 in Cache_process_queue (entry=0x8562980) at cache.c:1173 #9 0x0805c41f in Cache_delayed_process_queue_callback () at cache.c:1237 #10 0x080cc874 in fltk::wait () #11 0x080cca19 in fltk::run () #12 0x0804f158 in main (argc=1, argv=0xbfbfe798) at dillo.cc:353 I set YES/NO on w3c_plus_heuristics in dillorc but it didn't help. It seems that new_tag contains something valid but tag looks corrupted or not-initialized. (gdb) p new_tag $1 = {name = 0x80f8ef7 "body", Flags = 30 '\036', EndTag = 79 'O', TagLevel = 1 '\001', open = 0x8069e9c <Html_tag_open_body>, close = 0x8067db0 <Html_tag_close_body>} (gdb) p tag $2 = {name = 0x79000000 <Error reading address 0x79000000: Bad address>, Flags = 16 '\020', EndTag = 0 '\0', TagLevel = 0 '\0', open = 0, close = 0x2f} Regards, furaisanjin

Nov. 3, 2009

Big changes in DPI framework and API

by furaisanjin＠gmail.com

2009/11/3 Jorge Arellano Cid <jcid(a)dillo.org>: > ?Please try the latest repo and send feedback! > Thank you for updating and now I can compile. However I encounter the problematic pages. I will report this in another thread. Regards, furaisanjin

Nov. 3, 2009

Big changes in DPI framework and API

by corvid＠lavabit.com

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.

Nov. 2, 2009

Big changes in DPI framework and API

by jcid＠dillo.org

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.-

Nov. 2, 2009

Big changes in DPI framework and API

by corvid＠lavabit.com

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

Nov. 2, 2009

Cleanups for Html_tag_cleanup_at_close()

by onepoint＠starurchin.org

On Mon, Nov 02, 2009 at 01:51:58PM -0300, Jorge Arellano Cid wrote: > On Mon, Nov 02, 2009 at 07:14:29AM +0000, Jeremy Henty wrote: > > > Meanwhile I'd like to submit some cleanups for > > Html_tag_cleanup_at_close(), ... > > ... Sorry for the delay. FWIW, it was more me vanishing under the > DPI/DPIP work ;) No problems. I thought that was probably the reason so I delayed resubmitting for a few days. No need to apologise when Dillo keeps getting better! Regards, Jeremy Henty

Nov. 2, 2009

Big changes in DPI framework and API

by jcid＠dillo.org

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.-

Nov. 2, 2009

Big changes in DPI framework and API

by jcid＠dillo.org

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.-

Nov. 2, 2009

Cleanups for Html_tag_cleanup_at_close()

by jcid＠dillo.org

On Mon, Nov 02, 2009 at 07:14:29AM +0000, Jeremy Henty wrote: > > Congratulations on the big DPI reworking! Thanks Jeremy. It took a long effort, but now I'm confident it'll be less frustrating (and hopefully fun) to work with DPIs. At least it happened to me. After the underlying layer was ready, ironing bugs out was easy. > Meanwhile I'd like to > submit some cleanups for Html_tag_cleanup_at_close(), whose logic is > currently pretty opaque. The first is a resubmit (it seems to have > vanished into the ether when last posted). These should have no > effect on behaviour, they just make it more clear what is going on. Committed. Sorry for the delay. FWIW, it was more me vanishing under the DPI/DPIP work ;) -- Cheers Jorge.-

Nov. 2, 2009

Big changes in DPI framework and API

by corvid＠lavabit.com

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?

Nov. 2, 2009

Big changes in DPI framework and API

by jcid＠dillo.org

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.-

Nov. 2, 2009