- Dillo-dev - lists.mailman3.com

[patch] Search Previous

by jorl17.8＠gmail.com

Qui, 2009-02-05 ?s 20:56 +0000, Jo?o Ricardo Louren?o escreveu: > Qua, 2009-02-04 ?s 10:35 -0300, Jorge Arellano Cid escreveu: > > On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > > > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > > > Hello, > > > > > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > > Greetings. > > > > > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > > > it. > > > > > > > > > > Great. > > > > > > > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > > > > > I must say I have difficulties understanding the code behind > > > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > > > haven't found any bugs, if you find any, please do say. > > > > > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > > > for efficient searching. It is pretty clever but a bit tricky. > > > > > I see some issues in your implementation. E.g. try to search for > > > > > 'ab' in a string 'abababa'. > > > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > > > matches, but once it no longer does you would need to backtrack. > > > > > The easiest but inefficient way to implement searching > > > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > > > algorithm avoids that. > > > > > I think it would be best to adapt search0 somehow to allow backward > > > > > searching - it's more or less the same thing as forward searching > > > > > anyway. Some ugly edge cases when switching between forward and > > > > > backward maybe :-) > > > > > > > > > > Thanks for working on that, > > > > > Johannes > > > > > > > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > > > forwards? > > > > > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > > > compilable, but I might add some tests soon. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jo?o > > > > > > > > Thanks for your answer. > > > > > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > > > got (provisory) working search0Backwards() replacement. How efficient do > > > > you think it is to handle the word by reversing it? Rephrasing that, do > > > > you think there is a 'really' better way of searching backwards, than > > > > reversing the word and searching backwards? As far as code-changes it > > > > takes very few lines and I have a working example of it. However, the > > > > extra reversing work might hit us hard. > > > > > > Reversing the word (needle) we are searching for is no problem. It's supposed > > > to be rather small and we only need to reverse it once. > > > The point is to avoid the backtracking. So that every letter in the > > > text (haystack) is only visited once. > > > > If reversing the needle is all it takes, go ahead. > > If the code is simple and it takes twice the time a forward > > search, go ahead too. Backward search is much less used than > > forward search and it's better to have it than not, and unless > > the delay is annoying there's no compelling need to optimize. > > > > > > Thanks for the answer. > > OK, I think I worked it out, but the string is being reversed everytime > we search backwards, to maintain compatibility with forward searching. > Of course an alternative is to store it as private member, what do you > think? > > I couldn't find any function for reversing a C-String in dillo's code, > so I put my own as a static member in FindtextState, should I move it > elsewhere? > > I tested multiple cases and it seems (to me) that this one is bugless, > maybe you'll find a nasty/dirty bug I caused, but time will tell :) > > Also, the reverse string function was the only one added, all the rest > was only altered. > > Thanks for the support, > > Jo?o (Apart from the fact I didn't attach any patch...) Scratch that, my bad, that patch contained various bugs. The first kind of bug related to a typo which I now fixed. The second kind because of me interpreting code the wrong way and the third one because of the particular case of searching for things either at the beggining or at the end of the page. I think I fixed all of them and have an updated patch, excuse me for my previous mistakes... Jo?o

Feb. 5, 2009

[patch] Search Previous

by jorl17.8＠gmail.com

Qua, 2009-02-04 ?s 10:35 -0300, Jorge Arellano Cid escreveu: > On Wed, Feb 04, 2009 at 08:51:26AM +0100, Hofmann Johannes wrote: > > On Tue, Feb 03, 2009 at 11:54:56PM +0000, Jo?o Ricardo Louren?o wrote: > > > Ter, 2009-02-03 ?s 21:39 +0100, Hofmann Johannes escreveu: > > > > Hello, > > > > > > > > On Tue, Feb 03, 2009 at 07:48:18PM +0000, Jo?o Ricardo Louren?o wrote: > > > > > Greetings. > > > > > > > > > > I 'spotted' a TODO on searching 'backwards' and decided to have a go at > > > > > it. > > > > > > > > Great. > > > > > > > > > > > > > > Basically, I implemented the Search Previous feature. > > > > > > > > > > I must say I have difficulties understanding the code behind > > > > > FindtextState::search0(), so I did not base my code on it at all. Sure > > > > > it could possibly be optimized, but it seems to do the job for now, I > > > > > haven't found any bugs, if you find any, please do say. > > > > > > > > FindtextState implements the Knuth-Morris-Pratt algorithm > > > > http://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm > > > > for efficient searching. It is pretty clever but a bit tricky. > > > > I see some issues in your implementation. E.g. try to search for > > > > 'ab' in a string 'abababa'. > > > > Even more tricky is searching for ababb in abababb, i.e. the prefix > > > > matches, but once it no longer does you would need to backtrack. > > > > The easiest but inefficient way to implement searching > > > > is doing a strcmp() at every text position. The Knuth-Morris-Pratt > > > > algorithm avoids that. > > > > I think it would be best to adapt search0 somehow to allow backward > > > > searching - it's more or less the same thing as forward searching > > > > anyway. Some ugly edge cases when switching between forward and > > > > backward maybe :-) > > > > > > > > Thanks for working on that, > > > > Johannes > > > > > > > > > > > > > > Additionally, I did not set any hotkeys for the search-previous action, > > > > > maybe something like SHIFT+RETURN, since RETURN handles searching > > > > > forwards? > > > > > > > > > > Also, I did not add any tests, and I only altered a line to make them > > > > > compilable, but I might add some tests soon. > > > > > > > > > > Thanks, > > > > > > > > > > Jo?o > > > > > > Thanks for your answer. > > > > > > OK, I am still trying to 'go deep' with the KMP algorithm, but I have > > > got (provisory) working search0Backwards() replacement. How efficient do > > > you think it is to handle the word by reversing it? Rephrasing that, do > > > you think there is a 'really' better way of searching backwards, than > > > reversing the word and searching backwards? As far as code-changes it > > > takes very few lines and I have a working example of it. However, the > > > extra reversing work might hit us hard. > > > > Reversing the word (needle) we are searching for is no problem. It's supposed > > to be rather small and we only need to reverse it once. > > The point is to avoid the backtracking. So that every letter in the > > text (haystack) is only visited once. > > If reversing the needle is all it takes, go ahead. > If the code is simple and it takes twice the time a forward > search, go ahead too. Backward search is much less used than > forward search and it's better to have it than not, and unless > the delay is annoying there's no compelling need to optimize. > > Thanks for the answer. OK, I think I worked it out, but the string is being reversed everytime we search backwards, to maintain compatibility with forward searching. Of course an alternative is to store it as private member, what do you think? I couldn't find any function for reversing a C-String in dillo's code, so I put my own as a static member in FindtextState, should I move it elsewhere? I tested multiple cases and it seems (to me) that this one is bugless, maybe you'll find a nasty/dirty bug I caused, but time will tell :) Also, the reverse string function was the only one added, all the rest was only altered. Thanks for the support, Jo?o

