-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug in _TreeFindNodeWild with syntax such as .*** and :*** #417
Comments
The syntax is described at: Keith, can you write a parser for it ? I have an idea of how to make the search code much more simple. |
Given that some wildcard searches are broken, and there is ambiguity in the syntax for **** I propose we make the following syntax decisions: [[treename::]tagname{.|:}] Four single character punctuations
and these can be tripled to mad breadth first searches
four of these is a syntax error a special case would first translate *** to ~~~ Some examples
|
Given that some wildcard searches are broken, and there is ambiguity in the syntax for **** this change makes the following syntax changes: [[treename::]tagname{.|:}] Four single character punctuations '.' the child ':' the member '^' the parent '~' wildcard both member and child and these can be tripled to make breadth first searches '...' all children ':::' all members '~~~' all members and children '^^^' all parent four of these is a syntax error a special case would first translate *** to ~~~ (four of these is also a syntax error) however **** becomes ~~~* which is OK. Some examples a.b*.c - a child named c of a child starting with b of a member or child called a a.b*:c - a member named c of a child starting with b of a member or child called a a.b*~c -a member or child named c of a child starting with b of a member or child called a a.b...c - a child called c someplace under the child hierarchy under a.b a.b:::c - a member called c someplace under the member hierarchy under a.b a.b\~\~\~c - a child or member called c someplace under the child/member hierarchy under a.b a.b*\~\~\~ etc... Fixes issue #417 The new algorithm consists of: * use flex to scan (parse) the wildcard specification. Bison was not needed since the syntax is so simple. * find all the nodes on the initial call and place them in a list in memory. returning the 1st element * return elements from the list of found nodes until there are no more.
Given that some wildcard searches are broken, and there is ambiguity in the syntax for **** this change makes the following syntax changes: [[treename::]tagname{.|:}] Four single character punctuations '.' the child ':' the member '^' the parent '~' wildcard both member and child and these can be tripled to make breadth first searches '...' all children ':::' all members '~~~' all members and children '^^^' all parent four of these is a syntax error a special case would first translate *** to ~~~ (four of these is also a syntax error) however **** becomes ~~~* which is OK. Some examples a.b*.c - a child named c of a child starting with b of a member or child called a a.b*:c - a member named c of a child starting with b of a member or child called a a.b*~c -a member or child named c of a child starting with b of a member or child called a a.b...c - a child called c someplace under the child hierarchy under a.b a.b:::c - a member called c someplace under the member hierarchy under a.b a.b~~~c - a child or member called c someplace under the child/member hierarchy under a.b a.b*~~~ etc... Fixes issue #417 The new algorithm consists of: * use flex to scan (parse) the wildcard specification. Bison was not needed since the syntax is so simple. * find all the nodes on the initial call and place them in a list in memory. returning the 1st element * return elements from the list of found nodes until there are no more.
This bug may have been in MDSplus for a very long time but nobody used this search syntax before. That syntax started occurring mainly because of the way TreeNode.getNodeWild was implemented.
When the triple asterisk syntax is preceded by a period or colon, _TreeFindnodeWild seems to pass over some of the nodes multiple times sometimes causing the routine to return many more nodes than it should and in some cases infinitely recursing until the process runs out of memory.
The text was updated successfully, but these errors were encountered: