Community
Participate
Working Groups
It would be nice to have INFO be one of the reporting levels for chk file validation. I have a number of cases where a model issue is not necessarily a problem, but the user might want to be made aware of it. I know that it is possible to handle that with warnings but I find that sometimes that ends up making things look like problems that need to be fixed.
+ 1 Additionally to this it would be also nice, if the user could specify custom severities.
Agreed that it would be nice to be able to do custom severities. The overall issue is that chk should support (at least) the current IStatus contract for standard eclipse logging.
I can't reproduce the issue on the Mac, but that doesn't mean its not happening. :) Jonas, I think you guys are on XP.. any chance you can confirm this? Ranier, I've confirmed that the code generation is also an issue. Please see related bug for a workaround
I wonder if that is useful. I usually cover only real constraints be Check. For other things I use stdlib::io for logging of additional information. Are there more parties interested in having this? Please vote for the bug.
(In reply to comment #4) > I wonder if that is useful. I usually cover only real constraints be Check. For > other things I use stdlib::io for logging of additional information. Are there > more parties interested in having this? Please vote for the bug. Hi Karsten, I'd also like to hear what others think. This is a nice to have, not a must have. Constraints are already inherently contextual in that everything besides error has no functional effect. So all we're doing here is providing a level of constraint that goes from "you should be concerned about this" to "this may affect you in some way". One might even interpret them as hints, i.e. "if you did this, then that would allow you to..". Also, these are not logging concerns, they are marker concerns, that is they should be associated with the file, not the session. (Though incidentally I do turn some logging issues into markers in my implementations, so even this distinction is a little fuzzy..) Anyway, I think I should spell out some use cases. Let's say you have a meta-model that allows the definition of a search problem. The use defines a model for a problem that is in NP. Now, there is nothing wrong with doing that, and it might be exactly what the user intended, but it would also be extremely helpful for the user to know that and perhaps suggest that the user consider employing an approximation algorithm later when the user decides to send the problem to a solver. The point is that there is no way for Chk to determine what the user's *intention* is. Similarly, imagine a case where the user might use a model in a number of different environments. If they use a feature that is not supported in a particular target environment, it would be nice to let the user know that, but again, that isn't really a warning because the user may never have intended to use the model in that environment to begin with. I submit that these are different in kind from say a java compiler warning, where warnings represent issues that are typically a problem area but might not affect the particular user.
This is a batch close of open M2T Xpand bugs. It is not planned work on this component in the foreseeable future. If you think this issue needs to be solved and you plan to contribute a fix then feel free to reopen it.
