- Dillo-dev - lists.mailman3.com

Splitting html.cc: moving stuff into the form source

by onepoint＠starurchin.org

These patches move some declarations into form.hh and the form API into form.cc . Note that the form class declarations will move into form.cc later, for now they must be in form.hh . Regards, Jeremy Henty

June 5, 2008

recent style/layout segfaults

by corvid＠lavabit.com

I've seen occasional segfaults in recent weeks, and twice now I've been able to catch them when I remembered to have gdb going (and, well, zero times when I remembered to have ulimit -c unlimited) These two have been nearly identical. Here's the one I just got: #0 0x00000048 in ?? () #1 0x080aa74e in dw::core::Layout::removeFont (this=0x815ca58, attrs=0x81dfc08) at layout.hh:253 #2 0x080a8f07 in dw::core::style::Font::remove (this=0x81dfc08, layout=0x815ca58) at style.cc:287 #3 0x080aa85a in dw::core::style::Font::unref (this=0x81dfc08, layout=0x815ca58) at style.hh:587 #4 0x080aa042 in ~Style (this=0x81d8680) at style.cc:204 #5 0x0805b123 in dw::core::style::Style::unref (this=0x81d8680) at style.hh:505 #6 0x08089359 in ~Textblock (this=0x8249308) at textblock.cc:96 #7 0x080a52e7 in dw::core::Layout::setWidget (this=0x822f868, widget=0x827b3b0) at layout.cc:175 #8 0x0805aea8 in a_Web_dispatch_by_type ( Type=0x827c480 "text/html; charset=UTF-8", Web=0x824ebc0, Call=0x821d320, Data=0x821d324) at web.cc:94 .. The layout in frame 3 was: p *layout $7 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x814c0f0, views = 0x815cb78, topLevel = 0x0, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 0, canvasAscent = 0, canvasDescent = 0, usesViewport = true, scrollX = 0, scrollY = 0, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x815cba0, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x815ca58, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 1, toChar = 1, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 3, link = 0x0, linkChar = 3, linkNumber = 13}, findtextState = {key = 0x0, caseSens = 32, nexttab = 0x0, widget = 0x0, iterator = 0x0, hlIterator = 0x0}} and the layout in frame 7 was: p *this $8 = {<> = {<No data fields>}, emitter = {<> = {<No data fields>}, <No data fields>}, platform = 0x8281808, views = 0x8246f38, topLevel = 0x8249308, widgetAtPoint = 0x0, bgColor = 0x823a278, cursor = dw::core::style::CURSOR_DEFAULT, canvasWidth = 665, canvasAscent = 5, canvasDescent = 11564, usesViewport = true, scrollX = 0, scrollY = 8854, viewportWidth = 680, viewportHeight = 482, canvasHeightGreater = true, hScrollbarThickness = 15, vScrollbarThickness = 15, scrollTargetHpos = dw::core::HPOS_LEFT, scrollTargetVpos = dw::core::VPOS_TOP, scrollTargetX = 0, scrollTargetY = 0, scrollTargetWidth = 0, scrollTargetHeight = 0, requestedAnchor = 0x0, scrollIdleId = -1, resizeIdleId = -1, asapResizeIdle = true, scrollIdleNotInterrupted = true, anchorsTable = 0x81e4078, selectionState = { doubleClickEmitter = {<> = {<No data fields>}, <No data fields>}, layout = 0x822f868, selectionState = dw::core::SelectionState::NONE, from = 0x0, to = 0x0, fromChar = 3, toChar = 3, linkState = dw::core::SelectionState::LINK_NONE, linkButton = 136509888, link = 0x0, linkChar = 136509920, linkNumber = 0}, findtextState = { key = 0x0, caseSens = 16, nexttab = 0x0, widget = 0x8249308, iterator = 0x0, hlIterator = 0x0}} Both look fairly layoutish. I only had one bw open at the time of crash. My guess at the problem: StyleTable will give you back whatever Style matches your attrs, but maybe that Style was created with a different layout.

June 5, 2008

Splitting html.cc: common functions, part *2*

by onepoint＠starurchin.org

The rest of the renaming. Jeremy Henty

June 5, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

<headslap> Here's the patch. The followup to *this* will complete the renaming. Jeremy Henty

June 5, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

This patch moves some function declarations from html.cc to html_common.hh . It only does *some* of the renaming because the full patch breaks the list's moderation limit. I'll follow up to this message with the rest of the renaming. You may want to batch this patch and the followup together as a single commit. Please comment! Jeremy Henty

