- Dillo-dev - lists.mailman3.com

occasional bus errors

by corvid＠lavabit.com

Johannes wrote: > is anyone else seeing these rare bus errors? This is not new and > happens every now and then. I'm trying to track it down, but it > would be helpful to have a method to reliably reproduce it. No, I haven't been seeing them here on linux.

June 20, 2008

occasional bus errors

by Johannes.Hofmann＠gmx.de

Hi is anyone else seeing these rare bus errors? This is not new and happens every now and then. I'm trying to track it down, but it would be helpful to have a method to reliably reproduce it. Cheers, Johannes BTW: It's currently the only type of crash I noticed. Program terminated with signal 10, Bus error. #0 0x28595b1a in ?? () (gdb) bt #0 0x28595b1a in ?? () #1 0x0808ec51 in ~DeepIterator (this=0x28565720) at iterator.cc:515 #2 0x08091dc8 in dw::core::SelectionState::resetSelection (this=0x2850a47c) at selection.cc:85 #3 0x08091e20 in dw::core::SelectionState::reset (this=0x2850a47c) at selection.cc:75 #4 0x08091809 in dw::core::Layout::removeWidget (this=0x2850a400) at layout.cc:167 #5 0x080970ff in ~Widget (this=0x285aaf00) at widget.cc:269 #6 0x0807d554 in ~Textblock (this=0x285aaf00) at textblock.cc:117 #7 0x080916c7 in dw::core::Layout::setWidget (this=0x2850a400, widget=0x285b0300) at layout.cc:175 #8 0x08056ddc in a_Web_dispatch_by_type (Type=0x285a4560 "text/html; charset=us-ascii", Web=0x285659c0, Call=0x285958d0, Data=0x285958d4) at web.cc:94 #9 0x08058583 in Cache_process_queue (entry=0x28582400) at cache.c:1042 #10 0x08058d3c in a_Cache_process_dbuf (Op=0, buf=0x2873c000 "HTTP/1.1 200 OK\r\nDate: Fri, 20 Jun 2008 15:51:22 GMT\r\nServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nCache-control: no-cache\r\nConnection: close\r\nTransfer-Encoding: chu"..., buf_size=1440, Url=0x285a1d00) at cache.c:871 #11 0x080564b8 in a_Chain_fcb (Op=134802368, Info=0x285a2e80, Data1=0x285c9ac0, Data2=0x80eb3e3) at chain.c:111 #12 0x080743dc in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x28595b40, Data1=0x285c9200, Data2=0x0) at dpi.c:223 #13 0x080564b8 in a_Chain_fcb (Op=134802368, Info=0x285a2e80, Data1=0x285c9200, Data2=0x0) at chain.c:111 #14 0x08074cfd in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x28595ba0, Data1=0x28595e00, Data2=0x0) at IO.c:418 #15 0x08074e8a in IO_callback (fd=<value optimized out>, io=0x28595e00) at IO.c:205 #16 0x08074f63 in IO_fd_read_cb (fd=4, data=0x20e) at IO.c:291 #17 0x080c28cd in fltk::wait () #18 0x080c2a7d in fltk::run () #19 0x0804e63d in main (argc=-1958539068, argv=0x58390446) at dillo.cc:125

June 20, 2008

easy way to get many root certificates?

by corvid＠lavabit.com

Johannes wrote: > On Fri, Jun 20, 2008 at 02:16:33PM +0000, corvid wrote: > > Joerg wrote: > > > On Fri, Jun 20, 2008 at 05:06:49AM +0000, corvid wrote: > > > > But I don't want to do that over and over for all > > > > of the common root certificates. > > > > > > http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certda… > > > > Is there a quick way to generate certificates from that? > > You may try > > http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/security/mozilla-root… It's working! Thanks guys!

June 20, 2008

easy way to get many root certificates?

by joerg.sonnenberger＠web.de

On Fri, Jun 20, 2008 at 02:16:33PM +0000, corvid wrote: > Joerg wrote: > > On Fri, Jun 20, 2008 at 05:06:49AM +0000, corvid wrote: > > > But I don't want to do that over and over for all > > > of the common root certificates. > > > > http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certda… > > Is there a quick way to generate certificates from that? Yes, but it seems to be broken right now. I'll ask the author of the pkgsrc script to take a look. Joerg

June 20, 2008

[patch] move highlighting data into Textblock

by Johannes.Hofmann＠gmx.de

Hi, attached patch fixes the issue here. I had just recently switched the code from using hlStart[layer].index < 0 to hlStart[layer].index > hlEnd[layer].index to indicate that nothing is highlighted. It turned out that I had forgotten to adapt some parts. In addition this patch cleans up some rough edges. Cheers, Johannes On Thu, Jun 19, 2008 at 06:28:26PM -0400, Jorge Arellano Cid wrote: > On Fri, Jun 20, 2008 at 12:18:12AM +0200, Johannes Hofmann wrote: > > On Thu, Jun 19, 2008 at 03:16:38PM -0400, Jorge Arellano Cid wrote: > > > On Thu, Jun 19, 2008 at 04:32:31PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > as promised here comes a patch to move highlighting information from > > > > struct Word into Textblock to save memory. > > > > I had to change the semantics of the highlighting API slightly (see > > > > comments) to ensure that the highlighted part is always contiguous. > > > > > > > > Here are some measurements (with load_images=NO): > > > > > > > > Page dillo-fltk patched_dillo-fltk dillo1 firefox > > > > ============================================================== > > > > splash 7240K 7236K > > > > xslt [1] 15016K 14220K > > > > freebsd [2] 70264K 58084K > > > > mysql [3] 186M 148M 232M 200M > > > > > > > > Obviously the difference is mostly visible on large pages. And > > > > firefox is pretty close regarding memory usage. However it needed more > > > > than 3 minutes to load the local mysql page compared to 6 seconds > > > > for dillo-fltk! > > > > > > > > Please look out for possible highlight related regressions. > > > > > > With the same msql page: > > > > > > http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz > > > > > > and HUGE_FILESIZE set to 15MB, search for "yen sign". After > > > the fourth match, strange highlights become to happen. > > > > I only have the Euro sign on my keyboard :-) Searching for it works > > fine. Do you know how I can enter the Yen sign? > > No, but I'm talking of the string "yen sign" fed to find text! :-) > > > Can you try whether this issue is new with my patch? > > I did. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 20, 2008

