|
I'm trying to get the list of com port name and the device's name connected to it. (eg: I want to automatically find the COM port for a specific USB device of Fastrack modem M1206B series). In the case where it finds multiple possible ports and i want only finds the port depending on what other usb devices are connected. I tried the following where I get only the list of com ports.
[CODE]
string[] ports = SerialPort.GetPortNames();
foreach (string port in ports)
{
cboCOM.Items.Add(port);
}
[/CODE]
But I need get COMPort only finds the port depending on what other usb devices are connected.
|
|
|
|
|
Not having done anything with USB devices, would this document help? A USB Library to Detect USB Devices[^]
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
|
I used the Nokia E63 and run your code example but still not get the Nokia E63 COMPort. I run my code above to get comport I saw 3 but only 1 COM port COM4 port used to be, you have no way to remove the COM port can not be used ? you see my attach file http://imagizer.imageshack.com/img673/9968/t1MSeT.jpg
|
|
|
|
|
(No forum really fits..)
I'm trying to create a C#-like grammar in GOLD[^] that can handle generics with the same syntax like C# but the '<' is giving me trouble because the LALR-parser runs into a Shift-Reduce-conflict with the '<' used in the production for comparing values.
As I have seen in the C#-grammer-sample* that comes with GOLD you can do some acrobatics with the order of productions and whatnot to force the LALR-parser onto the right track (used for array-declarations there) but I can't figure out a way to make it work here.
* reflecting C# 1.0 I assume; my grammar is derived from it; the "acrobatics" are documented in the section titled "Statement Expressions & Local Variable Declaration"
I don't want to use a different parser because there's an extremely nifty framework (bsn[^]) to base your interpreter on which I'm already using - rather I'd use a different token than '<' to open a generic type argument list.
Here's the grammar, the culprit is on line 40/41 (section titled "Shared by multiple sections"). I realize due to its length it can be seen as a bit of an imposition. Please just don't bother if it doesn't really interest you 
"Case Sensitive" = 'True'
"Character Mapping" = 'Unicode'
"Start Symbol" = <Compilation Unit>
! ----------------------------------------------------------------- Sets
{ID Head} = {Letter} + [_]
{ID Tail} = {AlphaNumeric} + [_]
{String Ch} = {Printable} - ["]
{Lit String Ch} = {All Valid} - ["]
{Char Ch} = {Printable} - ['']
{Hex Digit} = {Digit} + [abcdef] + [ABCDEF]
{Bin Digit} = [01]
{Directive Ch} = {All Valid} - {CR} - {LF}
! ----------------------------------------------------------------- Terminals
Identifier = {ID Head} {ID Tail}*
MemberName = '.' {ID Head} {ID Tail}*
DecLiteral = {Digit}+ ( [UuLl] | [Uu][Ll] | [Ll][Uu] )?
RealLiteral = {Digit}*'.'{Digit}+ ( [dfmDFM] )?
StringLiteral = '"'( {String Ch} | '\'{Printable} )* '"' | '@' ('"' {Lit String Ch}+ '"')+
CharLiteral = '' ( {Char Ch} | '\'{Printable} )''
! ----------------------------------------------------------------- Comments
Comment Line = '//'
Comment Start = '/*'
Comment End = '*/'
! ===========================================================================
! Shared by multiple sections
! ===========================================================================
<Valid ID> ::= Identifier <Generic Type List Opt>
| <Base Type>
<Qualified ID> ::= <Valid ID> <Member List Opt>
<Member List Opt> ::= <Member List Opt> MemberName <Generic Type List Opt>
| !Zero or more
<Generic Type List Opt> ::= '<' <Generic Type List> '>'
|
<Generic Type List> ::= <Generic Type List> ',' <Generic Type>
| <Generic Type>
<Generic Type> ::= <Qualified ID>
! ===========================================================================
! Literals
! ===========================================================================
<Literal> ::= DecLiteral
| RealLiteral
| CharLiteral
| StringLiteral
| true
| false
| null
! ===========================================================================
! Types
! ===========================================================================
! The following defines built-in datatypes only. This is necessary for local
! variable declarations.
<Base Type> ::= <Other Type>
| <Integral Type>
<Other Type> ::= float
| double
| decimal
| bool
| object
| string
| datetime
| var
! Integral types are valid in enumeration declarations.
<Integral Type> ::= sbyte
| byte
| short
| ushort
| int
| uint
| long
| ulong
| char
! ===========================================================================
! C.2.4 Expressions
! ===========================================================================
<Expression Opt> ::= <Expression>
| !Nothing
<Expression List> ::= <Expression> ',' <Expression List>
| <Expression>
<Expression> ::= <Conditional Exp> '=' <Expression>
| <Conditional Exp> '+=' <Expression>
| <Conditional Exp> '-=' <Expression>
| <Conditional Exp> '*=' <Expression>
| <Conditional Exp> '/=' <Expression>
| <Conditional Exp>
<Conditional Exp> ::= <Or Exp> '?' <Or Exp> ':' <Conditional Exp>
| <Or Exp>
<Or Exp> ::= <Or Exp> '||' <And Exp>
| <And Exp>
<And Exp> ::= <And Exp> '&&' <Equality Exp>
| <Equality Exp>
<Equality Exp> ::= <Equality Exp> '==' <Compare Exp>
| <Equality Exp> '!=' <Compare Exp>
| <Compare Exp>
<Compare Exp> ::= <Compare Exp> '<' <Add Exp>
| <Compare Exp> '>' <Add Exp>
| <Compare Exp> '<=' <Add Exp>
| <Compare Exp> '>=' <Add Exp>
! | <Compare Exp> is <Qualified ID> ! <<<<< Shift-Reduce-Conflict
! | <Compare Exp> as <Qualified ID> ! <<<<< Shift-Reduce-Conflict
| <Add Exp>
<Add Exp> ::= <Add Exp> '+' <Mult Exp>
| <Add Exp> '-' <Mult Exp>
| <Mult Exp>
<Mult Exp> ::= <Mult Exp> '*' <Unary Exp>
| <Mult Exp> '/' <Unary Exp>
| <Mult Exp> '%' <Unary Exp>
| <Unary Exp>
<Unary Exp> ::= '!' <Unary Exp>
| '-' <Unary Exp>
| '++' <Unary Exp>
| '--' <Unary Exp>
| '(' <Expression> ')' <Method Exp> ! Cast "expression" is required to avoid a conflict
| <Method Exp>
<Method Exp> ::= <Method Exp> <Method>
| <Primary Exp>
<Primary Exp> ::= new <Qualified ID> '(' <Arg List Opt> ')' ! Non array creation
| '(' <Expression> ')'
| <Primary>
<Primary> ::= <Valid ID> '(' <Arg List Opt> ')' ! Current object method
| <Literal>
! | <Valid ID> ! replaced by <Base Type> / Identifier
| <Base Type>
! | Identifier ! <<<<< Shift-Reduce-Conflict
! ===========================================================================
! Arguments
! ===========================================================================
<Arg List Opt> ::= <Arg List>
| !Nothing
<Arg List> ::= <Argument> ',' <Arg List>
| <Argument>
<Argument> ::= <Expression>
! ===========================================================================
! C.2.5 Statements
! ===========================================================================
<Stm List> ::= <Statement> <Stm List>
| <Statement>
! This repetative productions below resolve the hanging-else problem by
! restricting the "if-then" statement to remove ambiguity. Two levels of
! statements are declared with the second, "restricted", group only used in
! the "then" clause of a "if-then-else" statement.
!
! The "restricted" group is completely identical the the first with one
! exception: only the "if-then-else" variant of the if statement is allowed.
! In other words, no "if" statements without "else" clauses can appear inside
! the "then" part of an "if-then-else" statement. Using this solution, the
! "else" will bind to the last "If" statement, and still allows chaining.
<Statement> ::= <Local Var Decl> ';'
| if '(' <Expression> ')' <Statement>
| if '(' <Expression> ')' <Then Stm> else <Statement>
| for '(' <For Init Opt> ';' <For Condition Opt> ';' <For Iterator Opt> ')' <Statement>
| while '(' <Expression> ')' <Statement>
| <Normal Stm>
<Then Stm> ::= if '(' <Expression> ')' <Then Stm> else <Then Stm>
| for '(' <For Init Opt> ';' <For Condition Opt> ';' <For Iterator Opt> ')' <Then Stm>
| while '(' <Expression> ')' <Then Stm>
| <Normal Stm>
<Normal Stm> ::= try <Block> <Catch Clauses Opt> <Finally Clause Opt>
| break ';'
| continue ';'
| return <Expression Opt> ';'
| display <Expression> ';'
| <Statement Exp> ';'
| <Block>
<Block> ::= '{' <Stm List> '}'
| '{' '}'
<Variable Declarator> ::= Identifier
| Identifier '=' <Expression>
! ===========================================================================
! For Clauses
! ===========================================================================
<For Init Opt> ::= <Local Var Decl>
| <Statement Exp List>
| !Nothing
<For Iterator Opt> ::= <Statement Exp List>
| !Nothing
<For Condition Opt> ::= <Expression>
| !Nothing
<Statement Exp List> ::= <Statement Exp> ',' <Statement Exp List>
| <Statement Exp>
! ===========================================================================
! Catch Clauses
! ===========================================================================
<Catch Clauses Opt> ::= <Catch Clause> <Catch Clauses Opt>
| !Nothing
<Catch Clause> ::= catch '(' <Qualified ID> Identifier ')' <Block>
<Finally Clause Opt> ::= finally <Block>
| !Nothing
! ===========================================================================
! Statement Expressions & Local Variable Declaration
! ===========================================================================
! The complex productions below are able to avoid the shift-reduce error caused
! by declaring an array. The notation used by C# (and the rest of the C++
! family) prevents an array declaration to be distinguished from an array
! assignment statement until a number of characters are read.
!
! a.b.c[2] = "Test"
! a.b.c[] = new String[3]
!
! The system CANNOT make a decision between the two until it is reading the
! contents the [ ... ].
!
! As a result, the local variable declaration below contains the full notation
! for each of the C# methods at the same level as local variable declarations.
! Since the system does not have to reduce UNTIL it is within the [ ... ], no
! shift-reduce error will occur. Nasty, huh?
<Local Var Decl> ::= <Qualified ID> <Variable Declarator>
<Statement Exp> ::= <Qualified ID> '(' <Arg List Opt> ')'
| <Qualified ID> '(' <Arg List Opt> ')' <Methods Opt> <Assign Tail>
| <Qualified ID> '[' <Expression List> ']' <Methods Opt> <Assign Tail>
| <Qualified ID> <Assign Tail>
<Assign Tail> ::= '++'
| '--'
| '=' <Expression>
| '+=' <Expression>
| '-=' <Expression>
| '*=' <Expression>
| '/=' <Expression>
<Methods Opt> ::= <Method> <Methods Opt>
| !Null
<Method> ::= MemberName ! <Generic Type List Opt> ! <<<<< Shift-Reduce-Conflict
! | MemberName <Generic Type List Opt> '(' <Arg List Opt> ')' ! <<<<< Shift-Reduce-Conflict
| '[' <Expression List> ']'
! ===========================================================================
! C.2.6 Namespaces
! ===========================================================================
<Compilation Unit> ::= <Using List Opt> <Compilation Items Opt>
<Using List Opt> ::= <Using Directive> <Using List Opt>
| !Nothing
<Using Directive> ::= using <Qualified ID> ';'
<Compilation Items Opt> ::= <Compilation Item> <Compilation Items Opt>
| ! Zero or more
<Compilation Item> ::= <Method Dec>
| <Statement>
! | '{' <Stm List> '}'
! ===========================================================================
! C.2.7 Classes
! ===========================================================================
<Method Dec> ::= <Qualified ID> Identifier <Generic Type List Opt> '(' <Formal Param List Opt> ')' <Block>
| 'void' Identifier <Generic Type List Opt> '(' <Formal Param List Opt> ')' <Block>
<Formal Param List Opt> ::= <Formal Param List>
| !Nothing
<Formal Param List> ::= <Formal Param> ',' <Formal Param List>
| <Formal Param>
<Formal Param> ::= <Qualified ID> Identifier
edit: grammar updated
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
modified 23-May-15 13:55pm.
|
|
|
|
|
|
No, unfortunately it doesn't help - I'm not writing the parser generator, I have to cope with what it can handle 
Kenneth Haugland wrote: I'm so curious. What you are going to use this for?
Please take a look at my response[^] to Manfred R. Bihy below
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Does this GOLD CC allow for multiple token lookahead or is it strictly LALR(1)?
Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
I've been dabbling for a bit in ANTLR[^] which is actually a Java project by a cool professor. There is also a C# port available, just look here: http://www.antlr.org/download.html[^].
If I remember correctly ANTLR is LL(K) which should help with your problem. I haven't really done any serious work with compilers the last eight years so guess I'm not of to much help there. 
Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Quote: Does this GOLD CC allow for multiple token lookahead or is it strictly LALR(1)?
It's strictly LALR(1).
Without knowing too much about parsers I had a gut feeling this might be the issue here. But I'm hoping that it's somehow possible to write the grammar in a way that one lookahead will suffice without butchering the syntax
The reason why I don't want to use another parser generator is that there's a framework/execution engine for GOLD which simplifies and beautifies the code you have to write for your interpreter - take a look at this:
public class If : Statement
{
private readonly Expression _test;
private readonly Statement _falseStatement;
private readonly Statement _trueStatement;
[Rule(@"<Stm> ::= ~if ~'(' <Expr> ~')' <Stm>")]
public If(Expression _test, Statement trueStatement)
: this(_test, trueStatement, null)
{
}
[Rule(@"<Stm> ::= ~if ~'(' <Expr> ~')' <Then Stm> ~else <Stm>")]
[Rule(@"<Then Stm> ::= ~if ~'(' <Expr> ~')' <Then Stm> ~else <Then Stm>")]
public If(Expression test, Statement trueStatement, Statement falseStatement)
{
_test = test;
_trueStatement = trueStatement;
_falseStatement = falseStatement;
}
protected override void DoExecute(IExecutionContext ctx)
{
if (Convert.ToBoolean(_test.GetValue(ctx)))
_trueStatement.Execute(ctx);
else if (_falseStatement != null)
_falseStatement.Execute(ctx);
}
}
You basically have nothing to do than write classes "like that" for your productions, put a Rule-attribute on the constructor(s), feed a source code into a "SematicProcessor"-class of that framework and it'll instantiate all those classes for you representing the fed program and you can call DoExecute(..) on the top node
It's for "yet another embeddable scripting engine" I wrote mainly for self-education. It doesn't bring a whole lot of new features to the table but it has a (IMO) very interesting twist which is why I intend to write an article about it. It's 90% finished (ignoring generics) so I wouldn't want to switch to another parser generator just for being able to replicate the C# syntax for generics - but it would be nice to have because you could just "drop in" existing C# code.
cheers, Sascha
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Wow, that rule attribute is sweet! 
Does GOLD also build an abstract syntax tree (AST)?
AST is one of the neat things about ANTLR. You can go over the syntax tree in multiple passes if you wish to and can do all sorts of optimizations on it.
Coming back to your problem: I remember doing some YACC stuff at uni and IIRC you can tell it try the shift first and if that didn't work out it'll do the reduce later.
This is what I found on the GOLD.org site:
Gold.org: Versions 2.4 and later of the GOLD Parser Builder automatically fixes Shift-Reduce Conflicts by not "reducing" when it would cause a conflict. This is the same behavior of the YACC compiler-compiler. It is best to closely check these states to determine if the "shift" is the action wanted.
So what version are you using then?
Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Wrong Site URL. It is http://goldparser.org/[^] not gold.org
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
Oh wow, glad you noticed that! Thanks for your, ehemm, contribution! 
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
I was rather confused by what popped up at the address you had in your post. I think others (esp. Noobs) might be as well.
What do you get when you cross a joke with a rhetorical question?
The metaphorical solid rear-end expulsions have impacted the metaphorical motorized bladed rotating air movement mechanism.
Do questions with multiple question marks annoy you???
|
|
|
|
|
I just had to download that GOLD ParserBuilder and try it out with your grammar.
As expected it showed only warnings of the Shift-Reduce conflict, but it produced the egt file just fine.
So it should work for you too, me thinks.
The Shift in favor of the reduce is totally acceptable if (pretty big if eh?) GOLD backtracks when subsequent tokens let the chosen production fail (That's the one it shifted on). So eventually it would fall back on the reduce production which is the compare expression production in your case.
What I just saw from 15 minutes of looking at this thing, I must say I'm pretty much impressed. Not only can you inspect the generated automaton, but also the messages for the conflicts were the best and most easily understandable compared to any of the CCs I have seen so far. (YACC, PROGRAMMAR, ANTLR).
What you really should do next is create a test file and run tests on the grammar to see if it can still parse comparisons as well as the generics.
Regards,
Manfred
P.S.: I totally forgot how much fun this is, makes me want to uses this tool for some fun project.
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Thank you for your effort, Manfred!
Initially I thought you might have solved the problem for me, pointing me to the shift-over-reduce precedence. I "theoretically" knew about this but (I guess) when I read it months ago I decided to go with my usual policy "warnings are errors" and disregarded that it might ever be a valid option.
But unfortunately it doesn't seem to be the solution (at least not by itself) because GOLD apparently does not backtrack: When trying to parse "var a = b < c;" the parser doesn't attempt the reduction and gives a syntax error. Looks like end of story?
Manfred R. Bihy wrote: P.S.: I totally forgot how much fun this is, makes me want to uses this tool for some fun project.
I think you'll enjoy my upcoming article - even with <:T> -syntax! 
Cheers, Sascha
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Momentarily I have the same result, but I still have an ace up my sleeve. If I find a solution I'll keep you updated.
Cheers!
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Manfred R. Bihy wrote: but I still have an ace up my sleeve
Feels like christmas anticipation
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Manfred, I found that my implementation for generics in the grammar is flawed, it's not possible to write "nested" generics like A<B<int>> . This is just FYI, I'll try to fix it and update the grammar in my original post.
cheers, Sascha
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Hi Manfred,
I think I've fixed the "generics nesting" in the grammar; I updated it in my original post. I also identified those productions that cause a conflict (5) and marked them with "<<<<< Shift-Reduce-Conflict", maybe it's helpful.
Have a nice long weekend -
cheers, Sascha
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
Hi Manfred! Did you get an opportunity yet to try playing your ace? 
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
What I had envisioned is not possible with GOLD.
Other programs like Antler allow for state or context switches, but it looks as if this can't be done with
GOLD.
Cheers
"I had the right to remain silent, but I didn't have the ability!"
Ron White, Comedian
|
|
|
|
|
Alright, thank you for trying!
cheers, Sascha
If the brain were so simple we could understand it, we would be so simple we couldn't. — Lyall Watson
|
|
|
|
|
HELLO!I know that you only can help me with some problems I might face in my code but i haven;t even understood the code that I have to work on. I am a university student and tomorrow I have to give my exercise to my tutor. I am putting here what I have to do and if anyone could help me in any way I would appreciate it. So I need to work on this: " Build a class that manages points having a fragmentary x and an ordinate y.Build a method "distance" which will calculate the distance between two points.Make another method "a.isFurther(B)" which will be able to find if "a" is further from the origin than "b" (Hint: you can use the previous method). Finally, build a method that checks whether three points are collinear."
|
|
|
|
|
Code Project is not a code-ordering site, and for that it is not a site for homework solving...
If you want help, you have to do the work by yourself, and come here with actual questions about actual problems in your code/solution...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
), but it sorta reminded me of Balanced grouping with RegEx: