- Dillo-dev - lists.mailman3.com

AW: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

Hey guys, I think I'm near on getting dillo2 working on blackfin uClinux. My concurrent problem is, that there are some Errors linking the project. Undefined reference ..... I'll give you my compile log: make[3]: F?r das Ziel ?all? ist nichts zu tun. make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src/IO' make[3]: Entering directory `/home/mheiser/dillo-2.1.1/src' bfin-linux-uclibc-g++ -I.. -I/home/mheiser/uClinux/uClinux/uclinux-dist/staging/usr/include/libpng12 -I/home/mheiser/fltk-2.0.x-r6841 -I/home/mheiser/uClinux/uclinux-dist/staging/usr/include/freetype2 -I/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45/X11/include -Wno-non-virtual-dtor -O2 -pipe -isystem /home/mheiser/uClinux/uclinux-dist/staging/usr/include -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -o dillo dillo.o paths.o ui.o uicmd.o bw.o cookies.o auth.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -lpng12 -L/home/mheiser/fltk-2.0.x-r6841/lib -Wl,-rpath,/home/mheiser/bfin-fltk2/lib -lfltk2_images -lpng -lfltk2_images -ljpeg -lz -lfltk2 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/nxlib/nxlib-0.45 -L/home/mheiser/uClinux/uclinux-dist/user/microwin/src/lib -L/home/mheiser/uClinux/uclinux-dist/staging/usr/lib -lX11 -lpthread -lm -lnano-X -lsupc++ -lz -liconv /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_Xutf8LookupString' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XFreeDeviceList' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_wcstombs' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_mbstowcs' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XOpenDevice' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XGetExtensionVersion' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XListInputDevices' /home/mheiser/fltk-2.0.x-r6841/lib/libfltk2.so: undefined reference to `_XSelectExtensionEvent' collect2: ld gab 1 als Ende-Status zur?ck make[3]: *** [dillo] Fehler 1 make[3]: Leaving directory `/home/mheiser/dillo-2.1.1/src' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/home/mheiser/dillo-2.1.1/src' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/mheiser/dillo-2.1.1' make: *** [all] Fehler 2 Can you give me an advice? I don't know exactly where I should begin searching for advice.... Regards Michael -----Urspr?ngliche Nachricht----- Von: corvid [mailto:corvid@lavabit.com] Gesendet: Donnerstag, 13. August 2009 02:10 An: Heiser Michael Betreff: Re: [Dillo-dev] Crosscompiling Dillo2 for uClinux on Blackfin If you get it working from that document mentioned on the uclinux forum, let us know so that I can add to Compatibility.html :) Von AVG ?berpr?ft - www.avg.de Version: 8.5.386 / Virendatenbank: 270.13.53/2299 - Ausgabedatum: 08/12/09 18:12:00

Aug. 14, 2009

Re: limit number of concurrent connections

by Johannes.Hofmann＠gmx.de

On Wed, Aug 12, 2009 at 09:54:49PM -0400, Jorge Arellano Cid wrote: > On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > > Jorge wrote: > > > [...] > > > All of these should be working now. Please report any further > > > problem you find. I'll try to make the empty cache entries removal > > > now, and then look for a way to hook the concurrent connection limit > > > without memory leaks. > > > > I don't know whether it's a problem, but I just noticed > > a difference in behaviour in that my form testcase that > > submits to localhost (there's no server listening) > > only prints "submitting multipart/form-data!" and > > I have to press stop to get > > '** WARNING **: IO_write, closing with pending data not sent' > > and see the query. > > Yes, I'm yet to look into it. > > BTW, just committed a patch for an elusive bug. Now it's > possible to browse (& populate DNS cache), disconnect, click a > link, have the abort operation on no network condition, reconnect > and click it again (and it will work!). > > The only bit missing is how to make the link return to its > normal color. a_Nav_repush() can do it easily but looks like an > overkill. Maybe Johannes has a good idea on this? Not sure why it should change it's color. It's still a visited link after all. Or does the link color have another semantics (like page is in cache) in dillo? Anyway, the real solution would need the DOM-tree which is currently not available. The DOM-tree would also be needed for :hover, :active, and for Javascript. However we could add a hack similar to the one to compute html->visited_color in Html_tag_open_body(). It assumes that there is just one visited_color in the whole page. Cheers, Johannes

Aug. 13, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Mon, Aug 10, 2009 at 12:42:05PM +0000, corvid wrote: > Jorge wrote: > > [...] > > All of these should be working now. Please report any further > > problem you find. I'll try to make the empty cache entries removal > > now, and then look for a way to hook the concurrent connection limit > > without memory leaks. > > I don't know whether it's a problem, but I just noticed > a difference in behaviour in that my form testcase that > submits to localhost (there's no server listening) > only prints "submitting multipart/form-data!" and > I have to press stop to get > '** WARNING **: IO_write, closing with pending data not sent' > and see the query. Yes, I'm yet to look into it. BTW, just committed a patch for an elusive bug. Now it's possible to browse (& populate DNS cache), disconnect, click a link, have the abort operation on no network condition, reconnect and click it again (and it will work!). The only bit missing is how to make the link return to its normal color. a_Nav_repush() can do it easily but looks like an overkill. Maybe Johannes has a good idea on this? -- Cheers Jorge.-

Aug. 13, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > > whole chain in one single step (for simplicity) and to > > > > > > define a standard way to end/abort the CCC (which I've > > > > > > given some thought). If muses decide to pay me a visit, > > > > > > I may develop a patch for this soon. :-) > > > > > > > > > > Good news. > > > > > > > > > > I already have dillo running on CCCs that build in one step > > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > > quite stable and behaves very well. Now I have to think what to > > > > > do with the gained simplicity. :) > > > > > > > > Something isn't working right in the new code for Abort. > > > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > > fails to resolve, I get a segfault. > > > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > > ** WARNING **: CCC: call on already finished chain.) > > > > > > > [...] > > > > Now after dns resolution times out, retrying in a new window/tab > > > > doesn't seem to work. > > > > > > Please try the current tip. It's not definitive, but it looks > > > like with some API polish it may be. > > > > Oh, there still is a bug after all. > > Yes, it's the same bug BTW. > > I added a new function call to the CCC API (wrapping the trick > of the previous patch) and used it in three parts of the code. > Please check the tip. > > > If I'm not connected and I try to go to a host that > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > Another SEGFAULT path was: > load dillo home > disconnect Internet > click 9years > press stop > > All of these should be working now. Please report any further > problem you find. I'll try to make the empty cache entries removal > now, and then look for a way to hook the concurrent connection limit > without memory leaks. I just got a segfault on NULL Info when going to the https url for the uclinux page: #0 0x0805cde1 in a_Chain_check (FuncStr=0x8118363 "a_Capi_ccc", Op=2, Branch=1, Dir=2, Info=0x0) at chain.c:191 #1 0x08063c72 in a_Capi_ccc (Op=2, Branch=1, Dir=2, Info=0x0, Data1=0x83e5ab0, Data2=0x0) at capi.c:522 #2 0x08063028 in Capi_conn_resume () at capi.c:172 #3 0x08063f10 in a_Capi_ccc (Op=2, Branch=1, Dir=1, Info=0x8cd2728, Data1=0x0, Data2=0x8122730) at capi.c:577 #4 0x0805cc80 in a_Chain_fcb (Op=2, Info=0x88224c0, Data1=0x0, Data2=0x8122730) at chain.c:113 #5 0x08086d95 in a_Dpi_ccc (Op=1, Branch=1, Dir=2, Info=0x88224c0, Data1=0x8b8d260, Data2=0x0) at dpi.c:625 #6 0x0805cd07 in a_Chain_bcb (Op=1, Info=0x8cd2728, Data1=0x8b8d260, Data2=0x0) at chain.c:136 #7 0x08063d6d in a_Capi_ccc (Op=1, Branch=1, Dir=2, Info=0x8cd2728, Data1=0x8936478, Data2=0x8b8d260) at capi.c:539 #8 0x08063b62 in a_Capi_dpi_send_cmd (url=0x8f1ef08, bw=0x81df6e8, cmd=0x8ee2400 "<cmd='open_url' url='https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=F…' query='GET /gf/project/uclinux-dist/fo"..., server=0x8b8d260 "proto.https", flags=1) at capi.c:482 [snip]

Aug. 13, 2009

Crosscompiling Dillo2 for uClinux on Blackfin

by heisermi＠hs-albsig.de

Hi guys, Currently I'm searching for a small footprint webbrowser to use on my blackin device. This device is driven by uClinux. The first positive I can tell you is, that I compiled fltk2 for blackfin with success. I followed the instructions on tw.myblog.yahoo.com/stevegigijoe/article<http://tw.myblog.yahoo.com/stevegigijoe/article?mid=138&prev=-1&next=137> to compile and run fltk2. My modifications can be read at https://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=F… So now I'm facing a problem with the configure script of dillo. I had to make few changes to configure.in to recognize crosscompiled Fltk2 lib. These changes went ok but when configure checks libz, then it crashes because it can't find right version of the library. So my question is, how can I tell configure to search in my uClinux directory where the library already is persistent for use with uClinux. Best Regards from Germany, Michae

Aug. 12, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > > Jorge wrote: > > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > > whole chain in one single step (for simplicity) and to > > > > > > define a standard way to end/abort the CCC (which I've > > > > > > given some thought). If muses decide to pay me a visit, > > > > > > I may develop a patch for this soon. :-) > > > > > > > > > > Good news. > > > > > > > > > > I already have dillo running on CCCs that build in one step > > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > > quite stable and behaves very well. Now I have to think what to > > > > > do with the gained simplicity. :) > > > > > > > > Something isn't working right in the new code for Abort. > > > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > > fails to resolve, I get a segfault. > > > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > > ** WARNING **: CCC: call on already finished chain.) > > > > > > > [...] > > > > Now after dns resolution times out, retrying in a new window/tab > > > > doesn't seem to work. > > > > > > Please try the current tip. It's not definitive, but it looks > > > like with some API polish it may be. > > > > Oh, there still is a bug after all. > > Yes, it's the same bug BTW. > > I added a new function call to the CCC API (wrapping the trick > of the previous patch) and used it in three parts of the code. > Please check the tip. > > > If I'm not connected and I try to go to a host that > > I have listed in /etc/hosts, then ^Q gives me a segfault. > > Another SEGFAULT path was: > load dillo home > disconnect Internet > click 9years > press stop > > All of these should be working now. Please report any further > problem you find. I'll try to make the empty cache entries removal > now, and then look for a way to hook the concurrent connection limit > without memory leaks. I don't know whether it's a problem, but I just noticed a difference in behaviour in that my form testcase that submits to localhost (there's no server listening) only prints "submitting multipart/form-data!" and I have to press stop to get '** WARNING **: IO_write, closing with pending data not sent' and see the query.

Aug. 10, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Fri, Aug 07, 2009 at 08:16:02PM +0000, corvid wrote: > Jorge wrote: > > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > > whole chain in one single step (for simplicity) and to > > > > > define a standard way to end/abort the CCC (which I've > > > > > given some thought). If muses decide to pay me a visit, > > > > > I may develop a patch for this soon. :-) > > > > > > > > Good news. > > > > > > > > I already have dillo running on CCCs that build in one step > > > > (both for HTTP and DPI), and also updated the documentation. It's > > > > quite stable and behaves very well. Now I have to think what to > > > > do with the gained simplicity. :) > > > > > > Something isn't working right in the new code for Abort. > > > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > > fails to resolve, I get a segfault. > > > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > > ** WARNING **: CCC: call on already finished chain.) > > > > > [...] > > > Now after dns resolution times out, retrying in a new window/tab > > > doesn't seem to work. > > > > Please try the current tip. It's not definitive, but it looks > > like with some API polish it may be. > > Oh, there still is a bug after all. Yes, it's the same bug BTW. I added a new function call to the CCC API (wrapping the trick of the previous patch) and used it in three parts of the code. Please check the tip. > If I'm not connected and I try to go to a host that > I have listed in /etc/hosts, then ^Q gives me a segfault. Another SEGFAULT path was: load dillo home disconnect Internet click 9years press stop All of these should be working now. Please report any further problem you find. I'll try to make the empty cache entries removal now, and then look for a way to hook the concurrent connection limit without memory leaks. -- Cheers Jorge.-

Aug. 8, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > > > As said in CCCwork.txt it would be good to build the > > > > whole chain in one single step (for simplicity) and to > > > > define a standard way to end/abort the CCC (which I've > > > > given some thought). If muses decide to pay me a visit, > > > > I may develop a patch for this soon. :-) > > > > > > Good news. > > > > > > I already have dillo running on CCCs that build in one step > > > (both for HTTP and DPI), and also updated the documentation. It's > > > quite stable and behaves very well. Now I have to think what to > > > do with the gained simplicity. :) > > > > Something isn't working right in the new code for Abort. > > > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > > fails to resolve, I get a segfault. > > > > (interestingly, if I start dillo with no args [my start url is about:blank] > > and then try to go to http://laskflsjsdfsf , ^Q just gets me > > ** WARNING **: CCC: call on already finished chain.) > > > [...] > > Now after dns resolution times out, retrying in a new window/tab > > doesn't seem to work. > > Please try the current tip. It's not definitive, but it looks > like with some API polish it may be. Oh, there still is a bug after all. If I'm not connected and I try to go to a host that I have listed in /etc/hosts, then ^Q gives me a segfault.

Aug. 7, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) > [...] > Now after dns resolution times out, retrying in a new window/tab > doesn't seem to work. Please try the current tip. It's not definitive, but it looks like with some API polish it may be. -- Cheers Jorge.-

Aug. 7, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Thu, Aug 06, 2009 at 05:20:04AM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > > > As said in CCCwork.txt it would be good to build the > > > whole chain in one single step (for simplicity) and to > > > define a standard way to end/abort the CCC (which I've > > > given some thought). If muses decide to pay me a visit, > > > I may develop a patch for this soon. :-) > > > > Good news. > > > > I already have dillo running on CCCs that build in one step > > (both for HTTP and DPI), and also updated the documentation. It's > > quite stable and behaves very well. Now I have to think what to > > do with the gained simplicity. :) > > Something isn't working right in the new code for Abort. > > If I type "dillo http://laskflsjsdfsf" and then ^Q after it > fails to resolve, I get a segfault. > > (interestingly, if I start dillo with no args [my start url is about:blank] > and then try to go to http://laskflsjsdfsf , ^Q just gets me > ** WARNING **: CCC: call on already finished chain.) Good! This will hopefully help me clean some old ad-hoc bindings. A simple way to avoid the segfault is to comment the line at http.c:497 (i.e. leave it as it was). Now, my idea is to standardize OpAbort, and have a uniform way to call it and thus avoid ad-hoc calls/non-calls that nobody understands. This may take some time or just a bit (we'll see..). The plan is to include the empty-cache-entry removal feature and improve OpStop once things are uniform. Stay tuned... -- Cheers Jorge.-

Aug. 6, 2009

Re: limit number of concurrent connections

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > > > As said in CCCwork.txt it would be good to build the > > whole chain in one single step (for simplicity) and to > > define a standard way to end/abort the CCC (which I've > > given some thought). If muses decide to pay me a visit, > > I may develop a patch for this soon. :-) > > Good news. > > I already have dillo running on CCCs that build in one step > (both for HTTP and DPI), and also updated the documentation. It's > quite stable and behaves very well. Now I have to think what to > do with the gained simplicity. :) Something isn't working right in the new code for Abort. If I type "dillo http://laskflsjsdfsf" and then ^Q after it fails to resolve, I get a segfault. (interestingly, if I start dillo with no args [my start url is about:blank] and then try to go to http://laskflsjsdfsf , ^Q just gets me ** WARNING **: CCC: call on already finished chain.)

Aug. 6, 2009

Re: patch: media_type pref

by jcid＠dillo.org

On Wed, Aug 05, 2009 at 03:07:54AM +0000, corvid wrote: > I wrote, some months ago: > > Jorge wrote: > > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > > It makes more sense to have a pref that the user can > > > > control than for us to guess what they might like > > > > based on screen size or whatever, I think. > > > > > > I hesitate on this. For instance: if media_type is defined to > > > "handheld" and there's no such remote CSS, at least it should > > > fallback to "screen". > > > > If there is a handheld style sheet available and dillo is running > > on a handheld, it would be a shame not to use it. I'm hoping that > > the page author would have the sense to supply something for type "all". > > > > > Maybe it's more practical to provide custom stylesheets (as the > > > current "style.css". e.g. small_screen.css, print.css) and to > > > allow switching among them from the "Tools" menu. > > > > > > What do you think? > > > > I think someone using handheld would want to use both the page > > author's handheld-specific code and a user style suitable for > > their device. > > > > I'll send this to the list in case anyone with experience using > > such devices with the web has opinions to share. > > I never was able to talk Jorge into this one, but I > might as well make the code available so that people > with handhelds can have it if they wish. I don't have a handheld and seldom use one. Despite my efforts, my attempts to try to give good advice on it in the past have proved clumsy and of no much use, so I prefer to follow the advice from the ones using them all the time (e.g. Andreas Kemnade). -- Cheers Jorge.-

Aug. 5, 2009

Re: patch: media_type pref

by corvid＠lavabit.com

I wrote, some months ago: > Jorge wrote: > > On Mon, Feb 16, 2009 at 05:37:36AM +0000, corvid wrote: > > > It makes more sense to have a pref that the user can > > > control than for us to guess what they might like > > > based on screen size or whatever, I think. > > > > I hesitate on this. For instance: if media_type is defined to > > "handheld" and there's no such remote CSS, at least it should > > fallback to "screen". > > If there is a handheld style sheet available and dillo is running > on a handheld, it would be a shame not to use it. I'm hoping that > the page author would have the sense to supply something for type "all". > > > Maybe it's more practical to provide custom stylesheets (as the > > current "style.css". e.g. small_screen.css, print.css) and to > > allow switching among them from the "Tools" menu. > > > > What do you think? > > I think someone using handheld would want to use both the page > author's handheld-specific code and a user style suitable for > their device. > > I'll send this to the list in case anyone with experience using > such devices with the web has opinions to share. I never was able to talk Jorge into this one, but I might as well make the code available so that people with handhelds can have it if they wish.

Aug. 5, 2009

Re: limit number of concurrent connections

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 01:40:17PM -0400, Jorge Arellano Cid wrote: > > As said in CCCwork.txt it would be good to build the > whole chain in one single step (for simplicity) and to > define a standard way to end/abort the CCC (which I've > given some thought). If muses decide to pay me a visit, > I may develop a patch for this soon. :-) Good news. I already have dillo running on CCCs that build in one step (both for HTTP and DPI), and also updated the documentation. It's quite stable and behaves very well. Now I have to think what to do with the gained simplicity. :) Bottom line: don't waste much time with the CCC and its docs in current repo, most probably they will be replaced soon. -- Cheers Jorge.-

Aug. 5, 2009

Re: dillo bug 916

by corvid＠lavabit.com

Jorge wrote: > On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > > Jorge wrote: > > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > > Scott wrote: > > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > > > Scott had reported: > > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > > of letting the window manager do its job. > > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > > Apps should not try to do their own window management." > > > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > > that a partially hidden Dillo window raises upon clicking it. > > > > > I hesitate because Firefox and even terminals here behave that > > > > > way. Please explain. > > > > > > > > Other windows don't for me. Dillo does if it's > > > > a new window/new tab or if I'm clicking below the bottom > > > > of the text when the page is very short. > > > > I imagine your WM must be set to do it... > > > > > > Oh, now I see it (with TWM). > > > Please commit. > > > > Yes, but we should mark it as a workaround for an FLTK issue and > > report it to FLTK. > > Exactly! > > (even though I have more hope for their 1.3 branch). Judging from the comment I mentioned: > fltk's Window::handle() has: > #if USE_X11 > case PUSH: > // Unused clicks should raise the window. Windows unfortunatly > // raises the window on *all* clicks so we don't bother except on X. > if (shown()) XMapRaised(xdisplay, i->xid); > #endif they seem to view it as correct, although it seems strangely arbitrary to me.

Aug. 3, 2009

Re: dillo bug 916

by jcid＠dillo.org

On Mon, Aug 03, 2009 at 06:20:50PM +0200, Johannes Hofmann wrote: > On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > > Jorge wrote: > > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > > Scott wrote: > > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > > > Scott had reported: > > > > > "Dillo sometimes raises its window when clicked, instead > > > > > of letting the window manager do its job. > > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > > Apps should not try to do their own window management." > > > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > > that a partially hidden Dillo window raises upon clicking it. > > > > I hesitate because Firefox and even terminals here behave that > > > > way. Please explain. > > > > > > Other windows don't for me. Dillo does if it's > > > a new window/new tab or if I'm clicking below the bottom > > > of the text when the page is very short. > > > I imagine your WM must be set to do it... > > > > Oh, now I see it (with TWM). > > Please commit. > > Yes, but we should mark it as a workaround for an FLTK issue and > report it to FLTK. Exactly! (even though I have more hope for their 1.3 branch). -- Cheers Jorge.-

Aug. 3, 2009

Re: dillo bug 916

by Johannes.Hofmann＠gmx.de

On Mon, Aug 03, 2009 at 12:17:35PM -0400, Jorge Arellano Cid wrote: > On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > > Jorge wrote: > > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > > Scott wrote: > > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > > > Scott had reported: > > > > "Dillo sometimes raises its window when clicked, instead > > > > of letting the window manager do its job. > > > > Usually if I have a window partially hidden, I don't want it raised... > > > > Apps should not try to do their own window management." > > > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > > that a partially hidden Dillo window raises upon clicking it. > > > I hesitate because Firefox and even terminals here behave that > > > way. Please explain. > > > > Other windows don't for me. Dillo does if it's > > a new window/new tab or if I'm clicking below the bottom > > of the text when the page is very short. > > I imagine your WM must be set to do it... > > Oh, now I see it (with TWM). > Please commit. Yes, but we should mark it as a workaround for an FLTK issue and report it to FLTK.

Aug. 3, 2009

Re: dillo bug 916

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 07:27:54PM +0000, corvid wrote: > Jorge wrote: > > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > > Scott wrote: > > > > As far as I can tell, it works correctly with the patch applied. :) > > > > > > Scott had reported: > > > "Dillo sometimes raises its window when clicked, instead > > > of letting the window manager do its job. > > > Usually if I have a window partially hidden, I don't want it raised... > > > Apps should not try to do their own window management." > > > > Sorry, I don't get the idea of the bug. IIUC the problem is > > that a partially hidden Dillo window raises upon clicking it. > > I hesitate because Firefox and even terminals here behave that > > way. Please explain. > > Other windows don't for me. Dillo does if it's > a new window/new tab or if I'm clicking below the bottom > of the text when the page is very short. > I imagine your WM must be set to do it... Oh, now I see it (with TWM). Please commit. -- Cheers Jorge.-

Aug. 3, 2009

Re: dillo bug 916

by corvid＠lavabit.com

Jorge wrote: > On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > > Scott wrote: > > > As far as I can tell, it works correctly with the patch applied. :) > > > > Scott had reported: > > "Dillo sometimes raises its window when clicked, instead > > of letting the window manager do its job. > > Usually if I have a window partially hidden, I don't want it raised... > > Apps should not try to do their own window management." > > Sorry, I don't get the idea of the bug. IIUC the problem is > that a partially hidden Dillo window raises upon clicking it. > I hesitate because Firefox and even terminals here behave that > way. Please explain. Other windows don't for me. Dillo does if it's a new window/new tab or if I'm clicking below the bottom of the text when the page is very short. I imagine your WM must be set to do it...

Aug. 2, 2009

Re: dillo bug 916

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 05:14:47PM +0000, corvid wrote: > Scott wrote: > > As far as I can tell, it works correctly with the patch applied. :) > > Scott had reported: > "Dillo sometimes raises its window when clicked, instead > of letting the window manager do its job. > Usually if I have a window partially hidden, I don't want it raised... > Apps should not try to do their own window management." Sorry, I don't get the idea of the bug. IIUC the problem is that a partially hidden Dillo window raises upon clicking it. I hesitate because Firefox and even terminals here behave that way. Please explain. -- Cheers Jorge.-

Aug. 2, 2009

limit number of concurrent connections

by jcid＠dillo.org

Hi, Here's a prototype patch that does the work. It's not yet optimized nor polished nor throughly tested, and it leaks Web structures, but it illustrates very well the idea, and finishing it shouldn't be hard. As said in CCCwork.txt it would be good to build the whole chain in one single step (for simplicity) and to define a standard way to end/abort the CCC (which I've given some thought). If muses decide to pay me a visit, I may develop a patch for this soon. :-) -- Cheers Jorge.-

Aug. 2, 2009

Re: dillo bug 916

by corvid＠lavabit.com

Scott wrote: > As far as I can tell, it works correctly with the patch applied. :) Scott had reported: "Dillo sometimes raises its window when clicked, instead of letting the window manager do its job. Usually if I have a window partially hidden, I don't want it raised... Apps should not try to do their own window management." fltk's Window::handle() has: #if USE_X11 case PUSH: // Unused clicks should raise the window. Windows unfortunatly // raises the window on *all* clicks so we don't bother except on X. if (shown()) XMapRaised(xdisplay, i->xid); #endif Aforementioned patch attached.

Aug. 2, 2009

experimental patch: Re: dillo2 wrapping Chinese

by jcid＠dillo.org

On Sun, Aug 02, 2009 at 01:04:26AM +0000, corvid wrote: > I made yet another version of this patch the other day, > and furaisanjin was kind enough to run on it a bit and > ensure it's doing what we want. > > With the previous version, compiling without optimization, > gprof showed 3-4% loss of speed on a page that's mostly > English text. > > - I removed the strdup/free from the common case. > - For nonideographic, it goes character by character instead of > checking every byte. This should help for, e.g., Russian, > but means some 'unnecessary' length-checking in the > mostly-ASCII case. > > And gprof suggested the slowdown might be 3% now, although > at this point, unless someone is paying you to perform a > lot of careful, drudgery-filled runs, it gets hard to pick the > signal out of the noise when examining the time spent in relevant > functions. I wouldn't go with complex code for 1% gain. > I tried adding in some code to bypass the ideographic call for > ASCII, but 1) it made the code a little messy 2) it looked like > it might be saving a few tenths of a percent 3) the compiler > might perform optimizations under certain circumstances making > my efforts unnecessary or counterproductive. > I could definitely be talked into this one, though. Please leave the messy part out. > I tried adding an addText() with a length argument and thought > it might help by saving me the trouble of writing NULL bytes into > the strings and saving the trouble of some strlen()ning in dw. > I couldn't see any difference in speed, although it did make > things cleaner and I would want to add it in eventually if this > all makes it into the repository. Considering it makes things cleaner I'm for it. > There will be a duplicated ideographic() test, for instance, if > a word starts with digits and ends with some Japanese characters. > 1) uncommon 2) complexity Not worth the trouble of. > This patch is really two patches because it also handles the > case where whitespace numeric character references are > inside a word, but I wanted to see the effects of both > and they are each an excuse for the overhead of the loop. > I'd split it into two pieces if committing it. OK. (i.e. please consider the above comments, split and commit). BTW: I'm working on the limit concurrent connections patch prototype. -- Cheers Jorge.-

Aug. 2, 2009

experimental patch: Re: dillo2 wrapping Chinese

by corvid＠lavabit.com

I made yet another version of this patch the other day, and furaisanjin was kind enough to run on it a bit and ensure it's doing what we want. With the previous version, compiling without optimization, gprof showed 3-4% loss of speed on a page that's mostly English text. - I removed the strdup/free from the common case. - For nonideographic, it goes character by character instead of checking every byte. This should help for, e.g., Russian, but means some 'unnecessary' length-checking in the mostly-ASCII case. And gprof suggested the slowdown might be 3% now, although at this point, unless someone is paying you to perform a lot of careful, drudgery-filled runs, it gets hard to pick the signal out of the noise when examining the time spent in relevant functions. I tried adding in some code to bypass the ideographic call for ASCII, but 1) it made the code a little messy 2) it looked like it might be saving a few tenths of a percent 3) the compiler might perform optimizations under certain circumstances making my efforts unnecessary or counterproductive. I could definitely be talked into this one, though. I tried adding an addText() with a length argument and thought it might help by saving me the trouble of writing NULL bytes into the strings and saving the trouble of some strlen()ning in dw. I couldn't see any difference in speed, although it did make things cleaner and I would want to add it in eventually if this all makes it into the repository. There will be a duplicated ideographic() test, for instance, if a word starts with digits and ends with some Japanese characters. 1) uncommon 2) complexity This patch is really two patches because it also handles the case where whitespace numeric character references are inside a word, but I wanted to see the effects of both and they are each an excuse for the overhead of the loop. I'd split it into two pieces if committing it.

Aug. 2, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote: > > Jorge wrote: > > > On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote: > > > > --- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > I don't see any mention of a limit on concurrent connections > > > > that was proposed earlier, and as far as I know it hasn't been > > > > implemented. In addition to the reasons given earlier, it is very > > > > frustrating to have to implement your own traffic-shaping just to > > > > avoid being blocked by a rate/connection-limiting firewall, or to > > > > avoid being blocklisted by a site you had hoped to visit. I'd > > > > hate to see dillo gain a reputation as a problematic UserAgent, > > > > and perhaps be blocked by some heavy-handed administrators. > > > > If I had magical make-Jorge-do-my-bidding powers, this would be on the > > top of my list. > > Interesting... > > I'll give it a look, try to come up with raw patch and > send it to you for polish. Would you? I can try. It would be nice if we could have Keep-Alive. (Conceivably pipelining someday, but there might be too many annoying failure modes to recover from.) > > > * Document CCC, dlib and dillo in doxygen format. > > > > The situation seems to me as follows: > > pre-doxygen: easy-to-read code, useless documentation > > post-doxygen: hard-to-read code, useless documentation > > Oh, sounds harsh! > > For me Dw docs have been a bless. Without them I would not be > able to rewrite the table-formating algorithms. The conceptual dw docs (doc/*.doc) have helped me understand some things at times (but not due to their doxygenicity), but the doxygen stuff in the source makes it harder for me to read comments. > Non-dw documents under doc/ are outdated and I have to agree > they are of little use. I'll try to write one about CCC that will > hopefully help you with the limit on concurrent connections. Yeah, I should dig through some of doc/*.txt and update some things in the areas I'm familiar with.

July 31, 2009

Planning

by jcid＠dillo.org

On Fri, Jul 31, 2009 at 07:40:20AM +0200, Johannes Hofmann wrote: > On Thu, Jul 30, 2009 at 07:55:43PM -0400, Jorge Arellano Cid wrote: > > On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote: > > > Jorge wrote: > > > > On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote: > > > > > --- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > I don't see any mention of a limit on concurrent connections > > > > > that was proposed earlier, and as far as I know it hasn't been > > > > > implemented. In addition to the reasons given earlier, it is very > > > > > frustrating to have to implement your own traffic-shaping just to > > > > > avoid being blocked by a rate/connection-limiting firewall, or to > > > > > avoid being blocklisted by a site you had hoped to visit. I'd > > > > > hate to see dillo gain a reputation as a problematic UserAgent, > > > > > and perhaps be blocked by some heavy-handed administrators. > > > > > > If I had magical make-Jorge-do-my-bidding powers, this would be on the > > > top of my list. > > > > Interesting... > > > > I'll give it a look, try to come up with raw patch and > > send it to you for polish. Would you? > > > > > > * Document CCC, dlib and dillo in doxygen format. > > > > > > The situation seems to me as follows: > > > pre-doxygen: easy-to-read code, useless documentation > > > post-doxygen: hard-to-read code, useless documentation > > > > Oh, sounds harsh! > > Yes that's a bit harsh, but I think corvid is right to some degree. > doxygen style comments that describe every method and their > parameters are not needed in dillo. It is no library after all. > What is really important is an up-to-date overview document > that explains the concepts. The rest can mostly be figured out from > the code. > > > > > For me Dw docs have been a bless. Without them I would not be > > able to rewrite the table-formating algorithms. > > Yes. the dw/* documentation is good because it describes the > concepts. But if I want to find out what some method does, I now > look at the code, not the docs. FWIW, when I said "doxygen format" I meant something similar to dw. As you remark, the concepts are the important part. The functions are well commented in the code. I don't know whether there's a fixed doxygen standard, and surely didn't mean it. Sorry for the confusion. -- Cheers Jorge.-

July 31, 2009

Planning

by Johannes.Hofmann＠gmx.de

On Thu, Jul 30, 2009 at 07:55:43PM -0400, Jorge Arellano Cid wrote: > On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote: > > Jorge wrote: > > > On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote: > > > > --- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > I don't see any mention of a limit on concurrent connections > > > > that was proposed earlier, and as far as I know it hasn't been > > > > implemented. In addition to the reasons given earlier, it is very > > > > frustrating to have to implement your own traffic-shaping just to > > > > avoid being blocked by a rate/connection-limiting firewall, or to > > > > avoid being blocklisted by a site you had hoped to visit. I'd > > > > hate to see dillo gain a reputation as a problematic UserAgent, > > > > and perhaps be blocked by some heavy-handed administrators. > > > > If I had magical make-Jorge-do-my-bidding powers, this would be on the > > top of my list. > > Interesting... > > I'll give it a look, try to come up with raw patch and > send it to you for polish. Would you? > > > > * Document CCC, dlib and dillo in doxygen format. > > > > The situation seems to me as follows: > > pre-doxygen: easy-to-read code, useless documentation > > post-doxygen: hard-to-read code, useless documentation > > Oh, sounds harsh! Yes that's a bit harsh, but I think corvid is right to some degree. doxygen style comments that describe every method and their parameters are not needed in dillo. It is no library after all. What is really important is an up-to-date overview document that explains the concepts. The rest can mostly be figured out from the code. > > For me Dw docs have been a bless. Without them I would not be > able to rewrite the table-formating algorithms. Yes. the dw/* documentation is good because it describes the concepts. But if I want to find out what some method does, I now look at the code, not the docs. > > Non-dw documents under doc/ are outdated and I have to agree > they are of little use. I'll try to write one about CCC that will > hopefully help you with the limit on concurrent connections. That would be great. Cheers, Johannes

July 31, 2009

Planning

by jcid＠dillo.org

On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote: > Jorge wrote: > > On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote: > > > --- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > I don't see any mention of a limit on concurrent connections > > > that was proposed earlier, and as far as I know it hasn't been > > > implemented. In addition to the reasons given earlier, it is very > > > frustrating to have to implement your own traffic-shaping just to > > > avoid being blocked by a rate/connection-limiting firewall, or to > > > avoid being blocklisted by a site you had hoped to visit. I'd > > > hate to see dillo gain a reputation as a problematic UserAgent, > > > and perhaps be blocked by some heavy-handed administrators. > > If I had magical make-Jorge-do-my-bidding powers, this would be on the > top of my list. Interesting... I'll give it a look, try to come up with raw patch and send it to you for polish. Would you? > > * Document CCC, dlib and dillo in doxygen format. > > The situation seems to me as follows: > pre-doxygen: easy-to-read code, useless documentation > post-doxygen: hard-to-read code, useless documentation Oh, sounds harsh! For me Dw docs have been a bless. Without them I would not be able to rewrite the table-formating algorithms. Non-dw documents under doc/ are outdated and I have to agree they are of little use. I'll try to write one about CCC that will hopefully help you with the limit on concurrent connections. -- Cheers Jorge.-

July 31, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote: > > --- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > From: Jorge Arellano Cid <jcid(a)dillo.org> > > > Subject: [Dillo-dev] Planning > > > To: "Dillo mailing list" <dillo-dev(a)dillo.org> > > > Date: Friday, July 24, 2009, 11:33 AM > > > Hi, > > > > > > ? Here? are? some? pending? issues > > > which I've partially sorted by > > > priority (at least the top half). Please add the missing > > > ones and > > > let's try to finish sorting it, with a view to planify our > > > work. > > > > > * Add blocker (this also has to do with privacy). > > > ???A? full? RE-based? > > > one? may? have? significant? overhead > > > (test > > > required),? but? simple string-matching may do > > > most of the trick. > > > I've? also? thought? for? a? > > > long? time? that? a "don't load from > > > other? sites"? preference? may? help a > > > lot. The whole topic needs > > > some thought but it's not hard to implement. > > > ???e.g. doubleclick. > > > > Or you could just point users to privoxy, junkbuster, WWWOFFLE, and/or polipo. Perhaps so. I would like some way to make it so that dillo would always ask me before following redirections, but maybe I should just argue for a pref for that specific thing rather than going for a whole general adblockerplus deal. > > I don't see any mention of a limit on concurrent connections > > that was proposed earlier, and as far as I know it hasn't been > > implemented. In addition to the reasons given earlier, it is very > > frustrating to have to implement your own traffic-shaping just to > > avoid being blocked by a rate/connection-limiting firewall, or to > > avoid being blocklisted by a site you had hoped to visit. I'd > > hate to see dillo gain a reputation as a problematic UserAgent, > > and perhaps be blocked by some heavy-handed administrators. If I had magical make-Jorge-do-my-bidding powers, this would be on the top of my list. > * Document CCC, dlib and dillo in doxygen format. The situation seems to me as follows: pre-doxygen: easy-to-read code, useless documentation post-doxygen: hard-to-read code, useless documentation > Please Johannes or corvid, sort the titles of the items we have > so far in this thread so we can sort them and do our planning. I guess I'll paw through it and stuff everything into Plans.html.

July 30, 2009

Planning

by jcid＠dillo.org

On Wed, Jul 29, 2009 at 02:14:30PM -0400, Jorge Arellano Cid wrote: > [...] > That was an incomplete list to start sorting priorities. BTW, we haven't even mentioned the javascript prototype, which is certainly a major topic. This mainly because it needs a lot of thought, a decision on whether to do it through dpip, etc. We'd be in a better shape to decide on scripting once the floats are in place, and some of the related topics are solved. -- Cheers Jorge.-

July 29, 2009

Planning

by jcid＠dillo.org

On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote: > > > > --- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > From: Jorge Arellano Cid <jcid(a)dillo.org> > > Subject: [Dillo-dev] Planning > > To: "Dillo mailing list" <dillo-dev(a)dillo.org> > > Date: Friday, July 24, 2009, 11:33 AM > > Hi, > > > > ? Here? are? some? pending? issues > > which I've partially sorted by > > priority (at least the top half). Please add the missing > > ones and > > let's try to finish sorting it, with a view to planify our > > work. > > > * Add blocker (this also has to do with privacy). > > ???A? full? RE-based? > > one? may? have? significant? overhead > > (test > > required),? but? simple string-matching may do > > most of the trick. > > I've? also? thought? for? a? > > long? time? that? a "don't load from > > other? sites"? preference? may? help a > > lot. The whole topic needs > > some thought but it's not hard to implement. > > ???e.g. doubleclick. > > Or you could just point users to privoxy, junkbuster, WWWOFFLE, and/or polipo. > > I don't see any mention of a limit on concurrent connections > that was proposed earlier, and as far as I know it hasn't been > implemented. In addition to the reasons given earlier, it is very > frustrating to have to implement your own traffic-shaping just to > avoid being blocked by a rate/connection-limiting firewall, or to > avoid being blocklisted by a site you had hoped to visit. I'd > hate to see dillo gain a reputation as a problematic UserAgent, > and perhaps be blocked by some heavy-handed administrators. That was an incomplete list to start sorting priorities. * Limit number of concurrent connections. is certainly a valid item, also as is * Document CCC, dlib and dillo in doxygen format. Please Johannes or corvid, sort the titles of the items we have so far in this thread so we can sort them and do our planning. -- Cheers Jorge.-

July 29, 2009

Re: dillo crash at dlib/dlib.c:173

by stevegigijoe＠yahoo.com.tw

Hello guys I'm Sorry. Corvid is right. I must mass up something :p Steve ______________________________________________________________________________________________________ ¥I¶O€~®e¶qµL€W¡HYahoo!©_Œ¯¹q€l«Hœc2.0§K¶Oµ¹§A¡A«H¥ó¥Ã»·€£¥²§R¡I http://tw.mg0.mail.yahoo.com/dc/landing

July 29, 2009

Planning

by bf2006a＠yahoo.com

--- On Fri, 7/24/09, Jorge Arellano Cid <jcid(a)dillo.org> wrote: > From: Jorge Arellano Cid <jcid(a)dillo.org> > Subject: [Dillo-dev] Planning > To: "Dillo mailing list" <dillo-dev(a)dillo.org> > Date: Friday, July 24, 2009, 11:33 AM > Hi, > > ? Here? are? some? pending? issues > which I've partially sorted by > priority (at least the top half). Please add the missing > ones and > let's try to finish sorting it, with a view to planify our > work. > * Add blocker (this also has to do with privacy). > ???A? full? RE-based? > one? may? have? significant? overhead > (test > required),? but? simple string-matching may do > most of the trick. > I've? also? thought? for? a? > long? time? that? a "don't load from > other? sites"? preference? may? help a > lot. The whole topic needs > some thought but it's not hard to implement. > ???e.g. doubleclick. Or you could just point users to privoxy, junkbuster, WWWOFFLE, and/or polipo. I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators. b.

July 29, 2009

dillo crash at dlib/dlib.c:173

by Johannes.Hofmann＠gmx.de

On Tue, Jul 28, 2009 at 07:41:41PM +0800, ?? ? wrote: > Hello all > > After update, the dillo crash while opening http://www.google.com.tw > on dlib/dlib.c:173 > > The array haystack is null and unchecked cause the problem... Can you please type "bt" in gdb to get a backtrace and post the output? Are you running plain dillo without additional patches? Cheers, Johannes > > Log as below > > gigijoe@user-desktop:~/dillo2$ gdb src/dillo > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > (gdb) r > Starting program: /home/gigijoe/dillo2/src/dillo > [Thread debugging using libthread_db enabled] > paths: Cannot open file '/home/gigijoe/.dillo/keysrc' > paths: Cannot open file '/usr/local/etc/dillo/keysrc' > paths: Using internal defaults... > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Nav_open_url: new url='http://www.google.com.tw' > [New Thread 0xb795b8e0 (LWP 11430)] > [New Thread 0xb782bb90 (LWP 11433)] > Dns_server [0]: www.google.com.tw is 74.125.19.105 74.125.19.106 74.125.19.99 74.125.19.104 74.125.19.103 74.125.19.147 > [Thread 0xb782bb90 (LWP 11433) exited] > Connecting to 74.125.19.105 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb795b8e0 (LWP 11430)] > 0x0807ee7c in dStristr (haystack=0x0, needle=0x810c13f "javascript") at dlib.c:173 > 173 for (i = 0, j = 0; haystack[i] && needle[j]; ++i) > Current language: auto; currently c > (gdb) q > The program is running. Exit anyway? (y or n) y > > > Steve > > > ______________________________________________________________________________________________________ > ?????????Yahoo!??????2.0????????????? http://tw.mg0.mail.yahoo.com/dc/landing > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

July 29, 2009

dillo crash at dlib/dlib.c:173

by corvid＠lavabit.com

?? wrote: > After update, the dillo crash while opening http://www.google.com.tw > on dlib/dlib.c:173 > > The array haystack is null and unchecked cause the problem... > > Log as below > > gigijoe@user-desktop:~/dillo2$ gdb src/dillo > GNU gdb 6.8-debian > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "i486-linux-gnu"... > (gdb) r > Starting program: /home/gigijoe/dillo2/src/dillo > [Thread debugging using libthread_db enabled] > paths: Cannot open file '/home/gigijoe/.dillo/keysrc' > paths: Cannot open file '/usr/local/etc/dillo/keysrc' > paths: Using internal defaults... > dillo_dns_init: Here we go! (threaded) > Disabling cookies. > Nav_open_url: new url='http://www.google.com.tw' > [New Thread 0xb795b8e0 (LWP 11430)] > [New Thread 0xb782bb90 (LWP 11433)] > Dns_server [0]: www.google.com.tw is 74.125.19.105 74.125.19.106 74.125.19.99 74.125.19.104 74.125.19.103 74.125.19.147 > [Thread 0xb782bb90 (LWP 11433) exited] > Connecting to 74.125.19.105 > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0xb795b8e0 (LWP 11430)] > 0x0807ee7c in dStristr (haystack=0x0, needle=0x810c13f "javascript") at dlib.c:173 > 173 for (i = 0, j = 0; haystack[i] && needle[j]; ++i) > Current language: auto; currently c > (gdb) q > The program is running. Exit anyway? (y or n) y I believe it's breaking in your javascript patch. We usually write if (attrbuf) { .. } But regardless, dStristr() should have checks for NULL. I'll add them in a moment.

July 28, 2009

dillo crash at dlib/dlib.c:173

by stevegigijoe＠yahoo.com.tw

Hello all After update, the dillo crash while opening http://www.google.com.tw on dlib/dlib.c:173 The array haystack is null and unchecked cause the problem... Log as below gigijoe@user-desktop:~/dillo2$ gdb src/dillo GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-linux-gnu"... (gdb) r Starting program: /home/gigijoe/dillo2/src/dillo [Thread debugging using libthread_db enabled] paths: Cannot open file '/home/gigijoe/.dillo/keysrc' paths: Cannot open file '/usr/local/etc/dillo/keysrc' paths: Using internal defaults... dillo_dns_init: Here we go! (threaded) Disabling cookies. Nav_open_url: new url='http://www.google.com.tw' [New Thread 0xb795b8e0 (LWP 11430)] [New Thread 0xb782bb90 (LWP 11433)] Dns_server [0]: www.google.com.tw is 74.125.19.105 74.125.19.106 74.125.19.99 74.125.19.104 74.125.19.103 74.125.19.147 [Thread 0xb782bb90 (LWP 11433) exited] Connecting to 74.125.19.105 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb795b8e0 (LWP 11430)] 0x0807ee7c in dStristr (haystack=0x0, needle=0x810c13f "javascript") at dlib.c:173 173 for (i = 0, j = 0; haystack[i] && needle[j]; ++i) Current language: auto; currently c (gdb) q The program is running. Exit anyway? (y or n) y Steve ______________________________________________________________________________________________________ ¥I¶O€~®e¶qµL€W¡HYahoo!©_Œ¯¹q€l«Hœc2.0§K¶Oµ¹§A¡A«H¥ó¥Ã»·€£¥²§R¡I http://tw.mg0.mail.yahoo.com/dc/landing

July 28, 2009

dIsspace

by jcid＠dillo.org

On Mon, Jul 27, 2009 at 02:16:53PM +0000, corvid wrote: > Jorge wrote: > > When porting dillo to minix3 I had this problem. > > So it works? I don't see it in Compatibility.html Minix3 doesn't have Unix sockets nor pthreads yet, so all the DPI framework is not of the party. The main program (dillo itself) works very well on rendering and UI (flawless in my local testing). I don't have a network card supported by minix so they're testing how it works on the real Web. Once I get an official OK, it surely deserves a mention in Compatibility.html. -- Cheers Jorge.-

July 27, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > On Sun, Jul 26, 2009 at 05:21:07PM +0000, corvid wrote: > > Jorge wrote: > > > * Jump to #anchor doesn't work correctly. > > > It looks like a timing issue, but the idle-call API needs a > > > review as a whole. > > > > Speaking of idle, is there a reasonable way to make it so that > > the importance goes > > 1) network->cache > > 2) UI responsive > > 3) cache->textblock > > Given the way the code and network engine are designed, > there're much simpler ways to achieve UI responsiveness. > > For instance: AFAIR, currently the redraw requests are queued > and idled. When the idle queue is finally processed all the > pending redraws are issued one after another. Considering that > rendering is a resource-heavy operation, if the drawing code > could cancel the previous requests and only issue the really > needed ones this alone could reduce CPU usage by a significative > factor, and make the whole browser feel much faster. Ohh... I thought it was doing this already.

July 27, 2009

dIsspace

by joerg.sonnenberger＠web.de

On Mon, Jul 27, 2009 at 10:02:28AM -0400, Jorge Arellano Cid wrote: > On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote: > > The results for C++ are not different as far as ctype(3) are concerned. > > It looks like it's the compiler the one that decides [1]. > When porting dillo to minix3 I had this problem. Yes, what I said is that it is irrelevant whether you have C or C++ for this. The argument for ctype(3) macros must always be either EOF or 0..255. At least on NetBSD you will also get a compiler warning when using (signed) char. Joerg

July 27, 2009

dIsspace

by corvid＠lavabit.com

Jorge wrote: > When porting dillo to minix3 I had this problem. So it works? I don't see it in Compatibility.html

July 27, 2009

Planning

by jcid＠dillo.org

On Sun, Jul 26, 2009 at 05:21:07PM +0000, corvid wrote: > Jorge wrote: > > * Jump to #anchor doesn't work correctly. > > It looks like a timing issue, but the idle-call API needs a > > review as a whole. > > Speaking of idle, is there a reasonable way to make it so that > the importance goes > 1) network->cache > 2) UI responsive > 3) cache->textblock Given the way the code and network engine are designed, there're much simpler ways to achieve UI responsiveness. For instance: AFAIR, currently the redraw requests are queued and idled. When the idle queue is finally processed all the pending redraws are issued one after another. Considering that rendering is a resource-heavy operation, if the drawing code could cancel the previous requests and only issue the really needed ones this alone could reduce CPU usage by a significative factor, and make the whole browser feel much faster. > I know we have "throttle rendering" listed in the plans, but I seem to > recall that being a KB/s sort of thing. There're several ways to approach this problem... -- Cheers Jorge.-

July 27, 2009

dIsspace

by jcid＠dillo.org

On Sun, Jul 26, 2009 at 06:53:11PM +0200, Joerg Sonnenberger wrote: > On Sun, Jul 26, 2009 at 12:27:05PM -0400, Jorge Arellano Cid wrote: > > On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote: > > > When are we supposed to use isspace() > > > and when are we supposed to use dIsspace()? > > > It appears that one is now used in the C++ code > > > and the other in the C code, but I don't know > > > the reason for this distinction. > > > > C and C++ have different conventions for data types. > > dIsspace() avoids problems in C code on platforms with > > a signed char default. C++ is inmune. > > The results for C++ are not different as far as ctype(3) are concerned. It looks like it's the compiler the one that decides [1]. When porting dillo to minix3 I had this problem. > > OTOH, it looks weird to have both calls in the code. I'd > > happily use dIsspace() all over if the compiler optimizes the > > extra cast away. > > The cast is a nop on every architecture that matters. That is not the > answer you might get from comp.lang.c though :) Good, then we can use dIsspace all over the place. [1] http://home.att.net/~jackklein/c/inttypes.html -- Cheers Jorge.-

July 27, 2009

Planning

by jcid＠dillo.org

On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote: > Hi, > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > Hi, > > > > Here are some pending issues which I've partially sorted by > > priority (at least the top half). Please add the missing ones and > > let's try to finish sorting it, with a view to planify our work. > > > > > > * Make DIV-based pages render correctly. > > This is the most visible rendering fault in Dillo. The > > textblock doesn't have a way to handle it (not implemented). > > IIRC I'm willing to dig into it and Johannes will help. > > e.g. http://www.advogato.org/faq.html > > With DIV-based pages you mean floats as in > http://www.w3.org/TR/CSS21/visuren.html#floats? Exactly. > Yes, this is the most obvious rendering problem atm. It looks complex, and it will take some time to study before coming with implementation ideas. > > * Add blocker (this also has to do with privacy). > > A full RE-based one may have significant overhead (test > > required), but simple string-matching may do most of the trick. > > I've also thought for a long time that a "don't load from > > other sites" preference may help a lot. The whole topic needs > > some thought but it's not hard to implement. > > e.g. doubleclick. > > > > * Handle negative values in CSS. e.g. wikipedia. > > Actually it's dw/* that needs to be adapted to handle negative > margins. This might be related to the floats stuff. It looks like. Maybe they can be implemented separately. > * Add clipping to the fltk drawing code, so that e.g. margins of huge > boxes don't cause X11 coordinate overflows. > E.g. on http://alpen-panoramen.de/newcomments.php > I will try to fix that. > Similar issues occur with very long lines in plain.cc. At what priority? -- Cheers Jorge.-

July 26, 2009

Planning

by corvid＠lavabit.com

Jorge wrote: > * Jump to #anchor doesn't work correctly. > It looks like a timing issue, but the idle-call API needs a > review as a whole. Speaking of idle, is there a reasonable way to make it so that the importance goes 1) network->cache 2) UI responsive 3) cache->textblock I know we have "throttle rendering" listed in the plans, but I seem to recall that being a KB/s sort of thing.

July 26, 2009

dIsspace

by joerg.sonnenberger＠web.de

On Sun, Jul 26, 2009 at 12:27:05PM -0400, Jorge Arellano Cid wrote: > On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote: > > When are we supposed to use isspace() > > and when are we supposed to use dIsspace()? > > It appears that one is now used in the C++ code > > and the other in the C code, but I don't know > > the reason for this distinction. > > C and C++ have different conventions for data types. > dIsspace() avoids problems in C code on platforms with > a signed char default. C++ is inmune. The results for C++ are not different as far as ctype(3) are concerned. > OTOH, it looks weird to have both calls in the code. I'd > happily use dIsspace() all over if the compiler optimizes the > extra cast away. The cast is a nop on every architecture that matters. That is not the answer you might get from comp.lang.c though :) Joerg

July 26, 2009

dIsspace

by jcid＠dillo.org

On Sat, Jul 25, 2009 at 08:02:02PM +0000, corvid wrote: > When are we supposed to use isspace() > and when are we supposed to use dIsspace()? > It appears that one is now used in the C++ code > and the other in the C code, but I don't know > the reason for this distinction. C and C++ have different conventions for data types. dIsspace() avoids problems in C code on platforms with a signed char default. C++ is inmune. OTOH, it looks weird to have both calls in the code. I'd happily use dIsspace() all over if the compiler optimizes the extra cast away. -- Cheers Jorge.-

July 26, 2009

dIsspace

by corvid＠lavabit.com

When are we supposed to use isspace() and when are we supposed to use dIsspace()? It appears that one is now used in the C++ code and the other in the C code, but I don't know the reason for this distinction.

July 25, 2009

Planning

by corvid＠lavabit.com

Johannes wrote: > On Fri, Jul 24, 2009 at 07:51:46PM +0200, Joerg Sonnenberger wrote: > > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > > * Add blocker (this also has to do with privacy). > > > A full RE-based one may have significant overhead (test > > > required), but simple string-matching may do most of the trick. > > > I've also thought for a long time that a "don't load from > > > other sites" preference may help a lot. The whole topic needs > > > some thought but it's not hard to implement. > > > > I'd be very careful with that assumptions. A good regex engine needs a > > single pass over the input string independent of the number of strings > > to search for. Note that the OS regex might not work that well, but > > e.g. TRE isn't that big. > > Yes, here is a nice article about regexp matching: > http://swtch.com/~rsc/regexp/regexp1.html > > IRC corvid already did some testing with regexps for adblocking. So far as I can recall, - using a small number of rules and some fnmatch() didn't give any obvious slowdown, although I didn't gprof it. - trying to make one big rule naively for regexec() used a huge amount of memory. and that's as far as I got.

July 24, 2009

exit codes

by corvid＠lavabit.com

I checked what bash sees when dillo returns -1 for bad cmdline argument, and $? shows 255. It seems that out of range values turn into 255. Not that anyone will ever care beyond zero vs nonzero, but I'd like to change it to something valid. I could change it to 1...or 2...or I could use the values from sysexits.h (i.e., borrow their values as opposed to including it, since it doesn't appear to be standard). Any opinions?

July 24, 2009

Planning

by Johannes.Hofmann＠gmx.de

On Fri, Jul 24, 2009 at 07:51:46PM +0200, Joerg Sonnenberger wrote: > On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote: > > * Add blocker (this also has to do with privacy). > > A full RE-based one may have significant overhead (test > > required), but simple string-matching may do most of the trick. > > I've also thought for a long time that a "don't load from > > other sites" preference may help a lot. The whole topic needs > > some thought but it's not hard to implement. > > I'd be very careful with that assumptions. A good regex engine needs a > single pass over the input string independent of the number of strings > to search for. Note that the OS regex might not work that well, but > e.g. TRE isn't that big. Yes, here is a nice article about regexp matching: http://swtch.com/~rsc/regexp/regexp1.html IRC corvid already did some testing with regexps for adblocking. Cheers, Johannes

July 24, 2009