- Dillo-dev - lists.mailman3.com

build fails on CentOS 7

by rdt＠cs.queensu.ca

: Making all in test make[2]: Entering directory `/home/rdt/src/dillo-3.0.4/test' g++ -DHAVE_CONFIG_H -I. -I.. -I.. -I/usr/local/include -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -MT dw_anchors_test.o -MD -MP -MF .deps/dw_anchors_test.Tpo -c -o dw_anchors_test.o dw_anchors_test.cc mv -f .deps/dw_anchors_test.Tpo .deps/dw_anchors_test.Po g++ -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O2 -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dw-anchors-test dw_anchors_test.o ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -Wl,-z,relro -lfltk /bin/ld: ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): undefined reference to symbol 'XCreatePixmap' /bin/ld: note: 'XCreatePixmap' is defined in DSO /lib64/libX11.so.6 so try adding it to the linker command line /lib64/libX11.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status make[2]: *** [dw-anchors-test] Error 1 make[2]: Leaving directory `/home/rdt/src/dillo-3.0.4/test' Bob T.

July 12, 2014

HTTP persistent connections / keep-alive

by eocene＠gmx.com

I wrote, three months ago: > I have been experimenting with persistent connections for http, and > wanted to see what your thoughts were. > > This has been working well enough for me: > http://flpsed.org/hgweb/eocene_persistent_connections/ > > Why? To be a good internet citizen, tcp slow-start, etc. > > Johannes gave it a try and said it performed well. [snip] So I've been using it for three months and I like it. I haven't noticed any problems with it, and I'm planning to merge it in next week -- maybe around the 17th. To enjoy persistent connections, you would have to put http_persistent_conns=YES in dillorc.

July 12, 2014

general uri handler

by dennisn＠dennisn.linuxd.org

On Sat, 5 Jul 2014 12:27:54 +0200, Johannes Hofmann wrote: > On Sat, Jun 28, 2014 at 07:58:20AM -0400, Dennis New wrote: > > How are you guys handling non-builtin uris, like ed2k:, mailto:, > > magnet:, etc? I hacked a general purpose handler (that calls a shell > > script) from dpi/hello.c, but surely something this useful should > > ship with dillo? > > > > It seems that this has been a popular request for a long time :P... > > > > http://lists.dillo.org/pipermail/dillo-dev/2004-October/002403.html > > I mostly use "Copy link location" from the popup menu. > Can you make the source of your general purpose handler availble > somewhere? It was a tiny hack of dpi/hello.c, I also got rid of the dialog box and changed the html output a bit, and didn't bother doing escape character filtering... + Dstr *cmd_arg = dStr_new(""); if (cmd && url) { - child_cmd = dStrdup("date -R"); + dStr_sprintfa(cmd_arg, "dillo-urihandler \"%s\"", url); + child_cmd = dStrdup(cmd_arg->str); MSG("[%s]\n", child_cmd); To make compilation easier, I didn't bother renaming "hello.filter.dpi". And I had to add an entry for each protocol that I wanted to handle in dpidrc... +proto.magnet=bla/hello.filter.dpi +proto.mailto=bla/hello.filter.dpi

July 5, 2014

general uri handler

by Johannes.Hofmann＠gmx.de

On Sat, Jun 28, 2014 at 07:58:20AM -0400, Dennis New wrote: > How are you guys handling non-builtin uris, like ed2k:, mailto:, > magnet:, etc? I hacked a general purpose handler (that calls a shell > script) from dpi/hello.c, but surely something this useful should ship > with dillo? > > It seems that this has been a popular request for a long time :P... > > http://lists.dillo.org/pipermail/dillo-dev/2004-October/002403.html I mostly use "Copy link location" from the popup menu. Can you make the source of your general purpose handler availble somewhere? Cheers, Johannes

July 5, 2014

general uri handler

by dennisn＠dennisn.linuxd.org

