Of course, what I really mean by "gone" is "hidden" - so that the average 
user does not see these "warnings" and thus become confused by them. (I have 
to assume that the messages are useful to *someone* or they wouldn't be 
there; so they should be available as specifically needed.)

Indeed it is only the most sophisticated user who can properly interpret the 
significance of these messages - beyond a general "it seems something may be 
missing." If an install goes as it should go, nothing needed by the average 
user *should* be missing - and the user's response would naturally be, "What 
did I do wrong?"

Furthermore, the message does *not* tell a user what *particular* opcode may 
not be available. Different opcodes are resident in different files, and it 
takes some digging to determine where a given opcode is located. (I 
personally think the groupings could be far better arranged, and their 
titles be made more self-descriptive. However, I realize that this is not 
likely a trivial task.)

I'm very glad that johnff has made the indicated change to the -m flag. This 
seems exactly what is needed.

As Rick and others have indicated, user friendliness to the "average Joe" 
needs be a top priority for all - and especially, I fervently hope, for our 
much appreciated developers. You can count on me periodically to be shouting 
this message from the rooftop (though I'll strive not to be overly 
strident).

Art Hunkins

----- Original Message ----- 
From: "Anthony Kozar" 
To: 
Sent: Sunday, March 16, 2008 12:47 PM
Subject: [Csnd] Re: Csound 5.08Beta


> Art Hunkins wrote on 3/15/08 2:59 PM:
>
>> What I'd like is for these messages to be *gone*.
>
> The messages are necessary for understanding why a particular opcode may 
> not
> be available.
>
>> Actually, what would likely satisfy most users is for the WARNING 
>> messages
>> (and WARNING is a good enough title for me) - and much of the rest of the
>> default initial messages? -  to be subject to a command-line flag that 
>> would
>> turn them off by default.
>
> John ff. already added some experimental code that makes the plugin 
> warnings
> subject to the -m flag.  It appears that this code will not be part of the
> 5.08 release though.  I would expect it to be finished for 5.09.
>
> Anthony Kozar
> mailing-lists-1001 AT anthonykozar DOT net
> http://anthonykozar.net/
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

I would have thought that anyone who's compiling code regularly would  
understand the difference between a warning and an error.
The warning messages can be useful, if they've got useful info. in  
them. And being able to turn them off can be helpful too.
It has always been my understanding that the average user would  
install an already compiled version.
I do wish the compilation process was a little easier than it is though.
Is there some way that the root directory can be made less daunting,  
say by factoring?
There seems to a few files in that dir that look 'outa date'.
Of course for those with experience of building this a worry. But it  
does make the learning curve a bit steep for those wanting to become  
average+.

D.

On 17/03/2008, at 5:11 AM, Art Hunkins wrote:

