2005-01-27      Istvan Varga    
         * Engine/entry1.c:
         * Engine/entry2.c:
         * Engine/express.c:
         * Engine/otran.c:
         * Engine/rdorch.c:
           use '.' instead of '_' in internal opcode names (e.g. osc.kk
           instead of osc_kk); this allows the use of the underscore
           character in real opcode names. Many files in Opcodes/ were
           also changed.
         * strings/makedb.c:
         * strings/all_strings, strings/english-strings, strings/french-strings:
         * H/text.h:
         * Top/getstring.c:
           new implementation for localized messages. Uses Str("...")
           instead of Str(X_nnnn,"..."). This also needed replacement
           of Str() in a large number of files.
         * Engine/oload.c, Engine/otran.c, H/csoundCore.h:
           use 'int' type for variable indexes instead of 'short';
           needs some testing
         * Engine/oload.c, Top/main.c, Top/one_file.c:
           removed API function prototypes, use csound.h instead
         * Top/csound.c, H/csound.h, Engine/oload.c, Engine/otran.c:
           incorporated some changes from the 'unofficial' 4.24.1 version,
           including timer functions, better checking of sr/kr/ksmps, and
           some fixes
         * Engine/memalloc.c: removed references to free_strings()
         * H/csdl.h: use csoundLocalizeString() instead of getstring()
         * InOut/widgets.cpp:
           include  instead of , and use stringstream
           instead of strstream
         * Opcodes/midiops3.c: fixed undefined order of operations
         * SConstruct: added /usr/X11R6/include to include paths on Linux



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan, 

I am glad that you are back and contributing to Csound again.  However, a
number of these changes are pretty major redesigns.  Perhaps it would have
been better to discuss them on the list before committing them.


On 1/27/05 2:51 PM, Istvan Varga  etched in stone:

> 2005-01-27      Istvan Varga    
> * Engine/entry1.c:
> * Engine/entry2.c:
> * Engine/express.c:
> * Engine/otran.c:
> * Engine/rdorch.c:
> use '.' instead of '_' in internal opcode names (e.g. osc.kk
> instead of osc_kk); this allows the use of the underscore
> character in real opcode names. Many files in Opcodes/ were
> also changed.

This is a rather significant change which has been discussed but not
pursued.

> * strings/makedb.c:
> * strings/all_strings, strings/english-strings, strings/french-strings:
> * H/text.h:
> * Top/getstring.c:
> new implementation for localized messages. Uses Str("...")
> instead of Str(X_nnnn,"..."). This also needed replacement
> of Str() in a large number of files.

I've looked at your old code for this recently, and I have to wonder if
indexing strings via the strings themselves is really a better idea than
indexing them by numbers.

For one thing, I am pretty sure that you just completely broke the getstring
code on MacOS 9.  The current Mac implementation requires that the strings
be numbered.

Could you please explain why you feel this change is necessary?

> * Engine/oload.c, Engine/otran.c, H/csoundCore.h:
> use 'int' type for variable indexes instead of 'short';
> needs some testing

If you really want to make sure that a larger integer size is used, you
should use long, not int.  int is the same size as short on some platforms.


Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Istvan,

