- Dillo-dev - lists.mailman3.com

Re: spam-safe and basic auth

by Jorge Arellano Cid

On Wed, 7 Jan 2004, Francis Daly wrote: > On Fri, Dec 19, 2003 at 05:45:50PM +0000, Francis Daly wrote: > > On Fri, Dec 12, 2003 at 06:32:54PM -0300, Jorge Arellano Cid wrote: > > > [...] > > > On to another topic, have you had a look at the basic > > > authentication patch by Madis and Tor? > > I've spent a few evenings on this now, and have through the mzz auth > patch, and tried implementing something similar myself. I don't see how > mzz avoids the "redirect loop" problem which it seems to generate. I got > the full mzz-wtab.diff file which applies cleanly to the 0.7.3 code, and > it compiled and ran okay, but failed to even ask for authentication when > I tried it against a 401 page. And it gave the "redirect loop" warning. > > So "doesn't work for me" is the best I can report about it for now, > unfortunately. I'm moving this thread to dillo-dev, just in case Madis or somebody else is interested in helping the development of this feature. > I believe that a 401-handler could be broadly analogous to the 30x > handler, Cache_redirect(). Within Cache_parse_header(), I set a new > value CA_Unauthorized for entry->Flags for a 401 response; and then > within Cache_process_queue(), if that value is set, call the new > Cache_reload_auth() just after where Cache_redirect() is called. Interesting idea. > For adding the Authorization: header, I just edit Http_query to > include an appropriate header if URL_RealmAccess is set (it's not used > elsewhere, and looks like it was intended for 401 usage); and within > Cache_reload_auth(), I set URL_RealmAccess and URL_E2EReload and call > a_Nav_push(). It seems to work fine for authentication pages with no > images, and for authentication pages with images which don't require > authentication. But images that *do* require authentication cause > breakage. Yes, a_Nav_push is for root urls (WEB_RootUrl). > The difficulty is in how to handle non-WEB_RootUrl requests -- I > was following Cache_redirect() for inspiration, and it appears that > Cache_redirect() just ignores them, and I don't see a clean way to > manage them. > > Why are sub entity redirections ignored? Is it because of > security/privacy concerns, or because it was difficult to do them > right? Because the only sub-entity type that dillo handles is image, and near 99% of image redirections is advertising, so given the state of the web, it's a feature! What could be done: my first thought is to check whether an URL (root or not) requires authentication (a flag). If it requires it and we have the auth cached, load it, if not, ignore. > If the former, then whatever the original plan was (using > a_Cache_open_url() or similar) would be worth learning. If the latter, > then unfortunately, in order to handle authentication it's going to have > to be addressed some time :-( Unfortunately I have little time to devote to this design, as I'm given priority to pushing the next release, that is, stabilizing the dpi framework (hopefully done), making the HTML warnings go into a window (not stdout), and adding an HTML error counter together with a "combat mode" parsing feature (a way to try to render pages full of errors in a simplistic but viewable way). Ah, and also giving a check to Keyb-nav-4 if it comes my way... > As I see it, the ideal situation would be that when Cache_parse_header() > finds the 401, it would be useful to check whether we have suitable > authentication credentials, and if so, initiate a new http request which > will feed into (and replace) the same "entry". Doing that directly, > though, probably cuts across too many layers of abstraction. Funny, quite the same I described above! No not that many layers. As you noticed, it can be viewed as a redirection (that asks for credentials on root pages.). It should be possible to implement it this way without breaking the current model. > (I did all my testing on the 0.7.3 codebase; I've just had a look at > CVS and it doesn't appear significantly different.) > > I'm quite happy to keep working on getting authentication working > (Basic, initially, but with the possibility of adding Digest or > anything else in the future) -- if you have any known-dead-ends from > implementing Cache_redirect, or ideas of "safe" ways to intercept the > cache handling, I'd appreciate hearing them. Try to prototype the idea above. It should work. Sorry for not being of more help by now. Cheers Jorge.-

Jan. 7, 2004

Re: [Dillo-dev] Re: dillo configuration on AIX

by Andreas Schweitzer

Hi, > > I have a question whichmight be a short configuration question. I'm > > trying to build dillo 0.7.3 on AIX 4.2.1 using gcc. I already installed > > and tested gtk and pth. FWIW, I used to run dillo 0.6.6 on AIX 4.3.2 quite extensively. > Pth is different from pthread (POSIX threads). I did not install pth either. > > when configuring dillo it says it can't find pthreads. In fact it tries > > -pthread. I'm sure that AIX has native threads, > http://home.t-online.de/home/Andreas.Steinmetz/unix/pthreads.html The odd thing is contrary to the above explanation, it worked for me with gcc and -pthread (and not -pthreads). I'm not quite sure which version of gcc I used back then. But gcc can (and should be) configured to do the right thing when called with -pthread. Using xlc instead of gcc however, was quite a bit of a mess ... I got it compiled somehow :-) ... but would need to look up the details. I beleive the explanations given in the web page refer to xlc. Now, all that does not really help the original poster :-) ... what would help is some more detailed output, maybe some portions of config.log and to some degree the output of gcc -v lslpp -l | egrep -i 'thread|xlc|gcc' and that possibly on-list ;-) Cheers, Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Jan. 7, 2004

Re: dillo configuration on AIX

by Jorge Arellano Cid

On Wed, 7 Jan 2004, Riccardo wrote: > Hello, Hi! > I have a question whichmight be a short configuration question. I'm > trying to build dillo 0.7.3 on AIX 4.2.1 using gcc. I already installed > and tested gtk and pth. Pth is different from pthread (POSIX threads). > > when configuring dillo it says it can't find pthreads. In fact it tries > -pthread. I'm sure that AIX has native threads, Yes, but our configure doesn't detect them yet. Although this should not be hard to do: Get the detected target system type string from the configure script. That is, near the third line of output, it says something like: checking target system type... i586-pc-linux-gnu Then add that option to "configure.in" inside the case statement for pthreads. Something like: [...] case $target in *-*-linux*|*-*-solaris*) AC_CHECK_LIB(pthread, pthread_create) ;; + *-*-aix*) + AC_CHECK_LIB(pthreads, pthread_create) + ;; [...] Then follow the directives at: http://home.t-online.de/home/Andreas.Steinmetz/unix/pthreads.html That is basically adding a call to pthread_init() somewhere in main() in dillo.c. Run autoreconf or autogen.sh, configure, make, tweak and send some feedback! :-) > but in any case -lpth > should be used to use libpth. I'm not an expert with AIX development, > I'm using version 4.2.1. > Can dillo be linked against lpth? other projects usually have a > configure option top select the threading model. Against Pth, no. Cheers Jorge.-

Jan. 7, 2004

MINISTRY OF MINES AND NATURAL RESOURCES,SIERRA-LEONE

by BRIGEDIER EVANS GIWA

