[chuck-users] Object reference weirdness

mike clemow gelfmuse at gmail.com
Thu Sep 25 09:32:02 EDT 2008

Well, that might certainly explain my mysterious double-reference, no?

I will post a copy of the code on my site so that you can run it.  It
probably won't be another few hours as I have class until 3pm on the
East Coast in the US.  Also, being that this is part of a larger
project, I'm going to have to write out some instructions on running
it and point out how to recreate the strange behavior.

In the meantime, I should say that I've sort of given up trying to get
this to work for this project.  I've come to the conclusion that Chuck
code that doesn't make any sound is a waste of time about 90% of the
time.  The 10% that's left is generally very concise and elegant (my
code is neither concise nor elegant).  Also, I think I'm coming to
understand that my dream of a class library for Chuck is somewhat
misguided.  What I mean by that is my conception of a class library
comes from the Smalltalk-style library where everything builds on
everything else.  This is great in purely object-oriented languages,
but not so much in Chuck.

I recently watched the Audicle demos again and have decided that Chuck
makes the most sense to me in the context of the Audicle.  The Audicle
really plays to the strengths of Chuck, which are three things:
*Audio* and *Concurrency* in a *Networked* environment.  The unit of
currency in Chuckland is not the object, it's the code file (or shred)
and thinking in this way makes way more sense.  In the Audicle, it's
second nature, however, coming on the commandline it's a little
strange, since these things exist on your drive and not necessarily in
the VM.

Basically, I've decided I'm trying to get Chuck to do something that I
don't think Chuck is good at, which translates to bad design on my
part.  I'm basically thinking inside the VM and I've got to start
thinking outside the VM.  Chuck is a live-coding language in which you
deploy code and remove code from a running VM.  But there's nothing to
say that the live-coder has to be a person: it could be another
program.  My direction after I get the basic audio functions working
(which they mostly are now, thanks to Spencer and the rest of you ;-)
is to start writing programs to write Chuck code and deploy it on the
fly.  Meta-live-coding, if you will.  I'd rather build my arrays in
Python and have Python write them into my Chuck files.  My "session"
would become the Chuck files that were generated while coding this
Python framework.  Python will do the wheeling and dealing with the
Chuck VM and my Chuck code basically becomes a modular sound server.
This will be excellent on a network as well.

I might have just described my thesis right there...  not sure.
Anyway, it also might be a complete failure.

I'll send my code out soon.  I'm sure that I've just messed something
up in there somewhere and Chuck's bus error is really my fault.


On Thu, Sep 25, 2008 at 3:34 AM, Tiemen Meerman
<tiemen.meerman at phorm.com> wrote:
> In the meantime, what exactly is a bus error?  What generally causes them?
> Bus errors can be caused by memory accesses that are misaligned: ie. a 32
> bit read off of an odd memory address.
> Sounds like some pointer arithmetic going wrong somewhere in ChucK.
> -T
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users


More information about the chuck-users mailing list