How are you guys handling non-builtin uris, like ed2k:, mailto:, magnet:, etc? I hacked a general purpose handler (that calls a shell script) from dpi/hello.c, but surely something this useful should ship with dillo? It seems that this has been a popular request for a long time :P... http://lists.dillo.org/pipermail/dillo-dev/2004-October/002403.html

June 28, 2014

Dicache work

by johannes.hofmann＠gmx.de

Hi Jorge, On Tue, Jun 24, 2014 at 08:32:11AM -0400, Jorge Arellano Cid wrote: > Hi there, > > There're three new dicache patches in the repo. These have > beeen tested/checked with valgrind and gcc's address sanitizer. > > Given the last memory usage reports, and a very necessary > cleanup that was pending for a long time, this patch set tries to > tackle the issue. > > There's also some decompressed image caching enabled (read the > verbose changelog) that will make dillo feel faster. Nice. It really helps especially with the CSS-triggered repushes where we previously were re-decoding the images. Cheers, Johannes

June 25, 2014

Dicache work

by jcid＠dillo.org

Hi there, There're three new dicache patches in the repo. These have beeen tested/checked with valgrind and gcc's address sanitizer. Given the last memory usage reports, and a very necessary cleanup that was pending for a long time, this patch set tries to tackle the issue. There's also some decompressed image caching enabled (read the verbose changelog) that will make dillo feel faster. Please test and send feedback. BTW, I found ways to crash dillo without the patches and wonder whether some of you also experimented image-related crashes. -- Cheers Jorge.-

June 24, 2014

Experimental repository "dillo_grows"

by sgeerken＠dillo.org

Hi! At <http://flpsed.org/hgweb/dillo_grows>, you'll find a version of dillo with some changes in how widget sizes are handled (GROWS stands for Grand Redesign Of Widget Sizes). There is also some doxygen documentation in doc/dw-grows.doc, or html/dw-grows.html. Work on floats is currently stalled since most recent bugs related to floats seem to result from problems addressed in GROWS. Sebastian

June 19, 2014

dicache valgrind log entries

by jcid＠dillo.org

On Fri, May 30, 2014 at 10:28:05AM -0400, Jorge Arellano Cid wrote: > On Fri, May 30, 2014 at 05:19:10AM +0000, eocene wrote: > > > > Jeremy's logs have been showing lots of dicache > > entries in recent days. > > Thanks. I'm working in the dicache now and there plenty > of things to iron out... Besides the "lost" blocks, valgrind also detected an "invalid read" for which I just committed a fix. The interesting part is that commit #3669 didn't introduce it, but just exposed it. -- Cheers Jorge.-

June 8, 2014

dicache valgrind log entries

by jcid＠dillo.org

On Fri, May 30, 2014 at 10:28:05AM -0400, Jorge Arellano Cid wrote: > On Fri, May 30, 2014 at 05:19:10AM +0000, eocene wrote: > > > > Jeremy's logs have been showing lots of dicache > > entries in recent days. > > Thanks. I'm working in the dicache now and there plenty > of things to iron out... Well, it turned out to be much less than it seemed. Just a simple bug in the new code I was working on. On current tree, valgrind reports "definitely lost" DICacheEntry blocks created by Dicache_entry_new(), but in fact, they're not lost. e.g. running: $valgrind --tool=memcheck --leak-check=yes --log-file=valg3678.out \ ./dillo http://lwn.net/ and exiting dillo after the page is fully loaded, reports lost blocks from Dicache_entry_new() (one per image). Now, if you run the same command, wait until the page is fully loaded, then switch to bookmarks and exit, there's no lost block reported. The point is: bookmarks has no images, and once it loads the dicache cleans previous images (from lwn.net) hence valgrind, sees no leaks. There're ways to fine tune valgrind with specific parameters for leak detection, but I don't know them in the necessary depth to chose the correct ones. -- Cheers Jorge.-

June 7, 2014