Hi all,

While preparing the package for debian, I noticed the following new
exported symbols, that are not immediately clear to me should be (and
some are not correctly namespaced):


argdecode
argsRequired
check_in_arg
check_in_args
check_out_arg
check_out_args
cs_cons
cs_cons_append
cs_cons_free
cs_cons_free_complete
cs_cons_length
cs_hash_table_create
cs_hash_table_free
cs_hash_table_free_complete
cs_hash_table_get
cs_hash_table_get_key
cs_hash_table_keys
cs_hash_table_merge
cs_hash_table_mfree_complete
cs_hash_table_put
cs_hash_table_put_key
cs_hash_table_remove
cs_hash_table_values
cs_strtod
cs_strtok_r
csoundWriteCircularBuffer
find_opcode2
find_opcode_new
getVarSimpleName
get_arg_string_from_tree
get_arg_type2
get_arg_type
initializeVarPool
reallocateVarPoolMemory
recalculateVarPoolMemory
resolve_opcode
resolve_opcode_get_outarg
splitArgs


Also, these constants are exported. I'm not sure how constants affect
the ABI, if the structs were to change.

CS_VAR_TYPE_A
CS_VAR_TYPE_ARRAY
CS_VAR_TYPE_B
CS_VAR_TYPE_C
CS_VAR_TYPE_F
CS_VAR_TYPE_I
CS_VAR_TYPE_K
CS_VAR_TYPE_P
CS_VAR_TYPE_R
CS_VAR_TYPE_S
CS_VAR_TYPE_W
CS_VAR_TYPE_b

--

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Felipe,

This is something I should have fixed but it slipped my mind.  The
reason I had exported these functions was so that I could unit test
them with CTest.  I had meant to look up what's the best way to handle
unit testing functions not meant to be exported; I had not seen
anything in my google searches initially.  If anyone has a
recommendation for this I'd love to know.

Also, some of these may be generally useful.  The type constants
should be handy for API users, though there was that thread between me
and Andres talking about what's the best way to lookup defined types
in the type pool that may very well change if these are exported or
not.  I am unsure about impact on ABI, but my assumption is that
taking any symbol out would only affect applications that used those
symbols.

Thanks,
steven

On Sat, Jul 13, 2013 at 1:19 PM, Felipe Sateler  wrote:
> Hi all,
>
> While preparing the package for debian, I noticed the following new
> exported symbols, that are not immediately clear to me should be (and
> some are not correctly namespaced):
>
>
> argdecode
> argsRequired
> check_in_arg
> check_in_args
> check_out_arg
> check_out_args
> cs_cons
> cs_cons_append
> cs_cons_free
> cs_cons_free_complete
> cs_cons_length
> cs_hash_table_create
> cs_hash_table_free
> cs_hash_table_free_complete
> cs_hash_table_get
> cs_hash_table_get_key
> cs_hash_table_keys
> cs_hash_table_merge
> cs_hash_table_mfree_complete
> cs_hash_table_put
> cs_hash_table_put_key
> cs_hash_table_remove
> cs_hash_table_values
> cs_strtod
> cs_strtok_r
> csoundWriteCircularBuffer
> find_opcode2
> find_opcode_new
> getVarSimpleName
> get_arg_string_from_tree
> get_arg_type2
> get_arg_type
> initializeVarPool
> reallocateVarPoolMemory
> recalculateVarPoolMemory
> resolve_opcode
> resolve_opcode_get_outarg
> splitArgs
>
>
> Also, these constants are exported. I'm not sure how constants affect
> the ABI, if the structs were to change.
>
> CS_VAR_TYPE_A
> CS_VAR_TYPE_ARRAY
> CS_VAR_TYPE_B
> CS_VAR_TYPE_C
> CS_VAR_TYPE_F
> CS_VAR_TYPE_I
> CS_VAR_TYPE_K
> CS_VAR_TYPE_P
> CS_VAR_TYPE_R
> CS_VAR_TYPE_S
> CS_VAR_TYPE_W
> CS_VAR_TYPE_b
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

To unit test private code, I think you can use the static library
(which would mean building stuff twice). Some googling suggests only
testing the public code, but I'm not sure that it is such great
advice. Alternatively, the test programs could not link with the
library but just use directly libcsound_SRCS.

About ABI impact, it is correct, but the thing is that users are not
always known beforehand.

