- Dillo-dev - lists.mailman3.com

form.cc: make Html_get_input_values a method

by jcid＠dillo.org

On Sun, Jun 08, 2008 at 06:16:45PM +0100, Jeremy Henty wrote: > > Changes Html_get_input_values() to DilloHtmlInput::getInputValues() . > The first patch makes the change, the second moves the definition to > the right place in the file. Committed. -- Cheers Jorge.-

June 8, 2008

form.cc: make Html_get_input_values a method

by onepoint＠starurchin.org

Changes Html_get_input_values() to DilloHtmlInput::getInputValues() . The first patch makes the change, the second moves the definition to the right place in the file. Regards, Jeremy Henty

June 8, 2008

another segfault

by Johannes.Hofmann＠gmx.de

On Sun, Jun 08, 2008 at 11:36:57AM -0400, Jorge Arellano Cid wrote: > On Sun, Jun 08, 2008 at 08:55:52AM +0200, Johannes Hofmann wrote: > > On Sat, Jun 07, 2008 at 06:49:22PM -0400, Jorge Arellano Cid wrote: > > > On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > > > > Johannes wrote: > > > > > now I've got some more info on that problem. The buffer on which > > > > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > > > > a_Cache_set_content_type(). I don't understand the details though. > > > > > Do you have an idea? > > > > > > > > Ah! Does this help? > > > > > > > > > > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > > > > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > > > > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > > > > /* Call the open function for this tag */ > > > > Tags[ni].open (html, tag, tagsize); > > > > > > > > + if (html->stop_parser) > > > > + return; > > > > + > > > > /* Now parse attributes that can appear on any tag */ > > > > if (tagsize >= 8 && /* length of "<t id=i>" */ > > > > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", > > > > > > > > > I tried to simplify the code by avoiding a return point in the middle of > > > the function. It took long to figure a way! > > > > > > Please test the patch in CVS. > > > > Are you sure it's in CVS? Current CVS still shows the bug. > > Yes. > > If you have a switch statement in Html_process_tag(), that's it. > Now I've got it. Works fine. For some reason I got this change only now from CVS. Thanks, Johannes

June 8, 2008

another segfault

by jcid＠dillo.org

On Sun, Jun 08, 2008 at 08:55:52AM +0200, Johannes Hofmann wrote: > On Sat, Jun 07, 2008 at 06:49:22PM -0400, Jorge Arellano Cid wrote: > > On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > > > Johannes wrote: > > > > now I've got some more info on that problem. The buffer on which > > > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > > > a_Cache_set_content_type(). I don't understand the details though. > > > > Do you have an idea? > > > > > > Ah! Does this help? > > > > > > > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > > > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > > > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > > > /* Call the open function for this tag */ > > > Tags[ni].open (html, tag, tagsize); > > > > > > + if (html->stop_parser) > > > + return; > > > + > > > /* Now parse attributes that can appear on any tag */ > > > if (tagsize >= 8 && /* length of "<t id=i>" */ > > > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", > > > > > > I tried to simplify the code by avoiding a return point in the middle of > > the function. It took long to figure a way! > > > > Please test the patch in CVS. > > Are you sure it's in CVS? Current CVS still shows the bug. Yes. If you have a switch statement in Html_process_tag(), that's it. -- Cheers Jorge.-

June 8, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > > That would be really cool. A few days ago I thought of something > > like that for Gimp: > > > > * all important objects are made accessible via 9P > > * an shell (eg. bash) is extended to support 9P directly > > * an special terminal (eg. via splitvt) runs both shell and > > some status like app > > * user commands can be easily written as shellscript functions > > Yes, in my _real_ dream world, one of the global distributed system > projects would have taken over and we wouldn't have web browsers at all. You might like have a look at Plan9 and how things are done there. We can learn really much from it :) cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 8, 2008

Small html and form cleanups

by jcid＠dillo.org

On Sun, Jun 08, 2008 at 05:52:47AM +0100, Jeremy Henty wrote: > > How about some *small* patches for a change? :-) > > * "a_Html_free()" is only used in html.cc , so change it to "static > Html_free()". > * The form argument of Html_input _image is unused, so delete it. > * The html.cc code that uses debug.h has moved to form.cc , so > remove the '#include "debug.h"' and move the '#define > DEBUG_LEVEL'. Committed. -- Cheers Jorge.-

June 8, 2008

another segfault

by corvid＠lavabit.com

Johannes wrote: > On Sat, Jun 07, 2008 at 06:49:22PM -0400, Jorge Arellano Cid wrote: > > On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > > > Johannes wrote: > > > > now I've got some more info on that problem. The buffer on which > > > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > > > a_Cache_set_content_type(). I don't understand the details though. > > > > Do you have an idea? > > > > > > Ah! Does this help? > > > > > > > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > > > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > > > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > > > /* Call the open function for this tag */ > > > Tags[ni].open (html, tag, tagsize); > > > > > > + if (html->stop_parser) > > > + return; > > > + > > > /* Now parse attributes that can appear on any tag */ > > > if (tagsize >= 8 && /* length of "<t id=i>" */ > > > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", > > > > > > I tried to simplify the code by avoiding a return point in the middle of > > the function. It took long to figure a way! > > > > Please test the patch in CVS. > > Are you sure it's in CVS? Current CVS still shows the bug. How is it breaking?

June 8, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* Jorge Arellano Cid <jcid(a)dillo.org> schrieb: Hi, > I believe one of the important things that we could support is > custom keyboard shortcuts in dillorc. ACK. Maybe would should go the way Mutt does: it internally works with commands, and keystrokes are mapped to commands. Such an simple command interpreter would be cool. If Dillo also provides an 9P server which publishes internal states and an command channel, it would be even cooler :) > * right-click context menus. > * providing some keyboard shortcuts. Both should be configurable. > AFAICS multiple dillorc files are simpler. ACK cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 8, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 10:16:14PM +0000, corvid wrote: > Johannes wrote: > > Comments welcome! I feel a bit uncomfortable proposing a > > pretty drastic change like this. > > Although obviously I don't know the code well, it seems like an improvement. > > PS Jeremy's new html.cc is in CVS now, so the dillo2 part of the patch > no longer applies very cleanly. Ah ok. I updated the dillo2 part: http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dillo2

June 8, 2008

another segfault

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 06:49:22PM -0400, Jorge Arellano Cid wrote: > On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > > Johannes wrote: > > > now I've got some more info on that problem. The buffer on which > > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > > a_Cache_set_content_type(). I don't understand the details though. > > > Do you have an idea? > > > > Ah! Does this help? > > > > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > > /* Call the open function for this tag */ > > Tags[ni].open (html, tag, tagsize); > > > > + if (html->stop_parser) > > + return; > > + > > /* Now parse attributes that can appear on any tag */ > > if (tagsize >= 8 && /* length of "<t id=i>" */ > > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", > > > I tried to simplify the code by avoiding a return point in the middle of > the function. It took long to figure a way! > > Please test the patch in CVS. Are you sure it's in CVS? Current CVS still shows the bug. Cheers, Johannes

June 8, 2008

Small html and form cleanups

by onepoint＠starurchin.org

How about some *small* patches for a change? :-) * "a_Html_free()" is only used in html.cc , so change it to "static Html_free()". * The form argument of Html_input _image is unused, so delete it. * The html.cc code that uses debug.h has moved to form.cc , so remove the '#include "debug.h"' and move the '#define DEBUG_LEVEL'. Regards, Jeremy Henty

June 8, 2008

patch: image input data submission

by jcid＠dillo.org

On Sat, Jun 07, 2008 at 11:59:00PM +0000, corvid wrote: > For image inputs, the dillo1 code would send > name=value > name.x=x-coord > name.y=y-coord > > When I was getting this working for dillo2, I was uncertain whether > name=value should be in there > (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004085.html) > I saw that firefox didn't send it, but I left it alone, since including it > shouldn't hurt anything. > > I later saw that it was clearer in html3.2: > "The x and y values of the location clicked are passed to the server: In > the submitted data, image fields are included as two name/value pairs. The > names are derived by taking the name of the field and appending ".x" for > the x value, and ".y" for the y value." > > and just as clear as day in "web forms 2.0": > "Image buttons, during this step, must be handled as if they were two > controls, one with the control's name with .x appended, whose value is > the x coordinate selected by the user, and the other with the control's > name with .y appended, whose value is the y coordinate selected by the > user. If the control's name is the empty string (e.g. if the name attribute > is omitted) then the names x and y must be used instead." > > > So I'll sneak in a patch before Jeremy gets back to form cleanup. > (All that actually changes in buildQueryData() is that the > DILLO_HTML_INPUT_IMAGE case goes up above Html_get_input_values() ) > Committed. -- Cheers Jorge.-

June 8, 2008

patch: image input data submission

by corvid＠lavabit.com

For image inputs, the dillo1 code would send name=value name.x=x-coord name.y=y-coord When I was getting this working for dillo2, I was uncertain whether name=value should be in there (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-April/004085.html) I saw that firefox didn't send it, but I left it alone, since including it shouldn't hurt anything. I later saw that it was clearer in html3.2: "The x and y values of the location clicked are passed to the server: In the submitted data, image fields are included as two name/value pairs. The names are derived by taking the name of the field and appending ".x" for the x value, and ".y" for the y value." and just as clear as day in "web forms 2.0": "Image buttons, during this step, must be handled as if they were two controls, one with the control's name with .x appended, whose value is the x coordinate selected by the user, and the other with the control's name with .y appended, whose value is the y coordinate selected by the user. If the control's name is the empty string (e.g. if the name attribute is omitted) then the names x and y must be used instead." So I'll sneak in a patch before Jeremy gets back to form cleanup. (All that actually changes in buildQueryData() is that the DILLO_HTML_INPUT_IMAGE case goes up above Html_get_input_values() )

June 8, 2008

another segfault

by jcid＠dillo.org

On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > Johannes wrote: > > now I've got some more info on that problem. The buffer on which > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > a_Cache_set_content_type(). I don't understand the details though. > > Do you have an idea? > > Ah! Does this help? > > --- dillo2/src/html.cc 2008-06-05 14:06:50.000000000 +0000 > +++ dillo2-cur/src/html.cc 2008-06-07 14:16:37.000000000 +0000 > @@ -5449,6 +5449,9 @@ static void Html_process_tag(DilloHtml * > /* Call the open function for this tag */ > Tags[ni].open (html, tag, tagsize); > > + if (html->stop_parser) > + return; > + > /* Now parse attributes that can appear on any tag */ > if (tagsize >= 8 && /* length of "<t id=i>" */ > (attrbuf = Html_get_attr2(html, tag, tagsize, "id", I tried to simplify the code by avoiding a return point in the middle of the function. It took long to figure a way! Please test the patch in CVS. -- Cheers Jorge.-

June 8, 2008

recent style/layout segfaults

by corvid＠lavabit.com

Johannes wrote: > Comments welcome! I feel a bit uncomfortable proposing a > pretty drastic change like this. Although obviously I don't know the code well, it seems like an improvement. PS Jeremy's new html.cc is in CVS now, so the dillo2 part of the patch no longer applies very cleanly.

June 8, 2008

RFC: removing the search dialog

by jcid＠dillo.org

Hi, Finally I got some time to answer this subject that needs some thought. > [Justus wrote:] > I was thinking about improving the dillo experience by adding some > functionality / shortcuts people have come to expect. But what people > expect is influenced by their background, their choice of desktop > environment and platform. Yes, the main point is different people like things in different ways. If we can provide a simple way to do things and offer the possibility to customize _some_ things, better. I believe one of the important things that we could support is custom keyboard shortcuts in dillorc. There are different shortcut sets, hardcoded into the user's brain, and they depend on what apps. the person is accustomed to use. For instance, if I've been using an editor where the "find text" function is F3, I'd like to have F3 do the same in dillo. > [Justus wrote:] > We could pick one / some user interface guideline(s) ([1] lists some) > and try to adhere to it / them. Or we could pick one popular browser and > copy its 'feel'. Dillo has come to have it's own "simple" feel, and users have been communicative in making clear they like it. Now that we changed the UI, we have to define some things though. The basic model behind dillo is simplicity achieved with: * right-click context menus. * providing some keyboard shortcuts. As stated before, we can improve it by allowing custom keybindings. On Sat, May 24, 2008 at 04:44:32AM +0200, Justus Winter wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hey :) > > I hacked up opera (at least I _think_ they do it this way) style search > engine handling. I am not too happy with what I did to the config file > parser, but it works for now :). I like the idea of having multiple search engines. As a matter of fact since some years (But manpower/priorities etc...). Well, the CLI is mainly for advanced users, and I'd like to provide a UI that's orthogonal with what we have before tackling a CLI. For instance, the same search engines can be listed from a right-click menu on the search button. e.g. .------------------. . Google . . Wikipedia . . Free Dictionary . . Linux Packages . . SomeWhere Else . '------------------' Now, if a dialog pops-up: .-------------------------------------. . Search Wikipedia: . . [ ] . . [Cancel] [OK] . '-------------------------------------' it'd be quite simple and mnemonic. OTOH, if instead of dialog, the Location bar is focused, it'd not be clear for a new user whether it is for an URL or a new text string. The pop-up provides enough clues. If the pop-up dialog is to be avoided, it'd be nice to have it displaying the same information in the panel, perhaps hiding the navigation buttons. .----------------------------------------------------------------------. . Search Wikipedia: . . [ ] [P] . '----------------------------------------------------------------------' (now we have enough visual clues) Why up and not down like findtext, because that way is easier to tell web searching from page searching (I used to make that mistake a lot! :-) BTW, I don't yet know why avoiding pop-up dialogs is considered good. Don't get me wrong, I prefer the find text bar as it is now, but for other things, I don't yet see the problem. For instance on popup dialogs, messages and inputs. <topic change> Ctrl-X shortcuts in menus: This is another topic that needs feedback. The simplicity of current right-click menus is nice, but they don't provide mnemonic feedback on what shortcuts the listed items have. Probably having the shortcuts listed outclasses the readability, and they should be back, together with a shortcut customization scheme. > I am not sure what I would like to see, but for the moment I'd go with > dictionaries and the ability to include other files. This way we could > ship some config files (think browser personalities) and the user could > include the one he likes best and fine tune the settings in his personal > dillorc. AFAICS multiple dillorc files are simpler. > I was also unsure about the proper way to inform the user of errors and > I believe the reason for this is simply that there is no mechanism to do > this properly. Currently there are two ways: * pop-up dialog message. * status bar message. Openning a new dillo window with a custom HTML message is an option too. The advantages/disadvantages should be considered. For instance, with "view source", there's the clear advantage of having "find text" functionality for free. -- Cheers Jorge.-

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 06:04:07PM +0200, Johannes Hofmann wrote: > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > 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) > > > > > > I had some of these segfaults too. > > > > > > > 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 > > [snip] > > > > 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. > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > associated with a layout too. > > > > It looks like style uses layout to get to platform. I wonder whether > > it would go against any dw rules to let style have platform. > > > > My problem is that I don't understand why fontsTable and > colorsTable need to be platform specific in the first place. > As long as their members match they should be sharable - even > if they are used for different platforms. > > I would just make them static members of Font and Color > respectively. That way we would no longer need the layout parameter > in the *::create methods. To make clear what I mean, here comes the patch: http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dw2 http://www.ecademix.com/JohannesHofmann/tmp/layoutless_style.dillo2 (they are too large for the list). I'm not sure why Sebastian avoided that possiblity. Maybe the virtual destructors which are needed in this implementation? Comments welcome! I feel a bit uncomfortable proposing a pretty drastic change like this. Cheers, Johannes

June 7, 2008

should zlib be required?

by weigelt＠metux.de

* Joerg Sonnenberger <joerg.sonnenberger(a)web.de> schrieb: > On Sat, Jun 07, 2008 at 09:33:51PM +0200, Enrico Weigelt wrote: > > If Dillo requires zlib by itself, it should import it propery > > (eg. via pkg-config). > > ...and since when does zlib provide any pkg-config glue? The OSS-QM branch does for quite a long time, and uptream has signalled to include my patch. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

Future of dillo2

by weigelt＠metux.de

* Jorge Arellano Cid <jcid(a)dillo.org> schrieb: Hi, > i. - Increase the development team by adding 6+ new developers. > ii.- Getting more involved with other projects. you can add me, as long as no C++ stuff is involved. (don't like it's overhead). I'm already working on German translation. > * Planning for CSS, floating objects and TABS. > (this are important features to a nice browsing experience) Missing CSS is really bad. I'm planning to write an universal but small CSS parser (as an separate library). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

should zlib be required?

by joerg.sonnenberger＠web.de

On Sat, Jun 07, 2008 at 09:33:51PM +0200, Enrico Weigelt wrote: > If Dillo requires zlib by itself, it should import it propery > (eg. via pkg-config). ...and since when does zlib provide any pkg-config glue? Joerg

June 7, 2008

should zlib be required?

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > Should zlib be required? > > I notice that testing for zlib is currently just a part of > deciding whether to enable png. I either need to make configure.in > require it, or make zlib optional with some ifdefs. libpng's zlib-dependency is not Dillo's business. So you should fix configure.in to properly call pkg-config (this was the first thing I did in my branch) If Dillo requires zlib by itself, it should import it propery (eg. via pkg-config). cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* corvid <corvid(a)lavabit.com> schrieb: > Justus wrote: > > I hacked up opera (at least I _think_ they do it this way) style search > > engine handling. > > In my dream world, web browsers would have command lines instead of > location bars. That would be really cool. A few days ago I thought of something like that for Gimp: * all important objects are made accessible via 9P * an shell (eg. bash) is extended to support 9P directly * an special terminal (eg. via splitvt) runs both shell and some status like app * user commands can be easily written as shellscript functions cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

RFC: removing the search dialog

by weigelt＠metux.de

* Justus Winter <4winter(a)informatik.uni-hamburg.de> schrieb: Hi, > I hacked up opera (at least I _think_ they do it this way) style search > engine handling. I am not too happy with what I did to the config file > parser, but it works for now :). The parser is beautiful in its > simplicity, but it has its limitations (like not being able to handle > dictionaries). What exactly do you mean w/ "dictionaries" ? An list of values ? Then simply use an extra text file. I'm currently developing an tiny desktop environment for unexperienced users and there I often need hierachical config data (even w/ binary content). The filesystem (plus atoi()+friends) is completely enough for that purpose. Can't imagine anything simpler ;-P All filesystem access runs through my userland vfs library, libmvfs. So it's trivial to use other datasources than the local fs, eg. via 9P. > I am not sure what I would like to see, but for the moment I'd go with > dictionaries and the ability to include other files. Includes and macros can be easily done via cpp. > I was also unsure about the proper way to inform the user of errors and > I believe the reason for this is simply that there is no mechanism to do > this properly. > > I am thinking about using the browser widget to render error pages like > most of the mainstream browsers. Any thoughts on this one? Isn't an simple popup window enough ? <snip> > +# The syntax is > +# > +# search_url="<id>|<url>" > +# > +# This sets the search URL to use with "<id> <keywords>". > +# %s in the URL is replaced with keywords separated by '+'. > + > +search_url="g|http://www.google.com/search?q=%s" > +search_url="ly|http://search.lycos.com/default.asp?query=%s" > +search_url="aw|http://www.alltheweb.com/search?cat=web&query=%s" > +search_url="y|http://search.yahoo.com/search?p=%s" > +search_url="l|http://localhost/cgi-bin/htsearch?words=%s" > +search_url="cc|http://search.creativecommons.org/?q=%s" > +search_url="d|http://www.dict.cc/?s=%s" I'd prefer to have this in an extra file. Separation via whitespace seems to convenient to me. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

Executing commands via URL

by weigelt＠metux.de

Hi folks, I'd like to use Dillo for an help system and control center on an end-user desktop appliance. Therefore I need it to execute certain commands. But Dillo itself should not fork/exec itself, instead send the commands to some special daemon via an 9P channel. An simple approach could be coding an dpi which just parses the requested URL and sends the actual command to the exec server through 9P. But I have to make absolutely sure that commands can only be sent when coming from certain pages. How can I achieve this ? thx -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 04:34:04PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > > Johannes wrote: > > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > > 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) > > > > > > > > I had some of these segfaults too. > > > > > > > > > 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 > > > [snip] > > > > > 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. > > > > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > > associated with a layout too. > > > > > > It looks like style uses layout to get to platform. I wonder whether > > > it would go against any dw rules to let style have platform. > > > > > > > My problem is that I don't understand why fontsTable and > > colorsTable need to be platform specific in the first place. > > As long as their members match they should be sharable - even > > if they are used for different platforms. > > > > I would just make them static members of Font and Color > > respectively. That way we would no longer need the layout parameter > > in the *::create methods. > > > > What am I missing here? > > I may be wrong here, but I think the idea is that the colors or fonts > in the tables are currently FltkColor/FltkFont, but they could in principle > be mixed together with ones from another toolkit. Yes, I also read the comment in platform.hh about Style Resources. But still, if every implementation of Font or Color would handle its caching on its own with a static hash table, it should still work. If there should be a GtkFont class some day, it would have its own static hash table. I would rather see the need for a Font factory in platform that creates the right sort of Font for that platform. > > Hmm. I wonder whether it would break anything to change > a_UIcmd_browser_window_new() to have a single static FltkPlatform... Yeah, I thought about that too. I think apart from the current delete platform; in the Layout destructor that should work. And we could delete platfrom at the level where it was created. But all the platform stuff is difficult to understand as we currently only have one.

June 7, 2008

recent style/layout segfaults

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > > Johannes wrote: > > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > > 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) > > > > > > I had some of these segfaults too. > > > > > > > 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 > > [snip] > > > > 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. > > > > > > > > > > I will have a look at that. Maybe the StyleTable should be > > > associated with a layout too. > > > > It looks like style uses layout to get to platform. I wonder whether > > it would go against any dw rules to let style have platform. > > > > My problem is that I don't understand why fontsTable and > colorsTable need to be platform specific in the first place. > As long as their members match they should be sharable - even > if they are used for different platforms. > > I would just make them static members of Font and Color > respectively. That way we would no longer need the layout parameter > in the *::create methods. > > What am I missing here? I may be wrong here, but I think the idea is that the colors or fonts in the tables are currently FltkColor/FltkFont, but they could in principle be mixed together with ones from another toolkit. Hmm. I wonder whether it would break anything to change a_UIcmd_browser_window_new() to have a single static FltkPlatform...

