With issues of the readability of the Csound code being discussed recently,
and Josep's request for some documentation on the Csound internals, I
thought I would throw out a suggestion or two on the subject.

While looking through the code, I see a lot of names for functions and
globals which I find incomprehensible. Many of these names seem to be very
important parts of Csound.

Names which I don't understand the meaning of and which have recently been
discussed on this list include musmon, frsturnon, and the ominous looking
global O (which by the way can often look like a zero in the code).

If making Csound more accessible to new developers is really important, in
addition to writing some documentation for the code, perhaps some of these
identifiers should be changed so that their purpose is crystal clear.  (I
know it would be more of pain for CVSers, but maybe some of the source files
should be renamed also).  Part of the code docs then might be to point out
the important name changes to seasoned developers.

As an example of identifiers which are very well named, I would suggest the
Csound API functions.

Just $0.02 from an "outsider."

Anthony Kozar
anthony.kozar@utoledo.edu

Completely agree.
I would really love to understand the code a bit...

Josep M Comajuncosas

-----Mensaje original-----
De: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu] En nombre de Anthony Kozar
Enviado el: lunes, 24 de noviembre de 2003 0:52
Para: Csound Developers Discussion List
Asunto: [CSOUND-DEV:3482] Names like Musmon and frsturnon

With issues of the readability of the Csound code being discussed
recently,
and Josep's request for some documentation on the Csound internals, I
thought I would throw out a suggestion or two on the subject.

While looking through the code, I see a lot of names for functions and
globals which I find incomprehensible. Many of these names seem to be
very
important parts of Csound.

Names which I don't understand the meaning of and which have recently
been
discussed on this list include musmon, frsturnon, and the ominous
looking
global O (which by the way can often look like a zero in the code).

If making Csound more accessible to new developers is really important,
in
addition to writing some documentation for the code, perhaps some of
these
identifiers should be changed so that their purpose is crystal clear.
(I
know it would be more of pain for CVSers, but maybe some of the source
files
should be renamed also).  Part of the code docs then might be to point
out
the important name changes to seasoned developers.

As an example of identifiers which are very well named, I would suggest
the
Csound API functions.

Just $0.02 from an "outsider."

Anthony Kozar
anthony.kozar@utoledo.edu

I revamped csound/configure.ac following leasons learned from the
strace package.  The new autoconf script uses autoheader to generate
config.h.in, and the resulting config.h is only included by the new
file autoheader.h.  This file adds some definitions derived from the
config.h definitions that do not seem to me should appear in
configure.ac.  Files such as cs.h and sysdep.h include autoheader.h.

The resulting system is known to automatically build systems on Linux
and Windows using MSys.  One can build libcsound as a shared library
on Linux, but something goes wrong on Windows.  Michael, I added
PUBLIC declarations as you directed, but something else must be wrong.
I'm not sure what to do next.

The new configure.ac file should not be very hard to incorporate into
csound5 once the problem with shared libraries on Windows is
discovered.  I did not change any of the checks for typedefs,
structures, or library functions, on the assumption they were
carefully selected to meet csound5's needs.

To give the new configuration scripts a spin, update your csound
module, and on a RH9 system, type "autoreconf -i".

John

Hi John R,

I took a quick test and look at the autobuild system and it's nice what
you've done.  I ran into a problem with widgets.cpp, but don't have time
to look into as I'm running off to work now.  I'll be trying this stuff
out on win2k at work.

Thanks!
steven


> To give the new configuration scripts a spin, update your csound
> module, and on a RH9 system, type "autoreconf -i".
> 
> John
> 
> 

You lucky...I'm also use to do some Csound stuff at work ;-)
Josep M Comajuncosas


-----Mensaje original-----
De: owner-csound-dev@eartha.mills.edu
[mailto:owner-csound-dev@eartha.mills.edu] En nombre de stevenyi
Enviado el: lunes, 24 de noviembre de 2003 18:27
Para: Csound Developers Discussion List
Asunto: [CSOUND-DEV:3491] Re: csound/configure.ac revamped

I'll be trying this stuff
out on win2k at work.

Thanks!
steven
 

stevenyi  writes:

> Hi John R,
> 
> I took a quick test and look at the autobuild system and it's nice what
> you've done.  I ran into a problem with widgets.cpp, but don't have time
> to look into as I'm running off to work now.

The only change I made to widgets.cpp is to have it include
autoheader.h as its first action.  If your copy of widgets.cpp does
not mention autoheader.h, do a cvs update to get the latest version.

John

Hi John,

