If the SONAME needs bumping, I do not have any issues with it
too.
Victor

----- Original Message ----- 
From: "jpff" 
To: "Developer discussions" 
Cc: 
Sent: Tuesday, November 18, 2008 6:21 AM
Subject: Re: [Cs-dev] Forward planning


>> Also, int is not 16 bits, unless you are using a very old
>> machine. Did you mean 32 bits?
>
> I meant what I said.  There were parts of the code where it is assumed
> that an int is 16 bits.  Remember Csound used to run on DOS.
> There were also places where it was assumed long was 32bits, and this
> is a long-term trap.
>
> I have no objection to changing API version number, but I do not use
> the API
>
> ==John ffitch
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great 
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the 
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

victor wrote on 11/18/08 3:59 AM:

> If the SONAME needs bumping, I do not have any issues with it
> too.
> Victor

This might be the best solution.  But lets consider some of the
ramifications of increasing the API major version number (which would also
be done, right?).

Currently any "properly written" client of the API should be performing a
check such as this one soon after it starts:

    #define  MY_APP_MIN_CS_VERS    102  /* API 1.2 */
    #define  CS_INCOMPATIBLE_VERS  200  /* API 2.0 */
    int csAPIVs = csoundGetAPIVersion();
    if (csAPIVs < MY_APP_MIN_CS_VERS || csAPIVs >= CS_INCOMPATIBLE_VERS)
        DoIncompatibleCsoundLibraryError(csAPIVs);

So, any client making such a check will have to be patched and recompiled if
the API version number does increase to 2.0.  This is obvious and necessary
of course for incompatible changes to the API that will cause an application
to crash.  The current situation is not such an obvious case though and
32-bit applications that do not check the API version will likely continue
to work.  What would happen if the API version number is not increased to
2.0 but just the SONAME (I am not even sure that is an option) ?  What if
the changes to the 64-bit API are considered "bug fixes" ?

I am worried about some API clients being updated that have already become
somewhat neglected.  For example, I had planned to stop development of the
Mac OS 9 Csound front end, but I wanted to be able to continue to compile
new Csound libraries for it on occasion.  I may feel it necessary to produce
one more front end update now.  I also wonder whether MacCsound will be
recompiled since Matt is currently "stalled" on finding a solution to Intel
Mac compatibility.

This should be a simple update for client developers since few code changes
may be necessary. But some appropriate changes such as adjusting types of
client variables to match Csound might not be caught by the compiler.

I suggest that we ask client developers how an API version increase (and the
changes that make it necessary) will affect them before we bump the number.
In particular, we should get feedback from developers who are distributing
client apps "outside" of the Csound sourceforge projects (such as Matt
Ingalls, Jean Piché, OLPC, etc.).

Finally, there have been proposed additions to Csound in the past that were
delayed because they would have required incompatible API changes.  We
decided to wait for those new features until a time when they could all be
made together so that the API would not introduce incompatibilities too
often.  Will consideration be given to implementing those features now?  (I
can't remember what they were, but I could go back through the list archives
...)

In the future, I hope that the ramifications of these types of changes to
Csound can be discussed before they are included in a release.  As for now,
increasing the API major version number seems almost unavoidable.

Anthony

> ----- Original Message -----
> From: "jpff" 
> To: "Developer discussions" 
> Cc: 
> Sent: Tuesday, November 18, 2008 6:21 AM
> Subject: Re: [Cs-dev] Forward planning
> 
> 
>>> Also, int is not 16 bits, unless you are using a very old
>>> machine. Did you mean 32 bits?
>> 
>> I meant what I said.  There were parts of the code where it is assumed
>> that an int is 16 bits.  Remember Csound used to run on DOS.
>> There were also places where it was assumed long was 32bits, and this
>> is a long-term trap.
>> 
>> I have no objection to changing API version number, but I do not use
>> the API


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have not had the time to go through old emails (or even reply to all my
new ones) this week.  There is at least one item on my own agenda that might
be good to implement now.  I would like to make Csound more flexible on
accepting fewer or more p-fields for instruments.  Currently, you get a
warning for every note where the number of p-fields does not match the
number explicitly referenced in the orchestra.  Since it is now possible to
"indirectly" reference p-fields (with the pcount and pindex opcodes), a
mechanism for allowing the user to set a range of acceptable numbers of
p-fields (say with an orchestra opcode) would be a nice cosmetic
enhancement.

I bring this up because I believe it will require changing some data
structures.  I have not yet investigated whether it would be an API/ABI
change, but now seems like a good time to look.

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

