The language is not changing, rather the infrastructure FOR the language is 
changing. I don't think most of these changes would affect the parser. If 
they do, I suspect it would be in defining new data types.

As I understand it, the parser is only involved in setting up the DSP graph. 
When the DSP graph is set up (i.e. the compiled instrument templates, 
opcodes chains, and i/o devices) then the parser is involved no more, and 
the graph just runs.

Also, the parser will have to be able to deal with plugin opcodes; I believe 
I recall John ffitch saying that it would do that.

Regards,
Mike

----- Original Message ----- 
From: "Richard Dobson" 
To: 
Sent: Tuesday, May 24, 2005 6:19 PM
Subject: Re: [Cs-dev] Jsound?


> Which makes sense; reasonable to defer completing the parser until the 
> language has stopped changing!
>
> Richard Dobson
>
>
> Istvan Varga wrote:
>
>> Victor Lazzarini wrote:
>>
>>> I noticed some new code in a directory called Jsound  in
>>> cs5 CVS. Is that the new parser?
>>
>>
>> Yes, although it does not look like being close to finished, and
>> seems to be outdated with respect to language changes introduced
>> since about 2002.
>>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 




-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "Michael" == Michael Gogins  writes:

 Michael> The language is not changing, rather the infrastructure FOR
 Michael> the language is changing. I don't think most of these
 Michael> changes would affect the parser. If they do, I suspect it
 Michael> would be in defining new data types.

The language has changed considerably.  At one stage the J-parser could
handle the entire language, but the introduction if a number of
changes has widened the gap.  Indeed I have made mild protests when
changes were made that made things harder, especially when the details
were not made clear

 Michael> As I understand it, the parser is only involved in setting
 Michael> up the DSP graph.  When the DSP graph is set up (i.e. the
 Michael> compiled instrument templates, opcodes chains, and i/o
 Michael> devices) then the parser is involved no more, and the graph
 Michael> just runs.

A major rewrite was necessary when opcodes were not known to the
parser.  That rewrite was completed in a boring meeting a month or two
back, but there is a known stupidity in the parse tree.

 Michael> Also, the parser will have to be able to deal with plugin
 Michael> opcodes; I believe I recall John ffitch saying that it would
 Michael> do that.

The big whole is UDO which I do not understand and have never used.
I do not understand either their syntax nor their semantics.

The working version compiled Csound->Csound and produced a more
efficient running system even at that stage.  The semantics checking
was almost complete as I remember it.  That need revisiting in the
light of plugin opcodes.

==John ffitch


-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

jpff@codemist.co.uk wrote:

> The big whole is UDO which I do not understand and have never used.
> I do not understand either their syntax nor their semantics.
> 
> The working version compiled Csound->Csound and produced a more
> efficient running system even at that stage.  The semantics checking
> was almost complete as I remember it.  That need revisiting in the
> light of plugin opcodes.

Does this mean that the parser has trouble with dynamically adding
opcodes at run-time ? I see the opcode list (of about Csound 4.20 or so)
hardcoded into the parser sources, as well as opcode names defined as
macros like T_CTRLINIT, T_STRSET, T_RND31, etc.
I also noticed
   instrdecl         : T_INSTR T_INTGR S_NL statementlist T_ENDIN S_NL
                           { start_instr(((TOKEN*)$2)->value);
                             statement_list = (TREE*)$4;
                             end_instr(); }
does this mean that the ability of defining instruments with string
names and multiple numbers was removed ?



-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

>>>>> "Istvan" == Istvan Varga  writes:

 Istvan> jpff@codemist.co.uk wrote:
 >> The big whole is UDO which I do not understand and have never used.
 >> I do not understand either their syntax nor their semantics.
 >> 
 >> The working version compiled Csound->Csound and produced a more
 >> efficient running system even at that stage.  The semantics checking
 >> was almost complete as I remember it.  That need revisiting in the
 >> light of plugin opcodes.
                                                ^______needed

 Istvan> Does this mean that the parser has trouble with dynamically adding
 Istvan> opcodes at run-time ? I see the opcode list (of about Csound 4.20 or so)
 Istvan> hardcoded into the parser sources, as well as opcode names defined as
 Istvan> macros like T_CTRLINIT, T_STRSET, T_RND31, etc.
 Istvan> I also noticed
 Istvan>    instrdecl         : T_INSTR T_INTGR S_NL statementlist T_ENDIN S_NL
 Istvan>                            { start_instr(((TOKEN*)$2)->value);
 Istvan>                              statement_list = (TREE*)$4;
 Istvan>                              end_instr(); }
 Istvan> does this mean that the ability of defining instruments with string
 Istvan> names and multiple numbers was removed ?

Then I comitted the wrong version.  It can and does handle plugin
opcodes as i said in my last message (been off air all dat trying to
fix a firewall).  The functions are hardwired though.


==John ffitch


-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net