> Is it correct that the default Scons build of Csound5 specifies the new
> parser?
>

Yes and no; it is built but the old parser is the default if release is
specified.


> If so, I think this is a major mistake, as the resultant Csound will not
> be backward compatible. At least, the new parser is not compatible with my
> realtime csd's. (I'm well aware that I can modify my csd, adding the
> --old-parser flag, but I shouldn't have to do that. And most users
> wouldn't *know* to do that. I'm reasonably knowledgeable, and had to ask.)

In my opinion getting th eparser up to speed is totally critical.  We are
asked for new language features, like lopps and arrays, and that is not
going to happen with the old parser.  Anyone building from source is in
mid release is playing with a beta system.  If you are not part of the
testing/developing then no one shoudl be building a non-release system


>
> IMHO, a default build configuration should never implement a feature that
> is not backward compatible.
>


Such as?  We need to identify bugs yes but maintaining compatability is a
large constraint on development

> Everyone knows I'm a Windows person, and normally wouldn't be affected by
> such largely "Linux issues." However, I am involved with the Fedora-based
> Sugar-on-a-Stick project. A new release is about to come out, and Csound
> has been built with default Scons options, resulting in its being
> incompatible with the Activities I've written, as well as with all
> previous Sugar-on-a-Stick releases. This is "a problem that shouldn't be".
>

I cannot be responsiple for the actions of fedora builders.  Of course teh
OLPC build did all that.

> At the very least, the default Scons script should indicate clearly the
> meaning of each option, and *in giant red letters/flags* (or the
> equivalent) indicate experimental and untested features. Then by all
> means, make a safe and compatible default build.
>


I am not aware of any experimental and untested features.  There are
developments happening

As it happens i have just spent a whole day loking at the parser.  I am
aware of one bug and a partially implemented (un documented) facility.

==John ff



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

I agree with most of your comments but...

On Tue, Jun 14, 2011 at 13:02, Art Hunkins  wrote:

> Everyone knows I'm a Windows person, and normally wouldn't be affected
> by such largely "Linux issues." However, I am involved with the Fedora-based
> Sugar-on-a-Stick project. A new release is about to come out, and Csound has
> been built with default Scons options, resulting in its being incompatible
> with the Activities I've written, as well as with all previous
> Sugar-on-a-Stick releases. This is "a problem that shouldn't be".

This is really a problem that shouldn't be, but not for the reasons
you argue. The csound maintainer in fedora should be specifying all
the features he wants and disabling all that he doesn't. Leaving the
build script to do whatever it feels like is wrong.


>
> At the very least, the default Scons script should indicate clearly the
> meaning of each option, and *in giant red letters/flags* (or the equivalent)
> indicate experimental and untested features. Then by all means, make a safe
> and compatible default build.
>
> Am I way off base? Please let me know what I'm missing.

This is my opinion only, but relying on defaults is the wrong way to
build software.


-- 

Saludos,
Felipe Sateler


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"