- Dillo-dev - lists.mailman3.com

--xid option

by corvid＠lavabit.com

Johannes wrote: > On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > > AFAIS the current repo is almost dillo-2.1. I'd freeze here > > and only accept bug fixes and polish from now. Opinions? > > Ok for me. A release sounds good. Of course naturally I think, "I hope my MSG macros count as polishing... I hope my UTF-8 file.c code counts as polishing..." The auth crash that Tim reported is the one thing clearly in the way. Bits of polish that I see in skimming through my mail is the matter of the sysconf dir, and of the keybindings changing and the mystery of KEYS_HIDE_PANELS. And putting together sample style.css and keysrc.

May 28, 2009

x offset > 64k

by corvid＠lavabit.com

Johannes wrote: > On Thu, May 28, 2009 at 03:55:57AM +0000, corvid wrote: > > I tried looking at a stylesheet, but nothing displayed. > > It was a one-line document about 7k chars long. > > > > It turned out that fltk::getwidth() calls XftTextExtents32() > > and the width comes back in a short, so it wrapped at 32k. > > > > I chopped the line into 1k-long "words", and now I saw > > text, but once I made a line somewhere over 8k chars long, drawing > > would wrap and start at the beginning again. Everything looked > > all right in fltk::drawtext_transformed() as it called > > XftDrawString32()... > > > > I have no idea whether this is something easy to deal with > > in some way, or a limitation in X... > > > > Oh. This is extremely nasty. Yes, it is a limitation of X. And > someone (fltk or dillo) needs to workaround it. Fltk2 has 32bit > coordinate space, but single drawing operations seem still to be > limited in size, as they are directly mapped to their X > counterparts. The individual drawing requests weren't too big after splitting them up, so far as I could tell. I was trying data = a_Misc_expand_tabs(Start + i - len, len); while (data->len > 1000) { char *s = dStrndup(data->str, 1000); DW2TB(dw)->addText(s, widgetStyle); dStr_erase(data, 0, 1000); dFree(s); } DW2TB(dw)->addText(data->str, widgetStyle); where data had become a Dstr*.

May 28, 2009

x offset > 64k

by Johannes.Hofmann＠gmx.de

On Thu, May 28, 2009 at 03:55:57AM +0000, corvid wrote: > I tried looking at a stylesheet, but nothing displayed. > It was a one-line document about 7k chars long. > > It turned out that fltk::getwidth() calls XftTextExtents32() > and the width comes back in a short, so it wrapped at 32k. > > I chopped the line into 1k-long "words", and now I saw > text, but once I made a line somewhere over 8k chars long, drawing > would wrap and start at the beginning again. Everything looked > all right in fltk::drawtext_transformed() as it called > XftDrawString32()... > > I have no idea whether this is something easy to deal with > in some way, or a limitation in X... > Oh. This is extremely nasty. Yes, it is a limitation of X. And someone (fltk or dillo) needs to workaround it. Fltk2 has 32bit coordinate space, but single drawing operations seem still to be limited in size, as they are directly mapped to their X counterparts. It not only affects text btw: <html> <body> <img src="foo" width="8000" height="20" style="border: 1px solid black" /> </body> </html> Maybe we need to add code to all the drawing operations in dw/fltkviewbase.cc to break up large drawing requests somehow? Cheers, Johannes

May 28, 2009

--xid option

by Johannes.Hofmann＠gmx.de

