[chuck-dev] wishlist and bugreport of hacking (from chuck list)
mikael at johanssons.org
Thu Dec 9 04:14:10 EST 2004
On Thu, 9 Dec 2004, Ge Wang wrote:
> 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
> 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.
So, what would it look like? Say I want to build a freqtodelay tool that
takes a frequency and returns the dur corresponding to the wavelength. (I
know, it's silly, but I want to get a hang of it...)
In my foobar_query function (registered in chuck_main, together with the
ulib_foo things) I include
QUERY->add_export(QUERY, "dur", "freqtodelay", freqtodelay_impl, TRUE);
QUERY->add_param(QUERY, "float", "frequency");
and where does the time come in? Or is it impossible to -return- durations
>> * 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.
There are already some macros taking care of stepping through arcane
arrays (the GET_NEXT_FLOAT et.c. family) - why not make sure there are
similar for the argument reading? The hack we finally got working was the
char* name = GET_CK_STRING(ARGS); (char*)ARGS+=sizeof(char*);
t_CKFLOAT foo = GET_CK_FLOAT(ARGS);
with the (foo*)ARGS+=sizeof(foo*) being repeated for every nonfinal
argument to be read... All this should be easy to wrap in a macro so that
all we really need to do is
char* name = GET_CK_STRING(ARGS);
t_CKFLOAT foo = GET_CK_FLOAT(ARGS);
with the GET_CK_FOO automatically incrementing as we go along...
> 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
>> * 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 just noted that while looking for potential memory leaks in our hacks,
we found leaks all over the audio code; but none in our own...
> Thanks for looking into this!
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
Mikael Johansson | To see the world in a grain of sand
mikael at 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
More information about the chuck-dev