easy way to get many root certificates?

by Johannes.Hofmann＠gmx.de

On Fri, Jun 20, 2008 at 02:16:33PM +0000, corvid wrote: > Joerg wrote: > > On Fri, Jun 20, 2008 at 05:06:49AM +0000, corvid wrote: > > > But I don't want to do that over and over for all > > > of the common root certificates. > > > > http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certda… > > Is there a quick way to generate certificates from that? You may try http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/security/mozilla-root… Cheers, Johannes

June 20, 2008

easy way to get many root certificates?

by corvid＠lavabit.com

Joerg wrote: > On Fri, Jun 20, 2008 at 05:06:49AM +0000, corvid wrote: > > But I don't want to do that over and over for all > > of the common root certificates. > > http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certda… Is there a quick way to generate certificates from that?

June 20, 2008

easy way to get many root certificates?

by joerg.sonnenberger＠web.de

On Fri, Jun 20, 2008 at 05:06:49AM +0000, corvid wrote: > But I don't want to do that over and over for all > of the common root certificates. http://lxr.mozilla.org/mozilla/source/security/nss/lib/ckfw/builtins/certda… Joerg

June 20, 2008

easy way to get many root certificates?

by corvid＠lavabit.com

I'm tired of clicking on the "remote certificate cannot be verified" message. I added a couple of lines to https.c so that it would save certificates. When I encountered the next https page, "openssl x509 -text -in [certificate]" showed that Equifax was the issuer. I got their root certificate, stuck it in .dillo/certs, found the hash value with "openssl x509 -hash -in [certificate]", and linked it to [hash].0. And, hey, no more message! But I don't want to do that over and over for all of the common root certificates. It seems that you can get the certificates out of firefox if you have some program called certutil, but, so far as I can tell, this requires getting a bunch of mozilla code known as NSS that is something like six megs of source. This is nowhere near worth the headaches that would surely result from trying to compile such a thing. So, does anyone happen to know an easy and convenient way to deal with this?

June 20, 2008

[patch] move highlighting data into Textblock

by corvid＠lavabit.com

Jorge wrote: > On Fri, Jun 20, 2008 at 12:18:12AM +0200, Johannes Hofmann wrote: > > I only have the Euro sign on my keyboard :-) Searching for it works > > fine. Do you know how I can enter the Yen sign? > > No, but I'm talking of the string "yen sign" fed to find text! :-) Not entirely on topic, then, but: compose worked well enough for my configuration once I went to fltk::compose() and put the // See if they type the compose prefix key: if (i == RightCtrlKey || i == 0xff20/* Multi-Key */) { compose_state = 1; return true; } ahead of the // Alt+letters are reserved for shortcuts. But alt+foreign letters // has to be allowed, because some key layouts require alt to be held // down in order to type them... if ((e_state & (ALT|META)) && !(ascii & 128)) return false; (my hazy recollection is that Multi_Key turned on META in e_state) Their site wouldn't let me register to bring up the matter, although it probably wouldn't have made any difference anyway (I note that recent talk about 2.0 in fltk.development has a lot of "somebody should" but nobody wants to be that somebody.)

June 20, 2008

[patch] move highlighting data into Textblock

by Johannes.Hofmann＠gmx.de

On Thu, Jun 19, 2008 at 06:28:26PM -0400, Jorge Arellano Cid wrote: > On Fri, Jun 20, 2008 at 12:18:12AM +0200, Johannes Hofmann wrote: > > On Thu, Jun 19, 2008 at 03:16:38PM -0400, Jorge Arellano Cid wrote: > > > On Thu, Jun 19, 2008 at 04:32:31PM +0200, Johannes Hofmann wrote: > > > > Hi, > > > > > > > > as promised here comes a patch to move highlighting information from > > > > struct Word into Textblock to save memory. > > > > I had to change the semantics of the highlighting API slightly (see > > > > comments) to ensure that the highlighted part is always contiguous. > > > > > > > > Here are some measurements (with load_images=NO): > > > > > > > > Page dillo-fltk patched_dillo-fltk dillo1 firefox > > > > ============================================================== > > > > splash 7240K 7236K > > > > xslt [1] 15016K 14220K > > > > freebsd [2] 70264K 58084K > > > > mysql [3] 186M 148M 232M 200M > > > > > > > > Obviously the difference is mostly visible on large pages. And > > > > firefox is pretty close regarding memory usage. However it needed more > > > > than 3 minutes to load the local mysql page compared to 6 seconds > > > > for dillo-fltk! > > > > > > > > Please look out for possible highlight related regressions. > > > > > > With the same msql page: > > > > > > http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz > > > > > > and HUGE_FILESIZE set to 15MB, search for "yen sign". After > > > the fourth match, strange highlights become to happen. > > > > I only have the Euro sign on my keyboard :-) Searching for it works > > fine. Do you know how I can enter the Yen sign? > > No, but I'm talking of the string "yen sign" fed to find text! :-) Ah, I see :-). I can reproduce it now. I will have a look at it. Cheers, Johannes > > > Can you try whether this issue is new with my patch? > > I did. > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 20, 2008

