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

web site partial update

by joerg.sonnenberger＠web.de

On Thu, Aug 28, 2008 at 12:27:57PM -0400, Jorge Arellano Cid wrote: > BTW, what version number should we give to dillo2? > 2.0 seems like a good candidate. Start with 1.99.0 and provide a first real alpha release? Joerg

Aug. 28, 2008

web site partial update

by jcid＠dillo.org

Hi, With a view to prepare our next dillo2 release, the web site has been partially updated. From the links column, these sections: Developers, Users, Related and "Hosted at" are up to date. Even the downloadable alternative icons work, and pages were bug-meter validated too. BTW, what version number should we give to dillo2? 2.0 seems like a good candidate. -- Cheers Jorge.-

Aug. 28, 2008

init_rawdatabuffer is slow.

by jcid＠dillo.org

On Tue, Aug 26, 2008 at 06:13:23PM +0000, corvid wrote: > That's the code that paints the stripes that you see initially in images. > > Here's what gprof said when I loaded a 2 meg jpeg: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 34.76 0.57 0.57 1 570.00 570.00 dw::fltk::init_rawdatabuffer(int, int, int, int, unsigned char > 26.83 1.01 0.44 1536 0.29 0.29 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) > 25.00 1.42 0.41 379 1.08 1.08 dStr_insert_l > 7.32 1.54 0.12 rgb_to_565d(unsigned char const*, unsigned char*, int, int) > 0.61 1.55 0.01 7759 0.00 0.00 lout::container::untyped::Iterator::hasNext() > .. > > > If I take out the init_rawdatabuffer() call and put in a bzero() instead, > I get: > > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls ms/call ms/call name > 51.43 0.54 0.54 1536 0.35 0.36 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) > 34.29 0.90 0.36 373 0.97 0.97 dStr_insert_l > 5.71 0.96 0.06 rgb_to_565d(unsigned char const*, unsigned char*, int, int) > 1.90 0.98 0.02 a_Image_imgbuf_new > 0.95 0.99 0.01 10868 0.00 0.00 lout::container::untyped::Collection0::AbstractIterator::unref() > .. > > > Any objections, then, to having pictures start out black instead of striped? OK, light gray using (memset) was committed as the new interim image background. -- Cheers Jorge.-

Aug. 27, 2008

init_rawdatabuffer is slow.

by corvid＠lavabit.com

That's the code that paints the stripes that you see initially in images. Here's what gprof said when I loaded a 2 meg jpeg: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 34.76 0.57 0.57 1 570.00 570.00 dw::fltk::init_rawdatabuffer(int, int, int, int, unsigned char 26.83 1.01 0.44 1536 0.29 0.29 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) 25.00 1.42 0.41 379 1.08 1.08 dStr_insert_l 7.32 1.54 0.12 rgb_to_565d(unsigned char const*, unsigned char*, int, int) 0.61 1.55 0.01 7759 0.00 0.00 lout::container::untyped::Iterator::hasNext() .. If I take out the init_rawdatabuffer() call and put in a bzero() instead, I get: Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls ms/call ms/call name 51.43 0.54 0.54 1536 0.35 0.36 dw::fltk::FltkImgbuf::copyRow(int, unsigned char const*) 34.29 0.90 0.36 373 0.97 0.97 dStr_insert_l 5.71 0.96 0.06 rgb_to_565d(unsigned char const*, unsigned char*, int, int) 1.90 0.98 0.02 a_Image_imgbuf_new 0.95 0.99 0.01 10868 0.00 0.00 lout::container::untyped::Collection0::AbstractIterator::unref() .. Any objections, then, to having pictures start out black instead of striped?

Aug. 26, 2008

a list of what dillo2 runs on

by corvid＠lavabit.com

