I have initialized and started a solver, I have registered a listener for the best solution change but I would also like to know when solving has ended.
I have configured the logger and it correctly shows when the solver has stopped solving (when the termination condition is met or when it is terminated early). I would like to know when the solver has finished, whichever way it ended.
Here's my current code for listening for best solution changes
solver.addEventListener(new SolverEventListener() {
#Override
public void bestSolutionChanged(BestSolutionChangedEvent bestSolutionChangedEvent) {
//Get the new best solution
}
});
I have gone through the documentation several times but couldn't find what I need. Any ideas? Thanks.
PS: I'm using Optaplanner 6.0.1 final
When the Solver.solve() method returns.
Note when the daemon mode is explicitly set to true, that will only happen if Solver.terminateEarly() is called from another thread. Otherwise it will happen after the Termination says it's done too.
Related
I'm learning Flutter and recently found Microtasks. I've read up on it and I understand what Microtasks are and what the Microtask queue is, but am still a little confused why I'd ever use one.
I'd appreciate an real-world example or explanation of when/why to use a Microtask.
Thanks.
Here is a concrete example I found usefull to understand it. Some operation while the widget tree is building are forbidden. Most of the time it is used in initState
Consider you are using the provider package
initState() {
super.initState();
context.read<MyNotifier>().fetchSomething(); // -> not work
}
Actually fetchSomething() will call a http package to get data and some stuff. This is not allowed because the state update is synchronous and here there is a lap of time during the value (new/old) can change (here before and after the data loaded from http).
This could cause inconsistencies in your UI and is therefore not allowed.
A workaround is to use a microtask to achieve it. This will schedule it to happen on the next async task cycle (i.e. after build is complete here).
initState() {
super.initState();
Future.microtask(() =>
context.read<MyNotifier>().fetchSomething(someValue); --> this work
);
}
To sum up this example, Microtask is usually created if we need to complete a task later, but before returning control to the event loop.
I'm curently working on a projet with a STM32F334 and a STM32L476RG and I have a problem to making them talking with eachother. I'm using a DMA global interrupt like explained here.
I noticed a difference into the 'main.c' of my both projects:
With the F334: MX_DMA_Init() is done before MX_USART2_UART_Init()
With the L476RG: It's the opposite.
I tryed to inverse them and it works but only once... (at start)
So how could I tell the code generator to initialize the DMA before my USART2?
void HAL_UARTEx_RxEventCallback(UART_HandleTypeDef *huart, uint16_t size) {
if (huart->Instance == USART2) {
rs485_send_data(huart, g_rs485Input, size);
HAL_UARTEx_ReceiveToIdle_DMA(&huart2, g_rs485Input, RS485_INPUT_LENGTH);
__HAL_DMA_DISABLE_IT(&hdma_usart2_rx, DMA_IT_HT);
}
}
I has experimented same issue.
I build the same example for NUCLEO-L073RZ but at first, the function HAL_UARTEx_RxEventCallback was never called.
Then I read your question, and I set the order as You say
MX_DMA_Init() before MX_USART2_UART_Init()
(like in the controllerstech example). I reset the uart transmisor and debug again NUCLEO board.Then I had one breakpoint in HAL_UARTEx_RxEventCallback, so the program entered into the function an was stoped in the breakpoint. AS you say, the program enter in the breakpoint once in ever start.
So, I tried deleting this breakpoint in order to do not stop the program in debugging. After that, I watch in Live Expressions MainBuf, RxBuf, isOK, oldPos, newPos and it seems that is working perfectly.
Has you tried without breakpoints? Another way, you can try not debugging, running the program in normal mode and verify turning on one led or writing in other uart port.
Is not the first time that I have experienced irregular running of the program in debug mode.
I had a setup where I was using Lab View to communicate with the Nucleo-STM32F401RE over UART, I was having the same issue as you described.
The solution in my case was to make sure the parity bit was set to none, for some reason if it's set to something else it caused the behavior you're describing.
I have come across the same issue. It took me a while to realise, but in debug mode the HAL_UARTEx_RxEventCallback is never called. Couldn't find a way to fix this, unfortunately. However, my code did run fine when running normally.
I inherited some LabVIEW that has a time counter on it. Although I don't completely understand it because I am not familiar to LabVIEW and I have been successful to some extent.
What I couldn't make though, is to initialize this counter.
And this is my unsuccessful attempt (it just doesn't progress anymore).
I've seen this question that seems similar, but it didn't help me to solve my problem.
Also, my attempt was based on this NI help: http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/initializing_shift_registe/ after which I assumed it would work, but it doesn't.
This does what I believe you're going for. It now resets when first called or when the reset button is pressed. Also, I put a tiny wait in there to avoid unnecessary CPU loading.
The reason your attempt to fix it didn't work is because you were initializing the shift register of the timer every time it ran. That shift register has to be left uninitialized so it can retain the value from the previous run.
Here is example of timer, with reset functionallity. It is done as FGV - functional global variable.
Below are screenshots of the each state:
runAsync {} ui {}
The ui{ } block is triggered sometimes and sometimes not . What causing it .
From my understanding if the task in runAsync { } is a quick task then ui{} doesn't work . Please help. It's kind of frustrating.
This was actually a design flaw in the ui function. It simply attached the passed in function to the setOnSucceeded callback without checking if the task was already complete at this point. This has been corrected in tornadofx-1.7.14-SNAPSHOT, which is available in oss.sonatype.org now. See the README page for information about how to use snapshot releases :)
I've implemented a custom workitemhandler which I want to complete only by an external REST call. Therefore the items executeWorkItem() method does NOT call manager.completeWorkItem(workItem.getId(), results); at the end, which is perfectly ok. I've also assigned a signal event to this workitem in my process, which is also called by an external REST call. Both things work as expected, but what I do not understand is that every time I signal the work item, it also automatically completes the work item, which leads to the problem that the process continuous with its regular path AND the signaled one. But the reason for the signal is to interrupt the process to follow ONLY the signaled path path.
The process image to this can be found here http://cl.ly/image/0F3L3E2w2l0j. In this example I signaled the "Fail Transfer" but the rest gets also executed even nothing completed the workitem.
I'm using jBPM 6.1 Final.
Thanks in advance for any help.
Nevermind, I found the reason for this behavior. The custom work item handler implemented
public void abortWorkItem(WorkItem workItem, WorkItemManager manager) {
manager.abortWorkItem(workItem.getId());
}
After removing manager.abortWorkItem(workItem.getId());, the process behaves as expected.