June 7, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

On Thu, Jun 05, 2008 at 10:43:36PM +0000, corvid wrote: > Johannes wrote: > > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > > 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) > > > > I had some of these segfaults too. > > > > > 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 > [snip] > > > 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. > > > > > > > I will have a look at that. Maybe the StyleTable should be > > associated with a layout too. > > It looks like style uses layout to get to platform. I wonder whether > it would go against any dw rules to let style have platform. > My problem is that I don't understand why fontsTable and colorsTable need to be platform specific in the first place. As long as their members match they should be sharable - even if they are used for different platforms. I would just make them static members of Font and Color respectively. That way we would no longer need the layout parameter in the *::create methods. What am I missing here? Cheers, Johannes > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

June 7, 2008

another segfault

by Johannes.Hofmann＠gmx.de

On Sat, Jun 07, 2008 at 02:24:09PM +0000, corvid wrote: > Johannes wrote: > > now I've got some more info on that problem. The buffer on which > > Html_write_raw is operating (0x285c8000 in this case) is free'd by > > a_Cache_set_content_type(). I don't understand the details though. > > Do you have an idea? > > Ah! Does this help? > Yes, it does. Excellent! Johannes

June 7, 2008

another segfault

by corvid＠lavabit.com

Johannes wrote: > now I've got some more info on that problem. The buffer on which > Html_write_raw is operating (0x285c8000 in this case) is free'd by > a_Cache_set_content_type(). I don't understand the details though. > Do you have an idea? Ah! Does this help?