Thanks! Things compiled here on FC3 just fine and everything is running 
very very smoothly.  I noticed you have put the --expression-opt option 
in: is the documentation from your 4.24.0 changeLog still applicable and 
should this be what is used if I update the manual? (I have pasted in 
what I found below)

  * new command line option (--expression-opt) that turns on some
    optimizations in expressions:
      * redundant assignment operations are eliminated whenever
        possible. This means that for example this line
          a1 = a2 + a3
        will compile as
          a1 Add a2, a3
        instead of
          #a0 Add a2, a3
          a1 = #a0
        saving a temporary variable and an opcode call. Less opcode
        calls result in reduced CPU usage (an average orchestra may
        compile about 10% faster with --expression-opt, but it
        depends largely on how many expressions are used, what the
        control rate is (see also below), etc.; thus, the difference
        may be less, but also much more).
      * number of a- and k-rate temporary variables is significantly
        reduced. This expression
          (a1 + a2 + a3 + a4)
        will compile as
          #a0 Add a1, a2
          #a0 Add #a0, a3
          #a0 Add #a0, a4       ; (the result is in #a0)
        instead of
          #a0 Add a1, a2
          #a1 Add #a0, a3
          #a2 Add #a1, a4       ; (the result is in #a2)
        The advantages of less temporary variables are:
          * less cache memory is used, which may improve performance
            of orchestras with many a-rate expressions and a low
            control rate (e.g. ksmps = 100)
          * large orchestras may load faster due to less different
            identifier names
          * index overflow errors (i.e. when messages like this
              Case2: indx=-56004 (ffff253c); (short)indx = 9532 (253c)
            are printed and odd behavior or a Csound crash occurs) may
            be fixed, because such errors are triggered by too many
            different (especially a-rate) variable names in a single
            instrument.
        Note that this optimization (due to technical reasons) is not
        performed on i-rate temporary variables.
    NOTE: when --expression-opt is turned on, it is not allowed to
    use the i() function with an expression argument.

Thanks,
steven



Istvan Varga wrote:

> 2005-01-27      Istvan Varga    
>         * Engine/entry1.c:
>         * Engine/entry2.c:
>         * Engine/express.c:
>         * Engine/otran.c:
>         * Engine/rdorch.c:
>           use '.' instead of '_' in internal opcode names (e.g. osc.kk
>           instead of osc_kk); this allows the use of the underscore
>           character in real opcode names. Many files in Opcodes/ were
>           also changed.
>         * strings/makedb.c:
>         * strings/all_strings, strings/english-strings, 
> strings/french-strings:
>         * H/text.h:
>         * Top/getstring.c:
>           new implementation for localized messages. Uses Str("...")
>           instead of Str(X_nnnn,"..."). This also needed replacement
>           of Str() in a large number of files.
>         * Engine/oload.c, Engine/otran.c, H/csoundCore.h:
>           use 'int' type for variable indexes instead of 'short';
>           needs some testing
>         * Engine/oload.c, Top/main.c, Top/one_file.c:
>           removed API function prototypes, use csound.h instead
>         * Top/csound.c, H/csound.h, Engine/oload.c, Engine/otran.c:
>           incorporated some changes from the 'unofficial' 4.24.1 version,
>           including timer functions, better checking of sr/kr/ksmps, and
>           some fixes
>         * Engine/memalloc.c: removed references to free_strings()
>         * H/csdl.h: use csoundLocalizeString() instead of getstring()
>         * InOut/widgets.cpp:
>           include  instead of , and use stringstream
>           instead of strstream
>         * Opcodes/midiops3.c: fixed undefined order of operations
>         * SConstruct: added /usr/X11R6/include to include paths on Linux
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>   rdorch.c: was a more difficult excercise, as it is quite different
>     from 4.24.1; I added (hopefully all) the changes relevant to
>     --expression-opt, but testing is needed to find if there are any
>     cases when it does not behave as well as the original version

Just let me know when you think I should run my heavy load benchmarks 
against 4.23.4.2 and 4.24.1 again. I'd certainly love to be able to move 
to csound5 for gig use.	

Those did make it to the list right? I did not see any comments on them 
one way or another. Or maybe there is just not much to say. ;)

iain



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

steven yi wrote:

> Thanks! Things compiled here on FC3 just fine and everything is running 
> very very smoothly.  I noticed you have put the --expression-opt option 
> in: is the documentation from your 4.24.0 changeLog still applicable and 
> should this be what is used if I update the manual? (I have pasted in 
> what I found below)

It has been ported from 4.24.1, the files changed are:
   csoundCore.h: added 'int expr_opt' to the OPARMS structure
   oload.c: same as above
   argdecode.c: added '--expression-opt' to long options help and
     long options parser (sets O.expr_opt)
   express.c: this file is now pretty much identical to the one
     in 4.24.1, save for minor changes in indentation, comments etc.
     Fortunately, it was not extensively modified between Csound4 and
     Csound5, so the merge was easy.
   rdorch.c: was a more difficult excercise, as it is quite different
     from 4.24.1; I added (hopefully all) the changes relevant to
     --expression-opt, but testing is needed to find if there are any
     cases when it does not behave as well as the original version
