Re: Threads in LC

[Bob Sneidar via use-livecode]

That would be awesome. I really need to do this for the File Storage library I 
want to include in my app. Right now I just save the PDFs on my local HDD, and 
each client has it’s own subset of the files it creates. But if I could pass 
the binary data for the PDF over a client server system of some sort, I could 
centrally store and recall all the documents from ALL the clients, hence the 
beginnings of a Document Capture and Storage app written in LC. 

Bob S


> On Jan 8, 2021, at 5:32 PM, Alex Tweedly via use-livecode 
>  wrote:
> 
> 
> On 08/01/2021 01:51, Bob Sneidar via use-livecode wrote:
>> I have thought about this a bit. If what you mean by multiprocessing is that 
>> a new process can be spawned while your app can go off and do other things 
>> and get notified later that something happened, then this is quite doable. 
>> If what you mean is that you want to make the app spawning the processes 
>> operate more efficiently by launching the same process over and over in 
>> multiple instances, then I don’t think so. At some point the parent process 
>> is going to have to get the result of each thread and do something about it.
> 
> I did something like this, but didn't spawn a new process for each asynch 
> task being launched.
> 
> What I did instead was have a very general purpose 'task handler' app, and 
> have multiple instances of this 'server app' running all the time; as long as 
> they're not doing any task, that's a negligible "cost" in resources. Each 
> instance would accept a socket connection on a different port (e.g. 6000, 
> 6001, 6002, ...) and would be passed "requests" to handle a specific task. It 
> would queue up multiple tasks, handle them in turn, and pass the result back 
> over the connection to whichever app requested it.
> 
> Then there was a client library, which would handle all the "messiness" for 
> the client, so the app need not be too involved. The app itself would simply 
> 'start using' the library, tell it which tasks it wanted to be able to do 
> (see below), and then pass in multiple requests through library calls. The 
> library would determine how many task-handler apps were available, parcel out 
> the requests between them, and provide the responses to the client (if 
> needed).
> 
> For each task (or set of tasks) you would write a library stack, which would 
> have handlers to perform the task(s), and respond.
> 
> 
> Example (trivial and may contain typos).
> 
> (you have to imagine that generating random numbers was very time consuming 
> :-),
> 
> 1. Write a library stack to perform some tasks.
> 
> stack "randomstuff"
> global gResultData, gResultObject   -- remember - one task at a time, so no 
> race conditions
> 
> on randomint pData
>local tmp, tMin, tMax
>put word 1 of pData into tMin
>put word 2 of pData into tMax
>put random(tMax - tMin + 1) into tmp
>put tmp-1 + tMin into gResultData
>send "completedTask" to gResultObject in 1 millisec
> end randomint
> 
> 
> 2. In the client app, determine the tasks to be handled
> 
> (within, say, openstack)
> 
>taskClientLoadStack "randomstuff.livecodescript"
> 
> 
> 3. when you need a number of random integers
> 
>   repeat 1000 times
> put taskClientSendARequest("randomstuff", "randomint 12 17", the long ID 
> of me) into tmp
>   end repeat
>-- (the return value is a request id - often can be ignored).
> ...
> on taskcomplete pID, pResult
>-- pID is the request ID, pResult is the returned data from that request
>put pResult  after sNumbers   -- or whatever
> ...
> end taskcomplete
> 
> In addition, there were various 'admin' taks you could request (close 
> connection, cancel pending tasks, get count of remaining tasks pending, ...). 
> The initial version of the client library simply round-robined the task 
> requests between the task-handlers, but the 'status' request would allow for 
> more intelligent load-balancing i fneeded.
> 
> 
> I did all this many years ago (2006 ??) and had this up on the earliest 
> version of revonline (which subsequently got deleted). I developed it to help 
> with indexing (including md5hash) of large numbers of image files. Using 4 
> task handlers, it was able to do the indexing in around 1/3 of the time the 
> single-threaded version took.
> 
> I still have the code - but unfortunately I can't find the write-up / 
> documentation on how to use it. And, I admit I absolutely cringe now to look 
> at the code - it *seriously* needs to be re-written, or heavily revised.
> 
> I'll clean up the code, write up how to use it and post it somewhere for 
> anyone who wishes to try it out.
> 
> Alex.
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode 