June 7, 2008

another segfault

by Johannes.Hofmann＠gmx.de

Hi, now I've got some more info on that problem. The buffer on which Html_write_raw is operating (0x285c8000 in this case) is free'd by a_Cache_set_content_type(). I don't understand the details though. Do you have an idea? (gdb) bt #0 dFree (mem=0x285c8000) at dlib.c:59 #1 0x08071ae7 in dStr_free (ds=0x285c0ed0, all=677150720) at dlib.c:291 #2 0x08058ef1 in a_Cache_set_content_type (url=0x28539500, ctype=0x285d2000 "text/html; charset=us-asci i", force=0 '\0') at cache.c:499 #3 0x08061a82 in Html_tag_open_meta (html=0x28689e00, tag=0x285c80a5 "<META http-equiv=\"Content-Type\" content=\"text/html; charset=us-ascii\">\n </HEAD >\n <BODY BGCOLOR=\"#ffffff\">\n <h1>The Mercurial Archives </h1>\n <p>\n You can get <a h ref=\"http://selenic.com"..., tagsize=70) at html.cc:3995 #4 0x080616c4 in Html_write_raw (html=0x28689e00, buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., bufsize=1119, Eof=0) at html.cc:5653 #5 0x08061af1 in DilloHtml::write (this=0x28689e00, Buf=0x285c8000 "<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 3.2//EN\">\n<HTML>\n <HEAD>\n <title>T he Mercurial Archives</title>\n <META NAME=\"robots\" CONTENT=\"noindex,follow\">\n <META http-e quiv=\"Content-Type\" con"..., BufSize=675443204, Eof=0) at html.cc:967 #6 0x080621ba in Html_callback (Op=0, Client=0x28549bc0) at html.cc:5883 #7 0x08058433 in Cache_process_queue (entry=0x285d4200) at cache.c:1075 #8 0x08058d98 in a_Cache_process_dbuf (Op=0, buf=0x285a1000 "HTTP/1.1 200 OK\r\nDate: Sat, 07 Jun 2008 09:35:46 GMT\r\nServer: Apache/1.3.34 (Deb ian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nLast-Modified: Sat, 07 Jun 2008 08:24:59 GMT\r\n ETag: \"271005-41b5-4"..., buf_size=1440, Url=0x28539800) at cache.c:871 #9 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x285c0340, Data2=0x80eb382) at chain.c:111 #10 0x08074440 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x285490c0, Data1=0x2848d5f0, Data2=0x0) at dpi .c:223 #11 0x0805650c in a_Chain_fcb (Op=675443204, Info=0x0, Data1=0x2848d5f0, Data2=0x0) at chain.c:111 #12 0x08074d61 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x28549ac0, Data1=0x285497c0, Data2=0x0) at IO.c :418 #13 0x08074eee in IO_callback (fd=<value optimized out>, io=0x285497c0) at IO.c:205 #14 0x08074fc7 in IO_fd_read_cb (fd=7, data=0xc) at IO.c:291 #15 0x080c2869 in fltk::wait () #16 0x080c2a19 in fltk::run () #17 0x0804e63d in main (argc=0, argv=0x0) at dillo.cc:125 (gdb) Cheers, Johannes