On Sat, Jul 13, 2013 at 2:51 PM, Steven Yi  wrote:
> Hi Felipe,
>
> This is something I should have fixed but it slipped my mind.  The
> reason I had exported these functions was so that I could unit test
> them with CTest.  I had meant to look up what's the best way to handle
> unit testing functions not meant to be exported; I had not seen
> anything in my google searches initially.  If anyone has a
> recommendation for this I'd love to know.
>
> Also, some of these may be generally useful.  The type constants
> should be handy for API users, though there was that thread between me
> and Andres talking about what's the best way to lookup defined types
> in the type pool that may very well change if these are exported or
> not.  I am unsure about impact on ABI, but my assumption is that
> taking any symbol out would only affect applications that used those
> symbols.
>
> Thanks,
> steven
>
> On Sat, Jul 13, 2013 at 1:19 PM, Felipe Sateler  wrote:
>> Hi all,
>>
>> While preparing the package for debian, I noticed the following new
>> exported symbols, that are not immediately clear to me should be (and
>> some are not correctly namespaced):
>>
>>
>> argdecode
>> argsRequired
>> check_in_arg
>> check_in_args
>> check_out_arg
>> check_out_args
>> cs_cons
>> cs_cons_append
>> cs_cons_free
>> cs_cons_free_complete
>> cs_cons_length
>> cs_hash_table_create
>> cs_hash_table_free
>> cs_hash_table_free_complete
>> cs_hash_table_get
>> cs_hash_table_get_key
>> cs_hash_table_keys
>> cs_hash_table_merge
>> cs_hash_table_mfree_complete
>> cs_hash_table_put
>> cs_hash_table_put_key
>> cs_hash_table_remove
>> cs_hash_table_values
>> cs_strtod
>> cs_strtok_r
>> csoundWriteCircularBuffer
>> find_opcode2
>> find_opcode_new
>> getVarSimpleName
>> get_arg_string_from_tree
>> get_arg_type2
>> get_arg_type
>> initializeVarPool
>> reallocateVarPoolMemory
>> recalculateVarPoolMemory
>> resolve_opcode
>> resolve_opcode_get_outarg
>> splitArgs
>>
>>
>> Also, these constants are exported. I'm not sure how constants affect
>> the ABI, if the structs were to change.
>>
>> CS_VAR_TYPE_A
>> CS_VAR_TYPE_ARRAY
>> CS_VAR_TYPE_B
>> CS_VAR_TYPE_C
>> CS_VAR_TYPE_F
>> CS_VAR_TYPE_I
>> CS_VAR_TYPE_K
>> CS_VAR_TYPE_P
>> CS_VAR_TYPE_R
>> CS_VAR_TYPE_S
>> CS_VAR_TYPE_W
>> CS_VAR_TYPE_b
>>
>> --
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Maybe static libs is the way to go.  I'll give that a try tomorrow in
Linux and see if it works; if so, I'll modify the tests for that and
remove the PUBLIC's.