> Of course, what I really mean by "gone" is "hidden" - so that the  
> average user does not see these "warnings" and thus become confused  
> by them. (I have to assume that the messages are useful to *someone*  
> or they wouldn't be there; so they should be available as  
> specifically needed.
...
> As Rick and others have indicated, user friendliness to the "average  
> Joe" needs be a top priority for all - and especially, I fervently  
> hope, for our much appreciated developers. You can count on me  
> periodically to be shouting this message from the rooftop (though  
> I'll strive not to be overly strident).

David,

It's all about the students, new users, the children of the world  
using the XO laptops.  All my Berklee kids....
All the future Csounders.

They get worried and confused by WARNINGS!!!!

Messages that provide useful info - are a good thing.  Messages that  
are merely informative - but come across as something dire - are not.

To the beginner - it seems like something MAJOR is wrong....

-dB

On Mar 16, 2008, at 3:41 PM, DavidW wrote:

> I would have thought that anyone who's compiling code regularly  
> would understand the difference between a warning and an error.
> The warning messages can be useful, if they've got useful info. in  
> them. And being able to turn them off can be helpful too.
> It has always been my understanding that the average user would  
> install an already compiled version.
> I do wish the compilation process was a little easier than it is  
> though.
> Is there some way that the root directory can be made less  
> daunting, say by factoring?
> There seems to a few files in that dir that look 'outa date'.
> Of course for those with experience of building this a worry. But  
> it does make the learning curve a bit steep for those wanting to  
> become average+.
>
> D.
>
> On 17/03/2008, at 5:11 AM, Art Hunkins wrote:
>
>> Of course, what I really mean by "gone" is "hidden" - so that the  
>> average user does not see these "warnings" and thus become  
>> confused by them. (I have to assume that the messages are useful  
>> to *someone* or they wouldn't be there; so they should be  
>> available as specifically needed.
> ...
>> As Rick and others have indicated, user friendliness to the  
>> "average Joe" needs be a top priority for all - and especially, I  
>> fervently hope, for our much appreciated developers. You can count  
>> on me periodically to be shouting this message from the rooftop  
>> (though I'll strive not to be overly strident).
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

I do understand that there is a learning curve on how to interpret the  
voluminous guff that is emitted by _most_ sw compilations.
I guess that's my point. Surely it is better to teach our students  
which ones to be worried about rather than protect them from the real  
world.
What happens when they pass a Warning! sign on the road? Turn around  
or proceed cautiously?
Still, I'm not too fussed. I like to see the warnings, 'cause often it  
reminds me what and what-not is being being compiled in.
I'm yet to produce a successful csnd API build on OSX 10.5.2, so I'm  
still learning.
For my $, there are other ways to improve/ simplify the build process:

Personally I doubt the efficiency of a single SConstruct file for all  
platforms. Not only is is harder to read, I bet it's harder to maintain.
But I realise I might be out on a limb on this one.

The contents of the INSTALL file could be improved.
the last line
http://csounds.com/manual/html/buildingCsound.html
                                                           ^
produces a 404 error, because it should be
http://csounds.com/manual/html/BuildingCsound.html
                                                           ^
which I remember notifying this group about this at least a year ago.
I looked at the bug-trackers but it's not clear how active that method  
of reporting is.
Is that the most appropriate place to log these things these days?

And if you look at the BuildingCsound.html page from the point of view  
of a beginner, it's daunting.
It's probably accurate, but I would suggest that it be rewritten to  
accommodate that way it's likely to be used by beginners: from a  
platform-specific POV.

Another thing I think would improve the readability of the code is to  
turn off the execute bit on all files which are not executable.
I bet I'm not alone in aliasing  ls='ls -FGkvx' or something similar.  
Which colour-codes file permissions.
INSTALL with the execute bit on turns it into a verb, which it is not;  
it takes the place of a README file.

It's not clear what the state the CVS download directory is in; it  
_looks_ like a it might have files lying around from some arbitrary  
build.
So it's natural to want to do a cleanup before beginning. cleanup.sh  
look promising but contains no comments within it about it's use.

Most sw I build these days builds into a platform-targeted build  
directory (in a 'builds' directory in the root).
Maybe that's not appropriate in this case, but it would certainly  
makes the root directory less cluttered.

None of this is meant as a criticism - I appreciate everyone's busy -  
simply as suggestions.

D.


On 17/03/2008, at 6:55 AM, Dr. Richard Boulanger wrote:

> David,
>
> It's all about the students, new users, the children of the world  
> using the XO laptops.  All my Berklee kids....
> All the future Csounders.
>
> They get worried and confused by WARNINGS!!!!
>
> Messages that provide useful info - are a good thing.  Messages that  
> are merely informative - but come across as something dire - are not.
>
> To the beginner - it seems like something MAJOR is wrong....
>
> -dB
>
> On Mar 16, 2008, at 3:41 PM, DavidW wrote:
>
>> I would have thought that anyone who's compiling code regularly  
>> would understand the difference between a warning and an error.
>> The warning messages can be useful, if they've got useful info. in  
>> them. And being able to turn them off can be helpful too.
>> It has always been my understanding that the average user would  
>> install an already compiled version.
>> I do wish the compilation process was a little easier than it is  
>> though.
>> Is there some way that the root directory can be made less  
>> daunting, say by factoring?
>> There seems to a few files in that dir that look 'outa date'.
>> Of course for those with experience of building this a worry. But  
>> it does make the learning curve a bit steep for those wanting to  
>> become average+.
>>
>> D.
>>
>> On 17/03/2008, at 5:11 AM, Art Hunkins wrote:
>>
>>> Of course, what I really mean by "gone" is "hidden" - so that the  
>>> average user does not see these "warnings" and thus become  
>>> confused by them. (I have to assume that the messages are useful  
>>> to *someone* or they wouldn't be there; so they should be  
>>> available as specifically needed.
>> ...
>>> As Rick and others have indicated, user friendliness to the  
>>> "average Joe" needs be a top priority for all - and especially, I  
>>> fervently hope, for our much appreciated developers. You can count  
>>> on me periodically to be shouting this message from the rooftop  
>>> (though I'll strive not to be overly strident).
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg
- MARCS Auditory Laboratories: marcs.uws.edu.au

Great suggestions David.  We do need to make building from CVS  
clearer for intermediates and advanced users as well... and your
suggestions would help us there too!.

Thanks.

-dB

On Mar 16, 2008, at 6:17 PM, DavidW wrote:

> I do understand that there is a learning curve on how to interpret  
> the voluminous guff that is emitted by _most_ sw compilations.
> I guess that's my point. Surely it is better to teach our students  
> which ones to be worried about rather than protect them from the  
> real world.
> What happens when they pass a Warning! sign on the road? Turn  
> around or proceed cautiously?
> Still, I'm not too fussed. I like to see the warnings, 'cause often  
> it reminds me what and what-not is being being compiled in.
> I'm yet to produce a successful csnd API build on OSX 10.5.2, so  
> I'm still learning.
> For my $, there are other ways to improve/ simplify the build process:
>
> Personally I doubt the efficiency of a single SConstruct file for  
> all platforms. Not only is is harder to read, I bet it's harder to  
> maintain.
> But I realise I might be out on a limb on this one.
>
> The contents of the INSTALL file could be improved.
> the last line
> http://csounds.com/manual/html/buildingCsound.html
>                                                           ^
> produces a 404 error, because it should be
> http://csounds.com/manual/html/BuildingCsound.html
>                                                           ^
> which I remember notifying this group about this at least a year ago.
> I looked at the bug-trackers but it's not clear how active that  
> method of reporting is.
> Is that the most appropriate place to log these things these days?
>
> And if you look at the BuildingCsound.html page from the point of  
> view of a beginner, it's daunting.
> It's probably accurate, but I would suggest that it be rewritten to  
> accommodate that way it's likely to be used by beginners: from a  
> platform-specific POV.
>
> Another thing I think would improve the readability of the code is  
> to turn off the execute bit on all files which are not executable.
> I bet I'm not alone in aliasing  ls='ls -FGkvx' or something  
> similar. Which colour-codes file permissions.
> INSTALL with the execute bit on turns it into a verb, which it is  
> not; it takes the place of a README file.
>
> It's not clear what the state the CVS download directory is in; it  
> _looks_ like a it might have files lying around from some arbitrary  
> build.
> So it's natural to want to do a cleanup before beginning.  
> cleanup.sh look promising but contains no comments within it about  
> it's use.
>
> Most sw I build these days builds into a platform-targeted build  
> directory (in a 'builds' directory in the root).
> Maybe that's not appropriate in this case, but it would certainly  
> makes the root directory less cluttered.
>
> None of this is meant as a criticism - I appreciate everyone's busy  
> - simply as suggestions.
>
> D.
>
>
> On 17/03/2008, at 6:55 AM, Dr. Richard Boulanger wrote:
>
>> David,
>>
>> It's all about the students, new users, the children of the world  
>> using the XO laptops.  All my Berklee kids....
>> All the future Csounders.
>>
>> They get worried and confused by WARNINGS!!!!
>>
>> Messages that provide useful info - are a good thing.  Messages  
>> that are merely informative - but come across as something dire -  
>> are not.
>>
>> To the beginner - it seems like something MAJOR is wrong....
>>
>> -dB
>>
>> On Mar 16, 2008, at 3:41 PM, DavidW wrote:
>>
>>> I would have thought that anyone who's compiling code regularly  
>>> would understand the difference between a warning and an error.
>>> The warning messages can be useful, if they've got useful info.  
>>> in them. And being able to turn them off can be helpful too.
>>> It has always been my understanding that the average user would  
>>> install an already compiled version.
>>> I do wish the compilation process was a little easier than it is  
>>> though.
>>> Is there some way that the root directory can be made less  
>>> daunting, say by factoring?
>>> There seems to a few files in that dir that look 'outa date'.
>>> Of course for those with experience of building this a worry. But  
>>> it does make the learning curve a bit steep for those wanting to  
>>> become average+.
>>>
>>> D.
>>>
>>> On 17/03/2008, at 5:11 AM, Art Hunkins wrote:
>>>
>>>> Of course, what I really mean by "gone" is "hidden" - so that  
>>>> the average user does not see these "warnings" and thus become  
>>>> confused by them. (I have to assume that the messages are useful  
>>>> to *someone* or they wouldn't be there; so they should be  
>>>> available as specifically needed.
>>> ...
>>>> As Rick and others have indicated, user friendliness to the  
>>>> "average Joe" needs be a top priority for all - and especially,  
>>>> I fervently hope, for our much appreciated developers. You can  
>>>> count on me periodically to be shouting this message from the  
>>>> rooftop (though I'll strive not to be overly strident).
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>>
>
> ________________________________________________
> David Worrall.
> - Experimental Polymedia:	www.avatar.com.au
> - Education for Financial Independence: www.mindthemarkets.com.au
> Australian research affiliations:
> - Capital Markets Cooperative Research Centre: www.cmcrc.com
> - Sonic Communications Research Group:	creative.canberra.edu.au/scrg
> - MARCS Auditory Laboratories: marcs.uws.edu.au
>
>
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"

Hi Andres,
On 17/03/2008, at 12:57 PM, Andres Cabrera wrote:

> Hi David,
>
> On Sun, Mar 16, 2008 at 5:17 PM, DavidW  wrote:
>
>> The contents of the INSTALL file could be improved. The last line
...
> Don't worry, this was fixed in cvs when you reported it. Simple fixes
> usually get attended.

Even _more_ of a worry not less , if it _was_ fixed, because I was  
quoting fom CVS of
/build-icl-release.bat/1.2/Sat Mar  8 18:49:32 2008//

i.e it must then have been .... unfixed :-)

>>  And if you look at the BuildingCsound.html page from the point of  
>> view
>> of a beginner, it's daunting.
>> It's probably accurate, but I would suggest that it be rewritten to
>> accommodate that way it's likely to be used by beginners: from a
>> platform-specific POV.
>>
>
> I agree that this section needs a lot of work. I would greatly
> appreciate if people can contribute to this. I will place anything I
> receive on this subject in the manual immediately, so consider this a
> call for proposals.
>
Basically I think it heeds separate sections for each platform.
I'll have a go at factoring it. For review.
Personally, I would take out
"If you wish to become a Csound developer, first obtain a SourceForge  
login, and then apply to John ffitch at the www.sourceforge.net/projects/csound 
   site, or through the Csound Mailing List." from this section. Has  
anyone ever applied - and gotten - developer status without first  
being a member of this list?


>>  Another thing I think would improve the readability of the code is  
>> to
>> turn off the execute bit on all files which are not executable.
>> I bet I'm not alone in aliasing  ls='ls -FGkvx' or something similar.
>> Which colour-codes file permissions.
>> INSTALL with the execute bit on turns it into a verb, which it is  
>> not;
>> it takes the place of a README file.
>
> I can do it, but don't know how... can you give me some pointers for
> doing this in cvs?
No, not in CVS. But other's might. Googling "CVS change file  
permissions" provides a menagerie of delights, especially for windows.
http://durak.org/sean/pubs/software/cvsbook/CVS-keeps-changing-file-permissions_003b-why-does-it-do-that_003f.html
seems to suggest that you can just enter the repository and do a chmod.
If that's the case, "chmod a-x" * will turn all the executbles off.   
Then turn on the ones that need to be.
But hey, I'm an SVNer.

ciao,
David

On 18/03/2008, at 1:01 AM, Andres Cabrera wrote:

> Hi,
> On Mon, Mar 17, 2008 at 12:32 AM, DavidW  wrote:
>>
>> Hi Andres,
>>
>> On 17/03/2008, at 12:57 PM, Andres Cabrera wrote:
>>
>> Even _more_ of a worry not less , if it _was_ fixed, because I was
>> quoting fom CVS of
>> /build-icl-release.bat/1.2/Sat Mar  8 18:49:32 2008//
>>
>> i.e it must then have been .... unfixed :-)
>>
>
> I'm not sure where you're looking, but it has in fact been fixed =)

well I just did a cvs update and in csound5/INSTALL
-rwxr-xr-x    1 root  wheel      628 29 Dec 07:08 INSTALL

It's last line still says
http://csounds.com/manual/html/buildingCsound.html
instead of
http://csounds.com/manual/html/BuildingCsound.html

Where are you looking? Maybe my CVS update command is wrong?
I'm using
%cvs -z3 update

ciao,
David



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Curiouser and curiouser.
I'm not sure it was a permissions thing as I was superuser doing the  
update.
Of course when I looked at the file in the repository, clearly it  
showed the update.
I deleted the file and then pulled it and the new version came down.
Makes me wonder about the state of my other files. I'll start with a  
fresh CVS I think.
Sorry for the silliness of this.

David.
On 18/03/2008, at 3:54 AM, Andres Cabrera wrote:

> That's odd, i don't think there's anything wrong with your cvs command
> (you may want to use -d to make sure new directories are checked
> out)... can you delete the file and check out again? Maybe a
> permissions issue?
>
> Cheers,
> Andrés
>
> On Mon, Mar 17, 2008 at 11:00 AM, DavidW  wrote:
>>
>> On 18/03/2008, at 1:01 AM, Andres Cabrera wrote:
>>
>>> Hi,
>>> On Mon, Mar 17, 2008 at 12:32 AM, DavidW  wrote:
>>>>
>>>> Hi Andres,
>>>>
>>>> On 17/03/2008, at 12:57 PM, Andres Cabrera wrote:
>>>>
>>>> Even _more_ of a worry not less , if it _was_ fixed, because I was
>>>> quoting fom CVS of
>>>> /build-icl-release.bat/1.2/Sat Mar  8 18:49:32 2008//
>>>>
>>>> i.e it must then have been .... unfixed :-)
>>>>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In my experience w. code build,  'BUILD' is distinguished frrom  
'INSTALL'
our INSTALL file has a para about INSTALLING precompiled binaries and  
the rest about how to build from these sources.
I suggest renaming this file README.txt  (or ReadMe.txt)

-----------

The file install.py has the comment on line 36:
print 'Csound5 Linux installer by Istvan Varga'

this file was last edited more than 12 months ago. Is it still in use?
If so, perhaps a name change is in order:
install_Istvan_Linux_Csound.py would better reflect what it actually  
says it does.

--------
David

On 18/03/2008, at 10:19 AM, DavidW wrote:

> Curiouser and curiouser.
> I'm not sure it was a permissions thing as I was superuser doing the
> update.
> Of course when I looked at the file in the repository, clearly it
> showed the update.
> I deleted the file and then pulled it and the new version came down.
> Makes me wonder about the state of my other files. I'll start with a
> fresh CVS I think.
> Sorry for the silliness of this.
>
> David.
> On 18/03/2008, at 3:54 AM, Andres Cabrera wrote:
>
>> That's odd, i don't think there's anything wrong with your cvs  
>> command
>> (you may want to use -d to make sure new directories are checked
>> out)... can you delete the file and check out again? Maybe a
>> permissions issue?
>>
>> Cheers,
>> Andrés
>>
>> On Mon, Mar 17, 2008 at 11:00 AM, DavidW  wrote:
>>>
>>> On 18/03/2008, at 1:01 AM, Andres Cabrera wrote:
>>>
>>>> Hi,
>>>> On Mon, Mar 17, 2008 at 12:32 AM, DavidW  wrote:
>>>>>
>>>>> Hi Andres,
>>>>>
>>>>> On 17/03/2008, at 12:57 PM, Andres Cabrera wrote:
>>>>>
>>>>> Even _more_ of a worry not less , if it _was_ fixed, because I was
>>>>> quoting fom CVS of
>>>>> /build-icl-release.bat/1.2/Sat Mar  8 18:49:32 2008//
>>>>>
>>>>> i.e it must then have been .... unfixed :-)
>>>>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg
- MARCS Auditory Laboratories: marcs.uws.edu.au




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net