- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev]testing dillo-0.8.3-rc1

by Jorge Arellano Cid

On Wed, Oct 06, 2004 at 03:47:32PM +0200, Bjoern Brill wrote: > Hello, > > [...] > - This one is not new, but I fixed it a while ago for myself and then > forgot about it: the "This page uses the NON-STANDARD meta refresh > tag..." warning usually occurs inside <head>, but is immediately > sent to the parser, which in turn switches its HTML processing state > from IN_HEAD to IN_BODY prematurely. After that, head-only tags like > <title> and <base> are ignored. A minimal fix is at the end of the > mail. Done. -- Cheers Jorge.-

Oct. 15, 2004

[Dillo-dev]Crash on fast reload for dpi pending...

by Jorge Arellano Cid

Hi there, Please note that hitting reload as a mad man over a dpi-handled URL can crash Dillo. This happens because currently there's no code to account for this case (as there is for the HTTP branch). Thinking about it, there's a possibility of merging the CCC branches into a couple of generic and very powerful ones (much like what the dpi is now). If this design is possible, and succeeds, it would mean much simpler handling of IO, the elimination of a lot of complexity, more stability (all the data would use it and thus be more tested). I'll give it some thought. Not for the next release though... :-) -- Cheers Jorge.-

Oct. 14, 2004

Re: [Dillo-dev]dillo-0.8.3-rc1.tar.bz2: bug

by Jorge Arellano Cid

On Wed, Oct 13, 2004 at 02:01:01PM +0200, Matthias Franz wrote: > On Tue, Oct 12, 2004 at 12:49:21PM -0300, Jorge Arellano Cid wrote: > > Well, I've devoted several days to this BUG. > > Dear Jorge, > > the time and energy you have been spending on this bug shows me > how much you are dedicated to high quality software. > > Thanks a lot! > > PS: Once you have a bugfix, I'd be happy to test it. A patch is in the CVS! Finally I figured it out: there were two race conditions, one on closing the write end of the socket (the easy one) and another on the thin time-slice between server FD close and the IO watch for it being scheduled inside Dillo. The problem was very hard to spot as it wasn't on a variable shared explicitly among threads, but on a file descriptor. If somewhere inside the above mentioned time-slice, Dillo requested for a new FD and the kernel noticed, and decided to reuse the FD, then there were problems. I say there were problems because the data transfer had a good chance to succeed on a fascinatingly wicked way! (covering up the BUG). The patch makes changes in several places, the most interesting of them being the threads list being sorted by a primary key other than the FD (this allows handling the CCCs for both, the just closed and the just openned one). I left the thread list's debug messages for checking purposes. If you see two identical FDs in the list, that was the bug (handled now). It worked OK on all my tests for the file dpi server and also for the file dpi filter. I left the dpi server option as default because it spawns less processes. If you want to test the file filter dpi, just compile dillo and run from the command line. To test the file dpi server, do a: make install-strip and remove, or 'chmod -x', the file.filter.dpi. (usually /usr/local/lib/dillo/dpi/file/file.filter.dpi). ... and tell us how it works. -- Cheers Jorge.-

Oct. 14, 2004

Re: [Dillo-dev]dillo-0.8.3-rc1.tar.bz2: bug

by Matthias Franz

On Tue, Oct 12, 2004 at 12:49:21PM -0300, Jorge Arellano Cid wrote: > Well, I've devoted several days to this BUG. Dear Jorge, the time and energy you have been spending on this bug shows me how much you are dedicated to high quality software. Thanks a lot! PS: Once you have a bugfix, I'd be happy to test it. -- Matthias Franz Section de Mathématiques, Université de Genève, Suisse

Oct. 13, 2004

[Dillo-dev]Webmails compatibility with Dillo 0.8.3rc1

by Florent BERANGER

Hi, Here a little test result about webmails compatibility : Read Compose Horde : ok nok Squirrel : ok ok -> you just have to select a frame and it's ok:) Tiscali : nok nok Ms hotmail: nok nok Google gmail: nok nok Yahoo mail: nok nok Best regards, Florent ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

Oct. 12, 2004

[jcid@dillo.org: Re: [Dillo-dev]Caching]

by Jorge Arellano Cid

Hi, Here's an email that I mistakenly replied personally instead of to dillo-dev. -- Cheers Jorge.-

Oct. 12, 2004

Re: [Dillo-dev]dillo-0.8.3-rc1.tar.bz2: bug

by Jorge Arellano Cid

