- Dillo-dev - lists.mailman3.com

What's the repository for latest dillo?

by Johannes.Hofmann＠gmx.de

Hi Walter, On Mon, Nov 17, 2014 at 12:31:46AM -0500, Walter Dnes wrote: > I've got dillo-3.0.4 running on Gentoo linux, with fltk-1.3.2. People > here seem to be running experimental "bleeding edge" versions. I assume > it's from a git repo. What are the instructions to download and build > dillo, preferably in my user directory? I'm aware that it may be broken > on edge cases. > > I'm not a C programmer. My main skills are in bash shell scripting. > If nothing else, I'll be another tester. instructions how to get the latest sources can be found at http://www.dillo.org/source.html Cheers, Johannes

Nov. 17, 2014

What's the repository for latest dillo?

by waltdnes＠waltdnes.org

I've got dillo-3.0.4 running on Gentoo linux, with fltk-1.3.2. People here seem to be running experimental "bleeding edge" versions. I assume it's from a git repo. What are the instructions to download and build dillo, preferably in my user directory? I'm aware that it may be broken on edge cases. I'm not a C programmer. My main skills are in bash shell scripting. If nothing else, I'll be another tester. -- Walter Dnes <waltdnes at waltdnes.org>

Nov. 17, 2014

what's currently broken in dillo

by onepoint＠starurchin.org

I wrote: > The Dillo source does something a little devious. It refers to > fl_oldfocus, but this symbol is not declared in any header, it is > just shared between two *.c files via an extern declaration (with a > comment that this is a hack to make Fl_Group work). Something has > changed in libfltk.so to stop the linker finding this symbol. I > don't know what (I am not experienced in debugging linking > failures.) Got it! When using autoconf, FLTK-1.3.3 compiles (if possible) with -fvisibility=hidden . This means that fl_oldfocus is marked as local instead of global in libfltk.so , which breaks linking Dillo. You can work around this with " ac_cv_cxx_fvisibility=no ./configure ... ". Regards, Jeremy Henty

Nov. 16, 2014

what's currently broken in dillo

by eocene＠gmx.com

Jeremy wrote: > The Dillo source does something a little devious. It refers to > fl_oldfocus, but this symbol is not declared in any header, it is just > shared between two *.c files via an extern declaration (with a comment > that this is a hack to make Fl_Group work). Something has changed in > libfltk.so to stop the linker finding this symbol. I don't know what > (I am not experienced in debugging linking failures.) To the best of my recollection, something tricky was necessary because Fl_Group didn't have the idea that the group itself could have focus instead of one of the children. I can't immediately see how to get it to work right without fl_oldfocus, but if we can't link, we have nothing, so I'll take out fl_oldfocus, and hopefully someone will figure out something at some point...

Nov. 16, 2014

what's currently broken in dillo

by onepoint＠starurchin.org

higuita wrote: > > > ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function > > > `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: > > > undefined reference to `fl_oldfocus' collect2: error: ld returned 1 > > > exit status make[3]: *** [dillo] Error 1 > > I'm not sure why you're getting that. > > I found that if i revert to fltk 1.3.2 it works, again building > the fltk 1.3.3, dillo build fails again. > > I have done make clean on fltk and dillo on every try and tried > to clean the system from any old files, but same results. > > greping the both fltk version for fl_oldfocus, i get the same > code, so is even weirder. > > Can someone reproduce this or i have something broken on my > system? I can reproduce this. The Dillo source does something a little devious. It refers to fl_oldfocus, but this symbol is not declared in any header, it is just shared between two *.c files via an extern declaration (with a comment that this is a hack to make Fl_Group work). Something has changed in libfltk.so to stop the linker finding this symbol. I don't know what (I am not experienced in debugging linking failures.) Incidentally, yoshimi also fails to link against FLTK-1.3.3, although a different symbol is involved. Regards, Jeremy Henty

Nov. 15, 2014

Strange linebreaking when long hyphenated words appear in table cells

by onepoint＠starurchin.org

The attached file demonstrates the problem. The test in the first paragraph easily linebreaks to fit the width of the window because of the potential linebreaks after each hyphen. The same text inside of a table cell forces the cell to be almost as wide as the unbroken text, although some line breaking does happen. My guess is that Dillo calculates the minimum width of the table cell without accounting for potential linebreaks after hyphens in the text. However, when it later fills the cell with the text it does allow linebreaks after hyphens. If that is correct then I think Dillo should account for potential linebreaks after hyphens both when calculating the minimum width of the cell and when filling the cell with text. The current situation is inconsistent and can deliver very poor results. Regards, Jeremy Henty

