For instance if I have some rule rule <k> foo bar => baz </k> <barList> bars </barList> and I only want to heat the rule when bar is in my list bars I believe I would add either requires bar in bars or when bar in bars. I've been using when as my go-to without issue but reading the K manual pending documentation it seems like requires may be preferred for this. Both seem to mean "only heat this rule if this condition is met" so I'm unclear on what the difference between requires and when is as well as in which circumstances to use which. Thanks!
when and requires are synonyms, but when is considered deprecated, so use requires instead.
Related
I am trying to lex/parse an existing language by using XText. I have already decided I will use a custom ANTLRv3 lexer, as the language cannot be lexed in a context-free way. Fortunately, I do not need parser information; just the previously encountered tokens is enough to decide the lexing mode.
The target language has an InputSection that can be described as follows: InputSection: INPUT_SECTION A=ID B=ID;. However, it can be specified in two different ways.
; The canonical way
$InputSection Foo Bar
$SomeOtherSection Fonzie
; The haphazard way
$InputSection Foo
$SomeOtherSection Fonzie
$InputSection Bar
Could I use TokenStreamRewriter to reorder all tokens in the canonical way, before passing this on to the parser? Or will this generate issues in XText later?
After a lot of investigation, I have come to the conclusion that editor tools themselves are truly not fit for this type of problem.
If you would start typing on one rule, you would have to take into account the AST context from subsequent sections to know how to auto-complete. At the same time, this will be very confusing for the user.
In the end, I will therefore simply not support this obscure feature of the language. Instead, the AST will be constructed so that a section (reasonably) divided between two parts will still parse correctly.
In the wit.ai UI when entering a story the interface constantly identifies and tags a number of entities that I don't want it to.
Screenshot showing UI
In the image above you can see two "package_type" entities being registered against the "How do I buy" sentence. I cant stop this from happening. Its wrong.
If I remove them manually, it adds them back in anyway.
I've reached out to their support, with no answer and also tweeted them to see if I can get a response.
Any help would be greatly appreciated.
You have to define correctly the package_type entity in Understanding tab. What search strategy to choose. If you know that package_type will always be one of the standard words from some sort of a list = set it only to be keywords and add them in the list (all in Understanding tab). That would be very strict and correct recognition of the entity all the time!
If you set package_type to be free-text and keywords - then that entity will be recognized by the existing keyword OR also you trust wit to "guess" it sometimes - things might go fuzzy here.
And if you use "trait" ... just don't:) don't use it for the type of entities which are more or less defined topics. This is used more for "detecting" the notion of the phrase. Positive \ Negative \ Happy \ Sad... It works - but it's a little fuzzy too:)
So just switch package_type to keywords, add some package types to the keywords list and see how the recognition works.
Made this: https://wit.ai/yuraantonov/My%20First%20App/entities
I have a bunch of nodes on each side of a central node. I am trying to find a way to position the node lines so that they go to the right or left side of the nodes.
So for this:
http://jsbin.com/ipuxub/4/edit?js,output
I want the lines for the Jerry node to go to right side of Elaine, George, Kramer, etc.
While I don't think this is possible now:
Is there a way to force it, trick it or make it look better?
If it is changing the Cytoscape JS code, any suggestions to where I begin or look at or what would need to be changed?
Controlling edge control points more manually or adding support for node bend points are things we have planned to add in future, and I think either case would satisfy your use case.
However, we do not have the resources to do this in the short term: Both cases require our side to plan how those features would fit in with the model and visual style system (cy.js css).
In the short term, if you want to control where edges are drawn, you have to adjust the positions of the connected nodes -- because the edge positions are inferred between them. The first edge is straight between them, and for 2 or more beziers are used.
If moving node positions does not suffice for your usecase, the first steps would be for us to discuss and plan how this feature would work and how it would fit into the system: https://github.com/cytoscape/cytoscape.js/issues/359
Then if you're interested in implementing it, it would be a straightforward process. We could direct you to the relevant parts of the code that would need to be changed etc over a Google+ call.
Thanks -M
I want to program a custom version of the predicate cumulative/2 (or at least a similar predicate in terms of functionality). I looked for the sources of CLP(FD) library and I was now wondering whether it could be a good idea to modify that library (only by adding new things) in order to incorporate the new my_cumulative/2 but with the library's private predicates available to do so.
I want to add the following features:
I want the task planner to be preemptive (meaning that planned tasks can be "splitted" in several time intervals).
Apart from being cumulative, I want it to be multi-resource (meaning that instead of [limit(3)] I could have, for instance, [limit(2),limit(3),limit(1)]; where each limit corresponds to a different resource)
I want to add priorities to each task, so that higher priority tasks have more "decision power" and can't be left unscheduled by lower ones.
I want the solution "not-schedulable" to be a possible solution for a task.
This idea came to me when I was trying to add a custom operator /\ to calculate intersections (like-wise \/ denotes unions) and I saw that there actually is one already defined in clpfd.pl but not made part of the module.
For a start, you should try to express your constraints in terms of exported library predicates. If you need to use a private predicate of the library, you can call it with its module prefix (like clpfd:some_predicate(...)). Private predicates may change without notice, but they can be useful if you want to experiment with some things, and you can ask for more public predicates etc. on the SWI mailing list when you have found out which ones are useful to you. To calculate intersections with public predicates, you can use for example: X in 0..5 #/\ X in 0..2, fd_dom(X, Dom). You can use (#\/) for unions.
You can define a new module and within it use the reexport/1 and reexport/2 directives to reexport the full CLP(FD) library or just part of it. In this new module, you can add new stuff or override the existing one if necessary.
I am using HP Exstream (formerly Dialogue from Exstream Software) version 5.0.x. It has a feature to define and save boolean expressions as "Rules".
It has been about 6 years since I used this, but does anybody know if you can define a rule in terms of another rule? There is a "VB-like" language in a popup window, so you are not forced to use the and/or, variable-relational expression form, but I don't have documentation handy. :-(
I would like to define a rule, "NotFoo", in terms of "Foo", instead of repeating the inverse of the whole thing. (Yes, that would be retarded, but that's probably what I will be forced to do, as in other examples of what I am maintaining.) Actually, nested rules would have many uses, if I can figure out how to do it.
I later found that what one needs to do in this case is create user defined "functions", which can reference each other (so long as you avoid indirect recursion). Then, use the functions to define the "rules" (and, don't even bother with "library" rules instead of "inline" rules, most of the time).
I'm late to the question but since you had to answer yourself there is a better way to handle it.
The issue with using functions and testing the result is that there's a good chance that you're going to be adding unnecessary processing because the engine will run through the function every time it's called. Not a big issue with a simple function but it can easily become a problem if the function is complex, especially if it's called in several places.
Depending on the timing of the function (you didn't say whether it was a run level, customer level, or specific to particular documents), it's often better to have the function set a User Boolean variable to store the result then in your library rules you can just check the value of the variable without having to run through the function every time.