Re: [TCLCORE] TIPs looking for implementations

[Donal K. F. <don...@ma...>]

Michael Kirkham wrote:
> I've started stubbing out TkPNG to work with-or-without the API specified 
> by TIP#234, though I can't guarantee to get that done by Dec 19 
> (especially with Pascal's site still down so I don't have 234's sample 
> implementation to work with or reference).

I had a lot of trouble with Pascal's site too. Luckily, I discovered
that Google Code Search had a cached copy. :-) I've greatly cleaned up
the code and included it in the HEAD of Tcl.

> Mainly this involves changing the ckalloc'ed buffers to byte array 
> Tcl_Objs and implementing versions of some of the 234 APIs within 244, but 
> wrapped in #ifdefs so that TkPNG can be built standalone or against zlib 
> in the core.  It may then need minor changes depending on how 234 actually 
> gets implemented to deal with partial reads/writes (e.g. whether it keeps 
> a copy of leftover data for the next call or holds a reference to the 
> input data Tcl_Obj may affect where I can store the next chunk of data to 
> feed to StreamPut).

It retains references to Tcl_Objs according to the "Hairy Monster"
style, so you'll need to both a) avoid passing refcount 0 objects in,
possibly by wrapping and Incr/Decr pair around the StreamPut, and b) not
reuse objects that you pass in. Don't be afraid to use new objects
though; their allocation path is reasonably optimized...

(No, I don't think I can change how it does reference management. It's
moderately tricky. Do badger me to put some notes on this in the C-level
documentation...)

> TIP#244 shouldn't require changes in Tcl to handle the building that I can 
> think of--that's all on the #234 (zlib) side, unless zlib being optional 
> at build time was still on the table (I though it wasn't) and you for some 
> reason still want to build #244 into Tk with #234 disabled in Tcl.  That 
> wouldn't be my recommendation. :P
> 
> ...or, maybe you meant #234 rather than #244 in your statement.

Right now, the #234 implementation isn't yet done to the degree to which
it should be. In particular, there's a need for more autogoo and a
compatibility inclusion of the zlib sources from a known good version.
(I've done enough that it can detect whether what is available on the
system is sufficient to support #234's features, but not actually the
replacement stuff yet: I'm not on a platform where I need to do that...)
Oh, and there's one feature not yet done.

But from your comments I think you're able to get on and use the APIs
that are there and working already. Well, so long as you are on a
platform with a good enough system zlib. :-)

Donal.