On Wed, Oct 06, 2004 at 01:52:40PM +0200, Matthias Franz wrote: > Hi everybody, > > the rendering is really much better in the 0.8.3 version. Well done! > > Unfortunately, I'm experiencing problems with the new version that > I've never had with 0.8.2: > > 1. Dillo displays a page without the embedded GIF image, showing the > alternate text instead. It starts consuming all cpu time, but still > responds to keyboard and mouse input (history navigation; no new pages > are displayed). > > 2. Dillo doesn't display a page at all. Cpu/input behaviour as before. > > The problems only occur with certain local files, not http pages. > Moreover, they don't occur deterministically. They seem to happen > somewhat more often if one follows a link instead of loading a page > from the command line. > [...] Well, I've devoted several days to this BUG. It's one of the hard kind to find and fix. It has to do with race conditions due to threading and communication with external processes. Sometimes it shows, some others not. I'm very advanced on it. Porting the file dpi to a dpi server helped me to reproduce the bug (and to discard the multiple random scheduled external processes as the root of the problem). I know the exact line where it crashes, and I'm in the process of trying to understand how it gets there. Shall "the force" be with me, a bug fix may come soon! :-) -- Cheers Jorge.-

Oct. 12, 2004

Re: [Dillo-dev][illegal content type in doc/Dpid.txt]

by Diego Sáenz

Sorry. If it is for me, i do not write that example. And it is true, the example send "text" instead "text/plain" as content type Diego/DarkSpirit. El Fri, 8 Oct 2004 09:26:23 -0400 Jorge Arellano Cid <jcid(a)dillo.org> escribio: > Hi, > > Diego, IIRC you wrote the below mentioned example. Please give > it a review. > > -- > Cheers > Jorge.- >

Oct. 10, 2004

Re: [Dillo-dev]which version does this patch file patch

by Riccardo Mottola

"Linda J. Laubenheimer" wrote: > I'm not a C programmer, otherwise I'd fix it and send it to you. > > > > Believe me, there's nothing to fix. Just install both gtk+-1 and > > gtk+-2 and live happily ever after. I did! > > Not going to happen. I stated, I thought clearly, that this was an > embedded project. You can't just go willy-nilly installing extra > libraries because an application only compiles against version 1, but > not version 2. The rest of the items in the project are compiled > against gtk2. So yes, in order to use Dillo, it would need to be fixed > to be compiled against glib2 and gtk2, because just installing another > set of libraries is not an option. well, I wouldn't use the bloat of gtk2/glib2 in an embedded system and I hope dillo stays gtk1, which is faster, more portable and consumes less resources (and besides,muchmore portable across different operating systems). I could rephrase saying that it is your problem using gtk2! Of course you have choosen your tools and libraries in your project... Personally I hope the independence of the dillo core will enable to port it to different UIs and different toolkits (think of motif or fltk or even other, fast toolkits) instead of binding us to gtk. Of course you can object that gtk2 is actively developed and gtk1 not, but I really agree with other saying here that the two are quite "different" beasts. Just my 2 cents, -R

Oct. 10, 2004

Re: [Dillo-dev]Caching

by Brian Hechinger

On Wed, Oct 06, 2004 at 09:37:48AM -0400, Jorge Arellano Cid wrote: > > It'd be good to have a way to control caching. Unfortunately > not for the next release. It has its complexities that need > careful design and time. > > We're sorting a large task list by priorities now with > Sebastian. I'd say in advance we'd need a volunteer developer to > look on this topic. We're far surpassed by the amount of work. ok, i will volunteer to do the caching portion. i need to finish reading Cache.txt and pick through capi.c and cache.c a bit more, but before i know everything i should know, here is what i'm planning so far: we go into cache.c as normal, if the page isn't cache, we initiate the connection and cache the page as normal. the only difference is now we search the header for the Pragma: no-cache meta tag. if we find it, we set a flag (i'm assuming Url->flags is a vector?) in the cache entry. the next time we go to that page, since it's in the cache, the first thing we check is for that no-cache flag. if it exists, we look at nocacherc (which will be structured exactly like cookiesrc) and if we have an ACCEPT match there, we simply behave as if the item doesn't exist in cache. does this sound like the proper way to do it to you guys? also, what is the proper no-cache system to honor? the Pragma meta tag? or is there something else we should look for? i'm not completely up on my HTML standards quite yet. -brian -- "The cats tend to administer themselves, and contrary to the expected facts, the house and everything in it was installed for their benefit." -- Nic Clews

Oct. 9, 2004