Separate the interface from running background routines (Solved)

[mrcoollion]

Hello fellow LC developers,

I want to build an application in such a way that the application interface is separate from the application ‘engine’ but they need to communicate witch each other (info and commands).
What is a good or best way to do this and has anybody have an example available?

To elaborate:
The user needs to be able to switch between cards in a stack while several routines need to be running unblocking at the same time. What the user does in the Cards can have an effect on what the running routines are doing. E.g. changing parameters or pausing or stopping the background routines.


Regards,

Paul

[jacque]

I do this frequently. Put the engine scripts into backscripts. (or assign as behaviors if appropriate) and then the UI stacks will work just as though the engine scripts were their own.

[dunbarx]

Paul.

A running handler, using "send in time", continues undisturbed if you change cards or if you leave LC entirely. These processes do not seem to care what else one does on any card on any stack anywhere at any time.

What are you seeing that breaks that? Or maybe the "send in time' methodology does not fit your needs as regards those "routines" you mentioned?

Craig

[FourthWorld]

Paul, can you tell us a bit more about why the processing needs to be parallel?

LC is single-threaded, but multiprocessing with inter-process comms over local sockets can be a practical solution, if the computation truly requires maxing all cores.

If you're merely looking for non-blocking operations to keep a UI fluid, Craig's suggestion can simulate backgrounding easily.

[dunbarx]

I had used a repetitive process to demonstrate a point, using 'send in time" over and over, just to keep things cooking. But any routine can be initiated at will with the plain "send" or "dispatch" commands, these being perhaps triggered by a similar repetitive "loop" that interrogates the stack for certain events, or any other property or action.

I am interested in what you find either just perfect or utterly useless in all this.

Craig

[mrcoollion]

Thanks for the information.

As requested some more information:
I am building an application that continuously scans the crypto markets and based on trigger criteria set by the user and an AI engine automatically places a buy or sell order. This application needs to keep monitoring and placing orders while the user at the same time should be able to change parameters, look in history information etc .

Only when the user gives the command the engine should stop scanning markets and placing buy/sell orders.

A good working simple example would be appreciated.

For those interested: The AI engine is based upon https://www.cs.waikato.ac.nz/ml/weka/


Paul

[dunbarx]

Paul.

As I said, a running "send in time" loop will happily keep, er, running, regardless of whatever else is going on, either within LC or outside of it. This includes manual or automatic interrogation of the internet, again either inside or outside of LC. The user will not see anything unusual. The background process will keep running, and can be accessed, or it will present itself in all its glory, depending on how you set it up.

I think this was your main issue: does this functionally exist in LC?

Yes.

I have attached a small stack that simply adds continuously to a field. If you press the optionKey, silly things happen, but the counter keeps on counting.
It does not matter what else you might do, or how any user action, message or property of the stack might be exploited. Messages are still generated in LC in the usual way. This is true even if you are in ANOTHER APP on your computer. Try it and see.

Modify the stack script (it is only four lines) to get data from your internet source and use it in whatever way you want to. The counter is still running...

Craig

startCounter2.livecode.zip

(1.32 KiB) Downloaded 208 times

[jacque]

One caveat: most handlers are blocking, which means no other handlers can run until the current one finishes. If the user chooses an acrion that requires some time to finish, the pending messages that were queued up with "send in time" will be delayed until the current handler is done. LC is very fast so generally the delay won't be noticible but if you are depending on split second accuracy it's something to be aware of.

[mrcoollion]

Thanks for the great support.

Ik made a small stack with 2 cards based upon the 99 Bottle example which does what I want.
I will upload it.

NonBlocking_MultiCard_UI_EngineProces_V02.zip

(2.48 KiB) Downloaded 214 times

Regards and thanks again....

Paul

[dunbarx]

What Jacque said. Nothing in this world is perfect.

Make sure, if you take this route, that you never wait without messages, minimize the use of dialog boxes, that sort of thing wherever you can if this might be as issue.

Craig

[mrcoollion]

Thanks Craig,

I only need to start routines every 30 seconds or so, so I am not worried about the speed. However, I do worry a bit about the recursion limit (40000 ?).
Could this be a problem in my case and if so is there a work around?

Regards,

Paul

[jacque]

Recursion usually only happens when one handler calls another that calls the first. Sending a message in <time> doesn't recurse. But you should make sure you don't have too many pending messages in the queue or they will pile up and then all execute at once or cause lag. Once you've received a pending message it is removed from the queue, but I usually do this to make sure I don't add extra ones:

Code: Select all

if "myMessage" is not in the pendingMessages then send "myMessage" to me in <time>

[dunbarx]

Jacque.

Recursion usually only happens when one handler calls another that calls the first.

I have seen this now and then even within a single "send in time" handler, where I am either interrogating some property or loitering for some event. It usually takes many minutes, and can be mitigated by waiting just a few ticks within each "loop". But that means, and this is only a theory, that if enough pendingMessages queue up it triggers the dialog. What else could it be? There is no "mindless repetitive" code flow that might gain the notice of the engine, because a new message is being sent each time through.

I could be wrong about this, but I know that a single "send in time" laden handler will terminate at 40K passes.

I have several machines running where this has occurred. A lot of loitering.

I have always wanted to be able to set the recursion limit. Could be dicey, I know, but I would be able to reduce the obligatory interrogation delay and not have to worry about extended inactivity stopping the whole process.

Craig

[rkriesel]

I have always wanted to be able to set the recursion limit.

Hi, Craig. Here's an example from the dictionary:

Code: Select all

set the recursionLimit to 20

-- Dick