Re: Threads in LC

[Alex Tweedly via use-livecode]

On 08/01/2021 01:51, Bob Sneidar via use-livecode wrote:

I have thought about this a bit. If what you mean by multiprocessing is that a 
new process can be spawned while your app can go off and do other things and 
get notified later that something happened, then this is quite doable. If what 
you mean is that you want to make the app spawning the processes operate more 
efficiently by launching the same process over and over in multiple instances, 
then I don’t think so. At some point the parent process is going to have to get 
the result of each thread and do something about it.


I did something like this, but didn't spawn a new process for each 
asynch task being launched.


What I did instead was have a very general purpose 'task handler' app, 
and have multiple instances of this 'server app' running all the time; 
as long as they're not doing any task, that's a negligible "cost" in 
resources. Each instance would accept a socket connection on a different 
port (e.g. 6000, 6001, 6002, ...) and would be passed "requests" to 
handle a specific task. It would queue up multiple tasks, handle them in 
turn, and pass the result back over the connection to whichever app 
requested it.


Then there was a client library, which would handle all the "messiness" 
for the client, so the app need not be too involved. The app itself 
would simply 'start using' the library, tell it which tasks it wanted to 
be able to do (see below), and then pass in multiple requests through 
library calls. The library would determine how many task-handler apps 
were available, parcel out the requests between them, and provide the 
responses to the client (if needed).


For each task (or set of tasks) you would write a library stack, which 
would have handlers to perform the task(s), and respond.



Example (trivial and may contain typos).

(you have to imagine that generating random numbers was very time 
consuming :-),


1. Write a library stack to perform some tasks.

stack "randomstuff"
global gResultData, gResultObject   -- remember - one task at a time, so 
no race conditions


on randomint pData
   local tmp, tMin, tMax
   put word 1 of pData into tMin
   put word 2 of pData into tMax
   put random(tMax - tMin + 1) into tmp
   put tmp-1 + tMin into gResultData
   send "completedTask" to gResultObject in 1 millisec
end randomint


2. In the client app, determine the tasks to be handled

(within, say, openstack)

   taskClientLoadStack "randomstuff.livecodescript"


3. when you need a number of random integers

  repeat 1000 times
    put taskClientSendARequest("randomstuff", "randomint 12 17", the 
long ID of me) into tmp

  end repeat
   -- (the return value is a request id - often can be ignored).
...
on taskcomplete pID, pResult
   -- pID is the request ID, pResult is the returned data from that request
   put pResult  after sNumbers   -- or whatever
...
end taskcomplete

In addition, there were various 'admin' taks you could request (close 
connection, cancel pending tasks, get count of remaining tasks pending, 
...). The initial version of the client library simply round-robined the 
task requests between the task-handlers, but the 'status' request would 
allow for more intelligent load-balancing i fneeded.



I did all this many years ago (2006 ??) and had this up on the earliest 
version of revonline (which subsequently got deleted). I developed it to 
help with indexing (including md5hash) of large numbers of image files. 
Using 4 task handlers, it was able to do the indexing in around 1/3 of 
the time the single-threaded version took.


I still have the code - but unfortunately I can't find the write-up / 
documentation on how to use it. And, I admit I absolutely cringe now to 
look at the code - it *seriously* needs to be re-written, or heavily 
revised.


I'll clean up the code, write up how to use it and post it somewhere for 
anyone who wishes to try it out.


Alex.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[JeeJeeStudio via use-livecode]

Not that I know of. When using LC it uses the GPIO library/api from the 
Master Library in which it was embedded. If I recall correct that uses 
access to the GPIO library which is on the Raspberry.


