- Dillo-dev - lists.mailman3.com

form.cc: private form methods

by jcid＠dillo.org

On Mon, Jun 09, 2008 at 04:14:21PM +0100, Jeremy Henty wrote: > > More C++-ification of form.cc . Most of the static functions > implement the internals of DilloHtmlForm::buildQueryUrl() , so let's > turn them into private DilloHtmlForm methods since nothing else calls > them. > > The first patch makes the changes, the second moves the definitions > around (the diff is a little mangled for some reason but it really > does nothing except move things). Committed. -- Cheers Jorge.-

June 9, 2008

form.cc: private form methods

by onepoint＠starurchin.org

More C++-ification of form.cc . Most of the static functions implement the internals of DilloHtmlForm::buildQueryUrl() , so let's turn them into private DilloHtmlForm methods since nothing else calls them. The first patch makes the changes, the second moves the definitions around (the diff is a little mangled for some reason but it really does nothing except move things). Regards, Jeremy Henty

June 9, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

On Sun, Jun 08, 2008 at 08:26:37PM +0000, corvid wrote: > Sebastian was once thinking of splitting "general parsing and > tokenizing" from "handling HTML specific stuff" in html.c I see splitting out form.cc , table.cc etc. as a step-by-step way of achieving that. The general parsing and tokenizing code would stay in html.cc , and html_common.h would become the generic parser interface. > Are you planning to do more with form.cc, or are you done with it > for now? There's quite a lot of cleaning up and refactoring of to form.cc still to do. I put it on hold and began splitting html.cc because I was getting bored and felt like a change. None of the form.cc work is urgent so I'd be happy to keep it on hold if others want to work on it without being disrupted. There's plenty other things to work on. Regards, Jeremy Henty

June 8, 2008

Splitting html.cc: what next?

by corvid＠lavabit.com

Sebastian was once thinking of splitting "general parsing and tokenizing" from "handling HTML specific stuff" in html.c (http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-June/000758.html) Whether that didn't turn out well or he got distracted by other things, I don't know... Are you planning to do more with form.cc, or are you done with it for now?

June 8, 2008

Splitting html.cc: what next?

by onepoint＠starurchin.org

Off the top of my head, some suggestions for more files that could usefully be split out from html.cc: - table.cc , handles <table> , <tr> , <td> , <th> - list.cc , handles <ul> , <ol> , <li> , <dl> , <dt> , <dd> - text.cc , handles , , , , <strike> - paragraph.cc , handles , <blockquote> , <center> , <address> - page.cc , handles <html> , <head> , <title> , <meta> , <body> Thoughts? Regards, Jeremy Henty

June 8, 2008

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