Dear sir, I PRESUME THIS LETTER WILL NOT BE A SURPRISE TO YOU. I am Brigedier Evans Giwa, a soldier by profession, formerly a director with the ministry of Mines and Natural Resources in SIERRA-LEONE before the out - break of the civil war in Sierra-Leone. When I was the director with that ministry, I acted as a link between foreign buyers of Diamonds and the Sierra-Leonian government, but ae a result of the civil war, I diverted the sum of US$36.5 million meant for Sierra-Leone government to a security company in Europe. All I need from you.: (1)Coming up with a viable business that we can invest this fund in. (2)To act as the beneficiary of the said money, as I cannot act in this capacity as I`m still directly or indirect involved in the peace negotiations going on in my country now. (3)To clear the money with the security company in Europe and lodge the money into an account we shall both run. After acknowledging this letter,and indicating your interest and willingness in my proposals, we shall arrange for a meeting in Europe to discuss your areas of interest and investment. As a christain, I will like to invest 20%of the money to help the less priviledged in the society.You willget 25% of the total money for your assistance and 5% will be set aside to offset whatever expenses incurred during the duratation of this transaction. Do kindly contact me through the below email address for further discussion and forsecurity reasons,this business remains confidential. Your Sincerly Brigedier. Evans Giwa giwa(a)consultant.com or egiwa(a)lycos.com

Jan. 7, 2004

Improved stability patch for dpi framework!

by Jorge Arellano Cid

Hi Ferdi, (et all) After spending the last weeks hunting for some bugs in the dpi framework deeply, I've succeeded to track them down, and finally, to fix them! From time to time there were multiple dpid instances, this was due to a race condition while waiting for dpid to be "online"; if the process took around a second, dillo could end launching multiple instances of the daemon (I left a commented sleep in the dpid code that served to reliably reproduce it). Another nasty bug was that sometimes dillo crash-locked when requesting a dpi service, for instance: launch dillo -> ask for bm -> kill dpid -> ask for bm -> crash ...this was because of FD inheritance! The bm dpi survived, and kept its parent's FD open, so the connect-test succeeded but there was no server to answer. This couple was really hard to track. As a by-product, lsof showed a FD leak in dpi.c (one per dpi request) and another for dillorc. All of these bugs are fixed in CVS. The good news is that this is a big step towards 0.8.0 release because the stabilization of the dpi-framework is a necessity. There is still at least one pending thing to polish, but it is not a big problem to live with it in 0.8.0 because it causes little harm. This is: if dpid crashes (or is killed), the dpi servers will survive, but the new dpid will launch new processes for them (the old ones will last until their bore-time is reached). No crash, no locks. My first idea was to make a connection-test to dpi servers from dpid at start time, but unfortunately, the parent-child relationship would be lost for the second dpid, so we have to find another way to tell dpid that a dpi-server has finished. The "srs" may be used, although it may be a bit tricky to do when the dpi server has crashed; anyway, the connection test from dpid can detect the crash and bypass the old server with a new one. Cheers Jorge.-

Jan. 5, 2004

Re: dillo 0.73 not compiling on slackware 3.9 ( libc5 )

by Jorge Arellano Cid

On Sat, 3 Jan 2004, matti christensen wrote: > Hello ! Hi! > > In Your README You asked to email comments on compiling Dillo on libc5, > and here's some of mine. Good, the first in a long time. > - slackware 3.9 is the last one with libc5 ( glibc 2.0.7pre6 ) and ( gcc > 2.7.23 ) No problem, I use slackware, and have deployed dillo on it in much earlier versions. > - kernel is the latest of 2.0 -series ( 2.0.39 ) which i have compiled > according to attached config and dmesg > > - i also compiled following in for Dillo ;o) > > --- XFree 3.3.6 > --- glib 1.2.9 > --- gtk+ 1.2.9 > --- jpeg-6b > --- libpng 1.2.5 > --- libtiff 3.5.7 > --- zlib 1.1.4 > > - when i try to make Dillo after making the changes to dns.c as You kindly > adviced, compiling stops to src/IO/mime.c saying "mime.c:34: parse error > before `static'" OK. It seems to be the G_GNUC_UNUSED directive. Remove lines 31 to 40 in mime.c. It should stop complaining about mime.c. If this is true, as I do expect, do the same with html.c and IO/Url.c. Please report me how it goes to fix it in current CVS. Cheers Jorge.-

Jan. 4, 2004

ASK FOR HELP:"view source" and edit data to send.

by FUN TOES

Some websites can't be visited by dillo.So I think of writing a patch to view the raw data(including header) from the server and send the raw data modified manually to the server. It is very easy to edit the data to send by modifying the function Http_send_query().But I do not know how to get the raw http data from the server.What is the function that I need read deeply? And I do not think IO_read()is a good selection.The function send raw data to html parse maybe a good selection.But I am a newbie,and I have difficuty in finding the correct function. Would you like help me find it?Appreciation for your help. -- ___________________________________________________ Check out the latest SMS services @ http://www.operamail.com, which allows you to send SMS through your mailbox. Powered by Outblaze

Jan. 2, 2004

Best wishes for year 2004

by Jorge Arellano Cid

Hi There, It's early in the morning here in Chile, and I know that in Europe the clock is around 4 to 6 hours ahead, hopefully still in time to send my greetings and best wishes to all the people scattered around the world that participate of dillo-dev. Somewhere inside this december the Dillo project completed four years of existence and continued development. Please excuse me for not displaying a birthday cake picture at the home page; I didn't have the time, but the will to share and celebrate the event still remains! I spent the last months of this year making the arrangements to be able to keep working on dillo the 2004, and hopefully more... It seems that these efforts will flourish and let me work through this new year with renewed energies and hope: let 2004 be a great year for the Dillo project! Cheers & Best wishes to all! Jorge.-

Dec. 31, 2003

Re: [Dillo-dev] VRML support in Dillo

by Thorben Thuermer

On Sun, 28 Dec 2003 13:37:19 EST Rich3800(a)aol.com wrote: > Does Dillo support display of VRML images? Dillo does currently not support renderer-type plugins that would be needed for inline display of VRML/SVG/flash/java/... content (unless hardcoded into the renderer). this is planned for a to-be-developed dpi2 plugin system as mentioned in: http://www.dillo.org/dpi1.html -

Dec. 30, 2003

VRML support in Dillo

by Rich3800＠aol.com

Does Dillo support display of VRML images?

Dec. 28, 2003

WINNING NOTIFICATION/FINAL NOTICE

by MR. TOM VANAD

RABOAS INTERNATIONAL LOTTERY NTERNATIONAL PROMOTION/PRIZE AWARD DEPT. HOLLAND REFF: OGS/7316786098/03 BATCH: 14/055/IPD /NL WINNING NOTIFICATION/FINAL NOTICE We are pleased to inform you of the result of the RABOAS Lottery International programs held on the 27st of Decbmer 2003. Your e-mail address attached to ticket number 4411465886-629 with serial number 3772-99 drew lucky numbers 7-14-17-23-31-44 which consequently won in the 2nd category, you have therefore been approved for a lump sum pay out of US$100,000.(One Hundred Thousand Dollars)CONGRATULATIONS!!! Due to mix up of some numbers and names, we ask that you keep your winning information confidential untill your claims has been processed and your money remitted into your accaunt. This is part of our security protocol to avoid double claiming and unwarranted abuse of this program by some participants All participants were selected through a computer ballot system drawn from over 100,000 company and 50,000,000 individual email addresses and names from all over the world. This promotional program take place every three years. We hope with part of your winning you will take part in our end of year 50 million Dollars international lottery. To file for your claim,please contact our fiduciary agent MR.DALE MELLOR, E.U.INTERNATIONAL B.V E.mail:dalemell@netscape.net TEL:31 641 684 576 Remember, all winning must be claimed not later than 11 th of January 2004. After this date all unclaimed funds will be included in the next take Please note in order to avoid unnecessary delays and complications please remember to quote your reference number and batch numbers in all correspondence. Furthermore,should there be any change of address do inform our agent as soon as possible.Congratulations once more! from our members of staff and thank you for being part of our promotional program. Note: Anybody under the age of 18 is automatically disqualified. Sincerely yours, MR. TOM VANAD (Winning Co-ordinator)

