November 2003 - Dillo-dev - lists.mailman3.com

Proposal: United Dillo

by Indan Zupancic

Hello, With "united Dillo" I mean that there is always just one Dillo running per user, so when you start Dillo while it is already running, then the current one will open a new window. I made a patch as proof of concept, see: http://www.xs4all.nl/~dorinek/dillo This approach has two big advantages: 1) Always one Dillo has less overhead than running multiple instances at the same time. 2) Automatic synchronization/no need for synchronization anymore. First advantage is in the spirit of Dillo, wanting to be small, light and fast. Second advantage means that doing certain things will be much simpler, like having always cookies, no need to synchronize plugins, meaning that dpid is not really needed anymore, because most of the points from the problem list are solved (see Dpid.txt). Problems that aren't solved: * Forks can be expensive (Dillo had to fork its dpis). But dpid does much more than simply forking: it forks and then starts up an external program (which often also forks and starts up wget). Beside, if Dillo uses library plugins then there is no need to fork at all. * It increments dillo's core size. The patch adds about 70 lines of code to dillo.c and increases dillo with about 1 K. It is true that if you get rid of dpid then more code is needed in Dillo's core. But that's only moving the code to some other place, no real increase if you ask me. Having a seperate dpid has much more overhead at runtime (seperate process versus bigger executable). You can always make a plugin handling library, then it isn't part of Dillo's core. Of course a united Dillo has problems/disadvantages too: It is sometimes still needed to synchronize multiple windows. If it's not implemented carefully, you may lose functionality (aka command line options). A user can't run more than one Dillo instance. Sometimes it's wanted to run multiple Dillo's, for instance two different versions. But that isn't possible at all, or if version awareness is added, without losing synchronization. What do you think about it? Greetings, Indan

Nov. 20, 2003

Small bug with combined frames/tabs/https patch and gcc 2.9x

by Mike Eriksen

I friend of mine ran into trouble with the lovely combined frames/tabs/https patch and gcc 2.9x. It turned out to be an issue already discussed earlier for the stand-alone version of the https patch concerning a small difference between gcc 2.9x and 3.x, but possibly some people did't catch this original discussion. The cure goes like this: At line 842 in dillo/src/IO/IO.c change FROM: ssize_t St = SSL_read.... TO: ssize_t St; St = SSL_read... The same goes for line 872. I had the impression this already was fixed by Indan, but apparently not. Best regards, Mike -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Nov. 20, 2003

Re: kbnav3 patch test

by Jorge Arellano Cid