On Wed, May 27, 2009 at 05:25:15PM -0400, Jorge Arellano Cid wrote: > On Tue, May 26, 2009 at 08:17:53PM +0200, Johannes Hofmann wrote: > > On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote: > > > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > > > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > > > > Hi, > > > > > > > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > > > > used to embed dillo into the claws mailer. > > > > > > > The right way to do this would probabely be to implement the > > > > > > > complete XEMBED protocol which is also mentioned in > > > > > > > doc/fltk-problems.doc. > > > > > > > However a simple XReparentWindow() seems to work more or less here. > > > > > > > Please test. > > > > > > > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > > > > e.g. hg add xembed.hh xembed.cc > > > > > > > > > > Oh yes. Should be fixed now. > > > > > Btw. I managed to install the claws mail client including the dillo > > > > > plugin and it seems to work fine now with dillo2. That's why I just > > > > > committed the xembed stuff. > > > > > > > > This is very good. > > > > > > > > I'll have to dig for the sylpheed contact to let them know. > > > > Does anybody here know the email? > > > > > > I already contacted them on irc (#claws on freenode). > > > It would be good if this get's some testing as there seems to be > > > some interaction with the WM in use. I now tested it successful > > > on dwm, twm, and fvwm. > > > Also there are probabely more elegant ways to do it, but > > > for now I think it's better than nothing. > > > > More testing showed that the current implementation has severe > > problems. > > The thing is that the window manager that I use (dwm) is one of the > > few non-reparenting WMs. Most others reparent new windows and that > > can create races with the reparentin we do. > > There also seems to be a problem with keyboard events in that case. > > Is there anyone on the list with in-depth X11 knowledge who could > > help with the xembed stuff? > > Not me. > > I've seen new patches in the repo so I assume this is more > or less being improved. Please let me know how it goes. I figured out some more how this is supposed to work with xtrace and the testsocket example from gtk2. For me it now works reliably with claws under kde3. An open issue is that claws eats up all key presses it has defined as hotkeys (including 'p' and 'u'), but the same thing happens when I embed the example plugin from gtk instead of dillo. > > AFAIS the current repo is almost dillo-2.1. I'd freeze here > and only accept bug fixes and polish from now. Opinions? Ok for me. Cheers, Johannes

May 28, 2009

x offset > 64k

by corvid＠lavabit.com

I tried looking at a stylesheet, but nothing displayed. It was a one-line document about 7k chars long. It turned out that fltk::getwidth() calls XftTextExtents32() and the width comes back in a short, so it wrapped at 32k. I chopped the line into 1k-long "words", and now I saw text, but once I made a line somewhere over 8k chars long, drawing would wrap and start at the beginning again. Everything looked all right in fltk::drawtext_transformed() as it called XftDrawString32()... I have no idea whether this is something easy to deal with in some way, or a limitation in X...

May 28, 2009

--xid option

by jcid＠dillo.org

On Tue, May 26, 2009 at 08:17:53PM +0200, Johannes Hofmann wrote: > On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote: > > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > > > Hi, > > > > > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > > > used to embed dillo into the claws mailer. > > > > > > The right way to do this would probabely be to implement the > > > > > > complete XEMBED protocol which is also mentioned in > > > > > > doc/fltk-problems.doc. > > > > > > However a simple XReparentWindow() seems to work more or less here. > > > > > > Please test. > > > > > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > > > e.g. hg add xembed.hh xembed.cc > > > > > > > > Oh yes. Should be fixed now. > > > > Btw. I managed to install the claws mail client including the dillo > > > > plugin and it seems to work fine now with dillo2. That's why I just > > > > committed the xembed stuff. > > > > > > This is very good. > > > > > > I'll have to dig for the sylpheed contact to let them know. > > > Does anybody here know the email? > > > > I already contacted them on irc (#claws on freenode). > > It would be good if this get's some testing as there seems to be > > some interaction with the WM in use. I now tested it successful > > on dwm, twm, and fvwm. > > Also there are probabely more elegant ways to do it, but > > for now I think it's better than nothing. > > More testing showed that the current implementation has severe > problems. > The thing is that the window manager that I use (dwm) is one of the > few non-reparenting WMs. Most others reparent new windows and that > can create races with the reparentin we do. > There also seems to be a problem with keyboard events in that case. > Is there anyone on the list with in-depth X11 knowledge who could > help with the xembed stuff? Not me. I've seen new patches in the repo so I assume this is more or less being improved. Please let me know how it goes. AFAIS the current repo is almost dillo-2.1. I'd freeze here and only accept bug fixes and polish from now. Opinions? -- Cheers Jorge.-

May 27, 2009

(no subject)

by bogus＠does.not.exist.com

From: Jorge Arellano Cid <jcid(a)dillo.org> To: Dillo mailing list <dillo-dev(a)dillo.org> Cc: Bcc: Subject: Re: [Dillo-dev] patch: a binding for stop Reply-To: In-Reply-To: <20090527142256.GH6001(a)local.gobigwest.com> On Wed, May 27, 2009 at 02:22:57PM +0000, corvid wrote: > > Wondering whether we can come to a decision on this one.. I don't like much Esc for stop, but if that's FFs default, it may be better than another (as the Ctrl-x clash you spot). Afterall this is what configurable keybindings is suppossed to solve so Esc is OK for me as default. > > Jeremy wrote: > > On Wed, May 06, 2009 at 11:32:31AM -0400, Jorge Arellano Cid wrote: > > > > > > The other one I can think of as mnemonic is <ctrl>x. What do > > > people think? > > > > That clashes with "Cut". Select some text in the URL window and > > <ctrl>+x will delete it. I think it's not a good idea to grab > > something that (a) already has a conventional action, and (b) already > > performs that conventional action in the GUI. > > > > And while we're talking about conventional use: Dillo is highly > > unconventional when it uses <ctrl>+q to close a tab. Everyone else[1] > > uses <ctrl>+w to close a tab (<ctrl>+<shift>+q to close a window) and > > <ctrl>+q to quit. Which can be annoying when switching between the > > two. > > > > Firefox uses Escape to stop, and arora[2] uses <ctrl>+. . > > > > Regards, > > > > Jeremy Henty > > > > [1] ie. Firefox :-) > > [2] http://code.google.com/p/arora/ - WebKit+Qt-based browser. It > > looks very nice and may supplant Firefox as "the browser to fall back > > to when Dillo can't handle the page". > > -- Cheers Jorge.-

May 27, 2009

include guard naming

by jcid＠dillo.org

On Wed, May 27, 2009 at 12:59:09AM +0000, corvid wrote: > Jorge wrote: > > On Sun, May 24, 2009 at 03:09:53PM -0400, corvid(a)lavabit.com wrote: > > > I was just going through and changing the include guards > > > that don't follow the dillo convention, and then > > > I glanced at http://en.wikipedia.org/wiki/Include_guard > > > and it reminds me that the C++ standard prohibits '_'s > > > at the beginning. > > > > > > Does anyone care enough to have an opinion? > > > If we want to rm the leading or surrounding underscores, > > > I might as well do that too before committing. > > > > A "D_" prefix looks OK to me. > > > > e.g. > > > > #ifndef D_BINARYCONST_H > > #define D_BINARYCONST_H > > > > ... > > > > #endif /* D_BINARYCONST_H */ > > Is that D_IO_, D_DLIB_, etc., on the dillo side > and LOUT_, DW_, etc., on the dw side? > (not sure whether dw is still supposed to maintain an > independence of sorts...) Good question... I'd say in that case an all around "G_" or "IG_" prefix (INCLUDE GUARD) may fit better. -- Cheers Jorge.-

May 27, 2009

[patch]: [doc]: escape some hash in the text

by corvid＠lavabit.com

Jeremy wrote: > When you're sick of bugs, clean up the docs! This escapes some '#' > characters so that "#define" and "#include" appear properly in the > text. It also silences some Doxygen warnings (it was trying to > interpret those words as links). Committed.

May 27, 2009

include guard naming

by corvid＠lavabit.com

Jorge wrote: > On Sun, May 24, 2009 at 03:09:53PM -0400, corvid(a)lavabit.com wrote: > > I was just going through and changing the include guards > > that don't follow the dillo convention, and then > > I glanced at http://en.wikipedia.org/wiki/Include_guard > > and it reminds me that the C++ standard prohibits '_'s > > at the beginning. > > > > Does anyone care enough to have an opinion? > > If we want to rm the leading or surrounding underscores, > > I might as well do that too before committing. > > A "D_" prefix looks OK to me. > > e.g. > > #ifndef D_BINARYCONST_H > #define D_BINARYCONST_H > > ... > > #endif /* D_BINARYCONST_H */ Is that D_IO_, D_DLIB_, etc., on the dillo side and LOUT_, DW_, etc., on the dw side? (not sure whether dw is still supposed to maintain an independence of sorts...)

May 27, 2009

include guard naming

by jcid＠dillo.org

On Sun, May 24, 2009 at 03:09:53PM -0400, corvid(a)lavabit.com wrote: > I was just going through and changing the include guards > that don't follow the dillo convention, and then > I glanced at http://en.wikipedia.org/wiki/Include_guard > and it reminds me that the C++ standard prohibits '_'s > at the beginning. > > Does anyone care enough to have an opinion? > If we want to rm the leading or surrounding underscores, > I might as well do that too before committing. A "D_" prefix looks OK to me. e.g. #ifndef D_BINARYCONST_H #define D_BINARYCONST_H ... #endif /* D_BINARYCONST_H */ -- Cheers Jorge.-

May 27, 2009

patch: Re: [Dillo-dev] https through a proxy

by corvid＠lavabit.com

Here you go. As I said, I have not had the opportunity to test this under a wide range of conditions.

May 27, 2009

--xid option

by Johannes.Hofmann＠gmx.de

On Tue, May 19, 2009 at 08:24:14PM +0200, Johannes Hofmann wrote: > On Tue, May 19, 2009 at 01:34:56PM -0400, Jorge Arellano Cid wrote: > > On Mon, May 18, 2009 at 11:14:14PM +0200, Johannes Hofmann wrote: > > > On Mon, May 18, 2009 at 01:48:43PM -0400, Jorge Arellano Cid wrote: > > > > On Mon, May 18, 2009 at 01:18:11AM +0200, Johannes Hofmann wrote: > > > > > Hi, > > > > > > > > > > attached patch tries to implement the missing --xid option that is > > > > > used to embed dillo into the claws mailer. > > > > > The right way to do this would probabely be to implement the > > > > > complete XEMBED protocol which is also mentioned in > > > > > doc/fltk-problems.doc. > > > > > However a simple XReparentWindow() seems to work more or less here. > > > > > Please test. > > > > > > > > It seems like you forgot to commit xembed.{hh,cc} to the repo. > > > > e.g. hg add xembed.hh xembed.cc > > > > > > Oh yes. Should be fixed now. > > > Btw. I managed to install the claws mail client including the dillo > > > plugin and it seems to work fine now with dillo2. That's why I just > > > committed the xembed stuff. > > > > This is very good. > > > > I'll have to dig for the sylpheed contact to let them know. > > Does anybody here know the email? > > I already contacted them on irc (#claws on freenode). > It would be good if this get's some testing as there seems to be > some interaction with the WM in use. I now tested it successful > on dwm, twm, and fvwm. > Also there are probabely more elegant ways to do it, but > for now I think it's better than nothing. More testing showed that the current implementation has severe problems. The thing is that the window manager that I use (dwm) is one of the few non-reparenting WMs. Most others reparent new windows and that can create races with the reparentin we do. There also seems to be a problem with keyboard events in that case. Is there anyone on the list with in-depth X11 knowledge who could help with the xembed stuff? Cheers, Johannes > > Cheers, > Johannes

May 26, 2009

https through a proxy

by corvid＠lavabit.com

I wrote: > Yesterday I hacked up (it's still very hacky right now) > some code that is intended to make https work through > a proxy, but I haven't tested it on an actual proxy yet. > > Do you have any suggestions on what would be > the most convenient way to go about this? > (It'd be nicer just to test with something > that's running out there than to do a bunch > of building and configuring for something I'll > just rm again afterward.) I built privoxy, which went smoothly, and found that my code is working.

May 26, 2009

https through a proxy

by corvid＠lavabit.com

Yesterday I hacked up (it's still very hacky right now) some code that is intended to make https work through a proxy, but I haven't tested it on an actual proxy yet. Do you have any suggestions on what would be the most convenient way to go about this? (It'd be nicer just to test with something that's running out there than to do a bunch of building and configuring for something I'll just rm again afterward.)

May 25, 2009

include guard naming

by Johannes.Hofmann＠gmx.de

On Sun, May 24, 2009 at 03:09:53PM -0400, corvid(a)lavabit.com wrote: > I was just going through and changing the include guards > that don't follow the dillo convention, and then > I glanced at http://en.wikipedia.org/wiki/Include_guard > and it reminds me that the C++ standard prohibits '_'s > at the beginning. > > Does anyone care enough to have an opinion? > If we want to rm the leading or surrounding underscores, > I might as well do that too before committing. +1 for removing the undescores

May 24, 2009

Spotted a tiny dillo bug with tabs

by Johannes.Hofmann＠gmx.de

On Sun, May 24, 2009 at 12:16:11PM -0700, Freya wrote: > > > Tiny bug: When dillo changes tabs it doesn't update the main window header thing. Also the same if you close a tab. This can lead to weird effects such as the top header thing having info about a webpage that you don't have open at all. That was fixed recently by Jorge. At least here it works fine now. Please make sure you are running the latest version from: http://hg.dillo.org/dillo Please report back if you are still seeing issues with that version. Cheers, Johannes

May 24, 2009

Spotted a tiny dillo bug with tabs

by freya128＠yahoo.com

Tiny bug: When dillo changes tabs it doesn't update the main window header thing. Also the same if you close a tab. This can lead to weird effects such as the top header thing having info about a webpage that you don't have open at all. Hope that helps! :) love Freya

May 24, 2009

include guard naming

by corvid＠lavabit.com

I was just going through and changing the include guards that don't follow the dillo convention, and then I glanced at http://en.wikipedia.org/wiki/Include_guard and it reminds me that the C++ standard prohibits '_'s at the beginning. Does anyone care enough to have an opinion? If we want to rm the leading or surrounding underscores, I might as well do that too before committing. [pop/smtp isn't working at the moment, so I'm sending this through webmail. Let's hope they doesn't mangle line wrapping or anything.]

May 24, 2009

[bug]: uint32_t not declared

by onepoint＠starurchin.org

On Sun, May 24, 2009 at 02:06:07PM +0000, corvid wrote: > Does tip work for you now? Yes. Thanks! Jeremy Henty

May 24, 2009

[bug]: uint32_t not declared

by corvid＠lavabit.com

Joerg wrote: > On Sun, May 24, 2009 at 02:06:57PM +0100, Jeremy Henty wrote: > > It's stdint.h , which is on my system and correctly found by autoconf. > > You should conditionally include both stdint.h and inttypes.h, some > system miss one or both of them. > > > Patch attached. But what happens if HAVE_STDINT_H is undefined? > > You can also use AC_TYPE_UINT32_T and friends, it will define uint32_t > if necessary. It looks like they were introduced in 2006 in autoconf 2.60. That's the version I happen to have, but...

May 24, 2009

[bug]: uint32_t not declared

by joerg.sonnenberger＠web.de

On Sun, May 24, 2009 at 02:06:57PM +0100, Jeremy Henty wrote: > It's stdint.h , which is on my system and correctly found by autoconf. You should conditionally include both stdint.h and inttypes.h, some system miss one or both of them. > Patch attached. But what happens if HAVE_STDINT_H is undefined? You can also use AC_TYPE_UINT32_T and friends, it will define uint32_t if necessary. Joerg

May 24, 2009

[bug]: uint32_t not declared

by corvid＠lavabit.com

Jeremy wrote: > The latest tip fails to build for me. I don't have uint32_t. Which > header should include it? I'm using gcc 4.1.2. Does tip work for you now?

May 24, 2009

[bug]: uint32_t not declared

by onepoint＠starurchin.org

Answering myself: On Sun, May 24, 2009 at 01:47:20PM +0100, Jeremy Henty wrote: > > I don't have uint32_t. Which header should include it? It's stdint.h , which is on my system and correctly found by autoconf. /* Define to 1 if you have the <stdint.h> header file. */ #define HAVE_STDINT_H 1 Patch attached. But what happens if HAVE_STDINT_H is undefined? Regards, Jeremy Henty

May 24, 2009

[bug]: uint32_t not declared

by onepoint＠starurchin.org

The latest tip fails to build for me. I don't have uint32_t. Which header should include it? I'm using gcc 4.1.2. Regards, Jeremy Henty

May 24, 2009

[patch]: [doc]: escape some hash in the text

by onepoint＠starurchin.org

When you're sick of bugs, clean up the docs! This escapes some '#' characters so that "#define" and "#include" appear properly in the text. It also silences some Doxygen warnings (it was trying to interpret those words as links). Regards, Jeremy Henty

May 23, 2009

Latest on invalid image callback references

by onepoint＠starurchin.org

On Fri, May 22, 2009 at 02:31:58PM -0400, Jorge Arellano Cid wrote: > On Tue, May 19, 2009 at 07:34:30AM +0100, Jeremy Henty wrote: > > > I have just applied a patch I was considering earlier that makes > > a_Cache_stop_client() close the client. And now I have just unapplied it because it crashed Dillo all the time. <sigh> If this patch isn't wrong, then something else is. > A huge step forward would be to find a way to repoduce the bug. Believe me, I know. Unfortunately my current patches do little more than confirm at the end of the session that sometime previously, something, somewhere went wrong. Which is great for confirming the existence of the bug, but for fixing it, not so much. What's really needed is complete logging of the CCC, the cache and the dicache. Back to the drawing board... > My guess is that this semantic is still fuzzy ... It's nice to know that it isn't just me who doesn't understand the code! :-) Just what is a repush anyway? (BTW, I'm not complaining, just pining for the good old days when Dillo was so buggy that it was easy for me to find something I could actually fix. :-) :-) ) Regards, Jeremy Henty PS. I agree that this should not block Dillo-2.1 . Just think of it as the Moby Dick to my Captain Ahab. From Hell's heart I stab at thee, freed struct DilloImage! Dillo-2.1 *will* rock, whether or not this is fixed.

May 23, 2009

[rutkowski.adrian1@gmail.com: Re: [Dillo-dev] Dillo failed to compile with GCC 4.4.0]

by jcid＠dillo.org

On Fri, May 22, 2009 at 06:51:16PM +0000, corvid wrote: > No need. Adrian went through a few rounds of sending me the error > msgs, I committed some consts, and then he reported: > > > Success! :) > > Now it compiles and runs whitout glitches. Excellent! -- Cheers Jorge.-

May 23, 2009

Latest on invalid image callback references

by jcid＠dillo.org

On Tue, May 19, 2009 at 07:34:30AM +0100, Jeremy Henty wrote: > > The valgrind logs are still showing invalid memory accesses that > happen when image callbacks refer to DilloImages that have been freed > by a_Web_free(). This is after the imgref patch was applied, since > when I've been running an essentially unpatched Dillo. My image > tracing still shows that the image pipeline sometimes continues to run > after a_Web_free() frees the image it is attached to. As far as I can > tell there has been no recent change in the behaviour of this problem. I see. > I have just applied a patch I was considering earlier that makes > a_Cache_stop_client() close the client. I've attached it for > comments, but I won't suggest applying it until we can see whether > it's made any difference. That will take a few days, as I still > haven't found a reliable way to reproduce the bug so I will just have > to wait a few days and see if it stops appearing in the logs. Please > comment on whether this patch is the right way to fix this. A long time ago when coding the bindings for the new imgbuf, I seem to remember seeing a corner case that would leak. Back then the priority was to get the port into a working state so it was left for future fixing (as many other things). Since then, the image code has undergone major changes and cleanups and it may take some effort to get to this bug. One chance I checked yesterday was a mismatched image type (e.g. PNG served as GIF) but it wasn't the cause. As we're almost done with rc1 for the dillo-2.1 release. I'd prefer to work on it after the release, or to dedicate more time to it only if there's a suitable window in the release process. A huge step forward would be to find a way to repoduce the bug. WRT the patch, it may be the fix, but there's a need to check for the current semantic of stop_clients in all cases. This function may only remove the client but not shut the decoding process (think of a repush for instance), and BTW some parts of the code use a flag (as "force"). My guess is that this semantic is still fuzzy so it may be necessary to study the whole, define an accurate behaviour, code accordingly, check the corner cases and to test in the "wild". -- Cheers Jorge.-

May 22, 2009