Dec. 27, 2003

Re: spam-safe and basic auth

by Jorge Arellano Cid

Hi Francis, > [...] > > I was just looking for the spam-safe image blocking patch and > > couldn't find it. Would you mind resending it to me? > > No problem at all. It's included below, updated for current CVS (the > earlier version applied cleanly with a 126-line offset). > > The same caveats as before apply -- there is no "right" answer, so the > choice between omitting the image entirely, faking a submit button, > including a default image, or something else, is pretty arbitrary. > > Faking a submit button is what I went for here, taking inspiration > from http://www.htmlhelp.com/reference/html40/forms/input.html#image > and http://ppewww.ph.gla.ac.uk/~flavell/alt/type-image.html > > If you prefer a different option, I'm sure you're well capable of > coding it ;-) I took the text-submit-button approach (it will also serve for when browsing in "text mode" with Dillo). It took me some time to review it (looks simple but it's not!), I also had to fix a bug... Cheers Jorge.- PS: further testing is welcome! ;)

Dec. 26, 2003

Re: [Dillo-dev] Cache expire header...

by Tom Lisjac

> > With this header, Dillo's stdout messages reported "bad clocks"... so I > > tried sending the same date for Expires and Last-Modified. Dillo's > > stdout came back with: "Forcing min expire 60 on >the url< instead 0". > > What does that mean? > > > you're using my patch? I'm using the cvs version of dillo (0.8.0-pre) that I compiled a few days ago. I wanted to test with a generic Dillo so I didn't apply any patches. > Bad clocks means that the expiration time seems to be in history > (compared to Last-Modified, when this header is present) for dillo at the > time when the header was received, and is so more than 1000 seconds. > These expirations are ignored, because many sites send these for all > their content and it would otherwise cause dillo to always reload > everything on these sites. For you're example - 1998 is very long history. That makes sense... thanks for the explanation. > Forcing min expire 60 - this is configurable using min_page_expire option > in dillorc. When this config option is non-zero, dillo will set expiration > times below this value (in seconds) to the config option value. It was > introduced to give better speed with stupid news sites. I appreciate the performance goal but I'm also concerned that the displayed page reflects the content that the site wants to deliver. For example after a user post, collaborative pages need to display fresh content immediately. > > I really need the content of certain pages to expire immediately when > > viewed. Any suggestions for the correct header parameters would be > > greatly appreciated. > > 1. following dillorc options make it most agressivily reload everything: > query_expire_time="0" > min_page_expire="0" > min_image_expire="0" Noted for client side use. > 2. Use Cache-Control header: > > Cache-Control: no-cache This fixed standard post operations... thank you! I had been sending: header("Cache-Control: no-cache, must-revalidate"); ... but I guess the second parameter was causing a problem. The cache is still a problem on post operations followed by a 302 redirect. After posting a user note to an existing page, my application redirects back to the updated main page+notes. With Dillo the page is displayed from cache and doesn't show the note the user just added. Hitting refresh shows the updated page... but having to do this isn't desireable behavior for a collaborative site. I don't have the version of the app posted that looks nice with Dillo yet but adding a note to the following test page shows the problem. http://theseus.sourceforge.net/ewsbeta/index.php?wiki=DilloTest Thanks for the reply! -Tom

Dec. 24, 2003

Re: [Dillo-dev] Cache expire header...

by Madis Janson

On Sun, 14 Dec 2003, Tom Lisjac wrote: > I've written a small, Dillo friendly wiki/cms system in php that I'm > hoping to release in a few weeks. During testing (today's cvs), I found > that Dillo's cache wasn't expiring the dynamic pages. Here's the header > I was initially using to disable client caching: > > header("Expires: Sun, 22 Mar 1998 20:00:00 GMT"); > header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); > header("Pragma: no-cache"); > header("Cache-Control: post-check=0, pre-check=0"); > > With this header, Dillo's stdout messages reported "bad clocks"... so I > tried sending the same date for Expires and Last-Modified. Dillo's > stdout came back with: "Forcing min expire 60 on >the url< instead 0". > What does that mean? > you're using my patch? (it remainds, that i should try to clean up the cache patch for Jorge... oh well it's not easy work, i'm afraid...) Bad clocks means that the expiration time seems to be in history (compared to Last-Modified, when this header is present) for dillo at the time when the header was received, and is so more than 1000 seconds. These expirations are ignored, because many sites send these for all their content and it would otherwise cause dillo to always reload everything on these sites. For you're example - 1998 is very long history. Forcing min expire 60 - this is configurable using min_page_expire option in dillorc. When this config option is non-zero, dillo will set expiration times below this value (in seconds) to the config option value. It was introduced to give better speed with stupid news sites. > I really need the content of certain pages to expire immediately when > viewed. Any suggestions for the correct header parameters would be > greatly appreciated. 1. following dillorc options make it most agressivily reload everything: query_expire_time="0" min_page_expire="0" min_image_expire="0" 2. Use Cache-Control header: Cache-Control: no-cache

Dec. 21, 2003

Is something wrong with the cvs repository?

by Matthias Pfeifer

I think the cvs version is currently not working. i do cd src cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo login cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo cd dillo automake -a autoconf (without outputs) and then ./configure gives ./configure: line 650: syntax error near unexpected toke `AM_INIT_AUTOMAKE(dillo,' ./configure: line 650: `AM_INIT_AUTOMAKE(dillo,0.8.0-pre)' - Matthias Pfeifer, Aachen/Germany

Dec. 19, 2003

ChessBrain: World Record!

by The ChessBrain Network

The ChessBrain Network T o be removed from our mailing list, send an email to support(a)chessbrain.net

Dec. 19, 2003

Re: [Dillo-dev] sending referer

by Andreas Tolfsen

Daniel wrote: >Hi Jan, > >On Fri, Dec 19, 2003 at 01:18:40PM +0100, Jan Stary wrote: > > >>why does Dillo not send the referer header? Without it, I >>cannot use the http://validator.w3.org/check/referer link, >>as appearing on the bottom of my pages. >> >> >referer == evil > >>his is the only problem which keeps mozilla on my machine. >> >> >It's not a problem it's a feature. And the reason I use Dillo not >Mozilla *g* > >Daniel > > Well, personally, I think there should be an option for turning it on and off maybe? Wouldn't that please everybody?

Dec. 19, 2003

Re: [Dillo-dev] sending referer

by Daniel

Hi Jan, On Fri, Dec 19, 2003 at 01:18:40PM +0100, Jan Stary wrote: > why does Dillo not send the referer header? Without it, I > cannot use the http://validator.w3.org/check/referer link, > as appearing on the bottom of my pages. referer == evil > This is the only problem which keeps mozilla on my machine. It's not a problem it's a feature. And the reason I use Dillo not Mozilla *g* Daniel -- Wenn man bedenkt, dass die Leute vor 150 Jahren ihre E-Mails noch bei Kerzenlicht geschrieben haben... [Marianne Kestler, de.admin.net-abuse.mail, 6.5.2000]

Dec. 19, 2003

