How does Feb 1, as suggested by Michael, sound as a release date?


Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "Victor" == Victor Lazzarini  writes:

 Victor> How does Feb 1, as suggested by Michael, sound as a release date?

I would be happy with this.  I think the system is ready now, and the
documentation is better than any previous version had.  Sure we could
produce better material, but we need to get this officially out.  Can
we move to preparing release material?

==John ffitch


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote on 1/25/06 1:39 AM:

>>>>>> "Victor" == Victor Lazzarini  writes:
> 
> Victor> How does Feb 1, as suggested by Michael, sound as a release date?
> 
> I would be happy with this.  I think the system is ready now, and the
> documentation is better than any previous version had.  Sure we could
> produce better material, but we need to get this officially out.  Can
> we move to preparing release material?


Feb 1st sounds great to me!

However, would anyone mind if I check in the following minor changes to
mixer.cpp, pythonopcodes.c, and sysdep.h so that I can continue to compile
on MacOS 9?  The change to mixer.cpp is a simple <> versus "" issue.  The
changes to the other two files are #ifdef-ed for MacOS 9 only and therefore
should not cause any problems for anyone else.

Sorry that I have not done this sooner.  (Unfortunately, changing sysdep.h
will cause nearly all object files to be out-of-date for everyone else ...)


Index: csound5/Opcodes/mixer.cpp
===================================================================
RCS file: /cvsroot/csound/csound5/Opcodes/mixer.cpp,v
retrieving revision 1.12
diff -r1.12 mixer.cpp
1c1
< #include 
---
> #include "OpcodeBase.hpp"


Index: csound5/Opcodes/py/pythonopcodes.c
===================================================================
RCS file: /cvsroot/csound/csound5/Opcodes/py/pythonopcodes.c,v
retrieving revision 1.15
diff -r1.15 pythonopcodes.c
22a23,25
> #ifdef mac_classic
> #  include 
> #endif
156a160,162
> #ifdef mac_classic
>       PyMac_Initialize();
> #else
157a164
> #endif


Index: csound5/H/sysdep.h
===================================================================
RCS file: /cvsroot/csound/csound5/H/sysdep.h,v
retrieving revision 1.36
diff -r1.36 sysdep.h
113c113,116
< #  include 
---
> /* #  define mills_macintosh  DEFINE THIS to COMPILE the Mills "Perf" Version
*/
> #  ifndef  USE_GUSI2
> #    include 
> #  endif
118a122
>    extern  off_t lseek(int, off_t, int);
161a166,170
> #ifdef USE_GUSI2  /* When compiling with GUSI on MacOS 9 (for Python),  */
>                   /* all of the other integer types are already defined */
>   typedef int64_t           int_least64_t;
>   typedef uint64_t          uint_least64_t;
> #else
184a194
> #endif /* USE_GUSI2 */



Anthony Kozar
anthonykozar AT sbcglobal DOT net



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Those patches look OK to me -- the first one looks like a bug at present.
==John ffitch


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Thanks to Istvan for checking in my changes before I could get to it :)

I updated the ChangeLog as well, and I put the sysdep.h changes for
including stdint.h back to the way I had them.  I think that it may be
necessary to do the USE_GUSI2 check first (before HAVE_STDINT_H) because
when I am compiling the Python material for Csound, there are two stdint.h
files that get included in my system.  One is from the compiler and the
other is from the GUSI package that Python requires.

The #ifdefs I put in sysdep.h are so that only the GUSI one gets included
when compiling Python opcodes and interface.  But when I compile CsoundLib
it needs to be the other way.  So please leave this alone for now.  Thanks.

Anthony Kozar
anthonykozar AT sbcglobal DOT net


Anthony Kozar wrote on 1/25/06 2:02 AM:

> However, would anyone mind if I check in the following minor changes to
> mixer.cpp, pythonopcodes.c, and sysdep.h so that I can continue to compile on
> MacOS 9?  The change to mixer.cpp is a simple <> versus "" issue.  The changes
> to the other two files are #ifdef-ed for MacOS 9 only and therefore should not
> cause any problems for anyone else.



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan Varga wrote on 1/25/06 2:58 PM:

> How about these ?
> 
> @@ -109,16 +109,19 @@
> #endif
> 
> #if defined(macintosh)
> #  define mac_classic   /* All Mac Compiles Before OSX, including Carbon */
> +   /* define mills_macintosh in your prefix file
> +      to compile the Mills "Perf" version */
> #  ifndef  USE_GUSI2
> #    include 
> #  endif
> #  define  O_NDELAY (0)
> #  define  DIRSEP ':'
> #elif defined(SYMANTEC)
> #  include      /* for open() etc protos on mac */
> #  define  DIRSEP ':'
> +   extern  off_t lseek(int, off_t, int);
> #else
> 
> Was not mills_macintosh removed earlier ?

It was mostly removed.  There is still some usage of that macro in
linevent.c, and I have not decided whether to replace those with mac_classic
or not.  If I compile Csound with MPW (a shell-like environment) then the
mills_macintosh #ifdefs may still be useful.

Regardless, mills_macintosh is not actually being defined here.  This is
simply a comment indicating where it used to be defined and that the correct
place to define it now is in a prefix header (the Mac equivalent of the -D
compiler flag) which is what I am doing.  Please consider this necessary
documentation for now.

> Also, where is lseek() used ? The only place I seem to find it is in
> Engine/envvar.c but there is already an lseek() declaration there for
> SYMANTEC; I do not really like the idea of declaring system functions
> instead of using the appropriate header, and prefer minimizing the use
> of such declarations.

I added this back because I was not sure if removing it would "break"
compiling with the SYMANTEC compiler.  You are correct though, it looks as
though it is no longer needed in sysdep.h.  (lseek() used to be used in a
lot more places I think).

I have noticed that there are still a lot of SYMANTEC macros throughout the
code.  Someone please correct me if I am wrong, but I believe that SYMANTEC
was only used on 68k Macs with System 6 & 7 when compiling with Think C
(i.e. before Matt Ingalls took over Mac development of Csound).  If this is
true, then all of the SYMANTEC-only code can probably be removed.

I would prefer to do this myself though so that I can make sure that none of
the code is still relevant to my MacOS 9 efforts with CodeWarrior.  I also
think that this can wait until after the 5.0 release for now.

Thanks.

Anthony Kozar
anthonykozar AT sbcglobal DOT net



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, I am responsible for the introduction of the SYMANTEC thread, as
that was the compiler I used on OS7.  I thought it had been removed.
==John ffitch


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Does "preparing release material" mean that we should begin compiling
binaries, or do you mean writing other materials such as Release Notes or a
ReadMe?

I would like to do a clean checkout of the release sources -- can we tag
everything when CVS is in order?

John, will you be making a release notes file with a list of significant
changes or would you like someone else to do so?  I volunteer to do it --
just be forewarned that I tend to write with --verbose on.

:)

Anthony Kozar
anthonykozar AT sbcglobal DOT net


jpff@codemist.co.uk wrote on 1/25/06 1:39 AM:

> Victor> How does Feb 1, as suggested by Michael, sound as a release date?
> 
> I would be happy with this.  I think the system is ready now, and the
> documentation is better than any previous version had.  Sure we could
> produce better material, but we need to get this officially out.  Can
> we move to preparing release material?



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net