June 7, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

On Fri, Jun 06, 2008 at 06:53:58PM +0100, Jeremy Henty wrote: > On Fri, Jun 06, 2008 at 04:29:02PM +0000, corvid wrote: > > compiler errors: I think it's that Jeremy is using gcc3 and not > > seeing those errors. > > I'll fix up the other branches and send a mega-patch privately. Done. Thanks to corvid for reminding me that we had seen this before. Are there any gcc flags I could set to stop stuff like this getting through? Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: common functions, part 1

by jcid＠dillo.org

On Fri, Jun 06, 2008 at 04:29:02PM +0000, corvid wrote: > compiler errors: I think it's that Jeremy is using gcc3 and not > seeing those errors. Here I have: gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) -- Cheers Jorge.-

June 6, 2008

Splitting html.cc: common functions, part 1

by onepoint＠starurchin.org

On Fri, Jun 06, 2008 at 04:29:02PM +0000, corvid wrote: > compiler errors: I think it's that Jeremy is using gcc3 and not > seeing those errors. Yes, it looks very much like something we have seen before where gcc4 wants the scope of variables initialised in switch statements to be restricted to one branch of the switch. In reset() that's already been done to the case DILLO_HTML_INPUT_FILE: branch lower down. I'll fix up the other branches and send a mega-patch privately. Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: common functions, part 1

