[chuck-dev] initial patch for 64-bit

Stephen Sinclair radarsat1 at gmail.com
Tue Sep 2 10:41:39 EDT 2008

On Sun, Aug 31, 2008 at 2:43 PM, Ge Wang <ge at ccrma.stanford.edu> wrote:
> Greetings again, Kassen and Steve!
> First of all, huge thank you's for all you've done for ChucK and friends!

I've really been enjoying hacking on Chuck lately.  ;)  I find it
pretty interesting to see how someone else has attacked the problem of
writing a language for real-time, sample-accurate audio with dynamic
behaviour and a complete VM.  I hope I'm able to contribute something
useful to the effort as ChucK makes a great alternative for me to the
graphically oriented audio tools like Pd.

Thanks for writing it!  And I'm really happy you seem to be interested
in continuing it even after finishing your thesis.  ;-) I would fully
understand the desire to leave such a big project behind after an
effort like that, at least for a few months of brain-rest.  But all
the more reason to encourage others to take on the new challenges!

>>> But I'm currently a bit confused whether the ChucK devs actually read and
>>> use this list, since there is obviously work being done on ChucK but I see
>>> no information about it, and no one responded to my patch. If not, I'm just
>>> wondering if there's a more appropriate place to discuss ChucK development
>>> or to at least submit patches.
> This is a great point.  We haven't been using this list as much as would
> be helpful.  Things have certainly been a bit crazy for everyone these last
> few months.  I just got back from ICMC in Belfast, and a week before that
> Beijing.  Others have had fairly crazy schedules as well.

Of course ICMC must have been crazy.. ;-)  and Beijing too, no doubt!
I guess some people here at McGill have just gotten back from that
too, I'll have to ask how it was..

Sorry for being whiny about my patch, I waited a week before
complaining.. ;-)  I find in open source, sometimes a little nudge
helps get people over the "hump" of getting around to examining
patches and bug fixing..

I'll continue to use this list as I think a mailing list is a great
way to send patches and generally communicate about development, but
for this very reason I was just a little surprised at the lack of mail
lately.  ICMC is a perfectly good excuse of course.. ;-)

>> Still, it's my suspicion that if more time would be spend on open
>> communication then that would make it easier to share the work (not just
>> coding but also documentation, finding bugs and documenting them, answering
>> questions, etc, etc, etc), thus decreasing the load on some individuals.
>> Right now I am contributing a bit but I could do more (and have fun doing
>> it) if we could improve comunication. I'd be happy to try my hand at fixing
>> Sitar, for example, but it's not at all clear to me how Sitar should deal
>> with very low notes (clearly not by outputting text warnings at sample-rate,
>> which is the current behaviour). I'd also be happy to help write the manual
>> but it's not at all clear to me in what form I should donate paragraphs or
>> small sections.
> Hear hear!  I agree with all of this.  At the moment, I honestly don't
> know how to effectively fix this, but please know that I genuinely want to.
>  Feedback in this forum, despite lack of responses from me, have
> been extremely helpful.  We'll need to come up with ways to submit patches,
> doc's, examples, etc...  Working on it, though slowly!

Well, one way might be to take advantage of services like sourceforge
which provide all these things.  Not necessarily SF of course, since
not everyone likes it.  (Personally i don't mind it, though it's
sometimes slow.)

My preference is to make use of the mailing list instead of or in
addition to a patch tracker, but either way some way of tracking these
things is always helpful.  Submitting patches against a specific CVS
date is pretty much equivalent to sending a tarball.  The nice thing
about including patches directly in an email is that you can look at
them (at least short ones) critically before even trying to compile
and test.  Another option would be to install something like Trac or
Redmine on the web server, but it's a lot more work to administer
something like that yourself.

I've said it before, but a great way to deal with looking at other
people's development trees is to use git (along with gitorious.org or
repo.or.cz for hosting), which allows someone to do all sorts of
development and then tell the mailing list, 'hey, look I added this
feature, come grab it'.  That way everyone takes care of their own
source repository, and you can easily grab the good parts from what
other people are working on when they are ready.  (While retaining
authorship credits, etc.)  I'm currently using git to track the chuck
CVS which makes it much easier to port my changes to the latest



More information about the chuck-dev mailing list