- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] tight loop on IO error

by Phil Pennock

On 2003-09-01 at 14:38 +0200, Andreas Schweitzer wrote: > I've noticed similar behaviour a lot of times on the FreeBSD > machine here but not on my Linux box. Since I couldn't > actually pin point the exact problem I did not file a bug > report yet. This was FreeBSD too. Perhaps some different error-code elsewhere? All I did was fix the problem for me -- it's possible that there's still some object cleanup elsewhere that really needs doing ... -- 2001: Blogging invented. Promises to change the way people bore strangers with banal anecdotes about their pets. <http://www.thelemon.net/issues/timeline.php>

Sept. 1, 2003

Re: [Dillo-dev] tight loop on IO error

by Andreas Schweitzer

Hi, On Mon, Sep 01, 2003 at 11:45:06AM +0000, Phil Pennock wrote: > When viewing the page [warning, many images]: ^^^^^^^^^^^^^^^^^^^^ and incorrect HTML :-) > <URL:http://primates.ximian.com/~miguel/all.html> > dillo runs into a tight loop when there's a broken pipe error on > retrieving one of the last couple of images. I've noticed similar behaviour a lot of times on the FreeBSD machine here but not on my Linux box. Since I couldn't actually pin point the exact problem I did not file a bug report yet. Occasionally I would use gdb to see what's up and found indeed broken pipes - but not always. Also it seemed to be hard to reproduce on my Linux machine. > I've tracked down the cause; I'm running the 0.7.3 code, with Frank's > patch, but have confirmed the presence of the code in HEAD via the > WebCVS interface (wonderful thing). I noticed my lock-ups on both the current CVS version, the 0.7.3 release version and patched versions. > In IO/IO.c:IO_write(), if the write() returns (-1) then unless the error > is one of EINTR or EGAIN, the case isn't handled and the "while (1) {}" > loop runs wild. The error conditions and the error handling is probably different enough on FreeBSD vs. Linux so that I notice it more on FreeBSD. Now, that the problem is clear, here is another way to trigger the problem on FreeBSD : try to access a non-responsive web server, and eventually CVS-dillo will freeze not noticing the timeout error, with the patch it no longer freezes ! Great ! (right now you can try www.sco.com, another DOS-attack ? :-) ... and wait 1-2 minutes until the timeout kicks in and watch the unpatched dillo hang with high CPU usage) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Sept. 1, 2003

Re: [Dillo-dev] Rendering problem

by Andreas Kemnade

On Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Now, it still shows several rendering problems. If those are > because of lack of implementation of "floats" we should fix it > someday. If it's because of bad HTML, you know our policy. > > OTOH, I believe slashdot webmasters will not pose major > problems to fix their HTML if they're emailed with the facts... Please fix it (at least the double </td></tr>). > > Please investigate those and report to them. > I have saved the index page (http://slashdot.org/) and edited it a bit. I hope the error ist still in common code. I found this: This simple fix makes the page readable with dillo! --- slashdot.html Mon Sep 1 14:00:58 2003 +++ slashdot1.html Mon Sep 1 14:19:05 2003 @@ -11,8 +11,8 @@ MARGINWIDTH="0" MARGINHEIGHT="0">  -<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#999999"> <FORM ACTION="http://www.osdn.com/osdnsearch.pl" METHOD="GET"> +<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#999999"> <tr><td><FONT size="-1"> <a href="http://www.osdn.com" title="click to visit OSDN.com!"><B><FONT color="#006699">OSDN</FONT></B></A> @@ -55,8 +55,8 @@ <td nowrap width="20" align="right" valign="middle"><FONT size="-1"><A HREF="//slashdot.org/users.pl?op=savemiscopts&opt_osdn_navbar=0"><B>X</B></A> </FONT></td> </tr> -</FORM> </table> +</FORM>  @@ -158,7 +158,7 @@  <A HREF="//science.slashdot.org">Science</A></FONT><BR>  <font size="1"><B>4 more</B></FONT></TD></TR> <TR><TD ><FONT SIZE="2">  <A HREF="//yro.slashdot.org">YRO</A></FONT></TD></TR> -</TD></TR> + <TR><TD> </TD></TR> <TR> <TD bgcolor="#006666"><FONT color="#FFFFFF"> Help</FONT></TD> Greetings Andreas Kemnade

Sept. 1, 2003

tight loop on IO error

by Phil Pennock

When viewing the page [warning, many images]: <URL:http://primates.ximian.com/~miguel/all.html> dillo runs into a tight loop when there's a broken pipe error on retrieving one of the last couple of images. I've tracked down the cause; I'm running the 0.7.3 code, with Frank's patch, but have confirmed the presence of the code in HEAD via the WebCVS interface (wonderful thing). In IO/IO.c:IO_write(), if the write() returns (-1) then unless the error is one of EINTR or EGAIN, the case isn't handled and the "while (1) {}" loop runs wild. With a quick change (including new debug statement) I now see: IO_callback: [GIOcond 4] IO_write IO_write: Broken pipe [errno 32] [St -1] IO_write: aborting: Broken pipe [errno 32] The patch includes some extra cosmetic DEBUG changes which can be safely discarded (and the DEBUG_LEVEL change probably should be ...) -----------------------------< cut here >------------------------------- --- /home/pdp/tmp/zshmiVuTI Mon Sep 1 13:43:24 2003 +++ IO.c Mon Sep 1 13:42:58 2003 @@ -30,7 +30,7 @@ #include "../klist.h" #include "IO.h" -#define DEBUG_LEVEL 5 +#define DEBUG_LEVEL 1 #include "../debug.h" @@ -399,8 +399,12 @@ St = read(io->FD, io->Buf, io->BufSize); io->Status = St; - DEBUG_MSG(3, " IO_read: %s [errno %d] [St %d]\n", - g_strerror(errno), errno, St); + if (errno) { + DEBUG_MSG(3, " IO_read: %s [errno %d] [St %d]\n", + g_strerror(errno), errno, St); + } else { + DEBUG_MSG(3, " IO_read: [St %d] success\n", St); + } if ( St < 0 ) { /* Error */ @@ -446,18 +450,27 @@ St = write(io->FD, io->Buf, io->BufSize); io->Status = St; - DEBUG_MSG(3, " IO_write: %s [errno %d] [St %d]\n", - g_strerror(errno), errno, St); + if (errno) { + DEBUG_MSG(3, " IO_write: %s [errno %d] [St %d]\n", + g_strerror(errno), errno, St); + } else { + DEBUG_MSG(3, " IO_write: success [St %d]\n", St); + } if ( St < 0 ) { /* Error */ io->Status = -errno; - if (errno == EINTR) { + switch (errno) { + case EINTR: continue; - } else if (errno == EAGAIN) { + case EAGAIN: DEBUG_MSG(4, " IO_write: EAGAIN\n"); ret = TRUE; break; + default: + DEBUG_MSG(5, " IO_write: aborting: %s [errno %d]\n", + g_strerror(errno), errno); + return FALSE; } } else if ( St < io->BufSize ){ /* Not all data written */

Sept. 1, 2003

path for support chinese

by super_hoo

I knowed that it had a patch for dillo0.7.2 to supportting Chinese. Where could I find this patch ? thanks a lot. ______________________________________ =================================================================== µ±µ±ÍøÈ«³¡ÒôÏñ5ÕÛ·â¶¥£¬ÓÅ»ÝŒŽœ«œáÊø£¡ (http://ad4.sina.com.cn/sina/dangdang0825.html)

Sept. 1, 2003

Re: [Dillo-dev] Rendering problem (temp-solution.. no patch)

by Ralph Slooten

It seems slashdot.org has serious issues with it's code, so bad that it makes it impossible, hard, or just a PITA to view with Dillo. Instead of patching dillo to render these pages despite obvious errors, I did a bit of simple PHP coding to do the following: I wrote a small php script to download a current working version of slashdot using a Mozilla cookie, wget, tidy and sed. It seems to work fine now with dillo, but probably will skrew up from time to time if 2 users at exactly the same time try refresh the page (I can't be bothered to make this into a full-blown project). It's only ment as a temp solution, and also _only_ supports the main page, linking goes directly to /.'s site, where the rendering is messed up again. http://axljab.homelinux.org:8080/slashdot/ Yeah, this is only for you /. junkies that love using Dillo, and although my internet connection may not be the best in the world, who knows, it may even work for you ;-) Also the page I created will not parse the page like in your own cookies, but is simply the default page using a cokkie of my own, but heck, it's the main page that's most interesting isn't it. Another note, each time the page is refreshed, the php downloads a new copy of/. .... so please don't abuse by continuously refreshing as it will kill my bandwidth, and possibly get me banned from slashdot altogether. Enjoy, and let me know if it works for you ... I love success stories ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 31, 2003

Re: [Dillo-dev] Rendering problem

by Madis Janson

On Fri, 29 Aug 2003, Jorge Arellano Cid wrote: > On Thu, 28 Aug 2003, Ralph Slooten wrote: > > > On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) > > "Andrew A. Gill" <superluser(a)frontiernet.net> wrote: > > > > > Normally, this isn't something that I really care about, but now it's > > > causing slashdot to be rendered as black-on-black text, thus depriving me > > > of my ability to read about the new MD5 sums that the RIAA is using. > > > > Yes, I'm getting this too since today. It's probably a small html error > > somewhere, but it's totally skrewed up dillo's rendering to the fullest here. > > Unfortunately slashdot is sending awful HTML-like content. > > The black text can be explained because they explicitly set the > background, textcolor and visited links to black! (<BODY ...>). > > Probably it changes with CSS. > No, slashdot does not use CSS. The white background is created by tables and is still visible, but articles now seem to be on the side of it, not on it (talking about main page). Probably some table/tr tags are in wrong order and screw up the push/pop parsing. Reason why i think so is that the slashdot page can be seen quite ok in dillo with this patch: @@ -1139,6 +1146,8 @@ static void Html_pop_tag(DilloHtml *html Html_eventually_pop_dw(html); return; } + if (Html_match_tag(html->stack[tag_index].tag, "table>", 6)) + break; } /* Not found, just ignore. */ } But yes, its a workaround for buggy html (not invented for slashdot) and a fact that it helps just quite proves that the slashdot page has problems with tables (along other bad html). I tried to find the problem from slashdot index page, but it was such a bloody mess that my sleepy brain could not parse it at all...