For this i can't recall if i needed to install something via terminal, 
which i needed to do for use with Python.


It just uses LC script, no LCB. So therefore my unknown wissdom about 
multi-threading / multi-core thought simplistic that one core could do 
the gui (would be more GPU then) and one core the GPIO handling. But you 
see my knowledge about it is minor.


Of course i could also just use Python without GUI and ask for some 
input setting from the user, if in the end a Python GUI might also be to 
heavy (read interference from any mouse movements).


For the beginning i have Start and stop buttons running in SimplePyGui , 
it needs input for how many steps, speed and size of the steps and how 
much it has to be repeated.




Op 8-1-2021 om 00:07 schreef Richard Gaskin via use-livecode:

JeeJeeStudio wrote:

> So what i actually meant is multiprocessing, would that give
> advantage?

Maybe.

Does your Pi_gpio_output function use file I/O calls to the virtual 
file system in /run, or call an LCB or external using a lower-level 
interface for GPIO?




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[David Bovill via use-livecode]

I would find it very helpful if we would share some code in this “thread” about 
threads?

At the moment I have a need to break up a heavy indexing task on a LiveCode 
server into a series of smaller steps that execute asynchronously.

The web server receives a webhook  notifying it that there is some new data 
that needs indexing, and should reply immediately notifying receipt of the 
webhook.

This is one of the “easy” cases Bob was referring too I think. But I’m not sure 
until I see and can test the code what the right approach is. Approaches could 
be:

1) In LiveCode server return “put” a response the after use wait / send in time 
to do indexing. Does this work and not lockup the server?

2) Schedule cron jobs with LiveCode

3) Use shell commands such as “at” to schedule a task at a future time.

4) Use tools that can manage spawning of LiveCode server pseudo-threads

While this example might be server centric, I suspect that many of the 
principles carry over to the desktop and it is the most common use case for a 
need for “threads”
On 8 Jan 2021, 10:32 +, Graham Samuel via use-livecode 
, wrote:
> On a purely personal note (does that make it OT?), I think I am beginning to 
> accept, at a pretty advanced age, that just understanding LC coding is not 
> really enough to get stuff done. Linux for example I have managed to avoid, 
> and many other technologies… perhaps learning all this stuff is good use of 
> one’s time in lockdown (I’m in the UK at the moment). Can’t spend all one’s 
> time on the bike trainer…
>
> So, Richard, if you have time to expand a bit on Linux virtual directories, 
> I’d be grateful. But only if you have time.
>
> Graham
>
> > On 8 Jan 2021, at 07:19, Richard Gaskin via use-livecode 
> >  wrote:
> >
> > Peter Bogdanoff wrote:
> >
> > > On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
> > >
> > > > Maybe.
> > > >
> > > > Does your Pi_gpio_output function use file I/O calls to the virtual
> > > > file system in /run, or call an LCB or external using a lower-level
> > > > interface for GPIO?
> > >
> > >
> > > Maybe. Maybe not. In spite of all events, this may be the most
> > > challenging, nay, inscrutable question I have seen this year.
> >
> > From you I'll take that as a compliment. :)
> >
> > If this is interesting I don't mind breaking that down for people who don't 
> > yet spend as much time on the Raspberry Pi. Linux virtual directories are a 
> > pretty nifty invention.
> >
> > --
> > Richard Gaskin
> > Fourth World Systems
> > Software Design and Development for the Desktop, Mobile, and the Web
> > 
> > ambassa...@fourthworld.com http://www.FourthWorld.com
> >
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Graham Samuel via use-livecode]

On a purely personal note (does that make it OT?), I think I am beginning to 
accept, at a pretty advanced age, that just understanding LC coding is not 
really enough to get stuff done. Linux for example I have managed to avoid, and 
many other technologies… perhaps learning all this stuff is good use of one’s 
time in lockdown (I’m in the UK at the moment). Can’t spend all one’s time on 
the bike trainer…

