February 2009 - Dillo-dev - lists.mailman3.com

RE: Free HG performance

by CHalbersma.12＠westminster-mo.edu

Souceforge always seemed pretty good at hosting open souce projects. Of course I could be wrong there. Christopher "Chewy" R. Halbersma

Feb. 6, 2009

[patch]: fix leak in a_Cookies_get_query()

by onepoint＠starurchin.org

On Thu, Feb 05, 2009 at 08:12:25PM +0000, corvid wrote: > Jeremy wrote: > > Why does a_Cookies_get_query() return a "Cookies2" header even if > > the cookies DPI returns nothing? [...] > > 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. OK, thanks for the explanation. Jeremy Henty

Feb. 6, 2009

FreeHG performance

by dillo-dev＠toykeeper.net

* Jeremy Henty <onepoint(a)starurchin.org> wrote: > Looks good, but I think Dillo would have to migrate > away from Mercurial to use it. After using hg for the past couple years and bzr for about a year, I've found bzr to be an upgrade. I still use both on a regular basis, but no longer choose hg for any new projects. The main differences to be aware of are: - Branches are directories instead of labels. Each directory has only one "head", and you switch between branches with "cd". Merging is done like "cd trunk ; bzr merge ../my-bugfix". - There are a lot of plugins available to extend functionality in various ways. A couple I recommend are bzr-gtk ("bzr vis" is a nice way to browse history) and bzr-bisect (helps isolate where bugs were introduced). - It has a concept of a main line of development, and meaningful version numbers. Merges are always explicit, even when hg would merge in-line. This makes feature branches more useful. That last one probably requires a little more explanation. Say you branch from trunk at r100 to add a feature. It requires some major changes, so you break everything while refactoring and spend a few revisions getting it all working again. It takes 10 revisions total. So, you send the changes upstream. They like it. They merge it... And nobody else checked anything in while you were working. Now (in hg) trunk is at r110, with your new feature. And the revision graph ends up being a straight line, so there's no evidence a merge occurred. If anyone tries to use r101 through r109, they'll find that it's all broken. The way bzr handles it is you submit 10 revisions, and when merged, trunk bumps up to r101. The revision graph shows a branch off to the side with 10 changes (r100.1.1 through r100.1.10) and a merge at the end (r101), and the trunk contains only non-broken versions. It makes more sense to me. > They use bzr, and although they integrate with some other > VCSs, mercurial isn't one of them. It's a one-time conversion, instead of the two-way conduit they support for subversion. I tried it just now (using bzr-fastimport) and it worked. The new branch is in my "junk" folder (launchpad equivalent of /tmp/) if anyone wants to try it: bzr branch lp:~toykeeper/+junk/dillo Personally, the main thing I find annoying about bzr is that it's not the easiest thing to type. I use "alias b=bzr" in my shell to fix that. -- Scott

Feb. 5, 2009

[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