A/AK. After reading discussions about different Things holding Tcl back, I decided to say it aloud: Ffidl should be in the core.When adding things to the core, there is always a trade-off between adding the useful functionality and keeping the core relatively small (hmm) and maintainable. But Ffidl has a huge potential usability and is yet relatively small in size.Why do I think that there is a huge potential usability in Ffidl? Here is an example: 3 days ago I was looking for ODBC->TCL binding that would support unicode SQL types. I considered adapting Tclodbc... but I've decided instead to make a low-level API calls with Ffidl and create a high-level interface with snit. Now I have a drop-in replacement for Tclodbc that works with unicode types; if I'll need some ODBC3-specific feature, it'll take only a few minutes to add it to my project.There is a question: would anyone bother implementing Tclodbc as a binary extension, if Ffidl were in the core? Well, I can't say for anyone, and ODBC is not that simple; it's possible that someone would write Tclodbc even in that case. However, I'm sure that a lot of binary extensions existing today would never be binary, but pure-Tcl, if the pure Tcl contained Ffidl out-of-the-box.For some extensions, implementing them in C is justified. However, a lot of extensions are mere replacements for the missing Ffidl: the only thing they do is forwarding script commands to the OS or some external library.Lars H: Putting something in the core is always very sensitive, but presumably "package bundled with the core" (like threads or http) would serve just as well? From the look of the above, it also seems this package has some maturing to do (not necessarily improving, but proving stability) before either could be considered, though.TP I would be interested in your TclODBC clone, is it available? Good points to raise regarding writing custom extensions vs. ones built from Ffidl & Ffix. Personally, I've written custom C coded extensions, SWIG generated + Tcl helpers, and Critcl extensions in the past; Ffix seems to be a nice helper on top of Ffidl.A/AK The ODBC wrapper is a part of my bigger project (not yet released), and has many dependencies on Tcl-8.5 as well as some other not-yet-released packages. Though I doubt whether you find it useful, I've uploaded the ODBC module, along with others that it depends on, to http://www.sw4me.com/private/monster-alpha.tar.gz
(package require odbc::obj and then odbc::database cmdName datasource login password is what you need to start with the ODBC wrapper). All prerequisites for odbc::obj are in the archive, except SNIT and Ffidl that must be downloaded separately. stmtname columns feature is not supported yet, other documented TclODBC features should work. This archive contains Tcl Modules that should be installed to an appropriate directory (it's easy to generate pkgIndex.tcl )To be short, you need to be familiar with Tcl-8.5 to get it all working. Porting these things to Tcl-8.4 is possible - even without getting rid of multiple uses of dict and {*} (I've had it in mind while writing a page on Using sugar for forward-compatible {*}). However, porting is not as easy as one may think, so I'll postpone it until the code base is stable.As of the usability of ffix, I've recently discovered a much more convenient way to specify argument conversions for output pointer arguments. Page about references in Tcl (a simple approach) contains a paragraph on it. Implementing that solution makes any wrapper procedure around a Ffidl callout almost unnecessary, as all argument conversions will be easily done where the function is called. So I should have think a little longer before writing ffix :-(A/AK 2005-Sep-09: SnODBC extension is a backport of the ODBC wrapper mentioned above to TCL 8.4. It is available as a starkit from [2]