by corvid＠lavabit.com

compiler errors: I think it's that Jeremy is using gcc3 and not seeing those errors.

June 6, 2008

Splitting html.cc: common functions, part 1

by jcid＠dillo.org

Hi Jeremy, On Thu, Jun 05, 2008 at 06:25:33PM +0100, Jeremy Henty wrote: > > 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! With regard to big patches and splitting, please don't burden yourself with splitting. This is just cleanup so please send me one big patch to my email address not dillo-dev. After applying thwe full patchset, I got compiler errors. :( <quote> g++ -DHAVE_CONFIG_H -I. -I.. -DDILLORC_SYS='"/usr/local/etc/dillorc"' -I/usr/local/include -I../../dw-testbed -I/usr/include/libpng12 -I/usr/local/include -I/usr/include/freetype2 -Wno-non-virtual-dtor -g -O2 -Wall -W -Wno-unused-parameter -MT form.o -MD -MP -MF .deps/form.Tpo -c -o form.o form.cc form.cc: In member function 'void DilloHtmlInput::reset()': form.cc:1413: error: jump to case label form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1414: error: jump to case label form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1419: error: jump to case label form.cc:1415: error: crosses initialization of 'dw::core::ui::ToggleButtonResource* tb_r' form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1434: error: jump to case label form.cc:1415: error: crosses initialization of 'dw::core::ui::ToggleButtonResource* tb_r' form.cc:1409: error: crosses initialization of 'dw::core::ui::EntryResource* entryres' form.cc:1449: error: jump to case label [...] </quote> To solve this problem, please send me one big patch with all the changes. I'm not committing anything yet. -- Cheers Jorge.-