[patch] move highlighting data into Textblock

by jcid＠dillo.org

On Fri, Jun 20, 2008 at 12:18:12AM +0200, Johannes Hofmann wrote: > On Thu, Jun 19, 2008 at 03:16:38PM -0400, Jorge Arellano Cid wrote: > > On Thu, Jun 19, 2008 at 04:32:31PM +0200, Johannes Hofmann wrote: > > > Hi, > > > > > > as promised here comes a patch to move highlighting information from > > > struct Word into Textblock to save memory. > > > I had to change the semantics of the highlighting API slightly (see > > > comments) to ensure that the highlighted part is always contiguous. > > > > > > Here are some measurements (with load_images=NO): > > > > > > Page dillo-fltk patched_dillo-fltk dillo1 firefox > > > ============================================================== > > > splash 7240K 7236K > > > xslt [1] 15016K 14220K > > > freebsd [2] 70264K 58084K > > > mysql [3] 186M 148M 232M 200M > > > > > > Obviously the difference is mostly visible on large pages. And > > > firefox is pretty close regarding memory usage. However it needed more > > > than 3 minutes to load the local mysql page compared to 6 seconds > > > for dillo-fltk! > > > > > > Please look out for possible highlight related regressions. > > > > With the same msql page: > > > > http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz > > > > and HUGE_FILESIZE set to 15MB, search for "yen sign". After > > the fourth match, strange highlights become to happen. > > I only have the Euro sign on my keyboard :-) Searching for it works > fine. Do you know how I can enter the Yen sign? No, but I'm talking of the string "yen sign" fed to find text! :-) > Can you try whether this issue is new with my patch? I did. -- Cheers Jorge.-

June 20, 2008

[patch] move highlighting data into Textblock

by Johannes.Hofmann＠gmx.de

On Thu, Jun 19, 2008 at 03:16:38PM -0400, Jorge Arellano Cid wrote: > On Thu, Jun 19, 2008 at 04:32:31PM +0200, Johannes Hofmann wrote: > > Hi, > > > > as promised here comes a patch to move highlighting information from > > struct Word into Textblock to save memory. > > I had to change the semantics of the highlighting API slightly (see > > comments) to ensure that the highlighted part is always contiguous. > > > > Here are some measurements (with load_images=NO): > > > > Page dillo-fltk patched_dillo-fltk dillo1 firefox > > ============================================================== > > splash 7240K 7236K > > xslt [1] 15016K 14220K > > freebsd [2] 70264K 58084K > > mysql [3] 186M 148M 232M 200M > > > > Obviously the difference is mostly visible on large pages. And > > firefox is pretty close regarding memory usage. However it needed more > > than 3 minutes to load the local mysql page compared to 6 seconds > > for dillo-fltk! > > > > Please look out for possible highlight related regressions. > > With the same msql page: > > http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz > > and HUGE_FILESIZE set to 15MB, search for "yen sign". After > the fourth match, strange highlights become to happen. I only have the Euro sign on my keyboard :-) Searching for it works fine. Do you know how I can enter the Yen sign? Can you try whether this issue is new with my patch? Cheers, Johannes > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 20, 2008

form.cc: more refactoring

by onepoint＠starurchin.org

On Wed, Jun 18, 2008 at 08:35:57AM -0400, Jorge Arellano Cid wrote: > Committed, except 00 and 05. > > 00: The stash buffer may hold a script, in that case parse_stash is not > as clear as parse_entities. Would a better name make the change acceptable? For instance, Html_parse_stash_entries() ? > 05: gives compilation errors: > [...] > form.cc: In function 'void Html_option_finish(DilloHtml*)': > form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* > DilloHtmlSelect::options' is private > form.cc:1918: error: within this context > form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* > DilloHtmlSelect::options' is private > form.cc:1918: error: within this context That's because not committing 00 breaks one of the chunks in 04 so you still have an explicit ->inputs which should have been replaced by a call to getCurrentOption() . I'm appending the missing chunk of 04 and resubmitting 05 . Regards, Jeremy Henty

June 19, 2008

[patch] move highlighting data into Textblock

by jcid＠dillo.org

On Thu, Jun 19, 2008 at 04:32:31PM +0200, Johannes Hofmann wrote: > Hi, > > as promised here comes a patch to move highlighting information from > struct Word into Textblock to save memory. > I had to change the semantics of the highlighting API slightly (see > comments) to ensure that the highlighted part is always contiguous. > > Here are some measurements (with load_images=NO): > > Page dillo-fltk patched_dillo-fltk dillo1 firefox > ============================================================== > splash 7240K 7236K > xslt [1] 15016K 14220K > freebsd [2] 70264K 58084K > mysql [3] 186M 148M 232M 200M > > Obviously the difference is mostly visible on large pages. And > firefox is pretty close regarding memory usage. However it needed more > than 3 minutes to load the local mysql page compared to 6 seconds > for dillo-fltk! > > Please look out for possible highlight related regressions. With the same msql page: http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz and HUGE_FILESIZE set to 15MB, search for "yen sign". After the fourth match, strange highlights become to happen. -- Cheers Jorge.-

June 19, 2008

[patch] fix FltkPlatform destructor

by jcid＠dillo.org

On Thu, Jun 19, 2008 at 05:10:43PM +0200, Johannes Hofmann wrote: > Hi, > > this fixes a small memory leak in FltkPlatform. Committed. -- Cheers Jorge.-

June 19, 2008

[patch] move highlighting data into Textblock

