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!
