October 2004 - Dillo-dev - lists.mailman3.com

[Dillo-dev]CYGWIN compatibility

by Jorge Arellano Cid

Hi, Sometime ago I forwarded this message to dillo-dev: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2004-October/002295.html <q> Hi anyone, I successfully compiled and installed dillo-0.8.2 on an AMD K7 600MHz: $ uname -a CYGWIN_NT-5.0 fermat 1.5.11(0.116/4/2) 2004-09-04 23:17 i686 unknown unknown Cygwin It runs very well, so you can update your compatibility file ;) Greetings, Marianne </q> Has anyone contacted Marianne to know the recipe? -- Cheers Jorge.-

Oct. 28, 2004

Re: [Dillo-dev]Re: dillo patch: anchor names

by Jorge Arellano Cid

Matthias, Please excuse me for the delayed answer. I had a hard time fixing release candidates for the dillo-0.8.3 release... On Tue, Oct 19, 2004 at 12:03:17PM +0200, Matthias Franz wrote: > Hi Richard, > > thanks for your comments! Yes, very interesting. > > On Fri, Oct 15, 2004 at 04:35:29PM -0400, Richard Page-Wood wrote: > > I do know a bit about HTML and XHTML, though, and I was wondering > > about your doctype-sniffing patch. As I understand it, you're trying > > to distinguish between HTML 4.01 and XHTML 1.x by sniffing the doctype > > and giving appropriate warnings for invalid markup. Are you also going > > to alter the rendering for XHTML? > > Certainly not as part of my patch. It's origin was simply the > observation that Dillo refused anchor names like "Dürst" which are > allowed in HTML if defined with the "name" attribute (see Section 12.2.3 > of the HTML 4.01 spec). > > > There's a good article here: > > > > http://www.hixie.ch/advocacy/xhtml > > > > which talks amongst other things about the impossibility of correctly > > identifying an XHTML document which might be of interest to you. > > Having looked at this article and the references given therein, I don't > feel anymore that it would be a good idea to try and figure out whether > the document type is HTML or XHTML. > > I still like the idea of supporting XHTML in some way, mostly because XML > lacks many of the strange features of SGML that make parsing difficult. > For example, "<" and "&" are not allowed as ordinary characters in XML. > But this has nothing to do with anchor names, so I will remove the XHTML > parts of the patch (unless someone complains). > > Jorge: Are you still interested in evaluating <!DOCTYPE> to figure out > the HTML version? Maybe it would be ok for a small browser like Dillo > to stick to HTML 4.01. Could be... As the suggested document explains, there's not a big gain in serving XHTML as such, and nowadays most of it is served as "text/html". BTW, it's hard to find a site that serves XHTML as "application/xhtml+xml", that's not intended for testing. In our case the "detection" was just to try to provide a hintful HTML/XHTML warning. The easy solution is not to raise a warning or to send it to extra warnings ;). What worries me a bit more is what to do with XHTML served with the proper MIME type. Currently it's not rendered at all, though Dillo can perfectly cope with it. The reason is that the XHTML SPEC requires a validating client, and as Dillo doesn't include a formal XML parser this is not possible. Today this is not a problem because such sites are very seldom found. Maybe a partial validation can serve the standards compliance objective. I mean, for instance: proper nesting, lowercase tags, tag names in the XHTML namespace. Not much more than that. Perhaps MIME type detection, plus some doctype sniffing (to have "an idea" of whether we are dealing with HTML 2.0, 3.2, 4.0, 4.1 or XHTML), and having that information in a structure like the one suggested in the former mail could serve to fine tune a bit the warning messages (or parser behaviour). For instance having that info, in the case of anchor names can lead to something as simple as: if (!isalpha(val[0]) && doctype == DOCTYPE_XHTML) MSG_HTML("first character of '%s' value is outside" " the [A-Za-z] set\n", attrname); Just make the patch with comment where this messages should go. With the fuzzy detection code in place it'll be a matter of binding. Not the highest priority, but easy to merge. -- Cheers Jorge.-

Oct. 28, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Brian Hechinger

On Thu, Oct 28, 2004 at 04:20:29PM +0200, Diego S?enz wrote: > What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? nothing, i just wanted to keep the code as identical to the original cookie version for now until it is decided what is going to be done with that hunk of code. -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Oct. 28, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Diego Sáenz