Aug. 31, 2003

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

On Sat, 30 Aug 2003 13:47:13 +0200 Ralph Slooten <ralph(a)genesys.ro> wrote: > After running the saved page through tidy, it actualy renders, and renders > well! Umm, just discovered that this only works for me when logged in. If I move my cookies somewhere else, re-open slashdot with dillo, save that page and try with tidy, it fails... Just thought I would let you all know before you go blue in the face trying ;-) Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 30, 2003

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

On Fri, 29 Aug 2003 10:31:29 -0400 (CLT) Jorge Arellano Cid <jcid(a)softhome.net> wrote: > Try with "force_my_colors=YES". Yes, this works, althought the rendering is totally shit ;-) ... definitly not a dillo problem in this case. The problem with Slashdot is that there are just so many tables / blocks that it makes it almost impossible to locate the precise bug (although if I am correct the page is filled with bugs). > Now, it still shows several rendering problems. If those are > because of lack of implementation of "floats" we should fix it > someday. If it's because of bad HTML, you know our policy. Yes, Dillo's policy is good... if the html is wrong then that's too bad. BUT... but but but, instead of manually running through all the code, I tried it with "tidy", which found a grand total of 254 warnings and 0 errors... Well, as for 0 errors, I would say 254 warnings should be more than enough to validate one big error ;-) After running the saved page through tidy, it actualy renders, and renders well! > OTOH, I believe slashdot webmasters will not pose major > problems to fix their HTML if they're emailed with the facts... > > Please investigate those and report to them. Yes, I have reported a bug about bad HTML on the sourceforge site. It's not really a matter of bad HTML, as the HTML seems resonable, but they are using terms and codes which are definitely not HTML compliant I would say. If you are interested in the output I have put up the origional page with the "fixed" version, and output of warnings / errors here: http://members.rott.chello.nl/r.slooten2/dillo/ You will see here that it appears as if I'm still logged in.. for some reason I cannot log out, LOL .. but that's not the issue.. you can just see how many invalid html commands they seem to be using, and that after the removal of this, and the insertion of several <font> and </font> attributes fixes the whole page which then renders perfectly in Dillo. Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 30, 2003

Re: [Dillo-dev] Problems with tab patch

by Nigel Wilkinson

Thanks Frank Nigel

Aug. 29, 2003

[PATCH] Server Mode (was: commands & auto-reload)

by Melvin Hadasht

Hi, I previously posted a "command" patch as a preliminary for the server mode patch for Dillo. It was about handling the list of commands to be sent to the server. The hereby attached patch already contains that patch slightly modified and adds the ability to eventually switch to server mode or to connect and send the commands to a server This patch does not solve the "reload" bugs. I have a web page (user oriented) at: http://melvin.hadasht.free.fr/home/dillo/server/index.html I finally chose the "straightforward" approach instead of the dpid approach. Two reasons for that: i) I felt it'd introduce more complexity, especially for a client instance that needs to connect to a server and ii) the current dpid allows only one socket per service while it would be needed to have more than one Dillo server. I already explained in another mail that the socket name would need to be parametrized (by the server name, for example). Of course, this patch of mine is just a suggestion, if others feels that the dpid approach is better and more efficient, I'd be happy to see how they implemented it. The "commands" patch could still be used. They just need to handle the server/client connection. The hereby attached patch has the following characteristics: - gtk_init() is never called by a client instance - if the XID option is given, and if the server already has an embedded window with that XID, it will reuse it. - an application can still directly access to the server socket and can keep the connection open until it really does not need it. It has to check whether /tmp/dillo-$USER-$SERVERNAME exists. If not, it should launch "dillo -s $SERVERNAME". Then it should open that Unix Domain Socket. Then it just need to send commands to it, the syntax of the commands being that of the -c options. The commands that are to be sent through the socket must be of the following format: ([COMMAND][NUL])*[CRLF] That is, each COMMAND string must be followed by the terminal NUL byte. The list of commands are buffered by the server command until a [CRLF] ("\r\n" without the terminal \NUL) is sent or until the socket is closed. Then, the list of buffered commands are executed. I'll provide a simple library that could be used by an application to directly use the socket, but for the moment, the most easy and straighforward approach is to set the browser command line to "dillo -s SERVERNAME URL". On a PII266Mhz, starting a dillo client with a single open() command needs only ~0.04 seconds (if gtk_init() were executed before command line parsing and thus if each dillo client had to init the display, it would have needed more than 0.1 seconds). My next plans are to provide a simple library to connect (and eventually start) a server and to sent it commands. Then I will try to fix the "reload" bug when the reload time is too short. -- Melvin Hadasht

Aug. 29, 2003

Rendering

by Jorge Arellano Cid

Hi Sebastian! Hope you're not under a pile of workload... Please review this site: http://cocoon.apache.org/index2.html When loaded slowly (dialup speed) it renders the leftmost column too wide (almost a screen), but Back&Forward fixes it. I you can also give a look at the slashdot problem it'd be great. I'm much more interested in the first though. Regards Jorge.-

Aug. 29, 2003

Re: Tab + frame patch, any progress?

by Jorge Arellano Cid

On Wed, 27 Aug 2003, Frank de Lange wrote: > Any progress on the CSS front by the way? Sometime ago we concluded with Sebastian that it may take near three months of work of both of us. We're focusing on other priorities now. I hope we can review your patch soon with him. Cheers Jorge.-

Aug. 29, 2003

Re: [Dillo-dev] Rendering problem

by Jorge Arellano Cid

On Thu, 28 Aug 2003, Ralph Slooten wrote: > On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) > "Andrew A. Gill" <superluser(a)frontiernet.net> wrote: > > > I've been having a problem with dillo rendering some portions of text. > > For instance, the Google sponsored links always take up vertical space > > before the results. > > > > Normally, this isn't something that I really care about, but now it's > > causing slashdot to be rendered as black-on-black text, thus depriving me > > of my ability to read about the new MD5 sums that the RIAA is using. > > Yes, I'm getting this too since today. It's probably a small html error > somewhere, but it's totally skrewed up dillo's rendering to the fullest here. Unfortunately slashdot is sending awful HTML-like content. The black text can be explained because they explicitly set the background, textcolor and visited links to black! (<BODY ...>). Probably it changes with CSS. > > Since about 2 weeks ago I'm also getting a black border on the right (with > exception to today of course where most of the page is black) which just takes > up valuable space ;-) > > Tried the light mode too like Frank suggests, but I prefer the default layout > myself. Anyway, it's not a dillo problem I think, as I get a total of 530 errors > just on the index page itself!!!!! Check now too if ya want: > http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org%2F Try with "force_my_colors=YES". Now, it still shows several rendering problems. If those are because of lack of implementation of "floats" we should fix it someday. If it's because of bad HTML, you know our policy. OTOH, I believe slashdot webmasters will not pose major problems to fix their HTML if they're emailed with the facts... Please investigate those and report to them. Cheers Jorge.-

Aug. 29, 2003

Re: [Dillo-dev] Running external Gtk programs under Tabs (fwd)

