Hooray! :D On Sat, Aug 25, 2012 at 11:16 AM, Scott Hewitt wrote:

Awesome! On Aug 25, 2012 1:15 AM, "Spencer Salazar" wrote:

...

Dear all,

chuck-1.3.0.0 (chimera) is available:

http://chuck.cs.princeton.edu/ http://chuck.stanford.edu/

This release incorporates ChuGins, a new way to extend ChucK. ChuGins are a continual work in progress, and we encourage feedback in anticipation of rapid updates, tweaks, and fixes. Chugens and Chubgraphs provide additional mechanisms for extending ChucK's built-in audio capabilities. Furthermore, this release variety of smaller fixes and additions.

To start developing ChuGins, please see several examples here, in addition to the chuginate utility, which generates the skeleton framework for a new ChuGin. https://github.com/spencersalazar/chugins and: https://ccrma.stanford.edu/~spencer/publications/CCC2012.pdf

(Please see the release notes at the end of this email.)

Many many thanks once again to Kassen, Casper Schipper, Jorge Herrera, Hongchan Choi, and everyone on chuck-users, as well as PLOrk, SLOrk, the Food Services Division at Smule, Fernando Lopez-Lezcano, Carr Wilkerson, Chris Chafe, and the rest of the chuck community for making this release happen!

Thanks and Happy ChucKing, UpChucKing!

Best, Ge + Spencer, on behalf of entire chuck team

--- 1.3.0.0 - (added) Chugins: dynamically loaded compiled classes/ugens see http://chuck.stanford.edu/extend/ for examples. - (added) new command line options --chugin-load:{auto|off} disable/enable chugin loading -gFILE/--chugin:FILE load chugin at FILE -GPATH/--chugin-path:PATH load all chugins in directory PATH --dac:NAME use dac with name matching NAME --adc:NAME use adc with name matching NAME - (added) Chubgraphs: create ugens by compositing existing UGens see examples/extend/chubgraph.ck - (added) ChuGens: create ugen by implementing audio-rate processing in ChucK see examples/extend/chugen.ck - (added) new ugens: - WvOut2: stereo uncompressed audio file output - SndBuf2: stereo uncompressed audio file input - (added) new functions: - me.sourcePath() returns file path of source file corresponding to this shred - me.sourceDir() returns directory of source file corresponding to this shred - MidiIn.open(string name) open MIDI input matching name - MidiOut.open(string name) open MIDI output matching name - Hid.open(string name) open HID matching name - (added) experimental OS X multitouch HID - (fixed) real-time audio on Mac OS X 10.7 (Lion), 10.8 (Mountain Lion) - (fixed) IO.newline() now flushes "chout" - (fixed) "chout" and "cherr" now invoke member functions correctly - (fixed) no for statement conditional handled correctly - (fixed) STK WvOut correctly handles case when file open fails - (fixed) << operator for arrays now correctly references counts - (fixed) crashing bug when receiving external events at a high-rate ("the OSC bug") - (fixed) scope closing correctly dereferences local objects - (fixed) crash when exiting shreds with connected ugens - (fixed) deallocation of "empty" Shred object no longer crashes - (fixed) crash when HID events are sent to an exited shred - (fixed) destructors for built-in objects are executed _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- Release me, insect, or I will destroy the Cosmos!

On Sat, Aug 25, 2012 at 06:30:34PM +0200, Hans Aberg wrote:

On 25 Aug 2012, at 02:14, Spencer Salazar wrote:

...

chuck-1.3.0.0 (chimera) is available:

On Mac OS X 10.7 and later, the system defined PATH includes /usr/local/bin/, which is where non-system installed binaries normally are put.

That makes sense for cleanliness, but what is the chance of people running a older version? Last time I checked OSX had some unexpected behaviour (for me) in that the "which" command follows the system path and not the user's. This can lead to "which" reporting a location for a binary that might not be the version that will get executed when the command is invoked. Might be a BSD standard with solid reasoning behind it, but from my perspective this looks potentially confusing and so I'd rather stick to what we can be sure is the system path. I agree with you that ideally /usr/bin is not the place where we should be if /usr/local/bin is a option, but I could see this breaking pre 10.7 configurations in ways OSX users may not be accustomed to fixing. Yours, Kas.

On 25 Aug 2012, at 18:42, Kassen wrote:

On Sat, Aug 25, 2012 at 06:30:34PM +0200, Hans Aberg wrote:

...

On 25 Aug 2012, at 02:14, Spencer Salazar wrote:

...

chuck-1.3.0.0 (chimera) is available:

On Mac OS X 10.7 and later, the system defined PATH includes /usr/local/bin/, which is where non-system installed binaries normally are put.

That makes sense for cleanliness, but what is the chance of people running a older version?

The INSTALL file should give separate instructions for those (also see below). Of course, one can set ones own PATH, especially since the system PATH has the wrong order: /usr/local/bin/ should normally be ahead of the system installation objects, so you get the latest version when installing duplicates.

Last time I checked OSX had some unexpected behaviour (for me) in that the "which" command follows the system path and not the user's. This can lead to "which" reporting a location for a binary that might not be the version that will get executed when the command is invoked. Might be a BSD standard with solid reasoning behind it, but from my perspective this looks potentially confusing and so I'd rather stick to what we can be sure is the system path.

I haven't see that, but for the program Terminal, one should set in .profile, whereas for X11 and xterm in .bashrc. So my .bashrc contains source ~/.profile

I agree with you that ideally /usr/bin is not the place where we should be if /usr/local/bin is a option, but I could see this breaking pre 10.7 configurations in ways OSX users may not be accustomed to fixing.

