Csound Csound-dev Csound-tekno Search About

[Cs-dev] Accessing string variables through the API

Date2015-03-17 03:30
FromAndres Cabrera
Subject[Cs-dev] Accessing string variables through the API
AttachmentsNone  None  
Hi,

The current state of string channels through the API causes issues for large strings. The problem is that there are no API methods to resize string variables (accessible from host code), so if string values for a channel are longer than the 128 that are pre-allocated in the init pass for the string variable, there is no way for the invalue callback to resize this data space.

Should there be these methods? How would this play with more complex data types (e.g. user defined types) and channels?

Cheers,
Andrés

Date2015-03-17 12:19
FromVictor Lazzarini
SubjectRe: [Cs-dev] Accessing string variables through the API
Can we not resize as needed in the callback, maybe exposing the memory functions to do that?

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 17 Mar 2015, at 03:30, Andres Cabrera  wrote:
> 
> Hi,
> 
> The current state of string channels through the API causes issues for large strings. The problem is that there are no API methods to resize string variables (accessible from host code), so if string values for a channel are longer than the 128 that are pre-allocated in the init pass for the string variable, there is no way for the invalue callback to resize this data space.
> 
> Should there be these methods? How would this play with more complex data types (e.g. user defined types) and channels?
> 
> Cheers,
> Andrés
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.s

Date2015-03-17 17:34
FromAndres Cabrera
SubjectRe: [Cs-dev] Accessing string variables through the API
AttachmentsNone  None  
Yes, I think that's the way to go. But this needs to be exposed in some generic way to allow for future usage of channels using any particular type. Maybe the type system could provide resizing functions and then this is what gets exposed. Currently the STRINGDAT struct is deep within the private API, and it's not really generic enough, I think it would be better if we integrate the type system here.

Cheers,
Andrés

On Tue, Mar 17, 2015 at 5:19 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
Can we not resize as needed in the callback, maybe exposing the memory functions to do that?

Victor Lazzarini
Dean of Arts, Celtic Studies, and Philosophy
Maynooth University
Ireland

> On 17 Mar 2015, at 03:30, Andres Cabrera <mantaraya36@gmail.com> wrote:
>
> Hi,
>
> The current state of string channels through the API causes issues for large strings. The problem is that there are no API methods to resize string variables (accessible from host code), so if string values for a channel are longer than the 128 that are pre-allocated in the init pass for the string variable, there is no way for the invalue callback to resize this data space.
>
> Should there be these methods? How would this play with more complex data types (e.g. user defined types) and channels?
>
> Cheers,
> Andrés
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel


Date2015-03-17 20:56
FromSteven Yi
SubjectRe: [Cs-dev] Accessing string variables through the API
I double checked, as I thought I might have modified the channels
system to use CS_VAR_MEM, so that you can access the type pointer.
However, that's not the case unfortunately.

Andres: could you file an issue and assign it to me for reworking the
channel db for CS_VAR_MEM?  We also may want to modify the system to
use CS_TYPE's when creating channels, rather than have a separate set
of type information like we do now.

For things like STRINGDAT, I think we need to have that be public.
It's sort of a primitive data type and there's not much one can do for
introspection.  For CS7 structs, the data type for that should also be
exposed.  For structs, one can use the CS_TYPE, which has information
about the fields of the structure, to interrogate values in a struct
variable.

On Tue, Mar 17, 2015 at 1:34 PM, Andres Cabrera  wrote:
> Yes, I think that's the way to go. But this needs to be exposed in some
> generic way to allow for future usage of channels using any particular type.
> Maybe the type system could provide resizing functions and then this is what
> gets exposed. Currently the STRINGDAT struct is deep within the private API,
> and it's not really generic enough, I think it would be better if we
> integrate the type system here.
>
> Cheers,
> Andrés
>
> On Tue, Mar 17, 2015 at 5:19 AM, Victor Lazzarini 
> wrote:
>>
>> Can we not resize as needed in the callback, maybe exposing the memory
>> functions to do that?
>>
>> Victor Lazzarini
>> Dean of Arts, Celtic Studies, and Philosophy
>> Maynooth University
>> Ireland
>>
>> > On 17 Mar 2015, at 03:30, Andres Cabrera  wrote:
>> >
>> > Hi,
>> >
>> > The current state of string channels through the API causes issues for
>> > large strings. The problem is that there are no API methods to resize string
>> > variables (accessible from host code), so if string values for a channel are
>> > longer than the 128 that are pre-allocated in the init pass for the string
>> > variable, there is no way for the invalue callback to resize this data
>> > space.
>> >
>> > Should there be these methods? How would this play with more complex
>> > data types (e.g. user defined types) and channels?
>> >
>> > Cheers,
>> > Andrés
>> >
>> > ------------------------------------------------------------------------------
>> > Dive into the World of Parallel Programming The Go Parallel Website,
>> > sponsored
>> > by Intel and developed in partnership with Slashdot Media, is your hub
>> > for all
>> > things parallel software development, from weekly thought leadership
>> > blogs to
>> > news, videos, case studies, tutorials and more. Take a look and join the
>> > conversation now. http://goparallel.sourceforge.net/
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub for
>> all
>> things parallel software development, from weekly thought leadership blogs
>> to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csoun