So, Richard, if you have time to expand a bit on Linux virtual directories, I’d 
be grateful. But only if you have time.

Graham

> On 8 Jan 2021, at 07:19, Richard Gaskin via use-livecode 
>  wrote:
> 
> Peter Bogdanoff wrote:
> 
> > On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
> >
> >> Maybe.
> >>
> >> Does your Pi_gpio_output function use file I/O calls to the virtual
> >> file system in /run, or call an LCB or external using a lower-level
> >> interface for GPIO?
> >
> >
> > Maybe. Maybe not. In spite of all events, this may be the most
> > challenging, nay, inscrutable question I have seen this year.
> 
> From you I'll take that as a compliment. :)
> 
> If this is interesting I don't mind breaking that down for people who don't 
> yet spend as much time on the Raspberry Pi. Linux virtual directories are a 
> pretty nifty invention.
> 
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Richard Gaskin via use-livecode]

Peter Bogdanoff wrote:

> On Jan 7, 2021, at 3:07 PM, Richard Gaskin wrote:
>
>> Maybe.
>>
>> Does your Pi_gpio_output function use file I/O calls to the virtual
>> file system in /run, or call an LCB or external using a lower-level
>> interface for GPIO?
>
>
> Maybe. Maybe not. In spite of all events, this may be the most
> challenging, nay, inscrutable question I have seen this year.

From you I'll take that as a compliment. :)

If this is interesting I don't mind breaking that down for people who 
don't yet spend as much time on the Raspberry Pi. Linux virtual 
directories are a pretty nifty invention.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Bob Sneidar via use-livecode]

A little more clearly, ...respond DIRECTLY BACK to the original instances of 
the apps as opposed to the SPAWNING agent.


On Jan 7, 2021, at 5:51 PM, Bob Sneidar via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

The fix for this is of course to have the spawned query agents, let’s call 
them, respond DIRECTLY BACK to the original instances of the apps as opposed to 
the listening agent. This would free up the spawning agent from having to 
handle the callbacks itself. A passive system of sorts. Hmmm… doable I think.

Bob S

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Bob Sneidar via use-livecode]

I have thought about this a bit. If what you mean by multiprocessing is that a 
new process can be spawned while your app can go off and do other things and 
get notified later that something happened, then this is quite doable. If what 
you mean is that you want to make the app spawning the processes operate more 
efficiently by launching the same process over and over in multiple instances, 
then I don’t think so. At some point the parent process is going to have to get 
the result of each thread and do something about it.

This assumes you NEED to hear back from the process. If that is not necessary, 
if you have a really good chance that nothing can go wrong, then I suppose it 
can be something along the lines of network multicasting where the packets go 
out into the ether, and they are on their own.

The real advantage to setting up a pseudo multiprocessing system with LC is 
that your main process can go about it’s business while the child process is 
doing some heavy lifting. If the main process cannot continue, or continue very 
far without hearing back from the spawn, then the point is moot.

For example, I can see a scenario where an agent could listen for requests to 
query/update a database from a large number of clients, then spawn a new server 
agent for each request and delete it when finished, but then the listening 
agent becomes the single process bottleneck. All that would have been done is 
remove the bottleneck down the path one step, and incur network delay, and the 
time it takes to spawn and delete the child processes along the way.

The fix for this is of course to have the spawned query agents, let’s call 
them, respond DIRECTLY BACK to the original instances of the apps as opposed to 
the listening agent. This would free up the spawning agent from having to 
handle the callbacks itself. A passive system of sorts. Hmmm… doable I think.

Bob S


On Dec 31, 2020, at 9:22 AM, Bob Sneidar 
mailto:bobsnei...@iotecdigital.com>> wrote:

You can also try using callbacks, although the callback will not get processed 
until the next idle message (script execution termination or wait with 
messages).

Bob S


