Menu
▾
▴
linuxsampler-devel
|
From: Rui N. C. <rn...@rn...> - 2004-06-20 17:00:18
Attachments:
linuxsampler-0.2-cvs20040619b.patch
|
Hi,
linuxsampler 0.2.x:
* Changed LSCPServer::LoadInstrument() signature, which adds a new
boolean argument (bool bBackground) where the loading mode maybe
selected, whether modal (the default), or modeless (in background).
This means that the LOAD INSTRUMENT command is back to the old modal
behavior, and the new LOAD_BACKGROUND INSTRUMENT just waits to be
implemented. These will be the intended mappings:
LOAD INSTRUMENT <file> <index> <channel>
-> LoadInstrument(file, index, channel, false);
LOAD_BACKGROUND INSTRUMENT <file> <index> <channel>
-> LoadInstrument(file, index, channel, true);
So, I'll ask the you lex/yacc gurus to put it to work asap :)
OTOH, this post of mine didn't get to the list, AFAICT, so I'll repeat it
here...
Hi Vladimir,
Christian,
Simon,
everybody
About the LOAD INSTRUMENT command, I've been doing simple implementation
changes (see attached patch). However I've stumbled on the
(f)lex/yacc/bison mysteries.
The fault is that my flex and bison installed packages probably aren't up
to par--they fail miserably while doing `make parser` under src/network.
I've give up for now.
My patch does try to implement the background mode for the LOAD
INSTRUMENT. However, I've bee trying to implement the following syntax:
LOAD INSTRUMENT <filename> <index> <channel> BACKGROUND
where I've introduced the BACKGROUND token to flag the modeless option.
I've noticed that Vladimir suggested a new LOAD_BACKGROUND verb instead of
an optional trailing particle like me. Of course, I prefer mine, but our
dictator must be heard ;)
Either way, the main change, which I think is about to stay, goes in
lscpserver.h/cpp, where I added a new boolean argument to
LSCPServer::LoadInstrument method (bool bBackground), where one opts for
the precise loading mode (default is false, that is modal).
Please try the patch and please help me on putting that damned flex/bison
stuff to work.
About the new quoting requirements, I'm all for it. Incidentally I was
predicting that myself, the bare proof is that liblscp implementation is
already prepared on parsing quoted responses. It even does not matter if
are single (') our double (").
However I personally find this new quoting requirement rather strange.
Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really
impossible having a syntax where a token is distinguishable from a
arbitrary literal value? Is it a lex/yacc fundamental limitation or what?
I'd rather have quotes optional, and only required where strictly
necessary, like e.g. in comma-separated list items.
Bye now.
--
rncbc aka Rui Nuno Capela
rn...@rn...
|
|
From: Vladimir S. <ha...@so...> - 2004-06-20 17:20:48
|
Hi Rui,
Thanks!
I'll put that code to work asap (after i fix CREATE AUDIO_OUTPUT_DEVICE).
I should have no problems now with the parser now after all that help
from Simon.
Regards,
Vladimir
Rui Nuno Capela wrote:
>Hi,
>
>linuxsampler 0.2.x:
>
>* Changed LSCPServer::LoadInstrument() signature, which adds a new
> boolean argument (bool bBackground) where the loading mode maybe
> selected, whether modal (the default), or modeless (in background).
>
>This means that the LOAD INSTRUMENT command is back to the old modal
>behavior, and the new LOAD_BACKGROUND INSTRUMENT just waits to be
>implemented. These will be the intended mappings:
>
> LOAD INSTRUMENT <file> <index> <channel>
> -> LoadInstrument(file, index, channel, false);
>
> LOAD_BACKGROUND INSTRUMENT <file> <index> <channel>
> -> LoadInstrument(file, index, channel, true);
>
>So, I'll ask the you lex/yacc gurus to put it to work asap :)
>
>OTOH, this post of mine didn't get to the list, AFAICT, so I'll repeat it
>here...
>
>Hi Vladimir,
>Christian,
>Simon,
>everybody
>
>About the LOAD INSTRUMENT command, I've been doing simple implementation
>changes (see attached patch). However I've stumbled on the
>(f)lex/yacc/bison mysteries.
>
>The fault is that my flex and bison installed packages probably aren't up
>to par--they fail miserably while doing `make parser` under src/network.
>I've give up for now.
>
>My patch does try to implement the background mode for the LOAD
>INSTRUMENT. However, I've bee trying to implement the following syntax:
>
> LOAD INSTRUMENT <filename> <index> <channel> BACKGROUND
>
>where I've introduced the BACKGROUND token to flag the modeless option.
>I've noticed that Vladimir suggested a new LOAD_BACKGROUND verb instead of
>an optional trailing particle like me. Of course, I prefer mine, but our
>dictator must be heard ;)
>
>Either way, the main change, which I think is about to stay, goes in
>lscpserver.h/cpp, where I added a new boolean argument to
>LSCPServer::LoadInstrument method (bool bBackground), where one opts for
>the precise loading mode (default is false, that is modal).
>
>Please try the patch and please help me on putting that damned flex/bison
>stuff to work.
>
>About the new quoting requirements, I'm all for it. Incidentally I was
>predicting that myself, the bare proof is that liblscp implementation is
>already prepared on parsing quoted responses. It even does not matter if
>are single (') our double (").
>
>However I personally find this new quoting requirement rather strange.
>Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really
>impossible having a syntax where a token is distinguishable from a
>arbitrary literal value? Is it a lex/yacc fundamental limitation or what?
>I'd rather have quotes optional, and only required where strictly
>necessary, like e.g. in comma-separated list items.
>
>Bye now.
>
>
>------------------------------------------------------------------------
>
>diff -duPNr linuxsampler-0.2-cvs20040619a/src/network/lscpserver.cpp linuxsampler-0.2-cvs20040619b/src/network/lscpserver.cpp
>--- linuxsampler-0.2-cvs20040619a/src/network/lscpserver.cpp 2004-06-19 20:16:49.000000000 +0100
>+++ linuxsampler-0.2-cvs20040619b/src/network/lscpserver.cpp 2004-06-19 23:17:54.332470712 +0100
>@@ -132,7 +132,7 @@
> /**
> * Will be called by the parser to load an instrument.
> */
>-String LSCPServer::LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel) {
>+String LSCPServer::LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel, bool bBackground) {
> dmsg(2,("LSCPServer: LoadInstrument(Filename=%s,Instrument=%d,SamplerChannel=%d)\n", Filename.c_str(), uiInstrument, uiSamplerChannel));
> LSCPResultSet result;
> try {
>@@ -140,8 +140,11 @@
> if (!pSamplerChannel) throw LinuxSamplerException("Index out of bounds");
> Engine* pEngine = pSamplerChannel->GetEngine();
> if (!pEngine) throw LinuxSamplerException("No engine loaded on channel");
>- LSCPLoadInstrument *pLoadInstrument = new LSCPLoadInstrument(pEngine, Filename.c_str(), uiInstrument);
>- pLoadInstrument->StartThread();
>+ if (bBackground) {
>+ LSCPLoadInstrument *pLoadInstrument = new LSCPLoadInstrument(pEngine, Filename.c_str(), uiInstrument);
>+ pLoadInstrument->StartThread();
>+ }
>+ else pEngine->LoadInstrument(Filename.c_str(), uiInstrument);
> }
> catch (LinuxSamplerException e) {
> result.Error(e);
>diff -duPNr linuxsampler-0.2-cvs20040619a/src/network/lscpserver.h linuxsampler-0.2-cvs20040619b/src/network/lscpserver.h
>--- linuxsampler-0.2-cvs20040619a/src/network/lscpserver.h 2004-06-19 20:16:49.000000000 +0100
>+++ linuxsampler-0.2-cvs20040619b/src/network/lscpserver.h 2004-06-19 23:17:54.332470712 +0100
>@@ -59,7 +59,7 @@
> // Methods called by the parser
> String CreateAudioOutputDevice(String Driver, std::map<String,String> Parameters);
> String DestroyAudioOutputDevice(uint DeviceIndex);
>- String LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel);
>+ String LoadInstrument(String Filename, uint uiInstrument, uint uiSamplerChannel, bool bBackground = false);
> String LoadEngine(String EngineName, uint uiSamplerChannel);
> String GetChannels();
> String AddChannel();
>diff -duPNr linuxsampler-0.2-cvs20040619a/src/network/lscp.y linuxsampler-0.2-cvs20040619b/src/network/lscp.y
>--- linuxsampler-0.2-cvs20040619a/src/network/lscp.y 2004-06-14 20:33:15.000000000 +0100
>+++ linuxsampler-0.2-cvs20040619b/src/network/lscp.y 2004-06-19 23:17:54.332470712 +0100
>@@ -59,6 +59,7 @@
> %token INSTRUMENT ENGINE
> %token AUDIO_OUTPUT_CHANNEL AUDIO_OUTPUT_CHANNEL_PARAMETER AUDIO_OUTPUT_DEVICE AUDIO_OUTPUT_DEVICES AUDIO_OUTPUT_DEVICE_PARAMETER AUDIO_OUTPUT_DRIVER AUDIO_OUTPUT_DRIVER_PARAMETER MIDI_INPUT_PORT MIDI_INPUT_CHANNEL MIDI_INPUT_TYPE VOLUME
> %token BYTES PERCENTAGE
>+%token BACKGROUND
>
> %type <Dotnum> volume
> %type <Number> sampler_channel instrument_index udp_port audio_output_channel midi_input_channel
>@@ -156,7 +157,8 @@
> list_instruction : AUDIO_OUTPUT_DEVICES { $$ = LSCPSERVER->GetAudioOutputDevices(); }
> ;
>
>-load_instr_args : filename SP instrument_index SP sampler_channel { $$ = LSCPSERVER->LoadInstrument($1, $3, $5); }
>+load_instr_args : filename SP instrument_index SP sampler_channel { $$ = LSCPSERVER->LoadInstrument($1, $3, $5, false); }
>+ | filename SP instrument_index SP sampler_channel SP BACKGROUND { $$ = LSCPSERVER->LoadInstrument($1, $3, $5, true); }
> ;
>
> load_engine_args : engine_name SP sampler_channel { $$ = LSCPSERVER->LoadEngine($1, $3); }
>
|
|
From: Vladimir S. <ha...@so...> - 2004-06-21 02:09:35
|
Hi All, Finally with some fixes and hacks CREATE AUDIO_OUTPUT_DEVICE is looking better. Background seems to be working ok too. (if not for that other crash i was mentioning before having to do with the fact that we can't set the audio output type yet). A lot of stuff still doesn't work. That includes destroying audio_output_devices, working with midi devices, mapping audio output devices to channels, detecting card specific parameter defaults and ranges etc, etc. I'm going to try to fix some of those issues next weekend. Time is tight so bear with me. Cheers, Vladimir. |
|
From: Rui N. C. <rn...@rn...> - 2004-06-21 09:32:02
|
Hi Simon, > >>However I personally find this new quoting requirement rather strange. >>Forgive my lex/yacc ignorance, but is it really unavoidable? Is it really >>impossible having a syntax where a token is distinguishable from a >>arbitrary literal value? Is it a lex/yacc fundamental limitation or what? >>I'd rather have quotes optional, and only required where strictly >>necessary, like e.g. in comma-separated list items. >> > I'm not sure the quoting was actually /unavoidable/. I suggested a couple > of ways the parser might have been fixed without introducing quotes but > they were difficult and/or inefficient and i'm not 100% sure they would > have worked. > > The argument for the introduction of quotes is: > > Its easier and more efficient to tokenise the protocol and then parse the > token-stream than it is to parse the protocol directly one character at > a time. Thats why lex and yacc exist as two separate tools. > > To tokenise the protocol its parts must be /lexically/ (as opposed to > syntactically) distinguishable from each other. > > The protocol carries arbitrary, user-entered strings, eg channel names, > which can only be lexically distinguished if they are delimited in some > way. > > Hence the quotes. > > Note that it is ONLY the values of string parameters which have the > quotes now. Setting a channel name looks like this: > > SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Name ="Monitor Left" > > but setting a numerical parameter is still: > > SET AUDIO_OUTPUT_CHANNEL PARAMETER 0 0 Whatever=2.27 > > Note also: The lexical analyser needs the quotes to see the strings... > but it "eats" the quotes as soon as it has seen them. It gives the > parser a string without quotes, and thats what the parser gives the > server. > > Its the packaging that has been changed, not the contents. > All right. The way it is, and as you've clarified above, it's in fact my personal preference, so we're all happy now. But (there's always a but :) maybe it isn't all about the quoting. What about that all-upper-case restriction for command keywords? And the parameter key names _must_ be capitalized or sort of. Isn't it too restrictive? I'd rather have LSCP case insensitive al together. Again, putting my logs into the fire ;) -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Simon J. <sje...@bl...> - 2004-06-21 11:08:51
|
Rui Nuno Capela wrote: >[...] What about that all-upper-case restriction for command keywords? And the >parameter key names _must_ be capitalized or sort of. > My suggestion was that "key names _must_ not match keywords" be the only rule - its sufficient - and that key names be mixed case by convention, rather than by law. That would allow for the occasional upper-case name where it made sense, eg for acronyms (still use ALSA rather than Alsa). The keywords are all upper case because... thats just the way they are. Its not a rule exactly (or IMHO shouldn't be) its simply the convention that was chosen/adopted. (FWIW I don't particularly like the upper case keywords because 1) its less readable, 2) its less typeable, 3) there's no need to shout, and 4) it isn't 1976 any more. But its not my place to rework the protocol according to my personal tastes/prejudices, especially when I lurked my way through the first eight drafts and am not involved in the software at either end of the link. So I'm just offering what help I can to make the parser work at all). >Isn't it too restrictive? I'd rather have LSCP case insensitive al together. > There's not much advantage in making the protocol case insensitive. Its not like the software at either end is going to forget to press the shift key. More likely it would fail to match an oddly cased key name because someone forgot ToUpper(). OK, some people might need to type LSCP by hand, but with a consistent set of conventions it shouldn't be too hard for them to get it right. The disadvantages of case insensitivity are 1) extra work in the lexical analyser and 2) extra opportunity for name/keyword clashes: It would no longer be possible to use the key name "Channel" because it would now clash with the keyword "CHANNEL". >Again, putting my logs into the fire ;) > > Me too. And its not even my fire. Simon Jenkins (Bristol, UK). |
|
From: Rui N. C. <rn...@rn...> - 2004-06-21 12:47:31
|
Hi Simon, > >>[...] What about that all-upper-case restriction for command keywords? >> And the parameter key names _must_ be capitalized or sort of. >> > My suggestion was that "key names _must_ not match keywords" be the only > rule - its sufficient - and that key names be mixed case by convention, > rather than by law. > That would allow for the occasional upper-case name where it made sense, > eg for acronyms (still use ALSA rather than Alsa). > Agreed. > The keywords are all upper case because... thats just the way they are. > Its not a rule exactly (or IMHO shouldn't be) its simply the convention > that was chosen/adopted. > > (FWIW I don't particularly like the upper case keywords because > 1) its less readable, > 2) its less typeable, > 3) there's no need to shout, and > 4) it isn't 1976 any more. > But its not my place to rework the protocol according to my personal > tastes/prejudices, especially when I lurked my way through the first > eight drafts and am not involved in the software at either end of the > link. So I'm just offering what help I can to make the parser work at > all). > >>Isn't it too restrictive? I'd rather have LSCP case insensitive al >> together. >> > There's not much advantage in making the protocol case insensitive. Its > not like the software at either end is going to forget to press the > shift key. > More likely it would fail to match an oddly cased key name because > someone forgot ToUpper(). > OK, some people might need to type LSCP by hand, but with a consistent > set of conventions it shouldn't be too hard for them to get it right. > > The disadvantages of case insensitivity are > 1) extra work in the lexical analyser and > 2) extra opportunity for name/keyword clashes: It would no longer be > possible to use the key name "Channel" because it would now clash with > the keyword "CHANNEL". > I surely understand about increased complexity for the lexical analyzer, but my complaints, or so to speak, were exactly about this clashing issue. Beware, ignorant's questions follows :) How can it be that a parser/syntax design is such that it can't resolve around distinguishing a keyword from a parameter key name? In my humble POV the position within the phrase would suffice to that. Is it a lex/yacc limitation or what, that a keyword is always taken literally, prioritary and unconditianally independant from where it occurs whithin a parsed sentence? Anyway, I can live with it. I only wish to know better. Finally, please forgive my not-so-good english, eheh, I hope you're not using a lex/yacc combination to read this :) Cheers. -- rncbc aka Rui Nuno Capela rn...@rn... |
|
From: Simon J. <sje...@bl...> - 2004-06-21 14:30:59
|
Rui Nuno Capela wrote: >How can it be that a parser/syntax design is such that it can't resolve >around distinguishing a keyword from a parameter key name? In my humble >POV the position within the phrase would suffice to that. > >Is it a lex/yacc limitation or what, that a keyword is always taken >literally, prioritary and unconditianally independant from where it occurs >whithin a parsed sentence? > Its possible to make it work like you say, but its not efficient. What happens at the moment is: 1. The lexical analyser sees the input first, tokenises it, and gives the tokens to the parser. The analyser /doesn't know/ where in the sentence it is... it simply knows that CHANNEL <----- is a keyword it has been told to recognise Channel <----- is not a keyword so it must be a name 2.67 <----- is a number "CHANNEL" <----- is a quoted string "Channel" <----- is a quoted string "2.67" <----- is a quoted string etc etc 2. The parser receives the tokens from the analyser. It knows exactly where in the sentence it is, but a "sentence", from the parser's POV, is a sequence of tokens not a sequence of characters. The purpose of this is to make everything a lot smaller and faster: The analyser handles the small-scale structure of the language with simple pattern matching rules, whilst the parser only handles the large-scale structure of the language with more complex grammatical rules. But to make it work like this you need a language whose parts can be identified in the analyser by simple pattern matching, not in the parser by where they are in a sentence If you want to distinguish keywords by where they are in a sentence then you have to abandon the lexical analyser and do /everything/ in the parser. The parser would have to look at the incoming characters, one at a time, and decide according to context whether it was seeing a keyword or a name or a string or a number. This is possible, but its much more expensive than doing it in a lexical analyser using simple pattern-matching. To summarise: ~ Tokenising makes the parser smaller and faster. ~ Therefore the protocol should be tokeniseable. Unless there's a _strong_ reason not to. Simon Jenkins (Bristol, UK) |
|
From: Christian S. <sch...@so...> - 2004-06-22 08:05:32
|
Hi everybody! I don't think I like all these tradeoffs in the protocol definition you're discussing the last days. :) The reason why I left this naive approach of the scanner/parser definition with all its ambiguities was the hope that we could find and move to a good parser generator that doesn't have this annoying or better say radical split between scanner and parser. That's the main problem of these ambiguities, not the protocol definition itself. So I would suggest to research for a better parser generator instead of doing all these unpretty and inconvinient tradeoffs and hacks. CU Christian P.S. case insensitivity does make sense; there's also a LSCP *shell* planned, which can handle autocompletion, etc., but not in the near future of course Es geschah am Montag, 21. Juni 2004 14:17 als Simon Jenkins schrieb: > Rui Nuno Capela wrote: > >[...] What about that all-upper-case restriction for command keywords? And > > the parameter key names _must_ be capitalized or sort of. > > My suggestion was that "key names _must_ not match keywords" be the only > rule - > its sufficient - and that key names be mixed case by convention, rather > than by law. > That would allow for the occasional upper-case name where it made sense, > eg for > acronyms (still use ALSA rather than Alsa). > > The keywords are all upper case because... thats just the way they are. > Its not a rule > exactly (or IMHO shouldn't be) its simply the convention that was > chosen/adopted. > > (FWIW I don't particularly like the upper case keywords because > 1) its less readable, > 2) its less typeable, > 3) there's no need to shout, and > 4) it isn't 1976 any more. > But its not my place to rework the protocol according to my personal > tastes/prejudices, > especially when I lurked my way through the first eight drafts and am > not involved in > the software at either end of the link. So I'm just offering what help I > can to make the > parser work at all). > > >Isn't it too restrictive? I'd rather have LSCP case insensitive al > > together. > > There's not much advantage in making the protocol case insensitive. Its > not like > the software at either end is going to forget to press the shift key. > More likely it > would fail to match an oddly cased key name because someone forgot > ToUpper(). > OK, some people might need to type LSCP by hand, but with a consistent > set of > conventions it shouldn't be too hard for them to get it right. > > The disadvantages of case insensitivity are > 1) extra work in the lexical analyser and > 2) extra opportunity for name/keyword clashes: It would no longer be > possible to > use the key name "Channel" because it would now clash with the keyword > "CHANNEL". > > >Again, putting my logs into the fire ;) > > Me too. And its not even my fire. > > Simon Jenkins > (Bristol, UK). > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference > Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer > Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA > REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND > _______________________________________________ > Linuxsampler-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel |
|
From: Simon J. <sje...@bl...> - 2004-06-22 21:30:15
|
Christian Schoenebeck wrote: >Hi everybody! > >I don't think I like all these tradeoffs in the protocol definition you're >discussing the last days. :) > All of them? There was one tradeoff (disallowing key names that match keywords so the parser can be smaller and faster) and one fix (putting quotes around string literals to repair a very large hole in an otherwise fairly tight spec). >The reason why I left this naive approach of the >scanner/parser definition with all its ambiguities was the hope that we could >find and move to a good parser generator that doesn't have this annoying or >better say radical split between scanner and parser. That's the main problem >of these ambiguities, not the protocol definition itself. > Its not about the tools. Yes, there are parser generators that accept more general grammars than yacc, eg Accent ( http://accent.compilertools.net ), but changing to one of them wouldn't resolve either of these issues: The Lex Tradeoff ~ If you don't think its a fair trade, you don't have to make it. Abandon lexical analysis for keywords and Yacc can generate a purely syntactic parser that's bigger and slower but can distinguish keywords from names by their position in the sentence. Switch to Accent? NO DIFFERENCE: You've still got exactly the same choice of whether or not to speed things up by lexing first. OK, maybe there's something out there that does something really clever, like flipping between different lexers according to context. But they've all got SOME notion of a lexical analysis phase, if only because... The String Problem ~ can ONLY be resolved lexically! Think about it... the protocol carries arbitrary, user entered strings. How can any parser POSSIBLY know where one of these strings ends without a lexical clue of some sort? Whatever the parser saw that might signal the end of a string could just as easily be more characters that were part of the string... it would have to wait /forever/ before it was sure. Simon Jenkins (Bristol, UK) |
|
From: Christian S. <sch...@so...> - 2004-06-23 07:46:22
|
Es geschah am Mittwoch, 23. Juni 2004 00:39 als Simon Jenkins schrieb: > Christian Schoenebeck wrote: > >I don't think I like all these tradeoffs in the protocol definition you're > >discussing the last days. :) > > All of them? There was one tradeoff (disallowing key names that match > keywords Thats one of the tradeoffs I definitely don't like. Because the driver developer should be able to add any parameter name he wants for his device driver. > so the parser can be smaller and faster) and one fix (putting quotes > around string literals Right, that was a relict, nothing against that of course. > OK, maybe there's something out there that does something really clever, > like flipping between different lexers according to context. But they've That's what I meant. The parser should at least work in such way together with the scanner, so the scanner only feeds the parser with terminal symbols which are defined in current (that is most congruent) grammar rule. The interface between lex and yacc is of course too primitive to allow such things. But there are a lot of parser generators out there, so I still hope we can find one that can do that and maybe even supports BNF, means an abstract definition of the protocol. > all got SOME notion of a lexical analysis phase, if only because... Lexical analysis itself is not the problem. > The String Problem ~ > can ONLY be resolved lexically! > > Think about it... the protocol carries arbitrary, user entered strings. > How can > any parser POSSIBLY know where one of these strings ends without a lexical > clue of some sort? Whatever the parser saw that might signal the end of > a string > could just as easily be more characters that were part of the string... > it would > have to wait /forever/ before it was sure. In our case the end of the wait would at least be the line feed character. But I agree that's not a good solution, so putting strings in apostrophes or quotes is far better from the parser's point of view. CU Christian |
|
From: Vladimir S. <ha...@so...> - 2004-06-23 12:40:29
|
Christian Schoenebeck wrote: >>>I don't think I like all these tradeoffs in the protocol definition you're >>>discussing the last days. :) >>> >>> >>All of them? There was one tradeoff (disallowing key names that match >>keywords >> >> > >Thats one of the tradeoffs I definitely don't like. Because the driver >developer should be able to add any parameter name he wants for his device >driver. > > There is an easy way to solve that is with the coding convention. For example, all tokens MUST be uppercase and all parameters MUST be lowercase. Does the driver developer care if his driver's parameters have to be lowercase? It can even be done for him automatically . . . I think this solves the issue and we can move on to solve other issues that have to do with the application. After all, we are not writing a parser, so we don't need to be 'perfect' there. Life and software are never perfect but as long as a particular solution solves the problem i don't see an issue. When you say 'one of the tradeoffs' what other tradeoffs do you see. Maybe i'm forgetting something but i thought that was the only one. >>so the parser can be smaller and faster) and one fix (putting quotes >>around string literals >> >> > >Right, that was a relict, nothing against that of course. > > > >>OK, maybe there's something out there that does something really clever, >>like flipping between different lexers according to context. But they've >> >> > >That's what I meant. The parser should at least work in such way together with >the scanner, so the scanner only feeds the parser with terminal symbols which >are defined in current (that is most congruent) grammar rule. The interface >between lex and yacc is of course too primitive to allow such things. But >there are a lot of parser generators out there, so I still hope we can find >one that can do that and maybe even supports BNF, means an abstract >definition of the protocol. > > We could. I'm not sure this is really necessary. The protocol is not that incredibly complex that we can't solve our issues using flex/bison combo. Again, i'm not a flex/bison person myself so i'd love to learn any other software as well so bring it on :) I just don't see any urgency in that. To me it's like priority number 65535 :) Regards, Vladimir. |
Thanks for helping keep SourceForge clean.
X