Im a trying to create a grammar in Javacc, and for a function name, I can have any assortment of lower character letters, or 'main'. If 'main' is the function name, then different procedures needed to be taken.
My problem is that main can not be matched as a string literal when it is included as a choice, and is matched to instead. So I was hoping that if I exclude the word 'main' from the token, then it might work!
< FUNCNAME: (["a"-"z"])+ ~["main"]>
The easiest thing to do is to make "main" a different token.
TOKEN: { <MAIN: "main" > }
TOKEN: { <FUNCNAME: (["a"-"z"])+ > }
Both rules match the prefix "main", but the first one wins because it is first. Note that "maintain" is still a FUNCNAME by the maximal munch rule. See FAQ 3.3 in the JavaCC FAQ.
Related
I am using the Symfony\Component\DomCrawler\Crawler package to find a form with a name containing a number of css special chars
<input name="myfield[0].thing">
I am using
$messageElement = $crawler->filter('input[name=myField[0].thing]');
return $messageElement->attr($attribute);
But I get the error
Symfony\Component\CssSelector\Exception\SyntaxErrorException: Expected "]", but found.
Obviously this is because the symfony css selector is using [ ] to contain the attributes. So If I try an escape all the special chars
$crawler->filter('input[name=myField\[0\]\.thing]');
I now get empty output. How can I fix this?
Bonus question: is it possible to use a wildcard instead? * doesn't seem to work for me.
If you encapsulate the field name it should work, try this:
$messageElement = $crawler->filter('input[name="myField[0].thing"]');
return $messageElement->attr($attribute);.
For the bonus question, you can use a regex match similar to suggested here: wildcard * in CSS for classes
// For matching strings starting with a certain thing notice the ^=
$messageElement = $crawler->filter('input[name^="myField[0]"]');
// For matching strings containing with a certain thing notice the *=
$messageElement = $crawler->filter('input[name*="myField[0]"]');
Is it possible to set the grammar to match case insensitively.
so for example a rule:
checkName = 'CHECK' Word;
would match check name as well as CHECK name
Creator of PEGKit here.
The only way to do this currently is to use a Semantic Predicate in a round-about sort of way:
checkName = { MATCHES_IGNORE_CASE(LS(1), #"check") }? Word Word;
Some explanations:
Semantic Predicates are a feature lifted directly from ANTLR. The Semantic Predicate part is the { ... }?. These can be placed anywhere in your grammar rules. They should contain either a single expression or a series of statements ending in a return statement which evaluates to a boolean value. This one contains a single expression. If the expression evaluates to false, matching of the current rule (checkName in this case) will fail. A true value will allow matching to proceed.
MATCHES_IGNORE_CASE(str, regexPattern) is a convenience macro I've defined for your use in Predicates and Actions to do regex matches. It has a case-sensitive friend: MATCHES(str, regexPattern). The second argument is an NSString* regex pattern. Meaning should be obvious.
LS(num) is another convenience macro for your use in Predicates/Actions. It means fetch a Lookahead String and the argument specifies how far to lookahead. So LS(1) means lookahead by 1. In other words, "fetch the string value of the first upcoming token the parser is about to try to match".
Notice that I'm still matching Word twice at the end there. The first Word is necessary for matching 'check' (even though it was already tested in the predicate, it was not matched and consumed). The second Word is for your name or whatever.
Hope that helps.
More than a long talk to explain that bug, here's a screenshot that explains everything :
As soon as we enter an "e" inside the url which correspond to rss_category, it no longer match the route. See :
!
We resolved this by forcing a requirements for {slugCat} to accept anything .^ (they were no requirements before)
If that can help someone somday, and if anyone has a valid explanation, i'll be glad to hear (runing under Symfony 2.1.1).
Wow, difficult one. This happens because when compiling the route, symfony tries to use the character preceeding the variable name as a separator. This code is from RouteCompiler.php:
// Use the character preceding the variable as a separator
$separators = array($match[0][0][0]);
if ($pos !== $len) {
// Use the character following the variable as the separator when available
$separators[] = $pattern[$pos];
}
$regexp = sprintf('[^%s]+', preg_quote(implode('', array_unique($separators)), self::REGEX_DELIMITER));
Symfony does this because usually you will have some kind of separator before the variable name, a route like /upload/rssArticle/{slugCat}, where '/' would be the separator and it is trying to be helpful by letting you use this separator to separate variables in routes which contain several variables. In your case, the character before the variable is an 'e' and that character becomes a separator and that is why your route does not match. If your route had beed /upload/rssArticles{slugCat}, then the 's' would be the separator and that would be the character you would not be able to use.
Maybe you could create an issue on the symfony router component. I think that the preceeding character should not be used as a separator if it is a letter or a number.
I am trying to write a regular expression for ASP.NET MapPageRoute that matches a specific type of path.
I do not want to match anything with a file extension so I used this regex ^[^.]*$ which worked fine except it also picked up if the default document was requested. I do not want it to pick up the default document so I have been trying to change it to require at least one character. I tried adding .{1,} or .+ to the beginning of the working regex but it stopped working alltogether.
routes.MapPageRoute("content", "{*contentpath}", "~/Content.aspx", true, new RouteValueDictionary { }, new RouteValueDictionary { { "contentpath", #"^[^.]*$" } });
How can I change my regex to accomplish this?
Unfortunately my brain does not seem capable of learning regular expressions properly.
You want to change your * quantifier to +. * matches zero or more times, whereas + matches one or more. So, what you are asking for is this:
^[^.]+$
The regex is accomplishing this: "At the beginning of the string, match all characters that are not ., at least one time, up to the end of the string."
^[^.]+$
zero is to * as one is to +
After much wrestling with the idea of ranking records, I finally settled on numeric based scores for my documents, which I emit to have them sorted based on these scores.
Now these numbers have meaning, where the 1st 2 digits represent a specific type of document.
Therefore, to get documents of type 22 sorted based on their scores, I simply query the view with start key being 220000 and end key being 229999
This is all great and works, my problems occur when I try to use url rewrites.
I'm basically trying to reroute:
/_rewrite/rankings/{doctype}
to
/_list/rankings?startkey=xx0000&endkeyxx9999
where xx is the {doctype}
my issue is with specifying rewrite rule:
[
{ "from":"rankings/:doctype",
"to":"_list/rankings",
"query": ??? //what will this be?
]
How can I construct the start and end keys by appending 0000 and 9999 respectively?
how can I specify a numeric value? since using place holder ":doctype" will result in a string type rather than a numberic type, resulting in a failed query even if I were to modify my pretty url to input both start and end keys.
I worked around the issue by filtering the results in my list view (ignoring docs im not interested in from getRow()), my concern here, should I worry about efficiency of list function now?
feel free to comment also on my sorting strategy .. would be interested to know how others solved their sorting and slicing problems with couchdb
Solution
First, you should emit the type and the score separately in an array instead of concatenating them:
emit([doc.type, doc.score], doc);
Then you can rewrite like this
[
{
"from" : "rankings/:doctype",
"to" : "_list/rankings/rankings",
"query" : {
"startkey" : [":doctype", 0],
"endkey" : [":doctype", 9999]
},
"formats": {
"doctype" : "int"
}
}
]
I tested it on CouchDB 1.1.1 and it works.
Reference
The relevant documentation is buried in this issue on JIRA: COUCHDB-1074
As you can see, the issue was resolved on April 2011, so it should work in CouchDB 1.0.3 and above.