June 6, 2008

Splitting html.cc: the rest of the form code

by onepoint＠starurchin.org

This is it!. These three patches complete the migration of all the form code to form.cc . They move respectively the receiver class, the input class and the class declarations (which were temporarily put in form.hh ). Now all the details of form handling are in form.cc and form.hh exports an opaque API to the rest of the Html module. Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: the form class, part II

by onepoint＠starurchin.org

And here we move the rest of the DilloHtmlForm implementation, in two patches. The first patch moves the methods that create data for submitting a form. This is large because it includes a number of static functions that have to be moved together. The second patch moves the last method. Regards, Jeremy Henty

June 6, 2008

Splitting html.cc: the form class, part I

by onepoint＠starurchin.org

The next task is to move the implementation of DilloHtmlForm into form.cc . This is a lot of code, so I'm splitting it into several parts. This part moves the constructor, destructor and most of the methods. Regards, Jeremy Henty

June 6, 2008

recent style/layout segfaults

by corvid＠lavabit.com

Johannes wrote: > On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > > 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) > > I had some of these segfaults too. > > > 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 [snip] > > 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. > > > > I will have a look at that. Maybe the StyleTable should be > associated with a layout too. It looks like style uses layout to get to platform. I wonder whether it would go against any dw rules to let style have platform.

