Csound Csound-dev Csound-tekno Search About

[Csnd] Re: Re: Re: Re: [Cs-dev] Sugar on a Stick - and OLPCsound

Date2009-07-03 17:44
From"Art Hunkins"
Subject[Csnd] Re: Re: Re: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
Unfortunately, this still leaves the Sugar on a Stick folks (as well as 
OLPC) with the challenge of making sure that the Python version they include 
and *update/upgrade* always corresponds to the appropriate Csound version.

(Right now I'm having a difficult time getting Python2.6 and Csound5.10 
working together in SoaS. I'm about to try a complete reinstall.)

Art Hunkins

----- Original Message ----- 
From: "Felipe Sateler" 
To: 
Sent: Thursday, July 02, 2009 11:22 PM
Subject: [Csnd] Re: Re: Re: [Cs-dev] Sugar on a Stick - and OLPCsound


> There is always the option of building csound n times for n python
> versions. A pain in the ass, I agree, but is the least work I think.
>
> On 03/07/2009, Michael Gogins  wrote:
>> As I have mentioned several times on this list, making the Csound API
>> independent of the Python version is not practical.
>>
>> We use SWIG to generate the Python wrapper, because it saves a simply
>> enormous amount of work to do so. Using SWIG also makes it easy to
>> generate two of the other wrappers: the Lua API and the Java API (the
>> Lisp API is done with cffi, which is different).
>>
>> SWIG, however, makes the Python wrapper depend on the specific version
>> of Python.
>>
>> The alternatives to using SWIG are basically boost::python, ctypes,
>> and hand-coding the wrappers in C. My limited experience with
>> boost::python is that it is not much less work than hand-coding, and
>> harder to maintain. I have a reasonable amount of experience with both
>> ctypes, and hand-coding Python wrappers in C. If I had to choose one
>> of these three, it would be ctypes because it is completely done in
>> the actual Python code and seems to work well.
>>
>> I know from experience that hand-coding C wrappers and using ctypes
>> involves about the same amount of work to get the same sort of
>> results.
>>
>> The code that SWIG generates is, naturally, very comparable to what a
>> good programmer would do by hand. If you want to see how much work
>> that would be, look at the sizes of the files generated by SWIG. They
>> are the largest source code files in the entire system, by a large
>> margin (they are not in CVS, you have to run SWIG to get them).
>>
>> There are two modules that get Python wrappers in Csound: csnd and
>> CsoundAC. I estimate that hand-coding wrappers even for csnd would
>> take a man-month at least. CsoundAC is several times as complex as
>> csnd.
>>
>> I am simply not willing to do that amount of work when what we are
>> currently doing works very well indeed except for this version
>> independence thing, which I admit is an annoyance.
>>
>> If anyone has a better idea, some other wrapper system that is
>> automatic but version-independent, I'd be glad to hear it.
>>
>> Hope this helps,
>> Mike
>>
>> On 7/2/09, Art Hunkins  wrote:
>> > 5.08 works with python2.5 but not with python2.6
>> >
>> > With SoaS, I imported 2.5 to sit alongside 2.6; 5.08 still didn't work 
>> > =
>> > (though I didn't really expect it to).
>> >
>> > I'm still waiting for 5.10 to be available to Soas; when it is, I'll =
>> > report whether it works with 2.6 (as I *do* expect).
>> >
>> > If it does, I'm going to make a strong plea that future versions of =
>> > Csound (I gather, the API) be made independent of python version.
>> >
>> > With Sugar, we'll have little or no control over what version of python 
>> > =
>> > is installed at any given time. If we want to write Csound Activities =
>> > using python (as is usual), Csound will need to adapt to whatever 
>> > python =
>> > is present.
>> >
>> > Either that, or Sugar and Csound will continue to have compatibility =
>> > issues (which will strictly limit its viability).
>> >
>> > Art Hunkins
>> >   ----- Original Message -----=20
>> >   From: victor=20
>> >   To: Art Hunkins ; Developer discussions=20
>> >   Sent: Wednesday, July 01, 2009 1:36 PM
>> >   Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
>> >
>> >
>> >   Because the 5.10 rpm has a python2.6 dependency. But that might
>> >   be the case for 5.08 too (I am not sure).
>> >     ----- Original Message -----=20
>> >     From: Art Hunkins=20
>> >     To: Developer discussions=20
>> >     Sent: Tuesday, June 30, 2009 2:22 AM
>> >     Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
>> >
>> >
>> >     I just noticed that the current OLPC build includes Python 2.5, =
>> > whereas SoaS includes Python 2.6
>> >
>> >     Csound 5.08.91 is currently in both. Wouldn't this explain why =
>> > 5.08.91 doesn't work on SoaS? And why 5.10 should?
>> >
>> >     Art Hunkins
>> >       ----- Original Message -----=20
>> >       From: Victor.Lazzarini@nuim.ie=20
>> >       To: Developer discussions=20
>> >       Sent: Monday, June 29, 2009 5:38 PM
>> >       Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
>> >
>> >
>> >       The message is strange, but it does not say there is a Python
>> >       version mismatch. However, having said that, the 5.08.91
>> >       rpm was built with 2.5 (unless what you have there is another
>> >       build that somehow uses 2.6).=20
>> >
>> >       What the message says is that the library module Python
>> >       tried to load does not have one of the API functions. The
>> >       reason for this I don't know.
>> >
>> >       Victor
>> >
>> >
>> >
>> > Send bugs reports to this list.
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body 
>> > "unsubscribe
>> > csound"
>> >
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>>
>
>
> -- 
>
> Saludos,
> Felipe Sateler
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 


Date2009-07-04 02:25
FromFelipe Sateler
Subject[Csnd] Re: Re: Re: Re: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
It should be possible (and I intend to do this for the debian packages
of csound, when I get enough time), to build csound for each version
of python *and ship them all* in the installer. This way, the
installed python version will get loaded and the other ones will fail
to, thus providing python "version independence".

Saludos,
Felipe Sateler



On Fri, Jul 3, 2009 at 23:44, Art Hunkins wrote:
> Unfortunately, this still leaves the Sugar on a Stick folks (as well as
> OLPC) with the challenge of making sure that the Python version they include
> and *update/upgrade* always corresponds to the appropriate Csound version.
>
> (Right now I'm having a difficult time getting Python2.6 and Csound5.10
> working together in SoaS. I'm about to try a complete reinstall.)
>
> Art Hunkins
>
> ----- Original Message ----- From: "Felipe Sateler" 
> To: 
> Sent: Thursday, July 02, 2009 11:22 PM
> Subject: [Csnd] Re: Re: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
>
>
>> There is always the option of building csound n times for n python
>> versions. A pain in the ass, I agree, but is the least work I think.
>>
>> On 03/07/2009, Michael Gogins  wrote:
>>>
>>> As I have mentioned several times on this list, making the Csound API
>>> independent of the Python version is not practical.
>>>
>>> We use SWIG to generate the Python wrapper, because it saves a simply
>>> enormous amount of work to do so. Using SWIG also makes it easy to
>>> generate two of the other wrappers: the Lua API and the Java API (the
>>> Lisp API is done with cffi, which is different).
>>>
>>> SWIG, however, makes the Python wrapper depend on the specific version
>>> of Python.
>>>
>>> The alternatives to using SWIG are basically boost::python, ctypes,
>>> and hand-coding the wrappers in C. My limited experience with
>>> boost::python is that it is not much less work than hand-coding, and
>>> harder to maintain. I have a reasonable amount of experience with both
>>> ctypes, and hand-coding Python wrappers in C. If I had to choose one
>>> of these three, it would be ctypes because it is completely done in
>>> the actual Python code and seems to work well.
>>>
>>> I know from experience that hand-coding C wrappers and using ctypes
>>> involves about the same amount of work to get the same sort of
>>> results.
>>>
>>> The code that SWIG generates is, naturally, very comparable to what a
>>> good programmer would do by hand. If you want to see how much work
>>> that would be, look at the sizes of the files generated by SWIG. They
>>> are the largest source code files in the entire system, by a large
>>> margin (they are not in CVS, you have to run SWIG to get them).
>>>
>>> There are two modules that get Python wrappers in Csound: csnd and
>>> CsoundAC. I estimate that hand-coding wrappers even for csnd would
>>> take a man-month at least. CsoundAC is several times as complex as
>>> csnd.
>>>
>>> I am simply not willing to do that amount of work when what we are
>>> currently doing works very well indeed except for this version
>>> independence thing, which I admit is an annoyance.
>>>
>>> If anyone has a better idea, some other wrapper system that is
>>> automatic but version-independent, I'd be glad to hear it.
>>>
>>> Hope this helps,
>>> Mike
>>>
>>> On 7/2/09, Art Hunkins  wrote:
>>> > 5.08 works with python2.5 but not with python2.6
>>> >
>>> > With SoaS, I imported 2.5 to sit alongside 2.6; 5.08 still didn't work
>>> > > =
>>> > (though I didn't really expect it to).
>>> >
>>> > I'm still waiting for 5.10 to be available to Soas; when it is, I'll =
>>> > report whether it works with 2.6 (as I *do* expect).
>>> >
>>> > If it does, I'm going to make a strong plea that future versions of =
>>> > Csound (I gather, the API) be made independent of python version.
>>> >
>>> > With Sugar, we'll have little or no control over what version of python
>>> > > =
>>> > is installed at any given time. If we want to write Csound Activities =
>>> > using python (as is usual), Csound will need to adapt to whatever >
>>> > python =
>>> > is present.
>>> >
>>> > Either that, or Sugar and Csound will continue to have compatibility =
>>> > issues (which will strictly limit its viability).
>>> >
>>> > Art Hunkins
>>> >   ----- Original Message -----=20
>>> >   From: victor=20
>>> >   To: Art Hunkins ; Developer discussions=20
>>> >   Sent: Wednesday, July 01, 2009 1:36 PM
>>> >   Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
>>> >
>>> >
>>> >   Because the 5.10 rpm has a python2.6 dependency. But that might
>>> >   be the case for 5.08 too (I am not sure).
>>> >     ----- Original Message -----=20
>>> >     From: Art Hunkins=20
>>> >     To: Developer discussions=20
>>> >     Sent: Tuesday, June 30, 2009 2:22 AM
>>> >     Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
>>> >
>>> >
>>> >     I just noticed that the current OLPC build includes Python 2.5, =
>>> > whereas SoaS includes Python 2.6
>>> >
>>> >     Csound 5.08.91 is currently in both. Wouldn't this explain why =
>>> > 5.08.91 doesn't work on SoaS? And why 5.10 should?
>>> >
>>> >     Art Hunkins
>>> >       ----- Original Message -----=20
>>> >       From: Victor.Lazzarini@nuim.ie=20
>>> >       To: Developer discussions=20
>>> >       Sent: Monday, June 29, 2009 5:38 PM
>>> >       Subject: Re: [Cs-dev] Sugar on a Stick - and OLPCsound
>>> >
>>> >
>>> >       The message is strange, but it does not say there is a Python
>>> >       version mismatch. However, having said that, the 5.08.91
>>> >       rpm was built with 2.5 (unless what you have there is another
>>> >       build that somehow uses 2.6).=20
>>> >
>>> >       What the message says is that the library module Python
>>> >       tried to load does not have one of the API functions. The
>>> >       reason for this I don't know.
>>> >
>>> >       Victor
>>> >
>>> >
>>> >
>>> > Send bugs reports to this list.
>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body >
>>> > "unsubscribe
>>> > csound"
>>> >
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>>
>> 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"
>