Felipe Sateler wrote on 11/23/08 9:50 PM:

> El 19/11/08 19:07 Anthony Kozar escribió:
> 
>> Finally, there have been proposed additions to Csound in the past that were
>> delayed because they would have required incompatible API changes.

> I've been searching the archives, and have only found out about a few by
> Michael Gogins that I think better fit a csound6 development tree rather than
> a api bump. Have you found anything else?


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think that this is a good idea.  I doubt it requires any API changes so it
can probably be implemented anytime.

I have one question about how this would work.  I assume we would add a
UDODIR environment variable that would point to one (or more) directories to
search.  It would probably be a good idea to limit loaded files to those
with the extension ".udo" or something like that.  The question is whether
all .udo files should be loaded before the orchestra is or should UDOs be
loaded on a as needed basis.  In the latter case, I could see requiring only
one UDO per file with the name of the file being the UDO identifier plus
".udo" so that Csound can easily locate UDOs when needed.  This still might
not be an easy thing to implement since Csound usually expects all UDOs to
be defined before any instrument blocks (correct?) and defining an UDO in
the middle of parsing an instrument might require more changes to the
current code than anyone would like to make.

Anthony

Rory Walsh wrote on 11/26/08 4:12 PM:

> I might as well chip in here although it's nothing to do with
> Anthony's request. I would like to see a default UDO folder so that
> users can use them without having to a)include the entire UDO text,
> and b)use includes which can get messy. The reason I feel the
> equivalent feature in Pd(an abstract) is used extensively is because
> they can seamlessly be entered into a patch as if they were an
> internal object. Instead of a dedicated plugin directory what about if
> they could just be dumped in the plugins folder. I don't use UDOs too
> often but I think a feature like this might encourage people to start
> developing and sharing more UDOs.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm sure that this _could_ be made dynamic one way or another (either as a
user-controlled option or automatically) but it will require some
investigation to see how complicated this will be.  I'll try to take a look
in December unless someone else really wants to work on this.

Anthony

David Akbari wrote on 11/26/08 4:40 PM:

> Would it be possible to also alter the way that the maximum number of
> input/output arguments to a UDO are defined? I believe that it is
> still a static declaration of 64, which for some work (for example
> with the Lemur) provides a lot of trouble considering how much data
> that and other OSC based hardware can output. Naturally I'm not
> suggesting to just increase the number of inputs but if there is
> something dynamic that can be implemented similarly to the p-field
> idea that you suggest then it may be worth while to add to the
> language.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Then we need a tag for UDO in teh csd structure

I would like to revisit the whole load-everything process this was never
my intention and I think it rather destroys the idea of having loadable
code.

Perhaps a .csd tag for what to load or where to look?  I realise this
would be quite a change, but the current version is just not right.

==John ff

> It might be a good idea to look for UDOs not only on the UDO directory
> but also on the current directory, that way, UDOs can be distributed
> with the csds without need to install anything.
>
> Cheers,
> Andrés
>
> On Thu, Nov 27, 2008 at 4:33 AM, Rory Walsh  wrote:
>> Perhaps they can be loaded before the orchestra by default. I see your
>> point about loading them on an 'as needed' basis. An option to turn
>> off loading of UDOs could be added to the command line.
>>
>> Rory.
>>
>>
>>
>> 2008/11/26 Anthony Kozar :
>>> I think that this is a good idea.  I doubt it requires any API changes
>>> so it
>>> can probably be implemented anytime.
>>>
>>> I have one question about how this would work.  I assume we would add a
>>> UDODIR environment variable that would point to one (or more)
>>> directories to
>>> search.  It would probably be a good idea to limit loaded files to
>>> those
>>> with the extension ".udo" or something like that.  The question is
>>> whether
>>> all .udo files should be loaded before the orchestra is or should UDOs
>>> be
>>> loaded on a as needed basis.  In the latter case, I could see requiring
>>> only
>>> one UDO per file with the name of the file being the UDO identifier
>>> plus
>>> ".udo" so that Csound can easily locate UDOs when needed.  This still
>>> might
>>> not be an easy thing to implement since Csound usually expects all UDOs
>>> to
>>> be defined before any instrument blocks (correct?) and defining an UDO
>>> in
>>> the middle of parsing an instrument might require more changes to the
>>> current code than anyone would like to make.
>>>
>>> Anthony
>>>
>>> Rory Walsh wrote on 11/26/08 4:12 PM:
>>>
>>>> I might as well chip in here although it's nothing to do with
>>>> Anthony's request. I would like to see a default UDO folder so that
>>>> users can use them without having to a)include the entire UDO text,
>>>> and b)use includes which can get messy. The reason I feel the
>>>> equivalent feature in Pd(an abstract) is used extensively is because
>>>> they can seamlessly be entered into a patch as if they were an
>>>> internal object. Instead of a dedicated plugin directory what about if
>>>> they could just be dumped in the plugins folder. I don't use UDOs too
>>>> often but I think a feature like this might encourage people to start
>>>> developing and sharing more UDOs.
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> --
>
>
> Andrés
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The CSD/Orc/Sco directory (not necessarily the same as the Unix concept of
the "current directory") could be appended to UDODIR in the same way that it
is for SSDIR, SADIR, and INCDIR.  Would that be sufficient?