by Lars Segerlund

very cool ! :-D BIG SMILEY Jorge Arellano Cid wrote: > > ---------- Forwarded message ---------- > Date: Wed, 27 Aug 2003 23:48:14 -0700 > From: t <loveall(a)qwest.net> > To: Jorge Arellano Cid <jcid(a)softhome.net> > Subject: Running external Gtk programs under Tabs > > Jorge, > > Please forward this to the dillo/dev mailing list unless you think it is not > appropriate. > > Nice job on dillo, guys! Have been using it since at least 0.2.1. > > Nice work on the tabs, Frank. They have added a whole new dimension to dillo. > > Recently, while working on a multi-media project, noticed that I had way too > many instances of a text editor open. Couldn't easily find the desired > file. > > About then Frank put up the tab/frame patch. Spent a day or so getting > external Gtk apps to run in a tabbed window. This turned dillo into an MDI > interface with built-in file picker and HTML help file viewer. > > This has been working for me in a stable manner, e.g. no seg faults, for about > two weeks under heavy use. Which means it will only take someone else about 5 > minutes to induce a failure:-). > > Have modified a file manager, my personal text editor and the erwin HTML > editor to run as client Gtk apps, just like dillo. As a matter of fact, dillo > can run itself as an external Gtk app in a tabbed window. The patch file for > the tab/frame patched version of dillo is set up to do this as a working > example. You can download it from: > http://www.users.qwest.net/~loveall/xid8-patch.gz > > !!!! NOTE !!!! > This patch is valid only on dillo-0.7.3 patched with Franks version 9 > tab/frame patch: > http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz > > To modify a typical Gtk app to act as a client requires just the following: > > In function main(), add these lines at the beginning just after the data > declarations: > > guint32 xid = 0; > int i = 1; > > if (i < argc-1 && !strcmp(argv[i++],"-x")){ > xid = strtol(argv[i], NULL, 10); > argc -= 2; > argv += 2; > if(xid == LONG_MIN || xid == LONG_MAX) xid = 0; > } > > This requires that the first two args when calling dillo be '-x <Xid number>'. > > Find and replace the (typically) single line: > > main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > > with: > if(!xid) > main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); > else > main_window = gtk_plug_new (xid); > > See also the working source which references 'xid' in dillo.c and interface.c. > > Thanks again, to the dillo crew. You guys are awesome. > > Regards, > Terry Loveall > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 29, 2003

Re: [Dillo-dev] Problems with tab patch

by Frank de Lange

On Thu, 28 Aug 2003 22:00:26 +0100 Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > Great, worked a treat but just for my info where was I going wrong in the following > > 1. I was gunzipping the patch file > 2. I was useing 'patch < dillo-20030821-tabs.patch' > if my CVS source was in ~/Source/dillo I tried this from ~/Source, ~/Source/dillo, and ~/Source/dillo/src > I also tried the above as 'patch -p1 < dillo-20030821-tabs.patch' as > well as -p2, -p3 etc > > The command 'patch < dillo-20030821-tabs.patch' came from the man page > so I just wondered why it didn't work. Well, this should also work: (on a clean, non-patched, not even partly patched source tree) cd ~/Source/dillo patch -p1 < /path/to/dillo-20030821-tabs.patch If it did not, either your source or uncompressed patch is not what it should be. Or you forgot to give the exact path to the patch file? > If I understand things correctly in the command 'zcat > dillo-20030821-tabs.patch.gz | patch -p1' > that worked zcat decompresses the zipped dillo patch and pipes it to > patch. Why is this different from > 'patch -p1 < dillo-20030821-tabs.patch' There is no real difference (zcat is more practical, as you do not have to uncompress the patch). Both commands should have the same results. If not, something weird is happening. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 29, 2003

Re: [Dillo-dev] Dillo Windows port IO_submit

by Madis Janson

On Thu, 28 Aug 2003, Robin Rowe wrote: > Hi. The IO_submit code isn't portable to Windows. Unlike unix, Windows > offers only blocking io on pipes. The usual way to deal with this is to spin > off read or write into another thread where it can block without hanging the > program. Your io scheme is complicated enough that it isn't immediately > obvious how best to do that. > > Can somebody offer more insight into the code below or offer any > suggestions? How long does an IO_submit operation stay open and what data is > transmitted normally? What dialog is expected across the pipe? Use two connected sockets instead of the pipe. You can create such pair for example by listening random port (bind to port 0) and connecting to address found out using getsockname.

Aug. 28, 2003

Re: [Dillo-dev] Dillo Windows port

by Andreas Schweitzer

Hi, although I'm not a main developer, I think I can answer a bit. > I have Dillo built now as a native Windows VC++ 6 project and am debugging > it. cool ! > Dillo uses pthreads and fork. Wouldn't it be better to use one multi-process > API? Shouldn't it be all pthreads? Of course, there is no fork under In the current CVS version I only found one reference to fork and it was to start a plugin. Currently, this is no longer used and is dead code. However, some way of starting the dpid automatically will most likely return - for the current CVS version this dpid has to be started manually. But either way, the plugins and the dpid are totally seperate programs. dpid is designed to only be started once. This functionality should be reproducable in Windows, I'd say :-) The other fork's are within the plugin framework when the dpid actually starts the requested plugin. You probably can delay that framework. Dillo will still work - with limited functionality. > Although Berkeley sockets are available in Windows, the AF_LOCAL protocol > doesn't seem to be. I've faked that out to get Dillo to compile but more > work may be needed there. Why are you using AF_LOCAL? What does that code do > and why? It's again related to plugins :-) ... dillo talks to its plugins via unix domain sockets. And that's what this code relates to. If you only need a help browser, you can ignore the plugin framework I would say. That way you will get no bookmarks, though. And the preferences are also planned to be done via a plugin. Or at least delay the plugin stuff until it matured. That's the cool part about the plugin design :-) I hope that helps, Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 28, 2003

Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Melvin Hadasht

> there are two small problems: > -if you specify a small reload time, and by that time is over before > the page is actually loaded -> coredump Does not core dump for me. Where does it core dump? I tried "dillo -r 1 http://freshmeat.net" and it reloads the page before it is finished loading. Or by "actually loaded" you mean "did not *start* to load" ?

Aug. 28, 2003

Re: [Dillo-dev] Dillo Windows port IO_submit

by Robin Rowe

Hi. The IO_submit code isn't portable to Windows. Unlike unix, Windows offers only blocking io on pipes. The usual way to deal with this is to spin off read or write into another thread where it can block without hanging the program. Your io scheme is complicated enough that it isn't immediately obvious how best to do that. Can somebody offer more insight into the code below or offer any suggestions? How long does an IO_submit operation stay open and what data is transmitted normally? What dialog is expected across the pipe? Thanks, Robin /* * Receive an IO request (IORead | IOWrite | IOWrites), * Set the GIOChannel and let it flow! */ static void IO_submit(IOData_t *r_io) { /* Insert this IO in ValidIOs */ IO_ins(r_io); #ifdef WIN32 /* Launch thread? */ #else /* Set FD to background and to close on exec. */ fcntl(r_io->FD, F_SETFL, O_NONBLOCK | fcntl(r_io->FD, F_GETFL)); fcntl(r_io->FD, F_SETFD, FD_CLOEXEC | fcntl(r_io->FD, F_GETFD)); #endif if ( r_io->Op == IORead ) { g_io_add_watch(r_io->GioCh, G_IO_IN | G_IO_ERR | G_IO_HUP, IO_callback, GINT_TO_POINTER (r_io->Key)); g_io_channel_unref(r_io->GioCh); } else if ( r_io->Op == IOWrite || r_io->Op == IOWrites ) { g_io_add_watch(r_io->GioCh, G_IO_OUT | G_IO_ERR, IO_callback, GINT_TO_POINTER (r_io->Key)); g_io_channel_unref(r_io->GioCh); } } --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Aug. 28, 2003

Re: [Dillo-dev] Rendering problem

by Ralph Slooten

On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) "Andrew A. Gill" <superluser(a)frontiernet.net> wrote: > I've been having a problem with dillo rendering some portions of text. > For instance, the Google sponsored links always take up vertical space > before the results. > > Normally, this isn't something that I really care about, but now it's > causing slashdot to be rendered as black-on-black text, thus depriving me > of my ability to read about the new MD5 sums that the RIAA is using. Yes, I'm getting this too since today. It's probably a small html error somewhere, but it's totally skrewed up dillo's rendering to the fullest here. Since about 2 weeks ago I'm also getting a black border on the right (with exception to today of course where most of the page is black) which just takes up valuable space ;-) Tried the light mode too like Frank suggests, but I prefer the default layout myself. Anyway, it's not a dillo problem I think, as I get a total of 530 errors just on the index page itself!!!!! Check now too if ya want: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.slashdot.org%2F Greetings Ralph -- http://axljab.homelinux.org:8080/ "...the software said Win95 or better, so I installed Linux"

