Separate the interface from running background routines (Solved)

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, robinmiller

Post Reply
mrcoollion
Posts: 586
Joined: Thu Sep 11, 2014 1:49 pm
Location: The Netherlands

Separate the interface from running background routines (Solved)

Post by mrcoollion » Wed Sep 09, 2020 9:31 am

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
Last edited by mrcoollion on Thu Sep 10, 2020 6:55 pm, edited 1 time in total.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5663
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Separate the interface from running background routines

Post by jacque » Wed Sep 09, 2020 5:14 pm

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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7154
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Separate the interface from running background routines

Post by dunbarx » Wed Sep 09, 2020 9:31 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 8146
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Separate the interface from running background routines

Post by FourthWorld » Wed Sep 09, 2020 9:39 pm

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.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7154
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Separate the interface from running background routines

Post by dunbarx » Wed Sep 09, 2020 11:05 pm

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
Posts: 586
Joined: Thu Sep 11, 2014 1:49 pm
Location: The Netherlands

Re: Separate the interface from running background routines

Post by mrcoollion » Thu Sep 10, 2020 11:39 am

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7154
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Separate the interface from running background routines

Post by dunbarx » Thu Sep 10, 2020 2:35 pm

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 33 times

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5663
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Separate the interface from running background routines

Post by jacque » Thu Sep 10, 2020 6:22 pm

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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

mrcoollion
Posts: 586
Joined: Thu Sep 11, 2014 1:49 pm
Location: The Netherlands

Re: Separate the interface from running background routines

Post by mrcoollion » Thu Sep 10, 2020 6:54 pm

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 37 times
Regards and thanks again....

Paul
Last edited by mrcoollion on Sat Sep 12, 2020 9:50 am, edited 1 time in total.

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7154
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Separate the interface from running background routines (Solved)

Post by dunbarx » Thu Sep 10, 2020 8:08 pm

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
Posts: 586
Joined: Thu Sep 11, 2014 1:49 pm
Location: The Netherlands

Re: Separate the interface from running background routines (Solved)

Post by mrcoollion » Thu Sep 10, 2020 10:32 pm

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5663
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Separate the interface from running background routines (Solved)

Post by jacque » Thu Sep 10, 2020 10:38 pm

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>
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7154
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Separate the interface from running background routines (Solved)

Post by dunbarx » Fri Sep 11, 2020 12:36 am

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
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 87
Joined: Thu Apr 13, 2006 6:25 pm

Re: Separate the interface from running background routines (Solved)

Post by rkriesel » Fri Sep 11, 2020 12:50 am

dunbarx wrote:
Fri Sep 11, 2020 12:36 am
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

Post Reply

Return to “Talking LiveCode”