Anthony

Andres Cabrera wrote on 11/27/08 8:32 AM:

> It might be a good idea to look for UDOs not only on the UDO directory
> but also on the current directory, that way, UDOs can be distributed
> with the csds without need to install anything.
> 
> Cheers,
> Andrés
> 
> On Thu, Nov 27, 2008 at 4:33 AM, Rory Walsh  wrote:
>> Perhaps they can be loaded before the orchestra by default. I see your
>> point about loading them on an 'as needed' basis. An option to turn
>> off loading of UDOs could be added to the command line.


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Does it load all plugins even when they're not used?
I think the best way would be if csound at the point where it decides if
an opcode is missing or not first searches the current dir (or better,
the dir of the csd/orc file) and then OPCODEDIR etc.. I guess this
happens in the parser or in another phase after creating the syntax tree
or whatever the parsers output is. No need to manually specify what to
load, and where to look is already in OPCODEDIR and it could search UDOs
there too.

jpff@cs.bath.ac.uk wrote:
> Then we need a tag for UDO in teh csd structure
> 
> I would like to revisit the whole load-everything process this was never
> my intention and I think it rather destroys the idea of having loadable
> code.
> 
> Perhaps a .csd tag for what to load or where to look?  I realise this
> would be quite a change, but the current version is just not right.
> 
> ==John ff
> 
>> It might be a good idea to look for UDOs not only on the UDO directory
>> but also on the current directory, that way, UDOs can be distributed
>> with the csds without need to install anything.
>>
>> Cheers,
>> Andrés
>>
>> On Thu, Nov 27, 2008 at 4:33 AM, Rory Walsh  wrote:
>>> Perhaps they can be loaded before the orchestra by default. I see your
>>> point about loading them on an 'as needed' basis. An option to turn
>>> off loading of UDOs could be added to the command line.
>>>
>>> Rory.
>>>
>>>
>>>
>>> 2008/11/26 Anthony Kozar :
>>>> I think that this is a good idea.  I doubt it requires any API changes
>>>> so it
>>>> can probably be implemented anytime.
>>>>
>>>> I have one question about how this would work.  I assume we would add a
>>>> UDODIR environment variable that would point to one (or more)
>>>> directories to
>>>> search.  It would probably be a good idea to limit loaded files to
>>>> those
>>>> with the extension ".udo" or something like that.  The question is
>>>> whether
>>>> all .udo files should be loaded before the orchestra is or should UDOs
>>>> be
>>>> loaded on a as needed basis.  In the latter case, I could see requiring
>>>> only
>>>> one UDO per file with the name of the file being the UDO identifier
>>>> plus
>>>> ".udo" so that Csound can easily locate UDOs when needed.  This still
>>>> might
>>>> not be an easy thing to implement since Csound usually expects all UDOs
>>>> to
>>>> be defined before any instrument blocks (correct?) and defining an UDO
>>>> in
>>>> the middle of parsing an instrument might require more changes to the
>>>> current code than anyone would like to make.
>>>>
>>>> Anthony
>>>>
>>>> Rory Walsh wrote on 11/26/08 4:12 PM:
>>>>
>>>>> I might as well chip in here although it's nothing to do with
>>>>> Anthony's request. I would like to see a default UDO folder so that
>>>>> users can use them without having to a)include the entire UDO text,
>>>>> and b)use includes which can get messy. The reason I feel the
>>>>> equivalent feature in Pd(an abstract) is used extensively is because
>>>>> they can seamlessly be entered into a patch as if they were an
>>>>> internal object. Instead of a dedicated plugin directory what about if
>>>>> they could just be dumped in the plugins folder. I don't use UDOs too
>>>>> often but I think a feature like this might encourage people to start
>>>>> developing and sharing more UDOs.
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>>> challenge
>>>> Build the coolest Linux based applications with Moblin SDK & win great
>>>> prizes
>>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>>> world
>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>> -------------------------------------------------------------------------
>>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>>> challenge
>>> Build the coolest Linux based applications with Moblin SDK & win great
>>> prizes
>>> Grand prize is a trip for two to an Open Source event anywhere in the
>>> world
>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>> --
>>
>>
>> Andrés
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