On Dec 31, 2020, at 8:53 AM, Rick Harrison via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Peter Bogdanoff via use-livecode]

Maybe. Maybe not. In spite of all events, this may be the most challenging, 
nay, inscrutable question I have seen this year.

Peter

> On Jan 7, 2021, at 3:07 PM, Richard Gaskin via use-livecode 
>  wrote:
> 
> JeeJeeStudio wrote:
> 
> > So what i actually meant is multiprocessing, would that give
> > advantage?
> 
> Maybe.
> 
> Does your Pi_gpio_output function use file I/O calls to the virtual file 
> system in /run, or call an LCB or external using a lower-level interface for 
> GPIO?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> 
> ambassa...@fourthworld.comhttp://www.FourthWorld.com
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Richard Gaskin via use-livecode]

JeeJeeStudio wrote:

> So what i actually meant is multiprocessing, would that give
> advantage?

Maybe.

Does your Pi_gpio_output function use file I/O calls to the virtual file 
system in /run, or call an LCB or external using a lower-level interface 
for GPIO?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[JeeJeeStudio via use-livecode]

For what i've seen and read is that one can run functions in their own 
thread, so you assign a thread to it.


I'm not very experienced in Python, but that is what i read and i found 
it interesting. (slowly progressing the motor project with simplepygui 
and the GPIO)


https://www.tutorialspoint.com/python/python_multithreading.htm

https://realpython.com/intro-to-python-threading/

Perhaps it is another way of calling it parallel and am i 
misinterpreting it as assigning stuff to another core.


So what i actually meant is multiprocessing, would that give advantage?

https://pymotw.com/2/multiprocessing/basics.html



Op 5-1-2021 om 22:38 schreef Richard Gaskin via use-livecode:

JeeJeeStudio wrote:

> i will experiment some more and else continue with the Puthon version.

Both Python and LiveCode are single-threaded.

IIRC, Python offers parallelism as a programming style, but unless 
you're using one of the special builds I don't believe it offers true 
concurrency (though both can handle concurrent tasks through 
multiprocessing).


This may be helpful here: how would you approach this in Python?

I wonder if we can tailor an LC approach to more closely resemble it, 
or at very least arrive at a language feature proposal to give us 
parallelism within a single-thread like Python does.




___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[doc hawk via use-livecode]

richard reminisced,

>I wonder if we can tailor an LC approach to more closely resemble it, or at 
>very least arrive
>at a language feature proposal to give us parallelism within a single-thread 
>like Python does.


I put some thought into this a few years ago.

It could begin with some not-quite-implemented language features and 
declarations.  (Perhaps “thread . . .” instead of “send”).

I also produced a master/slave pair of stacks.  Or, rather, a stack that acted 
differently when its filename started with “master” than with “slave”.

It was pretty straightforward to get them talking.

My intent was to have one running the application, and having the other send 
the Postgres requests.   However, with an open Postgres connection, things are 
fast enough that it turned out to be unnecessary.  (It also probably helped 
that I included a minimum delay from the last keyUp message before the 
“background” (by send in . . ) task would execute rather than kick itself down 
the clock a few seconds.

Anyway, the existing sockets might be expandable, allowing threads to 
essentially run their own instance of livecode and talk by message.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Richard Gaskin via use-livecode]

JeeJeeStudio wrote:

> i will experiment some more and else continue with the Puthon version.

Both Python and LiveCode are single-threaded.

IIRC, Python offers parallelism as a programming style, but unless 
you're using one of the special builds I don't believe it offers true 
concurrency (though both can handle concurrent tasks through 
multiprocessing).


This may be helpful here: how would you approach this in Python?

I wonder if we can tailor an LC approach to more closely resemble it, or 
at very least arrive at a language feature proposal to give us 
parallelism within a single-thread like Python does.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[JeeJeeStudio via use-livecode]

Hi Rick,


i will experiment some more and else continue with the Puthon version.