by jcid＠dillo.org

On Thu, Jun 19, 2008 at 04:32:31PM +0200, Johannes Hofmann wrote: > Hi, > > as promised here comes a patch to move highlighting information from > struct Word into Textblock to save memory. > I had to change the semantics of the highlighting API slightly (see > comments) to ensure that the highlighted part is always contiguous. > > Here are some measurements (with load_images=NO): > > Page dillo-fltk patched_dillo-fltk dillo1 firefox > ============================================================== > splash 7240K 7236K > xslt [1] 15016K 14220K > freebsd [2] 70264K 58084K > mysql [3] 186M 148M 232M 200M > > Obviously the difference is mostly visible on large pages. And > firefox is pretty close regarding memory usage. However it needed more > than 3 minutes to load the local mysql page compared to 6 seconds > for dillo-fltk! > > Please look out for possible highlight related regressions. Nice work! Committed. I made some tests here and it looks OK. Now it's in CVS for more testing. -- Cheers Jorge.-

June 19, 2008

Splitting html.cc: what next?

by jcid＠dillo.org

On Wed, Jun 11, 2008 at 06:49:39PM +0100, Jeremy Henty wrote: > On Wed, Jun 11, 2008 at 12:13:13PM -0400, Jorge Arellano Cid wrote: > > > I'd say go with table... > > ...and that's it. > > :-( I was looking forward to more slicing and dicing! ;-) You can keep on polishing! It's just we _may_ need to change some of the parser structure in the future and I didn't want you to polish it throughly and then see it re-structured into something different. -- Cheers Jorge.-

June 19, 2008

[patch] fix FltkPlatform destructor

by Johannes.Hofmann＠gmx.de

Hi, this fixes a small memory leak in FltkPlatform. Johannes

June 19, 2008

9P

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Jun 19, 2008 at 09:58:43AM -0400, Jorge Arellano Cid wrote: > Hi Enrico, > Hi Everybody, > > It took some time to get back to you, but the topics raised are > non trivial. Let's start with the simpler one: > > > > [Keyboard shortcuts] > > > I believe one of the important things that we could support is > > > custom keyboard shortcuts in dillorc. > > > > ACK. Maybe would should go the way Mutt does: it internally > > works with commands, and keystrokes are mapped to commands. > > Perfect for me. > > If you can patch dillo to do that, it'd be great. > > > > [C++] > > > i. - Increase the development team by adding 6+ new developers. > > > ii.- Getting more involved with other projects. > > > > you can add me, as long as no C++ stuff is involved. > > (don't like it's overhead). > > I also don't like C++ and its complexity! > > FLTK2 is in C++ so we had to interface with it. The idea was to > keep C++ to a minimum set of features. > > OTOH, windowing systems and widgets are quite well suited for > the object oriented approach, and in some places it gets simpler > than dealing directly with inheritance in C (as with GTK1). It's true that C++ projects tend to get over designed complex and bloated - more than C projects. And I really like Linus's famous mail on that topic: http://article.gmane.org/gmane.comp.version-control.git/57918 However fltk and even more dillo-fltk are a perfect example that this is not necessarily the case. If used properly C++ can also help to make the code more maintable. The dillo-fltk code is definately worth a look. There's a lot to be learned from it. Cheers, Johannes

June 19, 2008

[patch] move highlighting data into Textblock

by Johannes.Hofmann＠gmx.de

Hi, as promised here comes a patch to move highlighting information from struct Word into Textblock to save memory. I had to change the semantics of the highlighting API slightly (see comments) to ensure that the highlighted part is always contiguous. Here are some measurements (with load_images=NO): Page dillo-fltk patched_dillo-fltk dillo1 firefox ============================================================== splash 7240K 7236K xslt [1] 15016K 14220K freebsd [2] 70264K 58084K mysql [3] 186M 148M 232M 200M Obviously the difference is mostly visible on large pages. And firefox is pretty close regarding memory usage. However it needed more than 3 minutes to load the local mysql page compared to 6 seconds for dillo-fltk! Please look out for possible highlight related regressions. Cheers, Johannes [1] http://www.w3.org/TR/xslt [2] http://www.freebsd.org/doc/en/books/handbook/book.html [3] http://downloads.mysql.com/docs/refman-6.0-en.html.tar.gz

June 19, 2008

9P

by jcid＠dillo.org

