that's exactly what i just wanted to ask, too.
i just tried building csound for osx 10.5, and got the same error. i
assume you have 10.6 or 10.7?
funny enough, this was no problem on linux.

	joachim


Am 11.02.2012 22:43, schrieb Iain Duncan:
> With the tar ball from sourceforge, and the following scons line:
> 
> scons useCoreAudio=1 useJack=1 useGettext=0
> 
> malloc -I/opt/local/include/boost-1_32 -I/usr/include/python2.6
> -I/opt/local/include -I/usr/local/include Opcodes/tl/fractalnoise.cpp
> Opcodes/tl/fractalnoise.cpp: In function ‘void* aligned_calloc(size_t,
> size_t)’:
> Opcodes/tl/fractalnoise.cpp:42: error: pointer of type ‘void *’ used in
> arithmetic
> scons: *** [Opcodes/tl/fractalnoise.os] Error 1
> scons: building terminated because of errors.
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> 
> 
> 
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists

I havecorrectewd rhgat in git a few days ago
==John ff

> that's exactly what i just wanted to ask, too.
> i just tried building csound for osx 10.5, and got the same error. i
> assume you have 10.6 or 10.7?
> funny enough, this was no problem on linux.
>
> 	joachim
>
>
> Am 11.02.2012 22:43, schrieb Iain Duncan:
>> With the tar ball from sourceforge, and the following scons line:
>>
>> scons useCoreAudio=1 useJack=1 useGettext=0
>>
>> malloc -I/opt/local/include/boost-1_32 -I/usr/include/python2.6
>> -I/opt/local/include -I/usr/local/include Opcodes/tl/fractalnoise.cpp
>> Opcodes/tl/fractalnoise.cpp: In function ‘void* aligned_calloc(size_t,
>> size_t)’:
>> Opcodes/tl/fractalnoise.cpp:42: error: pointer of type ‘void *’ used
>> in
>> arithmetic
>> scons: *** [Opcodes/tl/fractalnoise.os] Error 1
>> scons: building terminated because of errors.
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>
>>
>>
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The latest in git has:

 inline void *aligned_calloc(size_t nmemb, size_t size)
 {
-    return (void*)((unsigned long)(calloc((nmemb*size)+15,
-                                          (sizeof(char)))+15) & 0xfffffff0);
+    return (void*)(((unsigned long)(calloc((nmemb*size)+15,
+                                           (sizeof(char))))+15) & 0xfffffff0);
 }

Seems that the source release needs to be redone?

On Sat, Feb 11, 2012 at 10:18 PM,   wrote:
> I havecorrectewd rhgat in git a few days ago
> ==John ff
>
>> that's exactly what i just wanted to ask, too.
>> i just tried building csound for osx 10.5, and got the same error. i
>> assume you have 10.6 or 10.7?
>> funny enough, this was no problem on linux.
>>
>>       joachim
>>
>>
>> Am 11.02.2012 22:43, schrieb Iain Duncan:
>>> With the tar ball from sourceforge, and the following scons line:
>>>
>>> scons useCoreAudio=1 useJack=1 useGettext=0
>>>
>>> malloc -I/opt/local/include/boost-1_32 -I/usr/include/python2.6
>>> -I/opt/local/include -I/usr/local/include Opcodes/tl/fractalnoise.cpp
>>> Opcodes/tl/fractalnoise.cpp: In function ‘void* aligned_calloc(size_t,
>>> size_t)’:
>>> Opcodes/tl/fractalnoise.cpp:42: error: pointer of type ‘void *’ used
>>> in
>>> arithmetic
>>> scons: *** [Opcodes/tl/fractalnoise.os] Error 1
>>> scons: building terminated because of errors.
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>>
>>>
>>>
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi,

I think you are right. Another important thing is that LINUX distributions might rely on source packages, and if they don't build out of the box, the update will be postponed until the next working release.

Cheers,
AndresOn 12/02/2012 1:56 Iain Duncan wrote:
On Sat, Feb 11, 2012 at 4:50 PM, Victor Lazzarini  wrote:

In general, we do not have such problems because we are constantly building from GIT and will identify these issues before a source release. However, this time I was occupied elsewhere and only built from GIT after the release was out, and had no problems whatsoever (probably due to the the fixes).


I don't think this is a problem that would affect the csound advocacy department as the number of OSX users building their own Csound is minimal and usually savvy enough to get around small issues like these.


Given that this has happened to twice to me in the last couple of months, once on os x and once on linux ( where it is documented as being 'the recommended way to install csound ). I'd respectfully disagree. 


It just shouldn't happen;  in most software development circles, the release of a broken build is an unacceptable failure. I realize that the Csound community has a different take on this, and that I'm in a minority here, but when new user/devlopers who come from other software development scenes come to check out csound and this happens, it creates a really negative impression. 


I do python web dev for a living, and  I download and install dozens of dependencies every day and rebuild stuff every day. Pubic release builds of published tools are *never* broken. No one releasing a package that gets used in the wild let's that happen, they'd lose your users in a flash. I really think there's no good reason for Csound not to hold itself to the same standard, because you never know how many potential developers get turned off and then decide to go off and be SuperCollider guys or use stk, or just write Csound off as some ivory tower dinosaur project. Yes, I hear that complaint. I don't believe that's the case, but I hear it. 


Jack is *never* released in a broken state. Paul would flip out if it happened because there are partnerships in place with people like Harrison consoles and the public release needs to always work. If this were going to be hard for the csound to community to achieve, I could understand dismissing my complaints as whining. But it's not, it's just standard practice for heavily used open source software, and it's not hard. All it takes is putting some kind of system in place. I really really want to tell people using my upcoming project to get into csound. :-/


Am I totally alone in thinking some kind of system to ensure releases work as advertised is warranted? Even if it's nothing more than a 3 day holding period while people test out the build before removing the word 'beta'? It's not asking much.


Iain



------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Windows, production releases of everything I build frequently have
problems, so I'm not really sure what the big deal is.  I will say,
however, that with all the libraries I build for my apps, the Csound
devs are the most responsive when I run into bugs, sometimes getting
fixes posted within the hour.  In comparison, the Qt libraries can
often take *months* to get fixes pushed through, and they have all
kinds of git branches, hooks, and CI to keep bugs from appearing.
While I'm sure those systems help them deal with the many issues
regarding their giant code-base, is this really necessary for a
repository as small as Csound's?  Granted, the Csound releases could
definitely be vetted out a bit, but again ...with the responsiveness
of the devs being so good, what's the big deal?

Cheers,
~ andy.f



On Sun, Feb 12, 2012 at 7:05 PM, Iain Duncan  wrote:
> On Sun, Feb 12, 2012 at 4:03 PM, Iain Duncan 
> wrote:
>>
>> On Sun, Feb 12, 2012 at 3:52 PM, Victor Lazzarini
>>  wrote:
>>>
>>> yes, what I am telling you is that GIT is not always stable, but if you
>>> ask the question politely, we will say whether the current GIT is correct or
>>> not, or try to help identify any issues.
>>>
>>
>> I apologize that I have come across as impolite.
>>
>> My poor conduct aside, this does not change the fact that all three broken
>> builds I have complained about were production snapshots, not pulls from git
>> as you believed. I still maintain that this is a serious problem, please see
>> my new post in which I have tried to be as polite and diplomatic as
>> possible.
>>
>
> I also believe that there should always be a way to get and build the latest
> production release without having to be on a mailing list and be following
> what is going on inside the development community. If someone is building an
> app that has csound as one of its dependencies, it does not seem reasonable
> to me to expect them to be up on Csound. It may be just one of many
> dependencies for the app in question.
>
> Iain
>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am also a developer of an app depending on Csound and I have no
problem with how Csound is released.  I just bring the Csound library
into my own repository and make sure it works in my build system.
Voila!  Build and install issues for my users disappear, and as an
added bonus I get a stripped down version of Csound that only depends
on libsndfile.

Cheers,
~ andy.f


On Sun, Feb 12, 2012 at 11:16 PM, Iain Duncan  wrote:
>> The big deal is that someone building an app that depends on Csound should
>> not need to be on mailing lists with the csound devs just to build csound
>> from a production release, in order to use it as a dependency for whatever
>> they are ultimately trying to build. Just as I don't have to be on the
>> mailing lists for the packages that Csound depends on to build csound. I
>> don't have to talk to fltk, portaudio, libsndfile I just download those
>> packages and build them. If I did have to, would we in csound land be using
>> them as dependencies? I have never had an issue downloading and building
>> FLTK, libsndfile, portaudio, qt, or jack. I can't say that they *never* have
>> this same issue, but my experience is that is has never happened to me,
>> while it has happened 3 times in two months with csound, and I don't even
>> build on windows. The QT releases always build, they may not be perfect, but
>> I definitely don't have to get on QT lists to get a new production releases
>> of QT working. I am not talking about 100% test coverage here, just source
>> releases building as advertised so they can be used.
>>
>
> Another way to look at this. Let's say I have a project (which of course I
> do, it's just a long way from release) and I want user/developers to build
> it from source. I publish a page on how to build it, much like the one we
> have here that Steven just updated:
>
> https://sourceforge.net/apps/mediawiki/csound/index.php?title=Building_Csound_on_OSX_Lion
>
> On the above the instructions tell us to go and get the latest production
> snapshot of each dependency, and also mention which one was used, which is
> as far as I can tell in all cases except for PortAudio, the latest
> production release. This page, and the process of building Csound from
> source, would be a lot worse if each package had to say something like
> "install this one only, we can't guarantee other versions including the
> latest build". I would hate to have to install each of those were their
> release management the same as Csound's. ( In fact, if I recall correctly,
> PortAudio's sketchy situation was indeed a cause of concern on the csound
> dev list years ago when audio output was moved to port audio, and that was
> part of the reason that it became one option for output and not *the* option
> for output. That was a long time ago, but I do remember gnashing of teeth on
> the list over portaudio, and I haven't used it as a result ).
>
> That is the relationship projects using the CsoundAPI will have to Csound.
>
> iain
>
>
>>
>> iain
>>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

First let nme say that i ALWAYS compile csound on my system before
release; only rarely does the GIT system not compile.  Similarly it is
plain incorrect to assume we do not test before a release.

One major difference between us and some of the other systems is rate of
change.  Even a "minor" release has many many lines changed or new.  Also
ther eis a relationship between size anad complexity

Crude count of lines of C/C++ gives

wiiuse         5K
liblo          6K
portaudio     42K
FLTK          54K
libsndfile    70K
exim          86K
csound       251K

We release more often than many of these, and change more.
And we can always improve if anyone were to care to instigate a serious
blackbox testing regime

==John ff



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

+1.  I agree with you, too, and it's one of the reasons I'm reluctant
to spend time contributing to Csound, which is something I was eager
to do initially.  Fortunately, I have no problem "black-boxing" Csound
for my own app since part of my design goal is for users not to worry
about what's going on under the hood, and I recommend this as the way
to go.  This is not to say I think the devs are doing a bad job.  Far
from it.  I just think their idea of a release differs from what other
projects' devs consider a release.  Knowing that difference exists,
I've adjusted my expectations accordingly and dealt with it.  I still
think Csound is the best sounding and most powerful free synth
available and I'll continue to use it in my app regardless of how I
feel about the quality of the releases.

Cheers,
~ andy.f



On Mon, Feb 13, 2012 at 1:17 PM, Andres Cabrera  wrote:
> Hi Iain,
>
> Although I'm not doing Csound development at the moment, I am also a user of
> the API, and agree with you. I agree that doing a release candidate branch
> now that we are on git would be a good idea.
>
> In my experience, there are always some bugs in the final releases that
> could be caught with a system like this.
>
> AFAIK John has a buildbot generating nightly builds for linux. I think
> buildbots for other platforms would certainly be welcome. Maybe they should
> be publicized as well (for example in the wiki), so people can use them.
>
> Cheers,
> Andrés
>
> On Mon, Feb 13, 2012 at 5:55 PM, Iain Duncan 
> wrote:
>>
>> On Mon, Feb 13, 2012 at 4:05 AM,  wrote:
>>>
>>> First let nme say that i ALWAYS compile csound on my system before
>>> release; only rarely does the GIT system not compile.  Similarly it is
>>> plain incorrect to assume we do not test before a release.
>>>
>>
>> I did not make that assumption, but I did make the observation that tests
>> are clearly not covering all platforms for all releases. I realize that
>> coverage of all platforms is hard. But, I'm not making up my three
>> problematic or non building releases in the last two months, those are plain
>> facts and not opinions.
>>
>>>
>>> One major difference between us and some of the other systems is rate of
>>> change.  Even a "minor" release has many many lines changed or new.  Also
>>> ther eis a relationship between size anad complexity
>>>
>>
>> I recognize this as well, which is why in my release management post, one
>> of the options I put forth was changing the labelling so that there are
>> perhaps fewer full production release which are tested more thoroughly, and
>> minor point releases which are not labelled as full production snap shots
>> and could continue using the current process. I realize Csound is huge, but
>> QT is also huge, and they have figured out how to deal with this issue. ( I
>> think part of their approach is fewer moving target releases branded as
>> production releases, but that is just an impression I get, I don't know for
>> sure..
>>
>>>
>>> We release more often than many of these, and change more.
>>> And we can always improve if anyone were to care to instigate a serious
>>> blackbox testing regime
>>>
>>
>> Thank you John, you are the first person to respond that yes this could be
>> improved. Everyone else has basically dismissed my concerns as 'not a big
>> deal'. And the bottom line is, this issue is something facing all big
>> projects that get used as dependencies by other projects, and how well they
>> deal with it has a very real effect on their uptake.
>>
>> Please tell me exactly what you would need and if it was met, what kind of
>> commitment would be in place to use it. I'm very serious about my project,
>> just as you are of course hugely dedicated to Csound ( don't think for a
>> moment I'm questioning the dedication of the devs! ) If using Csound as a
>> dependency for my work means I need to put some work in to improve Csound
>> release management, then I will evaluate the practical implications of doing
>> so. However, I need to know that my work would get used if it accomplishes
>> the requirements the csound devs set out. Obviously I don't want to drop a
>> weeks work setting up a buildbot for csound if I'm going to come out the
>> other end finding out that no one wants to use.
>>
>> I would love to have this turn into a conversation on that, which is why I
>> started the other thread. I've been gone for like 5 years, and now have
>> experience with this stuff, we use CI in our work. But I don't expect anyone
>> to trust an outsider or just let them redraw the ground rules. So what I'd
>> love is something clear with a list of what you would want to see me manage
>> (on my own or with volunteers) and what kind of commitment to use it would
>> happen as a result of that happening.
>>
>> Personally, I think the best solution would be a buildbot system that
>> builds nightly from trunk combined with fewer production releases and some
>> kind of branching in the trunk to work with that.
>>
>> Thanks
>> Iain
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Try before you buy = See our experts in action!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-dev2
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net