On Sat, Jul 13, 2013 at 6:10 PM, Felipe Sateler  wrote:
> To unit test private code, I think you can use the static library
> (which would mean building stuff twice). Some googling suggests only
> testing the public code, but I'm not sure that it is such great
> advice. Alternatively, the test programs could not link with the
> library but just use directly libcsound_SRCS.
>
> About ABI impact, it is correct, but the thing is that users are not
> always known beforehand.
>
> On Sat, Jul 13, 2013 at 2:51 PM, Steven Yi  wrote:
>> Hi Felipe,
>>
>> This is something I should have fixed but it slipped my mind.  The
>> reason I had exported these functions was so that I could unit test
>> them with CTest.  I had meant to look up what's the best way to handle
>> unit testing functions not meant to be exported; I had not seen
>> anything in my google searches initially.  If anyone has a
>> recommendation for this I'd love to know.
>>
>> Also, some of these may be generally useful.  The type constants
>> should be handy for API users, though there was that thread between me
>> and Andres talking about what's the best way to lookup defined types
>> in the type pool that may very well change if these are exported or
>> not.  I am unsure about impact on ABI, but my assumption is that
>> taking any symbol out would only affect applications that used those
>> symbols.
>>
>> Thanks,
>> steven
>>
>> On Sat, Jul 13, 2013 at 1:19 PM, Felipe Sateler  wrote:
>>> Hi all,
>>>
>>> While preparing the package for debian, I noticed the following new
>>> exported symbols, that are not immediately clear to me should be (and
>>> some are not correctly namespaced):
>>>
>>>
>>> argdecode
>>> argsRequired
>>> check_in_arg
>>> check_in_args
>>> check_out_arg
>>> check_out_args
>>> cs_cons
>>> cs_cons_append
>>> cs_cons_free
>>> cs_cons_free_complete
>>> cs_cons_length
>>> cs_hash_table_create
>>> cs_hash_table_free
>>> cs_hash_table_free_complete
>>> cs_hash_table_get
>>> cs_hash_table_get_key
>>> cs_hash_table_keys
>>> cs_hash_table_merge
>>> cs_hash_table_mfree_complete
>>> cs_hash_table_put
>>> cs_hash_table_put_key
>>> cs_hash_table_remove
>>> cs_hash_table_values
>>> cs_strtod
>>> cs_strtok_r
>>> csoundWriteCircularBuffer
>>> find_opcode2
>>> find_opcode_new
>>> getVarSimpleName
>>> get_arg_string_from_tree
>>> get_arg_type2
>>> get_arg_type
>>> initializeVarPool
>>> reallocateVarPoolMemory
>>> recalculateVarPoolMemory
>>> resolve_opcode
>>> resolve_opcode_get_outarg
>>> splitArgs
>>>
>>>
>>> Also, these constants are exported. I'm not sure how constants affect
>>> the ABI, if the structs were to change.
>>>
>>> CS_VAR_TYPE_A
>>> CS_VAR_TYPE_ARRAY
>>> CS_VAR_TYPE_B
>>> CS_VAR_TYPE_C
>>> CS_VAR_TYPE_F
>>> CS_VAR_TYPE_I
>>> CS_VAR_TYPE_K
>>> CS_VAR_TYPE_P
>>> CS_VAR_TYPE_R
>>> CS_VAR_TYPE_S
>>> CS_VAR_TYPE_W
>>> CS_VAR_TYPE_b
>>>
>>> --
>>>
>>> Saludos,
>>> Felipe Sateler
>>>
>>> ------------------------------------------------------------------------------
>>> See everything from the browser to the database with AppDynamics
>>> Get end-to-end visibility with application monitoring from AppDynamics
>>> Isolate bottlenecks and diagnose root cause in seconds.
>>> Start your free trial of AppDynamics Pro today!
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
>
> Saludos,
> Felipe Sateler
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Coming from the Java world, it's common to test both public and
protected functions (essentially acting like private functions for the
purpose of this comparison).  There's a standard method for doing this
by using a separate test code tree that has the same package names as
what exists in the src tree.  For myself, I think testing the private
code is essential for the unit tests.

As an update, I just tested using the static library for compiling the
unit tests and removing the PUBLIC identifiers on functions.  That
seems to work fine for Linux (Debian) and Mac OSX.  I've committed
those changes.

I removed PUBLIC from the functions that were definitely not for use
outside the library.  The other functions I'm not sure if we should
leave in or not, so did not change those.  I can see having a cons
list and hash table to be useful for C API users, but they'd be pretty
useless for SWIG-wrapped API's (java, python, etc.).  I'm happy to go
either way; if someone has an opinion to remove these from the PUBLIC
API, let me know and I'll go ahead and remove those.

Thanks!
steven

