[chuck-users] chuck and jack

[Hans Aberg]

On 14 Aug 2009, at 14:23, Kassen wrote:

>> There seems to be a timing problem with <<< ... >>> in ChucK. So  
>> take all that away in all time critical positions, and see if the  
>> problem goes away. And report back here, if it does.
>
> I think the main issue is that printing isn't done by the VM itself  
> and that printing to the screen is expensive, CPU-wise.

I have been searching the sources a bit, and it seems that the engine  
has to do a lot of interpretation to get the stuff printed out.

Searching for "<<<" gives
   chuck.y:        | L_HACK expression R_HACK          { $$ =  
new_exp_from_hack( $2, EM_lineNum ); }

Then "new_exp_from_hack" is defined in chuck_absyn.cpp:
   a_Exp new_exp_from_hack( a_Exp exp, int pos )
   {
     a_Exp a = (a_Exp)checked_malloc( sizeof( struct a_Exp_ ) );
     a->s_type = ae_exp_primary;
     a->s_meta = ae_meta_value;
     a->primary.s_type = ae_primary_hack;
     a->primary.exp = exp;
     a->primary.linepos = pos;
     a->linepos = pos;
     a->primary.self = a;

     return a;
   }

Then ae_primary_hack is used in chuck_emit.cpp, where the case calls  
emit_engine_emit_exp(), which seems to be a function that unwinds the  
closure that the expression points to. Continue the chase if you so  
like - it would be fun to know where it is printed.

So it seems a lot of stuff has to be done in real-time interpreting.  
Probably has nothing to do with buffering to the computer, which are  
so fast nowadays. It would explain other timing problems, like with  
audio-files.

   Hans