I have users in mind that we on occasion have seen here who know very little about UNIX and POSIX. If they have pre-10.7, it is easiest for them to use /usr/bin/. Hans

On 25 Aug 2012, at 19:15, Kassen wrote:

On Sat, Aug 25, 2012 at 07:03:42PM +0200, Hans Aberg wrote:

...

Of course, one can set ones own PATH, especially since the system PATH has the wrong order: /usr/local/bin/ should normally be ahead of the system installation objects, so you get the latest version when installing duplicates.

Yes, I agree.

On Mac OS X, one can change the system PATH by putting stuff in some directory somewhere, but then it is read in its own order (alphabetical probably). This is how it gets the wrong order.

...

I haven't see that, but for the program Terminal, one should set in .profile, whereas for X11 and xterm in .bashrc. So my .bashrc contains source ~/.profile

I think Linux will typically respect both (I forgot the order), and not just in X11, the TTY's read it too, at login.

Anyway, where it goes wrong (IMHO) is if you have a directory like ~/scripts In that case you'd put that in your path, perhaps even at the beginning. From memory; if you put a custom version of ChucK there for testing then "which chuck" -on OSX- will return /usr/bin/chuck while executing "chuck" will ~/scripts/chuck

That, needless to say, can cause confusion, though admittedly it is a independent issue from the one you are addressing.

As far as I know, 'which' just uses PATH. I have a ~/bin/ directory; here is test: $ which chuck /usr/local/bin/chuck $ cp /usr/local/bin/chuck bin/ $ which chuck /Users/<user>/bin/chuck And my PATH is (some stuff removed) /Users/<user>/bin:/usr/local/bin:/usr/local/X11R6/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin

...

I have users in mind that we on occasion have seen here who know very little about UNIX and POSIX. If they have pre-10.7, it is easiest for them to use /usr/bin/.

I agree, and I think that should be done by the makefile. What could be considered is the makefile reading the system path and if /usr/local/bin is in it (likely indicating ISX 10.7 or later) put it there, otherwise in /usr/bin like it used to be.

That'd be correct in all cases I can think of without breaking old stuff.

It would not work if the user has a custom version. The standard way, that ism what I have seen on most packages, is that 'make install' puts binaries in /usr/local/bin/, docs in /usr/local/share/doc/chuck/, and examples in /usr/local/share/chuck/examples/. Then one uses a prefix variable that can be changed from the default /usr/local/. There is a "Filesystem Hierarchy Standard" which BSD/GNU Linux system largely adheres to. It might be simpler to forget about a custom install for before 10.7 Mac OS X. Hans

On 25 Aug 2012, at 20:49, Kassen wrote:

On Sat, Aug 25, 2012 at 08:25:54PM +0200, Hans Aberg wrote:

...

On Mac OS X, one can change the system PATH by putting stuff in some directory somewhere, but then it is read in its own order (alphabetical probably). This is how it gets the wrong order.

Hmmmm

Right. :-)

...

As far as I know, 'which' just uses PATH. I have a ~/bin/ directory; here is test:

Maybe it was changed for the better. I ran into this on a Leopard install and as you can imagine; this led to some subtle and hard to trace trouble.

I haven't seen it, but 10.6 Intel was the first certified UNIX. Funnily, 10.7 isn't, but 10.8 is under the name "Mac OS X 10.8 Mountain Lion", with "Mac" then.

...

It would not work if the user has a custom version. The standard way, that ism what I have seen on most packages, is that 'make install' puts binaries in /usr/local/bin/, docs in /usr/local/share/doc/chuck/, and examples in /usr/local/share/chuck/examples/.

Then one uses a prefix variable that can be changed from the default /usr/local/.

There is a "Filesystem Hierarchy Standard" which BSD/GNU Linux system largely adheres to.

It might be simpler to forget about a custom install for before 10.7 Mac OS X.

Maybe the core of the issue is that OSX users, for very understandable reasons, are not used to installing binaries to the terminal's path. Most of the time they will install GUI applications but for better or worse those are not normally in the terminal's path.

Following UNIX traditions and keeping people who already know their way around that sort of thing happy is probably easier than making things easy to use and understand for people new to that layer.

I think so too, because there have not been too many UNIX novices on this list.

Oh, well, it's a interesting set of questions. I'd be inclined to take the lazy route now and stick to how it is and has been. /usr/bin in a fine place for executables too. It's not a "core system" thing, but that's a bit moot on OSX as you can't really boot just a core system (with no GUI, etc) anyway.

Since it is reserved for the system, an updater or installer could in principle overwrite it, though it is more important to not change anything installed by the system. But on Mac's, development tools are not installed by default.

I liked the "homebrew" idea too as that takes a lot of the fuzz off the user. Less fuzz it better terminals and CMD.exe already turn out to be big enough a challenge.

It expect one to change the permissions of /usr/local/, even though it might be possible to work around it. But it means changing the normal system installation, so I decided to pass. I have set a sticky bit on /usr/local/src/, so I can put sources of packages there and compile as a normal user. Then 'sudo' is only needed for 'make install'. In MacPorts is sometimes useful. For some reason, I haven't had much use of Fink. Hans

On 25 Aug 2012, at 21:29, Robert Poor wrote:

FWIW, I skirt the whole issue of "what version of <program name here> am I running" with a simple sandboxing technique. I relied heavily on this when I was using ChucK for live performances and absolutely needed to know that all the libraries and executables were self-consistant.

There is a package to automate something like that, though I didn't get to use it much. http://modules.sourceforge.net/ Hans