Aug. 28, 2003

Re: [Dillo-dev] Problems with tab patch

by Nigel Wilkinson

On Thu, 28 Aug 2003 22:19:29 +0200 Frank de Lange <frank(a)unternet.org> wrote: > You need to cd to the dillo directory before applying the patch: > > Assuming you have dillo CVS in /usr/src/dillo-cvs/dillo, and you do NOT want to apply the patch over the CVS directory itself (good idea, as you might want to update the CVS later...): > > % cd /usr/src/dillo-cvs (or whereever the dillo directory resides) > % cp -rd dillo dillo_tabs (this copies the CVS dir to a new dir) > % cd dillo_tabs (go to the new dir) > % zcat dillo-20030821-tabs.patch.gz | patch -p1 (apply patch) > % ./autogen.sh (generate configure and Makefile.in) > % ./configure (with whatever options you prefer) > % make > % make install > Great, worked a treat but just for my info where was I going wrong in the following 1. I was gunzipping the patch file 2. I was useing 'patch < dillo-20030821-tabs.patch' if my CVS source was in ~/Source/dillo I tried this from ~/Source, ~/Source/dillo, and ~/Source/dillo/src I also tried the above as 'patch -p1 < dillo-20030821-tabs.patch' as well as -p2, -p3 etc The command 'patch < dillo-20030821-tabs.patch' came from the man page so I just wondered why it didn't work. If I understand things correctly in the command 'zcat dillo-20030821-tabs.patch.gz | patch -p1' that worked zcat decompresses the zipped dillo patch and pipes it to patch. Why is this different from 'patch -p1 < dillo-20030821-tabs.patch' Cheers Nigel

Aug. 28, 2003

Re: [Dillo-dev] Problems with tab patch

by Frank de Lange

On Thu, 28 Aug 2003 20:35:27 +0100 Nigel Wilkinson <nigel(a)waspz.plus.com> wrote: > > Evenin' all > > I'm trying to patch the CVS with the tab patch but I haven't used patch much. The problem I'm haveing is that I don't know which directory to run the path from, it keeps complaining that it can't find the file to patch You need to cd to the dillo directory before applying the patch: Assuming you have dillo CVS in /usr/src/dillo-cvs/dillo, and you do NOT want to apply the patch over the CVS directory itself (good idea, as you might want to update the CVS later...): % cd /usr/src/dillo-cvs (or whereever the dillo directory resides) % cp -rd dillo dillo_tabs (this copies the CVS dir to a new dir) % cd dillo_tabs (go to the new dir) % zcat dillo-20030821-tabs.patch.gz | patch -p1 (apply patch) % ./autogen.sh (generate configure and Makefile.in) % ./configure (with whatever options you prefer) % make % make install Easy, not? Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 28, 2003

Re: [Dillo-dev] Rendering problem

by Frank de Lange

On Thu, 28 Aug 2003 12:57:36 -0400 (EDT) "Andrew A. Gill" <superluser(a)frontiernet.net> wrote: > I've been having a problem with dillo rendering some portions of text. > For instance, the Google sponsored links always take up vertical space > before the results. > > Normally, this isn't something that I really care about, but now it's > causing slashdot to be rendered as black-on-black text, thus depriving me > of my ability to read about the new MD5 sums that the RIAA is using. Off Topic, but... slashdot on Dillo works best when you use Slashdot's 'light' mode... No more annoying pictures, colors or other crap, just the 'facts' (if facts and slashdot can be named in the same sentence...). You need to be logged in to use light mode. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 28, 2003

Problems with tab patch

by Nigel Wilkinson

Evenin' all I'm trying to patch the CVS with the tab patch but I haven't used patch much. The problem I'm haveing is that I don't know which directory to run the path from, it keeps complaining that it can't find the file to patch Cheers Nigel

Aug. 28, 2003

Rendering problem

by Andrew A. Gill

I've been having a problem with dillo rendering some portions of text. For instance, the Google sponsored links always take up vertical space before the results. Normally, this isn't something that I really care about, but now it's causing slashdot to be rendered as black-on-black text, thus depriving me of my ability to read about the new MD5 sums that the RIAA is using. (bug 493) -- |Andrew A. Gill |I posted to Silent-Tristero and| |<superluser(a)frontiernet.net> |all I got was this stupid sig! | |alt.tv.simpsons CBG-FAQ author | | | (Report all obscene mail to Le Maitre Pots)| |Nothing here yet: <http://www.needsfoodbadly.com> Temporary sig: -- But thanks for everything else.

Aug. 28, 2003

Re: [Dillo-dev] Dillo Windows port

by Robin Rowe

Jorge, I have Dillo built now as a native Windows VC++ 6 project and am debugging it. Seems to be my unstable 1.14 version of GTK for Windows that is causing Dillo to hang on load. By the way, I'm the new GTK1 for Windows maintainer. Tor and GIMP for Windows are moving to GTK2, but CinePaint is staying with GTK1. Can we talk about Dillo design portability a bit? Dillo uses pthreads and fork. Wouldn't it be better to use one multi-process API? Shouldn't it be all pthreads? Of course, there is no fork under Windows. There isn't any pthreads either, but I've written a light emulation library (as yet untested) that calls Windows threads instead. You are using mutex and conditional pthreads together, which seems redundant. Are both needed? Could you use just a mutex? What is that code supposed to do and why? Another call unavailable in Windows is fcntl(). I've conditionally compiled those out, and don't know yet what that may effect. Although Berkeley sockets are available in Windows, the AF_LOCAL protocol doesn't seem to be. I've faked that out to get Dillo to compile but more work may be needed there. Why are you using AF_LOCAL? What does that code do and why? Can you tell me about your internationalization support in Dillo? How is that set up? What is it designed to handle? Thanks, Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Aug. 28, 2003

[Long] dillo server mode/remote control (was: Re: dillo / time-controlled reloads)

by Melvin Hadasht

Hi, > A simple flag, maybe in the DilloUrl or in the cache entry. In the posted patch, I just added a reload_timeout in DilloUrl and a reload_timeout_tag in BrowserWindow. When viewing a DilloUrl with a non-zero DilloUrl::reload_timeout, BrowserWindow will start a single shot timer which tag is saved in BrowserWindow::reload_timeout_tag. This timer will trigger a reload (as if the user hit the reload button). The reload will restart the timer. If another DilloUrl is viewed, any pending timer is stopped (and the new DilloUrl is again tested for a non-zero DilloUrl::reload_timeout). I also added a_Url_set_reload() to set/unset that reload_timeout. > > - add a "-r, --reload-every" command line option that calls that function. > > In fact, when I finish implementing the "(remote-)command" option, it would be > > something like: "-c open(URL, refresh=60)" (that is if I finally decide that > > supporting commands with more than one argument is worth the work). > > Hmmm, I think a simple cli switch to tell dillo to listen to > the reloads.dpi is enough: > > dillo -reloads Internally, the command line options are translated to a linked list of commands, which are executed by the running instance, or sent to a running server. So I implemented both. The advantage of the "-c" option is that commands could support parameters as in: "open(URL newwindow reload=50)". It adds flexibility. > > > > The first duty is to define what is required for a good, > > > > general purpose, kind of reloading dpi. The next one is to reduce > > > > the features to a minimum working set, then implement! I think it is easier to implement a remote command dpi than implementing a "reload dpi". The "reload" should only be one of the remote commands that a server must understand. > fprintf(reloads_dpi_socket, > "push http://localhost/someurl visible\n"); > > may be all the client program needs to know. Unfortunatly, fprintf does not work with Unix Domain Sockets but with pipes. Pipes have a limitation: if more than a client access to the pipe, the server could get mixed-up commands if the clients commands are larger than a system specific buffer size. For robustness, I will use UDS. If a client program wants to use dillo server capability, then we'd better provide a lib or a small C file. > Note that it may be good to integrate the remote control > functionality into the same dpi (and maybe call it remote.dpi?). Yes, I agree, the reload (and other functions) should be served by the remote control functionality. Whether it should be a plugin, I am not completly convinced, because it adds a little more complexity: At the current state of the dpid, we cannot run more than one dillo server (if we make exclusive use of the dpid framework). This is because for each service, there is only one socket. I think it is more flexible to have the possibility to have different dillo servers, each one with a distinct name provided by the user (or the application). For that, dpid should accept an additional parameter which is used to parametrize the socket name, e.g.: <dpi cmd="start_plugin" msg="dillo" param="cinepaint_help"> dpid will then look if a socket named: "/tmp/$USER-$RAND/dillo-server-$PARAM" ($PARAM being the value of the param tag) exist. If it does not exist, it would start the plugin with a special command line option: dillo -s $PARAM. This will require a way to tell the dpid how to call a parametrized plugin. Thus, relying on dpid to create the socket and run the server plugin would need some changes to dpid. An alternative solution, is to not rely on dpid but on dillo itself to start a server and to create the socket. The socket will be independent from the dpi_dir, and would be /tmp/dillo-$USER-$SERVERNAME. Subsequent communications could still use dpid's I/O functions. > This means adding a simple and useful API for help programs to > use. For instance to let them push new URLs into the same > instance of dillo (and not having to start a new dillo per > requested page). (if the application never starts a dillo instance, then there is no guarantee that there is a dpid running. Or you meant the API should take care of this, too?)

