May 2008 - Dillo-dev - lists.mailman3.com

Hooked a decoder for text/plain with charset.

by jcid＠dillo.org

On Thu, May 29, 2008 at 09:15:24PM +0000, corvid wrote: > Jorge wrote: > > On Thu, May 29, 2008 at 08:49:22PM +0000, corvid wrote: > > > Jorge wrote: > > > > Just committed this patch. It makes things like: > > > > > > > > http://separat-lib.narod.ru/master.txt > > > > > > > > work. > > > > > > Why now? I don't understand the motivation for this. > > > > > > My next patch is just going to rip it out again because it > > > will become unnecessary. > > > > Yeah, I noticed it could happen after making the patch, > > but a segfault on that page made me fix and commit it. > > Why did it make plain segfault? The patch is attached for you to review in detail. The relevant part is an: Start_Ofs += i - len; substituted by a: Buf_Consumed = BufSize - len; (if the length of a long line got bigger than 'i', 'i - len' was negative. A strange case triggered by that page, that has really long lines). -- Cheers Jorge.-

May 30, 2008

[patch]: html.cc: remove MSG_HTML and rename Html_msg() to DilloHtml::message()

by onepoint＠starurchin.org

Self-explanatory, I hope. This is a useful bit of yak-shaving to prepare for more refactoring of form handling code. The reasons for removing MSG_HTML are: * It doesn't belong in msg.h since it can only work when used in http.cc . * It's a UI function not a debugging function like the other MSG_* so it's misleading for it to look similar to the MSG_* macros. * Using it has no advantage over simply calling the function that it wraps. * It's fragile because it requires html to be in scope and have the right value. Regards, Jeremy Henty

May 30, 2008

[patch]: html.cc: DilloHtmlInput::connectTo()

by onepoint＠starurchin.org

Oops, here's the patch. (I need a rest!) Jeremy Henty

May 30, 2008

[patch]: html.cc: DilloHtmlInput::connectTo()

by onepoint＠starurchin.org

This implements DilloHtmlInput::connectTo() which is called by DilloHtmlForm::addInput and connects the input to the form. This is another API milestone: now only DilloHtmlForm methods access DilloHtmlForm::form_receiver . We are nearly done with the DilloHtmlForm API, there only a few locations left that directly access DilloHtmlForm data members. Regards,

May 30, 2008

[patch]: html.cc: remove DilloHtmlInput::widget

by onepoint＠starurchin.org

It turns out that the embed and widget members of the DilloHtmlInput class are always the same, so we can remove widget. Patch attached. Regards, Jeremy Henty

May 30, 2008

[patch]: html.cc: DilloHtmlForm::getRadioInput()

by onepoint＠starurchin.org

This refactors code that looks for a radio input with a given name into a new method DilloHtmlForm::getRadioInput() . This marks a DilloHtmlForm API milestone: now only DilloHtmlForm member functions access the inputs data member. Everything else that needs to get an input from a form goes through the API. Regards, Jeremy Henty

May 30, 2008

Re: patch: cache Data allocation

by corvid＠lavabit.com

Jorge wrote: > On Thu, May 29, 2008 at 05:51:02PM +0000, corvid wrote: > > This is to make my unref()s cleaner. > > As it was in the prototype code, I would always unref at IOClose time. > > This made the reference count negative for file not found, which I didn't > > like. I could've tested for GotHeader, but it seemed more natural to > > test for data before unref()ing data. > > I'd prefer GotHeader because that's what Cache_process_queue() > tests for, and thus Data doesn't become an implicit flag. All right. > > I think it's all right for me to put that Cache_process_queue(entry) inside > > an entry->Data test -- at least I couldn't find anything bad happening. > > BTW, funny as it may seem, I don't yet know what data unref > you're talking about! :-) The reference counting in my charset-translating-in-cache code. (For any others in the audience: I keep track of how many things are reading the UTF8-ized version of the cache entry data.)

May 29, 2008

Hooked a decoder for text/plain with charset.

by corvid＠lavabit.com

Jorge wrote: > On Thu, May 29, 2008 at 08:49:22PM +0000, corvid wrote: > > Jorge wrote: > > > Just committed this patch. It makes things like: > > > > > > http://separat-lib.narod.ru/master.txt > > > > > > work. > > > > Why now? I don't understand the motivation for this. > > > > My next patch is just going to rip it out again because it > > will become unnecessary. > > Yeah, I noticed it could happen after making the patch, > but a segfault on that page made me fix and commit it. Why did it make plain segfault?

May 29, 2008

Re: patch: cache Data allocation

by jcid＠dillo.org

On Thu, May 29, 2008 at 05:51:02PM +0000, corvid wrote: > This is to make my unref()s cleaner. > As it was in the prototype code, I would always unref at IOClose time. > This made the reference count negative for file not found, which I didn't > like. I could've tested for GotHeader, but it seemed more natural to > test for data before unref()ing data. I'd prefer GotHeader because that's what Cache_process_queue() tests for, and thus Data doesn't become an implicit flag. > I think it's all right for me to put that Cache_process_queue(entry) inside > an entry->Data test -- at least I couldn't find anything bad happening. BTW, funny as it may seem, I don't yet know what data unref you're talking about! :-) -- Cheers Jorge.-

May 29, 2008

Hooked a decoder for text/plain with charset.

by jcid＠dillo.org

On Thu, May 29, 2008 at 08:49:22PM +0000, corvid wrote: > Jorge wrote: > > Just committed this patch. It makes things like: > > > > http://separat-lib.narod.ru/master.txt > > > > work. > > Why now? I don't understand the motivation for this. > > My next patch is just going to rip it out again because it > will become unnecessary. Yeah, I noticed it could happen after making the patch, but a segfault on that page made me fix and commit it. -- Cheers Jorge.-

May 29, 2008