May 2008 - Dillo-dev - lists.mailman3.com

Re: (working) prototype of charset decoding in cache.c

by jcid＠dillo.org

On Mon, May 26, 2008 at 07:31:14PM +0000, corvid wrote: > Jorge wrote: > > On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > > > [...] > > > > > - a_Cache_[gs]et_content_type and capi and nav. Ugh again. > > > > > I don't know whether there's a timing issue with changing decoders > > > > > due to a meta tag at the same time that a view source window is being > > > > > opened. > > > > > > > > Yes there is. > > > > > > > > Simple to solve by allowing view source after parsing the HEAD > > > > element only. > > > > > > Do you think badly-formed html with, e.g., > > > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > > > is worth worrying about? > > > > This is already handled in the parser. > > But I mean it finishes seeing the first head, enables view source, > user views the source, and then the charset in the second head causes > a repush. Is the parser avoiding that? Yes, once you are IN_BODY, HEAD can't be re-opened, and META doesn't work outside HEAD. > > But now that you mention this, we have to be careful with > > reload. It deletes the entry from the cache before making the > > request. > > > > A simple solution is just to close the view-source window in > > this corner case. > > Ah, yes. Stupid corner cases! :) > > > I was saying that I was pushing around content-type instead of charset > > > because I liked changing it to text/plain in the dialog. > > > If there's no dialog, maybe I'll go back to charset. > > > > > > "View source" as a bw is not a bad idea. It reuses code and > > adds findtext for free, but currently loses the line numbers. > > (which match nicely with the bug meter). > > > > This is a separate problem. > > > > One way to have both features in "View source" is with a dpi > > that gets the source from dillo and sends back an html page. The > > simple way is to prefix line numbers and wrap with PRE. > > > > It can be sent with a no-cache directive, or removed from cache > > upon window close. > > > > The problem of sending back and forth a huge page may be not > > as bad as it looks because huge pages are seldom inspected for > > source from a browser, and it can be handled anyway. > > Maybe adding a callback that stuffs in line numbers before going into > the regular plain callback would work and be tiny. > a_Capi_open_url(Web, our_special_callback, ...) > Oh well, I realize it's premature to dream too hard about > this at this point :) I'd prefer to try the dpi before optimizing. Having one path helps a lot with... Oh, I already gave that lines. ;) The ones that read the paper, please raise your hands. :-) -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by corvid＠lavabit.com

I just remembered that inputs don't have to be in forms according to the spec, so maybe it won't be as easy to move so much to form.cc (unless form.cc is given an html-ui-widgety general sort of name...)

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by corvid＠lavabit.com

Jorge wrote: > On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > > [...] > > > > - a_Cache_[gs]et_content_type and capi and nav. Ugh again. > > > > I don't know whether there's a timing issue with changing decoders > > > > due to a meta tag at the same time that a view source window is being > > > > opened. > > > > > > Yes there is. > > > > > > Simple to solve by allowing view source after parsing the HEAD > > > element only. > > > > Do you think badly-formed html with, e.g., > > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > > is worth worrying about? > > This is already handled in the parser. But I mean it finishes seeing the first head, enables view source, user views the source, and then the charset in the second head causes a repush. Is the parser avoiding that? > But now that you mention this, we have to be careful with > reload. It deletes the entry from the cache before making the > request. > > A simple solution is just to close the view-source window in > this corner case. Ah, yes. Stupid corner cases! > > I was saying that I was pushing around content-type instead of charset > > because I liked changing it to text/plain in the dialog. > > If there's no dialog, maybe I'll go back to charset. > > > "View source" as a bw is not a bad idea. It reuses code and > adds findtext for free, but currently loses the line numbers. > (which match nicely with the bug meter). > > This is a separate problem. > > One way to have both features in "View source" is with a dpi > that gets the source from dillo and sends back an html page. The > simple way is to prefix line numbers and wrap with PRE. > > It can be sent with a no-cache directive, or removed from cache > upon window close. > > The problem of sending back and forth a huge page may be not > as bad as it looks because huge pages are seldom inspected for > source from a browser, and it can be handled anyway. Maybe adding a callback that stuffs in line numbers before going into the regular plain callback would work and be tiny. a_Capi_open_url(Web, our_special_callback, ...) Oh well, I realize it's premature to dream too hard about this at this point :)

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