Hi Enrico, Hi Everybody, It took some time to get back to you, but the topics raised are non trivial. Let's start with the simpler one: > [Keyboard shortcuts] > > I believe one of the important things that we could support is > > custom keyboard shortcuts in dillorc. > > ACK. Maybe would should go the way Mutt does: it internally > works with commands, and keystrokes are mapped to commands. Perfect for me. If you can patch dillo to do that, it'd be great. > [C++] > > i. - Increase the development team by adding 6+ new developers. > > ii.- Getting more involved with other projects. > > you can add me, as long as no C++ stuff is involved. > (don't like it's overhead). I also don't like C++ and its complexity! FLTK2 is in C++ so we had to interface with it. The idea was to keep C++ to a minimum set of features. OTOH, windowing systems and widgets are quite well suited for the object oriented approach, and in some places it gets simpler than dealing directly with inheritance in C (as with GTK1). > [Translations] > I'm already working on German translation. Are you working on a generic approach to translations or just German? > [CSS] > > * Planning for CSS, floating objects and TABS. > > (this are important features to a nice browsing experience) > > Missing CSS is really bad. > I'm planning to write an universal but small CSS parser > (as an separate library). You may give a look to RCSS by Raph Levien. > [Dillo as a help system] > I'd like to use Dillo for an help system and control center on an > end-user desktop appliance. Therefore I need it to execute certain > commands. But Dillo itself should not fork/exec itself, instead > send the commands to some special daemon via an 9P channel. I'd like to have Dillo as a help system in Debian! > An simple approach could be coding an dpi which just parses the > requested URL and sends the actual command to the exec server > through 9P. But I have to make absolutely sure that commands > can only be sent when coming from certain pages. > > How can I achieve this ? A simple way is to isolate those "certain pages" into a fixed URL scheme (e.g. localhost:8081/admin file:/etc/read_only_directory/) and to check that signature from the dpi. For this to work, you have to send the "requesting URL" to the dpi by using dpip. > [9P] > You might like have a look at Plan9 and how things are done there. > We can learn really much from it :) I gave a read to some docs. and it looks quite interesting. > [...] > I'd prefer a more generic approach: making everything available > via 9P and let separate programs work on that filesystem. > This also allows lot's other funny things, eg. an HTML external > editor which directly operates on an document within an dillo > viewer ;-) The 9P way of interaction is powerful. I like the idea of interfacing to a Javascript VM with 9P, and reusing a proved protocol instead of having to extend/debug dpip. Now, being a 9P newbie, how much (in LOC or KB) does it add to become a 9P server or client? This is my main concern. I'd like to see a sketch of a Dillo help system design using 9P. Currently dpid would provide a Unix socket to command Dillo, and 9P does something quite similar but more generic. The idea of being able to remote-control Dillo from a simple application/script with a 9P interface is more than interesting. For instance: Load URL, Reload, Stop, Open New window, Back, Forward, images on/off, etc. AFAIS, we'd need to make dillo work internally with commands, and then exposing that interface for the external world. If the dillo help system design looks interesting we can start from there. Obviously you have given it some thought in your project so please share your ideas with us. Obviously using 9P to remote-control dillo seems like an overkill, but when it comes to Javascript, or interfacing to external apps. as an HTML viewer, or serving as a GUI, it looks reasonable. Comments are welcomed. -- Cheers Jorge.-

June 19, 2008

recent style/layout segfaults

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 07:21:35PM +0200, Johannes Hofmann wrote: > On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > > Johannes wrote: > > > Comments welcome! I feel a bit uncomfortable proposing a > > > pretty drastic change like this. > > > > Although obviously I don't know the code well, it seems like an improvement. > > After thinking some more about it, I believe this is the right way to > go. My initial patch had some issues though: It was complete > nonsense of course to make the destructor of the derived class > (FltkFont and FltkColor) virtual. It only worked because Font and > Color are derived from lout::Object which already has a virtual > destructor. So in fact the change does not add any additional > virtual methods. > I also decided to keep the interface to dillo2 as it is (the now > unused layout parameter in Style::create()). > > So attached is my official proposal to fix the style related > segfaults that where introduced by my style caching patch. Committed! -- Cheers Jorge.-

June 18, 2008

patch: view gzipped local files

by jcid＠dillo.org

On Sat, Jun 14, 2008 at 04:13:18PM +0000, corvid wrote: > I'd been considering this for a while, but couldn't > decide whether it had any real value. > > Then it occurred to me that if people are often using > dillo as a local document viewer for minimalist systems, > they may value the ability to compress those documents. > Committed. -- Cheers Jorge.-

June 18, 2008

form.cc: more refactoring

by jcid＠dillo.org

On Sat, Jun 14, 2008 at 04:14:32PM +0100, Jeremy Henty wrote: > > A set of small patches that clean up form.cc , mostly to do with > DilloHtmlSelect . > > * refactor by creating new functions: > - a_Html_parse_stash() > - DilloHtmlSelect::ensureSelection() > - DilloHtmlSelect::addOptionsTo() > - DilloHtmlSelect::appendValuesTo() > - DilloHtmlSelect::getCurrentOption() (cf. other getCurrent* methods) > * make DilloHtmlSelect::options private > * rename DilloHtmlInput::getInputValues() to appendValuesTo() (the new > name is more mnemonic and consistent with the DilloHtmlSelect method > above) Committed, except 00 and 05. 00: The stash buffer may hold a script, in that case parse_stash is not as clear as parse_entities. 05: gives compilation errors: [...] form.cc: In function 'void Html_option_finish(DilloHtml*)': form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* DilloHtmlSelect::options' is private form.cc:1918: error: within this context form.cc:184: error: 'lout::misc::SimpleVector<DilloHtmlOption*>* DilloHtmlSelect::options' is private form.cc:1918: error: within this context -- Cheers Jorge.-

June 18, 2008

About the patch for Style-related crashes: +1 !

by onepoint＠starurchin.org