On Sun, Jul 14, 2013 at 11:11 PM, Andres Cabrera  wrote:
> I have always wondered about this too. I've also often seen recommendations
> that only public APIs should be tested but I think that internal functions
> might also need to be tested, as this case shows. I think another simple way
> to go is to simply include the files to be tested in the test application.
>
> Cheers,
> Andrés
>
>
> On Sun, Jul 14, 2013 at 7:25 PM, Steven Yi  wrote:
>>
>> Maybe static libs is the way to go.  I'll give that a try tomorrow in
>> Linux and see if it works; if so, I'll modify the tests for that and
>> remove the PUBLIC's.
>>
>> On Sat, Jul 13, 2013 at 6:10 PM, Felipe Sateler 
>> wrote:
>> > To unit test private code, I think you can use the static library
>> > (which would mean building stuff twice). Some googling suggests only
>> > testing the public code, but I'm not sure that it is such great
>> > advice. Alternatively, the test programs could not link with the
>> > library but just use directly libcsound_SRCS.
>> >
>> > About ABI impact, it is correct, but the thing is that users are not
>> > always known beforehand.
>> >
>> > On Sat, Jul 13, 2013 at 2:51 PM, Steven Yi  wrote:
>> >> Hi Felipe,
>> >>
>> >> This is something I should have fixed but it slipped my mind.  The
>> >> reason I had exported these functions was so that I could unit test
>> >> them with CTest.  I had meant to look up what's the best way to handle
>> >> unit testing functions not meant to be exported; I had not seen
>> >> anything in my google searches initially.  If anyone has a
>> >> recommendation for this I'd love to know.
>> >>
>> >> Also, some of these may be generally useful.  The type constants
>> >> should be handy for API users, though there was that thread between me
>> >> and Andres talking about what's the best way to lookup defined types
>> >> in the type pool that may very well change if these are exported or
>> >> not.  I am unsure about impact on ABI, but my assumption is that
>> >> taking any symbol out would only affect applications that used those
>> >> symbols.
>> >>
>> >> Thanks,
>> >> steven
>> >>
>> >> On Sat, Jul 13, 2013 at 1:19 PM, Felipe Sateler 
>> >> wrote:
>> >>> Hi all,
>> >>>
>> >>> While preparing the package for debian, I noticed the following new
>> >>> exported symbols, that are not immediately clear to me should be (and
>> >>> some are not correctly namespaced):
>> >>>
>> >>>
>> >>> argdecode
>> >>> argsRequired
>> >>> check_in_arg
>> >>> check_in_args
>> >>> check_out_arg
>> >>> check_out_args
>> >>> cs_cons
>> >>> cs_cons_append
>> >>> cs_cons_free
>> >>> cs_cons_free_complete
>> >>> cs_cons_length
>> >>> cs_hash_table_create
>> >>> cs_hash_table_free
>> >>> cs_hash_table_free_complete
>> >>> cs_hash_table_get
>> >>> cs_hash_table_get_key
>> >>> cs_hash_table_keys
>> >>> cs_hash_table_merge
>> >>> cs_hash_table_mfree_complete
>> >>> cs_hash_table_put
>> >>> cs_hash_table_put_key
>> >>> cs_hash_table_remove
>> >>> cs_hash_table_values
>> >>> cs_strtod
>> >>> cs_strtok_r
>> >>> csoundWriteCircularBuffer
>> >>> find_opcode2
>> >>> find_opcode_new
>> >>> getVarSimpleName
>> >>> get_arg_string_from_tree
>> >>> get_arg_type2
>> >>> get_arg_type
>> >>> initializeVarPool
>> >>> reallocateVarPoolMemory
>> >>> recalculateVarPoolMemory
>> >>> resolve_opcode
>> >>> resolve_opcode_get_outarg
>> >>> splitArgs
>> >>>
>> >>>
>> >>> Also, these constants are exported. I'm not sure how constants affect
>> >>> the ABI, if the structs were to change.
>> >>>
>> >>> CS_VAR_TYPE_A
>> >>> CS_VAR_TYPE_ARRAY
>> >>> CS_VAR_TYPE_B
>> >>> CS_VAR_TYPE_C
>> >>> CS_VAR_TYPE_F
>> >>> CS_VAR_TYPE_I
>> >>> CS_VAR_TYPE_K
>> >>> CS_VAR_TYPE_P
>> >>> CS_VAR_TYPE_R
>> >>> CS_VAR_TYPE_S
>> >>> CS_VAR_TYPE_W
>> >>> CS_VAR_TYPE_b
>> >>>
>> >>> --
>> >>>
>> >>> Saludos,
>> >>> Felipe Sateler
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> See everything from the browser to the database with AppDynamics
>> >>> Get end-to-end visibility with application monitoring from AppDynamics
>> >>> Isolate bottlenecks and diagnose root cause in seconds.
>> >>> Start your free trial of AppDynamics Pro today!
>> >>>
>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >>> _______________________________________________
>> >>> Csound-devel mailing list
>> >>> Csound-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> See everything from the browser to the database with AppDynamics
>> >> Get end-to-end visibility with application monitoring from AppDynamics
>> >> Isolate bottlenecks and diagnose root cause in seconds.
>> >> Start your free trial of AppDynamics Pro today!
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Csound-devel mailing list
>> >> Csound-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> >
>> >
>> >
>> > --
>> >
>> > Saludos,
>> > Felipe Sateler
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

One other other note, to build the tests it now requires building the
static library, which is not on by default.  You can do this by using
-DBUILD_STATIC_LIBRARY=1 when running cmake.  We could also make
static lib on by default if anyone would like that.

On Mon, Jul 15, 2013 at 3:58 PM, Steven Yi  wrote:
> Coming from the Java world, it's common to test both public and
> protected functions (essentially acting like private functions for the
> purpose of this comparison).  There's a standard method for doing this
> by using a separate test code tree that has the same package names as
> what exists in the src tree.  For myself, I think testing the private
> code is essential for the unit tests.
>
> As an update, I just tested using the static library for compiling the
> unit tests and removing the PUBLIC identifiers on functions.  That
> seems to work fine for Linux (Debian) and Mac OSX.  I've committed
> those changes.
>
> I removed PUBLIC from the functions that were definitely not for use
> outside the library.  The other functions I'm not sure if we should
> leave in or not, so did not change those.  I can see having a cons
> list and hash table to be useful for C API users, but they'd be pretty
> useless for SWIG-wrapped API's (java, python, etc.).  I'm happy to go
> either way; if someone has an opinion to remove these from the PUBLIC
> API, let me know and I'll go ahead and remove those.
>
> Thanks!
> steven
>
> On Sun, Jul 14, 2013 at 11:11 PM, Andres Cabrera  wrote:
>> I have always wondered about this too. I've also often seen recommendations
>> that only public APIs should be tested but I think that internal functions
>> might also need to be tested, as this case shows. I think another simple way
>> to go is to simply include the files to be tested in the test application.
>>
>> Cheers,
>> Andrés
>>
>>
>> On Sun, Jul 14, 2013 at 7:25 PM, Steven Yi  wrote:
>>>
>>> Maybe static libs is the way to go.  I'll give that a try tomorrow in
>>> Linux and see if it works; if so, I'll modify the tests for that and
>>> remove the PUBLIC's.
>>>
>>> On Sat, Jul 13, 2013 at 6:10 PM, Felipe Sateler 
>>> wrote:
>>> > To unit test private code, I think you can use the static library
>>> > (which would mean building stuff twice). Some googling suggests only
>>> > testing the public code, but I'm not sure that it is such great
>>> > advice. Alternatively, the test programs could not link with the
>>> > library but just use directly libcsound_SRCS.
>>> >
>>> > About ABI impact, it is correct, but the thing is that users are not
>>> > always known beforehand.
>>> >
>>> > On Sat, Jul 13, 2013 at 2:51 PM, Steven Yi  wrote:
>>> >> Hi Felipe,
>>> >>
>>> >> This is something I should have fixed but it slipped my mind.  The
>>> >> reason I had exported these functions was so that I could unit test
>>> >> them with CTest.  I had meant to look up what's the best way to handle
>>> >> unit testing functions not meant to be exported; I had not seen
>>> >> anything in my google searches initially.  If anyone has a
>>> >> recommendation for this I'd love to know.
>>> >>
>>> >> Also, some of these may be generally useful.  The type constants
>>> >> should be handy for API users, though there was that thread between me
>>> >> and Andres talking about what's the best way to lookup defined types
>>> >> in the type pool that may very well change if these are exported or
>>> >> not.  I am unsure about impact on ABI, but my assumption is that
>>> >> taking any symbol out would only affect applications that used those
>>> >> symbols.
>>> >>
>>> >> Thanks,
>>> >> steven
>>> >>
>>> >> On Sat, Jul 13, 2013 at 1:19 PM, Felipe Sateler 
>>> >> wrote:
>>> >>> Hi all,
>>> >>>
>>> >>> While preparing the package for debian, I noticed the following new
>>> >>> exported symbols, that are not immediately clear to me should be (and
>>> >>> some are not correctly namespaced):
>>> >>>
>>> >>>
>>> >>> argdecode
>>> >>> argsRequired
>>> >>> check_in_arg
>>> >>> check_in_args
>>> >>> check_out_arg
>>> >>> check_out_args
>>> >>> cs_cons
>>> >>> cs_cons_append
>>> >>> cs_cons_free
>>> >>> cs_cons_free_complete
>>> >>> cs_cons_length
>>> >>> cs_hash_table_create
>>> >>> cs_hash_table_free
>>> >>> cs_hash_table_free_complete
>>> >>> cs_hash_table_get
>>> >>> cs_hash_table_get_key
>>> >>> cs_hash_table_keys
>>> >>> cs_hash_table_merge
>>> >>> cs_hash_table_mfree_complete
>>> >>> cs_hash_table_put
>>> >>> cs_hash_table_put_key
>>> >>> cs_hash_table_remove
>>> >>> cs_hash_table_values
>>> >>> cs_strtod
>>> >>> cs_strtok_r
>>> >>> csoundWriteCircularBuffer
>>> >>> find_opcode2
>>> >>> find_opcode_new
>>> >>> getVarSimpleName
>>> >>> get_arg_string_from_tree
>>> >>> get_arg_type2
>>> >>> get_arg_type
>>> >>> initializeVarPool
>>> >>> reallocateVarPoolMemory
>>> >>> recalculateVarPoolMemory
>>> >>> resolve_opcode
>>> >>> resolve_opcode_get_outarg
>>> >>> splitArgs
>>> >>>
>>> >>>
>>> >>> Also, these constants are exported. I'm not sure how constants affect
>>> >>> the ABI, if the structs were to change.
>>> >>>
>>> >>> CS_VAR_TYPE_A
>>> >>> CS_VAR_TYPE_ARRAY
>>> >>> CS_VAR_TYPE_B
>>> >>> CS_VAR_TYPE_C
>>> >>> CS_VAR_TYPE_F
>>> >>> CS_VAR_TYPE_I
>>> >>> CS_VAR_TYPE_K
>>> >>> CS_VAR_TYPE_P
>>> >>> CS_VAR_TYPE_R
>>> >>> CS_VAR_TYPE_S
>>> >>> CS_VAR_TYPE_W
>>> >>> CS_VAR_TYPE_b
>>> >>>
>>> >>> --
>>> >>>
>>> >>> Saludos,
>>> >>> Felipe Sateler
>>> >>>
>>> >>>
>>> >>> ------------------------------------------------------------------------------
>>> >>> See everything from the browser to the database with AppDynamics
>>> >>> Get end-to-end visibility with application monitoring from AppDynamics
>>> >>> Isolate bottlenecks and diagnose root cause in seconds.
>>> >>> Start your free trial of AppDynamics Pro today!
>>> >>>
>>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> >>> _______________________________________________
>>> >>> Csound-devel mailing list
>>> >>> Csound-devel@lists.sourceforge.net
>>> >>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >>
>>> >>
>>> >> ------------------------------------------------------------------------------
>>> >> See everything from the browser to the database with AppDynamics
>>> >> Get end-to-end visibility with application monitoring from AppDynamics
>>> >> Isolate bottlenecks and diagnose root cause in seconds.
>>> >> Start your free trial of AppDynamics Pro today!
>>> >>
>>> >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> >> _______________________________________________
>>> >> Csound-devel mailing list
>>> >> Csound-devel@lists.sourceforge.net
>>> >> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > Saludos,
>>> > Felipe Sateler
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > See everything from the browser to the database with AppDynamics
>>> > Get end-to-end visibility with application monitoring from AppDynamics
>>> > Isolate bottlenecks and diagnose root cause in seconds.
>>> > Start your free trial of AppDynamics Pro today!
>>> >
>>> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Csound-devel mailing list
>>> > Csound-devel@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> See everything from the browser to the database with AppDynamics
>>> Get end-to-end visibility with application monitoring from AppDynamics
>>> Isolate bottlenecks and diagnose root cause in seconds.
>>> Start your free trial of AppDynamics Pro today!
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Mon, Jul 15, 2013 at 3:58 PM, Steven Yi  wrote:
> As an update, I just tested using the static library for compiling the
> unit tests and removing the PUBLIC identifiers on functions.  That
> seems to work fine for Linux (Debian) and Mac OSX.  I've committed
> those changes.


Great! 12 down, 26 to go ;).

> I can see having a cons
> list and hash table to be useful for C API users, but they'd be pretty
> useless for SWIG-wrapped API's (java, python, etc.).  I'm happy to go
> either way; if someone has an opinion to remove these from the PUBLIC
> API, let me know and I'll go ahead and remove those.

I'm of no opinion as to wether they should be part of the API or not.
But I do think that if they are part of the API, they should be
properly namespaced and documented.

BTW, the cscore* functions do not have any documentation...

--

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net