June 5, 2008

Re: Splitting html.cc

by jcid＠dillo.org

On Thu, Jun 05, 2008 at 03:48:53PM +0100, Jeremy Henty wrote: > On Thu, Jun 05, 2008 at 09:02:28AM -0400, Jorge Arellano Cid wrote: > > On Wed, Jun 04, 2008 at 03:38:38PM +0100, Jeremy Henty wrote: > > > > > The next step is to move some of the function declarations across, > > > but that depends on deciding what to do with the function names. > > > Should I rename "Html_*" to "a_Html_*"? > > > > I'd prefer to have C functions called from other sources as > > a_Html_*. > > OK, but how does that rule apply to Html_tag_{open,close}_*() ? They > aren't explicitly called anywhere, They are called by the parser from inside html.cc. > just referenced from the Tags array > in html.cc . The split will move some of them into form.cc . It > would be ugly to rename some of them but not others. If the plan is > to move most or all of them to separate files like form.cc (which I > think would be a good way to split up html.cc) then perhaps we should > rename them all to a_Html_tag_{open,close}_*() in advance? As the Html_tag_{open,close}_*() functions are closely related to the parser, I'd prefer to have them not renamed. If there's a need, these functions could call a_Form_*() functions. Something like: Html_open_form () { [...] a_Form_do_something() [...] } -- Cheers Jorge.-

June 5, 2008

Re: Splitting html.cc

by onepoint＠starurchin.org

On Thu, Jun 05, 2008 at 09:02:28AM -0400, Jorge Arellano Cid wrote: > On Wed, Jun 04, 2008 at 03:38:38PM +0100, Jeremy Henty wrote: > > > The next step is to move some of the function declarations across, > > but that depends on deciding what to do with the function names. > > Should I rename "Html_*" to "a_Html_*"? > > I'd prefer to have C functions called from other sources as > a_Html_*. OK, but how does that rule apply to Html_tag_{open,close}_*() ? They aren't explicitly called anywhere, just referenced from the Tags array in html.cc . The split will move some of them into form.cc . It would be ugly to rename some of them but not others. If the plan is to move most or all of them to separate files like form.cc (which I think would be a good way to split up html.cc) then perhaps we should rename them all to a_Html_tag_{open,close}_*() in advance? I'll submit more patches as soon as this is decided. Regards, Jeremy Henty

June 5, 2008

Re: Splitting html.cc

by jcid＠dillo.org

On Wed, Jun 04, 2008 at 03:38:38PM +0100, Jeremy Henty wrote: > > The first patch in this set creates stubs for the new files and adds > them to the build. Developers should run " make maintainer-clean ; > ./autogen.sh " after checking this out so that the new source file is > compiled. > > The other patches move some macros, typedefs, structs and class > definitions from html.cc into the new headers. Committed. > The next step is to move some of the function declarations across, but > that depends on deciding what to do with the function names. Should I > rename "Html_*" to "a_Html_*"? In other words, do functions in > form.hh count as part of the Html module API or part of its internals. > I am inclined to say they are internal and so not rename them. > Comments? I'd prefer to have C functions called from other sources as a_Html_*. -- Cheers Jorge.-

June 5, 2008

Re: Splitting html.cc

by onepoint＠starurchin.org

The first patch in this set creates stubs for the new files and adds them to the build. Developers should run " make maintainer-clean ; ./autogen.sh " after checking this out so that the new source file is compiled. The other patches move some macros, typedefs, structs and class definitions from html.cc into the new headers. The next step is to move some of the function declarations across, but that depends on deciding what to do with the function names. Should I rename "Html_*" to "a_Html_*"? In other words, do functions in form.hh count as part of the Html module API or part of its internals. I am inclined to say they are internal and so not rename them. Comments? Regards, Jeremy Henty

June 4, 2008

fltk2 snapshot update

by jcid＠dillo.org

On Mon, Jun 02, 2008 at 04:26:55PM +0200, Johannes Hofmann wrote: > Hi, > > at fltk.org there is a new fltk2 snaphot (r6132) available. It contains a > bugfix for the weird green artifacts in the FileChooser. I think we > should update the download instructions. > BTW, shouldn't we point users directly to fltk.org for downloading > fltk2? Otherwise people might think that dillo2 needs a > modified version of fltk2. Done. As the latest FLTK2 has worked OK for us the last months. -- Cheers Jorge.-

June 4, 2008