-- 
/Jonatan         [ http://kymatica.com ]

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> The CSD/Orc/Sco directory (not necessarily the same as the Unix concept of
> the "current directory") could be appended to UDODIR in the same way that it
> is for SSDIR, SADIR, and INCDIR.  Would that be sufficient?

With all th etrouble that environment variables have caused I am not
convinced that we should go this way
==John ffitch

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

> Does it load all plugins even when they're not used?

Yes.  That is why I would like to revisit this area.  That was never
my intent.
==John ffitch

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

But it is not necessary to use the auto-loading feature.  Simply do not
set OPCODEDIR and use the --opcode-lib= flag to load only the libraries
that you want instead.

I think it is a big mistake to remove the auto-loading of plugins though. 
I cannot remember which opcodes are in which plugins most of the time --
many locations are illogical.  And there is no end user method for
discovering which opcodes are in which plugins.  I proposed a system of
adding metadata to plugins that could be read by a simple utility so that
users could discover the location of opcodes and other information, but
the idea was ignored.

Anthony

On Fri, November 28, 2008 1:27 am, jpff wrote:
>> Does it load all plugins even when they're not used?
>
> Yes.  That is why I would like to revisit this area.  That was never
> my intent.
> ==John ffitch



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have that utility that records where opcodes are.

==John ffitch

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

(This reply is seomwhat long and probably not very useful, so skip it if you
are short on time ...)

Felipe Sateler wrote on 11/19/08 7:06 PM:

> El 19/11/08 19:07 Anthony Kozar escribió:

>> Currently any "properly written" client of the API should be performing a
>> check such as this one soon after it starts:
>> 
>> #define  MY_APP_MIN_CS_VERS    102  /* API 1.2 */
>> #define  CS_INCOMPATIBLE_VERS  200  /* API 2.0 */
>> int csAPIVs = csoundGetAPIVersion();
>> if (csAPIVs < MY_APP_MIN_CS_VERS || csAPIVs >= CS_INCOMPATIBLE_VERS)
>> DoIncompatibleCsoundLibraryError(csAPIVs);
>> 
>> So, any client making such a check will have to be patched and recompiled
>> if the API version number does increase to 2.0.  This is obvious and
>> necessary of course for incompatible changes to the API that will cause an
>> application to crash. The current situation is not such an obvious case
>> though and 32-bit applications that do not check the API version will
>> likely continue to work.
> 
> If the API major version is bumped, then the programs won't load the new
> library because it is named differently. In linux, libcsound.so.5.1,
> csound32.dll.5.1 on windows.

Sorry, but I don't know much about linking/loading on Linux (or Windows).  I
thought that a lot of linux software is packaged with a versioned library
(libfoo.so.X.Y) and a non-versioned symlink to the library (libfoo.so).  I
thought that programs that are linked to libfoo.so at compile time would be
loaded with whatever version of the library is currently pointed to by the
symlink at runtime.  But, I must have misunderstood, in which case, it
sounds like a major version increase will not be a problem on Linux.

> From what I see/guess in SConstruct, OSX frameworks are versioned too.

I was reading about this last week.  I was aware of framework versions, but
there is also another mechanism on OS X for setting the compatibility of a
library and I wasn't sure if the second mechanism was being used.  It does
look like it is, but there are other complications.

One issue would be to make sure that the OS X installers will not overwrite
the old 5.1 version of the framework when installing the 5.2 version.
Alternatively, we could include the latest 5.1-compatible version of the
framework with the new installers (which is Apple's recommended policy) but
that could be a logistical headache for packaging.

> Thus, the above check you describe is
> unnecessary, since the dynamic loader won't even try to load the new library
> and fail if the old one is not available. This has the advantage that you can
> install different versions of the library side by side, to support both old
> and new clients (of course, an appropriate OPCODEDIR would have to be set to
> match each library with its plugins. I have code in SConstruct that installs
> plugins to a versioned dir on linux, and sets the default OPCODEDIR
> accordingly, maybe it's useful on other platforms too?).

OPCODEDIR would be the other problem that I would anticipate on OS X.  For a
GUI client that is using the old framework version, installing the new
framework will change OPCODEDIR and will appear to break the client.  I
suppose this might be "fixable" by launching the client with a unique
environment via a shell script but whether the "typical" user will know how
to do that or whether the symptoms of the problem will suggest such a
solution are doubtful.  I think we will need to do some testing and try to
come up with a proactive solution before releasing a new framework version.
 
> BTW, I don't think clients should track the incompatible version. It's the
> library developers + dynamic loader's job to make sure that incompatible
> versions of the library aren't loaded for inappropriate clients (via the
> soname).

I don't think it is such a bad practice.  The open source world is such that
lots of people who are not the primary developers end up packaging and
distributing software.  For Csound, by definition, version 2.0 of the
library is assumed to be incompatible with all 1.x versions.  I little
defensive programming in case one of Csound's packagers gets the library
versioning incorrect does not hurt.  Also, since library versions are
controlled on several platforms by their filenames, they are
user-modifiable.  Better that a client detect an incompatible version that
should not have been loaded and report it than mysteriously crash.

Proper library versioning has been particularly a concern for me on Mac OS 9
where the compatibility information of Csound5Lib must be manually updated
by the person compiling the library.  Even though I was planning to
discontinue development for this platform, I probably should update the OS 9
project files to reflect the version change in case someone else attempts to
use them.

> Ideally, the API and ABI would be versioned separately. Maybe it is a good
> time to separate them? ABI can be preserved across API versions (what is done
> now via the API minor version), and API can be preserved across ABI versions
> (which can't be done now).

I don't see a great need for this separation.  I think most of the Csound
developers use the term "API" to refer to both aspects and they are somewhat
intertwined because Csound's plugin API includes both function pointers and
data structures.

> If macs version the framework, then both frameworks should be installable at
> the same time, and the user should only have to care about having an
> appropriate OPCODEDIR.

As I mentioned, these assumptions/considerations need to be checked.

I do thank you, Felipe, for explaining how library loading will not be a
problem for Windows and Linux.  I would like to do some testing on OS X to
see how old clients will work when the library version is increased --
hopefully before the next release.

I hope that we can avoid increasing the major API version at "unscheduled"
times in the future though as we do not want to create a confusing tangle of
of answers to "which version(s) of Csound do I have to install to use
clients X, Y, and Z at the same time?"

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/




------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am thinking that the code that is conditionally compiled with SDFT should
be made permanent.  I believe these changes techinally introduced an
incompatible change to a small part of Csound's ABI which was ignored.
Since we will now be increasing the API version, it seems like a bad idea to
me to keep an optional compilation flag that will break compatibility in the
future if someone turns it off.

Anthony

Felipe Sateler wrote on 11/23/08 9:50 PM:

> El 19/11/08 19:07 Anthony Kozar escribió:
> 
>> Finally, there have been proposed additions to Csound in the past that were
>> delayed because they would have required incompatible API changes.  We
>> decided to wait for those new features until a time when they could all be
>> made together so that the API would not introduce incompatibilities too
>> often.  Will consideration be given to implementing those features now?  (I
>> can't remember what they were, but I could go back through the list
>> archives ...)
> 
> I've been searching the archives, and have only found out about a few by
> Michael Gogins that I think better fit a csound6 development tree rather than
> a api bump. Have you found anything else?


------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

David, 

This part of the code is of course pretty complex.  I don't pretend to
understand it, but I do see that the xin and xout opcodes get replaced with
alternate opcodes (".xin64" or ".xout64") when the number of respective
arguments is more than 16 (".xin256" or ".xout256" if more than 64).  These
alternate opcodes have room for 64 or 256 arguments each.  I suspect that
this method is being used instead of dynamically allocating because Csound
stores a fixed value for the size of each opcode's private data space.  I am
not confident enough to try to change this -- perhaps the new parser will
allow a smarter approach?

The manual also mentions that the maximums are 256.  So it definitely
appears as if the maximum number of inputs and outputs are now each 256.  Is
that enough for now?

Anthony Kozar
mailing-lists-1001 AT anthonykozar DOT net
http://anthonykozar.net/

David Akbari wrote on 11/26/08 4:40 PM:

> Would it be possible to also alter the way that the maximum number of
> input/output arguments to a UDO are defined? I believe that it is
> still a static declaration of 64, which for some work (for example
> with the Lemur) provides a lot of trouble considering how much data
> that and other OSC based hardware can output. Naturally I'm not
> suggesting to just increase the number of inputs but if there is
> something dynamic that can be implemented similarly to the p-field
> idea that you suggest then it may be worth while to add to the
> language.


------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net