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

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

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