- Dillo-dev - lists.mailman3.com

[patch] cleanup ZoneAllocator

by weigelt＠metux.de

* Jorge Arellano Cid <jcid(a)dillo.org> schrieb: > On Mon, Jun 23, 2008 at 07:38:42PM +0200, Johannes Hofmann wrote: > > Hi, > > > > here comes me ZoneAllocator cleanup again. This time without the > > questionable strlen() stuff. > > Committed. BTW: could this allocator live in it's own lib ? Would be nice, to have an universal lib for that, IMHO :) cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

July 4, 2008

Please help me on this...

by jcid＠dillo.org

Hi there, Looking to a future dillo2 release for the public, I was wondering about the main drive behind dillo2. I mean, in this years of Facebook, WebKit, Flash, propietary video codecs, etc. what's the main point behind dillo2? From the objectives: 1.- The democratization of internet information access. 2.- Personal security and privacy. 3.- High software efficiency. The first one is interesting to analyze along the lines that dillo allows to search for tons of information spread through the Internet using low HW requirements and low bandwidth as a dialup. This is reassuring as dillo efectively enables information access to any person under such constraints. The second one is partly attained by not writing to HD and by a non-existent scripting support. The third one is the one to brag about. ;-) Since some time, the thought that enabling dillo2 as a help browser could also bring local information (i.e. in HD) closer to the user came as a powerful one. Having an app. that pops-up in a second and that's quick, responsive and easy to use is certainly a strong drive for a person in search of information (that's why I'd like to see it inside Debian as a help system). In the near future, I'd like to have CSS and proper floating text rendering (DIV element), plus an API as a help browser. There're countries where paying Universitary studies is the state's burden. If a citizen doesn't want to study there, it's a choice. I think the same may happen with dillo, once people know about it, they can choose to use it or not. While thinking about it, these comments surprised me: "Slashdot | What Do You Want On Future Browsers?" http://tech.slashdot.org/article.pl?sid=08/06/30/1845201 (yes, give them a read!) (They're talking from a full featured Firefox basis. I don't know how may of them would like to use something like dillo) Behind a project like ours, there're two communities: developers and users. The main factor to push forward the project is developers and their motivations (in a commercial environment what pushes the development is the money invested and the profit margins/strategy sought). That's why I'm asking you to help me with your views, needs visions on the future of dillo2 these days. With regard to the user community, I'd love to have some feedback from them, but I guess we need to release dillo2 first! :-) -- Cheers Jorge.-

July 3, 2008

[patch] use delete[] where necessary

by jcid＠dillo.org

On Thu, Jul 03, 2008 at 04:14:31PM +0200, Johannes Hofmann wrote: > On Wed, Jul 02, 2008 at 07:14:31PM -0400, Jorge Arellano Cid wrote: > > On Wed, Jul 02, 2008 at 10:38:51PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > attached patch uses delete[] for deleting arrays as required by C++. > > > > Committed. > > > > Hey, a quick test showed memory usage reduction! > > Ah nice. Didn't notice that. But it's quite significative! Around 12% reduction on VSZ and 13% on RSS. And the combined effect of all the memory reduction patches has come to reduce around 50% on RSS and 28% on VSZ in dillo2. Furthermore, when comparing dillo2 with dillo1, dillo2 uses near 45% less memory than dillo1. These are interesting figures. Below is an updated table of the huge page memory usage test case: ----------- Bck/Fwd test %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9672 4144 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun bare 0.2 10376 4756 pts/10 S+ 09:37 0:00 ./dillo-fltk.19Jun dir list 6.9 176176 144776 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun huge page 5.4 123556 113216 pts/10 S+ 09:37 0:02 ./dillo-fltk.19Jun back 7.0 176176 146240 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun forward 5.6 127020 117720 pts/10 S+ 09:37 0:05 ./dillo-fltk.19Jun back 7.0 176172 146240 pts/10 S+ 09:37 0:07 ./dillo-fltk.19Jun forward 5.6 127016 117716 pts/10 S+ 09:37 0:08 ./dillo-fltk.19Jun back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9672 4140 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun bare 0.2 10376 4760 pts/10 S+ 09:26 0:00 ./dillo-fltk.21Jun dir list 5.9 147904 123988 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun huge page 4.9 111668 101944 pts/10 S+ 09:31 0:02 ./dillo-fltk.21Jun back 6.0 147780 124792 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun forward 5.0 115008 105780 pts/10 S+ 09:31 0:05 ./dillo-fltk.21Jun back 6.0 147780 124856 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun forward 5.1 115008 105844 pts/10 S+ 09:31 0:07 ./dillo-fltk.21Jun back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 9676 4084 pts/10 S+ 11:16 0:00 ./dillo-fltk bare 0.2 10464 4768 pts/10 S+ 11:17 0:00 ./dillo-fltk dir list 5.4 136960 112920 pts/10 S+ 11:17 0:04 ./dillo-fltk huge page 4.3 100724 90864 pts/10 S+ 11:17 0:04 ./dillo-fltk back 5.4 136952 113756 pts/10 S+ 11:17 0:09 ./dillo-fltk forward 4.5 104180 94744 pts/10 S+ 11:17 0:09 ./dillo-fltk back 5.4 136888 113776 pts/10 S+ 11:17 0:13 ./dillo-fltk forward 4.5 104116 94764 pts/10 S+ 11:17 0:14 ./dillo-fltk back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.2 9676 4156 pts/13 S+ 14:57 0:00 ./dillo-fltk.03Jul bare 0.2 10300 4588 pts/13 S+ 14:57 0:00 ./dillo-fltk.03Jul dir list 5.0 114852 104808 pts/13 S+ 14:57 0:02 ./dillo-fltk.03Jul huge page 3.9 92196 82840 pts/13 S+ 14:57 0:02 ./dillo-fltk.03Jul back 5.1 117348 107284 pts/13 S+ 14:57 0:04 ./dillo-fltk.03Jul forward 3.9 92260 82972 pts/13 S+ 14:57 0:05 ./dillo-fltk.03Jul back 5.1 117364 107300 pts/13 S+ 14:57 0:07 ./dillo-fltk.03Jul forward 3.9 92260 82972 pts/13 S+ 14:57 0:07 ./dillo-fltk.03Jul back %MEM VSZ RSS TTY STAT START TIME COMMAND 0.1 8408 3524 pts/10 S+ 10:59 0:00 ./dillo1 bare 0.1 24788 3564 pts/10 S+ 11:01 0:00 ./dillo1 dir list 8.7 226996 182220 pts/10 S+ 11:01 0:07 ./dillo1 huge page 6.8 165880 141792 pts/10 S+ 11:01 0:09 ./dillo1 back 8.8 226952 184176 pts/10 S+ 11:01 0:17 ./dillo1 forward 6.9 166264 144024 pts/10 S+ 11:01 0:18 ./dillo1 back 8.8 226968 184216 pts/10 S+ 11:01 0:26 ./dillo1 forward 6.9 166264 144060 pts/10 S+ 11:01 0:27 ./dillo1 back -- Cheers Jorge.-