It's gone a little quiet here, I hope everyone's OK! Anyway I just want to register a yes vote for the patch that was proposed last week to fix crashes from inside Style::unref() when closing windows. These crashes were making Dillo almost unusable for me, but I applied the patch on Sunday and life has been blissful ever since. (I sound like one of those awful TV ads, don't I?) The plan was to wait a week for comments before deciding. I hope it gets committed soon because a fix for these crashes is IMHO vital. Regards, Jeremy Henty

June 18, 2008

patch: view gzipped local files

by corvid＠lavabit.com

I'd been considering this for a while, but couldn't decide whether it had any real value. Then it occurred to me that if people are often using dillo as a local document viewer for minimalist systems, they may value the ability to compress those documents.

June 14, 2008

form.cc: more refactoring

by onepoint＠starurchin.org

A set of small patches that clean up form.cc , mostly to do with DilloHtmlSelect . * refactor by creating new functions: - a_Html_parse_stash() - DilloHtmlSelect::ensureSelection() - DilloHtmlSelect::addOptionsTo() - DilloHtmlSelect::appendValuesTo() - DilloHtmlSelect::getCurrentOption() (cf. other getCurrent* methods) * make DilloHtmlSelect::options private * rename DilloHtmlInput::getInputValues() to appendValuesTo() (the new name is more mnemonic and consistent with the DilloHtmlSelect method above) Regards, Jeremy Henty

June 14, 2008

Valgrind: hashing StyleAttr objects accesses uninitialized data

by onepoint＠starurchin.org

On Thu, Jun 12, 2008 at 09:56:49PM +0200, Johannes Hofmann wrote: > On Wed, Jun 11, 2008 at 11:36:29PM +0100, Jeremy Henty wrote: > > BTW, StyleAttrs::initValues() fails to set some other data members > > such as font and color , but fixing this has no effect on the > > valgrind warnings. > > As far as I can see this is intentional. font and color have to be > set explicitely by the caller of Style::create(). And if valgrind > does not complain, that seems to be the case. OK, then it's not a problem. Thanks for checking it out. Regards, Jeremy henty

June 13, 2008

Valgrind: hashing StyleAttr objects accesses uninitialized data

by jcid＠dillo.org

On Thu, Jun 12, 2008 at 09:56:49PM +0200, Johannes Hofmann wrote: > yOn Wed, Jun 11, 2008 at 11:36:29PM +0100, Jeremy Henty wrote: > > On Wed, Jun 11, 2008 at 09:51:17PM +0200, Johannes Hofmann wrote: > > > > > I think even hashValue() should not access uninitialized data. Not > > > only because of the annoying valgrind messages. > > > > Got it! It's StyleAttrs::textAlignChar ! If I add "textAlignChar = > > '.';" to StyleAttrs::initValues() (which StyleAttrs::resetValues() > > already does!) then the valgrind warnings disappear. Only > > a_Html_tag_set_align_attr() sets textAlignChar , but it only does so > > if it sees "align='char'". > > Great. So it's just this inititialization missing. Patchlet > attached. Committed. -- Cheers Jorge.-

June 12, 2008

Valgrind: hashing StyleAttr objects accesses uninitialized data

by Johannes.Hofmann＠gmx.de

yOn Wed, Jun 11, 2008 at 11:36:29PM +0100, Jeremy Henty wrote: > On Wed, Jun 11, 2008 at 09:51:17PM +0200, Johannes Hofmann wrote: > > > I think even hashValue() should not access uninitialized data. Not > > only because of the annoying valgrind messages. > > Got it! It's StyleAttrs::textAlignChar ! If I add "textAlignChar = > '.';" to StyleAttrs::initValues() (which StyleAttrs::resetValues() > already does!) then the valgrind warnings disappear. Only > a_Html_tag_set_align_attr() sets textAlignChar , but it only does so > if it sees "align='char'". Great. So it's just this inititialization missing. Patchlet attached. > > BTW, StyleAttrs::initValues() fails to set some other data members > such as font and color , but fixing this has no effect on the valgrind > warnings. As far as I can see this is intentional. font and color have to be set explicitely by the caller of Style::create(). And if valgrind does not complain, that seems to be the case. Cheers, Johannes

June 12, 2008

Valgrind: hashing StyleAttr objects accesses uninitialized data

by onepoint＠starurchin.org

On Wed, Jun 11, 2008 at 09:51:17PM +0200, Johannes Hofmann wrote: > I will try to fix that. Can you please post some of the errors > reported by valgrind? I've attached four log snippets showing valgrind warnings from: * hashTable::get() * hashTable::put() * hashTable::remove() * StyleAttrs::equals() Regards, Jeremy Henty

June 12, 2008

Valgrind: hashing StyleAttr objects accesses uninitialized data

by onepoint＠starurchin.org

On Wed, Jun 11, 2008 at 09:51:17PM +0200, Johannes Hofmann wrote: > I think even hashValue() should not access uninitialized data. Not > only because of the annoying valgrind messages. Got it! It's StyleAttrs::textAlignChar ! If I add "textAlignChar = '.';" to StyleAttrs::initValues() (which StyleAttrs::resetValues() already does!) then the valgrind warnings disappear. Only a_Html_tag_set_align_attr() sets textAlignChar , but it only does so if it sees "align='char'". BTW, StyleAttrs::initValues() fails to set some other data members such as font and color , but fixing this has no effect on the valgrind warnings. Hope this helps, Jeremy Henty

June 12, 2008

Valgrind: hashing StyleAttr objects accesses uninitialized data

by Johannes.Hofmann＠gmx.de

On Wed, Jun 11, 2008 at 07:41:02PM +0100, Jeremy Henty wrote: > > Ever since StyleAttr objects were cached in a hash to promote sharing, > valgrind has reported nearly 1000 branches dependent on uninitialised > data when dillo renders the splash page. These all come from > StyleAttrs::hashValue() and StyleAttrs::equals() : if I hack > hashValue() to return ((intptr_t) this) and equals() to return (this > == otherAttrs) then the warnings disappear. > > Is this a problem? If these methods are accessing uninitialised data > members then what happens when that data is initialised? The return > values of hashValue() and equals() could change, which sounds like a > potential source of bugs. Even if it's not a bug, if the value of > hashValue() is unpredictable then we might not be sharing StyleAttr > objects as much as we could and so we could be wasting memory. > > If it is correct to have code that raises these warnings, perhaps > there could be a "#define VALGRIND" switch so developers could easily > compile a dillo that doesn't raise them? (It's possible to silence > them with a valgrind suppression file but that is tedious and risks > hiding other warnings. It would be much more straightforward to have > a valgrind-clean version of the code.) > > Comments are welcome, I think even hashValue() should not access uninitialized data. Not only because of the annoying valgrind messages. I will try to fix that. Can you please post some of the errors reported by valgrind? Johannes

June 11, 2008

Valgrind: hashing StyleAttr objects accesses uninitialized data

by onepoint＠starurchin.org

Ever since StyleAttr objects were cached in a hash to promote sharing, valgrind has reported nearly 1000 branches dependent on uninitialised data when dillo renders the splash page. These all come from StyleAttrs::hashValue() and StyleAttrs::equals() : if I hack hashValue() to return ((intptr_t) this) and equals() to return (this == otherAttrs) then the warnings disappear. Is this a problem? If these methods are accessing uninitialised data members then what happens when that data is initialised? The return values of hashValue() and equals() could change, which sounds like a potential source of bugs. Even if it's not a bug, if the value of hashValue() is unpredictable then we might not be sharing StyleAttr objects as much as we could and so we could be wasting memory. If it is correct to have code that raises these warnings, perhaps there could be a "#define VALGRIND" switch so developers could easily compile a dillo that doesn't raise them? (It's possible to silence them with a valgrind suppression file but that is tedious and risks hiding other warnings. It would be much more straightforward to have a valgrind-clean version of the code.) Comments are welcome, Jeremy Henty

June 11, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

On Wed, Jun 11, 2008 at 12:13:13PM -0400, Jorge Arellano Cid wrote: > I'd say go with table... OK, here's the patch. It's a much smaller change than the form.cc patch (table.cc is only 10k) because table parsing is much simpler and form.cc includes form submission code as well as parsing. It doesn't make nearly as much of an impact on the size of html.cc . It also moves more declarations into html_common.hh (stuff to parse colours and lengths and set styles). As before developers will have to " make maintainer-clean ; ./autogen.sh " so that table.cc gets built. > ...and that's it. :-( I was looking forward to more slicing and dicing! ;-) What do others think? Regards, Jeremy Henty

June 11, 2008

recent style/layout segfaults

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 07:21:35PM +0200, Johannes Hofmann wrote: > On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > > Johannes wrote: > > > Comments welcome! I feel a bit uncomfortable proposing a > > > pretty drastic change like this. > > > > Although obviously I don't know the code well, it seems like an improvement. > > After thinking some more about it, I believe this is the right way to > go. My initial patch had some issues though: It was complete > nonsense of course to make the destructor of the derived class > (FltkFont and FltkColor) virtual. It only worked because Font and > Color are derived from lout::Object which already has a virtual > destructor. So in fact the change does not add any additional > virtual methods. > I also decided to keep the interface to dillo2 as it is (the now > unused layout parameter in Style::create()). > > So attached is my official proposal to fix the style related > segfaults that where introduced by my style caching patch. Trying to be practical I'd say: if we don't have a comment in a week let's commit. -- Cheers Jorge.-

June 11, 2008

Splitting html.cc: what next?

by jcid＠dillo.org

On Sun, Jun 08, 2008 at 09:06:07PM +0100, Jeremy Henty wrote: > > Off the top of my head, some suggestions for more files that could > usefully be split out from html.cc: > > - table.cc , handles <table> , <tr> , <td> , <th> > - list.cc , handles <ul> , <ol> , <li> , <dl> , <dt> , <dd> > - text.cc , handles , , , , <strike> > - paragraph.cc , handles , <blockquote> , <center> , <address> > - page.cc , handles <html> , <head> , <title> , <meta> , <body> > > Thoughts? Considering: [...] 16 -rw-r--r-- 1 jcid jcid 14378 2008-06-01 21:59 nav.c 16 -rw-r--r-- 1 jcid jcid 15023 2008-02-29 14:40 png.c 16 -rw-r--r-- 1 jcid jcid 15318 2008-05-25 18:24 prefs.c 20 -rw-r--r-- 1 jcid jcid 16619 2008-06-01 21:59 uicmd.cc 20 -rw-r--r-- 1 jcid jcid 17543 2008-03-29 12:04 url.c 20 -rw-r--r-- 1 jcid jcid 17962 2008-06-01 21:59 capi.c 28 -rw-r--r-- 1 jcid jcid 26697 2008-05-21 18:56 ui.cc 32 -rw-r--r-- 1 jcid jcid 29415 2008-03-15 14:24 gif.c 36 -rw-r--r-- 1 jcid jcid 35558 2008-06-01 22:00 cache.c 64 -rw-r--r-- 1 jcid jcid 59540 2008-06-11 12:01 form.cc 132 -rw-r--r-- 1 jcid jcid 130045 2008-06-10 10:47 html.cc I'd say go with table and that's it. -- Cheers Jorge.-

June 11, 2008

form.cc: refactor DilloHtmlForm::eventHandler()

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 05:38:42PM +0100, Jeremy Henty wrote: > > Three small patches that clean up form event handling: > > 1: refactor file loading into DilloHtmlInput::readFile() > 2: refactor form submission into DilloHtmlForm::submit() > 3: refactor the input logic into DilloHtmlInput::activate() Committed. -- Cheers Jorge.-

June 11, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* Daniel Lord <elektro_news(a)gmx.de> schrieb: Hi, > I like the idea of having dillo CLI operational. May I suggest > having a look at vimperator? It's (in my eyes) beautiful ;) yep, would be cool. But that I could use in my current project (I'm building an DE for unexperienced users). I'd prefer a more generic approach: making everything available via 9P and let separate programs work on that filesystem. This also allows lot's other funny things, eg. an HTML external editor which directly operates on an document within an dillo vierwer ;-) 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/ ---------------------------------------------------------------------

June 11, 2008

RFC: removing the search dialog

by elektro_news＠gmx.de

Hi all, On Sun, 08 Jun 2008, Enrico Weigelt wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> schrieb: > > I believe one of the important things that we could support is > > custom keyboard shortcuts in dillorc. > > ACK. Maybe would should go the way Mutt does: it internally > works with commands, and keystrokes are mapped to commands. > > Such an simple command interpreter would be cool. If Dillo > also provides an 9P server which publishes internal states and > an command channel, it would be even cooler :) > > > * right-click context menus. > > * providing some keyboard shortcuts. > > Both should be configurable. > > > AFAICS multiple dillorc files are simpler. > > ACK I like the idea of having dillo CLI operational. May I suggest having a look at vimperator? It's (in my eyes) beautiful ;) Greetings Daniel