Thanks for the comparison. It seems other brands are offering more for 
buck, except maybe community support may be less. Don't know exactly.


Regards,

Jerry

Op 2-1-2021 om 23:00 schreef Rick Harrison via use-livecode:

Hi Jerry,

1 millisecond is probably asking too much of LC.
It doesn’t give an LC processor enough time to do
much of anything else and I can see why just
moving the mouse would affect the speed of the
motor.  I’m assuming that what you really want
is a steady rate for the motor rather than a
variable one.

Try some experiments with increasing the amount
of time in-between motor steps if you can.  You may
find a balance somewhere that is acceptable.

I also found this comparison of Banana Pi Vs. Raspberry Pi 3
which you may also find useful.

Good luck!

Rick

Banana Pi M3 Vs Raspberry Pi 3 Benchmark

Aspects Banana Pi M3Raspberry Pi 3
Processor   ARM V7 Cortex A7ARM V8 Cortex A53
Frequency   1.8GHz  1.2GHz
CPU Cores   8   4
RAM 2GB DDR31GB DDR2
SoC A83TBCM2837
Storage Micro SD/USB SATA 2.0   Micro SD 

Onboard Storage 8GB eMMCNo
GPU PowerVR SGX544MPBroadcom VideoCore IV
GPU Speed   700MHz  400MHz
GPIO Pins   40  40
USB 2.0 2 + 1 OTG   4
Power 

5V 2A   5V 2.5A



On Jan 1, 2021, at 11:20 AM, JeeJeeStudio via use-livecode 
 wrote:

Hi Rick,

thanks fo responding.

It's a Pi 3 model B+, should be fast enough for this simple task.

on clockWise
 -steps between pos and wait
   repeat for sStp times --clockwise
  Pi_gpio_output 20, 0 --dir
   Pi_gpio_output 21, 1 --step
   wait sSpd milliseconds with messages
   Pi_gpio_output 21, 0
   wait sSpd milliseconds with messages
 if the mouse is down
   then
  Pi_gpio_output 21, 0 --step
  set the label of me to "Start"
   exit repeat
end if
 end repeat
end clockWise

The time between a 1 and a 0 on the output is 1ms. I can lower the speed and 
thus increase time, but that does not matter.

I think I tried it once with send in time, not a succes. So maybe i have to 
rewrite that with a different mindsetting. I don't have all stack with me at 
the moment.

The above piece is from an older stack, but the last is similar.

Also the wait shall not be the most convenient wait to handle this.

It also has of course an counterClockwise handler which is similar, but then 
output 20 is a 1.

it should run for so many steps, then wait a few seconds and then return. If 
there is one position. If there are more positions, it should go to those 
positions too with eqaul steps, then wait on each position, then return those 
same positions to the start.

It all works, but due to the single thread, moving the mouse, it interferes. So 
in fact LC is to heavy for a single thread. Guess we would win speed if we got 
multi-thread. Not just for Raspberry.

Then there is still max LC7.0 for Rasp, so a port to that should also be made.

Thanks.

Jerry



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Rick Harrison via use-livecode]

Hi Jerry,

1 millisecond is probably asking too much of LC.
It doesn’t give an LC processor enough time to do 
much of anything else and I can see why just
moving the mouse would affect the speed of the
motor.  I’m assuming that what you really want
is a steady rate for the motor rather than a
variable one.

Try some experiments with increasing the amount
of time in-between motor steps if you can.  You may
find a balance somewhere that is acceptable.

I also found this comparison of Banana Pi Vs. Raspberry Pi 3
which you may also find useful.

Good luck!

Rick

Banana Pi M3 Vs Raspberry Pi 3 Benchmark

Aspects Banana Pi M3Raspberry Pi 3
Processor   ARM V7 Cortex A7ARM V8 Cortex A53
Frequency   1.8GHz  1.2GHz
CPU Cores   8   4
RAM 2GB DDR31GB DDR2
SoC A83TBCM2837
Storage Micro SD/USB SATA 2.0   Micro SD 

