[chuck-users] sporking shreds, advancing time

[Kassen]

On 10/5/06, vb <vboehm at gmx.ch> wrote:
>
> hi all,
> i'm still struggling with the basics of chuck, it seems.



Hi there! No problem, let's have a look at it.

is it more appropriate for chuck's liking to advance time inside the
> impulse function and spork it only once,
> or to spork the impulse function regularly?
> volker.



Well, both could be used and either might be apropriate depending on the
situation. I didn't try actually running either example but both look fine
to me. I'd say that for just this simple thing example 1 would be best
because it's most simple and probably cheaper on the cpu.


The second form could also be more simple since it's not actually nesicary
for two shreds to run at the same time you could simply call "click()" as a
function instead of sporking it to it's own shred.

Generally sporking shreds is used to have several things happen at the same
time. Function calls without sporking (instead of copying the function's
code to one or more locations) is mainly usefull for clarity, readability
and keeping your files from growing realy big. If neither is needed I
would't use either because they add complexity. Here I'd use;

-------
Impulse i => dac;

while(true)
   {
   1.0 => i.next;
   0.5::second => now;
   }
---------

This is the most simple form; if no more is needed then I wouldn't do any
more.

I think you are doing well; clearly you figured out that you can have
several programs that do the same thing, the one thing I could add to it is
that when you have several functionally identical programs you can pick the
one you like best. In those cases I myself often pick the one I find most
simple to deal with unless one of them is much less heavy on the cpu. I
think you'll find that the larger you programs become the more both matter;
a very big program needs good structuring or you'll be lost in it next week
and clearly for larger programs it's important to make sure the cpu doesn't
get overworked. Of cource it's also possible to have a small program that
looks simple but that still takes a lot of cpu but even then you'll benefit
from keeping it all simple because then it's easier to find what bit costs
so much cpu.

I hope this covers at least some of your question?
Do give a shout if I missed something.

Yours,
Kas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20061005/3fc2daca/attachment.htm