Separate the interface from running background routines (Solved)
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Posts: 720
- Joined: Thu Sep 11, 2014 1:49 pm
- Location: The Netherlands
Separate the interface from running background routines (Solved)
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
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.
-
- VIP Livecode Opensource Backer
- Posts: 7229
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Separate the interface from running background routines
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
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9648
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Separate the interface from running background routines
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9823
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Separate the interface from running background routines
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.
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
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 9648
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Separate the interface from running background routines
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
I am interested in what you find either just perfect or utterly useless in all this.
Craig
-
- Posts: 720
- Joined: Thu Sep 11, 2014 1:49 pm
- Location: The Netherlands
Re: Separate the interface from running background routines
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
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
-
- VIP Livecode Opensource Backer
- Posts: 9648
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Separate the interface from running background routines
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
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
-
- VIP Livecode Opensource Backer
- Posts: 7229
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Separate the interface from running background routines
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
HyperActive Software | http://www.hyperactivesw.com
-
- Posts: 720
- Joined: Thu Sep 11, 2014 1:49 pm
- Location: The Netherlands
Re: Separate the interface from running background routines
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.
Regards and thanks again....
Paul
Ik made a small stack with 2 cards based upon the 99 Bottle example which does what I want.
I will upload it.
Regards and thanks again....
Paul
Last edited by mrcoollion on Sat Sep 12, 2020 9:50 am, edited 1 time in total.
-
- VIP Livecode Opensource Backer
- Posts: 9648
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Separate the interface from running background routines (Solved)
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
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
-
- Posts: 720
- Joined: Thu Sep 11, 2014 1:49 pm
- Location: The Netherlands
Re: Separate the interface from running background routines (Solved)
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
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
-
- VIP Livecode Opensource Backer
- Posts: 7229
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Separate the interface from running background routines (Solved)
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
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9648
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Separate the interface from running background routines (Solved)
Jacque.
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
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.Recursion usually only happens when one handler calls another that calls the first.
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
Re: Separate the interface from running background routines (Solved)
Hi, Craig. Here's an example from the dictionary:
Code: Select all
set the recursionLimit to 20