Feb. 5, 2009

[patch]: fix leak in a_Cookies_get_query()

by corvid＠lavabit.com

Jeremy wrote: > This patch stops a_Cookies_get_query() leaking. However, I'm a little > puzzled by the logic here. Why does a_Cookies_get_query() return a > "Cookies2" header even if the cookies DPI returns nothing? Can't it > just return NULL or an empty string? Wouldn't that be cleaner? We return it if we are willing to accept cookies from the server. It indicates that dillo accepts the newer-style cookies. If we don't really want any cookies from them anyway, we return an empty string.

Feb. 5, 2009

[patch]: fix leak in a_Cookies_get_query()

by onepoint＠starurchin.org

This patch stops a_Cookies_get_query() leaking. However, I'm a little puzzled by the logic here. Why does a_Cookies_get_query() return a "Cookies2" header even if the cookies DPI returns nothing? Can't it just return NULL or an empty string? Wouldn't that be cleaner? Regards, Jeremy Henty

Feb. 5, 2009

Re: view stylesheets from page menu

by corvid＠lavabit.com

Johannes wrote: > On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > > To me: It looks more like a developers feature than one for user level. > > Well, not more than "View page source". Yes, the same charge could be levelled against the bug meter. > I think it's important and in the spirit of dillo to make the web as > transparent for the user as possible. Well said. And part of my motivation was that I was thinking of extending what I have now so that I could examine the URLs before loading them.

Feb. 5, 2009

FreeHG performance

by onepoint＠starurchin.org

On Thu, Feb 05, 2009 at 05:52:40AM -0700, Scott Scriven wrote: > Did anyone ever look at launchpad? > > https://launchpad.net/+tour > > It's a "batteries included" type of project infrastructure host, > feature-rich, easy, reliable, and free. It could provide hosting > for almost everything the project needs and provide plenty of > room to grow. Looks good, but I think Dillo would have to migrate away from Mercurial to use it. They use bzr, and although they integrate with some other VCSs, mercurial isn't one of them. Regards, Jeremy Henty

Feb. 5, 2009

FreeHG performance

by dillo-dev＠toykeeper.net

