- Dillo-dev - lists.mailman3.com

[SOLVED] How to do a local install?

by jcid＠dillo.org

On Thu, Jan 22, 2015 at 02:38:34AM -0500, Walter Dnes wrote: > [...] > For future reference, my build script goes like so... > > > #!/bin/bash > # hg clone http://hg.dillo.org/dillo dillo3 > cd /home/waltdnes/dillo/dillo3 > CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" > CXXFLAGS=${CFLAGS} > make clean > git pull > ./autogen.sh > ./configure \ > --prefix=/home/waltdnes/.local \ > --enable-ssl \ > --disable-ipv6 \ > --enable-cookies \ > --enable-png \ > --enable-jpg \ > --enable-gif \ > --enable-threaded-dns \ > --enable-dependency-tracking > make > make install-strip > > To accomadate the "--prefix=/home/waltdnes/.local" I've added > "/home/waltdnes/.local/bin" to my PATH. AFAICS: git pull should be: hg pull hg update -- Cheers Jorge.-

Jan. 22, 2015

[SOLVED] How to do a local install?

by waltdnes＠waltdnes.org

On Thu, Jan 22, 2015 at 12:15:13PM +1300, James C wrote > Hello Walter (via the list, for future readers' reference), > > I think that I'm succeeding in doing what you want. > > I did it with configure options, which I keep in a very small shell script: > > ----- > ./configure --prefix=/Users/jamescone/buildTrees --enable-ssl > --enable-dependency-tracking > ----- > > I also have a very small shell script for setting the build environment: > > -------- > export CFLAGS="-I/opt/local/include -g" > export CXXFLAGS="$CFLAGS -g" > > export LDFLAGS="-L/opt/local/lib -g" > > export PS1='$(echo $PWD\$\ | sed -e " > s#.*versions/## > s#/dillo-jfw01/#:# > ")' > -------- > > Related to the PS1 bit, I have a christmas tree of versions, to try to > keep a variety of partially-done patches separate. Somewhere in my > path, there is a /versions/ subdirectory, and it shows me the > subdirectory inside that, and the path inside the hg checkout. I > started doing that because I was making too many mistakes, doing > things to the wrong subtree. Thanks very much. I'm up and running and Dillo comes up with the "Welcome to Dillo 3.1-dev" splash screen. Now to copy over some settings from my previous dillorc, and start surfing, and (hopefully not too much) bug reporting. For future reference, my build script goes like so... #!/bin/bash # hg clone http://hg.dillo.org/dillo dillo3 cd /home/waltdnes/dillo/dillo3 CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS=${CFLAGS} make clean git pull ./autogen.sh ./configure \ --prefix=/home/waltdnes/.local \ --enable-ssl \ --disable-ipv6 \ --enable-cookies \ --enable-png \ --enable-jpg \ --enable-gif \ --enable-threaded-dns \ --enable-dependency-tracking make make install-strip To accomadate the "--prefix=/home/waltdnes/.local" I've added "/home/waltdnes/.local/bin" to my PATH. -- Walter Dnes <waltdnes at waltdnes.org>

Jan. 22, 2015

a different lines->getRef() segfault

by james.from.wellington＠gmail.com

This, on commit 553bbaa, may be a dup or related. It was exercised by loading this: http://www.inkcartridges.co.nz/brother-hl5350dn-laser-printer (On OSX 10.6.8, as is usual from me.) Regards, James. =================== Assertion failed: (wasAllocated ()), function findLineIndexWhenAllocated, file textblock.cc, line 1634. Program received signal SIGABRT, Aborted. 0x00007fff82c490b6 in __kill () (gdb) bt #0 0x00007fff82c490b6 in __kill () #1 0x00007fff82ce99f6 in abort () #2 0x00007fff82cd69bc in __assert_rtn () #3 0x00000001000647bc in dw::Textblock::findLineIndexWhenAllocated (this=0x11dc7f200, y=0) at textblock.cc:1634 #4 0x0000000100069a63 in dw::Textblock::draw (this=0x11dc7f200, view=0x11dc7f7c0, area=0x7fff5fbfd3b0) at textblock.cc:1791 #5 0x000000010008c4a9 in dw::core::Layout::draw (this=0x11dc7f9c0, view=0x11dc7f7c0, area=0x7fff5fbfd4a0) at layout.cc:696 #6 0x0000000100083ef1 in dw::core::Layout::expose (this=0x11dc7f9c0, view=0x11dc7f7c0, area=0x7fff5fbfd4a0) at layout.hh:317 #7 0x0000000100083652 in dw::fltk::FltkViewBase::draw (this=0x11dc7f7c0, rect=0x7fff5fbfd510, type=dw::fltk::FltkViewBase::DRAW_CLIPPED) at fltkviewbase.cc:174 #8 0x0000000100083843 in dw::fltk::FltkViewBase::draw (this=0x11dc7f7c0) at fltkviewbase.cc:126 #9 0x00000001000bc529 in Fl_Widget::clear_damage () at /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 #10 0x00000001000bc529 in Fl_Group::draw_child (this=<value temporarily unavailable, due to optimizations>, widget=@0x11dc7f7c8) at Fl_Group.cxx:773 #11 0x0000000100074334 in dw::fltk::ui::ComplexButton::draw (this=0x11dc7f710) at fltkcomplexbutton.cc:53 #12 0x00000001000bc529 in Fl_Widget::clear_damage () at /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 #13 0x00000001000bc529 in Fl_Group::draw_child (this=<value temporarily unavailable, due to optimizations>, widget=@0x11dc7f710) at Fl_Group.cxx:773 #14 0x0000000100081e25 in dw::fltk::FltkWidgetView::drawFltkWidget (this=0x102230a60, widget=0x11dc7f710, area=0x7fff5fbfd730) at fltkviewbase.cc:731 #15 0x000000010007a553 in dw::fltk::ui::FltkResource::draw (this=0x11dc7f640, view=0x102230a60, area=0x7fff5fbfd730) at fltkui.cc:230 #16 0x000000010007eedb in dw::fltk::ui::FltkSpecificResource<dw::core::ui::ComplexButtonResource>::draw (this=0x11dc7f5e0, view=0x102230a60, area=0x7fff5fbfd730) at fltkui.cc:329 #17 0x0000000100099da0 in dw::core::ui::Embed::draw (this=0x11dc7fcc0, view=0x102230a60, area=0x7fff5fbfd730) at ui.cc:137 #18 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc7ed10, line=0x11dc7ddd0, view=0x102230a60, area=0x7fff5fbfd860) at textblock.cc:1569 #19 0x0000000100069abd in dw::Textblock::draw (this=0x11dc7ed10, view=0x102230a60, area=0x7fff5fbfd860) at textblock.cc:1799 #20 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca0f10, line=0x11dc7f0b0, view=0x102230a60, area=0x7fff5fbfd990) at textblock.cc:1569 #21 0x0000000100069abd in dw::Textblock::draw (this=0x11dca0f10, view=0x102230a60, area=0x7fff5fbfd990) at textblock.cc:1799 #22 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc4d460, line=0x11dca1730, view=0x102230a60, area=0x7fff5fbfda90) at textblock.cc:1569 #23 0x0000000100069abd in dw::Textblock::draw (this=0x11dc4d460, view=0x102230a60, area=0x7fff5fbfda90) at textblock.cc:1799 #24 0x0000000100061446 in dw::Table::draw (this=0x11dc183f0, view=0x102230a60, area=0x7fff5fbfdb20) at table.cc:383 #25 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc17fd0, line=0x11dca90e0, view=0x102230a60, area=0x7fff5fbfdc50) at textblock.cc:1569 #26 0x0000000100069abd in dw::Textblock::draw (this=0x11dc17fd0, view=0x102230a60, area=0x7fff5fbfdc50) at textblock.cc:1799 #27 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dc48cf0, line=0x10059c490, view=0x102230a60, area=0x7fff5fbfdd80) at textblock.cc:1569 #28 0x0000000100069abd in dw::Textblock::draw (this=0x11dc48cf0, view=0x102230a60, area=0x7fff5fbfdd80) at textblock.cc:1799 #29 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca8410, line=0x10243a560, view=0x102230a60, area=0x7fff5fbfdeb0) at textblock.cc:1569 #30 0x0000000100069abd in dw::Textblock::draw (this=0x11dca8410, view=0x102230a60, area=0x7fff5fbfdeb0) at textblock.cc:1799 #31 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca7c70, line=0x11dca8030, view=0x102230a60, area=0x7fff5fbfdfe0) at textblock.cc:1569 #32 0x0000000100069abd in dw::Textblock::draw (this=0x11dca7c70, view=0x102230a60, area=0x7fff5fbfdfe0) at textblock.cc:1799 #33 0x0000000100069738 in dw::Textblock::drawLine (this=0x11dca5e70, line=0x11dca7e60, view=0x102230a60, area=0x7fff5fbfe0e0) at textblock.cc:1569 #34 0x0000000100069abd in dw::Textblock::draw (this=0x11dca5e70, view=0x102230a60, area=0x7fff5fbfe0e0) at textblock.cc:1799 #35 0x0000000100061446 in dw::Table::draw (this=0x11dcf4460, view=0x102230a60, area=0x7fff5fbfe170) at table.cc:383 #36 0x0000000100069738 in dw::Textblock::drawLine (this=0x10235e1c0, line=0x11dc64c30, view=0x102230a60, area=0x7fff5fbfe2c0) at textblock.cc:1569 #37 0x0000000100069abd in dw::Textblock::draw (this=0x10235e1c0, view=0x102230a60, area=0x7fff5fbfe2c0) at textblock.cc:1799 #38 0x000000010008c4a9 in dw::core::Layout::draw (this=0x1022a7170, view=0x102230a60, area=0x7fff5fbfe3b0) at layout.cc:696 #39 0x0000000100083ef1 in dw::core::Layout::expose (this=0x1022a7170, view=0x102230a60, area=0x7fff5fbfe3b0) at layout.hh:317 #40 0x0000000100083652 in dw::fltk::FltkViewBase::draw (this=0x102230a60, rect=0x7fff5fbfe420, type=dw::fltk::FltkViewBase::DRAW_CLIPPED) at fltkviewbase.cc:174 #41 0x0000000100083843 in dw::fltk::FltkViewBase::draw (this=0x102230a60) at fltkviewbase.cc:126 #42 0x0000000100084d53 in dw::fltk::FltkViewport::draw_area (data=0x102230a60, x=0, y=44, w=1185, h=636) at fltkviewport.cc:187 #43 0x0000000100084f63 in dw::fltk::FltkViewport::draw (this=0x102230a60) at fltkviewport.cc:213 #44 0x00000001000bc529 in Fl_Widget::clear_damage () at /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 #45 0x00000001000bc529 in Fl_Group::draw_child (this=<value temporarily unavailable, due to optimizations>, widget=@0x102230a68) at Fl_Group.cxx:773 #46 0x00000001000bd631 in Fl_Group::draw_children (this=0x10225a6a0) at Fl_Group.cxx:728 #47 0x00000001000bc529 in Fl_Widget::clear_damage () at /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:772 #48 0x00000001000bc529 in Fl_Group::draw_child (this=<value temporarily unavailable, due to optimizations>, widget=@0x10225a6a0) at Fl_Group.cxx:773 #49 0x00000001000bc529 in Fl_Group::draw_child (this=<value temporarily unavailable, due to optimizations>, widget=@0x10053c4a0) at Fl_Group.cxx:772 #50 0x00000001000bd631 in Fl_Group::draw_children (this=0x10053d9f0) at Fl_Group.cxx:728 #51 0x00000001000ddc40 in Fl_Window::draw (this=0x10053d9f0) at Fl_Window_shape.cxx:369 #52 0x00000001000a862e in Fl_X::flush (this=0x1024119a0) at Fl_cocoa.mm:2499 #53 0x00000001000a8703 in -[FLView drawRect:] (self=0x102214ea0, _cmd=<value temporarily unavailable, due to optimizations>, rect={origin = {x = 0, y = 0}, size = {width = 1200, height = 700}}) at Fl_cocoa.mm:2028 #54 0x00007fff8901acc5 in -[NSView _drawRect:clip:] () #55 0x00007fff89019938 in -[NSView _recursiveDisplayAllDirtyWithLockFocus:visRect:] () #56 0x00007fff8901800a in -[NSView _recursiveDisplayRectIfNeededIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:topView:] () #57 0x00007fff890143de in -[NSView _displayRectIgnoringOpacity:isVisibleRect:rectIsVisibleRectForView:] () #58 0x00007fff8918ee77 in -[NSView displayIfNeededIgnoringOpacity] () #59 0x00000001000a8685 in Fl_X::flush (this=0x1024119a0) at Fl_cocoa.mm:2509 #60 0x00000001000aff1f in Fl_Widget::clear_damage () at /Users/jamescone/buildTrees/fltk/fltk-1.3.3/FL/Fl_Widget.H:762 #61 0x00000001000aff1f in Fl::flush () at Fl.cxx:762 #62 0x00000001000ad23c in fl_mac_flush_and_wait (time_to_wait=0) at Fl_cocoa.mm:812 #63 0x00000001000b0025 in Fl::run () at Fl.cxx:589 #64 0x00000001000044c5 in main (argc=1, argv=0x7fff5fbff3f8) at dillo.cc:588 (gdb) On 20/01/2015, eocene <eocene at gmx.com> wrote: > > A new page was just coming in -- seems like the same sort of problem as > last time. > > (gdb) bt > #0 0xb77bb424 in __kernel_vsyscall () > #1 0xb72f9661 in *__GI_raise (sig=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0xb72fca92 in *__GI_abort () at abort.c:92 > #3 0xb72f2878 in *__GI___assert_fail ( > assertion=0x8151afe "i >= 0 && this->num - i > 0", > file=0x8151aee "../lout/misc.hh", line=167, > function=0x8151ba0 "T* lout::misc::SimpleVector<T>::getRef(int) const > [with T = dw::Textblock::Line]") at assert.c:81 > #4 0x080a9040 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( > this=0x953b618, i=-1) at ../lout/misc.hh:167 > #5 0x080a2786 in dw::Textblock::sendSelectionEvent (this=0x916c610, > eventType=dw::core::SelectionState::BUTTON_RELEASE, event=0xbfbb8180) > at textblock.cc:1093 > #6 0x080a24c3 in dw::Textblock::buttonReleaseImpl (this=0x916c610, > event=0xbfbb8180) at textblock.cc:1008 > #7 0x080d8910 in dw::core::Widget::buttonRelease (this=0x916c610, > event=0xbfbb8180) at widget.cc:1027 > #8 0x080cd617 in dw::core::Layout::processMouseEvent (this=0x90fc058, > event=0xbfbb8180, type=dw::core::Layout::BUTTON_RELEASE) at > layout.cc:1234 > #9 0x080cd00e in dw::core::Layout::buttonEvent (this=0x90fc058, > type=dw::core::Layout::BUTTON_RELEASE, view=0x90f9f60, numPressed=1, > x=127, y=180, state=0, button=1) at layout.cc:1023 > #10 0x080c46ae in dw::core::Layout::buttonRelease (this=0x90fc058, > view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) > at layout.hh:345 > #11 0x080c33f7 in dw::fltk::FltkViewBase::handle (this=0x90f9f60, event=2) > at fltkviewbase.cc:319 > #12 0x080c5e8a in dw::fltk::FltkViewport::handle (this=0x90f9f60, event=2) > at fltkviewport.cc:331 > #13 0x080ded22 in send(int, Fl_Widget*, Fl_Window*) () > #14 0x080dfbaf in Fl::handle_(int, Fl_Window*) () > #15 0x080dff0e in Fl::handle(int, Fl_Window*) () > #16 0x08107e9d in fl_handle(_XEvent const&) () > #17 0x08107fbc in do_queued_events() () > #18 0x0810822a in fl_wait(double) () > #19 0x080e08af in Fl::wait(double) () > #20 0x080e099d in Fl::run() () > #21 0x08052f7a in main (argc=1, argv=0xbfbb8854) at dillo.cc:588 > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 22, 2015

How to do a local install?

by james.from.wellington＠gmail.com

Hello Walter (via the list, for future readers' reference), I think that I'm succeeding in doing what you want. I did it with configure options, which I keep in a very small shell script: ----- ./configure --prefix=/Users/jamescone/buildTrees --enable-ssl --enable-dependency-tracking ----- I also have a very small shell script for setting the build environment: -------- export CFLAGS="-I/opt/local/include -g" export CXXFLAGS="$CFLAGS -g" export LDFLAGS="-L/opt/local/lib -g" export PS1='$(echo $PWD\$\ | sed -e " s#.*versions/## s#/dillo-jfw01/#:# ")' -------- Related to the PS1 bit, I have a christmas tree of versions, to try to keep a variety of partially-done patches separate. Somewhere in my path, there is a /versions/ subdirectory, and it shows me the subdirectory inside that, and the path inside the hg checkout. I started doing that because I was making too many mistakes, doing things to the wrong subtree. Regards, James. On 22/01/2015, Walter Dnes <waltdnes at waltdnes.org> wrote: > It's taken me a while to get around to trying to install from the git > repository. With experimental stuff, I prefer to do things in my local > directory, so that if it blows up, it doesn't blow up with root > permissions. I've done this in the past with other software, so I think > it can be done. Note that I'm running in Gentoo, if it makes any > difference. I have fltk-1.3.2 installed with USE="opengl threads xft" > enabled and other fltk options disabled. Here's my > /home/waltdnes/dillo/dbuild script, which I've loosely based on > instructions at http://www.dillo.org/source.html After the initial > "hg clone" command, updates are pulled in by "git pull" from inside the > dillo3 directory; is that correct? > > #!/bin/bash > # hg clone http://hg.dillo.org/dillo dillo3 > cd /home/waltdnes/dillo/dillo3 > PREFIX=/home/waltdnes/.local > CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables > -fno-asynchronous-unwind-tables" > CXXFLAGS=${CFLAGS} > make clean > git pull > ./autogen.sh > ./configure > make > make install-strip > > The process works until the last step, where it's suggested to sudo, > to allow installing in /usr/local It fails like so... > > make[4]: Entering directory '/home/waltdnes/dillo/dillo3/src' > /bin/mkdir -p '/usr/local/bin' > /bin/sh /home/waltdnes/dillo/dillo3/install-sh -c -s dillo > '/usr/local/bin' > cp: cannot create regular file '/usr/local/bin/_inst.22011_': Permission > denied > Makefile:538: recipe for target 'install-binPROGRAMS' failed > make[4]: *** [install-binPROGRAMS] Error 1 > make[4]: Leaving directory '/home/waltdnes/dillo/dillo3/src' > Makefile:856: recipe for target 'install-am' failed > make[3]: *** [install-am] Error 2 > make[3]: Leaving directory '/home/waltdnes/dillo/dillo3/src' > Makefile:695: recipe for target 'install-recursive' failed > make[2]: *** [install-recursive] Error 1 > make[2]: Leaving directory '/home/waltdnes/dillo/dillo3/src' > Makefile:469: recipe for target 'install-recursive' failed > make[1]: *** [install-recursive] Error 1 > make[1]: Leaving directory '/home/waltdnes/dillo/dillo3' > Makefile:767: recipe for target 'install-strip' failed > make: *** [install-strip] Error 2 > > What settings do I need to make to get the install totally in my home > directory? While I'm at it, what are the manual tweaks to enable > "gif jpeg png ssl" and disable "-doc -ipv6" in the build? Can all the > settings be put into local.mk, so I can "set it and forget it"? > > -- > Walter Dnes <waltdnes at waltdnes.org> > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 21, 2015

How to do a local install?

by waltdnes＠waltdnes.org

It's taken me a while to get around to trying to install from the git repository. With experimental stuff, I prefer to do things in my local directory, so that if it blows up, it doesn't blow up with root permissions. I've done this in the past with other software, so I think it can be done. Note that I'm running in Gentoo, if it makes any difference. I have fltk-1.3.2 installed with USE="opengl threads xft" enabled and other fltk options disabled. Here's my /home/waltdnes/dillo/dbuild script, which I've loosely based on instructions at http://www.dillo.org/source.html After the initial "hg clone" command, updates are pulled in by "git pull" from inside the dillo3 directory; is that correct? #!/bin/bash # hg clone http://hg.dillo.org/dillo dillo3 cd /home/waltdnes/dillo/dillo3 PREFIX=/home/waltdnes/.local CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe -fno-unwind-tables -fno-asynchronous-unwind-tables" CXXFLAGS=${CFLAGS} make clean git pull ./autogen.sh ./configure make make install-strip The process works until the last step, where it's suggested to sudo, to allow installing in /usr/local It fails like so... make[4]: Entering directory '/home/waltdnes/dillo/dillo3/src' /bin/mkdir -p '/usr/local/bin' /bin/sh /home/waltdnes/dillo/dillo3/install-sh -c -s dillo '/usr/local/bin' cp: cannot create regular file '/usr/local/bin/_inst.22011_': Permission denied Makefile:538: recipe for target 'install-binPROGRAMS' failed make[4]: *** [install-binPROGRAMS] Error 1 make[4]: Leaving directory '/home/waltdnes/dillo/dillo3/src' Makefile:856: recipe for target 'install-am' failed make[3]: *** [install-am] Error 2 make[3]: Leaving directory '/home/waltdnes/dillo/dillo3/src' Makefile:695: recipe for target 'install-recursive' failed make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory '/home/waltdnes/dillo/dillo3/src' Makefile:469: recipe for target 'install-recursive' failed make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory '/home/waltdnes/dillo/dillo3' Makefile:767: recipe for target 'install-strip' failed make: *** [install-strip] Error 2 What settings do I need to make to get the install totally in my home directory? While I'm at it, what are the manual tweaks to enable "gif jpeg png ssl" and disable "-doc -ipv6" in the build? Can all the settings be put into local.mk, so I can "set it and forget it"? -- Walter Dnes <waltdnes at waltdnes.org>

Jan. 21, 2015

Dillo CPU-hog lock on slashdot

by james.from.wellington＠gmail.com

Hello Jorge et al, Partly reproduced on OSX, on a branch that includes the repository up to 26 October, and eocene's SSL patch. The CPU and memory use is reasonable, but the stop icon does not turn grey. Fields on the right show "8 of 9" in black and "264.5 KB" in grey. Reproduced on OSX with the tip (changeset 553bbaa) of the default branch. Uses 100% of cpu and does not respond to Cmd-Q quit request. Fields on the right show "5 of 10" in black and "181.4 KB" in grey. Because the window won't scroll, it's hard to tell how much has rendered. Ignorant GDB exploring below. It seems to be struggling with word-wrap, tables, etc. Bin-packing is in NP-hard. I wonder what the right algorithm is for good table rendering. Regards, James. =============== Program received signal SIGINT, Interrupt. 0x00000001000a09f9 in lout::container::untyped::HashSet::calcHashValue (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.hh:242 242 return abs(object->hashValue()) % tableSize; (gdb) bt #0 0x00000001000a09f9 in lout::container::untyped::HashSet::calcHashValue (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.hh:242 #1 0x000000010009eeb9 in lout::container::untyped::HashSet::findNode (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.cc:497 #2 0x000000010009f2e3 in lout::container::untyped::HashTable::get (this=0x116b1bd90, key=0x7fff5fbfdb80) at container.cc:704 #3 0x000000010005d83c in lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) at container.hh:524 #4 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock (this=0x116b1bb60, textblock=0x116bf7270) at outofflowmgr.cc:1954 #5 0x0000000100059ad5 in dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x116bf64c0) at outofflowmgr.cc:291 #6 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, end=38, comparator=0x7fff5fbfdd80) at container.cc:239 #7 0x000000010005de36 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:159 #8 0x000000010005de6b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:456 #9 0x000000010005b27f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:340 #10 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 #11 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 #12 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 #13 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 #14 0x0000000100071f2b in dw::Textblock::balanceBreakPosAndHeight (this=0x116bf7270, wordIndex=0, firstIndex=0, searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:910 #15 0x00000001000729d2 in dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:746 #16 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 #17 0x00000001000701b7 in dw::Textblock::rewrap (this=0x116bf7270) at textblock_linebreaking.cc:1891 #18 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116bf7270, requisition=0x116bf7600) at textblock.cc:341 #19 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf7270, requisition=0x116bf7600) at widget.cc:494 #20 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf6ce0) at textblock_linebreaking.cc:1889 #21 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116bf6ce0, requisition=0x116bf8ac0) at textblock.cc:341 #22 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf6ce0, requisition=0x116bf8ac0) at widget.cc:494 #23 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf67c0) at textblock_linebreaking.cc:1889 #24 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116bf67c0, requisition=0x11713ac20) at textblock.cc:341 #25 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf67c0, requisition=0x11713ac20) at widget.cc:494 #26 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf57d0) at textblock_linebreaking.cc:1889 #27 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116bf57d0, requisition=0x117119680) at textblock.cc:341 #28 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf57d0, requisition=0x117119680) at widget.cc:494 #29 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf5590) at textblock_linebreaking.cc:1889 #30 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116bf5590, requisition=0x116bf5d80) at textblock.cc:341 #31 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf5590, requisition=0x116bf5d80) at widget.cc:494 #32 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf3c80) at textblock_linebreaking.cc:1889 #33 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116bf3c80, requisition=0x100941240) at textblock.cc:341 #34 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf3c80, requisition=0x100941240) at widget.cc:494 #35 0x0000000100070199 in dw::Textblock::rewrap (this=0x102277cd0) at textblock_linebreaking.cc:1889 #36 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x102277cd0, requisition=0x1009435c0) at textblock.cc:341 #37 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x102277cd0, requisition=0x1009435c0) at widget.cc:494 #38 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d7f0) at textblock_linebreaking.cc:1889 #39 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1d7f0, requisition=0x116b1daa0) at textblock.cc:341 #40 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1d7f0, requisition=0x116b1daa0) at widget.cc:494 #41 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d060) at textblock_linebreaking.cc:1889 #42 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1d060, requisition=0x116b1d3c0) at textblock.cc:341 #43 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1d060, requisition=0x116b1d3c0) at widget.cc:494 #44 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1ca30) at textblock_linebreaking.cc:1889 #45 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1ca30, requisition=0x116b1cd80) at textblock.cc:341 #46 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1ca30, requisition=0x116b1cd80) at widget.cc:494 #47 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1c570) at textblock_linebreaking.cc:1889 #48 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1c570, requisition=0x117125040) at textblock.cc:341 #49 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1c570, requisition=0x117125040) at widget.cc:494 #50 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b9b0) at textblock_linebreaking.cc:1889 #51 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1b9b0, requisition=0x116b1c180) at textblock.cc:341 #52 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1b9b0, requisition=0x116b1c180) at widget.cc:494 #53 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b4f0) at textblock_linebreaking.cc:1889 #54 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1b4f0, requisition=0x116b1b6f4) at textblock.cc:341 #55 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1b4f0, requisition=0x116b1b6f4) at widget.cc:494 #56 0x0000000100058685 in dw::OutOfFlowMgr::ensureFloatSize (this=0x1022478e0, vloat=0x116b1b6a0) at outofflowmgr.cc:2272 #57 0x000000010005b067 in dw::OutOfFlowMgr::tellFloatPosition (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1534 #58 0x000000010005b1dc in dw::OutOfFlowMgr::tellPosition (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1516 #59 0x0000000100072aef in dw::Textblock::wrapWordInFlow (this=0x116b1ad70, wordIndex=1, wrapAll=true) at textblock_linebreaking.cc:788 #60 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116b1ad70, wordIndex=1, wrapAll=true) at textblock_linebreaking.cc:606 #61 0x000000010006fbb2 in dw::Textblock::showMissingLines (this=0x116b1ad70) at textblock_linebreaking.cc:2113 #62 0x000000010006b230 in dw::Textblock::sizeRequestImpl (this=0x116b1ad70, requisition=0x10095b450) at textblock.cc:342 #63 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1ad70, requisition=0x10095b450) at widget.cc:494 #64 0x0000000100070199 in dw::Textblock::rewrap (this=0x10210cdf0) at textblock_linebreaking.cc:1889 #65 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x10210cdf0, requisition=0x1009597c0) at textblock.cc:341 #66 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x10210cdf0, requisition=0x1009597c0) at widget.cc:494 #67 0x0000000100070199 in dw::Textblock::rewrap (this=0x10054a2c0) at textblock_linebreaking.cc:1889 #68 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x10054a2c0, requisition=0x7fff5fbff040) at textblock.cc:341 #69 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x10054a2c0, requisition=0x7fff5fbff040) at widget.cc:494 #70 0x00000001000586cc in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x1022478e0, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #71 0x000000010005b757 in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x1022478e0, caller=0x10054a2c0) at outofflowmgr.cc:651 #72 0x000000010006ae82 in dw::Textblock::sizeAllocateImpl (this=0x10054a2c0, allocation=0x7fff5fbff240) at textblock.cc:757 #73 0x000000010009cfb2 in dw::core::Widget::sizeAllocate (this=0x10054a2c0, allocation=0x7fff5fbff240) at widget.cc:993 #74 0x000000010008e4ff in dw::core::Layout::resizeIdle (this=0x105109370) at layout.cc:912 #75 0x0000000100076d9e in dw::fltk::FltkPlatform::generalIdle (this=0x1051091c0) at fltkplatform.cc:627 #76 0x0000000100076def in dw::fltk::FltkPlatform::generalStaticIdle (data=0x1051091c0) at fltkplatform.cc:617 #77 0x00000001000ad21e in fl_mac_flush_and_wait (time_to_wait=1e+20) at Fl_cocoa.mm:806 #78 0x00000001000b0025 in Fl::run () at Fl.cxx:589 #79 0x00000001000044c5 in main (argc=1, argv=0x7fff5fbff3f8) at dillo.cc:588 (gdb) finish Run till exit from #0 0x00000001000a09f9 in lout::container::untyped::HashSet::calcHashValue (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.hh:242 0x000000010009eeb9 in lout::container::untyped::HashSet::findNode (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.cc:497 497 int h = calcHashValue(object); Value returned is $1 = 176 (gdb) Run till exit from #0 0x000000010009eeb9 in lout::container::untyped::HashSet::findNode (this=0x116b1bd90, object=0x7fff5fbfdb80) at container.cc:497 0x000000010009f2e3 in lout::container::untyped::HashTable::get (this=0x116b1bd90, key=0x7fff5fbfdb80) at container.cc:704 704 Node *node = findNode(key); Value returned is $2 = ('lout::container::untyped::HashSet::Node' *) 0x116bf7500 (gdb) Run till exit from #0 0x000000010009f2e3 in lout::container::untyped::HashTable::get (this=0x116b1bd90, key=0x7fff5fbfdb80) at container.cc:704 0x000000010005d83c in lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) at container.hh:524 524 { return (V*)((untyped::HashTable*)this->base)->get(key); } Value returned is $3 = ('lout::object::Object' *) 0x116bf73f0 (gdb) Run till exit from #0 0x000000010005d83c in lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) at container.hh:524 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock (this=0x116b1bb60, textblock=0x116bf7270) at outofflowmgr.cc:1954 1954 TBInfo *tbInfo = tbInfosByTextblock->get (&key); Value returned is $4 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116bf73f0 (gdb) Run till exit from #0 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock (this=0x116b1bb60, textblock=0x116bf7270) at outofflowmgr.cc:1954 0x0000000100059ad5 in dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x116bf64c0) at outofflowmgr.cc:291 291 TBInfo *t1 = oofm->getTextblock (f1->generatingBlock), Value returned is $5 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116bf73f0 (gdb) Run till exit from #0 0x0000000100059ad5 in dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x116bf64c0) at outofflowmgr.cc:291 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, end=38, comparator=0x7fff5fbfdd80) at container.cc:239 239 int c = comparator->compare (key, array[index]); Value returned is $6 = -4 (gdb) Run till exit from #0 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, end=38, comparator=0x7fff5fbfdd80) at container.cc:239 0x000000010005de36 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:159 159 { return bsearch (key, mustExist, 0, size () - 1, comparator); } Value returned is $7 = 32 (gdb) Run till exit from #0 0x000000010005de36 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:159 0x000000010005de6b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:456 456 comparator); } Value returned is $8 = 32 (gdb) Run till exit from #0 0x000000010005de6b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:456 0x000000010005b27f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:340 340 int i = bsearch (&key, false, &comparator); Value returned is $9 = 32 (gdb) Run till exit from #0 0x000000010005b27f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:340 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 424 int last = findFloatIndex (lastGB, lastExtIndex); Value returned is $10 = 31 (gdb) Run till exit from #0 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 2115 int first = list->findFirst (textblock, y, h, lastGB, lastExtIndex, NULL); Value returned is $11 = 29 (gdb) Run till exit from #0 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 2092 bool b = hasFloat (textblock, LEFT, y, h, lastGB, lastExtIndex); Value returned is $12 = true (gdb) Run till exit from #0 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, textblock=0x116bf7270, y=330882, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 2045 effOofRef); Value returned is $13 = true (gdb) Run till exit from #0 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 dw::Textblock::balanceBreakPosAndHeight (this=0x116bf7270, wordIndex=0, firstIndex=0, searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 912 newLineHasFloatLeft || newLineHasFloatRight : false; (gdb) Run till exit from #0 dw::Textblock::balanceBreakPosAndHeight (this=0x116bf7270, wordIndex=0, firstIndex=0, searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:749 749 int yNewLine = yOffsetOfLineToBeCreated (); (gdb) Run till exit from #0 dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:749 ^C Program received signal SIGINT, Interrupt. 0x000000010005d834 in lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) at container.hh:524 524 { return (V*)((untyped::HashTable*)this->base)->get(key); } (gdb) finish Run till exit from #0 0x000000010005d834 in lout::container::typed::HashTable<lout::object::TypedPointer<dw::Textblock>, dw::OutOfFlowMgr::TBInfo>::get (this=0x116b1bd80, key=0x7fff5fbfdb80) at container.hh:524 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock (this=0x116b1bb60, textblock=0x116b1b9b0) at outofflowmgr.cc:1954 1954 TBInfo *tbInfo = tbInfosByTextblock->get (&key); Value returned is $14 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116b1bf10 (gdb) Run till exit from #0 0x00000001000587fd in dw::OutOfFlowMgr::getTextblock (this=0x116b1bb60, textblock=0x116b1b9b0) at outofflowmgr.cc:1954 0x0000000100059aee in dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x117126ff0) at outofflowmgr.cc:292 292 *t2 = oofm->getTextblock (f2->generatingBlock); Value returned is $15 = ('dw::OutOfFlowMgr::TBInfo' *) 0x116b1bf10 (gdb) Run till exit from #0 0x0000000100059aee in dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fff5fbfdd80, o1=0x7fff5fbfdd10, o2=0x117126ff0) at outofflowmgr.cc:292 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, end=38, comparator=0x7fff5fbfdd80) at container.cc:239 239 int c = comparator->compare (key, array[index]); Value returned is $16 = -2 (gdb) Run till exit from #0 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, start=0, end=38, comparator=0x7fff5fbfdd80) at container.cc:239 0x000000010005de36 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:159 159 { return bsearch (key, mustExist, 0, size () - 1, comparator); } Value returned is $17 = 32 (gdb) Run till exit from #0 0x000000010005de36 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:159 0x000000010005de6b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:456 456 comparator); } Value returned is $18 = 32 (gdb) Run till exit from #0 0x000000010005de6b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x116b1bbd0, key=0x7fff5fbfdd10, mustExist=false, comparator=0x7fff5fbfdd80) at container.hh:456 0x000000010005b27f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:340 340 int i = bsearch (&key, false, &comparator); Value returned is $19 = 32 (gdb) Run till exit from #0 0x000000010005b27f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:340 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, textblock=0x116bf7270, y=616745, h=1, lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 424 int last = findFloatIndex (lastGB, lastExtIndex); Value returned is $20 = 31 (gdb) Run till exit from #0 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, textblock=0x116bf7270, y=616745, h=1, lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=616745, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 2115 int first = list->findFirst (textblock, y, h, lastGB, lastExtIndex, NULL); Value returned is $21 = 29 (gdb) Run till exit from #0 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=616745, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, textblock=0x116bf7270, y=616745, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 2092 bool b = hasFloat (textblock, LEFT, y, h, lastGB, lastExtIndex); Value returned is $22 = true (gdb) Run till exit from #0 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, textblock=0x116bf7270, y=616745, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 2045 effOofRef); Value returned is $23 = true (gdb) Run till exit from #0 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 dw::Textblock::balanceBreakPosAndHeight (this=0x116bf7270, wordIndex=0, firstIndex=0, searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 912 newLineHasFloatLeft || newLineHasFloatRight : false; (gdb) Run till exit from #0 dw::Textblock::balanceBreakPosAndHeight (this=0x116bf7270, wordIndex=0, firstIndex=0, searchUntil=0x7fff5fbfe078, tempNewLine=false, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0x7fff5fbfe08d, wrapAll=false, diffWords=0x7fff5fbfe084, wordIndexEnd=0x7fff5fbfe070, lastFloatPos=0x7fff5fbfe064, regardBorder=true, height=0x7fff5fbfe06c, breakPos=0x7fff5fbfe068) at textblock_linebreaking.cc:912 dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:749 749 int yNewLine = yOffsetOfLineToBeCreated (); (gdb) Run till exit from #0 dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:749 ^C Program received signal SIGINT, Interrupt. dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fff5fbfdd30, o1=0x7fff5fbfdcc0, o2=0x116bcf1e0) at outofflowmgr.cc:295 295 for (TBInfo *t = t1; t != NULL; t = t->parent) (gdb) finish Run till exit from #0 dw::OutOfFlowMgr::Float::CompareGBAndExtIndex::compare (this=0x7fff5fbfdd30, o1=0x7fff5fbfdcc0, o2=0x116bcf1e0) at outofflowmgr.cc:295 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdcc0, mustExist=false, start=0, end=38, comparator=0x7fff5fbfdd30) at container.cc:239 239 int c = comparator->compare (key, array[index]); Value returned is $24 = 28 (gdb) Run till exit from #0 0x000000010009eaf6 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdcc0, mustExist=false, start=0, end=38, comparator=0x7fff5fbfdd30) at container.cc:239 0x000000010005de36 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdcc0, mustExist=false, comparator=0x7fff5fbfdd30) at container.hh:159 159 { return bsearch (key, mustExist, 0, size () - 1, comparator); } Value returned is $25 = 32 (gdb) Run till exit from #0 0x000000010005de36 in lout::container::untyped::Vector::bsearch (this=0x116b1bc00, key=0x7fff5fbfdcc0, mustExist=false, comparator=0x7fff5fbfdd30) at container.hh:159 0x000000010005de6b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x116b1bbd0, key=0x7fff5fbfdcc0, mustExist=false, comparator=0x7fff5fbfdd30) at container.hh:456 456 comparator); } Value returned is $26 = 32 (gdb) Run till exit from #0 0x000000010005de6b in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x116b1bbd0, key=0x7fff5fbfdcc0, mustExist=false, comparator=0x7fff5fbfdd30) at container.hh:456 0x000000010005b27f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:340 340 int i = bsearch (&key, false, &comparator); Value returned is $27 = 32 (gdb) Run till exit from #0 0x000000010005b27f in dw::OutOfFlowMgr::SortedFloatsVector::findFloatIndex (this=0x116b1bbd0, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:340 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, textblock=0x116bf7270, y=948395, h=1, lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 424 int last = findFloatIndex (lastGB, lastExtIndex); Value returned is $28 = 31 (gdb) Run till exit from #0 0x000000010005b986 in dw::OutOfFlowMgr::SortedFloatsVector::findFirst (this=0x116b1bbd0, textblock=0x116bf7270, y=948395, h=1, lastGB=0x116bf7270, lastExtIndex=-1, lastReturn=0x0) at outofflowmgr.cc:424 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=948395, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 2115 int first = list->findFirst (textblock, y, h, lastGB, lastExtIndex, NULL); Value returned is $29 = 29 (gdb) Run till exit from #0 0x000000010005bd1a in dw::OutOfFlowMgr::hasFloat (this=0x116b1bb60, textblock=0x116bf7270, side=dw::OutOfFlowMgr::LEFT, y=948395, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2115 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, textblock=0x116bf7270, y=948395, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 2092 bool b = hasFloat (textblock, LEFT, y, h, lastGB, lastExtIndex); Value returned is $30 = true (gdb) Run till exit from #0 0x000000010005bdd0 in dw::OutOfFlowMgr::hasFloatLeft (this=0x116b1bb60, textblock=0x116bf7270, y=948395, h=1, lastGB=0x116bf7270, lastExtIndex=-1) at outofflowmgr.cc:2092 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 2045 effOofRef); Value returned is $31 = true (gdb) Run till exit from #0 0x000000010006fdb2 in dw::Textblock::calcBorders (this=0x116bf7270, lastOofRef=-1, height=1) at textblock_linebreaking.cc:2045 dw::Textblock::initNewLine (this=0x116bf7270) at textblock_linebreaking.cc:1990 1990 newLineAscent = newLineDescent = 0; (gdb) Run till exit from #0 dw::Textblock::initNewLine (this=0x116bf7270) at textblock_linebreaking.cc:1990 dw::Textblock::addLine (this=0x116bf7270, firstWord=0, lastWord=-1, newLastOofPos=-1, temporary=false, minHeight=1) at textblock_linebreaking.cc:523 523 return line; (gdb) Run till exit from #0 dw::Textblock::addLine (this=0x116bf7270, firstWord=0, lastWord=-1, newLastOofPos=-1, temporary=false, minHeight=1) at textblock_linebreaking.cc:523 dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:826 826 for(int i = breakPos + 1; i <= wordIndexEnd; i++) Value returned is $32 = ('dw::Textblock::Line' *) 0x11ad3ca80 (gdb) Run till exit from #0 dw::Textblock::wrapWordInFlow (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:826 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 606 n = wrapWordInFlow (wordIndex, wrapAll); Value returned is $33 = 0 (gdb) Run till exit from #0 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116bf7270, wordIndex=0, wrapAll=false) at textblock_linebreaking.cc:606 dw::Textblock::rewrap (this=0x116bf7270) at textblock_linebreaking.cc:1885 1885 for (int i = firstWord; i < words->size (); i++) { Value returned is $34 = 0 (gdb) Run till exit from #0 dw::Textblock::rewrap (this=0x116bf7270) at textblock_linebreaking.cc:1885 dw::Textblock::sizeRequestImpl (this=0x116bf7270, requisition=0x116bf7600) at textblock.cc:342 342 showMissingLines (); (gdb) Run till exit from #0 dw::Textblock::sizeRequestImpl (this=0x116bf7270, requisition=0x116bf7600) at textblock.cc:342 dw::core::Widget::sizeRequest (this=0x116bf7270, requisition=0x116bf7600) at widget.cc:495 495 this->requisition = *requisition; (gdb) Run till exit from #0 dw::core::Widget::sizeRequest (this=0x116bf7270, requisition=0x116bf7600) at widget.cc:495 dw::Textblock::rewrap (this=0x116bf6ce0) at textblock_linebreaking.cc:1891 1891 wordWrap (i, false); (gdb) Run till exit from #0 dw::Textblock::rewrap (this=0x116bf6ce0) at textblock_linebreaking.cc:1891 dw::Textblock::sizeRequestImpl (this=0x116bf6ce0, requisition=0x116bf8ac0) at textblock.cc:342 342 showMissingLines (); (gdb) Run till exit from #0 dw::Textblock::sizeRequestImpl (this=0x116bf6ce0, requisition=0x116bf8ac0) at textblock.cc:342 dw::core::Widget::sizeRequest (this=0x116bf6ce0, requisition=0x116bf8ac0) at widget.cc:495 495 this->requisition = *requisition; (gdb) Run till exit from #0 dw::core::Widget::sizeRequest (this=0x116bf6ce0, requisition=0x116bf8ac0) at widget.cc:495 dw::Textblock::rewrap (this=0x116bf67c0) at textblock_linebreaking.cc:1891 1891 wordWrap (i, false); (gdb) Run till exit from #0 dw::Textblock::rewrap (this=0x116bf67c0) at textblock_linebreaking.cc:1891 dw::Textblock::sizeRequestImpl (this=0x116bf67c0, requisition=0x11713ac20) at textblock.cc:342 342 showMissingLines (); (gdb) Run till exit from #0 dw::Textblock::sizeRequestImpl (this=0x116bf67c0, requisition=0x11713ac20) at textblock.cc:342 dw::core::Widget::sizeRequest (this=0x116bf67c0, requisition=0x11713ac20) at widget.cc:495 495 this->requisition = *requisition; (gdb) Run till exit from #0 dw::core::Widget::sizeRequest (this=0x116bf67c0, requisition=0x11713ac20) at widget.cc:495 dw::Textblock::rewrap (this=0x116bf57d0) at textblock_linebreaking.cc:1891 1891 wordWrap (i, false); (gdb) Run till exit from #0 dw::Textblock::rewrap (this=0x116bf57d0) at textblock_linebreaking.cc:1891 dw::Textblock::sizeRequestImpl (this=0x116bf57d0, requisition=0x117119680) at textblock.cc:342 342 showMissingLines (); (gdb) Run till exit from #0 dw::Textblock::sizeRequestImpl (this=0x116bf57d0, requisition=0x117119680) at textblock.cc:342 dw::core::Widget::sizeRequest (this=0x116bf57d0, requisition=0x117119680) at widget.cc:495 495 this->requisition = *requisition; (gdb) Run till exit from #0 dw::core::Widget::sizeRequest (this=0x116bf57d0, requisition=0x117119680) at widget.cc:495 dw::Textblock::rewrap (this=0x116bf5590) at textblock_linebreaking.cc:1891 1891 wordWrap (i, false); (gdb) Run till exit from #0 dw::Textblock::rewrap (this=0x116bf5590) at textblock_linebreaking.cc:1891 dw::Textblock::sizeRequestImpl (this=0x116bf5590, requisition=0x116bf5d80) at textblock.cc:342 342 showMissingLines (); (gdb) bt #0 dw::Textblock::sizeRequestImpl (this=0x116bf5590, requisition=0x116bf5d80) at textblock.cc:342 #1 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf5590, requisition=0x116bf5d80) at widget.cc:494 #2 0x0000000100070199 in dw::Textblock::rewrap (this=0x116bf3c80) at textblock_linebreaking.cc:1889 #3 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116bf3c80, requisition=0x100941240) at textblock.cc:341 #4 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116bf3c80, requisition=0x100941240) at widget.cc:494 #5 0x0000000100070199 in dw::Textblock::rewrap (this=0x102277cd0) at textblock_linebreaking.cc:1889 #6 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x102277cd0, requisition=0x1009435c0) at textblock.cc:341 #7 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x102277cd0, requisition=0x1009435c0) at widget.cc:494 #8 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d7f0) at textblock_linebreaking.cc:1889 #9 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1d7f0, requisition=0x116b1daa0) at textblock.cc:341 #10 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1d7f0, requisition=0x116b1daa0) at widget.cc:494 #11 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1d060) at textblock_linebreaking.cc:1889 #12 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1d060, requisition=0x116b1d3c0) at textblock.cc:341 #13 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1d060, requisition=0x116b1d3c0) at widget.cc:494 #14 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1ca30) at textblock_linebreaking.cc:1889 #15 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1ca30, requisition=0x116b1cd80) at textblock.cc:341 #16 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1ca30, requisition=0x116b1cd80) at widget.cc:494 #17 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1c570) at textblock_linebreaking.cc:1889 #18 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1c570, requisition=0x117125040) at textblock.cc:341 #19 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1c570, requisition=0x117125040) at widget.cc:494 #20 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b9b0) at textblock_linebreaking.cc:1889 #21 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1b9b0, requisition=0x116b1c180) at textblock.cc:341 #22 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1b9b0, requisition=0x116b1c180) at widget.cc:494 #23 0x0000000100070199 in dw::Textblock::rewrap (this=0x116b1b4f0) at textblock_linebreaking.cc:1889 #24 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x116b1b4f0, requisition=0x116b1b6f4) at textblock.cc:341 #25 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1b4f0, requisition=0x116b1b6f4) at widget.cc:494 #26 0x0000000100058685 in dw::OutOfFlowMgr::ensureFloatSize (this=0x1022478e0, vloat=0x116b1b6a0) at outofflowmgr.cc:2272 #27 0x000000010005b067 in dw::OutOfFlowMgr::tellFloatPosition (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1534 #28 0x000000010005b1dc in dw::OutOfFlowMgr::tellPosition (this=0x1022478e0, widget=0x116b1b4f0, yReq=0) at outofflowmgr.cc:1516 #29 0x0000000100072aef in dw::Textblock::wrapWordInFlow (this=0x116b1ad70, wordIndex=1, wrapAll=true) at textblock_linebreaking.cc:788 #30 0x0000000100072e23 in dw::Textblock::wordWrap (this=0x116b1ad70, wordIndex=1, wrapAll=true) at textblock_linebreaking.cc:606 #31 0x000000010006fbb2 in dw::Textblock::showMissingLines (this=0x116b1ad70) at textblock_linebreaking.cc:2113 #32 0x000000010006b230 in dw::Textblock::sizeRequestImpl (this=0x116b1ad70, requisition=0x10095b450) at textblock.cc:342 #33 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x116b1ad70, requisition=0x10095b450) at widget.cc:494 #34 0x0000000100070199 in dw::Textblock::rewrap (this=0x10210cdf0) at textblock_linebreaking.cc:1889 #35 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x10210cdf0, requisition=0x1009597c0) at textblock.cc:341 #36 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x10210cdf0, requisition=0x1009597c0) at widget.cc:494 #37 0x0000000100070199 in dw::Textblock::rewrap (this=0x10054a2c0) at textblock_linebreaking.cc:1889 #38 0x000000010006b227 in dw::Textblock::sizeRequestImpl (this=0x10054a2c0, requisition=0x7fff5fbff040) at textblock.cc:341 #39 0x000000010009c7a7 in dw::core::Widget::sizeRequest (this=0x10054a2c0, requisition=0x7fff5fbff040) at widget.cc:494 #40 0x00000001000586cc in dw::OutOfFlowMgr::doFloatsExceedCB (this=0x1022478e0, side=dw::OutOfFlowMgr::LEFT) at outofflowmgr.cc:1045 #41 0x000000010005b757 in dw::OutOfFlowMgr::sizeAllocateEnd (this=0x1022478e0, caller=0x10054a2c0) at outofflowmgr.cc:651 #42 0x000000010006ae82 in dw::Textblock::sizeAllocateImpl (this=0x10054a2c0, allocation=0x7fff5fbff240) at textblock.cc:757 #43 0x000000010009cfb2 in dw::core::Widget::sizeAllocate (this=0x10054a2c0, allocation=0x7fff5fbff240) at widget.cc:993 #44 0x000000010008e4ff in dw::core::Layout::resizeIdle (this=0x105109370) at layout.cc:912 #45 0x0000000100076d9e in dw::fltk::FltkPlatform::generalIdle (this=0x1051091c0) at fltkplatform.cc:627 #46 0x0000000100076def in dw::fltk::FltkPlatform::generalStaticIdle (data=0x1051091c0) at fltkplatform.cc:617 #47 0x00000001000ad21e in fl_mac_flush_and_wait (time_to_wait=1e+20) at Fl_cocoa.mm:806 #48 0x00000001000b0025 in Fl::run () at Fl.cxx:589 #49 0x00000001000044c5 in main (argc=1, argv=0x7fff5fbff3f8) at dillo.cc:588 (gdb) On 1/21/15, Jorge Arellano Cid <jcid at dillo.org> wrote: > Hi there, > > Trying to read about this laptop on slashdot dillo > locks with 100% CPU and increasing memory footprint. :-P > > > [1] > http://hardware.slashdot.org/story/15/01/20/1655242/librem-a-laptop-custom-… > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 21, 2015

Dillo CPU-hog lock on slashdot

by jcid＠dillo.org

Hi there, Trying to read about this laptop on slashdot dillo locks with 100% CPU and increasing memory footprint. :-P [1] http://hardware.slashdot.org/story/15/01/20/1655242/librem-a-laptop-custom-… -- Cheers Jorge.-

Jan. 20, 2015

Core-dump pasting from one form field into another

by johannes.hofmann＠gmx.de

Hi James, On Tue, Jan 20, 2015 at 08:50:22PM +1300, James C wrote: > Hi All, > > I think I've worked out what's going on with drag-and-drop. > > We're compiling with -fno-rtti and (some parts of) fltk do > dynamic_cast, which needs rtti. The run-time handling for detecting > the conflict is nonexistent/unforgiving. > > When I make the change below and rebuild, drag-and-drop starts working for me. Cool that you found the reason! >From http://en.wikipedia.org/wiki/FLTK fltk is supposed to work without rtti, but things might have changed of course. It would be cool if you could bring up the topic on an fltk list to see if it's intended like this. Cheers, Johannes

Jan. 20, 2015

a different lines->getRef() segfault

by eocene＠gmx.com

A new page was just coming in -- seems like the same sort of problem as last time. (gdb) bt #0 0xb77bb424 in __kernel_vsyscall () #1 0xb72f9661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb72fca92 in *__GI_abort () at abort.c:92 #3 0xb72f2878 in *__GI___assert_fail ( assertion=0x8151afe "i >= 0 && this->num - i > 0", file=0x8151aee "../lout/misc.hh", line=167, function=0x8151ba0 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 #4 0x080a9040 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( this=0x953b618, i=-1) at ../lout/misc.hh:167 #5 0x080a2786 in dw::Textblock::sendSelectionEvent (this=0x916c610, eventType=dw::core::SelectionState::BUTTON_RELEASE, event=0xbfbb8180) at textblock.cc:1093 #6 0x080a24c3 in dw::Textblock::buttonReleaseImpl (this=0x916c610, event=0xbfbb8180) at textblock.cc:1008 #7 0x080d8910 in dw::core::Widget::buttonRelease (this=0x916c610, event=0xbfbb8180) at widget.cc:1027 #8 0x080cd617 in dw::core::Layout::processMouseEvent (this=0x90fc058, event=0xbfbb8180, type=dw::core::Layout::BUTTON_RELEASE) at layout.cc:1234 #9 0x080cd00e in dw::core::Layout::buttonEvent (this=0x90fc058, type=dw::core::Layout::BUTTON_RELEASE, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.cc:1023 #10 0x080c46ae in dw::core::Layout::buttonRelease (this=0x90fc058, view=0x90f9f60, numPressed=1, x=127, y=180, state=0, button=1) at layout.hh:345 #11 0x080c33f7 in dw::fltk::FltkViewBase::handle (this=0x90f9f60, event=2) at fltkviewbase.cc:319 #12 0x080c5e8a in dw::fltk::FltkViewport::handle (this=0x90f9f60, event=2) at fltkviewport.cc:331 #13 0x080ded22 in send(int, Fl_Widget*, Fl_Window*) () #14 0x080dfbaf in Fl::handle_(int, Fl_Window*) () #15 0x080dff0e in Fl::handle(int, Fl_Window*) () #16 0x08107e9d in fl_handle(_XEvent const&) () #17 0x08107fbc in do_queued_events() () #18 0x0810822a in fl_wait(double) () #19 0x080e08af in Fl::wait(double) () #20 0x080e099d in Fl::run() () #21 0x08052f7a in main (argc=1, argv=0xbfbb8854) at dillo.cc:588

Jan. 20, 2015

Core-dump pasting from one form field into another

by james.from.wellington＠gmail.com

Hi All, I think I've worked out what's going on with drag-and-drop. We're compiling with -fno-rtti and (some parts of) fltk do dynamic_cast, which needs rtti. The run-time handling for detecting the conflict is nonexistent/unforgiving. When I make the change below and rebuild, drag-and-drop starts working for me. The executable size penalty is significant. The only 3+MB one is the only one with rtti turned on: ...$ ls -l versions/*/*/src/dillo -rwxr-xr-x 1 ... staff 2943392 25 Nov 21:42 versions/cookies/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 3253032 20 Jan 20:10 versions/everything/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2943096 26 Oct 16:46 versions/pull-everything/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2942840 15 Sep 18:11 versions/render/dillo-jfw01/src/dillo -rwxr-xr-x 1 ... staff 2942448 28 Oct 17:58 versions/ssh-everything-dirty/dillo-jfw01/src/dillo ...$ There are two dynamic casts in fltk: ./src/Fl_cocoa.mm:3792: if ( dynamic_cast<Fl_Input_*>(w) != NULL || dynamic_cast<Fl_Text_Display*>(w) != NULL) { ./src/Fl_cocoa.mm:3973: BOOL to_quartz = dynamic_cast<Fl_Printer*>(this) != NULL; I have no opinion yet about how difficult they would be to replace. The way forward should be decided by someone who remembers why no-rtti was originally turned on. Regards, James. $ hg diff configure.ac diff -r e773dab661ec configure.ac --- a/configure.ac Wed Sep 17 00:24:37 2014 +1200 +++ b/configure.ac Tue Jan 20 20:49:00 2015 +1300 @@ -488,7 +488,8 @@ dnl if eval "test x$GCC = xyes"; then - CXXFLAGS="$CXXFLAGS -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions" + CXXFLAGS="$CXXFLAGS -Wall -W -Wno-unused-parameter -fno-exceptions" +dnl removed -fno-rtti to enable DND in FLTK fi AC_SUBST(BASE_CUR_WORKING_DIR) On 1/7/15, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > On Sat, Dec 27, 2014 at 08:42:55PM +0100, Johannes Hofmann wrote: >> On Sat, Dec 27, 2014 at 06:22:12PM +0000, eocene wrote: >> > James wrote: >> > > This is exercisable in Dillo 3.0.4.1, but not new. I found it by >> > > accident in my hack-up of Dillo 3.0.4. >> > > >> > > The reproduction is: >> > > - enable cookies for .google.com >> > > - navigate to https://mail.google.com/mail/?ui=html >> > > - fight the links until you get a screen with two fields, one for the >> > > username and one for the password >> > > - type something into the username field >> > > - select it and drag to the password field >> > > -- core dump >> > > >> > > I am on: >> > > >> > > - OSX 10.6.8 >> > > - Dillo 3.0.4.1 with SSL enabled >> > > - FLTK 1.3.3 >> > > - with dpid, etc from Dillo 3.0.4 with extensive hacking >> > > >> > > so the fault could be Mac-specific. >> > >> > I tried playing around a little, on linux and not having a gmail acct, >> > and nothing wanted to go wrong, so, yeah, it might be an osx issue... >> >> Can't reproduce it either on DragonFly BSD. I can try later to get >> a stack trace on osx. > > On MacOSX all attempts to drag and drop crash dillo for me. > As it also causes confusion on X11 based systems I disabled DND > alltogether for now. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 20, 2015

form input placeholder text

by eocene＠gmx.com

Everyone's getting into the habit of using the html5 placeholder attributes on form inputs to tell users what the inputs are for, decreasing usability for the rest of us, so I implemented it for INPUT text/password. (It's also legal on TEXTAREA.) http://www.dillo.org/test/input_placeholder.diff

Jan. 20, 2015

addParbreak, display:inline

by eocene＠gmx.com

I was looking at why the page numbers at the bottom of a startpage search results page aren't visible. It seems that the numbers are forms with display:inline. open_form has HT2TB(html)->addParbreak (9, html->wordStyle ()); Am I correct in thinking that the assorted addParbreak()s have to come out at some point for display to work, or is there some other plan? I note that the html5 spec has: "In quirks mode, the following rules are also expected to apply: ... form { margin-bottom: 1em; }" to provide the gap in this case.

Jan. 19, 2015

resolution independent px

by sgeerken＠dillo.org

On So, Jan 18, 2015, Johannes Hofmann wrote: > As nobody actually has a problem at the moment I think we can > postpone this. It will come up again as high resolution devices are > becoming more popular. Furthermore, if such devices become more common, web designers may become more aware of this problem; something like this ---------------------------------------------------------------------- Some text and an image: <img src="http://www.dillo.org/Icons/ProgramIcon32.png" style="min-height: 1em"> ---------------------------------------------------------------------- would solve the problem, too (test it with different font sizes in dillo 3.1-dev). Sebastian

Jan. 18, 2015

should we have a dillo-announce list?

by eocene＠gmx.com

James wrote: > I've discovered openhub by accident: > https://www.openhub.net/p?ref=homepage&q=dillo > > Would it be a sensible place to announce new releases of Dillo? Are people using ohloh/openhub? I remember someone coming along at one point during dillo2 and mentioning it on the list (perhaps asking what to put in certain fields in the entry for dillo?), but that was a while ago. I was imagining asking Andreas to add a dillo-announce to lists.dillo.org...

Jan. 18, 2015

resolution independent px

by eocene＠gmx.com

Johannes wrote: > As nobody actually has a problem at the moment I think we can > postpone this. It will come up again as high resolution devices are > becoming more popular. Speaking of high resolution devices, does it look like there's much value these days in trying to get dillo to work better in the world of touch interfaces, or has dillo been utterly passed by there for one reason or another?

Jan. 18, 2015

resolution independent px

by Johannes.Hofmann＠gmx.de

Hi, On Sun, Jan 18, 2015 at 09:20:06PM +1300, James C wrote: > Hi Johannes, > > Reading the link, it looks like normally viewed displays with any > resolution between about 50 DPI and 140 DPI will have one CSS pixel > exactly equal to one device pixel; so resolutions outside that are the > definition of 'differs a lot' in the standard. > > What's the overhead of asking the library to re-scale the image to the > size that it already is? If it's significant, then maybe there needs > to be a special case for 1:1. the overhead is significant in case images would not be scaled otherwise, so we would want to special case it somehow. > > I start out with a bias against adding another run-time option, but > it's based on my not-very-relevant experience of adding an option to > dpid. > > Contradicting myself, the standard implies that there could be an > option for viewing distance, in which case there could be a special > case to that option for 'never scale'. As nobody actually has a problem at the moment I think we can postpone this. It will come up again as high resolution devices are becoming more popular. Cheers, Johannes > > Regards. > James. > > On 1/18/15, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > > On Fri, Jan 16, 2015 at 12:14:19PM -0300, Jorge Arellano Cid wrote: > >> On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote: > >> > Hi, > >> > > >> > attached is a patch that would enable resolution independent > >> > handling of px as described in [1]. > >> > It would result in roughly equally sized images on high and low > >> > resolution devices at the cost of a higher overhead for additional > >> > image scaling. > >> > >> A long time ago, image scaling was relatively low overhead, > >> but since dillo got correct gamma correction, it became much > >> more expensive. > >> > >> I remember testing this and the difference was noticeable. > >> It was left anyway because the amount of scaled images > >> in the average web page is low. > >> > >> > >> > Is there a need for something like this? > >> > >> I don't know... > >> > >> > Should it be enabled via config option or should we do it > >> > automatically if we detect a DPI value that differs a lot from > >> > the standard value? > >> > >> For me, it is hard to say without knowing the main use of it. > >> What I do know is that our scaling is CPU intensive, so I tend > >> to have it off unless necessary. > > > > It's only useful if you have a high resolution device where DPI is > > much higher than about 70. In that case images will be rendered > > very small. > > > > I currently don't have such a device, so personally I don't have > > any need for this now. I just wanted to get feedback from dillo-dev > > in case someone already ran into this issue. > > > > Cheers, > > Johannes > > > > _______________________________________________ > > Dillo-dev mailing list > > Dillo-dev at dillo.org > > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev > > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Jan. 18, 2015

resolution independent px

by james.from.wellington＠gmail.com

Hi Johannes, Reading the link, it looks like normally viewed displays with any resolution between about 50 DPI and 140 DPI will have one CSS pixel exactly equal to one device pixel; so resolutions outside that are the definition of 'differs a lot' in the standard. What's the overhead of asking the library to re-scale the image to the size that it already is? If it's significant, then maybe there needs to be a special case for 1:1. I start out with a bias against adding another run-time option, but it's based on my not-very-relevant experience of adding an option to dpid. Contradicting myself, the standard implies that there could be an option for viewing distance, in which case there could be a special case to that option for 'never scale'. Regards. James. On 1/18/15, Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote: > On Fri, Jan 16, 2015 at 12:14:19PM -0300, Jorge Arellano Cid wrote: >> On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote: >> > Hi, >> > >> > attached is a patch that would enable resolution independent >> > handling of px as described in [1]. >> > It would result in roughly equally sized images on high and low >> > resolution devices at the cost of a higher overhead for additional >> > image scaling. >> >> A long time ago, image scaling was relatively low overhead, >> but since dillo got correct gamma correction, it became much >> more expensive. >> >> I remember testing this and the difference was noticeable. >> It was left anyway because the amount of scaled images >> in the average web page is low. >> >> >> > Is there a need for something like this? >> >> I don't know... >> >> > Should it be enabled via config option or should we do it >> > automatically if we detect a DPI value that differs a lot from >> > the standard value? >> >> For me, it is hard to say without knowing the main use of it. >> What I do know is that our scaling is CPU intensive, so I tend >> to have it off unless necessary. > > It's only useful if you have a high resolution device where DPI is > much higher than about 70. In that case images will be rendered > very small. > > I currently don't have such a device, so personally I don't have > any need for this now. I just wanted to get feedback from dillo-dev > in case someone already ran into this issue. > > Cheers, > Johannes > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 18, 2015

should we have a dillo-announce list?

by james.from.wellington＠gmail.com

Hello All, I've discovered openhub by accident: https://www.openhub.net/p?ref=homepage&q=dillo Would it be a sensible place to announce new releases of Dillo? Regards, James. On 1/7/15, Jorge Arellano Cid <jcid at dillo.org> wrote: > On Sat, Jan 03, 2015 at 07:49:29PM +0000, eocene wrote: >> >> Seems like a release announcements list would be valuable... > > +1 > > At least that way we'd have one official channel (without the > burden of receiving the whole traffic in dillo-dev). > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 18, 2015

page doesn't finish rendering

by eocene＠gmx.com

This page doesn't finish rendering for me: http://edge.org/responses/what-do-you-think-about-machines-that-think

Jan. 17, 2015

resolution independent px

by Johannes.Hofmann＠gmx.de

On Fri, Jan 16, 2015 at 12:14:19PM -0300, Jorge Arellano Cid wrote: > On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote: > > Hi, > > > > attached is a patch that would enable resolution independent > > handling of px as described in [1]. > > It would result in roughly equally sized images on high and low > > resolution devices at the cost of a higher overhead for additional > > image scaling. > > A long time ago, image scaling was relatively low overhead, > but since dillo got correct gamma correction, it became much > more expensive. > > I remember testing this and the difference was noticeable. > It was left anyway because the amount of scaled images > in the average web page is low. > > > > Is there a need for something like this? > > I don't know... > > > Should it be enabled via config option or should we do it > > automatically if we detect a DPI value that differs a lot from > > the standard value? > > For me, it is hard to say without knowing the main use of it. > What I do know is that our scaling is CPU intensive, so I tend > to have it off unless necessary. It's only useful if you have a high resolution device where DPI is much higher than about 70. In that case images will be rendered very small. I currently don't have such a device, so personally I don't have any need for this now. I just wanted to get feedback from dillo-dev in case someone already ran into this issue. Cheers, Johannes

Jan. 17, 2015

resolution independent px

by sgeerken＠dillo.org

On Fr, Jan 16, 2015, Jorge Arellano Cid wrote: > On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote: > > Hi, > > > > attached is a patch that would enable resolution independent > > handling of px as described in [1]. > > It would result in roughly equally sized images on high and low > > resolution devices at the cost of a higher overhead for additional > > image scaling. > > A long time ago, image scaling was relatively low overhead, > but since dillo got correct gamma correction, it became much > more expensive. It is not so much gamma correction, but some improvements before. BTW: if you look at dw/fltkimgbuf.cc, you see that the old fast code is still available, by setting scaleMode to SIMPLE. Perhaps this should be configurable (should be simple), or depending on estimated CPU performance. If you run dillo (3.1-dev, not 3.0.4.1) with the attached page, change the window width, and compare the results with Firefox, you'll notice that Firefox responds a bit faster. I'm not sure whether Firefox scales faster, but in other circumstances I've noticed that Firefox seems to apply two scaling algorithms: one simple but fast one, with higher priority, and a better but slower one, which is applied with lower priority. Sebastian

Jan. 16, 2015

resolution independent px

by jcid＠dillo.org

On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote: > Hi, > > attached is a patch that would enable resolution independent > handling of px as described in [1]. > It would result in roughly equally sized images on high and low > resolution devices at the cost of a higher overhead for additional > image scaling. A long time ago, image scaling was relatively low overhead, but since dillo got correct gamma correction, it became much more expensive. I remember testing this and the difference was noticeable. It was left anyway because the amount of scaled images in the average web page is low. > Is there a need for something like this? I don't know... > Should it be enabled via config option or should we do it > automatically if we detect a DPI value that differs a lot from > the standard value? For me, it is hard to say without knowing the main use of it. What I do know is that our scaling is CPU intensive, so I tend to have it off unless necessary. Another way around is to optimize our gamma correction algorithm with integer arithmetic. An option that was not taken at the time because of the above stated reasons. HTH. -- Cheers Jorge.-

Jan. 16, 2015

resolution independent px

by Johannes.Hofmann＠gmx.de

Hi, attached is a patch that would enable resolution independent handling of px as described in [1]. It would result in roughly equally sized images on high and low resolution devices at the cost of a higher overhead for additional image scaling. Is there a need for something like this? Should it be enabled via config option or should we do it automatically if we detect a DPI value that differs a lot from the standard value? Cheers, Johannes [1] http://www.w3.org/TR/CSS2/syndata.html#x39

Jan. 16, 2015

background images

by eocene＠gmx.com

Saw another case today where a forum had quoted text obscured by repeated background quotation marks. Playing around a little, the behaviour seems flaky (html and image files attached).

Jan. 15, 2015

different rendering depending on DOCTYPE

by Johannes.Hofmann＠gmx.de

Hi, I noticed, that firefox and chrome render stuff differently depending on the DOCTYPE. Attached is a small example. firefox doesn't show overlapping text but dillo does. When the DOCTYPE line is removed firefox renders the page as dillo does. Wikipedia has some information about the topic at [1]. I think at some point we need to handle these cases too. It would also be interesting which rule exactly prevents firefox from showing overlapping text when the DOCTYPE line is present. Cheers, Johannes [1] http://en.wikipedia.org/wiki/Quirks_mode

Jan. 11, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Tue, Jan 06, 2015, Sebastian Geerken wrote: > On Sun, Dec 28, 2014, Sebastian Geerken wrote: > > On Wed, Dec 24, 2014, eocene wrote: > > > - source is slow to render, seemingly something to do with large tables. > > > > Yes, I'm noticing that rendering large tables is much slower than in > > 3.0.4. I'll work on this. (Probably a side-effect of GROWS.) > > It has become much better, although still slower than 3.0.4. A simple gprof run showed another opportunity for optimization. There should now be no performance problems anymore with tables. Sebastian

Jan. 7, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Sun, Dec 28, 2014, Sebastian Geerken wrote: > On Wed, Dec 24, 2014, eocene wrote: > > - source is slow to render, seemingly something to do with large tables. > > Yes, I'm noticing that rendering large tables is much slower than in > 3.0.4. I'll work on this. (Probably a side-effect of GROWS.) It has become much better, although still slower than 3.0.4. Sebastian

Jan. 6, 2015

Core-dump pasting from one form field into another

by Johannes.Hofmann＠gmx.de

On Sat, Dec 27, 2014 at 08:42:55PM +0100, Johannes Hofmann wrote: > On Sat, Dec 27, 2014 at 06:22:12PM +0000, eocene wrote: > > James wrote: > > > This is exercisable in Dillo 3.0.4.1, but not new. I found it by > > > accident in my hack-up of Dillo 3.0.4. > > > > > > The reproduction is: > > > - enable cookies for .google.com > > > - navigate to https://mail.google.com/mail/?ui=html > > > - fight the links until you get a screen with two fields, one for the > > > username and one for the password > > > - type something into the username field > > > - select it and drag to the password field > > > -- core dump > > > > > > I am on: > > > > > > - OSX 10.6.8 > > > - Dillo 3.0.4.1 with SSL enabled > > > - FLTK 1.3.3 > > > - with dpid, etc from Dillo 3.0.4 with extensive hacking > > > > > > so the fault could be Mac-specific. > > > > I tried playing around a little, on linux and not having a gmail acct, > > and nothing wanted to go wrong, so, yeah, it might be an osx issue... > > Can't reproduce it either on DragonFly BSD. I can try later to get > a stack trace on osx. On MacOSX all attempts to drag and drop crash dillo for me. As it also causes confusion on X11 based systems I disabled DND alltogether for now. Cheers, Johannes

Jan. 6, 2015

should we have a dillo-announce list?

by jcid＠dillo.org

On Sat, Jan 03, 2015 at 07:49:29PM +0000, eocene wrote: > > Seems like a release announcements list would be valuable... +1 At least that way we'd have one official channel (without the burden of receiving the whole traffic in dillo-dev). -- Cheers Jorge.-

Jan. 6, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Mon, Jan 05, 2015 at 03:59:15PM +0100, Sebastian Geerken wrote: > On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > > It's a bit sad to find time and again that 3.0.4 has better rendering > > than the new branch. (e.g. [1]) > > > > [1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes > > It is getting better (fixing "plain" bugs). While examining why the > images are not shown, I noticed that some element is set at height 0. > Test the attached page in dillo and Firefox and notice the difference: > Firefox shows the first line, although it has height 0, but draws the > second line at the same position as the first, the latter shining > through. > > It is somewhat difficult to imitate this behavour [1]; but two > solutions are feasable: (i) ignore height (perhaps via user style > sheet); (ii) use 'height' only to make elements larger (somewhat > similar to 'adjust_min_width'). In both cases, the two lines would be > put on top of each other. I like (ii). It falls in the "make dillo decide when directives make no sense" philosophy I'm advocating for.. -- Cheers Jorge.-

Jan. 6, 2015

what's currently broken in dillo

by jcid＠dillo.org

Hi Sebastian, On Sun, Jan 04, 2015 at 02:00:52PM +0100, Sebastian Geerken wrote: > On Sa, Jan 03, 2015, Jorge Arellano Cid wrote: > > [...] > > One solution I've been thinking about is to customize the > > rendering for each user. In general terms, a user goes to a > > handful of websites regularly. Those sites are the ones he cares > > more about. > > > > If we for instance remember that for site X, the user prefers > > no embedded CSS, that's it. > > > > This would be stored in a plain text file as a simple line. The > > UI interface, under Tools|Customize may offer something like: > > > > [ ] Remember settings for this page > > [ ] Remember settings for this site > > > > That's it, after a few simple clicks, problem is gone. > > > > The idea is this to be exceptional, this is, used as an > > exception for a few sites as general rendering should solve most > > cases. > > > > FWIW, I'm planning to make a list of these ideas to work on > > this year and be of help in this area. > > First of all, let's see how many problems fall into the "plain bug" > category, and so are simple to fix (although it needs work and time). Yes, sure. Now, with some sites it's not clear whether something is a bug, bad HTML, contradicting directives, etc. IMHO, just there, having an easy (i.e. user ready, click-click) way to customize can help a lot. e.g.[1] Here, I don't know what's wrong, but reading the text in those colors clearly hurts. Avoiding embedded CSS "solves" the problem with one click (from a user perspective). I may try coding it a bit and check how it feels. [1] http://www.veteranstoday.com/2015/01/05/hate-conspiracies/ > Partly, this kind of customization is already possible by usage of > user style sheets; perhaps we could add a (proprietary) extension for > selecting specific sites. Yes, but this solution requires good knowledge on CSS and HTML and some digging time (as in the example above where we don't know the problem in advance). OTOH, clicking a pair of checkboxes and see whether that helps is much easier. It's a user-level "solution". > While we're at this: Attached is a page which renders differently in > dillo and Firefox; the latter closes the "em" implicitely, so that the > red box is below (not inside) the green one. It's very good you discovered this point! > From my understanding, > > (i) this is incorrect HTML, but Yes. > (ii) since "div" is not allowed within "em", this could be easily > detected, to mimic Firefox behaviour. Yes. > This page is a simplified version of a real-word page, and in some > cases, the implications for the rendering are quite extreme. Yes. IMO this is a good place to nail some "rendering bugs" (by reacting as FF to bad HTML). AFAIR, the HTML cleanup heuristics were tuned before DIV was supported! I'll work on this now. Please let me know of any other tags you've found in real pages that mess with DIV in this sense while I work on it (for instance EM is in the phrase set which should be treated similarly). It may end helping rendering of a lot of sites or just a few, who knows, but's definitely worth the try. See attached toy-patch for the test case. -- Cheers Jorge.-

Jan. 6, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

> Test the "soon" > attached page ...

Jan. 5, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > It's a bit sad to find time and again that 3.0.4 has better rendering > than the new branch. (e.g. [1]) > > [1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes It is getting better (fixing "plain" bugs). While examining why the images are not shown, I noticed that some element is set at height 0. Test the attached page in dillo and Firefox and notice the difference: Firefox shows the first line, although it has height 0, but draws the second line at the same position as the first, the latter shining through. It is somewhat difficult to imitate this behavour [1]; but two solutions are feasable: (i) ignore height (perhaps via user style sheet); (ii) use 'height' only to make elements larger (somewhat similar to 'adjust_min_width'). In both cases, the two lines would be put on top of each other. Sebastian [1] Complicated cases of overlapping elements are handled in the "dillo_grows" repository, at <http://flpsed.org/hgweb/dillo_grows>.

Jan. 5, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > On Fri, Jan 02, 2015, eocene wrote: > > Sebastian wrote: > > > Yes, I now see; I assume that you mean this: > > > > > > http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png > > > > > > I'll look at it. > > > > Yes, that. Thanks... > > Finally works, although the floats ("Tonight", "Monday" ...) look a > bit different from Firefox. Thanks :)

Jan. 4, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Mon, Dec 29, 2014, James C. wrote: > I have missing words on the right, on the attached, which are exercisable only: > - with the CSS > - with at least one graphic correctly linked > > I didn't finish walking down a small test-case, because the other thing intervened. This works now, too. BTW, there were a couple of bugs occurring here. Sebastian

Jan. 4, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Fri, Jan 02, 2015, eocene wrote: > Sebastian wrote: > > Yes, I now see; I assume that you mean this: > > > > http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png > > > > I'll look at it. > > Yes, that. Thanks... Finally works, although the floats ("Tonight", "Monday" ...) look a bit different from Firefox. Sebastian

Jan. 4, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On So, Jan 04, 2015, Sebastian Geerken wrote: > While we're at this: Attached is a page [...] Attached in the following post ... :-)

Jan. 4, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Sa, Jan 03, 2015, Jorge Arellano Cid wrote: > [...] > One solution I've been thinking about is to customize the > rendering for each user. In general terms, a user goes to a > handful of websites regularly. Those sites are the ones he cares > more about. > > If we for instance remember that for site X, the user prefers > no embedded CSS, that's it. > > This would be stored in a plain text file as a simple line. The > UI interface, under Tools|Customize may offer something like: > > [ ] Remember settings for this page > [ ] Remember settings for this site > > That's it, after a few simple clicks, problem is gone. > > The idea is this to be exceptional, this is, used as an > exception for a few sites as general rendering should solve most > cases. > > FWIW, I'm planning to make a list of these ideas to work on > this year and be of help in this area. First of all, let's see how many problems fall into the "plain bug" category, and so are simple to fix (although it needs work and time). Partly, this kind of customization is already possible by usage of user style sheets; perhaps we could add a (proprietary) extension for selecting specific sites. While we're at this: Attached is a page which renders differently in dillo and Firefox; the latter closes the "em" implicitely, so that the red box is below (not inside) the green one.

Jan. 4, 2015

what's currently broken in dillo

by james.from.wellington＠gmail.com

I'm imagining, but I have no code, writing stream filters to edit websites until I like them. My first proposed victim would be gmail, to make plain html gmail take less vertical real-estate on my width of monitor. This would be fairly un-userproof. On 1/4/15, Jorge Arellano Cid <jcid at dillo.org> wrote: > On Sat, Jan 03, 2015 at 01:13:11AM +0100, Sebastian Geerken wrote: >> On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: >> > It's a bit sad to find time and again that 3.0.4 has better rendering >> > than the new branch. (e.g. [1]) >> >> The new branch is still in development. > > Sure. > > BTW, there're also cases where it renders better than 3.0.4 (e.g. [1]) > > [1] http://www.phoenixcentre.com/bodywork/bodywork3-4chakra.htm > > Personally I'm optimistic, see below. > >> I'm currently working on another page, which shows a similar behaviour >> (table with too wide columns); in my case, the reason is a plain bug >> which will be fixed soon. Hopefully, your case will be similar. >> >> There are some other issues: >> >> 2. What to do with badly designed pages, which are now less readabe >> since dillo supports new CSS attribues? "adjust_min_width" is a >> solution to one of those problems. > > 3.0.4 came to very reasonable rendering by overriding weird directives, > and solving corner cases and contradicting values as Firefox. I'm > proposing to do the same with floats and CSS. > > Somehow even when 3.0.4 decides a layout that's very different from > the originally intended, it is usable (e.g. [1]). Maybe the same > strategy can work here. > > >> 3. It may be that incomplete support (say, floats but no absolute >> positions) may cause some problems. >> >> Anyway, I believe that most reports fall into the first category. > > Yes, incomplete support (an old constant in dillo) has some > problems, but *somehow*, 3.0.4 ended with a rendering logic that > needed no more tweaks or controls. > > Now that we have CSS, floats, and missing absolute positions, > etc. it may become a bit harder. > > One solution I've been thinking about is to customize the > rendering for each user. In general terms, a user goes to a > handful of websites regularly. Those sites are the ones he cares > more about. > > If we for instance remember that for site X, the user prefers > no embedded CSS, that's it. > > This would be stored in a plain text file as a simple line. The > UI interface, under Tools|Customize may offer something like: > > [ ] Remember settings for this page > [ ] Remember settings for this site > > That's it, after a few simple clicks, problem is gone. > > The idea is this to be exceptional, this is, used as an > exception for a few sites as general rendering should solve most > cases. > > FWIW, I'm planning to make a list of these ideas to work on > this year and be of help in this area. > > HTH. > > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev at dillo.org > http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev >

Jan. 4, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Sat, Jan 03, 2015 at 01:13:11AM +0100, Sebastian Geerken wrote: > On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > > It's a bit sad to find time and again that 3.0.4 has better rendering > > than the new branch. (e.g. [1]) > > The new branch is still in development. Sure. BTW, there're also cases where it renders better than 3.0.4 (e.g. [1]) [1] http://www.phoenixcentre.com/bodywork/bodywork3-4chakra.htm Personally I'm optimistic, see below. > I'm currently working on another page, which shows a similar behaviour > (table with too wide columns); in my case, the reason is a plain bug > which will be fixed soon. Hopefully, your case will be similar. > > There are some other issues: > > 2. What to do with badly designed pages, which are now less readabe > since dillo supports new CSS attribues? "adjust_min_width" is a > solution to one of those problems. 3.0.4 came to very reasonable rendering by overriding weird directives, and solving corner cases and contradicting values as Firefox. I'm proposing to do the same with floats and CSS. Somehow even when 3.0.4 decides a layout that's very different from the originally intended, it is usable (e.g. [1]). Maybe the same strategy can work here. > 3. It may be that incomplete support (say, floats but no absolute > positions) may cause some problems. > > Anyway, I believe that most reports fall into the first category. Yes, incomplete support (an old constant in dillo) has some problems, but *somehow*, 3.0.4 ended with a rendering logic that needed no more tweaks or controls. Now that we have CSS, floats, and missing absolute positions, etc. it may become a bit harder. One solution I've been thinking about is to customize the rendering for each user. In general terms, a user goes to a handful of websites regularly. Those sites are the ones he cares more about. If we for instance remember that for site X, the user prefers no embedded CSS, that's it. This would be stored in a plain text file as a simple line. The UI interface, under Tools|Customize may offer something like: [ ] Remember settings for this page [ ] Remember settings for this site That's it, after a few simple clicks, problem is gone. The idea is this to be exceptional, this is, used as an exception for a few sites as general rendering should solve most cases. FWIW, I'm planning to make a list of these ideas to work on this year and be of help in this area. HTH. -- Cheers Jorge.-

Jan. 3, 2015

should we have a dillo-announce list?

by eocene＠gmx.com

Seems like a release announcements list would be valuable...

Jan. 3, 2015

what's currently broken in dillo

by Johannes.Hofmann＠gmx.de

On Sat, Jan 03, 2015 at 01:13:11AM +0100, Sebastian Geerken wrote: > On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > > It's a bit sad to find time and again that 3.0.4 has better rendering > > than the new branch. (e.g. [1]) > > The new branch is still in development. > > I'm currently working on another page, which shows a similar behaviour > (table with too wide columns); in my case, the reason is a plain bug > which will be fixed soon. Hopefully, your case will be similar. > > There are some other issues: > > 2. What to do with badly designed pages, which are now less readabe > since dillo supports new CSS attribues? "adjust_min_width" is a > solution to one of those problems. > > 3. It may be that incomplete support (say, floats but no absolute > positions) may cause some problems. > > Anyway, I believe that most reports fall into the first category. We always had these issues since we started with CSS. Sometimes implementing a feature makes rendering worse instead of better on some pages. But Sebastian's most recent commits improved things a lot again. And you can always add "* {float: none !important}" to your ~/.dillo/style.css Cheers, Johannes

Jan. 3, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > It's a bit sad to find time and again that 3.0.4 has better rendering > than the new branch. (e.g. [1]) The new branch is still in development. I'm currently working on another page, which shows a similar behaviour (table with too wide columns); in my case, the reason is a plain bug which will be fixed soon. Hopefully, your case will be similar. There are some other issues: 2. What to do with badly designed pages, which are now less readabe since dillo supports new CSS attribues? "adjust_min_width" is a solution to one of those problems. 3. It may be that incomplete support (say, floats but no absolute positions) may cause some problems. Anyway, I believe that most reports fall into the first category. Sebastian

Jan. 3, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Fri, Jan 02, 2015 at 07:32:52PM +0000, eocene wrote: > Sebastian wrote: > > Yes, I now see; I assume that you mean this: > > > > http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png > > > > I'll look at it. > > Yes, that. Thanks... I'm just using the new setting, and *anything* that helps to have better rendering is welcomed. It's a bit sad to find time and again that 3.0.4 has better rendering than the new branch. (e.g. [1]) OTOH, it looks like if dillo is the one to finally decide how to fit the layout and not the plethora of redundant & weird directives, our postmodern HTML pages have, it'll be much better for everybody. I mean, if the given directives pass our weirdness test, follow them, if not, use our criteria. May be adjustable too. e.g. 1: always follow dillo heuristics 2: when in shallow doubt, follow dillo heuristics 3: only if width exceeds viewport, follow dillo heuristics 4: only if the page is too large/weird, follow dillo heuristics. 5: always follow HTML/CSS/* directives. DISCLAIMER HINT: as stated before. In the long term past, similar schemes ended in just a simple "follow dillo's heuristics unless forced not to". [1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes -- Cheers Jorge.-

Jan. 2, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > Yes, I now see; I assume that you mean this: > > http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png > > I'll look at it. Yes, that. Thanks...

Jan. 2, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Fr, Jan 02, 2015, eocene wrote: > Sebastian wrote: > > > > > - on some sites, the ending words of a line are missing. > > > > > > The forecasts on the US national weather service page do this for me. > > > See the Detailed Forecast section. > > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > > demonstrated in the attached test page. Element #b is 1000px wide, but > > its parent, #a, is set to 100%, which refers to the viewport width > > (more or less), which may be less than 1000px. Note also #c, which is > > broken at the viewport width. > > > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > > set to 'YES', the width of #a, and so the srollable area, are adjusted > > (but not the width of #c), so that you can scroll to the right to read > > the rest. > > > > Currently, 'adjust_min_width' is not set by default. Probably, it > > should be set, to avoid such cases. What do you think? > > If it keeps text from being clipped, it sounds good. It is now set by default. > The weather page still breaks for me. Had you been able to reproduce the > problem earlier? I just tried moving dillorc and domainrc without any > effect on it. Yes, I now see; I assume that you mean this: http://www.dillo.org/~sgeerken/attic/forecast.weather.gov_01.png I'll look at it. Sebastian

Jan. 2, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > > > > - on some sites, the ending words of a line are missing. > > > > The forecasts on the US national weather service page do this for me. > > See the Detailed Forecast section. > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > demonstrated in the attached test page. Element #b is 1000px wide, but > its parent, #a, is set to 100%, which refers to the viewport width > (more or less), which may be less than 1000px. Note also #c, which is > broken at the viewport width. > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > set to 'YES', the width of #a, and so the srollable area, are adjusted > (but not the width of #c), so that you can scroll to the right to read > the rest. > > Currently, 'adjust_min_width' is not set by default. Probably, it > should be set, to avoid such cases. What do you think? If it keeps text from being clipped, it sounds good. The weather page still breaks for me. Had you been able to reproduce the problem earlier? I just tried moving dillorc and domainrc without any effect on it.

Jan. 2, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Fri, Jan 02, 2015 at 06:13:38PM +0100, Sebastian Geerken wrote: > > > > - on some sites, the ending words of a line are missing. > > > > The forecasts on the US national weather service page do this for me. > > See the Detailed Forecast section. > > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 > > I'm not sure, I cannot reproduce it now; but I've fixed a bug > demonstrated in the attached test page. Element #b is 1000px wide, but > its parent, #a, is set to 100%, which refers to the viewport width > (more or less), which may be less than 1000px. Note also #c, which is > broken at the viewport width. > > Without 'adjust_min_width' set, parts of #b are indeed clipped; when > set to 'YES', the width of #a, and so the srollable area, are adjusted > (but not the width of #c), so that you can scroll to the right to read > the rest. > > Currently, 'adjust_min_width' is not set by default. Probably, it > should be set, to avoid such cases. What do you think? Speaking from experience gained from having to handle HTML parsing errors, and table apportioning algorithms, with all the contradicting directives, overrides, etc. In the long run, having dillo decide the final values by adding a cleanup stage at some points, has emerged as the choice with better rendering. (e.g. w3c_plus_heuristics=YES, cleanup_at_{open, close}(), contrast_visited_color=YES, ... ;) -- Cheers Jorge.-

Jan. 2, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

> > > - on some sites, the ending words of a line are missing. > > The forecasts on the US national weather service page do this for me. > See the Detailed Forecast section. > Example: http://forecast.weather.gov/MapClick.php?lat=40&lon=-90 I'm not sure, I cannot reproduce it now; but I've fixed a bug demonstrated in the attached test page. Element #b is 1000px wide, but its parent, #a, is set to 100%, which refers to the viewport width (more or less), which may be less than 1000px. Note also #c, which is broken at the viewport width. Without 'adjust_min_width' set, parts of #b are indeed clipped; when set to 'YES', the width of #a, and so the srollable area, are adjusted (but not the width of #c), so that you can scroll to the right to read the rest. Currently, 'adjust_min_width' is not set by default. Probably, it should be set, to avoid such cases. What do you think? Sebastian

Jan. 2, 2015

what's currently broken in dillo

by eocene＠gmx.com

Sebastian wrote: > On Sun, Dec 28, 2014, eocene wrote: > > Sebastian wrote: > > > On Mi, Dez 24, 2014, eocene wrote: > > > > - on some sites, rendering never stops as the horizontal scrollbar shows the > > > > page growing wider and wider. > > > > arstechnica.com does this like 95% of the time (I think deterministically -- > > like you can catch them at a time when their html is such that it doesn't > > show the problem, but it normally does.) > > This seems fixed now. Great :)

Jan. 2, 2015