- Dillo-dev - lists.mailman3.com

[Dillo-dev]dillo-0.8.4-rc1

by Jorge Arellano Cid

Hi, I just finished packing the tarball for dillo-0.8.4-rc1. Please excuse me for the delay, but I received a security notice that needed to be addressed (CAN-2005-0012), and I discovered a minor bug with the HEAD tag implicit-close handling code. All of this is fixed in the tarball now, plus a few comments. Please grab it ASAP, test it throughly and report your findings (finding no problems is a good sign ;). Some emphasis should be put on the newest file server dpi and on compiling on 64 bit machines. Enjoy! -- Cheers Jorge.-

Jan. 6, 2005

Re: [Dillo-dev]cache replace

by Thorben Thuermer

On Thu, 6 Jan 2005 21:18:17 +0800 "Yu Zenghui" <yuzenghui(a)people.com.cn> wrote: > hello all: > it seems that dillo doesn't use cache replace algorithms. it simply > inserts new entry into the hash table. > then if the program runs for a long time, it will use more and more memories. > doesn't it? exactly. there's a patch that i've been using for years, it's perfectly stable (but i'm not sure if it applies cleanly to current versions): http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-January/000073.html - Thorben

Jan. 6, 2005

[Dillo-dev]cache replace

by Yu Zenghui

hello all: it seems that dillo doesn't use cache replace algorithms. it simply inserts new entry into the hash table. then if the program runs for a long time, it will use more and more memories. doesn't it?

Jan. 6, 2005