July 3, 2008

[patch] use delete[] where necessary

by Johannes.Hofmann＠gmx.de

On Wed, Jul 02, 2008 at 07:14:31PM -0400, Jorge Arellano Cid wrote: > On Wed, Jul 02, 2008 at 10:38:51PM +0200, Johannes Hofmann wrote: > > Hi, > > > > attached patch uses delete[] for deleting arrays as required by C++. > > Committed. > > Hey, a quick test showed memory usage reduction! Ah nice. Didn't notice that. Cheers, Johannes

July 3, 2008

[patch] iterator related bugs

by Johannes.Hofmann＠gmx.de

Hi, now I have a reliable way to reproduce the problem. On DragonFly I use debug malloc options, but valgrind should also work. Even without any debug features I can crash dillo that way, but it takes longer. * Choose a rather long page that does not fit on the screen with lot's of links. I use my bookmarks page. * Start the search dialog and enter a very common string e.g. 2 chars and hold the Enter key down. Dillo now scrolls through the page over and over again. * Now click the 1. mouse button and move the mouse like crazy over the scrolling page so arbitrary text gets selected and deselected. That crashes dillo pretty soon for me. Attached patch fixes the problem here. Please test and check for potential memory leaks. BTW, the patch fixes one leak in Iterator::scrollTo(). Cheers, Johannes

July 3, 2008

Re: patch: rm unused dw configure.in options]

by jcid＠dillo.org

On Thu, Jul 03, 2008 at 12:04:26AM +0000, corvid wrote: > Jorge accidentally applied my dw2 configure.in change (sent off-list) > to dillo2 instead, so let's put the libjpeg stuff back in case > anyone needs it: Yes, I should not commit when as tired as yesterday... Fix committed. -- Cheers Jorge.-

July 3, 2008

Re: patch: rm unused dw configure.in options]

by corvid＠lavabit.com

Jorge accidentally applied my dw2 configure.in change (sent off-list) to dillo2 instead, so let's put the libjpeg stuff back in case anyone needs it:

July 3, 2008

[patch] use delete[] where necessary

by jcid＠dillo.org

On Wed, Jul 02, 2008 at 10:38:51PM +0200, Johannes Hofmann wrote: > Hi, > > attached patch uses delete[] for deleting arrays as required by C++. Committed. Hey, a quick test showed memory usage reduction! -- Cheers Jorge.-

July 3, 2008

patch: (any Solarians in the audience?) rm nanosleep solaris workaround

by jcid＠dillo.org

On Tue, Jul 01, 2008 at 09:57:59PM +0000, corvid wrote: > It seems that there was a nanosleep() in src/IO/dpi.c long ago, > but I can't find any nanosleep()s anywhere anymore, so... Committed. Let's hope for somebody to have FLTK2 and dillo2 in Solaris! :) -- Cheers Jorge.-

July 3, 2008

iterator related bugs

by jcid＠dillo.org

On Wed, Jul 02, 2008 at 09:11:12PM +0200, Johannes Hofmann wrote: > Hi, > > while looking for the reason of the rare selection related crashes I > found something that seems like a severe bunch of bugs in the > iterator code. > It might be related to the crash, but I'm not 100% sure yet. > > There is this innocent comment in front of the DeepIterator > constructor in iterator.cc: > > If you want to continue using \em it, pass it->cloneIterator(). > > This means, that the DeepIterator constructor eats up the Iterator it > get's passed a pointer to! > > The evil thing is that every method that passes one of it's > arguments to the DeepIterator constructor inherits this property, > e.g: > > DeepIterator::createVariant() and as a consequence also: > SelectionState::switchLinkToSelection() and > SelectionState::adjustSelection() > > In Iterator::scrollTo() Iterators that are used after being > passed to the DeepIterator constructor. > > In SelectionState::buttonRelease() an iterator that has been passed > to switchLinkToSelection() might be used afterwards as argument to > adjustSelection(). > > I would propose to change the behaviour of the DeepIterator > constructor and always clone its input Iterator. > Better be safe than sorry and the fact that there is already several > bugs related to this shows, that the current behaviour - even if > it's documented - is really dangerous. > > What do you think? I agree with you. This is an API which already has hard-to-find side effects. Set DeepIterator to always clone, and if there's a performance penalty that's worth addressing, we may add a reference-parameter version of the constructor. -- Cheers Jorge.-

July 3, 2008