Frank, > Jorge Arellano Cid wrote: > > >Hi Frank, > > > > After waiting for a week as you suggested, today I gave a > >review to the new kbnav patch. It feels good! > > > > After some testing I came across a page that produces a > >segfault. The attached patch is against today's CVS + a couple of > >compiler-warning removals. The page is also attached. Beware that > >the segfault is only caught when the new parser is used, and that > >the page has bad-html. The case is interesting though, because a > >weird widget tree is generated and iterators should be able to > >handle/survive them! > > > > Please give it a look. > > > > Cheers > > Jorge.- > > > I have taken a look at your patch-to-my-patch, but did not apply it to > the version I will publish later today. :-o > I did do some manual > reformatting to correct some tab-related problems Good! > (Emacs' use of tabs > messes up things sometimes, and the 2-space indent it uses are not > consistent with Dillo's conventions). Thanks, we strive to be style consistent. BTW, I didn't try to fix indentation in the patch, it was just to do a test run. > Some files seem to be missing from > the patch you sent me, I guess you did not make any changes to those? My mistake. > > I did not see anything in your patch which would have corrected any > compiler warnings by that way, with a possible exception for the > disputed URL_ILLEGAL_CHARS_ macro. In my patch I used > URL_ILLEGAL_CHARS_(u) in html.c, while you use URL_ILLEGAL_CHARS(u). In > the current patch I use URL_ILLEGAL_CHARS(u) as well. The end result > should be the same however now that both versions exist. What compiler > warnings did you get which were corrected by your modifications to my patch? focus.c: In function `Focus_state_find_list': focus.c:268: warning: `list' might be used uninitialized in this function focus.c: In function `Focus_state_find_link': focus.c:465: warning: `list' might be used uninitialized in this function gcc version 3.2.3 > > On that Tarot-page you added to the message, I can say that navigation > is still quirky. But so is the page, it produces 9 warnings about > misplaced </a> tags. If you look at the source, you'll notice that it > misses several closing </A> tags (causing Dillo to allocate links all > over the page). It also contains some links with <BR> in them, which > used to crash patched Dillo because of the problem with > a_Dw_page_construct_iterator (which used to always set the mask to > DW_CONTENT_ALL, I changed this to a user-settable mask like all other > iterators have). I guess you attached the page because of those crashes? Yes, for you to have a way to reproduce it. BTW, that is what I meant with: "page has bad-html". > I will probably publish a new version of the patch (4) today, together > with a new version of the tab/frame patch. That version should be more > or less ready to commit, as no serious problems have cropped up for > several days now. See the list for problems found and corrected > (including the one causing the Tarot page to crash by the way - see my > message dated Wed, 12 Nov 2003 11:00:58 +0100). Oh, I didn't find anything about it at GMANE !? Cheers Jorge.-

Nov. 20, 2003

mail adress

by Sebastian Geerken

Hi! Please send private mail to me via <s.geerken(a)ping.de>. Do not use <sgeerken(a)student.physik.uni-dortmund.de>, the latter causes some problems. Sebastian

Nov. 18, 2003

Re: [Dillo-dev] tabs, https, ...

by Indan Zupancic

Hello, Thank you for your kind offer, but as it looks now it's just Frank and me who could use a CVS branch, and perhaps the Dillo developers are willing to make a CVS branch too, then you don't have to be bothered with mirroring the base Dillo and serving it. Having one or more CVS branches would be great, the question is if the Dillo developers are willing to cooperate and provide them, or that we should make use of your offer. Let's see what Frank has to say about it. Greetings, Indan

Nov. 17, 2003

tabs, https, ...

by taj＠www.linux.org.uk

I've been following the dillo mail list for a while getting a feel for what is up; Good things! With the external patches, I'd be willing to toss in a cvs server that mirrors the base dillo and has modified branches for various interests or even one merged branch. The intent would be to just keep a seperate single repository for external work which dillo could merge portions that fit it's philosophy. The offer would include www,cvs,ftp and shell access for developers that post their nontrivial patches to the official mail-list. -- Trent Jarvi taj(a)www.linux.org.uk

Nov. 17, 2003

Re: [Dillo-dev] gushort for port instead of guint

by Indan Zupancic

> What about the port in DilloUrl then? A port is always a unsigned short, can store it as an int if you want, but doesn't make much sense. I only looked at Dillo's IO code, so didn't notice the one in DilloUrl. It's really not very important, but in the case of SocketData it at least makes the structure smaller, DilloUrl stays the same size. Greetings, Indan

Nov. 16, 2003

Re: [Dillo-dev] HTTPS Patch

by Mike Eriksen

Thank you, Indan! This works great! I hope you will consider to match your HTTPS patch against Franks frames/tab patch once in a while. It makes life so much easier for amatuers like myself. If you guys manage to get the branching to work, this will of course be solved this way. A short note to people trying to compile on Red Hat 9.0: Add: EXPORT CPPFLAGS=-I/usr/kerberos/include in front of "./configure" (and don't forget to to change the zcat lines from "...patch" to "...patch.gz" as pointed out elsewhere) Mike On Fri, 14 Nov 2003, Indan Zupancic wrote: > Hello, > > I made a version of my https patch which works with Frank's tabs patch, > version 14 I think, there was one silly reject. I also made a simple > (unfinished) script to get a patched Dillo version from CVS, edit it for > your needs: > > ------- script ------- > #!/bin/sh > > CFLAGS="-O2 -s -pipe" > > mkdir Dillo-patched > cd Dillo-patched > echo "Getting Dillo source..." > cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co -D > "11/10/03" dillo > > echo "Getting patches..." > wget "http://www.geocities.com/ikbenfrank/dillo-20031110-tabs.patch.gz" > wget "http://www.xs4all.nl/~dorinek/dillo/dillo-20031110-https.patch.gz" > cd dillo > > echo "Applying tabs patch..." > zcat ../dillo-20031110-tabs.patch | patch -p1 > echo "Applying https patch..." > zcat ../dillo-20031110-https.patch | patch -p1 > > ./autogen.sh > echo "Running configure..." > CFLAGS=$CFLAGS ./configure > > #echo "Compiling patched Dillo..." > #make > #echo "Install patched Dillo?" > #su > #make install > #exit > #cd ../../ > #rm -rf Dillo-patched > ------- end script ------- > > Greetings, > > Indan > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev > -- Thinstation FAQ maintainer http://thinstation.sourceforge.net - a light, full featured linux based thin client OS

Nov. 16, 2003

Re: [Dillo-dev] gushort for port instead of guint

by Stephan Goetter

Am Sat, Nov 15, 2003 at 07:09:43PM +0100 schrieb Indan Zupancic und sprach: > Hello, > > Just a tiny cleanup, ports are always shorts, so no need to make it an > int. It also makes the structure SocketData 4 bytes smaller because of > less padding. > > diff -purN orig/src/IO/http.c https/src/IO/http.c > --- orig/src/IO/http.c 2003-11-11 22:15:39.000000000 +0100 > +++ https/src/IO/http.c 2003-11-15 18:26:01.000000000 +0100 > @@ -58,7 +58,7 @@ G_STMT_START { > typedef struct { > gint SockFD; > const DilloUrl *Url; /* reference to original URL */ > - guint port; /* need a separate port in order to support > PROXY */ > + gushort port; /* need a separate port in order to support > PROXY */ > gboolean use_proxy; /* indicates whether to use proxy or not */ > DilloWeb *web; /* reference to client's web structure */ > GSList *addr_list; /* Holds the DNS answer */ > What about the port in DilloUrl then? Stephan

Nov. 16, 2003

gushort for port instead of guint

by Indan Zupancic

Hello, Just a tiny cleanup, ports are always shorts, so no need to make it an int. It also makes the structure SocketData 4 bytes smaller because of less padding. Greetings, Indan diff -purN orig/src/IO/http.c https/src/IO/http.c --- orig/src/IO/http.c 2003-11-11 22:15:39.000000000 +0100 +++ https/src/IO/http.c 2003-11-15 18:26:01.000000000 +0100 @@ -58,7 +58,7 @@ G_STMT_START { typedef struct { gint SockFD; const DilloUrl *Url; /* reference to original URL */ - guint port; /* need a separate port in order to support PROXY */ + gushort port; /* need a separate port in order to support PROXY */ gboolean use_proxy; /* indicates whether to use proxy or not */ DilloWeb *web; /* reference to client's web structure */ GSList *addr_list; /* Holds the DNS answer */

Nov. 15, 2003