[Dillo-dev]Re: dillo patch: entities (BUG#605)

by Jorge Arellano Cid

On Tue, Jan 04, 2005 at 01:33:01PM +0100, Matthias Franz wrote: > Hi Jorge, > > On Mon, Jan 03, 2005 at 12:05:59PM -0300, Jorge Arellano Cid wrote: > > I just reviewed and commited the patch. > > Great! > > > > > * The ';' at the end is no longer required. In fact, it is optional > > > according to the SGML spec (see also Sec. 5.3 of the HTML 4.01 spec). > > > Omitting the ';' produces a warning. > > > > When show_extra_warnings is set. > > > > I wonder if it is better to always rise the warning. Of course > > it is perfectly legal for SGML but IIRC XHTML requires the ';' > > and authors prefer to add it with a view to avoid problems, so a > > reminder should be welcome. e.g. www.linuxpackages.net. > > That depends on what the (extra) warnings are intended for. I thought > that ordinary HTML_MSG are for errors, so that (ideally - we/you don't > want to be 100% perfect) if show_extra_warnings is off, "no errors" means > that the page is valid HTML. If show_extra_warnings is on, then one gets > additonal warnings, for example about bad style, incompatibility with > XHTML etc. Of course, this is a design question. I also agree with this view. It provides a simple formal definition too ;). Let's keep it now and see what happens. > One more remark about the HTML error messages. I would suggest the > following: > > * Leave out the "HTML warning" at the beginning of each entry - all the > more that most entries are errors. > > * Introduce a macro HTML_ERROR for real error messages. It replaces > HTML_MSG (in most of the source code; internally it may call HTML_MSG). > > * Introduce a macro HTML_WARNING like > > #define HTML_WARNING(fmt...) if (prefs.show_extra_warnings) \ > HTML_MSG("warning: " ## fmt) > > (not tested - you get the idea). > > What do you think about it? It looks like a good idea. It's more correct to label them "HTML error" and "HTML warning" than as it is done currently. My main concern is about page authors taking it personal. ;-) The other point is that we'd have to be very accurate. The nesting detection is ok now, but we'd have to start taking into account whether we're dealing with HTML.(version) or XHTML for some messages. > > > I made a minor change to avoid the #ifdefs. > > good idea > > > > Ah, we're now raising a warning when a named entity is not > > found. I don't know whether our list is complete. It'd be good to > > check because we could be giving misleading warnings for a small > > yet unsupported set. > > OK, I'll do it. But give me some days ... -- Cheers Jorge.-

Jan. 5, 2005

[Dillo-dev]Re: styles leak bug

by Jorge Arellano Cid

Hi Roberto, On Sun, Jan 02, 2005 at 01:28:07PM -0500, Roberto Sanchez wrote: > Jorge Arellano Cid wrote: > >=== > > > > Have you had the time to look into the styles leak bug? > > > > Only briefly. I also noticed that it occured on another webpage that > I developing for my church. I will let you know as soon I can figure > something out. Good news: I had some luck with an idea to test the origin of it. It's fixed in the CVS now! I'll try to pack the rc1 tarball tomorrow. -- Cheers Jorge.-

Jan. 4, 2005

Re: [Dillo-dev]2005

by Jeremy Henty

Jorge Arellano Cid wrote: > ... this is mainly a bugfix release and it has proven very > stable as from CVS. Seconded! I pulled down the CVS a few days ago to see if I could generate any bug reports before the -rc1, but it's been rock-solid! Here's to Dillo in 2005! Jeremy Henty

Jan. 4, 2005

Re: [Dillo-dev]new file server dpi in CVS.

by Jorge Arellano Cid

On Thu, Dec 30, 2004 at 10:49:14PM -0500, Brian Hechinger wrote: > On Tue, Dec 28, 2004 at 06:59:07PM -0300, Jorge Arellano Cid wrote: > > Hi Dieter, > > > > I just finished the first prototype for the two-threads-only > > file server dpi. I've had this in mind for sometime because the > > old one, despite solving a deadlock race, used too much threads > > when the page requested too much different files (one per file). > > i haven't looked at it yet, and i appologize for commenting before > doing do, but is this something that could be made configurable? > > i ask only since some machines (a lot that i own anyway *G*) do better > IO than CPU stuff, so doing lots of simultaneous IO would make dillo > faster there. On single-CPU sytems this server will be faster in most cases. On multi-CPU systems I doubt a difference because the threaded tasks are almost pure IO and not CPU-intensive. OTOH, computer architecture magic can surprise anyone! ;-) -- Cheers Jorge.-

Jan. 4, 2005

[Dillo-dev]2005

by Jorge Arellano Cid

Hi there! Please receive my best wishes for this new year. Our project has kept its advancing pace and we're very close to dillo-0.8.4-rc1. There's still a DwStyle leak to investigate and that's it. If it takes more than two days more, I'll pack rc1 anyway to start the testing cycle. This should be a short stage because this is mainly a bugfix release and it has proven very stable as from CVS. The idea is to have 0.8.4 before January 15. Althoug the mailing list has been a bit quiet, there's been good work going on in the background, with some new developers and several patches! (the CVS shows it). If destiny smiles, I could be on FOSDEM 2005 presenting Dillo on the embedded track and making contacts with a view to find a way to finally get a core team working full-time on it, thus boosting the development pace. Please join your best thinking, good wishes, and let's hope the best for this 2005! -- Cheers Jorge.-

Jan. 4, 2005

Re: [Dillo-dev]configurable page increment

by Brian Hechinger

On Sun, Dec 19, 2004 at 03:05:00PM -0700, Scott Scriven wrote: > Hello. hi there! > I'd like to make the page increment configurable. I liked the > old half-page behavior, and would like to be able to use that > instead of the current "96% of the viewport" method. However, I > don't really know where to start, or how to hook into dillo's > configuration system. > > Ideally, I'd like to set values for how much to scroll on each > type of scroll event: PgUp/Dn, Space/BkSpace, arrows, and the > mouse wheel. (96%, 50%, 1 line, and 2 lines, respectively) > > I've found the code which configures one of these events, thanks > to a snippet early on this list ("0.96 * allocation->height"), > but don't know where/how to handle the others. > > So, any hints? Or, alternately, does anyone with more of a clue > feel like adding this? i could possibly be convinced to look into this after i finish the configuration as dpi project (which is getting started today!!!!) -brian -- "Now you know why I got the everliving hell OUT of Windows administration. Knowing it doesn't make it any easier. It's just broken-as-designed."

Jan. 4, 2005

[Dillo-dev]How does CCC handle the parallelism of IO?

by uniharmony＠gmail.com

In my opinion, the CCC is a dynamic doubly linked list with function pointers. And all the CCC functions in the chain are called serially. How does CCC handle the parallelism of IO? And Why do you consider it as "pseudo-thread"? I want to dive in it and thanks for reply.

Jan. 4, 2005