Nov. 14, 2014

Assertion `oofm->wasAllocated (fl2->generatingBlock)' failed.

by sgeerken＠dillo.org

On Mi, Nov 05, 2014, eocene wrote: > outofflowmgr.cc:203: virtual int > dw::OutOfFlowMgr::Float::ComparePosition::compare(lout::object::Object*, > lout::object::Object*): Assertion `oofm->wasAllocated > (fl2->generatingBlock)' failed. [...] This assertion is indeed wrong, and has been removed, along with some others. Sebastian

Nov. 9, 2014

assert failed when using text search while page still loading

by eocene＠gmx.com

Sebastian wrote: > On Fri, Oct 24, 2014, Sebastian Geerken wrote: > > I've problems to reproduce it, but I'm guessing ... > > > > On Do, Okt 23, 2014, eocene wrote: > > > (gdb) bt > > > #0 0xb778a424 in __kernel_vsyscall () > > > #1 0xb70b2661 in *__GI_raise (sig=6) > > > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > > > #2 0xb70b5a92 in *__GI_abort () at abort.c:92 > > > #3 0xb70ab878 in *__GI___assert_fail ( > > > assertion=0x816049e "i >= 0 && this->num - i > 0", > > > file=0x816048e "../lout/misc.hh", line=167, > > > function=0x8160540 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 > > > #4 0x080a73f6 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( > > > this=0x905df50, i=-1) at ../lout/misc.hh:167 > > > #5 0x080a8447 in dw::Textblock::TextblockIterator::getAllocation ( > > > this=0x885ef98, start=0, end=5, allocation=0xbff2e818) > > > at textblock_iterator.cc:288 > > > > A line is missing, but everything else seems OK. I guess that this has > > to do with the new line breaking (introduced with release 3.0.3), > > where some words are not immediately assigned to a line. I'll soon > > work on this. > > I just pushed a fix. Does the problem still occur? I'll probably be lucky to trigger the right conditions again, but I'll try to make a habit of searching for text while waiting for pages to load and render...

Nov. 7, 2014

assert failed when using text search while page still loading

by sgeerken＠dillo.org

On Fri, Oct 24, 2014, Sebastian Geerken wrote: > I've problems to reproduce it, but I'm guessing ... > > On Do, Okt 23, 2014, eocene wrote: > > (gdb) bt > > #0 0xb778a424 in __kernel_vsyscall () > > #1 0xb70b2661 in *__GI_raise (sig=6) > > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > > #2 0xb70b5a92 in *__GI_abort () at abort.c:92 > > #3 0xb70ab878 in *__GI___assert_fail ( > > assertion=0x816049e "i >= 0 && this->num - i > 0", > > file=0x816048e "../lout/misc.hh", line=167, > > function=0x8160540 "T* lout::misc::SimpleVector<T>::getRef(int) const [with T = dw::Textblock::Line]") at assert.c:81 > > #4 0x080a73f6 in lout::misc::SimpleVector<dw::Textblock::Line>::getRef ( > > this=0x905df50, i=-1) at ../lout/misc.hh:167 > > #5 0x080a8447 in dw::Textblock::TextblockIterator::getAllocation ( > > this=0x885ef98, start=0, end=5, allocation=0xbff2e818) > > at textblock_iterator.cc:288 > > A line is missing, but everything else seems OK. I guess that this has > to do with the new line breaking (introduced with release 3.0.3), > where some words are not immediately assigned to a line. I'll soon > work on this. I just pushed a fix. Does the problem still occur? Sebastian

Nov. 6, 2014