Re: [Dillo-dev] [PATCH] Version 15 of tab/frame/kbnav/etc patch, now with keywords and more...

by Sebastian Geerken

On Sun, Nov 23, Frank de Lange wrote: > Paul Pelzl wrote: > >I've got a couple of early bugs to report: > > > >1) when using kbnav to move from a link to an entry box in a form, the > > most recently selected link is not properly deselected. Example: > > google.com. > > > > > If this is what I think it is, it actually seems to be a widget bug. > I've discussed this with Sebastian before. Relevant part of discussion > plus link to bug description: This is bug #202, and has been fixed now in CVS (positive result also with Frank's keyboard navigation patch). This fix is a bit difficult to test, so I've committed it after relatively short testing time on my side, and ask the list for any experience (bugs, CPU load etc). Sebastian

Dec. 19, 2003

sending referer

by Jan Stary

Hello, why does Dillo not send the referer header? Without it, I cannot use the http://validator.w3.org/check/referer link, as appearing on the bottom of my pages. This is the only problem which keeps mozilla on my machine. Thank you Jan

Dec. 19, 2003

Re: [Dillo-dev] Automake and dynamic linking

by Jorge Arellano Cid

On Wed, 17 Dec 2003, Jorgen Viksell wrote: > Hi, > > I've actually got a patch for this. It's just that it's part of a larger > patch to clean up configure.in. > I can split these changes out and send it to you in a couple of days. > > Jörgen Excellent! Greetings Jorge.-

Dec. 18, 2003

Re: [Dillo-dev] Automake and dynamic linking

by Jorgen Viksell

Hi, I've actually got a patch for this. It's just that it's part of a larger patch to clean up configure.in. I can split these changes out and send it to you in a couple of days. Jörgen ons 2003-12-17 klockan 20.58 skrev Jorge Arellano Cid: > Hi guys, > > I just noticed that out automake process ends linking all the > libraries required by dillo to dpid and every dpi! > > For instance: > > $ldd dpid > libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) > libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) > libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) > libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) > libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) > libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) > libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) > libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) > libdl.so.2 => /lib/libdl.so.2 (0x40239000) > libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) > libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) > libm.so.6 => /lib/libm.so.6 (0x40311000) > libc.so.6 => /lib/libc.so.6 (0x40334000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > > Wow! > > And the kernel reports: > > VmSize: 4684 kB > VmLck: 0 kB > VmRSS: 1160 kB > VmData: 304 kB > VmStk: 16 kB > VmExe: 24 kB > VmLib: 4208 kB > > This means that resident dpis (servers) can end wasting virtual > memory after dillo exits by retaining unused libs in VmLib. > > If someone here can make a patch for this problem, it'd be a > great time saver. Please? :-) > > > Cheers > Jorge.-

Dec. 17, 2003

Automake and dynamic linking

by Jorge Arellano Cid

Hi guys, I just noticed that out automake process ends linking all the libraries required by dillo to dpid and every dpi! For instance: $ldd dpid libpthread.so.0 => /lib/libpthread.so.0 (0x4001f000) libpng.so.3 => /usr/lib/libpng.so.3 (0x40071000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x4009b000) libz.so.1 => /usr/lib/libz.so.1 (0x400b8000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400c5000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x401e3000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40214000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40218000) libdl.so.2 => /lib/libdl.so.2 (0x40239000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4023c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4024a000) libm.so.6 => /lib/libm.so.6 (0x40311000) libc.so.6 => /lib/libc.so.6 (0x40334000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Wow! And the kernel reports: VmSize: 4684 kB VmLck: 0 kB VmRSS: 1160 kB VmData: 304 kB VmStk: 16 kB VmExe: 24 kB VmLib: 4208 kB This means that resident dpis (servers) can end wasting virtual memory after dillo exits by retaining unused libs in VmLib. If someone here can make a patch for this problem, it'd be a great time saver. Please? :-) Cheers Jorge.-

Dec. 17, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Jorge Arellano Cid

On Fri, 5 Dec 2003, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Dec 04, 2003 at 10:43:34AM -0300, Jorge Arellano Cid wrote: > > > > I could not yet get any reproducible results from profiling, > > > > !? > > > > Doesn't it show any function usage-ratio/run-time change? > > > > Ok, I redid the profiling on my slower Linux box with utilities.html. > > Html_cleanup_tag is called more often in cvs version (16742 vs. 10749) and > seems quite a bit slower than in 0.7.3. > > See gprof output below. > [...] This is one of those weird situations that computer programming has. If we had been working for a year to make rendering three times faster, and succeeded on the effort, it'd be regarded as a substantial achievement. Actually we had been working for four years to get every bit of speed we can into dillo, and a library upgrade that makes dillo three times slower, is unacceptable. Now, all of a sudden, rendering went three times slower because of some unknown reasons, after applying a simple patch. Profiling revealed that Html_cleanup_tag() was to blame, _but_ that function is identical in both versions! Who's to blame? The compiler, the CPU cache, the pipeline, memory handling, page faults, ... All of them? I made a guess based on our C code, rearranged it and voila!, the former performance is back. Weird world, isn't it? What should have a minor impact on performance (a few CPU cycles overhead) exceeded 0(n) algorithms by a factor of two. :-o It seems that detailed knowledge of the underlying layers plays a significant role in the overall performance of a program. This may seem obvious, but remember that the academy teachs the opposite. Caveat emptor! Patch commited. Cheers Jorge.-

Dec. 17, 2003

Re: [Dillo-dev] Re: BUG#494

by Madis Janson

On Sun, 14 Dec 2003, Trent Jarvi wrote: > > Some *BSD don't provide a reentrant gethostbyname: > > > > <q source='manpage of a BSD'> > > BUGS > > These functions use static data storage; if the data is needed for future > > use, it should be copied before any subsequent calls overwrite it. Only > > the Internet address format is currently understood. > > </q> > > > > The only one I know that doesn't work is openBSD >= 3.3. > > (produces random lookups) > > > > Does anyone know the situation better? > > It is for disabling threaded dns lookups at configure time. > > Would gethostbyname_r() solve this? > I had getaddrinfo patch, but it was done, when dillo had no ipv6 support and so it cannot be directly applied now. getaddrinfo has some advantages, but i do not know how well it is supported on different unix flavors. Although getaddrinfo is in posix standard, when gethostbyname_r imho is not. The dillo way of using gethostbyname as a re-entrable function surely isn't standard eighter, even when glibc2 supports it.

Dec. 15, 2003

Cache expire header...

by Tom Lisjac

Hi All! I've written a small, Dillo friendly wiki/cms system in php that I'm hoping to release in a few weeks. During testing (today's cvs), I found that Dillo's cache wasn't expiring the dynamic pages. Here's the header I was initially using to disable client caching: header("Expires: Sun, 22 Mar 1998 20:00:00 GMT"); header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); header("Pragma: no-cache"); header("Cache-Control: post-check=0, pre-check=0"); With this header, Dillo's stdout messages reported "bad clocks"... so I tried sending the same date for Expires and Last-Modified. Dillo's stdout came back with: "Forcing min expire 60 on >the url< instead 0". What does that mean? I really need the content of certain pages to expire immediately when viewed. Any suggestions for the correct header parameters would be greatly appreciated. Thanks! -Tom

Dec. 14, 2003

Re: [Dillo-dev] Re: BUG#494

by Trent Jarvi

> > > Hi, > > Some *BSD don't provide a reentrant gethostbyname: > > <q source='manpage of a BSD'> > BUGS > These functions use static data storage; if the data is needed for future > use, it should be copied before any subsequent calls overwrite it. Only > the Internet address format is currently understood. > </q> > > The only one I know that doesn't work is openBSD >= 3.3. > (produces random lookups) > > Does anyone know the situation better? > It is for disabling threaded dns lookups at configure time. > > Would gethostbyname_r() solve this? -- Trent Jarvi taj(a)www.linux.org.uk

Dec. 14, 2003

*BSD and gethostbyname

by Jorge Arellano Cid

Hi, Some *BSD don't provide a reentrant gethostbyname: <q source='manpage of a BSD'> BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Only the Internet address format is currently understood. </q> The only one I know that doesn't work is openBSD >= 3.3. (produces random lookups) Does anyone know the situation better? It is for disabling threaded dns lookups at configure time. Cheers Jorge.- PS: That's it. A thread follows with other minutiae... ---------- Forwarded message ---------- Date: Sat, 13 Dec 2003 14:26:58 +0100 (MET) From: Anders Gavare <md1gavan(a)mdstud.chalmers.se> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: [Dillo-dev] Re: BUG#494 On Sat, 13 Dec 2003, Jorge Arellano Cid wrote: > On Sat, 13 Dec 2003, Anders Gavare wrote: > > How typical: now I found this already mentioned in dillo's README file. > > Sorry to have bothered you. :-) Still, this is something that should > > be detected and taken care of by the configure script... > > Thanks for the info. > > Can you send me a patch for configure.in? Unfortunately I don't think I'm familiar enough with neither Dillo nor the configure system to add such a functionality. It took several days for me to track down the widget bug (#494), and several hours of testing to figure out this gethostbyname() bug. > Or at least the contents of the detected $target variable on > your machine (an extra line with "echo $target" after > AC_CANONICAL_SYSTEM will tell). sparc64-unknown-openbsd3.3 The same problem should exist in other BSDs as well, but I've not actually seen the symptoms. The manpages of FreeBSD 4.5 and NetBSD-current (after 1.6.1) have the following in their gethostbyname(3) manpages: BUGS These functions use static data storage; if the data is needed for future use, it should be copied before any subsequent calls overwrite it. Only the Internet address format is currently understood. Imho, if Dillo aims for platform independance, which is one of the things I like best about Dillo, this feature (multithreaded DNS lookups) would be better off disabled _unless_ the underlying platform explicitly allows it. Not the other way around. That's my opinion, anyway. Anders

Dec. 13, 2003

Re: [Dillo-dev] Re: BUG#494

by Anders Gavare

Replying to myself... On Sat, 13 Dec 2003, Anders Gavare wrote: > Dillo's dns lookups randomly stop working. gethostbyname() isn't > reentrant on OpenBSD 3.3/sparc64. (I believe that's what causing the > random bugs.) Undefining G_DNS_THREADED in src/dns.c solved the > symptoms here. How typical: now I found this already mentioned in dillo's README file. Sorry to have bothered you. :-) Still, this is something that should be detected and taken care of by the configure script... Anders

Dec. 13, 2003

Re: [Dillo-dev] Re: BUG#494

by Anders Gavare

On Wed, 10 Dec 2003, Jorge Arellano Cid wrote: > On Wed, 10 Dec 2003, Anders Gavare wrote: ... > > entry from the bug database. I've not had any other problems on sparc64 > > yet, except possible some random lock-ups. The version in CVS as of > > 07:00 this morning seems to work just fine (that is, it still has the > > random lock-ups but the output looks nice). > > lock-ups... Can you decribe them some more, or better, run > dillo under gdb to find out where or why it locks (I haven't > seen that bug ever). Dillo's dns lookups randomly stop working. gethostbyname() isn't reentrant on OpenBSD 3.3/sparc64. (I believe that's what causing the random bugs.) Undefining G_DNS_THREADED in src/dns.c solved the symptoms here. > PS: Are you on dillo-dev? No. Anders

Dec. 13, 2003

Re: [Dillo-dev] statically linked dillo

by Madis Janson

On Fri, 12 Dec 2003, Jorge Arellano Cid wrote: > > Hi, > > ---------- Forwarded message ---------- > Date: Thu, 11 Dec 2003 23:30:05 +0000 > From: Victor M. <voremo(a)safe-mail.net> > To: jcid(a)softhome.net > Subject: dillo > > Can dillo be compiled into a static, self-contained executable > to run under X? (.i.e. that it can be pressed on and run from > a publication CD, with no need for GTK libraries on the > target computer...?) > Victor > --------------------------------------- > > > Does anyone here know/done it? > > sure, why not? mzz@alien:/z/src/dillo/dillo/src$ gcc -o dillo-static chain.o commands.o cache.o capi.o doc.o dw.o dw_aligned_page.o dw_bullet.o dw_button.o dw_container.o dw_embed_gtk.o dw_ext_iterator.o dw_gtk_scrolled_frame.o dw_gtk_scrolled_window.o dw_gtk_statuslabel.o dw_gtk_viewport.o dw_hruler.o dw_image.o dw_list_item.o dw_marshal.o dw_page.o dw_style.o dw_table.o dw_table_cell.o dw_tooltip.o dw_widget.o gtkframeset.o findtext.o selection.o focus.o web.o pagemark.o progressbar.o dillo.o bookmark.o dicache.o dns.o gif.o jpeg.o png.o html.o image.o misc.o tab.o interface.o history.o nav.o plain.o menu.o prefs.o colors.o bitvec.o klist.o strbuf.o url.o cookies.o IO/libDio.a -lpthread /usr/lib/libpng.a /usr/lib/libjpeg.a /usr/lib/libz.a /usr/lib/libgtk.a /usr/lib/libgdk.a /usr/lib/libgmodule.a /usr/lib/libglib.a /usr/X11R6/lib/libXi.a /usr/X11R6/lib/libXext.a /usr/X11R6/lib/libX11.a /usr/lib/libm.a -ldl mzz@alien:/z/src/dillo/dillo/src$ strip --strip-all dillo-static mzz@alien:/z/src/dillo/dillo/src$ ldd dillo-static libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x4000e000) libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4001e000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40021000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x411c2000) mzz@alien:/z/src/dillo/dillo/src$ ls -la dillo-static -rwxr-xr-x 1 mzz mzz 2063896 2003-12-12 20:13 dillo-static the libc and dl were linked dynamically, because glibc tries to read some 'modules' and crashes, when these are not compatible with the glibc version (makeing it impossible to reliable run static-glibc linked program on other host or even after upgradeing libraries on the same machine).

Dec. 12, 2003

statically linked dillo

by Jorge Arellano Cid

Hi, ---------- Forwarded message ---------- Date: Thu, 11 Dec 2003 23:30:05 +0000 From: Victor M. <voremo(a)safe-mail.net> To: jcid(a)softhome.net Subject: dillo Can dillo be compiled into a static, self-contained executable to run under X? (.i.e. that it can be pressed on and run from a publication CD, with no need for GTK libraries on the target computer...?) Victor --------------------------------------- Does anyone here know/done it? Cheers Jorge.-

Dec. 12, 2003

[PATCH] I18N

by Kiyo

Hi. I made an I18N patch for Dillo. This is simple I18N. Japanese, Chinese, Korean, Greek, etc. Only LOCALE character are displayed. Not support "complicated languages". (such as Arabic) Internal code is mainly processing by UTF-8. UTF-8 wrapper of a part of APIs of GTK+1 is included. This wrapper will be unnecessary if Dillo ports to FLTK2 or GTK+2. But, I think that others will be probably needed. A part of this patch referred to Mr. Robert Thomson's Japanese patch. It is better to also gettextize. But, it has not applied to this patch. http://teki.jpn.ph/pc/software/dillo-cvs2003121203-i18n.diff.bz2 md5sum: 5a1e0428d0e049a081dd4721d48b1de2 and... For Core team, may not be desirable... This is large patch for Dillo-0.7.3 . I18N(UTF-8 support and gettext) Xft antialiasing(multibyte support) Setting Tool(gtk+) frame&tab(ver.10 with I18N fix) gzip compression transmission SearchBox UserAgent changer Referer meta-refresh SSL BASIC authorization Fix page scroll Character entity references(Probably almost is supported. but it's dependent on LOCALE.) and some various changes. Various persons' patches are unified and an original improvement is added. http://teki.jpn.ph/pc/software/dillo-0.7.3-i18n-misc-20031208.diff.bz2 md5sum: 0d3bdf88a3e61a4659e708ac4a971c1f #I'm hoping that both user and developer can become happy :-) --- Kiyo<kiyo(a)teki.jpn.ph> http://teki.jpn.ph/

Dec. 12, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Jorge Arellano Cid

On Fri, 5 Dec 2003, Johannes Hofmann wrote: > Hi Jorge, > > On Thu, Dec 04, 2003 at 10:43:34AM -0300, Jorge Arellano Cid wrote: > > > > I could not yet get any reproducible results from profiling, > > > > !? > > > > Doesn't it show any function usage-ratio/run-time change? > > > > Ok, I redid the profiling on my slower Linux box with utilities.html. > > Html_cleanup_tag is called more often in cvs version (16742 vs. 10749) and > seems quite a bit slower than in 0.7.3. > > See gprof output below. > > Hope that helps, > Johannes > > PS: Of course I can send you the whole gprof output, but it is quite > large, so I did not want to send the whole thing to the list. > [...] Thanks a lot! Now it's clear where's the problem. I'll review it together with another parsing issue in a few days I hope. Cheers Jorge.-

Dec. 11, 2003

latest network patch

by Jorge Arellano Cid

Hi there! A network patch that covers several aspects was just commited: + Connected the dpi stream to the cache using the CCC! + Fixed the cache API by introducing the new call a_Capi_get_buf(). + Fixed a race condition and a multiple request problem. + Enabled the https dpi (it doesn't work yet, just a development version). + Removed a cpu-hog when the network is unreachable. Besides what's stated above, it has improved a bit the network experience (for instance on sites with lots of small images. For ex. newspapers). Please test it and tell me how it works. Anders: Please try it and tell us if it also produces the locks you've seen. Does 0.7.3 also lock? Ferdi: It has the proper bindings between the cache and dpi, so HTML served over FTP works, among others! Some https sites are also viewable... Madis: This patch has the framework to implement https in a similar way than the ssl gateway. The connection between dillo and the https dpi is done by the generic dpi handler. Note that although it may be easy to add the POST method using wget to the current https dpi (wget >= 1.9.x using --post-data and the DilloUrl), making a native https plugin (avoiding wget) as in the ssl gatway is preferred. This allows for a simple way to implement connection caching. The current https dpi is a filter, not a server as it should to implement it this way. This is also easy to do. Regards Jorge.-

Dec. 11, 2003

Re: [Dillo-dev] Re: BUG#494

by Jorge Arellano Cid

On Wed, 10 Dec 2003, Anders Gavare wrote: > On Tue, 9 Dec 2003, Jorge Arellano Cid wrote: > > > Hi, > > > > Some time ago I read this bug and now the CVS has a bunch of > > fixed for signed/unsigned conflicts that may cause trouble on > > 64bit machines. Please test our CVS and tell me if the bug > > persists. > > Once I found out what the problem was, I mailed Sebastian Geerken about > it. I think that was in September. > > http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/dillo/dillo/src/dw_widget.c… > > That fixed the rendering bug. OK. > I'm sorry that I forgot to remove the > entry from the bug database. I've not had any other problems on sparc64 > yet, except possible some random lock-ups. The version in CVS as of > 07:00 this morning seems to work just fine (that is, it still has the > random lock-ups but the output looks nice). lock-ups... Can you decribe them some more, or better, run dillo under gdb to find out where or why it locks (I haven't seen that bug ever). > I use dillo daily. It is very neat, especially on non-i386 platforms. > Keep up the good work :-) Thanks. Cheers Jorge.- PS: Are you on dillo-dev?

Dec. 10, 2003

BUG#494

by Andrew A. Gill

Good Ol' Jorge wrote: > > Some time ago I read this bug and now the CVS has a bunch of > fixed for signed/unsigned conflicts that may cause trouble on > 64bit machines. Please test our CVS and tell me if the bug > persists. Alpha EV56 running gcc 3.3.2 (glibc 2.3.2) reports no errors yet, sir! In fact, Slashdot now seems to be readable, thanks to something in Dillo CVS (with old Dillo it's still unreadable). -- |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: -- Full speed ahead!

Dec. 10, 2003

Re: BUG#494

by Anders Gavare

On Tue, 9 Dec 2003, Jorge Arellano Cid wrote: > Hi, > > Some time ago I read this bug and now the CVS has a bunch of > fixed for signed/unsigned conflicts that may cause trouble on > 64bit machines. Please test our CVS and tell me if the bug > persists. Once I found out what the problem was, I mailed Sebastian Geerken about it. I think that was in September. http://cvs.auriga.wearlab.de/cgi-bin/cvsweb.cgi/dillo/dillo/src/dw_widget.c… That fixed the rendering bug. I'm sorry that I forgot to remove the entry from the bug database. I've not had any other problems on sparc64 yet, except possible some random lock-ups. The version in CVS as of 07:00 this morning seems to work just fine (that is, it still has the random lock-ups but the output looks nice). > Cheers > Jorge.- I use dillo daily. It is very neat, especially on non-i386 platforms. Keep up the good work :-) regards Anders

Dec. 10, 2003

navigation

by montegue＠myrealbox.com

i would like to see in addition to the forward and backward navigation buttons, one that goes to the parent directory, like konqueror does, and galeon if i am not mistaken :) thanks for a terrific application -- GR I have seen the future and it is just like the present, only longer. -- Kehlog Albran

Dec. 9, 2003

BUG#494

by Jorge Arellano Cid

Hi, Some time ago I read this bug and now the CVS has a bunch of fixed for signed/unsigned conflicts that may cause trouble on 64bit machines. Please test our CVS and tell me if the bug persists. You can send me the screenshot (not to dillo-dev please) Cheers Jorge.-

Dec. 9, 2003

Re: dpid

by Jorge Arellano Cid

