Developers, Sorry for the multiple posts - this is continuing Mikael's thread from chuck list. ----
* capability to build ulib_foo functions that can treat the dur primitive type.
They actually can, in a semi-hack way. dur and time are passed as double-precision floats (or t_CKDUR and t_CKTIME). When defining the prototype, you only need to specify "dur" or "time". The semantic of both is that they both count samples (or fractions thereof). There are ways of converting samples to sample-rate independent time, the most basic of which is to normalize by the system sample rate in Digitalio.
* The handling of parameter input to ulib functions is severely flawed, including lack of type security across platforms and probably not 64-bit secured:
Um, yes - there are some egregious hacks in that area of the code. We have tried to alleviate the data width with consistent types across the system (t_CKFLOAT, t_CKINT, etc), and hopefully a configure script would be able to resolve that across platforms. As for the (non-existent) type-checking at the ckx level, this is so because currently ckx are viewed as "trusted" modules to be plugged in, and while the paradigm of ChucK allows for externals to be added, ChucK reduces the need for many externals because of the flexibility of timing mechanism and soon the ability to write unit generators directly in ChucK. (the idea is to move away from dependence on plug-in modules, but support them anyway) Also, such checks may reduce performance. Given this and priorities for other features, no type-checking is performed when a ckx is dynamically loaded or when the functions are invoked. However, we are open to methods of efficiently handling this, especially when we release (by which I mean document) the CKX way of importing modules written in other languages.
* You have several various memory leaks and similar problems; use of valgrind is advised.
We have documented some known leaks, most of which is in the type checker / emitter, which accumulates slowly when loading new parse trees and such (but is stable otherwise). Which ones are you referring to? Much of this is being fixed as we work on the rewrite, which overhauls the type checker and emitter, and parts of the VM. Thanks for looking into this! Best, Ge!