I've just read the documentation here again, and it says the supervisor needs to explicitly check for the stop condition in the main loop, but it doesn't explain why it has to do so. What's the reason behind it?
So far for most of my code I've not included this condition and things still work fine. Is there a case I should be worried about here?
Also, if the condition is a standard code like:
if sv.should_stop():
sv.request_stop()
that has to be included every time a session was run, why couldn't it be included in a managed session by default? Meaning to say, is there a special use for writing this code explicitly in the for/while loop for training?
This is in case one of your queues becomes empty, or something else errors out and requires you to stop. If your queues are never empty and there are never any errors then you don't need to check.
There are a few threads on SO regarding this issue but none is answered really.
Apparently it has something to do with AVAudioPlayer but that's about it. No one seems to be able to point out what exactly to fix.
In my case, I get that error message but everything works fine. The audio file gets played, no crash, nothing. Anyhow I'd still like to know why I'm getting that error message and eventually, eliminate it completely.
This error doesn't show up often at all. It almost never happens but maybe once every 40 tries I'd get one... it is so random so I'm not sure what to do about it.
Can someone please help me?
I have a series of questions relating to debugging in Leksah, which does not seem to work, or maybe it is only me who is not using it correctly. I don't know.
I present the questions in a screencast because it is much more clearer to present it like that then in writing+pictures : https://www.youtube.com/watch?v=KeB8j_Viwrg
Main question : is this buggy behaviour of Leksah or is it only me who is not using it correctly ? If it is latter, how should I use the debug features correctly ?
Thanks heaps for making this video, it makes it much easier to follow what is going on!
I think the problem is that Haskell is really lazy. When you evaluated n at the very start of the debug session (before the video starts but you can see it in the log pane at the start of the video) n was replaced with the result (in this case 17). When you ask it to step into it there is nothing left to step into it is as iff you just had n=17 in the code.
Try restarting the the debug session or pressing Ctrl+B to force a :reload of the code. After you do this n should be an unevaluated thunk again and you should be able to step through it or set breakpoints in code it uses.
I am working with drools expert 6.0.0.Beta3 (latest available on the downloads page) and I am trying to update a rule existing in the working memory. Basically, I am calling add() of kBuilder again, like so:
kBuilder.add(org.drools.io.ResourceFactory.newByteArrayResource(drl.getBytes()),
org.drools.builder.ResourceType.DRL);
When I first add the rule, it gets added, and is even triggered when conditions meet. However, when calling add() again, as above, I get the following exception:
java.lang.NullPointerException
at org.drools.compiler.compiler.PackageBuilder.validateUniqueRuleNames(PackageBuilder.java:1314)
at org.drools.compiler.compiler.PackageBuilder.initPackageRegistry(PackageBuilder.java:916)
at org.drools.compiler.compiler.PackageBuilder.addPackage(PackageBuilder.java:869)
at org.drools.compiler.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:474)
at org.drools.compiler.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:670)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:51)
at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:40)
at org.drools.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:34)
...
You are doing something wrong since trying to add the same DRL twice to the KnowledgeBuilder will end up in having the same rule twice in the KnowledgeBase. Honestly I'd be curious to know why you're trying this.
Anyway you should have a compilation issue reporting the duplicated rule name and not a NPE. This is definitively a bug that I reported here and already fixed on the master.
Thanks for having found this.
Say you have the following code block:
if (Light.On) {
// do something...
} else if (Light.Off) {
// do something else...
} else {
// this state should never be reached
}
Now assume that the applications logic dictates that in this part of the code, the last state should never be reached, but it is not something that can be determined at compile time. And maybe there ARE other states (e.g. Light.Broken) which could be set by other parts of the application, but which are not used here.
What code do you add in the last else block?
Add no code, because it should not be reached anyway.
Add some logging functionality, so that you as a developer know that some illegal state has been reached.
Throw an exception, because the state must not be reached and if it is reached anyway, something else must be wrong.
The first option doesn't seem reasonable to me, hoping something goes right seems hardly the right choice. Option two has the advantage that your app doesn't crash right away, so if this happens in a rare occasion which was not caught in testing, the customer can continu using the application and the developer is notified of the problem. Option three causes the app to crash, which obviously is not something you want your customers to experience, but it does make it very clear that something is wrong.
What is the best way to handle such a situation?
EDIT, based on comments:
Some additional consideration to steer the discussion:
The contract of the method that contains the above code does not allow any other values to be set at that moment then On and Off.
Assume that the code is in a not-so-critical part of the application.
In development - fail hard and fail fast. Throw some kind of runtime exception, or just Assert(false).
In a release - shutdown gracefully. Your app is in an unusable state, and you cant realy on anything that you normally would, such as class invariants etc. Give the user a chance to save thir work, for example, try and log an error that could be sent back to the dev team and then shutdown.
EDIT: Based on comments added.
If the contract of the function states that the light shouold be on or off at function entry then any other state is an error. The function should fail, according to the principles outlined in my original answer.
Regarding the 'non-critical' aspaect - if a function precondition is not being met that means that your application is broken. Regardless of wether the error is detected in a non-critical piece of code, that does not imply that the problem itself is non-critical - you have no way of knowing that the bug that creates the invalid state doesnt also affect critical areas of code.
Well ... It depends. Having a third case for a boolean test would make me want to cry. It's just noise, adding confusion and telling me the developer was at least as confused as it makes me feel.
For a non-boolean, I guess you could do whatever ... If the ifs capture the states that are relevant to the code in question, there's no harm in just ignoring other cases. If there's a good chance that further cases will be needed in the future, a comment might be enough to indicate that for clarity.
As already said, in development phase you should make it visible as soon as possible. In release phase, it depends on how critical it is to reach this invalid state.
The least is to issue a log for debugging purpose.
Then you can try to recover from this invalid state either by going back to a previous valid state or by going to a new valid state.
Finally if nothing safe can be done, you can terminate the execution (with an alert to the user and a log to the maintainer).
3rd option is the correct as if for that part any other state is not valid so it should throw and exception saying invalid state.
Don't do anything. If all you care about is whether the light is on or not:
if (Light.On) {
// do some work
} else {
// too darned dark to work
}
Otherwise you should enumerate all your states.
If the other states are not allowed, you should error. If they're allowed but irrelevant, just ignore them. With properly designed code, there is no problem.
You're main problem here lies in a design that can have Light.On and Light.Off set at the same time. You should be using a state Light.State which is set to one of {on, flickering, off, broken, unplugged, exploded, emitting_dangerous_gamma_rays} and so on.
Throw an exception.
As you said, the third case should never occur. If it does happens, then something went wrong, and you don't know what else can be going wrong.
You also don't want calling code to think that code is working normally, when it is actually failing.
Additionally it makes it a lot easier to spot the issue Before it is released.
In the development version, just throw an exception.
In the release version:
Throw an exception
Save the user's work in some temporary file if possible
Save a crashdump and (using a small helper application) offer the user the option of sending it to you so you can identify and fix the problem