Aug. 28, 2003

Re: [Dillo-dev] CinePaint and Windows port

by Jorge Arellano Cid

On Tue, 26 Aug 2003, Robin Rowe wrote: > Hi. I'm the project leader for CinePaint, an open source paint program used > mainly by the motion picture industry. Our code was branched from GIMP in > 1998. Hi! Yes, I knew about your project by the time we were applying to LinuxFund... > > How would the Dillo project feel about Dillo being embedded in another > application as a help browser? Very good. In fact it has been done in the past with the Sylpheed-claws email client: it embeds dillo for secure HTML mail viewing. In fact we're working in a remote control plugin for dillo to allow better support for this kind of functionality. Currently applications can launch Dillo and let the user navigate the help docs without problems. Now, if the app. wants to provide context sensitive help, it needs to end dillo and launch another instance to make it display the required page (quite fast, but not optimal), and here's where we're improving it. > We're looking for a new help system browser and considering Dillo. We are > impressed how compact your implementation is. We only need a limited set of > HTML features: links, images, tables, bullet lists, number lists, headings, > ordinary text, bold, and italic. In these features we need the browser to be > absolutely stable. Any issues there? None! You'll hardly find a browser that's more stable. And for any issue that may arise, you can email us back for support. > > We support all platforms, including Windows. One of the first things I would > intend to do is port Dillo to Windows. I saw in your archives that you had > made some effort in that direction, but it seemed to peter out. What are the > problems? If you need dillo to run on the dark side, take a look at: http://www.hyperborea.org/software/dillo/cygwin.html Cheers Jorge.-

Aug. 28, 2003

