1.2 aproaching? and building on FreeBSD
Hi! I'm another of those chuck users / hackers at Stacken, and just
subscribed to the chuck lists.
What is the current status on the 1.2 release? Is there anything I
can do to help?
I just compiled chuck (both "src" and "v2") on FreeBSD 5.4pre, to
build with "make linux-oss" I had to:
* Add -I/usr/local/include to FLAGS
* Remove -ldl from LIBS
* Added #include
Hi! I'm another of those chuck users / hackers at Stacken, and just subscribed to the chuck lists.
Hi Rasmus! Long live Stacken.
What is the current status on the 1.2 release?
The type system has been overhauled to support arrays and objects and to remove some bad hacks (and add others). Added more operators for convenience (+=>, -=>), added break, continue. Arrays are done - int/string indexed, multi-dim. Objects are also done, at least to a usable degree - virtual inheritance, static/member functions/data, recursive namespace. The final push is to add ugen and library classes back into the type system in a way that is flexible and extensible. This part makes us want to chuck something out the window (because it's so "fun") - but it's almost done (and there aren't many windows in the lab, at least not to the outside world.)
Is there anything I can do to help?
The import system is the bottle neck right now. Further hacking depends on this. Once it's done, then C/C++ code can be imported less stupidly than before, and the portal to massive hacking will be opened (yikes).
I just compiled chuck (both "src" and "v2") on FreeBSD 5.4pre, to build with "make linux-oss" I had to:
* Added #include
in util_sndfile.h, just before whats seems to be a copy of sndfile.h from a specific system. Is there any reason to copy in the file rather than including it?
It was just there for (in)convenience. There is a hack to get around this hack - in the makefile: #----------------------------------------------------------------------------- # by default, ChucK uses a pre-configured libsndfile... # uncomment the next 3 lines to use libsndfile on your system #----------------------------------------------------------------------------- #FLAGS+= -D__CK_SNDFILE_NATIVE__ #LIBS+= -lsndfile #SF_OBJ= May need to add -I/usr/local/include to FLAGS, and also -L/usr/local/lib to LIBS. In the Stacken autoconf, I sense this is finally resolved cleanly. As soon as the code becomes stable, we will start to integrate what you guys have done with autoconf. Stacken rocks. We are committed to making this release happen as soon as possible. We will put out a working version (hopefully) and continue to work together make it better, on-the-fly. Best, Ge!
"GW" == Ge Wang
writes:
What is the current status on the 1.2 release?
GW> The type system has been overhauled to support arrays and objects and GW> to remove some bad hacks (and add others). Added more operators for GW> convenience (+=>, -=>), added break, continue. Sounds cool ... Would "foo => bar; baz +=> bar;" mean the same thing as "foo + baz => bar;" then? GW> Arrays are done - int/string indexed, multi-dim. That can probably be usefull. A string-indexed array, sounds like a convenient lookup table ... GW> Objects are also done, at least to a usable degree - virtual GW> inheritance, static/member functions/data, recursive namespace. Now this like something *really* cool, which I've been longing for for six months or so ... :-) Is there any example code (or even documentation) for this? GW> The final push is to add ugen and library classes back into the GW> type system in a way that is flexible and extensible. This part GW> makes us want to chuck something out the window (because it's so GW> "fun") - but it's almost done (and there aren't many windows in GW> the lab, at least not to the outside world.) Eh ... *lol*, I think ... :-)
Is there anything I can do to help?
GW> The import system is the bottle neck right now. Further hacking GW> depends on this. Once it's done, then C/C++ code can be imported GW> less stupidly than before, and the portal to massive hacking will GW> be opened (yikes). Huh? Import from what to where? [...] GW> #------------------------------------------------------------------ GW> # by default, ChucK uses a pre-configured libsndfile... GW> # uncomment the next 3 lines to use libsndfile on your system GW> #------------------------------------------------------------------ GW> #FLAGS+= -D__CK_SNDFILE_NATIVE__ GW> #LIBS+= -lsndfile GW> #SF_OBJ= Oups, sorry I didn't notice that! GW> We are committed to making this release happen as soon as possible. GW> We will put out a working version (hopefully) and continue to work GW> together make it better, on-the-fly. Thats great! And sorry to be a bother with just loads of questions. -- Rasmus Kaj --+-- rasmus@kaj.se --+-- http://www.stacken.kth.se/~kaj/ För övrigt anser jag att det var något förhastat att bränna Kartago
Sounds cool ... Would "foo => bar; baz +=> bar;" mean the same thing as "foo + baz => bar;" then?
close: "baz +=> bar;" is the same as "bar + baz => bar".
Is there any example code (or even documentation) for this?
Not really. (Uh, what's documentation again?) There are some test cases - mostly for unit testing that doesn't do much else. "cvs update -d" should get the "v2/test" and the 100+ test code segments. Phil (mostly) and I made these to "rigorously" test the language. However, since unit generators are still being re-imported, no sound can be synthesized yet (boo). Also, not all the grammar is finalized yet in these files, and we as a group/community will continue to evolve the language. Documentation - the good news is that Adam Tindale and others has been working hard to put together bona-fide docs for ChucK. The bad news, well there is no bad news really, for once.
GW> The import system is the bottle neck right now. Further hacking GW> depends on this. Once it's done, then C/C++ code can be imported GW> less stupidly than before, and the portal to massive hacking will GW> be opened (yikes).
Huh? Import from what to where?
C/C++ to ChucK. classes written in ChucK can instantiate imported objects, and even extend them.
GW> #------------------------------------------------------------------ GW> # by default, ChucK uses a pre-configured libsndfile... GW> # uncomment the next 3 lines to use libsndfile on your system GW> #------------------------------------------------------------------ GW> #FLAGS+= -D__CK_SNDFILE_NATIVE__ GW> #LIBS+= -lsndfile GW> #SF_OBJ=
Oups, sorry I didn't notice that!
Um, it might have been more helpful if we actually documented this somewhere other than the makefile itself... we are at fault.
Thats great! And sorry to be a bother with just loads of questions.
Good questions and of course no bother at all. This is chuck-dev, after all! Best, Ge!
participants (2)
-
Ge Wang
-
Rasmus Kaj