* Jeremy Henty <onepoint(a)starurchin.org> wrote: > On Tue, Feb 03, 2009 at 01:47:48PM +0100, Hofmann Johannes wrote: > > I doubt that setting up a savannah project would take very long. > Really? I just had a look and there's a long checklist. ... Did anyone ever look at launchpad? https://launchpad.net/+tour It's a "batteries included" type of project infrastructure host, feature-rich, easy, reliable, and free. It could provide hosting for almost everything the project needs and provide plenty of room to grow. The tour gives a pretty good overview... it may be a lot to absorb all at once, but it's worth a look. -- Scott

Feb. 5, 2009

Re: view stylesheets from page menu

by Johannes.Hofmann＠gmx.de

On Thu, Feb 05, 2009 at 08:19:03AM -0300, Jorge Arellano Cid wrote: > On Tue, Feb 03, 2009 at 08:00:12PM +0100, Hofmann Johannes wrote: > > Hi corvid, > > > > On Tue, Feb 03, 2009 at 05:13:27PM +0000, corvid wrote: > > > > > > (a rough quick patch just to get feedback) > > > I saw that Jorge added cssUrls, which provided an opportunity... > > > > Very nice! Just one small thing. The stylesheets entry does not get > > disabled on non-CSS pages here. Extending the check like this: > > > > + if (cssUrls && cssUrls->size () > 0) { > > > > helps. > > To me: It looks more like a developers feature than one for user level. Well, not more than "View page source". I think it's important and in the spirit of dillo to make the web as transparent for the user as possible. > > > > BTW: Viewing stylesheets in a normal browser window is really fast > > compared to the fltk text viewer we use for "View page source"! > > Yes, since a long time I've wanted to find some time to turn > "View page source" into a dpi. > > Maybe after the close-tab button I can give it a hand. > Yes, that would be great. Cheers, Johannes > -- > Cheers > Jorge.-

Feb. 5, 2009

FreeHG performance

by jcid＠dillo.org

On Wed, Feb 04, 2009 at 08:31:06PM +0100, Andreas Kemnade wrote: > Hi, > > On Fri, 30 Jan 2009 17:24:56 +0100 > Andreas Kemnade <akemnade(a)tzi.de> wrote: > > > Hi Jorge, > > > > On Fri, 30 Jan 2009 12:22:46 -0300 > > Jorge Arellano Cid <jcid(a)dillo.org> wrote: > > > > > On Fri, Jan 30, 2009 at 01:21:47PM +0000, Jeremy Henty wrote: > > > > > > > > Am I the only one getting very poor performance from FreeHG ? Quite > > > > often I get a 404 Not Found and right now it's hanging. Everyone > > > > confirms that Mercurial itself is really fast and I've seen other > > > > reports criticising FreeHG's performance. Perhaps we should think > > > > about moving host? It's not always easy to find time to devote to > > > > Dillo so it's rather aggravating when that time is wasted just waiting > > > > for a connection to the server. I'm committed enough to grit my teeth > > > > and wait but I can see it putting off would-be contributors. > > > > > > > > Just a thought, > > > > > > Yes, I've also had trouble with it, and when normal it's slower > > > than our Wearlab's CVS. > > > > > > A couple of days ago (while developoing/reviewing patches) I > > > digged a bit on it and it seems that bitbucket is much faster. We > > > can try bitbucket while we find a long term solution (e.g. FSF's > > > savannah is offering Mercurial and Git repos, but the applying > > > process may take some time). > > > > > > At some point in time we should move out from the Wearlab, as > > > it may be closed soon. Currently we need webserver/CGI/python > > > shell accounts and a DCVS (Hg or Git). CGI is quite useful, but > > > we may use another bugtracker too. > > > > > The server which actually hosts the dillo debian and openmoko > > packages should be an alternative. > > At least performance and bandwidth should be no problem. Maybe moving > > hg there is a starting point. > > > ok, try > hg clone http://hg.dillo.org/dillo > > just add entries for hg.dillo.org in your /etc/hosts to point to that server. > 85.214.105.140 hg.dillo.org It works very well! > push access (with ssl) is not set up yet. > When it is done, of course the dns can be changed so that > hg.dillo.org points to the right server. Good. Just let me know when it's done. -- Cheers Jorge.-

Feb. 5, 2009

FreeHG performance

by onepoint＠starurchin.org

On Wed, Feb 04, 2009 at 08:31:06PM +0100, Andreas Kemnade wrote: > ok, try hg clone http://hg.dillo.org/dillo Now *that* was nice and fast! Thanks! Jeremy Henty

Feb. 4, 2009