I was using PITclipse on Eclipse to run PIT mutation tests on code. There are three type of operators in PITclipse: DEFAULT, STRONGER and ALL).
What is the different between them and the list of mutants listed in each operator?
You can see the existing groups here: https://pitest.org/quickstart/mutators/
Each group has a different set of mutators/operators. I know that DEFAULT only includes mutators very well tested. If you choose ALL you may include some mutators that come up with false positives. From my experience is not common, but it has happened once to me
Related
After discovering (see here and here) that:
"VBA.Len" is not equivalent to "Len"
"VBA.LenB" is not equivalent to "LenB"
"VBA.Mid" is not equivalent to "Mid"
"VBA.Left$" is equivalent to "Left$"
and other confusing things like that:
"Left" and "InStr" are in this official list of keywords while it's not in this other official list of keywords
"InStrRev" and "LenB" don't appear in any official keywords lists while "InStr" and "Len" do appear in one or both lists
I'm left very confused about when to use "VBA." and when not.
Is there a way to obtain a real complete list of the native-internal VBA commands, more reliable than the official documentation?
I mean something like an "object browser" (where I can see the real complete list of the commands in the "VBA." library) for native-internal VBA commands?
The best resource is probably VBE's help and similar on-line, though it's not complete, and doesn't go into the details your raise. Also it doesn't document 'hidden' methods which were once intended to be deprecated but never were, some of which are very useful! Some of your questions were well answered in those other threads, but more generally about your points -
Qualifying with VBA is more about 'where' the method is sourced, and then whether or not there is any difference in the actual method, which in most cases there isn't apart from sourcing. Most of those strings functions are both in the Strings module and in the _HiddenInterface Interface (which is faster).
Left$ though is only in the Strings module, as are similar $ functions, and why you don't notice any difference in performance. Str is both in the _HiddenInterface and Conversion module.
If you're sure the unqualified versions do what you want you might think best to not to qualify, and generally that's fine. But if you ever end up with a project with a MISSING reference, unqualified Strings and DateTime functions will blow before your code has a chance to be alerted. Depending on how deployed or if not sure I tend to fully qualify, eg VBA.Strings.Left$, VBA.DateTime.Date. FWIW as a small bonus you'll get the intellisense.
Why do operators have different functions in different languages?
Because different languages exist to solve different problems, are developed at different times by different people with different levels of knowledge, under different outside constraints.
Depending on what problems a language tries to solve (or tries to solve first), some of the easier characters to type might have already been used for more common or newer concepts by the time a new operator is added.
E.g. PHP wasn't an object-oriented language at first, so used . as the concatenation operator. Then they added object-oriented PHP, and now they needed a different operator for identifying fields.
OTOH in a language like HyperTalk, which doesn't have data structures, you do not need a field-resolution operator at all.
I am using TeamCity with NCover integration and we want to exclude anonymous types from our code coverage reports. Is this possible? I've searched through the documentation and can't not find any mention of how or if this can be done.
You could use the fact that they are attributed with the CompilerGeneratedAttribute and exclude them, however this has the bad side effect of also excluding the expression in lambdas and possibly several other things.
//ea "System.Runtime.CompilerServices.CompilerGeneratedAttribute"
In our NCover setup we exclude code attributed with GeneratedCodeAttribute, but nothing else as we couldn't find a reliable way of determining those types. At the end of the day, anonymous types are very easy to cover if you have at least a single unit test on that code.
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.