[chuck-dev] wishlist and bugreport of hacking (from chuck list)

Mikael Johansson mikael at johanssons.org
Thu Dec 9 04:14:10 EST 2004

On Thu, 9 Dec 2004, Ge Wang wrote:
> 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.

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*);

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);
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
> 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 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!
> Best,
> Ge!
> _______________________________________________
> chuck-dev mailing list
> chuck-dev at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-dev

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 mailing list