Hi All,

Just FYI, I've pushed a new branch called "feature/rtti" that has the
code for runtime type identification.  You can review the code change
and test csd file here:

https://github.com/csound/csound/commit/30e360a7269cd980b338db44244a3c408c3f24d2
https://github.com/csound/csound/commit/45ef9b38193083108acc067c588a9612aa7ec773

As for current status:

* the type for an argument can be read at runtime by any opcode, with
the exception of Label arguments.  This actually has some
complications as LBLBLK's are actually opcodes.  I think to support
RTTI of labels, all OPDS entries would have to be prepended with the
CS_TYPE, and we'd have to add a type for Opcodes.  This is something
we'd eventually need anyways if we're going to have first-class
opcodes (i.e. being able to store and pass opcodes to opcodes).  For
the moment, I am holding off on RTTI for labels.

* pset and --midi-key-xxx type flags have been modified to work with
the CS_VAR_MEM code.

* Pfields currently all have a type of CS_VAR_TYPE_P.  This should
eventually change to reflect the real type (i, S, etc.).  This
requires some other changes and I think is out of scope for the time
being. (i.e. we need to have a way to have modifiers for variables,
i.e. const, pfield, so we could say "this var is of type i and is a
const")

The bigger issue is that one of my CSD tests here is not working. I
suspect that the RTTI work needs changes for UDO's.  Because of this,
I have pushed my work into the branch for the time being.  Once UDO's
work, I will do some further testing and request others to test. After
that, I will plan to merge.

Thanks!
steven

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi All,

I've fixed up the issue with RTTI and UDO's. I turns out the issue had
to do with pfield values not being set correctly on the UDO INSDS
instance from the parent.  With the fix, I'm able to run my CSD's
here.

I did find that there was an odd situation where if you were in a UDO
and tried to read a pfield as a string, it caused a crash. I modified
things such that get_arg_string() now always goes to the root INSDS
and reads from that one's char* strarg.

I also found that testing subinstruments does not seem to work.
Running subinstr.csd and subinstr_named.csd from the manual examples
seems to run alright but I get no audio output.  I tested using my
RTTI branch as well as with a build from a month ago and got the same
result.   I suspect this has been broken a while.

I'd like to request two things:

1. If you can, please try running subinstr.csd and subinstr_named.csd
and see if you get audio output with whatever version of Csound you
have there.

2. Please try out the features/rtti branch. I'll plan to merge on
Tuesday unless I hear any feedback of any bugs.

To note, I have run Trapped with both the RTTI branch and the build
from a month ago. The RTTI branch renders without problems, and seems
to perform in the same amount of time as without the RTTI.

Thanks!
steven

On Fri, Jul 11, 2014 at 10:48 AM, Steven Yi  wrote:
> Hi All,
>
> Just FYI, I've pushed a new branch called "feature/rtti" that has the
> code for runtime type identification.  You can review the code change
> and test csd file here:
>
> https://github.com/csound/csound/commit/30e360a7269cd980b338db44244a3c408c3f24d2
> https://github.com/csound/csound/commit/45ef9b38193083108acc067c588a9612aa7ec773
>
> As for current status:
>
> * the type for an argument can be read at runtime by any opcode, with
> the exception of Label arguments.  This actually has some
> complications as LBLBLK's are actually opcodes.  I think to support
> RTTI of labels, all OPDS entries would have to be prepended with the
> CS_TYPE, and we'd have to add a type for Opcodes.  This is something
> we'd eventually need anyways if we're going to have first-class
> opcodes (i.e. being able to store and pass opcodes to opcodes).  For
> the moment, I am holding off on RTTI for labels.
>
> * pset and --midi-key-xxx type flags have been modified to work with
> the CS_VAR_MEM code.
>
> * Pfields currently all have a type of CS_VAR_TYPE_P.  This should
> eventually change to reflect the real type (i, S, etc.).  This
> requires some other changes and I think is out of scope for the time
> being. (i.e. we need to have a way to have modifiers for variables,
> i.e. const, pfield, so we could say "this var is of type i and is a
> const")
>
> The bigger issue is that one of my CSD tests here is not working. I
> suspect that the RTTI work needs changes for UDO's.  Because of this,
> I have pushed my work into the branch for the time being.  Once UDO's
> work, I will do some further testing and request others to test. After
> that, I will plan to merge.
>
> Thanks!
> steven

------------------------------------------------------------------------------
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

hi steven -

i can confirm that subinstr.csd and subinstr_named.csd do not generate 
any audio output. i am running yesterday's git develop branch.

looking forward to check out your RTTI branch. ciao -

	joachim


Am 14.07.2014 00:53, schrieb Steven Yi:
> Hi All,
>
> I've fixed up the issue with RTTI and UDO's. I turns out the issue had
> to do with pfield values not being set correctly on the UDO INSDS
> instance from the parent.  With the fix, I'm able to run my CSD's
> here.
>
> I did find that there was an odd situation where if you were in a UDO
> and tried to read a pfield as a string, it caused a crash. I modified
> things such that get_arg_string() now always goes to the root INSDS
> and reads from that one's char* strarg.
>
> I also found that testing subinstruments does not seem to work.
> Running subinstr.csd and subinstr_named.csd from the manual examples
> seems to run alright but I get no audio output.  I tested using my
> RTTI branch as well as with a build from a month ago and got the same
> result.   I suspect this has been broken a while.
>
> I'd like to request two things:
>
> 1. If you can, please try running subinstr.csd and subinstr_named.csd
> and see if you get audio output with whatever version of Csound you
> have there.
>
> 2. Please try out the features/rtti branch. I'll plan to merge on
> Tuesday unless I hear any feedback of any bugs.
>
> To note, I have run Trapped with both the RTTI branch and the build
> from a month ago. The RTTI branch renders without problems, and seems
> to perform in the same amount of time as without the RTTI.
>
> Thanks!
> steven
>
> On Fri, Jul 11, 2014 at 10:48 AM, Steven Yi  wrote:
>> Hi All,
>>
>> Just FYI, I've pushed a new branch called "feature/rtti" that has the
>> code for runtime type identification.  You can review the code change
>> and test csd file here:
>>
>> https://github.com/csound/csound/commit/30e360a7269cd980b338db44244a3c408c3f24d2
>> https://github.com/csound/csound/commit/45ef9b38193083108acc067c588a9612aa7ec773
>>
>> As for current status:
>>
>> * the type for an argument can be read at runtime by any opcode, with
>> the exception of Label arguments.  This actually has some
>> complications as LBLBLK's are actually opcodes.  I think to support
>> RTTI of labels, all OPDS entries would have to be prepended with the
>> CS_TYPE, and we'd have to add a type for Opcodes.  This is something
>> we'd eventually need anyways if we're going to have first-class
>> opcodes (i.e. being able to store and pass opcodes to opcodes).  For
>> the moment, I am holding off on RTTI for labels.
>>
>> * pset and --midi-key-xxx type flags have been modified to work with
>> the CS_VAR_MEM code.
>>
>> * Pfields currently all have a type of CS_VAR_TYPE_P.  This should
>> eventually change to reflect the real type (i, S, etc.).  This
>> requires some other changes and I think is out of scope for the time
>> being. (i.e. we need to have a way to have modifiers for variables,
>> i.e. const, pfield, so we could say "this var is of type i and is a
>> const")
>>
>> The bigger issue is that one of my CSD tests here is not working. I
>> suspect that the RTTI work needs changes for UDO's.  Because of this,
>> I have pushed my work into the branch for the time being.  Once UDO's
>> work, I will do some further testing and request others to test. After
>> that, I will plan to merge.
>>
>> Thanks!
>> steven
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I fixed it now. Line 1589 had been commented out and that was causing the problem as the loop
in 1590 was going ahead when it should not. I am not sure why that line was commented out, I wonder if it was
after one of the coverity checks.

========================
Dr Victor Lazzarini
Senior Lecturer
NUI Maynooth, Ireland
victor dot lazzarini at nuim dot ie




On 14 Jul 2014, at 09:46, joachim heintz  wrote:

> hi steven -
> 
> i can confirm that subinstr.csd and subinstr_named.csd do not generate 
> any audio output. i am running yesterday's git develop branch.
> 
> looking forward to check out your RTTI branch. ciao -
> 
> 	joachim
> 
> 
> Am 14.07.2014 00:53, schrieb Steven Yi:
>> Hi All,
>> 
>> I've fixed up the issue with RTTI and UDO's. I turns out the issue had
>> to do with pfield values not being set correctly on the UDO INSDS
>> instance from the parent.  With the fix, I'm able to run my CSD's
>> here.
>> 
>> I did find that there was an odd situation where if you were in a UDO
>> and tried to read a pfield as a string, it caused a crash. I modified
>> things such that get_arg_string() now always goes to the root INSDS
>> and reads from that one's char* strarg.
>> 
>> I also found that testing subinstruments does not seem to work.
>> Running subinstr.csd and subinstr_named.csd from the manual examples
>> seems to run alright but I get no audio output.  I tested using my
>> RTTI branch as well as with a build from a month ago and got the same
>> result.   I suspect this has been broken a while.
>> 
>> I'd like to request two things:
>> 
>> 1. If you can, please try running subinstr.csd and subinstr_named.csd
>> and see if you get audio output with whatever version of Csound you
>> have there.
>> 
>> 2. Please try out the features/rtti branch. I'll plan to merge on
>> Tuesday unless I hear any feedback of any bugs.
>> 
>> To note, I have run Trapped with both the RTTI branch and the build
>> from a month ago. The RTTI branch renders without problems, and seems
>> to perform in the same amount of time as without the RTTI.
>> 
>> Thanks!
>> steven
>> 
>> On Fri, Jul 11, 2014 at 10:48 AM, Steven Yi  wrote:
>>> Hi All,
>>> 
>>> Just FYI, I've pushed a new branch called "feature/rtti" that has the
>>> code for runtime type identification.  You can review the code change
>>> and test csd file here:
>>> 
>>> https://github.com/csound/csound/commit/30e360a7269cd980b338db44244a3c408c3f24d2
>>> https://github.com/csound/csound/commit/45ef9b38193083108acc067c588a9612aa7ec773
>>> 
>>> As for current status:
>>> 
>>> * the type for an argument can be read at runtime by any opcode, with
>>> the exception of Label arguments.  This actually has some
>>> complications as LBLBLK's are actually opcodes.  I think to support
>>> RTTI of labels, all OPDS entries would have to be prepended with the
>>> CS_TYPE, and we'd have to add a type for Opcodes.  This is something
>>> we'd eventually need anyways if we're going to have first-class
>>> opcodes (i.e. being able to store and pass opcodes to opcodes).  For
>>> the moment, I am holding off on RTTI for labels.
>>> 
>>> * pset and --midi-key-xxx type flags have been modified to work with
>>> the CS_VAR_MEM code.
>>> 
>>> * Pfields currently all have a type of CS_VAR_TYPE_P.  This should
>>> eventually change to reflect the real type (i, S, etc.).  This
>>> requires some other changes and I think is out of scope for the time
>>> being. (i.e. we need to have a way to have modifiers for variables,
>>> i.e. const, pfield, so we could say "this var is of type i and is a
>>> const")
>>> 
>>> The bigger issue is that one of my CSD tests here is not working. I
>>> suspect that the RTTI work needs changes for UDO's.  Because of this,
>>> I have pushed my work into the branch for the time being.  Once UDO's
>>> work, I will do some further testing and request others to test. After
>>> that, I will plan to merge.
>>> 
>>> Thanks!
>>> steven
>> 
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>> 
> 
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck®
> Code Sight™ - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi Victor and Joachim,

Thanks for answering my requests!  I've merged the latest from develop
into the feature/rtti branch and all is working well with subinstr
now.

Thanks!
steven


On Mon, Jul 14, 2014 at 5:22 AM, Victor Lazzarini
 wrote:
> I fixed it now. Line 1589 had been commented out and that was causing the problem as the loop
> in 1590 was going ahead when it should not. I am not sure why that line was commented out, I wonder if it was
> after one of the coverity checks.
>
> ========================
> Dr Victor Lazzarini
> Senior Lecturer
> NUI Maynooth, Ireland
> victor dot lazzarini at nuim dot ie
>
>
>
>
> On 14 Jul 2014, at 09:46, joachim heintz  wrote:
>
>> hi steven -
>>
>> i can confirm that subinstr.csd and subinstr_named.csd do not generate
>> any audio output. i am running yesterday's git develop branch.
>>
>> looking forward to check out your RTTI branch. ciao -
>>
>>       joachim
>>
>>
>> Am 14.07.2014 00:53, schrieb Steven Yi:
>>> Hi All,
>>>
>>> I've fixed up the issue with RTTI and UDO's. I turns out the issue had
>>> to do with pfield values not being set correctly on the UDO INSDS
>>> instance from the parent.  With the fix, I'm able to run my CSD's
>>> here.
>>>
>>> I did find that there was an odd situation where if you were in a UDO
>>> and tried to read a pfield as a string, it caused a crash. I modified
>>> things such that get_arg_string() now always goes to the root INSDS
>>> and reads from that one's char* strarg.
>>>
>>> I also found that testing subinstruments does not seem to work.
>>> Running subinstr.csd and subinstr_named.csd from the manual examples
>>> seems to run alright but I get no audio output.  I tested using my
>>> RTTI branch as well as with a build from a month ago and got the same
>>> result.   I suspect this has been broken a while.
>>>
>>> I'd like to request two things:
>>>
>>> 1. If you can, please try running subinstr.csd and subinstr_named.csd
>>> and see if you get audio output with whatever version of Csound you
>>> have there.
>>>
>>> 2. Please try out the features/rtti branch. I'll plan to merge on
>>> Tuesday unless I hear any feedback of any bugs.
>>>
>>> To note, I have run Trapped with both the RTTI branch and the build
>>> from a month ago. The RTTI branch renders without problems, and seems
>>> to perform in the same amount of time as without the RTTI.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Fri, Jul 11, 2014 at 10:48 AM, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> Just FYI, I've pushed a new branch called "feature/rtti" that has the
>>>> code for runtime type identification.  You can review the code change
>>>> and test csd file here:
>>>>
>>>> https://github.com/csound/csound/commit/30e360a7269cd980b338db44244a3c408c3f24d2
>>>> https://github.com/csound/csound/commit/45ef9b38193083108acc067c588a9612aa7ec773
>>>>
>>>> As for current status:
>>>>
>>>> * the type for an argument can be read at runtime by any opcode, with
>>>> the exception of Label arguments.  This actually has some
>>>> complications as LBLBLK's are actually opcodes.  I think to support
>>>> RTTI of labels, all OPDS entries would have to be prepended with the
>>>> CS_TYPE, and we'd have to add a type for Opcodes.  This is something
>>>> we'd eventually need anyways if we're going to have first-class
>>>> opcodes (i.e. being able to store and pass opcodes to opcodes).  For
>>>> the moment, I am holding off on RTTI for labels.
>>>>
>>>> * pset and --midi-key-xxx type flags have been modified to work with
>>>> the CS_VAR_MEM code.
>>>>
>>>> * Pfields currently all have a type of CS_VAR_TYPE_P.  This should
>>>> eventually change to reflect the real type (i, S, etc.).  This
>>>> requires some other changes and I think is out of scope for the time
>>>> being. (i.e. we need to have a way to have modifiers for variables,
>>>> i.e. const, pfield, so we could say "this var is of type i and is a
>>>> const")
>>>>
>>>> The bigger issue is that one of my CSD tests here is not working. I
>>>> suspect that the RTTI work needs changes for UDO's.  Because of this,
>>>> I have pushed my work into the branch for the time being.  Once UDO's
>>>> work, I will do some further testing and request others to test. After
>>>> that, I will plan to merge.
>>>>
>>>> Thanks!
>>>> steven
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck®
>> Code Sight™ - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck®
> Code Sight™ - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi All,

Just to note, I found that running the RTTI branch with Blue via API
is getting crashes on csoundReset.  This looks to be happening from:

5                                     0x0000000190c3e167 delete_channel_db + 199

I suspect there's a free going on in a pointer that is offset from the
original address due to the shifting with CS_VAR_MEM.  I will reply
once I have a chance to diagnose and fix.

Thanks!
steven


On Mon, Jul 14, 2014 at 7:28 AM, Steven Yi  wrote:
> Hi Victor and Joachim,
>
> Thanks for answering my requests!  I've merged the latest from develop
> into the feature/rtti branch and all is working well with subinstr
> now.
>
> Thanks!
> steven
>
>
> On Mon, Jul 14, 2014 at 5:22 AM, Victor Lazzarini
>  wrote:
>> I fixed it now. Line 1589 had been commented out and that was causing the problem as the loop
>> in 1590 was going ahead when it should not. I am not sure why that line was commented out, I wonder if it was
>> after one of the coverity checks.
>>
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>>
>>
>>
>>
>> On 14 Jul 2014, at 09:46, joachim heintz  wrote:
>>
>>> hi steven -
>>>
>>> i can confirm that subinstr.csd and subinstr_named.csd do not generate
>>> any audio output. i am running yesterday's git develop branch.
>>>
>>> looking forward to check out your RTTI branch. ciao -
>>>
>>>       joachim
>>>
>>>
>>> Am 14.07.2014 00:53, schrieb Steven Yi:
>>>> Hi All,
>>>>
>>>> I've fixed up the issue with RTTI and UDO's. I turns out the issue had
>>>> to do with pfield values not being set correctly on the UDO INSDS
>>>> instance from the parent.  With the fix, I'm able to run my CSD's
>>>> here.
>>>>
>>>> I did find that there was an odd situation where if you were in a UDO
>>>> and tried to read a pfield as a string, it caused a crash. I modified
>>>> things such that get_arg_string() now always goes to the root INSDS
>>>> and reads from that one's char* strarg.
>>>>
>>>> I also found that testing subinstruments does not seem to work.
>>>> Running subinstr.csd and subinstr_named.csd from the manual examples
>>>> seems to run alright but I get no audio output.  I tested using my
>>>> RTTI branch as well as with a build from a month ago and got the same
>>>> result.   I suspect this has been broken a while.
>>>>
>>>> I'd like to request two things:
>>>>
>>>> 1. If you can, please try running subinstr.csd and subinstr_named.csd
>>>> and see if you get audio output with whatever version of Csound you
>>>> have there.
>>>>
>>>> 2. Please try out the features/rtti branch. I'll plan to merge on
>>>> Tuesday unless I hear any feedback of any bugs.
>>>>
>>>> To note, I have run Trapped with both the RTTI branch and the build
>>>> from a month ago. The RTTI branch renders without problems, and seems
>>>> to perform in the same amount of time as without the RTTI.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>> On Fri, Jul 11, 2014 at 10:48 AM, Steven Yi  wrote:
>>>>> Hi All,
>>>>>
>>>>> Just FYI, I've pushed a new branch called "feature/rtti" that has the
>>>>> code for runtime type identification.  You can review the code change
>>>>> and test csd file here:
>>>>>
>>>>> https://github.com/csound/csound/commit/30e360a7269cd980b338db44244a3c408c3f24d2
>>>>> https://github.com/csound/csound/commit/45ef9b38193083108acc067c588a9612aa7ec773
>>>>>
>>>>> As for current status:
>>>>>
>>>>> * the type for an argument can be read at runtime by any opcode, with
>>>>> the exception of Label arguments.  This actually has some
>>>>> complications as LBLBLK's are actually opcodes.  I think to support
>>>>> RTTI of labels, all OPDS entries would have to be prepended with the
>>>>> CS_TYPE, and we'd have to add a type for Opcodes.  This is something
>>>>> we'd eventually need anyways if we're going to have first-class
>>>>> opcodes (i.e. being able to store and pass opcodes to opcodes).  For
>>>>> the moment, I am holding off on RTTI for labels.
>>>>>
>>>>> * pset and --midi-key-xxx type flags have been modified to work with
>>>>> the CS_VAR_MEM code.
>>>>>
>>>>> * Pfields currently all have a type of CS_VAR_TYPE_P.  This should
>>>>> eventually change to reflect the real type (i, S, etc.).  This
>>>>> requires some other changes and I think is out of scope for the time
>>>>> being. (i.e. we need to have a way to have modifiers for variables,
>>>>> i.e. const, pfield, so we could say "this var is of type i and is a
>>>>> const")
>>>>>
>>>>> The bigger issue is that one of my CSD tests here is not working. I
>>>>> suspect that the RTTI work needs changes for UDO's.  Because of this,
>>>>> I have pushed my work into the branch for the time being.  Once UDO's
>>>>> work, I will do some further testing and request others to test. After
>>>>> that, I will plan to merge.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>> Code Sight™ - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Want fast and easy access to all the code in your enterprise? Index and
>> search up to 200,000 lines of code with a free copy of Black Duck®
>> Code Sight™ - the same software that powers the world's largest code
>> search on Ohloh, the Black Duck Open Hub! Try it now.
>> http://p.sf.net/sfu/bds
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck®
Code Sight™ - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

FYI: I've fixed the issue. It was due to a call to Free() on the data
pointer of a CHNENTRY, which when used with chnexport cause it try to
free a pointer that wasn't allocated.  I took out the call to Free()
as the data pointed to by normal channels is Calloc()'d with Csound's
memory functions, thus it is tracked and will be freed anyways in
csoundReset(), or otherwise it will be chnexport'ed, and the data
pointed to will/should be freed by other code.  Doing the change has
fixed the crashing issue for me from the API.

At this point, I'm not seeing other issues.  I will plan to merge the
code tomorrow to the develop branch.

On Mon, Jul 14, 2014 at 8:46 AM, Steven Yi  wrote:
> Hi All,
>
> Just to note, I found that running the RTTI branch with Blue via API
> is getting crashes on csoundReset.  This looks to be happening from:
>
> 5                                     0x0000000190c3e167 delete_channel_db + 199
>
> I suspect there's a free going on in a pointer that is offset from the
> original address due to the shifting with CS_VAR_MEM.  I will reply
> once I have a chance to diagnose and fix.
>
> Thanks!
> steven
>
>
> On Mon, Jul 14, 2014 at 7:28 AM, Steven Yi  wrote:
>> Hi Victor and Joachim,
>>
>> Thanks for answering my requests!  I've merged the latest from develop
>> into the feature/rtti branch and all is working well with subinstr
>> now.
>>
>> Thanks!
>> steven
>>
>>
>> On Mon, Jul 14, 2014 at 5:22 AM, Victor Lazzarini
>>  wrote:
>>> I fixed it now. Line 1589 had been commented out and that was causing the problem as the loop
>>> in 1590 was going ahead when it should not. I am not sure why that line was commented out, I wonder if it was
>>> after one of the coverity checks.
>>>
>>> ========================
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> NUI Maynooth, Ireland
>>> victor dot lazzarini at nuim dot ie
>>>
>>>
>>>
>>>
>>> On 14 Jul 2014, at 09:46, joachim heintz  wrote:
>>>
>>>> hi steven -
>>>>
>>>> i can confirm that subinstr.csd and subinstr_named.csd do not generate
>>>> any audio output. i am running yesterday's git develop branch.
>>>>
>>>> looking forward to check out your RTTI branch. ciao -
>>>>
>>>>       joachim
>>>>
>>>>
>>>> Am 14.07.2014 00:53, schrieb Steven Yi:
>>>>> Hi All,
>>>>>
>>>>> I've fixed up the issue with RTTI and UDO's. I turns out the issue had
>>>>> to do with pfield values not being set correctly on the UDO INSDS
>>>>> instance from the parent.  With the fix, I'm able to run my CSD's
>>>>> here.
>>>>>
>>>>> I did find that there was an odd situation where if you were in a UDO
>>>>> and tried to read a pfield as a string, it caused a crash. I modified
>>>>> things such that get_arg_string() now always goes to the root INSDS
>>>>> and reads from that one's char* strarg.
>>>>>
>>>>> I also found that testing subinstruments does not seem to work.
>>>>> Running subinstr.csd and subinstr_named.csd from the manual examples
>>>>> seems to run alright but I get no audio output.  I tested using my
>>>>> RTTI branch as well as with a build from a month ago and got the same
>>>>> result.   I suspect this has been broken a while.
>>>>>
>>>>> I'd like to request two things:
>>>>>
>>>>> 1. If you can, please try running subinstr.csd and subinstr_named.csd
>>>>> and see if you get audio output with whatever version of Csound you
>>>>> have there.
>>>>>
>>>>> 2. Please try out the features/rtti branch. I'll plan to merge on
>>>>> Tuesday unless I hear any feedback of any bugs.
>>>>>
>>>>> To note, I have run Trapped with both the RTTI branch and the build
>>>>> from a month ago. The RTTI branch renders without problems, and seems
>>>>> to perform in the same amount of time as without the RTTI.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>> On Fri, Jul 11, 2014 at 10:48 AM, Steven Yi  wrote:
>>>>>> Hi All,
>>>>>>
>>>>>> Just FYI, I've pushed a new branch called "feature/rtti" that has the
>>>>>> code for runtime type identification.  You can review the code change
>>>>>> and test csd file here:
>>>>>>
>>>>>> https://github.com/csound/csound/commit/30e360a7269cd980b338db44244a3c408c3f24d2
>>>>>> https://github.com/csound/csound/commit/45ef9b38193083108acc067c588a9612aa7ec773
>>>>>>
>>>>>> As for current status:
>>>>>>
>>>>>> * the type for an argument can be read at runtime by any opcode, with
>>>>>> the exception of Label arguments.  This actually has some
>>>>>> complications as LBLBLK's are actually opcodes.  I think to support
>>>>>> RTTI of labels, all OPDS entries would have to be prepended with the
>>>>>> CS_TYPE, and we'd have to add a type for Opcodes.  This is something
>>>>>> we'd eventually need anyways if we're going to have first-class
>>>>>> opcodes (i.e. being able to store and pass opcodes to opcodes).  For
>>>>>> the moment, I am holding off on RTTI for labels.
>>>>>>
>>>>>> * pset and --midi-key-xxx type flags have been modified to work with
>>>>>> the CS_VAR_MEM code.
>>>>>>
>>>>>> * Pfields currently all have a type of CS_VAR_TYPE_P.  This should
>>>>>> eventually change to reflect the real type (i, S, etc.).  This
>>>>>> requires some other changes and I think is out of scope for the time
>>>>>> being. (i.e. we need to have a way to have modifiers for variables,
>>>>>> i.e. const, pfield, so we could say "this var is of type i and is a
>>>>>> const")
>>>>>>
>>>>>> The bigger issue is that one of my CSD tests here is not working. I
>>>>>> suspect that the RTTI work needs changes for UDO's.  Because of this,
>>>>>> I have pushed my work into the branch for the time being.  Once UDO's
>>>>>> work, I will do some further testing and request others to test. After
>>>>>> that, I will plan to merge.
>>>>>>
>>>>>> Thanks!
>>>>>> steven
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Want fast and easy access to all the code in your enterprise? Index and
>>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>>> Code Sight™ - the same software that powers the world's largest code
>>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>>> http://p.sf.net/sfu/bds
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Want fast and easy access to all the code in your enterprise? Index and
>>> search up to 200,000 lines of code with a free copy of Black Duck®
>>> Code Sight™ - the same software that powers the world's largest code
>>> search on Ohloh, the Black Duck Open Hub! Try it now.
>>> http://p.sf.net/sfu/bds
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net