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!
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 too?
* 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 following: 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 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@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@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
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 too?
This should work just fine. (just remember to return a float that is the number of samples (using Digitalio to go from seconds etc to samples))
* 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 following: 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...
Yes - foo is out of date for this... the macros you mentioned are made for this purpose: // param conversion #define GET_CK_FLOAT(ptr) (*(t_CKFLOAT *)ptr) #define GET_CK_SINGLE(ptr) (*(float *)ptr) #define GET_CK_DOUBLE(ptr) (*(double *)ptr) #define GET_CK_INT(ptr) (*(t_CKINT *)ptr) #define GET_CK_UINT(ptr) (*(t_CKUINT *)ptr) #define GET_CK_TIME(ptr) (*(t_CKTIME *)ptr) #define GET_CK_DUR(ptr) (*(t_CKDUR *)ptr) #define GET_CK_STRING(ptr) (*(char **)ptr) // param conversion with pointer advance #define GET_NEXT_FLOAT(ptr) (*((t_CKFLOAT *&)ptr)++) #define GET_NEXT_SINGLE(ptr) (*((float *&)ptr)++) #define GET_NEXT_DOUBLE(ptr) (*((double *&)ptr)++) #define GET_NEXT_INT(ptr) (*((t_CKINT *&)ptr)++) #define GET_NEXT_UINT(ptr) (*((t_CKUINT *&)ptr)++) #define GET_NEXT_TIME(ptr) (*((t_CKTIME *&)ptr)++) #define GET_NEXT_DUR(ptr) (*((t_CKDUR *&)ptr)++) #define GET_NEXT_STRING(ptr) (*((char * *&)ptr)++) there are set macros as well. Ge!
participants (2)
-
Ge Wang -
Mikael Johansson