I'm pretty sure I have the latest widgets.cpp as I was doing diffs this 
morning with the other revisions to see if anything else had changed 
beside the autoheader.h.  My last guess was that it was something to do 
with the Makefile generated, as it didn't seem to have all of the flags 
there (i.e. -fno-exceptions -fno-rtti) (have to confirm this, didn't 
have a chance to spend too much time with this.  Sorry for not being 
more helpful in this; I should have some time tonight to work on 
figuring what's going on).

steven

John D. Ramsdell wrote:

>stevenyi  writes:
>
>  
>
>>Hi John R,
>>
>>I took a quick test and look at the autobuild system and it's nice what
>>you've done.  I ran into a problem with widgets.cpp, but don't have time
>>to look into as I'm running off to work now.
>>    
>>
>
>The only change I made to widgets.cpp is to have it include
>autoheader.h as its first action.  If your copy of widgets.cpp does
>not mention autoheader.h, do a cvs update to get the latest version.
>
>John
>
>
>
>  
>

Hi John R,

I spent the past hour trying to figure out what's going on with
widgets.cpp.  All I've ascertained so far is that I can compile the same
widgets.cpp with Makefile.lnx but can not with the autogenerated
Makefile.  So it seems that it's some kind of configuration issue,
though what it is I'm not sure yet.

steven


On Tue, 2003-11-25 at 11:49, steven wrote:
> Hi John,
> 
> I'm pretty sure I have the latest widgets.cpp as I was doing diffs this 
> morning with the other revisions to see if anything else had changed 
> beside the autoheader.h.  My last guess was that it was something to do 
> with the Makefile generated, as it didn't seem to have all of the flags 
> there (i.e. -fno-exceptions -fno-rtti) (have to confirm this, didn't 
> have a chance to spend too much time with this.  Sorry for not being 
> more helpful in this; I should have some time tonight to work on 
> figuring what's going on).
> 
> steven
> 
> John D. Ramsdell wrote:
> 
> >stevenyi  writes:
> >
> >  
> >
> >>Hi John R,
> >>
> >>I took a quick test and look at the autobuild system and it's nice what
> >>you've done.  I ran into a problem with widgets.cpp, but don't have time
> >>to look into as I'm running off to work now.
> >>    
> >>
> >
> >The only change I made to widgets.cpp is to have it include
> >autoheader.h as its first action.  If your copy of widgets.cpp does
> >not mention autoheader.h, do a cvs update to get the latest version.
> >
> >John
> >
> >
> >
> >  
> >
> 
> 

Does anyone object to me adding a csound directory into the csound
module, and moving all the files that make up a traditional Csound
source distibution into it?  In addition to reducing the clutter, this
change would facilitate adding automake support to CsoundVST.

John

My first attempt to send this not was rejected because the listproc
thought it was a command!  Anyway, here is try number two.

When building shared libraries using libtool with MSYS, the transcript
reports that the shared library was not build because it contains
undefined symbols.  Perhaps the list of source files used to build the
library given in Makefile.am is too big.

John

From: listproc@ella.mills.edu
Subject: list CSOUND-DEV: List Message Rejected
To: ramsdell@mitre.org
Date: Wed, 26 Nov 2003 01:17:28 PST
Reply-To: listproc@ella.mills.edu

Dear ramsdell@mitre.org:

Your recent message to the CSOUND-DEV list has been
rejected for the following reason:

The following string matched one of ListProc's command words:

   REPORTS THAT THE SHARED LIBRARY WAS NOT BUILD BECAUSE IT CONTAINS

Hence, your message looks like it was intended for the ListProc server,
rather than for a particular list.  If you are trying to send server
commands, please send them to listproc@eartha.mills.edu.  If you 
were trying to send a message to the list, please rephrase your message
so the command word does not appear at the beginning of a message line.

....

As requested, I've placed the wxCsound sources in the csound CVS
repository.  The module wxcsound also contains a snapshot of the
csound sources, which are built and installed by the wxCsound system.
The wxCsound configure.ac file uses AC_CONFIG_SUBDIRS to configure the
csound package.

John ffitch, I'd like to make a wxCsound distribution available via
SF's file release mechanism, but I currently do not have permission to
do so.  Please give me file release privileges.

John

steven  writes:

> Hi John,
> 
> I'm pretty sure I have the latest widgets.cpp as I was doing diffs
> this morning with the other revisions to see if anything else had
> changed beside the autoheader.h.  My last guess was that it was
> something to do with the Makefile generated, as it didn't seem to
> have all of the flags there (i.e. -fno-exceptions -fno-rtti) ...

I left these flags out of csound/configure.ac because they were left
out of csound5/configure.in, but I notice they are specified in
csound5/Makefile.in.  As a result, I changed csound/Makefile.am to
include these flags when compiling C++ sources for the library.

John