From: Andreas K. <and...@ac...> - 2007-02-13 19:24:00
|
> On 12 Feb 2007, at 19:07, Andreas Kupries wrote: > > http://wiki.tcl.tk/17686 > > > > Good enough for adding them to tcllib ? > > (Under struct, I would say, should our answer be 'yes') > > I'm certainly happy to see them added to tcllib. A test-suite is > needed, of course. If it goes in to tcllib alongside struct::list, > then it might be worth examining the API. For instance, struct::list > equal assumes that its elements are either strings or sub-lists, > whereas dictutils equal requires an explicit equality predicate for > the elements. You could probably add a predicate to list equality, as > an optional first argument, and let it default to the current > behaviour. Huh. Didn't notice that. One thing I am doing slowly at the side is working a bit on Critcl implementations for the struct::list ops. List equality I found to be one of the harder ones. Because it is looking for sublists, and checking for the difference between a plain string and a list is awkward at the C level. I haven't completed that one yet. Of course, the LCS and various db-related joins ops will be hard as well, however there the problem is more the size of the algorithm, and not the conceptual underpinnings. > Problem is the format -- should it be a simple [eq? $a $b] > or include the index too [eq? $i $a $b]? The first is simpler (and > allows using things like {string equal}), whereas the latter is > perhaps more flexible (e.g., if a list is being used like a tuple). Hm. My gut feeling just after reading the above is have it with index, with the antagonistic part of me asking for a concrete example where it would truly be useful. Which I don't have, causing me overall to sit on the fence here. I wonder how much of a problem having the index would be, given that 8.5 also has apply and thus the ability to write anon wrapper commands to get something like 'string equal' to work. > I've some other bits of code that could be contributed to tcl/tklib > at some point: > > * A higher level channel API (http://wiki.tcl.tk/17012) -- I have a > bunch of updates/changes to this that I want to finish up, then I > think it might be worth adding. Hm. Interesting. Note that I recently added some higher-level channel stuff as well, see the 'transfer' packages (transfer::connect , transfer::copy , transfer::data::destination , transfer::data::source , transfer::receiver , transfer::copy::queue , transfer::transmitter) > * A thread-safe message queue (http://wiki.tcl.tk/17652) -- might be > better bundled directly with the Thread extension, but could also go > in tcllib. I have some tests and docs for this too, so it could go > straight in (subject to review). I agree with the sentiment that this belongs more with Thread than tcllib. Hm. ... It seems you are using the 'shared var' facility of Thread to implement them. I wonder if it might be easier to use 'thread::send' as a basis instead, i.e. the C-level event (message) queue as the foundation. > * Simple download progress widget (http://wiki.tcl.tk/10571) -- with > a bit of polish this could find its way into tklib. I have some half- > finished code generalising this into a task-progress dialog. Yes, tklib definitely ... Jeff has a number of things under the widget module, maybe it fits in there ? (Note: Jeff's stuff is snit based. Ah, yours too, good). > I also have a variety of other bits and pieces sitting on my laptop > that could be polished up -- e.g., an "article" widget for displaying/ > composing email/usenet articles, Interesting. A new mail/news reader in Tcl/Tk ? > various implementations of algebraic > datatypes Which types ? And what advantages do we get from their algebraic-ness ? > and pattern matching, a couple of unification algorithms, a > scrolling ticker widget, etc. If any of these appeal I could be > tempted into packaging them up. Yes. -- Andreas Kupries <and...@Ac...> Developer @ http://www.ActiveState.com Tel: +1 778-786-1122 |