This would require changing the user's Python code to be specialized
for the different versions of csnd.

That is, csndf.pyd and csndd.pyd would require "import csndf" and
"import csndd". And then csndf.thisfunction() and csndd.this
function()...

Regards,
Mike

On 10/23/09, Andy Fillebrown  wrote:
> Hello,
>
> I'd like to request that in the next release of Csound (5.12?) that the
> float and double versions of csnd.dll be given different names, like the two
> different names for csound32.dll.5.2 and csound64.dll.5.2. It would make
> installing and running both versions on the same system easier. As it is
> right now, I have to setup two different environments to run the different
> versions of QuteCsound since it is now calling
> CsoundPerformanceThread::ScoreEvent and putting both versions of Csound on
> the system PATH causes the wrong csnd.dll to be loaded depending on which
> Csound path comes first in the PATH variable. Is there any reason why the
> two different versions of csnd.dll could not be renamed to indicate which
> floating point type is in use? It's only a minor inconvenience, but it's
> easily fixed in the next release imo, so I figure it couldn't hurt to ask.
>
> Cheers,
> ~ andy.f
>
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

ok, that's it ...this python stuff has to go (just kidding, of course =)

Seriously, though, there must be a simple solution other than having to setup two different environments?



----- "Michael Gogins"  wrote:
> This would require changing the user's Python code to be specialized
> for the different versions of csnd.
> 
> That is, csndf.pyd and csndd.pyd would require "import csndf" and
> "import csndd". And then csndf.thisfunction() and csndd.this
> function()...
> 
> Regards,
> Mike
> 
> On 10/23/09, Andy Fillebrown  wrote:
> > Hello,
> >
> > I'd like to request that in the next release of Csound (5.12?) that
> the
> > float and double versions of csnd.dll be given different names, like
> the two
> > different names for csound32.dll.5.2 and csound64.dll.5.2. It would
> make
> > installing and running both versions on the same system easier. As
> it is
> > right now, I have to setup two different environments to run the
> different
> > versions of QuteCsound since it is now calling
> > CsoundPerformanceThread::ScoreEvent and putting both versions of
> Csound on
> > the system PATH causes the wrong csnd.dll to be loaded depending on
> which
> > Csound path comes first in the PATH variable. Is there any reason
> why the
> > two different versions of csnd.dll could not be renamed to indicate
> which
> > floating point type is in use? It's only a minor inconvenience, but
> it's
> > easily fixed in the next release imo, so I figure it couldn't hurt
> to ask.
> >
> > Cheers,
> > ~ andy.f
> >
> >
> 
> 
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart
> your
> developing skills, take BlackBerry mobile applications to market and
> stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That's a good question, and I hadn't thought of it. I will try it out.

Thanks,
Mike

On 10/23/09, Jeremy Voorhis  wrote:
> Hello,
>
> I'm no crack Pythonista, but wouldn't that be alleviated by the "import
>  as " syntax?
>
> Best,
>
> Jeremy
>
> On Fri, Oct 23, 2009 at 5:21 AM, Michael Gogins
> wrote:
>
>> This would require changing the user's Python code to be specialized
>> for the different versions of csnd.
>>
>> That is, csndf.pyd and csndd.pyd would require "import csndf" and
>> "import csndd". And then csndf.thisfunction() and csndd.this
>> function()...
>>
>> Regards,
>> Mike
>>
>> On 10/23/09, Andy Fillebrown  wrote:
>> > Hello,
>> >
>> > I'd like to request that in the next release of Csound (5.12?) that the
>> > float and double versions of csnd.dll be given different names, like the
>> two
>> > different names for csound32.dll.5.2 and csound64.dll.5.2. It would make
>> > installing and running both versions on the same system easier. As it is
>> > right now, I have to setup two different environments to run the
>> different
>> > versions of QuteCsound since it is now calling
>> > CsoundPerformanceThread::ScoreEvent and putting both versions of Csound
>> on
>> > the system PATH causes the wrong csnd.dll to be loaded depending on
>> > which
>> > Csound path comes first in the PATH variable. Is there any reason why
>> > the
>> > two different versions of csnd.dll could not be renamed to indicate
>> > which
>> > floating point type is in use? It's only a minor inconvenience, but it's
>> > easily fixed in the next release imo, so I figure it couldn't hurt to
>> ask.
>> >
>> > Cheers,
>> > ~ andy.f
>> >
>> >
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Looks like it will probably work. I will test it more.

Thanks again,
Mike

On 10/23/09, Michael Gogins  wrote:
> That's a good question, and I hadn't thought of it. I will try it out.
>
> Thanks,
> Mike
>
> On 10/23/09, Jeremy Voorhis  wrote:
>> Hello,
>>
>> I'm no crack Pythonista, but wouldn't that be alleviated by the "import
>>  as " syntax?
>>
>> Best,
>>
>> Jeremy
>>
>> On Fri, Oct 23, 2009 at 5:21 AM, Michael Gogins
>> wrote:
>>
>>> This would require changing the user's Python code to be specialized
>>> for the different versions of csnd.
>>>
>>> That is, csndf.pyd and csndd.pyd would require "import csndf" and
>>> "import csndd". And then csndf.thisfunction() and csndd.this
>>> function()...
>>>
>>> Regards,
>>> Mike
>>>
>>> On 10/23/09, Andy Fillebrown  wrote:
>>> > Hello,
>>> >
>>> > I'd like to request that in the next release of Csound (5.12?) that
>>> > the
>>> > float and double versions of csnd.dll be given different names, like
>>> > the
>>> two
>>> > different names for csound32.dll.5.2 and csound64.dll.5.2. It would
>>> > make
>>> > installing and running both versions on the same system easier. As it
>>> > is
>>> > right now, I have to setup two different environments to run the
>>> different
>>> > versions of QuteCsound since it is now calling
>>> > CsoundPerformanceThread::ScoreEvent and putting both versions of
>>> > Csound
>>> on
>>> > the system PATH causes the wrong csnd.dll to be loaded depending on
>>> > which
>>> > Csound path comes first in the PATH variable. Is there any reason why
>>> > the
>>> > two different versions of csnd.dll could not be renamed to indicate
>>> > which
>>> > floating point type is in use? It's only a minor inconvenience, but
>>> > it's
>>> > easily fixed in the next release imo, so I figure it couldn't hurt to
>>> ask.
>>> >
>>> > Cheers,
>>> > ~ andy.f
>>> >
>>> >
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>


-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It can also be solved by a symlink (do shortcuts work in windows for
this?) csnd.py -> csndf.py (or whatever is the default version). That
failing, could a simple csnd.py wrapper do?:

haveCsnd = False
try:
    import csndf as csnd
    haveCsnd = True
except ImportError:
    try:
        import csndd as csnd
    except ImportError:
        raise ImportError("No suitable csound module found!")


On Fri, 2009-10-23 at 05:42 -0700, Andy Fillebrown wrote:
> 
> 
> ok, that's it ...this python stuff has to go (just kidding, of course =)
> 
> Seriously, though, there must be a simple solution other than having to setup two different environments?
> 
> 
> 
> ----- "Michael Gogins"  wrote:
> > This would require changing the user's Python code to be specialized
> > for the different versions of csnd.
> > 
> > That is, csndf.pyd and csndd.pyd would require "import csndf" and
> > "import csndd". And then csndf.thisfunction() and csndd.this
> > function()...
> > 
> > Regards,
> > Mike
> > 
> > On 10/23/09, Andy Fillebrown  wrote:
> > > Hello,
> > >
> > > I'd like to request that in the next release of Csound (5.12?) that
> > the
> > > float and double versions of csnd.dll be given different names, like
> > the two
> > > different names for csound32.dll.5.2 and csound64.dll.5.2. It would
> > make
> > > installing and running both versions on the same system easier. As
> > it is
> > > right now, I have to setup two different environments to run the
> > different
> > > versions of QuteCsound since it is now calling
> > > CsoundPerformanceThread::ScoreEvent and putting both versions of
> > Csound on
> > > the system PATH causes the wrong csnd.dll to be loaded depending on
> > which
> > > Csound path comes first in the PATH variable. Is there any reason
> > why the
> > > two different versions of csnd.dll could not be renamed to indicate
> > which
> > > floating point type is in use? It's only a minor inconvenience, but
> > it's
> > > easily fixed in the next release imo, so I figure it couldn't hurt
> > to ask.
> > >
> > > Cheers,
> > > ~ andy.f
> > >
> > >
> > 
> > 
> > -- 
> > Michael Gogins
> > Irreducible Productions
> > http://www.michael-gogins.com
> > Michael dot Gogins at gmail dot com
> > 
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart
> > your
> > developing skills, take BlackBerry mobile applications to market and
> > stay 
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
Saludos,
Felipe Sateler