As far as the documentation is concerned, what you have quoted from
the changelogs is correct (although 'index overflow errors' should
not occur now (as indexes were made 32-bit), with or without
expression optimization, unless I made errors in porting the relevant
code).


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> I am glad that you are back and contributing to Csound again.  However, a
> number of these changes are pretty major redesigns.  Perhaps it would have
> been better to discuss them on the list before committing them.

The changes may look quite extensive, although only two affect a large number
of files (and these were simple search/replace changes):
   1. now Str("...") is used instead of Str(X_nnnn,"...").
   2. undocumented internal opcode names like "osc_kk" or "rnd31_a"
      have been replaced with "osc.kk", "rnd31.a", etc. The purpose
      of this is to allow use of the '_' character in real (i.e. not
      internally generated by the parser) opcode names, e.g. FLpanel_end.
These can be discussed in more detail, but I can easily revert any
changes if requested.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "Anthony" == Anthony Kozar  writes:

 Anthony> Istvan, 
 Anthony> I am glad that you are back and contributing to Csound again.  However, a
 Anthony> number of these changes are pretty major redesigns.  Perhaps it would have
 Anthony> been better to discuss them on the list before committing them.


 Anthony> On 1/27/05 2:51 PM, Istvan Varga  etched in stone:

 >> 2005-01-27      Istvan Varga    
 >> * Engine/entry1.c:
 >> * Engine/entry2.c:
 >> * Engine/express.c:
 >> * Engine/otran.c:
 >> * Engine/rdorch.c:
 >> use '.' instead of '_' in internal opcode names (e.g. osc.kk
 >> instead of osc_kk); this allows the use of the underscore
 >> character in real opcode names. Many files in Opcodes/ were
 >> also changed.

 Anthony> This is a rather significant change which has been discussed but not
 Anthony> pursued.

But if i get the parser rewrite it is all rather irrelevant which is
why i have been opposed to this change.

Did the files filter2, bus, midiops2, midiops3, oscbnk,spectra,
ugens6, uggab and ugmoss get changed as well? Did not notice

 >> * Engine/oload.c, Engine/otran.c, H/csoundCore.h:
 >> use 'int' type for variable indexes instead of 'short';
 >> needs some testing

 Anthony> If you really want to make sure that a larger integer size is used, you
 Anthony> should use long, not int.  int is the same size as short on some platforms.

also parser

==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

gogins@pipeline.com wrote:

 > I don"t think we need to worry about int being short any more.

The issue was not that 'int' may be 16 bit (it is at least 32 bit
on any modern system), but rather that the 'short' type (which is
usually 16 bit) was used as the index to the instrument variable
pools, limiting an instrument to have no more than about 32000
local variables. That may sound a lot, but an a-rate variable takes
up ksmps locations, so with ksmps=100, you are limited to about
320 a-rate variables in a single instrument. To make things worse,
the expression parser generates temporary variables that also take
up space (more than one would think), so it is quite possible to
have an index overflow error with large and complex instruments.
I made changes so that now the 'int' type is used for this purpose,
eliminating the limitation.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sounds good; I'll add this to the docs (with a note that this is a 
cound5 option) along with the other things you sent (UDO/Subinstrument) 
in during this weekend.  Apologies again for the delay in updating!

steven


