Re: Building a Standalone MacOS App in 9.6.1
Hi Panos, That’s just a typo correction by MacOS mail. I actually applied the sudo call as you suggested. I have not replied because as a trial I have now done a full install of Xcode 12.3 from the App Store which as usual asked me to install the additional components. I did this. Now when I build a standalone with LC it works. Whatever was missing seems to have been corrected by the Xcode install. I will not be removing Xcode now but it gives me an excuse to play with SwiftUI to see how it performs. Thanks to everyone for their suggestions. Terry > On 6 Jan 2021, at 14:30, panagiotis merakos via use-livecode > wrote: > > Hello Terry, > > Just a clarification - the correct command is: > > sudo xcode-select --install > > and not > > sudo xcode-select —install > > Hope this helps. > > Kind regards, > Panos > -- > >> > 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
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: LC & Mac M1 Chip
I know the mothership does not like to estimate release dates, but does anyone have a sense of when LC 9.6.2 STABLE may be out? And more importantly, whether it will come with 'official' support for the M1 hardware or at least a fix for this apparent M1 specific bug: https://quality.livecode.com/show_bug.cgi?id=23013 We're getting a certain amount of pressure for our primary app to support the Big Sur and the new hardware. LC9.6.2rc1 address our main Big Sur issues (not that there were many), but the dashes in menus on M1 (#23013) concerns me as we have several customer who have said they are upgrading to M1 laptops. ___ 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 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: LC & Mac M1 Chip
Paul: > we have several customer who have said > they are upgrading to M1 laptops Yes; important to support! I'm looking in that direction too. It'll be popular, plus it's what I can afford. Many people in the same boat. (Backstory: Apple's biz model forces Apple to force us to spend on hardware. The mobile herd sticks with Apple, so the dev herd does too, so wallets must open and notes must rain down. But not satisfied yet with the rain from software tweaks, so now hardware tweaks too.) I'm planning to get an M1 Mac this year, to get back on the bleeding edge for a while. It's time. My old Mac hardware is still perfectly good, it was well-built and has zero issues, but finally has been pushed into what will soon be an untenable corner by the combo of new OS to support and new chip to support. But the older Mac will continue to serve for testing and for transition dev if needed. > a sense of when LC 9.6.2 STABLE may be out? Could be roughly predicted, maybe, by looking at what they are working on. I actually agree with LC's anti release date policy; announcing firm dates is just begging for another issue to pop up. But since Apple's biz model places so much pressure on devs to keep up, a sense would be good. Especially since third-party addons and widgets also have to keep up with our ecosystem. (Another backstory: Don't forget the stable/stable linguistic play; I've seen RCs here that were actually more "stable" than the final, because glitches, regressions, and extra bugs are sometimes - perhaps often - introduced in the very process of fixing bugs. Depending on a stable to be stable is a gamble, and depending on the specific features in an app, there are times when the RC is more reliable. Nevertheless I really hate to publish anything with an RC; only when forced to do so.) BTW, Paul knows all of this very well. I'm just replying publicly in case the backstories will benefit other readers here in the process. :) Best wishes, Curry Kenworthy Custom Software Development "Better Methods, Better Results" LiveCode Training and Consulting http://livecodeconsulting.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
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
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
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
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
