[chuck-users] Object reference weirdness
gelfmuse at gmail.com
Thu Sep 25 17:55:46 EDT 2008
As promised, my spaghetti code:
There's a README.txt file that has all the details about running the
code and where the issues are described. Thanks to anyone who takes
the time to look at this.
On Thu, Sep 25, 2008 at 9:32 AM, mike clemow <gelfmuse at gmail.com> wrote:
> 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.
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
More information about the chuck-users