On Sat, 6 Dec 2003, Ferdi Franceschini wrote: > Hi Jorge, > > On Fri, Dec 05, 2003 at 09:25:20AM -0300, Jorge Arellano Cid wrote: > > > > Hi Ferdi, > > > > I've catched an API problem inside the capi/cache that may be > > the cause for the fork-hog. This note is just to keep you from > > wasting time reviewing it. I'll write to you soon. > Great. It _was_ the cause! There was a race condition hidden behind the lack of dpi-cache connection (the part we blamed) and a slightly broken API (the cloaked problem). As a matter of fact this bug had remained unnoticed maybe for years. In my patched tree (which is under test), the bug is fixed (both parts) and dillo works even better than before. > I think I have a new solution to the inf loop caused when a connection is not > accepted on a dpi socket for any reason. This new solution does not require > any code changes to the plugins. I will post more info to dillo-dev but I need > to experiment a bit first. That's good news. Cheers Jorge.-

Dec. 9, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Frank de Lange

BTW, The new kbnav patch is NOT on the site yet, wait for the announcement before you try to download it... 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." ]

Dec. 5, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Frank de Lange

Related to this, I have a new version (probably the last, announcement to follow) of the kbnav patch which solves some performance issues related to g_list_search_custom(). This function, which caused an enormous overhead, has been eliminated from the patch alltogether in favor of a hashtable-based search. 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." ]

Dec. 5, 2003

Re: [Dillo-dev] wanted: CPU overhead source.

by Johannes Hofmann

Hi Jorge, On Thu, Dec 04, 2003 at 10:43:34AM -0300, Jorge Arellano Cid wrote: > > I could not yet get any reproducible results from profiling, > > !? > > Doesn't it show any function usage-ratio/run-time change? > Ok, I redid the profiling on my slower Linux box with utilities.html. Html_cleanup_tag is called more often in cvs version (16742 vs. 10749) and seems quite a bit slower than in 0.7.3. See gprof output below. Hope that helps, Johannes PS: Of course I can send you the whole gprof output, but it is quite large, so I did not want to send the whole thing to the list. ================================= current cvs ============================: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 12.24 0.24 0.24 27862 8.61 8.61 Html_get_attr2 11.73 0.47 0.23 58152 3.96 6.88 Dw_page_real_word_wrap 8.67 0.64 0.17 16742 10.15 12.71 Html_cleanup_tag 5.61 0.75 0.11 61 1803.28 6299.81 Html_write_raw 4.59 0.84 0.09 354712 0.25 0.25 a_Dw_widget_get_type 4.59 0.93 0.09 14073 6.40 13.90 p_Dw_widget_queue_resize 3.06 0.99 0.06 15306 3.92 3.92 Dw_page_add_line 3.06 1.05 0.06 2207 27.19 27.52 Dw_page_get_extremes 2.55 1.10 0.05 15980 3.13 6.77 Html_process_space 2.55 1.15 0.05 5993 8.34 8.34 Html_push_tag 2.04 1.19 0.04 121087 0.33 0.33 a_Dw_page_get_type 1.53 1.22 0.03 77221 0.39 0.40 Dw_page_get_word_extremes 1.53 1.25 0.03 58845 0.51 0.80 Dw_page_mark_change 1.53 1.28 0.03 23886 1.26 1.26 a_Dw_gtk_viewport_get_type 1.53 1.31 0.03 13499 2.22 12.24 Html_process_word 1.53 1.34 0.03 6883 4.36 4.36 a_Dw_style_new 1.53 1.37 0.03 1887 15.90 129.82 Html_tag_open_table_cell 1.53 1.40 0.03 1887 15.90 39.66 a_Dw_table_add_cell 1.53 1.43 0.03 Dw_page_destroy 1.53 1.46 0.03 Dw_table_size_request 1.02 1.48 0.02 58440 0.34 0.34 Html_tag_compare 1.02 1.50 0.02 19938 1.00 1.00 Dw_page_add_word 1.02 1.52 0.02 16527 1.21 9.69 a_Dw_page_add_text 1.02 1.54 0.02 15155 1.32 1.32 a_Dw_page_add_space 1.02 1.56 0.02 13003 1.54 61.50 Html_process_tag 1.02 1.58 0.02 13003 1.54 3.08 Html_tag_index 1.02 1.60 0.02 8499 2.35 2.77 a_Dw_widget_size_request 1.02 1.62 0.02 6883 2.91 2.91 Dw_style_remove 1.02 1.64 0.02 6151 3.25 3.58 Dw_page_forall 1.02 1.66 0.02 3380 5.92 88.16 Dw_page_rewrap 1.02 1.68 0.02 2729 7.33 17.85 Dw_container_destroy 1.02 1.70 0.02 858 23.31 108.94 Html_tag_open_tr 0.51 1.71 0.01 28657 0.35 0.35 a_Dw_container_get_type 0.51 1.72 0.01 16527 0.61 0.61 Dw_page_calc_text_size 0.51 1.73 0.01 16383 0.61 0.61 a_Dw_table_get_type 0.51 1.74 0.01 8016 1.25 1.25 a_Url_str 0.51 1.75 0.01 6159 1.62 1.62 a_Dw_widget_set_ascent 0.51 1.76 0.01 5993 1.67 6.50 Html_eventually_pop_dw 0.51 1.77 0.01 5993 1.67 14.38 Html_tag_cond_cleanup <snip> ----------------------------------------------- 0.00 0.00 69/16742 Html_tag_open_dt [77] 0.00 0.00 426/16742 Html_par_push_tag [88] 0.00 0.00 480/16742 Html_tag_open_dd [68] 0.01 0.00 681/16742 Html_tag_open_table [23] 0.03 0.01 3432/16742 Html_tag_open_tr [19] 0.06 0.01 5661/16742 Html_tag_open_td [7] 0.06 0.02 5993/16742 Html_tag_cond_cleanup [22] [12] 10.9 0.17 0.04 16742 Html_cleanup_tag [12] 0.01 0.03 5993/5993 Html_eventually_pop_dw [37] 0.00 0.00 1314/6883 Dw_style_remove [63] 0.00 0.00 16742/16742 Html_match_tag [227] ----------------------------------------------- ========================== 0.7.3 ===========================: Flat profile: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls us/call us/call name 13.71 0.27 0.27 58152 4.64 7.26 Dw_page_real_word_wrap 10.66 0.48 0.21 24525 8.56 8.56 Html_get_attr2 6.60 0.61 0.13 333652 0.39 0.39 a_Dw_widget_get_type 4.57 0.70 0.09 116585 0.77 0.77 a_Dw_page_get_type 3.55 0.77 0.07 19938 3.51 3.51 Dw_page_add_word 3.55 0.84 0.07 61 1147.54 6345.30 Html_write_raw 2.54 0.89 0.05 Dw_page_destroy 2.54 0.94 0.05 Dw_page_size_allocate 2.03 0.98 0.04 58440 0.68 0.68 Html_tag_compare 2.03 1.02 0.04 15304 2.61 2.61 Dw_page_add_line 2.03 1.06 0.04 10749 3.72 4.44 Html_cleanup_tag 2.03 1.10 0.04 5993 6.67 6.67 Html_push_tag 2.03 1.14 0.04 Dw_table_size_request 1.52 1.17 0.03 77221 0.39 0.41 Dw_page_get_word_extremes 1.52 1.20 0.03 51991 0.58 1.26 Dw_page_mark_change 1.52 1.23 0.03 16527 1.82 12.58 a_Dw_page_add_text 1.52 1.26 0.03 15980 1.88 6.64 Html_process_space 1.52 1.29 0.03 13499 2.22 15.57 Html_process_word 1.52 1.32 0.03 12896 2.33 12.23 p_Dw_widget_queue_resize 1.52 1.35 0.03 8499 3.53 4.17 a_Dw_widget_size_request 1.52 1.38 0.03 6883 4.36 4.36 a_Dw_style_new 1.52 1.41 0.03 3238 9.26 17.79 Dw_page_calc_widget_size 1.52 1.44 0.03 2207 13.59 14.37 Dw_page_get_extremes 1.52 1.47 0.03 1362 22.03 29.75 Dw_table_sub_calc_col_widt 1.02 1.49 0.02 28654 0.70 0.70 a_Dw_container_get_type 1.02 1.51 0.02 15155 1.32 1.32 a_Dw_page_add_space 1.02 1.53 0.02 6883 2.91 2.91 Dw_style_remove 1.02 1.55 0.02 5135 3.89 12.34 Html_pop_tag 1.02 1.57 0.02 2117 9.45 9.45 a_Url_free 1.02 1.59 0.02 1784 11.21 11.21 Url_object_new 1.02 1.61 0.02 858 23.31 74.05 Html_tag_open_tr 1.02 1.63 0.02 681 29.37 158.58 Html_tag_open_table 1.02 1.65 0.02 Cache_url_hash 0.51 1.66 0.01 22704 0.44 0.44 a_Dw_gtk_viewport_get_type 0.51 1.67 0.01 16565 0.60 0.60 Html_match_tag 0.51 1.68 0.01 16383 0.61 0.61 a_Dw_table_get_type 0.51 1.69 0.01 13003 0.77 48.25 Html_process_tag 0.51 1.70 0.01 13003 0.77 3.85 Html_tag_index 0.51 1.71 0.01 8345 1.20 1.20 a_Url_str 0.51 1.72 0.01 6150 1.63 2.40 Dw_page_forall 0.51 1.73 0.01 6130 1.63 2.07 Dw_widget_update_cursor 0.51 1.74 0.01 6130 1.63 4.11 a_Dw_widget_unrealize 0.51 1.75 0.01 5312 1.88 7.02 Html_eventually_pop_dw 0.51 1.76 0.01 4383 2.28 2.28 a_Bitvec_free 0.51 1.77 0.01 3380 2.96 96.27 Dw_page_rewrap 0.51 1.78 0.01 3067 3.26 4.04 a_Dw_widget_size_allocate 0.51 1.79 0.01 3065 3.26 12.33 a_Dw_widget_realize 0.51 1.80 0.01 3064 3.26 3.96 Dw_container_remove <snip> ----------------------------------------------- 0.00 0.00 69/10749 Html_tag_open_dt [140] 0.00 0.00 426/10749 Html_par_push_tag [110] 0.00 0.00 480/10749 Html_tag_open_dd [78] 0.00 0.00 681/10749 Html_tag_open_table [17] 0.01 0.00 3432/10749 Html_tag_open_tr [27] 0.02 0.00 5661/10749 Html_tag_open_td [9] [35] 2.4 0.04 0.01 10749 Html_cleanup_tag [35] 0.01 0.00 10749/16565 Html_match_tag [93] 0.00 0.00 177/5312 Html_eventually_pop_dw [44]

Dec. 5, 2003

Re: dead link behavior

by Peter Milne

dillo-0.7.3.tar.bz2 is the Freebsd ported version of Dillo. No IPv6 I'll do something else...suggestion? :o) -- ~~~Pete~~~ http://milneweb.com http://nomorevirus.com

Dec. 5, 2003

Re: [Dillo-dev] dead link behavior

by Jorge Arellano Cid

On Thu, 4 Dec 2003, Peter Milne wrote: > > This is what Jorge Arellano Cid wrote prior to this response: > > > > >> > >> If I click a link and it turns out to be a dead link.....everything > >> locks > >> up hard and I have to 'xkill' Dillo. > > > > Definitely not normal. Anyway to reproduce it? [snip] > Sure thing, let me click on a dead link. Example: > > (Thu 13:44) happy %dillo > Setting locale to C... > dillo_dns_init: Here we go! > Enabling cookies as from cookiesrc... > Nav_open_url: Url=>about:splash< > Nav_open_url: Url=>http://www2.bsdhound.org< > Dns_server [0]: www2.bsdhound.org is 0x814fe78 > Connecting to 12.*.*.* > > > And there it hangs...... Doesn't happen here. Are you using 0.7.3 or CVS? With IPv6 or default? Has anyone seen this bug? Cheers Jorge.-

Dec. 5, 2003

Re: [Dillo-dev] Frames

by Ralph Slooten

On Thu, 4 Dec 2003 22:32:17 -0700 (MST) "Peter Milne" <peter(a)milneweb.com> wrote: > Tell me, if I recall, there is a way to view frames in > Dillo...correct? Would love to use it for Squirrelmail. Would > actually be willing to use another web based, imap mail client too. Tried searching the archives? LOL. The standard dillo does not (yet?) support frames, however Frank de Lange has provided patches for quite a while now on his site. http://www.geocities.com/ikbenfrank/ Greetings Ralph -- http://axljab.homelinux.org/ "...the software said Win95 or better, so I installed Linux"

Dec. 5, 2003

Frames

by Peter Milne

Tell me, if I recall, there is a way to view frames in Dillo...correct? Would love to use it for Squirrelmail. Would actually be willing to use another web based, imap mail client too. -- ~~~Pete~~~ http://milneweb.com http://nomorevirus.com

Dec. 5, 2003

Re: [Dillo-dev] gcc 2.95 doesn't know about -Wno-unused-parameter

by David McKee

On Thu, 4 Dec 2003, Jorge Arellano Cid wrote: > On Wed, 3 Dec 2003, David McKee wrote: > > On Tue, 2 Dec 2003, David McKee wrote: > > > On Tue, 2 Dec 2003, Jorge Arellano Cid wrote: > > > > On Tue, 25 Nov 2003, Andreas Schweitzer wrote: > > > [attribution to me lost] > > > > > > my gcc doesn't believe in -Wno-unused-parameters, > > > [snip] > > > > > Attached is a patch > > > [snip] > > > > Commited. > > > > Does it work for you David? [snip] > > I tried it on my work machine. > > > > The Redhat box actual uses: > > > > $ gcc -v > > Reading specs from > > /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs > > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) [snip] > I commited a patch that tests for gcc version 3. > Please test it and tell us. Worked on both machines. Very nice. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Dec. 5, 2003

Re: [Dillo-dev] gcc 2.95 doesn't know about -Wno-unused-parameter

by Jorge Arellano Cid

On Wed, 3 Dec 2003, David McKee wrote: > On Tue, 2 Dec 2003, David McKee wrote: > > On Tue, 2 Dec 2003, Jorge Arellano Cid wrote: > > > On Tue, 25 Nov 2003, Andreas Schweitzer wrote: > > [attribution to me lost] > > > > > my gcc doesn't believe in -Wno-unused-parameters, > > [snip] > > > > Attached is a patch > > [snip] > > > Commited. > > > Does it work for you David? > > > Perfectly. Thanks. > > Having said that on the basis of my gcc 2.95 based debian machine at home, > I tried it on my work machine. > > The Redhat box actual uses: > > $ gcc -v > Reading specs from > /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > *sigh* > [...] > Style question: > > Would it be better to test for the presence of the flag than to try to > exclude those compilers without it? Yes, that's the right way to do it, but I don't know how yet :) I commited a patch that tests for gcc version 3. Please test it and tell us. Cheers Jorge.-

Dec. 4, 2003