Hi All,

I was exploring some ideas about retrofitting run-time type
identification into Csound.  I thought I had a simple solution but
when I went to try it I realized I had a fundamental flaw to the idea.
 However, I did manage to find a semi-hack.

I've attached a test file on how this would work.  Essentially, the
issue is that all opcode use MYFLT* as pointers to memory for args.
The MYFLT* is then cast to what kind of data the opcode really expects
(i.e. could be MYFLT, but could be PVSDAT, etc.).  The trick to the
code is in this struct:

typedef struct _var {
  double* type;
  double* value;
} var;

Eseentially, the double* type is just pointing to something. In the
example it points to a char* to write out type.  In Csound, it could
point to a CS_TYPE. The test code does this:

1. Create a var to hold the variable.
2. Set type and value.
3. Advance pointer by one double* so that it now points to value.  Use
that to set as the arg to an opcode.

>From here, if an opcode would want to access the type of the var, it
could take the address and subtract one to get to the type info.

Now, the creation of var's would happen by the instance() function.
Essentially, we'd pre-pad all vars with the type in the INSDS
instance's memory block.  We'd hook the pointer to the value area to
the opcodes, which is one address ahead of the type pointer.

The takeaway from this would be that all opcode today would continue
to function without change.  Any opcode that would want to access the
type could do so.  This paves the way for operations that require
run-time type information (such as having lists of variables of any
type).

Anyways, I found this to be an interesting possibility. My first
inclination was to make the value go first, then type, but then I
realized that the size of the data is different for each type.
Subtracting though would be by a constant offset size.  A bit of a
hack, but the easiest solution I've come up with for the situation
without trying to rewrite a lot of Csound.

I'm not sure if we need this just yet, but thought I'd email this now
so that it doesn't get lost.

Thanks!
steven

Would adding a field to hold the size of the data not be useful in this case?

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

On 10 May 2014, at 19:10, Steven Yi  wrote:

> Hi All,
> 
> I was exploring some ideas about retrofitting run-time type
> identification into Csound.  I thought I had a simple solution but
> when I went to try it I realized I had a fundamental flaw to the idea.
> However, I did manage to find a semi-hack.
> 
> I've attached a test file on how this would work.  Essentially, the
> issue is that all opcode use MYFLT* as pointers to memory for args.
> The MYFLT* is then cast to what kind of data the opcode really expects
> (i.e. could be MYFLT, but could be PVSDAT, etc.).  The trick to the
> code is in this struct:
> 
> typedef struct _var {
>  double* type;
>  double* value;
> } var;
> 
> Eseentially, the double* type is just pointing to something. In the
> example it points to a char* to write out type.  In Csound, it could
> point to a CS_TYPE. The test code does this:
> 
> 1. Create a var to hold the variable.
> 2. Set type and value.
> 3. Advance pointer by one double* so that it now points to value.  Use
> that to set as the arg to an opcode.
> 
>> From here, if an opcode would want to access the type of the var, it
> could take the address and subtract one to get to the type info.
> 
> Now, the creation of var's would happen by the instance() function.
> Essentially, we'd pre-pad all vars with the type in the INSDS
> instance's memory block.  We'd hook the pointer to the value area to
> the opcodes, which is one address ahead of the type pointer.
> 
> The takeaway from this would be that all opcode today would continue
> to function without change.  Any opcode that would want to access the
> type could do so.  This paves the way for operations that require
> run-time type information (such as having lists of variables of any
> type).
> 
> Anyways, I found this to be an interesting possibility. My first
> inclination was to make the value go first, then type, but then I
> realized that the size of the data is different for each type.
> Subtracting though would be by a constant offset size.  A bit of a
> hack, but the easiest solution I've come up with for the situation
> without trying to rewrite a lot of Csound.
> 
> I'm not sure if we need this just yet, but thought I'd email this now
> so that it doesn't get lost.
> 
> Thanks!
> steven
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Following up on this, thanks Michael for mentioning BSTR.  I think we
won't have issues with deallocation as all arguments to opcodes are
allocated elsewhere, in this case, as part of the calculated size for
the INSDS instrument instance.