Onboard Storage 8GB eMMCNo
GPU PowerVR SGX544MPBroadcom VideoCore IV
GPU Speed   700MHz  400MHz
GPIO Pins   40  40
USB 2.0 2 + 1 OTG   4
Power 

  5V 2A   5V 2.5A


> On Jan 1, 2021, at 11:20 AM, JeeJeeStudio via use-livecode 
>  wrote:
> 
> Hi Rick,
> 
> thanks fo responding.
> 
> It's a Pi 3 model B+, should be fast enough for this simple task.
> 
> on clockWise
> -steps between pos and wait
>   repeat for sStp times --clockwise
>  Pi_gpio_output 20, 0 --dir
>   Pi_gpio_output 21, 1 --step
>   wait sSpd milliseconds with messages
>   Pi_gpio_output 21, 0
>   wait sSpd milliseconds with messages
> if the mouse is down
>   then
>  Pi_gpio_output 21, 0 --step
>  set the label of me to "Start"
>   exit repeat
>end if
> end repeat
> end clockWise
> 
> The time between a 1 and a 0 on the output is 1ms. I can lower the speed and 
> thus increase time, but that does not matter.
> 
> I think I tried it once with send in time, not a succes. So maybe i have to 
> rewrite that with a different mindsetting. I don't have all stack with me at 
> the moment.
> 
> The above piece is from an older stack, but the last is similar.
> 
> Also the wait shall not be the most convenient wait to handle this.
> 
> It also has of course an counterClockwise handler which is similar, but then 
> output 20 is a 1.
> 
> it should run for so many steps, then wait a few seconds and then return. If 
> there is one position. If there are more positions, it should go to those 
> positions too with eqaul steps, then wait on each position, then return those 
> same positions to the start.
> 
> It all works, but due to the single thread, moving the mouse, it interferes. 
> So in fact LC is to heavy for a single thread. Guess we would win speed if we 
> got multi-thread. Not just for Raspberry.
> 
> Then there is still max LC7.0 for Rasp, so a port to that should also be made.
> 
> Thanks.
> 
> Jerry
> 
> 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[JeeJeeStudio via use-livecode]

Thanks Bob, will try some out.

regards,

Jerry

Op 31-12-2020 om 18:22 schreef Bob Sneidar via use-livecode:

You can also try using callbacks, although the callback will not get processed 
until the next idle message (script execution termination or wait with 
messages).

Bob S


On Dec 31, 2020, at 8:53 AM, Rick Harrison via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[JeeJeeStudio via use-livecode]

Hi Rick,

thanks fo responding.

It's a Pi 3 model B+, should be fast enough for this simple task.

on clockWise
    -steps between pos and wait
  repeat for sStp times --clockwise
 Pi_gpio_output 20, 0 --dir
  Pi_gpio_output 21, 1 --step
  wait sSpd milliseconds with messages
  Pi_gpio_output 21, 0
  wait sSpd milliseconds with messages
    if the mouse is down
  then
 Pi_gpio_output 21, 0 --step
 set the label of me to "Start"
  exit repeat
   end if
    end repeat
end clockWise

The time between a 1 and a 0 on the output is 1ms. I can lower the speed 
and thus increase time, but that does not matter.


I think I tried it once with send in time, not a succes. So maybe i have 
to rewrite that with a different mindsetting. I don't have all stack 
with me at the moment.


The above piece is from an older stack, but the last is similar.

Also the wait shall not be the most convenient wait to handle this.

It also has of course an counterClockwise handler which is similar, but 
then output 20 is a 1.


it should run for so many steps, then wait a few seconds and then 
return. If there is one position. If there are more positions, it should 
go to those positions too with eqaul steps, then wait on each position, 
then return those same positions to the start.