What is the difference between CACHE_ACCEPT and CACHE_ACCEPT_SESSION? DarkSpirit. El Thu, 28 Oct 2004 08:05:20 -0400 Brian Hechinger <wonko(a)4amlunch.net> escribio: > On Thu, Oct 28, 2004 at 11:02:17AM +0200, Roberto A. Foglietta wrote: > > > > Obviously to respect Dillo's team decision to do not allow refresh as > > default policy I make it optional by setting a flag from command line > > speaking of patches, i have finished the caching work yesterday, and need some > people to look at it and test it. > > it uses .dillo/cacherc to control which sites are allowed to set the browser to > not cache the pages there, and also, it only currently honors Pragma no-cache. > > i want to modify the control functions to live in a public place and be > generic enough that they can be used for anything, since all i did was copy > them out of cookies.c and changed all occurances of Cookie or Cookies to Cache > so the functions themselves don't change. > > once done, this could very easily be applied to the refresh tag to control that, > and in fact, could be applied to any tag whatsoever at that point. > > here is the patch, let me know what you think, it patches against: > > /cache.c/1.74/Mon Oct 25 22:49:26 2004// > /cache.h/1.18/Thu Oct 21 14:45:51 2004// > /html.c/1.219/Thu Oct 21 22:48:54 2004// > > -brian > -- > IHTFP: I firmly believe that people dumber than me exist solely for my > amusement. > IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake. >

Oct. 28, 2004

Re: [Dillo-dev]meta refresh patch for 0.8.2

by Brian Hechinger

On Thu, Oct 28, 2004 at 11:02:17AM +0200, Roberto A. Foglietta wrote: > > Obviously to respect Dillo's team decision to do not allow refresh as > default policy I make it optional by setting a flag from command line speaking of patches, i have finished the caching work yesterday, and need some people to look at it and test it. it uses .dillo/cacherc to control which sites are allowed to set the browser to not cache the pages there, and also, it only currently honors Pragma no-cache. i want to modify the control functions to live in a public place and be generic enough that they can be used for anything, since all i did was copy them out of cookies.c and changed all occurances of Cookie or Cookies to Cache so the functions themselves don't change. once done, this could very easily be applied to the refresh tag to control that, and in fact, could be applied to any tag whatsoever at that point. here is the patch, let me know what you think, it patches against: /cache.c/1.74/Mon Oct 25 22:49:26 2004// /cache.h/1.18/Thu Oct 21 14:45:51 2004// /html.c/1.219/Thu Oct 21 22:48:54 2004// -brian -- IHTFP: I firmly believe that people dumber than me exist solely for my amusement. IHTFP: Okay, maybe not solely for my amusement. Some of them make good cake.

Oct. 28, 2004

Re: [Dillo-dev]news about memory leak

by Roberto A. Foglietta

Riccardo Mottola wrote: > Hey, > > I am on a NetBSD/ppc system. DIllo 0.8.3 and can reproduce the leak. I > noted however that: > > - clicking the reload button in thight succession gets an increment of > about 4K every time > - the leak is consitent, you can make the amount of leaked memory > skyrocket to megabytes. > - clicking slowly, waitning 10 seconds each time does NOT make dillo > leak > > I suspect the leak happens if you click reload before dillo has > "finished" the page and the "stop button" is disabled. Excellent but using my refresh patch I could fix exactly delay among reloads and I see that 5 second are sufficient to load a trivial or not trivial html page but memory leak still. So what happens in ten seconds that doesn't happen in five? Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Oct. 28, 2004

[Dillo-dev]meta refresh patch for 0.8.2

by Roberto A. Foglietta

Hi to all, actually I'm working for a local public transport company in which I have to develop a new way to display time table and information to people. Using Dillo into embedded linux system allow my collegues to change graphical display just editing php code in the server BUT this kind of information have to stay up-to-date. Commit a refresh from server is, in this case, the best solution I can immagine. So supporting meta refresh tag makes Dillo good for embedded client systems. This is the main reason because I developed this web-deprecated but very-useful-in-embedded function. In addition to this pratical consideration I think people use free software to be free, so it makes sense give them the freedoom to choose also deprecated functions. Obviously to respect Dillo's team decision to do not allow refresh as default policy I make it optional by setting a flag from command line The patch is plenty of /* RAF, 2004-10-XX: bla bla */ comments because they are usefull for others developers inside my company when they will patch an original version of Dillo and found quickly what I have changed in. If you agree to apply this patch to future stable branches this kind of comments are not any more usefull. If you will include my patch, in agreement with gpl, please inserit somewhere a noticed of code-contribution refering me and the company which is employing me actually. Patch doens't add the memory leak bug which I submit, simply it was the way I discovered that bug. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Oct. 28, 2004

