Is there any possibility of getting anonymous access to the princeton cvs? Should such things go via the sf account instead? We want to keep the local cvs @ stacken up to date with whatever is committed at your place so that our hacking won't start from the release version and then discover that it's badly out of sync with what's in the cvs (as we just discovered... =) Oh, and, we have still not managed to get a decent windows build environment up and running; but we have verified build on Free/OpenBSD, Linux (debian & redhat) and OSX. Should we commit and test or wait and then commit? Best wishes, the Stacken hack group! =) -- Mikael Johansson | To see the world in a grain of sand mikael@johanssons.org | And heaven in a wild flower http://www.mikael.johanssons.org | To hold infinity in the palm of your hand | And eternity for an hour
From: Mikael Johansson
Is there any possibility of getting anonymous access to the princeton cvs? Should such things go via the sf account instead?
We want to keep the local cvs @ stacken up to date with whatever is committed at your place so that our hacking won't start from the release version and then discover that it's badly out of sync with what's in the cvs (as we just discovered... =)
Mikael did a checkout that we tossed into our cvs. I have just ported much of our stuff into that cvs version. This includes the basic Autoconf/Automake stuff that Hans with a little help from me and Mikael have done. I tossed together a man-page aswell. I expect that most if not all of the diffs will be more or less in sync during the weekend. I have been working on the chuck/src directory where as I have noticed that there is a chuck/v2 directory as well. Hans tossed together a none-audio driver which seems to work. I am considering applying more automagic to the autoconf stuff as things progresses. Currently we do stuff with --with-audio=alsa etc. but I want to remove the need for it so it just discovers what is there, but with the manual force still in place if you wish for it. In the long term should we commit straight into the main repository, but let's first get the aggregate stuff into par with your latest cvs and then we figure out how to best merge it.
Oh, and, we have still not managed to get a decent windows build environment up and running; but we have verified build on Free/OpenBSD, Linux (debian & redhat) and OSX. Should we commit and test or wait and then commit?
To clarify on the Windows comment. A tired mind (mine that is) was unable to have the ./configure script to get pass the GCC tests in MSYS/MINGW. It fails to compile the simple test-program. A less tired mind may solve this. I rarely find a need to use the MSYS/MINGW environment so that could be a reason, but autoconf/configure should work in there.
Best wishes, the Stacken hack group! =)
Best wishes, Magnus - another Stacken Chuck-hacker
I have been working on the chuck/src directory where as I have noticed that there is a chuck/v2 directory as well.
the v2 is the rewrite, and is currently rather uncompilable.
Hans tossed together a none-audio driver which seems to work.
cool. does this behave the same as --silent, but is independent of the audio system at compile-time?
I am considering applying more automagic to the autoconf stuff as things progresses. Currently we do stuff with --with-audio=alsa etc. but I want to remove the need for it so it just discovers what is there, but with the manual force still in place if you wish for it.
it seems having manual force optional is always good idea... how does everyone feel about this?
To clarify on the Windows comment. A tired mind (mine that is) was unable to have the ./configure script to get pass the GCC tests in MSYS/MINGW. It fails to compile the simple test-program. A less tired mind may solve this. I rarely find a need to use the MSYS/MINGW environment so that could be a reason, but autoconf/configure should work in there.
Thank you very much for all you guys are doing! Best, Ge!
From: Ge Wang
I have been working on the chuck/src directory where as I have noticed that there is a chuck/v2 directory as well.
the v2 is the rewrite, and is currently rather uncompilable.
I'll see what I can do about it.
Hans tossed together a none-audio driver which seems to work.
cool. does this behave the same as --silent, but is independent of the audio system at compile-time?
Exactly. If you are going to run chuck on boxes with no real-time audio capablity or with unsupported audio, then you need this, or you will not be able to compile as it looks right now. The none audio driver solves this. In one of our imagined applications we use small formfactor cards to do sequencing, MIDI-interfacing etc. and using Ethernet/IP to interface to the other boxes. Having no need for the audio in the current system requires it for no real use.
I am considering applying more automagic to the autoconf stuff as things progresses. Currently we do stuff with --with-audio=alsa etc. but I want to remove the need for it so it just discovers what is there, but with the manual force still in place if you wish for it.
it seems having manual force optional is always good idea... how does everyone feel about this?
Actually, as long as the automagic solves 99% of the problems and there is easy ways to override the automagic on key parameters (which is easy), then you will have it. The automagic is tossed in for it to become more of straight-from-the-box kind of deal. A "./configure; make install" should be all that people have to worry about normally, with the possible addition of a --prefix as usual.
To clarify on the Windows comment. A tired mind (mine that is) was unable to have the ./configure script to get pass the GCC tests in MSYS/MINGW. It fails to compile the simple test-program. A less tired mind may solve this. I rarely find a need to use the MSYS/MINGW environment so that could be a reason, but autoconf/configure should work in there.
Thank you very much for all you guys are doing!
Well, we are using chuck, see the oppertunity to fix things and hack away, as we are doing by habit anyway! Cheers, Magnus
From: Ge Wang
the v2 is the rewrite, and is currently rather uncompilable.
I'll see what I can do about it.
Don't worry about this yet - it isn't supposed to work, parts of the code have been replaced with new interfaces. Sorry about the confusion.
OK. I hope you are moving all that stuff over to the src directory when it is time. Do you want a diff of what we have now? There is a few additional hacks which I think we better diff in separately so they could be considered by themselfs. The autoconf/automake stuff does these changes: 1) Additional files. Autoconf and Automake requires additional files and also requires a certain infrastructure in files (existens of NEWS, INSTALL, README, AUTHORS, ChangeLog etc. even if one can cheat-out but it's recommended and not very hard anyway).' The traditional way of passing parameters is by using config.h (distributed as config.h.in) which is what we also use. 2) Minimal change of files. As a minimum, the config.h should be included wherever it may be needed. 3) Adaptation of configured parts. Instead of the different make-files for different targets Hans setup a common makefile, but then by using definitions in config.h (originating from the configure script naturally) will the content of unused audio and midi drivers be ifdef:ed out. In a similar sense is different placements of headers, different interfaces etc. ifdefed in the same fashion. We have seen stuff that happends in the current files which should be decided by the configue script rather than in ifdef logic. 4) Added stuff. I have added a man-page. Basically what was on the web "manesque", but adapted. Automake magic installes it in the propper place. Cheers, Magnus
Is there any possibility of getting anonymous access to the princeton cvs? Should such things go via the sf account instead?
cvs -d :ext:anon-chuck@cvs.cs.princeton.edu:/cvs checkout chuck_dev password: leave blank
Oh, and, we have still not managed to get a decent windows build environment up and running; but we have verified build on Free/OpenBSD, Linux (debian & redhat) and OSX. Should we commit and test or wait and then commit?
we should coordinate this with v2. If you like, you can commit under a new directory in chuck_dev/build or chuck_dev/conf or another name of your choosing.
Best wishes, the Stacken hack group! =)
You guys rock!! Best, Ge!
From: Ge Wang
Is there any possibility of getting anonymous access to the princeton cvs? Should such things go via the sf account instead?
cvs -d :ext:anon-chuck@cvs.cs.princeton.edu:/cvs checkout chuck_dev password: leave blank
We attempted something similar last evening, but failed. We used Mikaels checkout instead. The above works.
Oh, and, we have still not managed to get a decent windows build environment up and running; but we have verified build on Free/OpenBSD, Linux (debian & redhat) and OSX. Should we commit and test or wait and then commit?
we should coordinate this with v2. If you like, you can commit under a new directory in chuck_dev/build or chuck_dev/conf or another name of your choosing.
The thing is, things needs to be distributed and several, if not all, .cpp files needs patching. Only a few things go separately, and thus must be put in the top directory.
Best wishes, the Stacken hack group! =)
You guys rock!!
Not yeat, we are working on it! ;O) Cheers, Magnus
participants (3)
-
Ge Wang -
Magnus Danielson -
Mikael Johansson