I'm not sure we need a separate size field, as the CS_VARIABLE should
hold the information for the size of the memory pointed to as the
argument.

I think this is certainly worth exploring in a branch.  I was thinking
with this, we should be able to do things like get rid of things like
STRCOD, which really is a form of run-time type identification. Using
CS_VAR's would be more generic though and open up a number of
possibilities that the STRCOD system couldn't scale up to.

On Sat, May 10, 2014 at 5:44 PM, Michael Gogins
 wrote:
> In Microsoft land, BSTR * is const char * with a size field just one int
> below the address of the string. THe is similar to your idea and we all use
> this every day, It does mean that the deallocator will have to be changed to
> deallocate Csound types starting with the type field.
>
> If the type field is a pointer, then the first field of the type structure
> can be size.
>
> Best,
> Mike
>
>
>
>
> -----------------------------------------------------
> Michael Gogins
> Irreducible Productions
> http://michaelgogins.tumblr.com
> Michael dot Gogins at gmail dot com
>
>
> On Sat, May 10, 2014 at 3:37 PM, Victor Lazzarini 
> wrote:
>>
>> Would adding a field to hold the size of the data not be useful in this
>> case?
>>
>> ========================
>> Dr Victor Lazzarini
>> Senior Lecturer
>> NUI Maynooth, Ireland
>> victor dot lazzarini at nuim dot ie
>>
>> On 10 May 2014, at 19:10, Steven Yi  wrote:
>>
>> > Hi All,
>> >
>> > I was exploring some ideas about retrofitting run-time type
>> > identification into Csound.  I thought I had a simple solution but
>> > when I went to try it I realized I had a fundamental flaw to the idea.
>> > However, I did manage to find a semi-hack.
>> >
>> > I've attached a test file on how this would work.  Essentially, the
>> > issue is that all opcode use MYFLT* as pointers to memory for args.
>> > The MYFLT* is then cast to what kind of data the opcode really expects
>> > (i.e. could be MYFLT, but could be PVSDAT, etc.).  The trick to the
>> > code is in this struct:
>> >
>> > typedef struct _var {
>> >  double* type;
>> >  double* value;
>> > } var;
>> >
>> > Eseentially, the double* type is just pointing to something. In the
>> > example it points to a char* to write out type.  In Csound, it could
>> > point to a CS_TYPE. The test code does this:
>> >
>> > 1. Create a var to hold the variable.
>> > 2. Set type and value.
>> > 3. Advance pointer by one double* so that it now points to value.  Use
>> > that to set as the arg to an opcode.
>> >
>> >> From here, if an opcode would want to access the type of the var, it
>> > could take the address and subtract one to get to the type info.
>> >
>> > Now, the creation of var's would happen by the instance() function.
>> > Essentially, we'd pre-pad all vars with the type in the INSDS
>> > instance's memory block.  We'd hook the pointer to the value area to
>> > the opcodes, which is one address ahead of the type pointer.
>> >
>> > The takeaway from this would be that all opcode today would continue
>> > to function without change.  Any opcode that would want to access the
>> > type could do so.  This paves the way for operations that require
>> > run-time type information (such as having lists of variables of any
>> > type).
>> >
>> > Anyways, I found this to be an interesting possibility. My first
>> > inclination was to make the value go first, then type, but then I
>> > realized that the size of the data is different for each type.
>> > Subtracting though would be by a constant offset size.  A bit of a
>> > hack, but the easiest solution I've come up with for the situation
>> > without trying to rewrite a lot of Csound.
>> >
>> > I'm not sure if we need this just yet, but thought I'd email this now
>> > so that it doesn't get lost.
>> >
>> > Thanks!
>> > steven
>> >
>> > ------------------------------------------------------------------------------
>> > Is your legacy SCM system holding you back? Join Perforce May 7 to find
>> > out:
>> > • 3 signs your SCM is hindering your productivity
>> > • Requirements for releasing software faster
>> > • Expert tips and advice for migrating your SCM now
>> >
>> > http://p.sf.net/sfu/perforce_______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Is your legacy SCM system holding you back? Join Perforce May 7 to find
>> out:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net