On Fri, 2009-10-23 at 09:28 -0700, Jeremy Voorhis wrote:
> Hello,
> 
> 
> I'm no crack Pythonista, but wouldn't that be alleviated by the
> "import  as " syntax?

Yup, that should work, this is common on python web apps that need to
use different bits based on the host system. All main body code runs on
import time of course, so you can do conditional imports that check
their conditions at module import.

if ( check the system using os or sys ):
  import foo as bar
else:
  import spam as bar 

or alternately if only one will actually be present:

try:
  import foo as bar
except:
  import spam as bar


Then when another module imports bar from this module, they will get the
right bar.

Iain



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I don't know about python wrappers, but I'm reasonably certain shortcuts in Windows don't work like a symlinks in Linux, which is a shame because it'd be awesome if they did.



----- "Felipe Sateler"  wrote:
> It can also be solved by a symlink (do shortcuts work in windows for
> this?) csnd.py -> csndf.py (or whatever is the default version). That
> failing, could a simple csnd.py wrapper do?:
> 
> haveCsnd = False
> try:
>     import csndf as csnd
>     haveCsnd = True
> except ImportError:
>     try:
>         import csndd as csnd
>     except ImportError:
>         raise ImportError("No suitable csound module found!")
> 
> 
> On Fri, 2009-10-23 at 05:42 -0700, Andy Fillebrown wrote:
> > 
> > 
> > ok, that's it ...this python stuff has to go (just kidding, of
> course =)
> > 
> > Seriously, though, there must be a simple solution other than having
> to setup two different environments?
> > 
> > 
> > 
> > ----- "Michael Gogins"  wrote:
> > > This would require changing the user's Python code to be
> specialized
> > > for the different versions of csnd.
> > > 
> > > That is, csndf.pyd and csndd.pyd would require "import csndf" and
> > > "import csndd". And then csndf.thisfunction() and csndd.this
> > > function()...
> > > 
> > > Regards,
> > > Mike
> > > 
> > > On 10/23/09, Andy Fillebrown  wrote:
> > > > Hello,
> > > >
> > > > I'd like to request that in the next release of Csound (5.12?)
> that
> > > the
> > > > float and double versions of csnd.dll be given different names,
> like
> > > the two
> > > > different names for csound32.dll.5.2 and csound64.dll.5.2. It
> would
> > > make
> > > > installing and running both versions on the same system easier.
> As
> > > it is
> > > > right now, I have to setup two different environments to run
> the
> > > different
> > > > versions of QuteCsound since it is now calling
> > > > CsoundPerformanceThread::ScoreEvent and putting both versions
> of
> > > Csound on
> > > > the system PATH causes the wrong csnd.dll to be loaded depending
> on
> > > which
> > > > Csound path comes first in the PATH variable. Is there any
> reason
> > > why the
> > > > two different versions of csnd.dll could not be renamed to
> indicate
> > > which
> > > > floating point type is in use? It's only a minor inconvenience,
> but
> > > it's
> > > > easily fixed in the next release imo, so I figure it couldn't
> hurt
> > > to ask.
> > > >
> > > > Cheers,
> > > > ~ andy.f
> > > >
> > > >
> > > 
> > > 
> > > -- 
> > > Michael Gogins
> > > Irreducible Productions
> > > http://www.michael-gogins.com
> > > Michael dot Gogins at gmail dot com
> > > 
> > >
> ------------------------------------------------------------------------------
> > > Come build with us! The BlackBerry(R) Developer Conference in SF,
> CA
> > > is the only developer event you need to attend this year.
> Jumpstart
> > > your
> > > developing skills, take BlackBerry mobile applications to market
> and
> > > stay 
> > > ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> > > http://p.sf.net/sfu/devconference
> > > _______________________________________________
> > > Csound-devel mailing list
> > > Csound-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/csound-devel
> > 
> > 
> >
> ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF,
> CA
> > is the only developer event you need to attend this year. Jumpstart
> your
> > developing skills, take BlackBerry mobile applications to market and
> stay 
> > ahead of the curve. Join us from November 9 - 12, 2009. Register
> now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> -- 
> Saludos,
> Felipe Sateler


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael Gogins wrote:

> This would require changing the user's Python code to be specialized
> for the different versions of csnd.
> 
> That is, csndf.pyd and csndd.pyd would require "import csndf" and
> "import csndd". And then csndf.thisfunction() and csndd.this
> function()...

Isn't it possible to something like:

   import csndd as csnd

Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sat, 2009-10-24 at 11:36 +1100, Erik de Castro Lopo wrote:
> Michael Gogins wrote:
> 
> > This would require changing the user's Python code to be specialized
> > for the different versions of csnd.
> > 
> > That is, csndf.pyd and csndd.pyd would require "import csndf" and
> > "import csndd". And then csndf.thisfunction() and csndd.this
> > function()...
> 
> Isn't it possible to something like:
> 
>    import csndd as csnd

Note that this solution would make every python app incompatible with
csound 5.12.

-- 
Saludos,
Felipe Sateler

On Fri, 2009-10-23 at 22:26 -0300, Felipe Sateler wrote:
> On Sat, 2009-10-24 at 11:36 +1100, Erik de Castro Lopo wrote:
> > Michael Gogins wrote:
> > 
> > > This would require changing the user's Python code to be specialized
> > > for the different versions of csnd.
> > > 
> > > That is, csndf.pyd and csndd.pyd would require "import csndf" and
> > > "import csndd". And then csndf.thisfunction() and csndd.this
> > > function()...
> > 
> > Isn't it possible to something like:
> > 
> >    import csndd as csnd
> 
> Note that this solution would make every python app incompatible with
> csound 5.12.

See my post about conditional imports, it's used all the time for
dealing with library dependencies in python web apps, there's no reason
you couldn't use it to prevent backward compatibility probelsm. You can
check anything you like and then import as an alias, all modules at
import from this one will get the final resolved object when they
import.

(random examples)
try: 
   import csndd as csnd
   assert csdn.__version__ == '5.12'
except:
   import csound as csnd

etc etc, it's really easy to do. It helps a lot if all modules add a
__version__ string to their top level namespace too.

Iain

> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have a couple of things to say about this:

1) Note that on OSX, there are libcsnd,dylib and libcsnd64.dylib. They  
are
symlinks to the respective versions of the library

2) I think the best way to go about this might be to
      a. Create duplicate interface files for python, java, etc,  
wrappers
      b. these would have at the top

                  %module csnd64

         instead of %module csnd
       c. Modify SConstruct to name/symlink csnd.dll etc csnd64.dll etc
           and use python_interface64.i  etc in the case of a doubles  
build.

Advantages:
    No backward incompatibility (there will still be csnd.pyd/_csnd.so)
    No need to edit SWIG-created files (csnd.py etc)
    Solution would work for all wrappers.

I would prefer if we adopted this simpler modification

Victor



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

In fact, there is no need for duplicate interface files, we can just use
ifdef USE_DOUBLE to select the module name.

Victor
On 24 Oct 2009, at 07:46, Victor Lazzarini wrote:

> I have a couple of things to say about this:
>
> 1) Note that on OSX, there are libcsnd,dylib and libcsnd64.dylib. They
> are
> symlinks to the respective versions of the library
>
> 2) I think the best way to go about this might be to
>      a. Create duplicate interface files for python, java, etc,
> wrappers
>      b. these would have at the top
>
>                  %module csnd64
>
>         instead of %module csnd
>       c. Modify SConstruct to name/symlink csnd.dll etc csnd64.dll etc
>           and use python_interface64.i  etc in the case of a doubles
> build.
>
> Advantages:
>    No backward incompatibility (there will still be csnd.pyd/_csnd.so)
>    No need to edit SWIG-created files (csnd.py etc)
>    Solution would work for all wrappers.
>
> I would prefer if we adopted this simpler modification
>
> Victor
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Would this be problem on Windows where there are no symlinks?

Cheers,
Andrés

On Sat, Oct 24, 2009 at 8:19 AM, Victor Lazzarini
 wrote:
> In fact, there is no need for duplicate interface files, we can just use
> ifdef USE_DOUBLE to select the module name.
>
> Victor
> On 24 Oct 2009, at 07:46, Victor Lazzarini wrote:
>
>> I have a couple of things to say about this:
>>
>> 1) Note that on OSX, there are libcsnd,dylib and libcsnd64.dylib. They
>> are
>> symlinks to the respective versions of the library
>>
>> 2) I think the best way to go about this might be to
>>      a. Create duplicate interface files for python, java, etc,
>> wrappers
>>      b. these would have at the top
>>
>>                  %module csnd64
>>
>>         instead of %module csnd
>>       c. Modify SConstruct to name/symlink csnd.dll etc csnd64.dll etc
>>           and use python_interface64.i  etc in the case of a doubles
>> build.
>>
>> Advantages:
>>    No backward incompatibility (there will still be csnd.pyd/_csnd.so)
>>    No need to edit SWIG-created files (csnd.py etc)
>>    Solution would work for all wrappers.
>>
>> I would prefer if we adopted this simpler modification
>>
>> Victor
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 


Andrés

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

No, just use  2 different libs. The reason for symlinks on Mac is to  
do with
the use of frameworks.

Victor
On 24 Oct 2009, at 08:31, Andres Cabrera wrote:

> Would this be problem on Windows where there are no symlinks?
>
> Cheers,
> Andrés
>
> On Sat, Oct 24, 2009 at 8:19 AM, Victor Lazzarini
>  wrote:
>> In fact, there is no need for duplicate interface files, we can  
>> just use
>> ifdef USE_DOUBLE to select the module name.
>>
>> Victor
>> On 24 Oct 2009, at 07:46, Victor Lazzarini wrote:
>>
>>> I have a couple of things to say about this:
>>>
>>> 1) Note that on OSX, there are libcsnd,dylib and libcsnd64.dylib.  
>>> They
>>> are
>>> symlinks to the respective versions of the library
>>>
>>> 2) I think the best way to go about this might be to
>>>      a. Create duplicate interface files for python, java, etc,
>>> wrappers
>>>      b. these would have at the top
>>>
>>>                  %module csnd64
>>>
>>>         instead of %module csnd
>>>       c. Modify SConstruct to name/symlink csnd.dll etc csnd64.dll  
>>> etc
>>>           and use python_interface64.i  etc in the case of a doubles
>>> build.
>>>
>>> Advantages:
>>>    No backward incompatibility (there will still be csnd.pyd/ 
>>> _csnd.so)
>>>    No need to edit SWIG-created files (csnd.py etc)
>>>    Solution would work for all wrappers.
>>>
>>> I would prefer if we adopted this simpler modification
>>>
>>> Victor
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart
>>> your
>>> developing skills, take BlackBerry mobile applications to market and
>>> stay
>>> ahead of the curve. Join us from November 9 - 12, 2009. Register  
>>> now!
>>> http://p.sf.net/sfu/devconference
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market  
>> and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
>
>
> Andrés
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Sat, 2009-10-24 at 07:46 +0100, Victor Lazzarini wrote:
> I have a couple of things to say about this:
> 
> 1) Note that on OSX, there are libcsnd,dylib and libcsnd64.dylib. They  
> are
> symlinks to the respective versions of the library

So the original request is already fulfilled in OSX? I think this should
be adopted by all platforms. However, a lot of code in SConstruct
assumes the 'csnd' name for the library. That would have to change, I
think.

> 
> 2) I think the best way to go about this might be to
>       a. Create duplicate interface files for python, java, etc,  
> wrappers
>       b. these would have at the top
> 
>                   %module csnd64
> 
>          instead of %module csnd
>        c. Modify SConstruct to name/symlink csnd.dll etc csnd64.dll etc
>            and use python_interface64.i  etc in the case of a doubles  
> build.
> 
> Advantages:
>     No backward incompatibility (there will still be csnd.pyd/_csnd.so)
>     No need to edit SWIG-created files (csnd.py etc)
>     Solution would work for all wrappers.
> 
> I would prefer if we adopted this simpler modification

I think a stub that loads any available version is better. Your solution
would make every application out there a user of the 32 bit sample size,
instead of giving flexibility. AFAIK, this flexibility cannot be given
on Java, but it can be given in lua and python. A python stub is easily
crafted in under 10 lines, I don't know lua but it should be similar.

-- 
Saludos,
Felipe Sateler

I think we should leave the decision between floats/doubles to  
application
designers (as in the other cases). I think my solution works for Java as
well, because we will have two JNIs with different names.

In OSX, lib_csnd.dylib lives inside the framework and if applications  
link to the
CsoundLib64.framework, they should link to it as well.

But I just noticed that there are some linking issues in 64bit that I  
need to fix.

Victor


On 25 Oct 2009, at 01:33, Felipe Sateler wrote:

> On Sat, 2009-10-24 at 07:46 +0100, Victor Lazzarini wrote:
>> I have a couple of things to say about this:
>>
>> 1) Note that on OSX, there are libcsnd,dylib and libcsnd64.dylib.  
>> They
>> are
>> symlinks to the respective versions of the library
>
> So the original request is already fulfilled in OSX? I think this  
> should
> be adopted by all platforms. However, a lot of code in SConstruct
> assumes the 'csnd' name for the library. That would have to change, I
> think.
>
>>
>> 2) I think the best way to go about this might be to
>>      a. Create duplicate interface files for python, java, etc,
>> wrappers
>>      b. these would have at the top
>>
>>                  %module csnd64
>>
>>         instead of %module csnd
>>       c. Modify SConstruct to name/symlink csnd.dll etc csnd64.dll  
>> etc
>>           and use python_interface64.i  etc in the case of a doubles
>> build.
>>
>> Advantages:
>>    No backward incompatibility (there will still be csnd.pyd/ 
>> _csnd.so)
>>    No need to edit SWIG-created files (csnd.py etc)
>>    Solution would work for all wrappers.
>>
>> I would prefer if we adopted this simpler modification
>
> I think a stub that loads any available version is better. Your  
> solution
> would make every application out there a user of the 32 bit sample  
> size,
> instead of giving flexibility. AFAIK, this flexibility cannot be given
> on Java, but it can be given in lua and python. A python stub is  
> easily
> crafted in under 10 lines, I don't know lua but it should be similar.
>
> -- 
> Saludos,
> Felipe Sateler
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I mean that if the application designer doesn't want to make that
choice, then don't force him to make one. In C, C++ or Java, I don't
think there is a way to avoid that. However, in Python there is no need
for an application to choose one version or the other (since there is no
float/double distinction in the language). Thus, a way to let the
application work with either version would be good, I think.

On Sun, 2009-10-25 at 06:26 +0000, Victor Lazzarini wrote:
> I think we should leave the decision between floats/doubles to  
> application
> designers (as in the other cases). I think my solution works for Java as
> well, because we will have two JNIs with different names.
> 
> In OSX, lib_csnd.dylib lives inside the framework and if applications  
> link to the
> CsoundLib64.framework, they should link to it as well.
> 
> But I just noticed that there are some linking issues in 64bit that I  
> need to fix.
> 
> Victor
> 
> 
> On 25 Oct 2009, at 01:33, Felipe Sateler wrote:
> 
> > On Sat, 2009-10-24 at 07:46 +0100, Victor Lazzarini wrote:
> >> I have a couple of things to say about this:
> >>
> >> 1) Note that on OSX, there are libcsnd,dylib and libcsnd64.dylib.  
> >> They
> >> are
> >> symlinks to the respective versions of the library
> >
> > So the original request is already fulfilled in OSX? I think this  
> > should
> > be adopted by all platforms. However, a lot of code in SConstruct
> > assumes the 'csnd' name for the library. That would have to change, I
> > think.
> >
> >>
> >> 2) I think the best way to go about this might be to
> >>      a. Create duplicate interface files for python, java, etc,
> >> wrappers
> >>      b. these would have at the top
> >>
> >>                  %module csnd64
> >>
> >>         instead of %module csnd
> >>       c. Modify SConstruct to name/symlink csnd.dll etc csnd64.dll  
> >> etc
> >>           and use python_interface64.i  etc in the case of a doubles
> >> build.
> >>
> >> Advantages:
> >>    No backward incompatibility (there will still be csnd.pyd/ 
> >> _csnd.so)
> >>    No need to edit SWIG-created files (csnd.py etc)
> >>    Solution would work for all wrappers.
> >>
> >> I would prefer if we adopted this simpler modification
> >
> > I think a stub that loads any available version is better. Your  
> > solution
> > would make every application out there a user of the 32 bit sample  
> > size,
> > instead of giving flexibility. AFAIK, this flexibility cannot be given
> > on Java, but it can be given in lua and python. A python stub is  
> > easily
> > crafted in under 10 lines, I don't know lua but it should be similar.
> >
> > -- 
> > Saludos,
> > Felipe Sateler
> > ------------------------------------------------------------------------------
> > Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> > is the only developer event you need to attend this year. Jumpstart  
> > your
> > developing skills, take BlackBerry mobile applications to market and  
> > stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference_______________________________________________
> > Csound-devel mailing list
> > Csound-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
Saludos,
Felipe Sateler