Some things that would be nice to be able to do - now that we've started hacking things with new ulib_foo constructs... * capability to build ulib_foo functions that can treat the dur primitive type. * The handling of parameter input to ulib functions is severely flawed, including lack of type security across platforms and probably not 64-bit secured: the method for retrieving multiple parameters as done in the implementation of math.pow will break down if sizes of ints, floats and pointers start to differ; and should in any case be wrapped in some more robust handling way; for instances those actually present in C++ a priori. * You have several various memory leaks and similar problems; use of valgrind is advised. If these things are not possible due to not being harmonic with the ChucK way of thinking; please tell us what to do instead (instructions for building .ckx would be nice for instance... =) -- Mikael Johansson | To see the world in a grain of sand mikael@johanssons.org | And heaven in a wild flower http://www.mikael.johanssons.org | To hold infinity in the palm of your hand | And eternity for an hour
Hi Mikael et. al,
* 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. We should continue this discussion on chuck-dev. Thanks for looking into this! Best, Ge!
participants (2)
-
Ge Wang -
Mikael Johansson