It all works, but due to the single thread, moving the mouse, it 
interferes. So in fact LC is to heavy for a single thread. Guess we 
would win speed if we got multi-thread. Not just for Raspberry.


Then there is still max LC7.0 for Rasp, so a port to that should also be 
made.


Thanks.

Jerry

Op 31-12-2020 om 17:53 schreef Rick Harrison via use-livecode:

Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick


On Dec 31, 2020, at 7:20 AM, JeeJeeStudio via use-livecode 
 wrote:

Hi,


is it possible to assign threads in LC and why not?

In python you can assign threads, not that i needed that with python, but it is 
possible.

I'm playing with a stepper motor (for a while now) on a raspberry and with 
python it runs so smooth, with lc it's a different story.

It runs, but when moving the mouse, the motor is responding to that. This 
should not happen, but probably because LC is a bit more heavy in use and use 
only one thread for graphics and other things.

If more threads could be use then most probably it would run smooth too.


Now working with simplGui to have a GUI, which is quite easy, and now trying to 
solve that gui actions also do what needs to be done. More work, less easy than 
lc, but slowly we are getting there.

I'm not a fan of python.

Long story short, are multiple threads possible in LC and/or when will that be 
implemented?


Thanks and Happy 2021!

Jerry



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Bob Sneidar via use-livecode]

You can also try using callbacks, although the callback will not get processed 
until the next idle message (script execution termination or wait with 
messages).

Bob S


On Dec 31, 2020, at 8:53 AM, Rick Harrison via use-livecode 
mailto:use-livecode@lists.runrev.com>> wrote:

Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Threads in LC

[Rick Harrison via use-livecode]

Hi Jerry,

What version of Raspberry PI are you using?

If you are using an older version of Raspberry PI just replacing it
with a newer version might be your best work around.  The older
PI’s are pretty slow.  Have you looked into Banana PI for instance?

While LC isn’t multi-threaded there may be a work around which
could make it behave as though it was.  Have you tried Send in Time?

How often are you telling your stepper motor to run?  Once in every
10 milliseconds or once in every 20 milliseconds etc?

Good luck!

Rick

> On Dec 31, 2020, at 7:20 AM, JeeJeeStudio via use-livecode 
>  wrote:
> 
> Hi,
> 
> 
> is it possible to assign threads in LC and why not?
> 
> In python you can assign threads, not that i needed that with python, but it 
> is possible.
> 
> I'm playing with a stepper motor (for a while now) on a raspberry and with 
> python it runs so smooth, with lc it's a different story.
> 
> It runs, but when moving the mouse, the motor is responding to that. This 
> should not happen, but probably because LC is a bit more heavy in use and use 
> only one thread for graphics and other things.
> 
> If more threads could be use then most probably it would run smooth too.
> 
> 
> Now working with simplGui to have a GUI, which is quite easy, and now trying 
> to solve that gui actions also do what needs to be done. More work, less easy 
> than lc, but slowly we are getting there.
> 
> I'm not a fan of python.
> 
> Long story short, are multiple threads possible in LC and/or when will that 
> be implemented?
> 
> 
> Thanks and Happy 2021!
> 
> Jerry
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Threads in LC

[JeeJeeStudio via use-livecode]

Hi,


is it possible to assign threads in LC and why not?

In python you can assign threads, not that i needed that with python, 
but it is possible.


I'm playing with a stepper motor (for a while now) on a raspberry and 
with python it runs so smooth, with lc it's a different story.


It runs, but when moving the mouse, the motor is responding to that. 
This should not happen, but probably because LC is a bit more heavy in 
use and use only one thread for graphics and other things.


If more threads could be use then most probably it would run smooth too.


Now working with simplGui to have a GUI, which is quite easy, and now 
trying to solve that gui actions also do what needs to be done. More 
work, less easy than lc, but slowly we are getting there.


I'm not a fan of python.

Long story short, are multiple threads possible in LC and/or when will 
that be implemented?



Thanks and Happy 2021!

Jerry



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode