[chuck-users] Blob (was; Physics Engine In Chuck)

Stephen Sinclair radarsat1 at gmail.com
Tue Dec 16 20:15:36 EST 2008

I think the part that I don't get about what you're saying is that you
seem convinced that create extensions (ckx) is a good idea, yet you
are worried about fracturing the development model.  I'm suggesting
providing a place where we can build them into the actual program.  I
would claim that creating ckx extensions is far more "fracturing",
like the Pd model.

I'm not a fan of plugins.  I think including the kitchen sink is a
good way to go with this kind of program, because it gives you
something you can depend on.  With two versions available, an
experimental version and a 'master' version, you can easily say, "this
program works with real ChucK", or "this program works with the
experimental version".

If you start throwing ckx files in there, it becomes much more
complicated.  "This program works with real ChucK, with this and that
extension loaded, which you can go download from this guy's website",
etc.  That's why I thought it would be prudent to create a community
edition that allows people to get their code in to a central location,
without putting any overhead on the ChucK team.

Using a central git repo, we can have branches for each feature people
want to integrate, and then just give a shout to the ChucK team
saying, "hey we did this, it's in branch X, grab the patch if you
want."  The key thing being that there will be a "mob" branch that
anyone can submit patches to without having to ask for permission.


On Tue, Dec 16, 2008 at 7:44 PM, Adam Tindale <adamtindale at hotmail.com> wrote:
> I think we are not actually that far apart, but I still think that
> fracturing the project in any way weakens it. Making it easier for users to
> go deeper and experiment with the guts sounds like a good idea. I suggest we
> proceed with caution.
> You guys bring up a good point: Ge has created a monster. The state of the
> ASIO patch is not good. I think we need to apply pressure to the DEV team to
> get an explanation about this.
> To create a playground is possible by downloading any release and messing
> with the source. In the past, people have created diffs, forwarded them to
> the DEV team, and they were then merged. Some people have become part of the
> DEV team and gotten access to the CVS, made their changes, did the commits
> themselves, and then that was it for their time as DEVs.
> Here is what I would like to see ChucK-users or ChucK-forge to be: A
> collection of user .ck files. I think we could get it hosted at Princeton as
> well or we could open a sourceforge project.
> I think you guys bring up a good point that it isn't quite enough at this
> point. Steve's work at compiling UGENS is great and now what we need is the
> proposed .ckx file which was supposed to be exactly this. Maybe this is
> something to revisit, it would help others and also make it so that Steve
> wouldn't have to appologize. The work was great, we should all build upon
> it.
> If we cannot get a .ckx thing going then at that point I think it becomes
> necessary to create a ChucK thing where user generated UGENS are compiled
> in. I don't think we need to get there though. I think we investigate some
> of Kas' work on the wiki and look at the tracking and reporting structure
> that is not in place right now. The DEVs are busy. If we ask something from
> them we should give back, that is excatly why I started on the manual oh so
> many moons ago. We could help integrate a bug tracking system or
> organization software solution to address some of the problems we have
> noticed in ChucK's development.
> Maybe this needs to be moved to the DEV list as we impliment solutions.
> --art
> ________________________________
> Visit messengerbuddies.ca to find out how you could win. Enter today.
> _______________________________________________
> 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