On Mon, May 26, 2008 at 02:57:09PM -0400, Jorge Arellano Cid wrote: > Committed as: > > inline DilloHtmlForm *getCurrentForm (); Cool, but that name change will break the second patch I just submitted. :-( I'll resubmit a fixed version. Regards, Jeremy Henty

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by jcid＠dillo.org

On Mon, May 26, 2008 at 04:24:37PM +0100, Jeremy Henty wrote: > > This patch adds a DilloHtml::currentForm() method and uses it to > refactor wherever possible. This reduces the number of instances of > the "foo->size() - 1" idiom in html.cc from 23 to 13! Committed as: inline DilloHtmlForm *getCurrentForm (); -- Cheers Jorge.-

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

Here's the next patch: it turns DilloHtmlForm into a class with a constructor and destructor to manage the data members. It depends on the previous patch. Note that this changes DilloHtml slightly to manage DilloHtmlForm pointers instead of DilloHtmlForm structs. This improves consistency as DilloHtml already manages DilloLinkImage and DilloUrl objects by pointers. Next I plan to refactor common code into DilloHtmlForm members just as I did with DilloHtml, then address DilloHtmlInput, DilloHtmlSelect and DilloHtmlOption in the same way. I expect this to be straightforward. Then we will be ready to consider moving the form handling code to a separate file and replacing the DilloHtmlInput case statements with virtual methods. This will probably be trickier and need some more planning. (I already tried once to move out the form handling code and gave up because it is so entangled. Hopefully the above cleanups will make it feasible.) Please comment on the patch and the plan, especially if you have an interest in how html.cc should be cleaned up. Regards, Jeremy Henty

May 26, 2008

Re: (working) prototype of charset decoding in cache.c

by jcid＠dillo.org

On Mon, May 26, 2008 at 03:01:53PM +0000, corvid wrote: > > > [...] > > > - a_Cache_[gs]et_content_type and capi and nav. Ugh again. > > > I don't know whether there's a timing issue with changing decoders > > > due to a meta tag at the same time that a view source window is being > > > opened. > > > > Yes there is. > > > > Simple to solve by allowing view source after parsing the HEAD > > element only. > > Do you think badly-formed html with, e.g., > <head>..</head><body>...</body><head><meta..charset..></head> <body>...</body> > is worth worrying about? This is already handled in the parser. But now that you mention this, we have to be careful with reload. It deletes the entry from the cache before making the request. A simple solution is just to close the view-source window in this corner case. > > > (Why content-type and not charset? I find switching to text/plain to > > > use findtext on the source to be useful.) > > > > Sorry, I don't understand the question. > > I was saying that I was pushing around content-type instead of charset > because I liked changing it to text/plain in the dialog. > If there's no dialog, maybe I'll go back to charset. "View source" as a bw is not a bad idea. It reuses code and adds findtext for free, but currently loses the line numbers. (which match nicely with the bug meter). This is a separate problem. One way to have both features in "View source" is with a dpi that gets the source from dillo and sends back an html page. The simple way is to prefix line numbers and wrap with PRE. It can be sent with a no-cache directive, or removed from cache upon window close. The problem of sending back and forth a huge page may be not as bad as it looks because huge pages are seldom inspected for source from a browser, and it can be handled anyway. -- Cheers Jorge.-

May 26, 2008

[patch] dw2 memory reduction

by joerg.sonnenberger＠web.de

On Mon, May 26, 2008 at 05:01:34PM +0200, Johannes Hofmann wrote: > > On the very long mysql page, addWord is called 1192256 times. But > > due to the allocation in 2^n steps in SimpleVector memory for > > some more of them could be allocated > > structs on 32bit systems are 8 byte aligned. struct Word with > > Argh, structs are 4byte aligned of course! On most sane architectures a structshave the same alignment as the strictest type in it. There's one important exception -- ARM, where the minimal alignment is 16 Byte (IIRC). Joerg

May 26, 2008

[patch]: html.cc cleanup: DilloHtml::currentForm()

by onepoint＠starurchin.org

This patch adds a DilloHtml::currentForm() method and uses it to refactor wherever possible. This reduces the number of instances of the "foo->size() - 1" idiom in html.cc from 23 to 13! Regards, Jeremy Henty

May 26, 2008

[patch] dw2 memory reduction

by Johannes.Hofmann＠gmx.de

On Sun, May 25, 2008 at 06:47:11PM +0200, Johannes Hofmann wrote: > On Sun, May 25, 2008 at 09:12:11AM -0400, Jorge Arellano Cid wrote: > > On Sun, May 25, 2008 at 10:08:12AM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > On Sat, May 24, 2008 at 04:39:42PM -0400, Jorge Arellano Cid wrote: > > > > On Sat, May 24, 2008 at 02:58:08PM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > attached is patch to reduce the memory usage of dw2: > > > > > > > > Excellent! > > > > (AFAIU this is near 30% memory usage reduction in dw2) > > > > > > > > Committed. > > > > > > > > > > > > > > * Styles are now reused if they are equal. This brings down the > > > > > number of Style objects on the mysql page from around 180000 to > > > > > 23000 and reduces memory usage by about 25M at the cost of an > > > > > additional HashTable. > > > > > Maybe the hash table should be part of fltkplatform > > > > > as the hash tables for Color and Font? > > > > > There would be even more sharing of styles possible, if > > > > > x_link would not be part of style. On the other hand about 3M for > > > > > styles on the huge mysql page is pretty ok. > > > > > > > > > > * Size of struct Word is reduced by 4 integers by using shorts. I > > > > > know that this is questionable, but I think in the case of struct > > > > > Word that can be allocated a lot it is worth the hassle. > > > > > Please check whether my assumption that space lengths and word > > > > > lengths can be stored in shorts are valid in general. > > > > > > > > It looks OK at first sight, but to be sure it'd be good to know > > > > what happens when the limit is surpassed. > > > > > > Just tried it on a page with 40000 char long word. With short for > > > hlStart/hlEnd, selection is - obviously - no longer possible. > > > That's clearly a regression. > > > Please revert with attached patch. > > > > A max of 32K for a single word, looks quite reasonable to me. > > I meant, if the browser doesn't crash, and fails gracefully, why > > not. > > > > BTW, it can be extended to 64K with unsigned, by using 65535 as > > sentinel value (instead of -1), but again, is it worth? > > > > It'd be good to know how much "struct Word" is reduced in size > > (after compiler alignment), and how much it impacts overall > > memory usage. I mean if struct word is reduced 20% and that > > yields a 4% overall memory reduction, it may be not worth > > complicating the data type. > > > > OTOH, ... > > On the very long mysql page, addWord is called 1192256 times. But > due to the allocation in 2^n steps in SimpleVector memory for > some more of them could be allocated > structs on 32bit systems are 8 byte aligned. struct Word with Argh, structs are 4byte aligned of course! Cheers, Johannes

May 26, 2008