June 6, 2008

another segfault

by Johannes.Hofmann＠gmx.de

Hi, here is another segfault I get consistently when clicking a certain sequence of links. I have no idea about the cause however. Cheers, Johannes Loaded symbols for /usr/libexec/ld-elf.so.2 Core was generated by `dillo-fltk'. Program terminated with signal 11, Segmentation fault. #0 Html_get_attr2 (html=0x28560300, tag=0x284810a5 <Address 0x284810a5 out of bounds>, tagsize=70, attrname=0x80e9e69 "id", tag_parsing_flags=3) at html.cc:5707 5707 if (isspace(tag[i])) (gdb) bt #0 Html_get_attr2 (html=0x28560300, tag=0x284810a5 <Address 0x284810a5 out of bounds>, tagsize=70, attrname=0x80e9e69 "id", tag_parsing_flags=3) at html.cc:5707 #1 0x080617d5 in Html_write_raw (html=0x28560300, buf=0x28481000 <Address 0x28481000 out of bounds>, bufsize=1119, Eof=0) at html.cc:5628 #2 0x08061acd in DilloHtml::write (this=0x28560300, Buf=0x28481000 <Address 0x28481000 out of bounds>, BufSize=0, Eof=0) at html.cc:961 #3 0x08062196 in Html_callback (Op=0, Client=0x284f8fa0) at html.cc:5855 #4 0x08058433 in Cache_process_queue (entry=0x28474d40) at cache.c:1075 #5 0x08058d98 in a_Cache_process_dbuf (Op=0, buf=0x2854a000 "HTTP/1.1 200 OK\r\nDate: Thu, 05 Jun 2008 20:56:16 GMT\r\nServer: Apache/1.3.34 (Debian) PHP/4.4.4-8+etch6 mod_ssl/2.8.25 OpenSSL/0.9.8c\r\nLast-Modified: Thu, 05 Jun 2008 16:16:48 GMT\r\nETag: \"271005-41b5-4"..., buf_size=1440, Url=0x284f9c00) at cache.c:871 #6 0x0805650c in a_Chain_fcb (Op=0, Info=0x2850f340, Data1=0x2850f230, Data2=0x80eb382) at chain.c:111 #7 0x08074444 in a_Dpi_ccc (Op=2, Branch=2, Dir=1, Info=0x284f8f40, Data1=0x284f73c0, Data2=0x0) at dpi.c:223 #8 0x0805650c in a_Chain_fcb (Op=0, Info=0x2850f340, Data1=0x284f73c0, Data2=0x0) at chain.c:111 #9 0x08074d65 in a_IO_ccc (Op=2, Branch=2, Dir=1, Info=0x284f8f60, Data1=0x284f8f80, Data2=0x0) at IO.c:418 #10 0x08074ef2 in IO_callback (fd=<value optimized out>, io=0x284f8f80) at IO.c:205 #11 0x08074fcb in IO_fd_read_cb (fd=6, data=0xc) at IO.c:291 #12 0x080c286d in fltk::wait () #13 0x080c2a1d in fltk::run () #14 0x0804e63d in main (argc=Cannot access memory at address 0x0

June 5, 2008

recent style/layout segfaults

by Johannes.Hofmann＠gmx.de

Hi, On Thu, Jun 05, 2008 at 06:05:39PM +0000, corvid wrote: > 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) I had some of these segfaults too. > > 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. > I will have a look at that. Maybe the StyleTable should be associated with a layout too. Cheers, Johannes

June 5, 2008

Splitting html.cc: form parsing *II*

by onepoint＠starurchin.org

These patches move the rest of the form parsing code into form.cc . Regards, Jeremy Henty

June 5, 2008

Splitting html.cc: form parsing I

by onepoint＠starurchin.org

Now we move the form parsing code into form.cc . The 40K posting limit forces me send the patches in two batches. Here's the first lot. Jeremy Henty

June 5, 2008

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