Running external Gtk programs under Tabs (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Wed, 27 Aug 2003 23:48:14 -0700 From: t <loveall(a)qwest.net> To: Jorge Arellano Cid <jcid(a)softhome.net> Subject: Running external Gtk programs under Tabs Jorge, Please forward this to the dillo/dev mailing list unless you think it is not appropriate. Nice job on dillo, guys! Have been using it since at least 0.2.1. Nice work on the tabs, Frank. They have added a whole new dimension to dillo. Recently, while working on a multi-media project, noticed that I had way too many instances of a text editor open. Couldn't easily find the desired file. About then Frank put up the tab/frame patch. Spent a day or so getting external Gtk apps to run in a tabbed window. This turned dillo into an MDI interface with built-in file picker and HTML help file viewer. This has been working for me in a stable manner, e.g. no seg faults, for about two weeks under heavy use. Which means it will only take someone else about 5 minutes to induce a failure:-). Have modified a file manager, my personal text editor and the erwin HTML editor to run as client Gtk apps, just like dillo. As a matter of fact, dillo can run itself as an external Gtk app in a tabbed window. The patch file for the tab/frame patched version of dillo is set up to do this as a working example. You can download it from: http://www.users.qwest.net/~loveall/xid8-patch.gz !!!! NOTE !!!! This patch is valid only on dillo-0.7.3 patched with Franks version 9 tab/frame patch: http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz To modify a typical Gtk app to act as a client requires just the following: In function main(), add these lines at the beginning just after the data declarations: guint32 xid = 0; int i = 1; if (i < argc-1 && !strcmp(argv[i++],"-x")){ xid = strtol(argv[i], NULL, 10); argc -= 2; argv += 2; if(xid == LONG_MIN || xid == LONG_MAX) xid = 0; } This requires that the first two args when calling dillo be '-x <Xid number>'. Find and replace the (typically) single line: main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); with: if(!xid) main_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); else main_window = gtk_plug_new (xid); See also the working source which references 'xid' in dillo.c and interface.c. Thanks again, to the dillo crew. You guys are awesome. Regards, Terry Loveall

Aug. 28, 2003

Re: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Jorge Arellano Cid

On Wed, 27 Aug 2003, Madis Janson wrote: > > On Wed, 27 Aug 2003, Melvin Hadasht wrote: > > > [Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to > > the list and will respond when I have time and when I have something to respond.] > > > > Hi, > > > > > ok, dillo never reloads the images, not even on manual reloads - still > > > showing days old stats. > > > you think that is fixeable soon, for some value of "soon"? > > > > I don't always have time for Dillo. Maybe this weekend, maybe the next. > > > > This patch (although not up-to-date for current dillo version) has > capability to reload things, when it has been requested with > expires/no-cache/cache-control headers. > > http://www.zone.ee/myzz/dillo/dillo-cache-control.diff > > Since the dillo cache has not changed much lately, it probably applies > with minor conflicts. > > Version for dillo 0.7.3+tabs is part of patch described here: > http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html > > But it doesn't make dillo reload images, when reload button has been > pressed. imho mozilla/ie doesn't do it eighter by default (you have to > press shift-reload to make them reload images). Believe it or not I've being reviewing the patch these days and it's in my short-term list of duties! A lot of project managing (meetings, conversations, emails, projection requests, etc, etc, etc.) workload has come my way. I expect to be more coding-active next month. Some very good news may happen. Cross fingers! Jorge.-

Aug. 27, 2003

Re: [Dillo-dev] Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Madis Janson

On Wed, 27 Aug 2003, Melvin Hadasht wrote: > [Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to > the list and will respond when I have time and when I have something to respond.] > > Hi, > > > ok, dillo never reloads the images, not even on manual reloads - still > > showing days old stats. > > you think that is fixeable soon, for some value of "soon"? > > I don't always have time for Dillo. Maybe this weekend, maybe the next. > This patch (although not up-to-date for current dillo version) has capability to reload things, when it has been requested with expires/no-cache/cache-control headers. http://www.zone.ee/myzz/dillo/dillo-cache-control.diff Since the dillo cache has not changed much lately, it probably applies with minor conflicts. Version for dillo 0.7.3+tabs is part of patch described here: http://www.zone.ee/myzz/dillo/0.7.3/dillo-0.7.3-mzz.html But it doesn't make dillo reload images, when reload button has been pressed. imho mozilla/ie doesn't do it eighter by default (you have to press shift-reload to make them reload images).

Aug. 27, 2003

Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Melvin Hadasht

[Please, as this thread is on the ML, do not mail me personnaly (nor CC me). I'm subscribed to the list and will respond when I have time and when I have something to respond.] Hi, > ok, dillo never reloads the images, not even on manual reloads - still > showing days old stats. > you think that is fixeable soon, for some value of "soon"? I don't always have time for Dillo. Maybe this weekend, maybe the next. Concerning the reload time, I should be able to fix it when I have time. Concerning the cached images, I will need more time. Concerning the "void" input driver, is the coredump due to my patch? -- Melvin Hadasht

Aug. 27, 2003

tab and frames in webmail

by �޽��

hi, Frank de Lange: I apply you dillo tab frame patch,and it seem very cool. But when I go to the www.163.com and www.163.net, I found I can't go into my mailbox.It only says that "This page uses frames, but your browser doesn't support them."And the statusbar shows "Contacting host", for ever. In windows IE I can see the soursecode of that page as following: <html><head> <title>网易邮件系统</title> <meta http-equiv="Content-Type" content="text/html; charset=gb2312"> </head> <frameset frameborder=NO rows=80,* border=0 framespacing=0> <frame name="2" src="/newtop.htm" target=contents scrolling=NO marginwidth=0 marginheight=0 frameborder=NO > <frameset border=0 cols=160,* framespacing=0 marginheight=0 marginwidth=0 frameborder=NO> <frame name="folder" src="/cgi/ldapapp?funcid=simplefdr&sid=DBTpkvElTAQAKUwf" target=rtop marginwidth=0 marginheight=0 frameborder=NO scrolling=yes>  <frame name="main" src="/cgi/ldapapp?funcid=foldmain&sid=DBTpkvElTAQAKUwf" target=rbottom marginwidth=0 marginheight=0 scrolling=AUTO frameborder=NO> </frameset> </frameset> <noframes> <body bgcolor="#FFFFFF"><p>This page uses frames, but your browser doesn't support them.</p> </body></noframes> </html> What's wrong? best reguards 　　　　　　　　Jewen_Luo(a)163.com 　　　　　　　　　　2003-08-27

Aug. 27, 2003

CinePaint and Windows port

by Robin Rowe

Hi. I'm the project leader for CinePaint, an open source paint program used mainly by the motion picture industry. Our code was branched from GIMP in 1998. How would the Dillo project feel about Dillo being embedded in another application as a help browser? We're looking for a new help system browser and considering Dillo. We are impressed how compact your implementation is. We only need a limited set of HTML features: links, images, tables, bullet lists, number lists, headings, ordinary text, bold, and italic. In these features we need the browser to be absolutely stable. Any issues there? We support all platforms, including Windows. One of the first things I would intend to do is port Dillo to Windows. I saw in your archives that you had made some effort in that direction, but it seemed to peter out. What are the problems? Thanks! Robin --------------------------------------------------------------------------- Robin.Rowe(a)MovieEditor.com Hollywood, California www.CinePaint.org Free motion picture and still image editing software

Aug. 27, 2003

[lmettler@lamlaw.com: Re: A few remarks on your site layout...]

by Frank de Lange

----- Forwarded message from Lewis Mettler <lmettler(a)lamlaw.com> ----- >Thanks for the corrected index.html page for my site. > >You are correct. Some of those tags did appear to be out of place. > >I first wrote that page 5-6 years ago using a program from Corel. It is >not surprising that it was put up incorrectly. Most likely I was trying >several different formats and then stopped screwing with it. I noticed >it still had the NT label embedded. I have not used NT for many years. > >In any event, I edited the version you provided to replace the NT >reference and updated a few of the tags. > >Thanks again. > >And, good fortune with the Dillo browser. > >Let me know if my site now formats correctly using Dillo. Well, it seems to... If only all sites responded as quickly... Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 26, 2003

Re: [Dillo-dev] libc dependency in 0.8.0pre (bug 487)

by Joerg Sonnenberger

On Tue, Aug 12, 2003 at 04:33:43PM -0400, David McKee wrote: > Folks, > Updated my CVS at home (Debian 3.0) to 0.8.0pre the other day, and I > like what I see. When I tried to do the same at work today (Redhat 6.2), I > had problems building. Dpid uses mkdtemp() which was introduced in glibc > 2.1.9. However, ./configure has no problems with my glibc 2.1.3. > > Submitted as bug 487 Could you try the attached patch and report success or failure? Esp. whether the included mkdtemp.c compiles clean and dpiddir.c gets the prototype. Thanks, Joerg

Aug. 26, 2003

On-line demonstration against software patents in Europe

by Frank de Lange

Hi'all, As you might know, the European Parliament will vote on software patents in the EU on the 1st of september 2003. I have added a notice to my patch page (http://www.geocities.com/ikbenfrank) about this. Maybe the main Dillo page can do the same? For more info on this issue, go to http://swpat.ffii.org Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 26, 2003

Frameset & lanlaw.org

by Frank de Lange

I just noticed that my current version of the tab+frame patch still has problems with sites like lamlaw.com, which put body content outside of frameset content. Even though this is against the spec, I've changed my current version of the patch so it displays the right (frameset) content for sites like this. BTW, lamlaw.com is really weird... The sequence of tags is html - head - frameset - /frameset - noframes - /head - body - /body - /noframes - /frameset - /html. So, it has frameset inside head (wrong), /head inside noframes, an extra /frameset, etc. The document claims to be html-4.0-transitional. Sure. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 26, 2003

New dpid patch

by Ferdi Franceschini

There is a new dpid patch for dillo-0.8-pre available from http://www.geocities.com/ferdif2003/ Plugins are now stored in a directory structure under libdir/dillo/dpi. You need to put dpi_dir=/usr/local/lib/dillo/dpi in ~/.dillo/dpidrc so that dpid can find the plugins, there should be no other entries in this file. Dpid now uses a .filter suffix in the plugin name to identify plugins which read and write to stdio (eg hello.filter.dpi). The following changes affect the CVS repository: Renamed dpiddir.[ch] to dpi_socket_dir.[ch] New files dpi_service.[ch] Cheers, Ferdi

Aug. 24, 2003

Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Henning Brauer

On Fri, Aug 22, 2003 at 11:30:47PM +0200, Melvin Hadasht wrote: > [Henning, you may be interested: the patch implements a --reload option] hmm, I have one more issue. dillo caches the images too well. try looking at any mrtg-generated page. the mrtg graphs are usually rebuilt every N minutes, where N=5 in my case. tho, now, at 3:20h, it still shows the images from ~ 1:30h. old data is not relevant in this case :-(

Aug. 24, 2003

Re: [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Henning Brauer

On Fri, Aug 22, 2003 at 11:30:47PM +0200, Melvin Hadasht wrote: > [Henning, you may be interested: the patch implements a --reload option] guys, you rock. it's just two days ago that I asked for that. It works great on OpenBSD/i386 and OpenBSD/sparc, all OpenBSD -current (3.4-beta atm). there are two small problems: -if you specify a small reload time, and by that time is over before the page is actually loaded -> coredump -on sparc, using the "void" input drivers for keyboard and mouse -> coredump that must be the visibility check? both issues are unfortunaltely pretty much showstoppers in my application :-((

Aug. 23, 2003

Re: Re: dillo / time-controlled reloads

by Jorge Arellano Cid

On Wed, 20 Aug 2003, Melvin Hadasht wrote: > > Hi Jorge & Melvin, > > Hi Henning & Jorge, > > (Is there a reason why this is not on the ML?) The only reason is that I pressed "reply" on a mail sent to my personal address. :-) > > > > > there's one bit missing. there is NO concept at all about time-based > > > > reloads. the meta refresh header would be reasonably close, but even > > > > better would be something like > > > > > > > > dillo -reload-every 60 http://blah/cgi-bin/blubb.cgi > > > > > > > > it should reload that URL every 60 seconds in that case no matter what. > > > > > > I think reloading it if upon display is also a good choice. I > > > mean, let the user browse other pages without reloading the > > > special URL, and reload it when it's back on display and the > > > timeout has been reached. > > I don't see why a browser should reload an URL if it is not currently viewed, but > I'm not a web expert. > > > > > I looked into adding a sigalrm handler an solving it this way, but > > > > then it turned out that is more complicated > > We can use the glib timeout functions for that. Yes, timeouts are simpler. > > Here is how I would implement the feature: > > - an internal Dillo function to mark/unmark a URL with > "reload periodically when viewed", A simple flag, maybe in the DilloUrl or in the cache entry. > it will also create a timeout > callback that will reload the URL if it is currently viewed. A periodiciy of 0 will > stop reloading. For that, I need to take a look on the browser history/cache, too. Don't worry, I can do that easily (I know pretty well the cache). I'd prefer you to focus on the dpi part. I mean, this dpi will end asking dillo to do the job. For instance: <dpi cmd='set_reload_URL' url='...' always='true'> > > - add a "-r, --reload-every" command line option that calls that function. > In fact, when I finish implementing the "(remote-)command" option, it would be > something like: "-c open(URL, refresh=60)" (that is if I finally decide that > supporting commands with more than one argument is worth the work). Hmmm, I think a simple cli switch to tell dillo to listen to the reloads.dpi is enough: dillo -reloads (or something like it) Then, the client communicates with the dpi socket. All this API is what needs to be designed. I'd appreciate you to work on this part. > > > The first duty is to define what is required for a good, > > > general purpose, kind of reloading dpi. The next one is to reduce > > > the features to a minimum working set, then implement! > > parameters: URL, periodicity (seconds), when (visible|always). This is a good start! For instance: fprintf(reloads_dpi_socket, "push http://localhost/someurl visible\n"); may be all the client program needs to know. Of course it could also be something like: fprintf(reloads_dpi_socket, "<dpi cmd='reloads' url='http://localhost/someurl' visible>" * The first example makes more clear that it goes trough reloads.dpi who parses it and then sends a dpip tag to dillo to request the job done. This may also be handy: "<dpi cmd='reloads' url='http://localhost/someurl' stop>" Note that it may be good to integrate the remote control functionality into the same dpi (and maybe call it remote.dpi?). This means adding a simple and useful API for help programs to use. For instance to let them push new URLs into the same instance of dillo (and not having to start a new dillo per requested page). Ex: The client app. asks the remote control dpi whether there's a running instance of dillo. YES -> send new to-be-pushed URL NO -> start "dillo -rc" (remote control) send new to-be-pushed URL Please polish along these lines. Cheers Jorge.-

Aug. 23, 2003

Re: [Dillo-dev] libc dependency in 0.8.0pre (bug 487)

by Jorge Arellano Cid

On Thu, 21 Aug 2003, Joerg Sonnenberger wrote: > On Wed, Aug 20, 2003 at 01:02:40PM -0400, Jorge Arellano Cid wrote: > [snip] > > Don't panic! > > > > The mkdtemp() issue needs to be solved. Thanks for reporting > > the problem. > > > > If configure has a way to deal with it, we'd need to find it > > out how. If not, just to think of something else (as implementing > > a custom function as you did, or see if there's a wrapper in glib > > etc.) > > > > I'm open to suggestions. > > Well, you could add a portable implementation e.g. from the *BSD libc > to dillo and a AC_CHECK_FUNCS to autoconf to conditionally include > that code. This is the way coreutils and other GNU packages work. > > I'll send you a working copy if you want. Of course! It'd be of great help. Cheers Jorge.-

Aug. 23, 2003

Re: [Dillo-dev] [PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Melvin Hadasht

Sorry, it looks the attachment was truncated. Here it is again, gzipped.

Aug. 22, 2003

[PATCH]: commands & auto-reload (was Re: dillo / time-controlled reloads)

by Melvin Hadasht

[Henning, you may be interested: the patch implements a --reload option] Hi, To implement the server and remote commands feature in Dillo, I'm going to go step by step. First, I'll implement commands to control Dillo at startup time, then I'll implement the server mode (where a Dillo instance can send the aforementioned commands to another Dillo instance). This is because I may try two differents approaches for the server mode part and because the commands are just a generalization of the command line options and can be implemented separately. Here is my first step: implement commands (like -c "open(URL)"). Patch is attached and is against CVS version. This is a generalization of the command line interface, and in fact, most of the old command line options are translated to a Dillo -c command. The advantage of such approach is that the commands can take optional parameters, like in: dillo -c "open(URL newwindow reload=10 fullwindow=yes)" which is approximately equivalent to: dillo -f -r 10 URL The commands are passed to Dillo as arguments to the -c, --command command line option: dillo -c "open(http://www.google.com)" 1. Command Syntax The argument to the -c command line option is of the form: CMD([STRING][ PARAM=VALUE]...) CMD: command name STRING: first and generic argument: in general a URL or yes|no PARAM: name of optional parameter VALUE: value of optional parameter. Currently, only booleans (yes|no) and integer values are supported. Boolean value can be omitted, in which case the value is considered to be "yes". Integer value cannot be omitted. Parameters are separated with a single space (no commas, to simplify the parser) Commands can be divided into two groups: actions commands, and options commands 2. Action Commands: They do some action: currently implemented commands: open(URL [ fullwindow[=yes|no]] [ reload=SECONDS] [ spamsafe[=yes|no]] [ xid=XID]) parameters speak for themselves. The "reload" parameter is a new feature: it allows to reload the URL each SECONDS seconds. The reload is halted when the page is not viewed and restarted if the user comes back to it. exit() exit the instance. This will be useful when passed to another Dillo instance running as a server. Other commands can be added. The framework is quite flexible and extensible. 3. Options Commands These commands set some options that will affect the following commands. For example, the parameters used in the open() command act only on that particular URL. But it can be useful to be able to set some defaults values. The currently implemented commands that influence these defaults are: fullwindow([yes|no]) reload(SECONDS) spamsafe([yes|no]) xid(XID) all open() commands that come after these options commands will have these default values, unless explicitly overridden. 4. Examples: dillo -c "open(http://www.google.com)" -c "open(file:///home/mhadasht/test.html newwindow spamsafe)" will open two windows: the first with google, and the second with the local file opened in spamsafe mode. dillo -c "reload(10)" -c "open(http://www.freshmeat.net)" -c "open(http://news.google.com newwindow)" will open 2 windows and will reload both URLs each 10s. This is equivalent to: dillo --reload 10 http://www.freshmeat.net http://news.google.com 5. Implementation details: 5.1. Command Line Parsing Command line options other than the help/version options are translated into a -c command and stored in a list. The list of commands is then executed (or, when the server mode will is implemented, sent to another Dillo instance) 5.2. Reload Function a URL can be set to auto-reload itself if it is currently viewed. For that, a new member (reload_interval [milliseconds]) to DilloUrl is added and set with a_Url_set_reload(). Each BrowserWindow can trigger a timer function if the viewed URL (Nav_open_url()) has a non-zero reload_interval. (As soon as another URL is viewed, or when the BrowserWindow is destroyed, the eventually pending timeout function is removed.) The timer is of the one-shot type: when it is triggered, it requests its BrowserWindow to reload the URL, then it stops itself. There is currently no UI to start/stop an auto-reload of a URL, but it is just a matter of using a_Url_set_reload() to a non-zero or a zero reload interval. 6. Remark The -c command and the normal command line options can be seen as two ways of doing the same thing: passing commands to Dillo. But the -c command is more generic and flexible and has a more powerful syntax. 7. Future Plans I plan to implement the server mode. After reading the dpi doc and source, I found that it cannot be used to make Dillo act as a plugin unless we accept to have only one Dillo server. This is because the socket names are tightly linked to the service name. Each service has only one socket. Whereas Dillo servers must have a distinct socket. If the we add another argument to the "start_plugin" cmd: <dpi cmd="start_plugin" msg="dillo" param="SERVER_NAME"> and if we modify the socket naming scheme, then it could be possible. I have to think about that again. But I may still use the communication infrastructure of the dpi. If I find this overkill, I'll revert to the straightforward approach I used before, that is, I won't use the dpi framework. OK, it's late, I hope I managed to be somewhat clear... Cheers. -- Melvin Hadasht

Aug. 22, 2003

finger plugin

by Andreas Schweitzer

Hi, as promised in a previous mail. Here is the still quite rough finger dpi intended for interested developers : http://www.hs.uni-hamburg.de/~stcd102/dillo/ http://www.hs.uni-hamburg.de/~stcd102/dillo/adpi-0.1.tar.gz It's configure.in is essentially dillo's configure.in :-) you could actually just put finger.c in the ./dpi/ subdirectory of dillo and adjust Makefile.am accordingly. but now I have an actual distribution :-) In the tarball is also what I call so far a library ... well, or at least the routines that have been re-used over and over. Lastly, there is also an experiment : a term plugin, which lets you call arbitrary programs from within dillo (read the source, though !) Installation: just copy the created .dpi files to ~/.dillo/ and edit ~/.dillo/dpidrc (as long as this file exists), then go to dpi:/finger/ If you want dillo to actually recognize the finger URL you will have to edit src/IO/Url.c and sr/capi.c. Search for the string "ftp" inside these two files and duplicate the relevant part for the finger protocol. Or await how dillo evolves :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 22, 2003

Re: [Dillo-dev] [PATCH] version 9 of tab+frame patch, frame support 'complete' (?)

by Andreas Schweitzer

Hi, > http://www.geocities.com/ikbenfrank/ > > More specifically for both versions: > > Dillo 0.8.0-pre (CVS) > ===================== > http://www.geocities.com/ikbenfrank/dillo-20030821-tabs.patch.gz > size: 66661 bytes (gzipped, as downloaded) > 281416 bytes (uncompressed) > md5sum: 6afb73d97d3db88c629726cef100f604 (gzipped, as downloaded) > c3b6ee3095d4b230a78cf836516e0023 (uncompressed) > > Dillo 0.7.3 (release) > ===================== > http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz > size: 93929 bytes (gzipped, as downloaded) > 399156 bytes (uncompressed) > md5sum: 0363c9ad9f94df9b1bca23e5489e5c5e (gzipped, as downloaded) > 8fca8c49a01cd6a6103661720eb8d60d (uncompressed) or again from my mirror. This time : http://www.hs.uni-hamburg.de/~stcd102/dillo/ Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 22, 2003

Re: [Dillo-dev] Some points about the dpi's

by Andreas Schweitzer

Hi, This e-mail account was cut off the net (literally ...) for 2 days, hence the delay in answering. > > > However, this brings me to my questions : > > > 1) will there be a generic URL->dpi mapping ? > > > I could imagine that dpid could actually handle that. > > Yes, but I think you mean URL->SERVICE, a dpi is just an implementation > > of a service. > > Ditto!. I understand. I think my original wording was not the best. But in the end, if the user can easily manage and configure URL->(via services)->dpi-program w/o compiling dillo, (s)he will be happy :-) > > > 1b) Either way, I am planing on writing a "catch-all-URL handler" > > > or "fallback handler" or "univeral URL handler" or the like. > > > It will give the user the possibility to start an external > > > program for handling certain URL's. > > > In fact, with my current dpi, this is quite easy > > > to do :-). > > OK, but I think we should hold off on 1 and 1b until I make the next > > dpid patch available. > > Me too. I'll put it on hold :-) > > > 3) About configuration (and I think I read comments about this > > > in the code), shouldn't there be only one config file ? > > > and not dpidrc and possibly different configs for all the dpis ? > > > maybe even merge cookiesrc with dillorc ? > > Yes, my next dpid patch gets rid of dpidrc. > > This is the only point I have some doubts. > > I've always thought that it is a good idea to keep separate > configuration files for dillo, and its dpis (and dpid). > > One file with a lengthy collection of not tightly-related > configuration directives sounds to me as low-cohesion and > high-coupling (I'm not sure about what are the words in english > for those technical terms. In spanish it is: cohesión y > acoplamiento). OTOH, for a user (like myself) who likes editing configuration files by hand, it is more convenient to have it in one place ... just an opinion though :-) ... but ... as you say : > The idea of having a preferences plugin providing an HTML GUI > for: dillo, dpid, and each dpi, is what I picture in the long > term. Something like: > > .-------. > | Dillo | Dpid | ftp | https | .... > | ---------------------------------------------------. ^^^^^ should be named "Plugin Management" or the like :-) this is of course also acceptable. Thinking a bit longer ... I think Mozilla is very much like that. You can configure Mozilla from within and it puts its config files scattered thorugh ~/.mozilla/ within a maze of directories. Every time I look inside that directory trying to fix things by hand, I am completely lost ... hence my desire for a one stop config file :-) > > > P.S.: I also have some ideas about improving the ftp plugin. There > > > is a pretty simple ftp library, > > Which one? http://nbpfaus.net/~pfau/ftplib/ seems to be relatively old, but the ftp protocol hasn't really changed that much :-) I *think* it is also used in some other applications. > > > and I think it does make sense to > > > actually log in an ftp server and stay logged in for all the operations. > > > (unlike wget which logs in and out for every file). This is not only > > > faster but helps with busy ftp sites, too ! > > Developing the ftp plugin is a high priority and your help here would be > > appreciated. > > Just as hinted in the comments inside ftp.c! > > Note that you only need to provide the HTML output for > FTP directories. and for files the user clicks on, like text files, images and even html files that exist in the ftp directory. > Downloads are to be bounced back to dillo for it > to forward them to the downloads plugin (that way the whole > downloading is centralized in a single place, stats can be > provided etc.). I have been thinking back and forth about that point. I think what I will end up doing is at least implementing the actual download from within the ftp plugin. Weather it will be included in the "official" one, or if I make 2 versions (a basic one and a fancy one), or whatever, remains to be seen. I guess one could also think about sending the data from the ftp plugin directly to the download plugin w/o relaying it via dillo. > I left some code inside ftp.c that shows a beautiful trick to > tell whether an FTP URL is a directory when using wget (it > probably can be re-used). I saw it, and this is indeed a problem. I checked the ftp rfc and there is no command that will tell me if something is a regular file or a directory. Also, after checking the ftp rfc and the url syntax rfc (rfc 1738) especially, section 3.2.4 and 3.2.5 makes the logging into ftp sites somewhat problematic. Essentially, it says, unless you actually travel an ftp site like within an interactive client, there is no way of telling how to get from ftp://site.com/foo/bar/ (which could be one link in an html page) to ftp://site.com/foo2/bar2/ (which could be a 2nd link in an html page) > The most time consuming task with this approach is to parse the > ASCII from the ftp server into HTML (easy in theory but you'll > find different layouts). In fact that's what I did with and > ancient FTP plugin I wrote. > > If the library you think of using writes HTML itself, great! If > not, just tell me to dig in for my old FTP code, and to send it > to you. I think either way it could be useful to look at :-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Aug. 22, 2003