Istvan Varga wrote:
> steven yi wrote:
> 
>> Thanks! Things compiled here on FC3 just fine and everything is 
>> running very very smoothly.  I noticed you have put the 
>> --expression-opt option in: is the documentation from your 4.24.0 
>> changeLog still applicable and should this be what is used if I update 
>> the manual? (I have pasted in what I found below)
> 
> 
> It has been ported from 4.24.1, the files changed are:
>   csoundCore.h: added 'int expr_opt' to the OPARMS structure
>   oload.c: same as above
>   argdecode.c: added '--expression-opt' to long options help and
>     long options parser (sets O.expr_opt)
>   express.c: this file is now pretty much identical to the one
>     in 4.24.1, save for minor changes in indentation, comments etc.
>     Fortunately, it was not extensively modified between Csound4 and
>     Csound5, so the merge was easy.
>   rdorch.c: was a more difficult excercise, as it is quite different
>     from 4.24.1; I added (hopefully all) the changes relevant to
>     --expression-opt, but testing is needed to find if there are any
>     cases when it does not behave as well as the original version
> As far as the documentation is concerned, what you have quoted from
> the changelogs is correct (although 'index overflow errors' should
> not occur now (as indexes were made 32-bit), with or without
> expression optimization, unless I made errors in porting the relevant
> code).
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

OK.  I guess we'll just see how all the changes work and adjust if necessary
:)

Anthony

On 1/28/05 7:59 AM, Istvan Varga  etched in stone:

> The changes may look quite extensive, although only two affect a large number
> of files (and these were simple search/replace changes):

> These can be discussed in more detail, but I can easily revert any
> changes if requested.



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

OK, that's one vote to revert to the old version. I would like
to hear opinions about which one of the following three options
should be chosen:

   1. old getstring: printf(Str(X_nnnn,"..."))
   2. new getstring: printf(Str("..."))
   3. remove getstring: printf("...")

Removing getstring entirely would make sense, as the string databases
are not actively maintained (other than fixing problems with existing
strings, but no new translations or languages have been added in
recent years), and the system is really just an annoyance to both users
and developers without much practical use.
Without answers to this post, I will probably restore the old getstring
(that requires a number index), in response to complaints about breaking
code.

Anthony Kozar wrote:

> I've looked at your old code for this recently, and I have to wonder if
> indexing strings via the strings themselves is really a better idea than
> indexing them by numbers.
> 
> For one thing, I am pretty sure that you just completely broke the getstring
> code on MacOS 9.  The current Mac implementation requires that the strings
> be numbered.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> If you really want to make sure that a larger integer size is used, you
> should use long, not int.  int is the same size as short on some platforms.

Does anyone actually use a system where ints and pointers are still 16 bit ?
I think platforms with a 16 bit word size can really be considered obsolete
now.
On the other hand, using long is rarely useful, as it is usually not 'long'
in any way (in most cases, both sizeof(int) and sizeof(long) are 4), and is
usually just a source of confusion. It *may* be 64 bit on some platforms, but
you cannot rely on that. If you need a 64 bit variable, use int64_t/uint64_t
from stdint.h.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 1/30/05 5:02 AM, Istvan Varga  etched in stone:

> Removing getstring entirely would make sense, as the string databases
> are not actively maintained (other than fixing problems with existing
> strings, but no new translations or languages have been added in
> recent years), and the system is really just an annoyance to both users
> and developers without much practical use.

I have mixed feelings about this.  I certainly have not been good about
creating new strings when I am modifying code.  But then there are
definitely some theoretical benefits to the system.  (Despite being someone
who only speaks English, I don't expect that the rest of the world should
have to :)

> Without answers to this post, I will probably restore the old getstring
> (that requires a number index), in response to complaints about breaking
> code.

I can certainly adapt if there are real benefits to the new system.  And
Csound has never been localized for other languages on MacOS 9 anyways.

But I do want to avoid the confusion of having external string databases and
users not knowing which database goes with which version of Csound.
(Currently on MacOS 9, the strings are integrated into the application's
resource fork.  One of the advantages of this is being able to have multiple
versions of Csound in the same folder while keeping their string databases
separate).

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> I have mixed feelings about this.  I certainly have not been good about
> creating new strings when I am modifying code.

Having eliminated the index number, you only need to enclose the string
with Str(), e.g. Str("blah"). If there is a translation for the string
literal "blah", then it will be translated; if not, then it will just
remain as it is. The disadvantage is that you need to be more careful
about typos, although the only adverse effect of a mistyped string is
that it will not be translated. You can also easily provide your own
translations for a plugin (or others can contribute), without the need
for a central authority to assign index numbers. The new system will
load all database files of the selected language from the directory
defined by CSSTRNGS, and any string that has been found in a database
will be translated.