Christopher Illies wrote: > On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > > I wonder whether we could get someone for each system who > > would have the responsibility (or, let's say "_glory_" :) > > of responding to "Hey, we changed [some configuration stuff] > > in the latest CVS. Does it work fine on your system?" messages. > > I can take that part for FreeBSD for now and will respond when such > messages are posted to this list. Also, I can do a fresh compile every > two weeks or so. Cool!

Aug. 26, 2008

a list of what dillo2 runs on

by christopher.illies＠ki.se

On Mon, Aug 25, 2008 at 04:14:34PM +0000, corvid wrote: > I wonder whether we could get someone for each system who > would have the responsibility (or, let's say "_glory_" :) > of responding to "Hey, we changed [some configuration stuff] > in the latest CVS. Does it work fine on your system?" messages. I can take that part for FreeBSD for now and will respond when such messages are posted to this list. Also, I can do a fresh compile every two weeks or so. Christopher

Aug. 26, 2008

patch: make prefs.c and dillorc2 consistent

by corvid＠lavabit.com

Jorge wrote: > > In other news, I was just starting to play with the > > mangleme fuzzer that Justus mentioned some months back. > Oh, I missed that email. Where's the fuzzer? earlier thread: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-May/004395.html fuzzer: http://lcamtuf.coredump.cx/soft/mangleme.tgz

Aug. 26, 2008

Re: patch: disallow textarea/button inside select

by jcid＠dillo.org

On Sun, Aug 24, 2008 at 01:25:02AM +0000, corvid wrote: > Putting aside the Stash one for something easy > (with Stash, the html file is like 90K, and it > seems like touching any of it makes the crashing > stop, so...), I find that textarea or button inside > select is bad because close_select assumes that > current input is a select. > > An alternative would be to make close_select > check the current input, but then other > controls aren't supposed to be inside it anyway... > > I feel like we already had this bug and fixed it, > but I must be thinking of whatever specifically made > us add the IN_SELECT test to open_input. We may find a canonical way to implement this constraints in the future (e.g. only OPTION|OPTGROUP in SELECT), maybe inside Html_process_tag()... Committed... -- Cheers Jorge.-

Aug. 25, 2008

patch: make prefs.c and dillorc2 consistent

by jcid＠dillo.org

On Sat, Aug 23, 2008 at 11:30:42PM +0000, corvid wrote: > Jorge wrote: > > BTW, my preference is allow_white_bg=NO, but left it as is > > (YES), waiting for your opinions. > > I had set it to YES because it seemed less surprising for the > people who aren't like me and don't page through dotfiles > when trying software. Yes, that's why I also chose YES in the dillorc. Now, it would be funny if everybody changes it to NO. :-) > In other news, I was just starting to play with the > mangleme fuzzer that Justus mentioned some months back. > It has quickly shown that something is wrong with html->Stash > (e.g. *** glibc detected *** double free or corruption (!prev): 0x08204d28 ***), > but I haven't looked into the problem yet. Oh, I missed that email. Where's the fuzzer? -- Cheers Jorge.-

Aug. 25, 2008

a list of what dillo2 runs on

by jcid＠dillo.org

On Tue, Aug 19, 2008 at 08:22:54PM +0000, corvid wrote: > > The key is to be informative and that page construction > > and updating is a breeze to do. > > > > > Is it officially obsolete, or should parts of Current Plans > > > migrate over there eventually? > > > > I agree that "current plans" fits the goal better. If you can > > think of a _simple_ way to make it better, go ahead. > > > > This is, in principle I agree that removing the achieved goals > > link, and favouring "Current Plans" improves the site. Now, if we > > find a simple way to keep "Current Plans" up to date and not > > bloated, better. > > I haven't been able to think of anything good... in order to > at least have something, though, how about if I add a link like > "Goals reached since last update" to the bottom of achieved goals, > pointing to current plans? > (where they get migrated over hopefully whenever a release is made, > or at least when they are so old that they can no longer be ignored...) ... or we may switch to this scheme: [Current Plans] // as it is [Changelog Highlights] // for last release [Changelog] // full changelog This looks simple to maintain and understand. (removing achieved goals). -- Cheers Jorge.-

Aug. 25, 2008