[PATCH] version 9 of tab+frame patch, frame support 'complete' (?)

by Frank de Lange

Hi'all, The next version (9) of my tab patch is ready (see bottom of this message for download instructions). Frameset support is now almost complete, manual resize has been added, targeted link functionality has been improved, most frame-related attributes actually work, try it I'd say... Frameset (and iframe) support is enabled by default, it can be disabled using the configure option --enable-xhtml-dtd=strict. You can also use --enable-xhtml-dtd=transitional, which will give you iframe but no frameset support. The default option, --enable-xhtml-dtd=frameset, gives both iframe and frameset support. As usual, tab support can be disabled using --disable-tabs. Other new features (since the last version): - CTRL-U pops up the view source window - CTRL-B bookmarks the current page - CTRL-S pops up save page window New preferences frame_blank_in_tab=([NO]/YES): show frames with "_blank" target in new tab (instead of new window) (read the Browser_Frames.txt and Browser_Tabs.txt documents (in the doc/ directory) and the dillorc file for more info on tab- and frame-related preferences (after applying the patch, of course...)) Of course, the patch also fixes some bugs (and possibly introduces new ones). More on frame/iframe support ============================ Frameset support is based on a new widget (GtkFrameset) which implements <frameset> as specified in xhtml-dtd-frameset. This widget is not Dillo-specific, so it can in theory be used in any GTK program. It is a pure GTK widget, not rooted in Dw. It does not provide any special support for Dw-specific features (eg. the full-screen-off-button is not displayed in the widget). I might make a special version for Dillo after the GTK-version has been debugged sufficiently. What works: - loading (nested) framesets, displaying frames at their appropriate location and appropriate size, including margin width/height and scrolling. - loading (nested) iframes, displaying iframes at their appropriate location and with (mostly) appropriate size and alignment. - manual frame resize (row, column or both at the same time (drag border crossing - this does not work between nested framesets) - all frame-related menu options (in the popup menu). Frame menus can be accessed using the 'This Frame...' button in the popup menu, nested framesets have their own 'This Frameset...' menu. This way, Dillo allows you to limit actions to a subset of a framed document, eg. you can search for text in just one frame/iframe/frameset. Top-level menu options usually refer to the whole document (the frameset). An exception to this is the 'Jump To' option, which refers to the frame in which the menu was opened (question: should this contain the anchors for all frames?). Use the 'Show only this Frame' option in the Frame Options menu to get a full-page view of a frame. Same for 'Show only this Frameset'. What does not work yet: - the full_screen_off_button is not shown in frame documents. Use double-click instead to toggle the full screen setting... - the frameborder attribute works, but dw_gtk_scrolled_frame always draws a (focus) shadow around itself - even with the border size is set to 0. This makes it impossible to draw frames seamlessly. Tabs, Frames and browser bloat ============================== version: 0.8.0-pre patch: dillo-20030821-tabs.patch.gz unpatched: 285536 bytes patched, no tabs, no frames: 290444 bytes patched, with tabs, no frames: 298092 bytes patched, no tabs, with frames: 307116 bytes patched, with tabs, with frames: 314892 bytes version: 0.7.3 patch: dillo-0.7.3-20030821-tabs.patch.gz unpatched: 284416 bytes patched, no tabs, no frames: 289708 bytes patched, with tabs, no frames: 297324 bytes patched, no tabs, with frames: 305708 bytes patched, with tabs, with frames: 313452 bytes (gcc 3.2.2, binutils 2.13.90.0.18, CFLAGS "-Os") Judge for yourself if the features are worth their weight in bytes... Download instructions ===================== There are now two versions of the patch, one for Dillo 0.7.3 (release) and one for Dillo 0.8.0-pre (CVS). Make sure to download the correct version for the Dillo source you want to patch! If you patch the CVS source, do not forget to run ./autogen.sh after applying the patch. The CVS patch is made against 20030820 CVS, while the 0.7.3 patch is made against Dillo-0.7.3.tar.bz2 (the source tarball on the main Dillo website). Both versions of the patch can be downloaded from the usual (ad-happy, but...) Geocities site: http://www.geocities.com/ikbenfrank/ More specifically for both versions: Dillo 0.8.0-pre (CVS) ===================== http://www.geocities.com/ikbenfrank/dillo-20030821-tabs.patch.gz size: 66661 bytes (gzipped, as downloaded) 281416 bytes (uncompressed) md5sum: 6afb73d97d3db88c629726cef100f604 (gzipped, as downloaded) c3b6ee3095d4b230a78cf836516e0023 (uncompressed) Dillo 0.7.3 (release) ===================== http://www.geocities.com/ikbenfrank/dillo-0.7.3-20030821-tabs.patch.gz size: 93929 bytes (gzipped, as downloaded) 399156 bytes (uncompressed) md5sum: 0363c9ad9f94df9b1bca23e5489e5c5e (gzipped, as downloaded) 8fca8c49a01cd6a6103661720eb8d60d (uncompressed) As always, check the site for the most recent version: That's all for now, Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Aug. 21, 2003