Re: Deployment: a plea/opportunity
Thank you for speaking up, Richard. I could not agree more: deployment issues are a critical bottleneck that deserves immediate attention. Regards, Derek Bump On 10/13/23 12:46, Richard Gaskin via use-livecode wrote: We see it here in this list. We see it in the forums. We see it wherever app deployment is discussed: OS requirements for packaging/stapling/signing apps are onerous. At the edge of, and sometimes exceeding, being prohibitively so. There's no point in making a standalone if you can't ship it. If pro devs with decades of experience struggle with this, newcomers will run screaming. SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY. Pardon the all-caps. I rarely use them. But this is important. Simplifying deployment is more important than "AI". Simplifying deployment is more important than "nocode". It is the single biggest pain point. And so it is the single biggest opportunity. ___ 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: arrayToJSON on lc server
let's see: in the public repo, there's the json.lcb source: https://github.com/livecode/livecode/blob/4606a10ea10b16d5071d0f9f263ccdd7ede8b31d/extensions/libraries/json/json.lcb#L4 also, references to the "fastjson" library: https://github.com/bhall2001/fastjson On Mon, Oct 16, 2023 at 10:49 PM Mike Kerner wrote: > the externalfunctions doesn't seem to be returning anything for a project > i just opened (never tested it, before). that project has a lot of > standalone inclusions, some of which have external functions, so i don't > know if it means externals that are directly attached to the stack (like > old xcmd's/xfcn's). > grasping at straws, because i'm not deploying to lc server on linux > * i assume you manually included mergjson in your standalone (assuming > you're building your project). if not, try that. > * have you tried embedding the source from the > mergJSONLibrary.livecodescript into your main stack and then stepping > through the code? it's available in the oss repo or any of the forks of > that repo. that's just the library, not the mergjsonencode external, but it > might get you closer. > * if that doesn't work, there are at least two other oss lc json > codebases, the most popular being mark smith's, which, i think, is what > monte used when he wrote mergjson. > > On Mon, Oct 16, 2023 at 7:21 PM Neville Smythe via use-livecode < > use-livecode@lists.runrev.com> wrote: > >> I am having a problem with the function arrayToJSON on LC Server 9.6.10 >> pro (Linux host) (I couldn't get it to work on earlier versions either) >> >> I get the error >> >> Function: error in function handler (arrayToJSON) >> The mergJSON.so file is in the Externals folder, which resides in the >> same directory as livecode-server. Since revdb calls work, which I assume >> use the revdb.so library, evidently Externals are loading, and permissions >> for mergJSON.so are the same as for revdb.so. >> >> This is supposed to work out of the box, so I must be missing something >> obvious. >> >> BTW, the call "the externalFunctions of this stack" return empty - is >> that correct, should it not return the functions available in the Externals >> .so libraries? >> >> Neville Smythe >> >> >> >> >> ___ >> 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 >> > > > -- > On the first day, God created the heavens and the Earth > On the second day, God created the oceans. > On the third day, God put the animals on hold for a few hours, >and did a little diving. > And God said, "This is good." > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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: arrayToJSON on lc server
the externalfunctions doesn't seem to be returning anything for a project i just opened (never tested it, before). that project has a lot of standalone inclusions, some of which have external functions, so i don't know if it means externals that are directly attached to the stack (like old xcmd's/xfcn's). grasping at straws, because i'm not deploying to lc server on linux * i assume you manually included mergjson in your standalone (assuming you're building your project). if not, try that. * have you tried embedding the source from the mergJSONLibrary.livecodescript into your main stack and then stepping through the code? it's available in the oss repo or any of the forks of that repo. that's just the library, not the mergjsonencode external, but it might get you closer. * if that doesn't work, there are at least two other oss lc json codebases, the most popular being mark smith's, which, i think, is what monte used when he wrote mergjson. On Mon, Oct 16, 2023 at 7:21 PM Neville Smythe via use-livecode < use-livecode@lists.runrev.com> wrote: > I am having a problem with the function arrayToJSON on LC Server 9.6.10 > pro (Linux host) (I couldn't get it to work on earlier versions either) > > I get the error > > Function: error in function handler (arrayToJSON) > The mergJSON.so file is in the Externals folder, which resides in the same > directory as livecode-server. Since revdb calls work, which I assume use > the revdb.so library, evidently Externals are loading, and permissions for > mergJSON.so are the same as for revdb.so. > > This is supposed to work out of the box, so I must be missing something > obvious. > > BTW, the call "the externalFunctions of this stack" return empty - is that > correct, should it not return the functions available in the Externals .so > libraries? > > Neville Smythe > > > > > ___ > 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 > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." ___ 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: Deployment: a plea/opportunity
I’ve stopped development of my Mac app because LiveCode does not support in-app purchases (ie, allowing me to get paid) and the deployment hassle is just not worth it for an app that has no way to make money. There is NO REASON for each developer to painfully figure out how to deploy apps when LiveCode could do it for everyone. Kee Nethery > On Oct 13, 2023, at 10:52 AM, Klaus major-k via use-livecode > wrote: > > Bravo, Richard, you are so right, bravo! > >> Am 13.10.2023 um 19:46 schrieb Richard Gaskin via use-livecode >> : >> >> We see it here in this list. We see it in the forums. We see it wherever app >> deployment is discussed: >> OS requirements for packaging/stapling/signing apps are onerous. >> At the edge of, and sometimes exceeding, being prohibitively so. >> There's no point in making a standalone if you can't ship it. >> If pro devs with decades of experience struggle with this, newcomers will >> run screaming. >> SIMPLIFYING DEPLOYMENT IS THE NUMBER ONE PRIORITY. >> Pardon the all-caps. I rarely use them. But this is important. >> Simplifying deployment is more important than "AI". >> Simplifying deployment is more important than "nocode". >> It is the single biggest pain point. >> And so it is the single biggest opportunity. >> Fulfill the promise of "Everyone can code": focus on simplifying deployment. >> Step 1: Acquire Matthias' great tool. >> Step 2: Enhance it for current requirements across platforms. >> Step 3: Look for every opportunity to further simplify the process, and take >> it, at least one more simplification with each new build. >> This is important. It really is. >> -- >> And no, web export will not magically save things. Even when that becomes >> truly production-ready, it's only for web apps. Not everything needs to be >> a web app. >> There are a hundred ways to make web apps. >> There are few ways to make cross-platform native apps. >> And almost none that rival what LC can do on the desktop. >> Play into strengths. Make native deployment the best it can be. >> When that's done, only then resume work on more peripheral features. >> -- >> Richard Gaskin >> Fourth World Systems > > -- > Klaus Major > https://www.major-k.de > https://www.major-k.de/bass > kl...@major-k.de > > > ___ > 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
arrayToJSON on lc server
I am having a problem with the function arrayToJSON on LC Server 9.6.10 pro (Linux host) (I couldn't get it to work on earlier versions either) I get the error Function: error in function handler (arrayToJSON) The mergJSON.so file is in the Externals folder, which resides in the same directory as livecode-server. Since revdb calls work, which I assume use the revdb.so library, evidently Externals are loading, and permissions for mergJSON.so are the same as for revdb.so. This is supposed to work out of the box, so I must be missing something obvious. BTW, the call "the externalFunctions of this stack" return empty - is that correct, should it not return the functions available in the Externals .so libraries? Neville Smythe ___ 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: Another macOS Codesigning/Notarization issue
The uninformative error dialog is what I got when the app was corrupted but I doubt that's the problem for yours. But if code signing is the issue you usually get a different dialog with a reason. Have you tried Matthias' helper tool? Once I fixed my app it worked perfectly. You can download it from the link at the top of the lesson page, the one for Xcode 13+. t does use notarytool. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On October 15, 2023 4:01:05 PM Paul Dupuis via use-livecode wrote: Help, I am trying to switch Notarization tools for the Apple November deadline. I was using macOS Mojave with Xcode 10.2.1 and not (to use the new mandated Notary tool) have to move to Sonoma with Xcode 15.0.0. I have signed, notarized, and stapled (all responses returned were what the lessons at Livecode.com by Matthias said they should be) a Livecode 9.6.10 Standalone using my Mojave system (the old tool) and it works on Sonoma and Mojave I have signed, notarized, and stapled (all responses were as the lesson said they should be) a Livecode 9.6.10 Standalone using my Sonoma system (the new tool) and I get an error trying to run it on Sonoma. It runs under Mojave (although the first time the cursor spins a lot and it takes a while to start) The error is an extraordinary helpful dialog with a smiling macOS icon that say 'The application "" can't be opened." and an OK button. I though for a bit that it was that I was still building for Intel and the Sonoma is a M1 macBook Air, so I changed the Standalone settings and redid everything (again all seemed okay) and the GetInfo says Universal (where it said Intel before) but I get the same message. AGAIN, the old Notarization procedure produces an notarized (and stapled) app (that is actually just Intel) that runs without error on Sonoma on M1 MacBook Air and Mojave on Intel Powerbook, but the new one, from the lessons for Xcode 13+ produced the error above and my app will not run. Security is set to allow App Store and Identified Developers. Unless I figure this out, I will not be able to make new version of our macOS app after November 1. Has anyone else experienced this? Has any one see this 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 ___ 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: All Versions of LC crashing in Sonoma
Yes, that was the question I was answering. Best Regards, Heather Heather Laine Customer Services Manager LiveCode Ltd www.livecode.com > On 13 Oct 2023, at 18:58, matthias rebbe via use-livecode > wrote: > > Yes that is definitely the case. > > But Bill asked if Apple will "fix that in Sonoma" so his old standalones will > still work under Sonoma without building them again with 9.6.10 or 10.0.6. At > least that was my understanding. ;) > > > >> Am 13.10.2023 um 18:32 schrieb Bob Sneidar via use-livecode >> : >> >> Heather, just to be clear, I was under the implression that 9.6.10 and >> 10.0.6 WAS the fix for this. >> >> Bob S >> >> >> -Original Message- >> From: use-livecode On Behalf Of >> Heather Laine via use-livecode >> Sent: Friday, October 13, 2023 1:37 AM >> To: How to use LiveCode >> Cc: Heather Laine >> Subject: Re: All Versions of LC crashing in Sonoma >> >> I don't think you can hope for that. It's not a bug, its a change in the way >> they are implementing menus. >> >> Best Regards, >> >> Heather >> >> Heather Laine >> Customer Services Manager >> LiveCode Ltd >> www.livecode.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 ___ 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: Universal buttons: bugs or feature
Thanks Ralf. I quite like the look of the Universal button myself. Since its a widget, if you come up with a revision and want it tested I’d be happy try it in my current project. Best, Mark Sent from my iPhone > On Oct 15, 2023, at 10:46 PM, Ralf Bitter via use-livecode > wrote: > > Neither, it is quite simply sloppiness. Sorry for that, > will look into it. > > > Ralf > > >> On 15.10.2023 21:23, Mark Smith via use-livecode wrote: >> Are these differences in the Universal button deliberate features or bugs? >> If features, why so? > > > ___ > 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