Assertion `oofm->wasAllocated (fl2->generatingBlock)' failed.

by eocene＠gmx.com

outofflowmgr.cc:203: virtual int dw::OutOfFlowMgr::Float::ComparePosition::compare(lout::object::Object*, lout::object::Object*): Assertion `oofm->wasAllocated (fl2->generatingBlock)' failed. (gdb) bt #0 0xb7705424 in __kernel_vsyscall () #1 0xb702d661 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0xb7030a92 in *__GI_abort () at abort.c:92 #3 0xb7026878 in *__GI___assert_fail ( assertion=0x814bcf0 "oofm->wasAllocated (fl2->generatingBlock)", file=0x814bc53 "outofflowmgr.cc", line=203, function=0x814c2e0 "virtual int dw::OutOfFlowMgr::Float::ComparePosition::compare(lout::object::Object*, lout::object::Object*)") at assert.c:81 #4 0x080b0a83 in dw::OutOfFlowMgr::Float::ComparePosition::compare ( this=0xbfcd6d6c, o1=0xbfcd6d18, o2=0x89c46d8) at outofflowmgr.cc:203 #5 0x080d926c in lout::container::untyped::Vector::bsearch (this=0x8b29898, key=0xbfcd6d18, mustExist=false, start=0, end=6, comparator=0xbfcd6d6c) at container.cc:239 #6 0x080b5607 in lout::container::typed::Vector<dw::OutOfFlowMgr::Float>::bsearch (this=0x8a63970, key=0xbfcd6d18, mustExist=false, start=0, end=6, comparator=0xbfcd6d6c) at ../lout/container.hh:451 #7 0x080b0f24 in dw::OutOfFlowMgr::SortedFloatsVector::find (this=0x8a63970, textblock=0x887dc60, y=4079, start=0, end=6) at outofflowmgr.cc:382 #8 0x080b0fdd in dw::OutOfFlowMgr::SortedFloatsVector::findFirst ( this=0x8a63970, textblock=0x887dc60, y=4079, h=1, lastGB=0x887dc60, lastExtIndex=9, lastReturn=0x0) at outofflowmgr.cc:429 #9 0x080b458f in dw::OutOfFlowMgr::hasFloat (this=0x8a526d0, textblock=0x887dc60, side=dw::OutOfFlowMgr::LEFT, y=4079, h=1, lastGB=0x887dc60, lastExtIndex=9) at outofflowmgr.cc:2172 #10 0x080b44df in dw::OutOfFlowMgr::hasFloatLeft (this=0x8a526d0, textblock=0x887dc60, y=4079, h=1, lastGB=0x887dc60, lastExtIndex=9) at outofflowmgr.cc:2149 #11 0x080ac7c2 in dw::Textblock::calcBorders (this=0x887dc60, lastOofRef=-1, height=1) at textblock_linebreaking.cc:1986 #12 0x080aa385 in dw::Textblock::balanceBreakPosAndHeight (this=0x887dc60, wordIndex=19, firstIndex=10, searchUntil=0xbfcd6f58, tempNewLine=true, penaltyIndex=0, borderIsCalculated=true, thereWillBeMoreSpace=0xbfcd6f5f, wrapAll=true, diffWords=0xbfcd6f60, wordIndexEnd=0xbfcd6f54, lastFloatPos=0xbfcd6f48, regardBorder=true, height=0xbfcd6f50, breakPos=0xbfcd6f4c) at textblock_linebreaking.cc:893 #13 0x080a9f81 in dw::Textblock::wrapWordInFlow (this=0x887dc60, wordIndex=19, wrapAll=true) at textblock_linebreaking.cc:728 #14 0x080a9bfa in dw::Textblock::wordWrap (this=0x887dc60, wordIndex=19, wrapAll=true) at textblock_linebreaking.cc:588 #15 0x080aca94 in dw::Textblock::showMissingLines (this=0x887dc60) at textblock_linebreaking.cc:2054 #16 0x0809febd in dw::Textblock::sizeAllocateImpl (this=0x887dc60, allocation=0xbfcd7160) at textblock.cc:562 #17 0x080d6ed5 in dw::core::Widget::sizeAllocate (this=0x887dc60, allocation=0xbfcd7160) at widget.cc:986 #18 0x080a0340 in dw::Textblock::sizeAllocateImpl (this=0x87fa748, allocation=0xbfcd7240) at textblock.cc:731 #19 0x080d6ed5 in dw::core::Widget::sizeAllocate (this=0x87fa748, allocation=0xbfcd7240) at widget.cc:986 #20 0x080cb35c in dw::core::Layout::resizeIdle (this=0x875f858) at layout.cc:912 #21 0x080b9b48 in dw::fltk::FltkPlatform::generalIdle (this=0x874fc58) at fltkplatform.cc:627 #22 0x080b9ad0 in dw::fltk::FltkPlatform::generalStaticIdle (data=0x874fc58) at fltkplatform.cc:617

Nov. 5, 2014