June 10, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > Johannes wrote: > > Comments welcome! I feel a bit uncomfortable proposing a > > pretty drastic change like this. > > Although obviously I don't know the code well, it seems like an improvement. After thinking some more about it, I believe this is the right way to go. My initial patch had some issues though: It was complete nonsense of course to make the destructor of the derived class (FltkFont and FltkColor) virtual. It only worked because Font and Color are derived from lout::Object which already has a virtual destructor. So in fact the change does not add any additional virtual methods. I also decided to keep the interface to dillo2 as it is (the now unused layout parameter in Style::create()). So attached is my official proposal to fix the style related segfaults that where introduced by my style caching patch. Cheers, Johannes

June 10, 2008

form.cc: refactor DilloHtmlForm::eventHandler()

by onepoint＠starurchin.org

Three small patches that clean up form event handling: 1: refactor file loading into DilloHtmlInput::readFile() 2: refactor form submission into DilloHtmlForm::submit() 3: refactor the input logic into DilloHtmlInput::activate() Regards, Jeremy Henty

June 10, 2008

form.cc: select and option classes

by jcid＠dillo.org

On Tue, Jun 10, 2008 at 03:27:11PM +0100, Jeremy Henty wrote: > > Two patches here. > > The first patch turns DilloHtmlSelect and DilloHtmlOption into classes > and implements their constructors and destructors. It also makes > DilloHtmlInput::DilloHtmlInput() responsible for creating the select > object if necessary (as determined by examining the input type) and > removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and > DilloHtmlForm::addInput() . Committed. > The second patch is a small followup that simplifies select handling > elsewhere: instead of checking the input type we check if the input's > select is non-NULL. Not committed. The canonical way is more orthogonal. -- Cheers Jorge.-

