>
> Also, what is being done to remove *broken* things from the Csound build
> and
> the manual? In particular, I'm thinking of the opcodes that rely on HETRO
> (which seems definitely broken), although I'm sure there might be
> others.....the manual might be changed to have footnotes letting users
> know
> that certain opcodes may be broken, or perhaps they can all be found and
> lumped under a "work in progress" sub-section of the manual?
>

I was not aware that meyro was broken.  If it ius not reported and it i
snot an opcode i use personally it is hard to know that it i sbroken




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"

Hi Aaron,

In general, I've found that having a continuous integration server
doing builds on projects to be a good thing.  I think it's really best
when paired together with an automated test suite to help detect
unintended application changes.

The issue with setting up a server I've found is that it can be
resource hungry, particularly for disk space to store built artifacts.
Besides just a script to build, it'd be nice to get notification of
breakages.

I think it's a good idea but would to be of real benefit I think it'd
require some work to setting up a test suite and finding a server to
use to run it.

Thanks!
steven

On Tue, Jul 13, 2010 at 4:45 PM, Aaron Krister Johnson
 wrote:
> Hi all,
>
> I'm wondering if anyone else would be interested in a nightly build
> script....I know that this is done with (for instance) Firefox. One can
> automate a script to check CVS for changes, and maybe a build with some
> default options can be made. I'd be happy to come up with one to share,
> maybe then it could be put on a server where it could be used to make
> binaries for a given platform to be distributed from
> csounds.com/sourceforge?
>
> I think also simplifying the build/install process in general would be a
> good idea. I'd like to see the weird dependency on libwiiuse, which seems an
> odd default, to go away, since for some reason building Csound with a
> dynamic library makes it fail to run if you don't have libwiiuse on your
> system....a fact I wasted about 3 hours of my life finding out.
>
> Also, would it be possible to create a SCONS build which allows one to
> specify a streamlined Csound, should that be desired? By this, I mean being
> able to pick some basic oscillator opcodes, or maybe have opcodes in
> families that one can opt out of (e.g. additive, granular, sample/soundfont,
> basic subtractive, PVS, Loris (this is already optional). Perhaps a
> customized Csound like this would be more memory/speed efficient?
>
> Also, what is being done to remove *broken* things from the Csound build and
> the manual? In particular, I'm thinking of the opcodes that rely on HETRO
> (which seems definitely broken), although I'm sure there might be
> others.....the manual might be changed to have footnotes letting users know
> that certain opcodes may be broken, or perhaps they can all be found and
> lumped under a "work in progress" sub-section of the manual?
>
> --
> Best,
>
> Aaron Krister Johnson
> http://www.akjmusic.com
> http://www.untwelve.org
>
>


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 could do a daily build and place on dream.cs.bath.ac.uk but this would
be for Linux and probably OpenSuse; could use VirtualBox for an Ubuntu
binary.  I do not have a windows machine or a sufficiently recent Mac to
provide other builds.  I have the server and the disk space if anyone
wanted to contrbute a nightly build+SSH to the server.

==John ff

> Hi Aaron,
>
> In general, I've found that having a continuous integration server
> doing builds on projects to be a good thing.  I think it's really best
> when paired together with an automated test suite to help detect
> unintended application changes.
>
> The issue with setting up a server I've found is that it can be
> resource hungry, particularly for disk space to store built artifacts.
> Besides just a script to build, it'd be nice to get notification of
> breakages.
>
> I think it's a good idea but would to be of real benefit I think it'd
> require some work to setting up a test suite and finding a server to
> use to run it.
>
> Thanks!
> steven
>
> On Tue, Jul 13, 2010 at 4:45 PM, Aaron Krister Johnson
>  wrote:
>> Hi all,
>>
>> I'm wondering if anyone else would be interested in a nightly build
>> script....I know that this is done with (for instance) Firefox. One can
>> automate a script to check CVS for changes, and maybe a build with some
>> default options can be made. I'd be happy to come up with one to share,
>> maybe then it could be put on a server where it could be used to make
>> binaries for a given platform to be distributed from
>> csounds.com/sourceforge?
>>
>> I think also simplifying the build/install process in general would be a
>> good idea. I'd like to see the weird dependency on libwiiuse, which
>> seems an
>> odd default, to go away, since for some reason building Csound with a
>> dynamic library makes it fail to run if you don't have libwiiuse on your
>> system....a fact I wasted about 3 hours of my life finding out.
>>
>> Also, would it be possible to create a SCONS build which allows one to
>> specify a streamlined Csound, should that be desired? By this, I mean
>> being
>> able to pick some basic oscillator opcodes, or maybe have opcodes in
>> families that one can opt out of (e.g. additive, granular,
>> sample/soundfont,
>> basic subtractive, PVS, Loris (this is already optional). Perhaps a
>> customized Csound like this would be more memory/speed efficient?
>>
>> Also, what is being done to remove *broken* things from the Csound build
>> and
>> the manual? In particular, I'm thinking of the opcodes that rely on
>> HETRO
>> (which seems definitely broken), although I'm sure there might be
>> others.....the manual might be changed to have footnotes letting users
>> know
>> that certain opcodes may be broken, or perhaps they can all be found and
>> lumped under a "work in progress" sub-section of the manual?
>>
>> --
>> Best,
>>
>> Aaron Krister Johnson
>> http://www.akjmusic.com
>> http://www.untwelve.org
>>
>>
>
>
> 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"
>
>
>
>




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"

Hi,

I think it would also be useful for people who need just a single fix
in a plugin library, but can't compile themselves. What platform did
you have in mind?

Cheers,
Andrés

On Thu, Jul 15, 2010 at 3:20 PM, Steven Yi  wrote:
> Hi Aaron,
>
> In general, I've found that having a continuous integration server
> doing builds on projects to be a good thing.  I think it's really best
> when paired together with an automated test suite to help detect
> unintended application changes.
>
> The issue with setting up a server I've found is that it can be
> resource hungry, particularly for disk space to store built artifacts.
> Besides just a script to build, it'd be nice to get notification of
> breakages.
>
> I think it's a good idea but would to be of real benefit I think it'd
> require some work to setting up a test suite and finding a server to
> use to run it.
>
> Thanks!
> steven
>
> On Tue, Jul 13, 2010 at 4:45 PM, Aaron Krister Johnson
>  wrote:
>> Hi all,
>>
>> I'm wondering if anyone else would be interested in a nightly build
>> script....I know that this is done with (for instance) Firefox. One can
>> automate a script to check CVS for changes, and maybe a build with some
>> default options can be made. I'd be happy to come up with one to share,
>> maybe then it could be put on a server where it could be used to make
>> binaries for a given platform to be distributed from
>> csounds.com/sourceforge?
>>
>> I think also simplifying the build/install process in general would be a
>> good idea. I'd like to see the weird dependency on libwiiuse, which seems an
>> odd default, to go away, since for some reason building Csound with a
>> dynamic library makes it fail to run if you don't have libwiiuse on your
>> system....a fact I wasted about 3 hours of my life finding out.
>>
>> Also, would it be possible to create a SCONS build which allows one to
>> specify a streamlined Csound, should that be desired? By this, I mean being
>> able to pick some basic oscillator opcodes, or maybe have opcodes in
>> families that one can opt out of (e.g. additive, granular, sample/soundfont,
>> basic subtractive, PVS, Loris (this is already optional). Perhaps a
>> customized Csound like this would be more memory/speed efficient?
>>
>> Also, what is being done to remove *broken* things from the Csound build and
>> the manual? In particular, I'm thinking of the opcodes that rely on HETRO
>> (which seems definitely broken), although I'm sure there might be
>> others.....the manual might be changed to have footnotes letting users know
>> that certain opcodes may be broken, or perhaps they can all be found and
>> lumped under a "work in progress" sub-section of the manual?
>>
>> --
>> Best,
>>
>> Aaron Krister Johnson
>> http://www.akjmusic.com
>> http://www.untwelve.org
>>
>>
>
>
> 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"
>
>



-- 


Andrés


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"

One thing to note, a cross-compile build should be possible to create
Windows builds on a Linux machine.  Istvan used to do this a long time
ago.  I do not know if NSIS installer builder can be run this way
however.

On Thu, Jul 15, 2010 at 10:33 AM, Andres Cabrera  wrote:
> Hi,
>
> I think it would also be useful for people who need just a single fix
> in a plugin library, but can't compile themselves. What platform did
> you have in mind?
>
> Cheers,
> Andrés
>
> On Thu, Jul 15, 2010 at 3:20 PM, Steven Yi  wrote:
>> Hi Aaron,
>>
>> In general, I've found that having a continuous integration server
>> doing builds on projects to be a good thing.  I think it's really best
>> when paired together with an automated test suite to help detect
>> unintended application changes.
>>
>> The issue with setting up a server I've found is that it can be
>> resource hungry, particularly for disk space to store built artifacts.
>> Besides just a script to build, it'd be nice to get notification of
>> breakages.
>>
>> I think it's a good idea but would to be of real benefit I think it'd
>> require some work to setting up a test suite and finding a server to
>> use to run it.
>>
>> Thanks!
>> steven
>>
>> On Tue, Jul 13, 2010 at 4:45 PM, Aaron Krister Johnson
>>  wrote:
>>> Hi all,
>>>
>>> I'm wondering if anyone else would be interested in a nightly build
>>> script....I know that this is done with (for instance) Firefox. One can
>>> automate a script to check CVS for changes, and maybe a build with some
>>> default options can be made. I'd be happy to come up with one to share,
>>> maybe then it could be put on a server where it could be used to make
>>> binaries for a given platform to be distributed from
>>> csounds.com/sourceforge?
>>>
>>> I think also simplifying the build/install process in general would be a
>>> good idea. I'd like to see the weird dependency on libwiiuse, which seems an
>>> odd default, to go away, since for some reason building Csound with a
>>> dynamic library makes it fail to run if you don't have libwiiuse on your
>>> system....a fact I wasted about 3 hours of my life finding out.
>>>
>>> Also, would it be possible to create a SCONS build which allows one to
>>> specify a streamlined Csound, should that be desired? By this, I mean being
>>> able to pick some basic oscillator opcodes, or maybe have opcodes in
>>> families that one can opt out of (e.g. additive, granular, sample/soundfont,
>>> basic subtractive, PVS, Loris (this is already optional). Perhaps a
>>> customized Csound like this would be more memory/speed efficient?
>>>
>>> Also, what is being done to remove *broken* things from the Csound build and
>>> the manual? In particular, I'm thinking of the opcodes that rely on HETRO
>>> (which seems definitely broken), although I'm sure there might be
>>> others.....the manual might be changed to have footnotes letting users know
>>> that certain opcodes may be broken, or perhaps they can all be found and
>>> lumped under a "work in progress" sub-section of the manual?
>>>
>>> --
>>> Best,
>>>
>>> Aaron Krister Johnson
>>> http://www.akjmusic.com
>>> http://www.untwelve.org
>>>
>>>
>>
>>
>> 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"
>>
>>
>
>
>
> --
>
>
> Andrés
>
>
> 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"
>
>


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"