> But then there are definitely some theoretical benefits to the system.
 > (Despite being someone who only speaks English, I don't expect that the
 > rest of the world should have to :)

I did not suggest to remove localization support (although I pointed out
some advantages of doing so), only asked for opinions about three possible
solutions. So far, I got two votes for removing support for multiple
languages (by Michael Gogins and Victor Lazzarini), you apparently prefer
the original getstring by John ffitch (although I am not sure), and finally
I would choose to either remove getstring or use the new one. Overall, the
idea of removing getstring seems to be most popular, but more posts on this
subject are needed, as a total of 4 answers may not be enough to make a
decision.

> But I do want to avoid the confusion of having external string databases and
> users not knowing which database goes with which version of Csound.
> (Currently on MacOS 9, the strings are integrated into the application's
> resource fork.  One of the advantages of this is being able to have multiple
> versions of Csound in the same folder while keeping their string databases
> separate).

The new system has a fixed, portable string database format. You can create a
database now (documentation on the format has been posted), and use it on any
future version of Csound - assuming that the code is not removed - on any
platform. Additionally, .xmg files of the old (number indexed) format are
simply ignored, and do not cause any problem.


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Istvan, thanks very much for clarifying the purpose and advantages of the
new system.  (And sorry for the delay in replying -- the dev list pace
recently has been incredible !)

Now that I have had a chance to look more closely at the new system, I would
like to vote in favor of keeping it.  But since the localization system has
never been used much, I would like to propose that it be a compile time
option that defaults to _off_.  This will satisfy the developers who think
it should be removed and most users who never use it, but will still allow
Csound to be compiled with localization support when needed.

Using the new system will require changes on the Mac side.  However, I agree
that it will provide some important advantages and I am willing to do the
work to accomadate it.  Most importantly, I think that the new system will
be significantly more efficient when no database is being used on MacOS 9.
(Currently, a built-in database is used even when the strings are not being
translated, which requires more memory and is slower).

Thanks for adding the code and for being patient enough to explain it to me
:)

Anthony Kozar
anthony.kozar@utoledo.edu
http://akozar.spymac.net/

On 2/1/05 6:42 AM, Istvan Varga  etched in stone:

> I did not suggest to remove localization support (although I pointed out
> some advantages of doing so), only asked for opinions about three possible
> solutions. So far, I got two votes for removing support for multiple
> languages (by Michael Gogins and Victor Lazzarini), you apparently prefer
> the original getstring by John ffitch (although I am not sure), and finally
> I would choose to either remove getstring or use the new one. Overall, the
> idea of removing getstring seems to be most popular, but more posts on this
> subject are needed, as a total of 4 answers may not be enough to make a
> decision.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Anthony Kozar wrote:

> Now that I have had a chance to look more closely at the new system, I would
> like to vote in favor of keeping it.  But since the localization system has
> never been used much, I would like to propose that it be a compile time
> option that defaults to _off_.  This will satisfy the developers who think
> it should be removed and most users who never use it, but will still allow
> Csound to be compiled with localization support when needed.

In fact, it is disabled by default, unless the user actually sets
a language in the CS_LANG environment variable. Without any database
files being loaded, csoundLocalizeString() simply returns the string
pointer that has been passed to it:

PUBLIC char *csoundLocalizeString(const char *s)
{
     /* if default language, */
     if (getstr_db.lang_code == CSLANGUAGE_DEFAULT)
       return (char*) s;         /* return original string */
     else {
       [...translate string...]
     }
}

I am not entirely sure how it could be disabled even more at compile time.
It is possible to have something like these, but the advantages are not
obvious to me (other than a very minor increase in speed that is difficult
to notice considering how slow the printf() calls usually following the
string translation are):

   PUBLIC char *csoundLocalizeString(const char *s)
   {
       return (char*) s;
   }

   #define Str(x) x



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net