June 10, 2008

form.cc: select and option classes

by onepoint＠starurchin.org

Two patches here. The first patch turns DilloHtmlSelect and DilloHtmlOption into classes and implements their constructors and destructors. It also makes DilloHtmlInput::DilloHtmlInput() responsible for creating the select object if necessary (as determined by examining the input type) and removes the select argumentfrom DilloHtmlInput::DilloHtmlInput() and DilloHtmlForm::addInput() . The second patch is a small followup that simplifies select handling elsewhere: instead of checking the input type we check if the input's select is non-NULL. Regards, Jeremy Henty

June 10, 2008

form.cc: private form methods

by jcid＠dillo.org

On Mon, Jun 09, 2008 at 04:14:21PM +0100, Jeremy Henty wrote: > > More C++-ification of form.cc . Most of the static functions > implement the internals of DilloHtmlForm::buildQueryUrl() , so let's > turn them into private DilloHtmlForm methods since nothing else calls > them. > > The first patch makes the changes, the second moves the definitions > around (the diff is a little mangled for some reason but it really > does nothing except move things). Committed. -- Cheers Jorge.-

June 9, 2008

form.cc: private form methods

by onepoint＠starurchin.org

More C++-ification of form.cc . Most of the static functions implement the internals of DilloHtmlForm::buildQueryUrl() , so let's turn them into private DilloHtmlForm methods since nothing else calls them. The first patch makes the changes, the second moves the definitions around (the diff is a little mangled for some reason but it really does nothing except move things). Regards, Jeremy Henty

June 9, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

On Sun, Jun 08, 2008 at 08:26:37PM +0000, corvid wrote: > Sebastian was once thinking of splitting "general parsing and > tokenizing" from "handling HTML specific stuff" in html.c I see splitting out form.cc , table.cc etc. as a step-by-step way of achieving that. The general parsing and tokenizing code would stay in html.cc , and html_common.h would become the generic parser interface. > Are you planning to do more with form.cc, or are you done with it > for now? There's quite a lot of cleaning up and refactoring of to form.cc still to do. I put it on hold and began splitting html.cc because I was getting bored and felt like a change. None of the form.cc work is urgent so I'd be happy to keep it on hold if others want to work on it without being disrupted. There's plenty other things to work on. Regards, Jeremy Henty

June 8, 2008

Splitting html.cc: what next?

by corvid＠lavabit.com

Sebastian was once thinking of splitting "general parsing and tokenizing" from "handling HTML specific stuff" in html.c (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-June/000758.html) Whether that didn't turn out well or he got distracted by other things, I don't know... Are you planning to do more with form.cc, or are you done with it for now?

June 8, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

Off the top of my head, some suggestions for more files that could usefully be split out from html.cc: - table.cc , handles <table> , <tr> , <td> , <th> - list.cc , handles <ul> , <ol> , <li> , <dl> , <dt> , <dd> - text.cc , handles , , , , <strike> - paragraph.cc , handles , <blockquote> , <center> , <address> - page.cc , handles <html> , <head> , <title> , <meta> , <body> Thoughts? Regards, Jeremy Henty

June 8, 2008