[Dillo-dev]news about memory leak

by Riccardo Mottola

Hey, I am on a NetBSD/ppc system. DIllo 0.8.3 and can reproduce the leak. I noted however that: - clicking the reload button in thight succession gets an increment of about 4K every time - the leak is consitent, you can make the amount of leaked memory skyrocket to megabytes. - clicking slowly, waitning 10 seconds each time does NOT make dillo leak I suspect the leak happens if you click reload before dillo has "finished" the page and the "stop button" is disabled. I used a very simple page: <html>this is a test</html> Cheers, Riccardo

Oct. 28, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

robert w hall wrote: > Hmm - could this be distro/kernel dependent? > Doing something similar (toggling reload when monitoring the dillo cvs > page IIRC) and monitoring memory via top on a remote terminal shows No > systematic effect - but this is playstation2-linux - an old 2.2.21 > kernel on a redhat-like implementation for a mips. > > In detail:- > On first coming from the home page to the CVS changelog, top shows > 9460k; this goes up to 9564 on first and stays there for subsequent > presses of reload. Returning to Home then back to cvs recovers the 9460, > 9564, 9564 sequence. > Bob It should be a glibc bug much more than kernel one, IMHO. Sometimes (but very rarely) I supposed to have managed to fix it because I didn't see it anymore, but recompiling THE SAME code or simply restarting dillo I saw it again. Obviously I was reloading THE SAME trivial html page (html, head, body, 4 links in 4 rows, closing-end). I'm working on MDK 10.1 but I could test it on a slackware too. Or better I will test dillo running on A but compiled in B and all others combinations foreach A, B in {mdk,slack}. Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Oct. 28, 2004

Re: [Dillo-dev]Memory leak bug (was dillo-0.8.3)

by Roberto A. Foglietta

Jorge Arellano Cid wrote: > On Wed, Oct 27, 2004 at 06:42:14PM +0200, Roberto A. Foglietta wrote: > >>Jorge Arellano Cid wrote: >> >>> [...] >>> Please get it at: >>> >>> http://www.dillo.org/download/dillo-0.8.3.tar.bz2 >>> >>> and send your feedback. 36 hours of testing time remain! :-) >>> >>> >> >> Sorry to inform you but v0.8.3 (far from, at least v0.8.2) has a >>memory leak bug. > > > I tested it and 0.8.2 also leaks the same amount. :-) > > >> Clicking on reload button used memory increase around 4kb for each >>click. Stop clicking make used memory increasing stop too. So increase >>memory size of dillo depends on reloads but not following links. >> >> Dillo show the same memory leak using back-foward button between two >>different address. Could you reproduce it? > > > Yes I can. > > I'm testing with a trivial HTML page: "<html>@</html>", because > bad formed pages may result in some leaks. It's interesting to > note that the leak shows with this page too. I forgot to say that probably small and big pages have different amount of memory leak but it exist always, even in trivial and correct pages. The first thing I try to check was the correctness of my html. After I check that EVERY TAG, included <p> was always closed even if is not necessary close it (like meta tag, or <p> or <br>). HTML doesn't seem to me the reason of memory leak, if it were probably memory leak get out in following links too bit it doesn't. > > I'll give it a look, though it's hard to know where to start... Checking previuos version hoping to found one which hasn't this bug and comparing code between has/has-not could give us a good starting point to solve bug. > > Thanks for the report. If you find more details of this BUG, > please let us know. I will... Cheers, -- Roberto A. Foglietta Analista Programmatore GNU/Linux SAD Trasporto Locale S.p.a. Corso Italia 13/N 39100 BOLZANO (I) Tel. +39/0471-450.261 Fax +39/0471-450.253

Oct. 28, 2004