From: Michael K. <mi...@mu...> - 2008-12-17 01:28:25
|
On Tue, 16 Dec 2008, Donal K. Fellows wrote: > * TIP#244 requires a chunk of effort to get done, especially as it > might result in changes in Tcl too to handle the building. This is > probably the biggest single concern right now. 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). 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). 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. -- Michael Kirkham President & CEO Muonics, Inc. http://www.muonics.com/ |