Re: How to set up a library?
Ben: > What is the best way to structure a library these days? Flashback to an interesting conversation, when LiveCode Ltd (or RunRev Ltd) asked me, "what is a library?" Not kidding; real question. It's like Newton Ltd asking you, "what is gravity?" That opened my eyes to how libraries have been underappreciated and underpromoted at times, even at the very top of the LC community. So I'm happy to see a thread about libraries. Thanks for starting it. Best way is most efficient way. What's most efficient depends on your current or desired workflow. > Currently I've got buttons with a script, and a 'mouseup' handler > to 'insert the script of me into back' in my object library. > But I don't think that's very modern. Neither way is extremely modern. But modern shouldn't be the overriding criterion for judging good design. Very true that good design is often modern, but conflating the two would be missing the point. Start using, insert script into - both introduced in 1.0, if the dictionary serves. There's nothing less modern about insert. Yet I've always preferred "start using." It suits my own style of organizing code (stacks or substacks) and loading it into memory. Not necessarily better; again depends on YOUR workflow and overall organization methods. And where you need the code in the message path. I've seen great button script inserts. (Although plenty of bad ones. Especially when inserting into front, it's a must to make sure the inserted code is pretty darn good.) And I've seen terrible code with start using! It's possible to really do it badly. But I'm biased in favor of start using for most work. > What's the right way to do it? Especially if I want to share it? So it's kind of a Ford/Chevy or AK/AR question. Used well, either will do. Either way, make sure initialization happens only once, don't tread on the user and seize control, try to anticipate how different users work in LiveCode and structure their scripts, etc. Don't duplicate code. And get a testing partner; he or she is a force multiplier. But if modern IS to be the overriding criterion - peer pressure/trends/fads - I'd say cool kids better use git, script-only stacks, AND also plenty of behaviors which were introduced much later than libraries themselves. All together. And don't forget to make it a MVP. Otherwise behind the times, not kewl fewl. :) Good topic. 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: How to set up a library?
On 31/12/2020 17:12, Bob Sneidar via use-livecode wrote: Setting the behavior of something is a one time thing. Start Using is something that has to be done every time a stack is opened, unless another stack in the IDE has done so. Doing it more than once has no effect, other than pushing the script to the back of the stacks in use. um - not 100% "no effect". If you have a 'librarystack' handler it will be run each time you 'start using' the stack, and therefore if it does something without checking for having been already run, you can get unexpected effects. (For example, if your librarystack handler was to explicitly set some variable to empty then that would overwrite (i.e. lose) any value set since the previous occurrence. Like others have said, I use a folder (I call it Libraries) with the 'My Livecode' folder to hold all my libraries (and I make sure they can be 'start using'ed multiple times. If I have a library which depends on other libraries, I give it a librarystack handler which (among other things) will 'start using' any libraries it requires. 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: LC & Mac M1 Chip
I figured it was good, but thanks for letting us know. Marty >>> On Dec 30, 2020, at 7:07 PM, Roger Guay via use-livecode >>> wrote: >>> >>> Yes, I just tried it and it works fine! I’m happy to try yours out if you >>> wish?? >>> >>> Roger ___ 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: How to set up a library?
I actually have a folder that I created called "myLibraries". You just need to put that folder into the path so that your application can see it. Sincerely, Clarence Martin Email: chi...@themartinz.com Phone: 626 6965561 -Original Message- From: use-livecode On Behalf Of Ben Rubinstein via use-livecode Sent: Thursday, December 31, 2020 10:19 AM To: use-livecode@lists.runrev.com Cc: Ben Rubinstein Subject: Re: How to set up a library? Thanks for responding Bob. Apologies for the confusion, I wasn't suggesting adding it in the actual application bundle; I was wondering whether there is a corresponding location in what used to be the "My LiveCode" folder in Documents. I.e. in that folder on my machine I see subfolders Extensions Externals Plugins Projects Resources Runtime and I wondered whether any of those had some blessed quality which would allow library stacks stored there to be loaded more easily than 'ordinary' stacks. Ben On 31/12/2020 17:12, Bob Sneidar via use-livecode wrote: > Trouble with putting a library in the Livecode libraries folder is every time > you upgrade Livecode, those may get deleted. This is especially true for OS > X, where those libraries are in the app bundle. I would not put a library in > that location. > > Also, you do not have to specify the path. Add the library to the Stack Files > of the stack, and then start using it by the stack short name. If you are > using a script only stack, you should also add the SOS to the stack files, > mainly because when you create a standalone these will get included in the > standalone. Otherwise I suppose you *could* start using a stack by full path > name or else it has to be in the current default folder. > > Setting the behavior of something is a one time thing. Start Using is > something that has to be done every time a stack is opened, unless another > stack in the IDE has done so. Doing it more than once has no effect, other > than pushing the script to the back of the stacks in use. > > The difference between the two is that a behavior is in the message path of > the object itself, and so it’s handlers are not accessible to any other > object unless you send or dispatch to that object. > > Start Using makes the script globally accessible to ALL stacks running in the > IDE (or in the Standalone). > > On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode > mailto:use-livecode@lists.runrev.com>> wrote: > > Thanks Alex and Bob for your responses. > > And if I make it a script-only stack, is there a clever place to store > it - e.g. the standard distribution libraries are in > .../Tools/Toolset/libraries/ > > Is there a convention or location which would allow me to reference the > library without having to specify the full path, for example? > > thanks, > > Ben > > ___ > 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: How to set up a library?
Thanks for responding Bob. Apologies for the confusion, I wasn't suggesting adding it in the actual application bundle; I was wondering whether there is a corresponding location in what used to be the "My LiveCode" folder in Documents. I.e. in that folder on my machine I see subfolders Extensions Externals Plugins Projects Resources Runtime and I wondered whether any of those had some blessed quality which would allow library stacks stored there to be loaded more easily than 'ordinary' stacks. Ben On 31/12/2020 17:12, Bob Sneidar via use-livecode wrote: Trouble with putting a library in the Livecode libraries folder is every time you upgrade Livecode, those may get deleted. This is especially true for OS X, where those libraries are in the app bundle. I would not put a library in that location. Also, you do not have to specify the path. Add the library to the Stack Files of the stack, and then start using it by the stack short name. If you are using a script only stack, you should also add the SOS to the stack files, mainly because when you create a standalone these will get included in the standalone. Otherwise I suppose you *could* start using a stack by full path name or else it has to be in the current default folder. Setting the behavior of something is a one time thing. Start Using is something that has to be done every time a stack is opened, unless another stack in the IDE has done so. Doing it more than once has no effect, other than pushing the script to the back of the stacks in use. The difference between the two is that a behavior is in the message path of the object itself, and so it’s handlers are not accessible to any other object unless you send or dispatch to that object. Start Using makes the script globally accessible to ALL stacks running in the IDE (or in the Standalone). On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Thanks Alex and Bob for your responses. And if I make it a script-only stack, is there a clever place to store it - e.g. the standard distribution libraries are in .../Tools/Toolset/libraries/ Is there a convention or location which would allow me to reference the library without having to specify the full path, for example? thanks, Ben ___ 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: Server error? SOLVED
Yup. I said try replacing the older library with the newer one. You would have had to do that in the standalone. I didn’t know there were two versions, but it seemed obvious there must have been. Bob S On Dec 31, 2020, at 9:15 AM, Klaus major-k via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Hi Bob, Am 31.12.2020 um 18:01 schrieb Bob Sneidar via use-livecode mailto:use-livecode@lists.runrev.com>>: Hey, what I said! :-) oh, really? Sorry must have missed that. :-( Anyway, a happy (and better) new year, everybody! 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
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: How to set up a library?
BTW you may want to consider inserting anything with a mouseUp handler in the front, if you want every mouseUp to be trapped. If you only want the library’s mouseUp to be triggered “on demand” then insert into back and then pass mouseUp to trigger your library handler (assuming mouseUp is not trapped anywhere else in the message path.) For example, I have a mouseDown handler in a front script, where I then get the target and determine what kind of object it is, handling the objects I want (usually for contextual menus) and then passing at the end. Bob S On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Currently I've got buttons with a script, and a 'mouseup' handler to 'insert the script of me into back' in my object library. But I don't think that's very modern. ___ 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: Server error? SOLVED
Hi Bob, > Am 31.12.2020 um 18:01 schrieb Bob Sneidar via use-livecode > : > > Hey, what I said! :-) oh, really? Sorry must have missed that. :-( Anyway, a happy (and better) new year, everybody! > Bob S > > On Dec 31, 2020, at 3:08 AM, Klaus major-k via use-livecode > mailto:use-livecode@lists.runrev.com>> wrote: > Hi all, > we could finally solve the problem by copying the revsecurity.dll from > LC 9 to the LC 5.x runtime folder! 8-) > ... Best Klaus -- Klaus Major https://www.major-k.de 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
Re: How to set up a library?
Trouble with putting a library in the Livecode libraries folder is every time you upgrade Livecode, those may get deleted. This is especially true for OS X, where those libraries are in the app bundle. I would not put a library in that location. Also, you do not have to specify the path. Add the library to the Stack Files of the stack, and then start using it by the stack short name. If you are using a script only stack, you should also add the SOS to the stack files, mainly because when you create a standalone these will get included in the standalone. Otherwise I suppose you *could* start using a stack by full path name or else it has to be in the current default folder. Setting the behavior of something is a one time thing. Start Using is something that has to be done every time a stack is opened, unless another stack in the IDE has done so. Doing it more than once has no effect, other than pushing the script to the back of the stacks in use. The difference between the two is that a behavior is in the message path of the object itself, and so it’s handlers are not accessible to any other object unless you send or dispatch to that object. Start Using makes the script globally accessible to ALL stacks running in the IDE (or in the Standalone). On Dec 31, 2020, at 3:55 AM, Ben Rubinstein via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Thanks Alex and Bob for your responses. And if I make it a script-only stack, is there a clever place to store it - e.g. the standard distribution libraries are in .../Tools/Toolset/libraries/ Is there a convention or location which would allow me to reference the library without having to specify the full path, for example? thanks, Ben ___ 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: Server error? SOLVED
Hey, what I said! :-) Bob S On Dec 31, 2020, at 3:08 AM, Klaus major-k via use-livecode mailto:use-livecode@lists.runrev.com>> wrote: Hi all, we could finally solve the problem by copying the revsecurity.dll from LC 9 to the LC 5.x runtime folder! 8-) I really had no idea that they were compatible!? Nevertheless I will write to the mothership next week, just to get to know why everythings works fine in the IDE but not in a runtime. ___ 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
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
Re: LC & Mac M1 Chip
On 12/31/2020 8:22 AM, John Balgenorth via use-livecode wrote: I thought the Mac M1 Chip has Rosetta or something like that allowing most 64 bit programs to still run so I was thinking any 64 bit version of LC would still work. You can search the Livecode Quality center for Big Sur bugs. As I recall the 3 main ones were: 1) A bug with custom window shapes (not an issue if you do not use any custom window shapes) 2) A bug with the highlights on tabbed buttons (not an issue if you do not use tabbed buttons - also there was a script work-around available) 3) An issue with dialogs displayed "as sheet" These bugs are resent under Big Sur (regardless of whether you are on the M1 chip or Intel) in LC 9.6.1 and are fixed in 9.6.2rc1 Again, search the https://quality.livecode.com/ for "big sur" for details JB On Dec 31, 2020, at 5:15 AM, Paul Dupuis via use-livecode wrote: You need to be on macOS Big Sur for the new hardware (I think). There are bugs in LC vs Big Sur that are only fixed in LC 9.6.2rc1 so you probably want to rebuild any Standalones using that version of LC On 12/30/2020 10:29 PM, John Balgenorth via use-livecode wrote: Should any LC standalone work with the Mac M1 Chip if it was working on Mojave and above? JB On Dec 30, 2020, at 7:07 PM, Roger Guay via use-livecode wrote: Yes, I just tried it and it works fine! I’m happy to try yours out if you wish?? Roger On Dec 30, 2020, at 2:47 PM, Marty Knapp via use-livecode wrote: Has anyone tried an LC standalone on one of the new Macs with the M1 chip? I have customers asking and I don’t want to go buy one just to find out! Thanks, Marty ___ 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 ___ 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: LC & Mac M1 Chip
I thought the Mac M1 Chip has Rosetta or something like that allowing most 64 bit programs to still run so I was thinking any 64 bit version of LC would still work. JB > On Dec 31, 2020, at 5:15 AM, Paul Dupuis via use-livecode > wrote: > > You need to be on macOS Big Sur for the new hardware (I think). > > There are bugs in LC vs Big Sur that are only fixed in LC 9.6.2rc1 so you > probably want to rebuild any Standalones using that version of LC > > >> On 12/30/2020 10:29 PM, John Balgenorth via use-livecode wrote: >> Should any LC standalone work with the Mac M1 Chip >> if it was working on Mojave and above? >> >> JB >> >> On Dec 30, 2020, at 7:07 PM, Roger Guay via use-livecode wrote: >>> >>> Yes, I just tried it and it works fine! I’m happy to try yours out if you >>> wish?? >>> >>> Roger >>> >>> On Dec 30, 2020, at 2:47 PM, Marty Knapp via use-livecode wrote: Has anyone tried an LC standalone on one of the new Macs with the M1 chip? I have customers asking and I don’t want to go buy one just to find out! Thanks, Marty ___ 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 > > > ___ > 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: LC & Mac M1 Chip
You need to be on macOS Big Sur for the new hardware (I think). There are bugs in LC vs Big Sur that are only fixed in LC 9.6.2rc1 so you probably want to rebuild any Standalones using that version of LC On 12/30/2020 10:29 PM, John Balgenorth via use-livecode wrote: Should any LC standalone work with the Mac M1 Chip if it was working on Mojave and above? JB On Dec 30, 2020, at 7:07 PM, Roger Guay via use-livecode wrote: Yes, I just tried it and it works fine! I’m happy to try yours out if you wish?? Roger On Dec 30, 2020, at 2:47 PM, Marty Knapp via use-livecode wrote: Has anyone tried an LC standalone on one of the new Macs with the M1 chip? I have customers asking and I don’t want to go buy one just to find out! Thanks, Marty ___ 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 ___ 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
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
Re: How to set up a library?
Thanks Alex and Bob for your responses. And if I make it a script-only stack, is there a clever place to store it - e.g. the standard distribution libraries are in .../Tools/Toolset/libraries/ Is there a convention or location which would allow me to reference the library without having to specify the full path, for example? thanks, Ben On 29/12/2020 23:40, Alex Tweedly via use-livecode wrote: I'd make it a script-only stack, and then start using stack "..." (probably in an openstack handler - but could be anywhere you like for your own use). By far the easiest to share (and for others to accept when shared). Alex. P.S. And, should this library be useful in LCServer context, it means you can upload the stack to the server without getting annoying error messages about mixed line endings which Coda-2 and some others give on binary stacks). On 29/12/2020 19:34, Ben Rubinstein via use-livecode wrote: What is the best way to structure a library these days? Currently I've got buttons with a script, and a 'mouseup' handler to 'insert the script of me into back' in my object library. But I don't think that's very modern. What's the right way to do it? Especially if I want to share it? TIA, Ben ___ 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: Server error? SOLVED
Hi Mark, > Am 31.12.2020 um 12:30 schrieb Mark Waddingham via use-livecode > : > > On 2020-12-31 11:08, Klaus major-k via use-livecode wrote: >> Hi all, >> we could finally solve the problem by copying the revsecurity.dll from >> LC 9 to the LC 5.x runtime folder! 8-) >> I really had no idea that they were compatible!? >> Nevertheless I will write to the mothership next week, just to get to >> know why everythings works fine in the IDE but not in a runtime. > > The IDE loads different DLLs from those it includes in standalones. So there > is a revsecurity.dll (near/next to) the IDE engine on Windows, and also one > in the Runtime/Windows... folder. The latter is copied into standalones, the > former is only used by the IDE. OK, so there ARE in fact two different versions. > It suggests that you have previously copied a newer DLL over the one near the > IDE engine - so it works in the IDE... > Then when you copied the same DLL into the runtime folder, it then works in > standalones too. I cannot speak for my customer, but maybe that is the case with him. However I have a "stock" Mac installation of LC 5.02 on my Mac, which I did NOT alter in any way. But here the same thing happened, it worked in the IDE, but not in the runtime!? And on the Mac there is even not revsecurity.dll, I think this functionality is in the engine. > The DLLs from newer versions aren't guaranteed to be compatible with older > versions - in the specific case of revsecurity it depends on whether OpenSSL > has changed its API in a way which causes an incompatibility but it hasn't > done this very often (fortunately in this case, it would seem!). Yo! :-) > Warmest Regards, > > Mark. Thanks for the explanation! Best Klaus -- Klaus Major https://www.major-k.de 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
Re: Server error? SOLVED
On 2020-12-31 11:08, Klaus major-k via use-livecode wrote: Hi all, we could finally solve the problem by copying the revsecurity.dll from LC 9 to the LC 5.x runtime folder! 8-) I really had no idea that they were compatible!? Nevertheless I will write to the mothership next week, just to get to know why everythings works fine in the IDE but not in a runtime. The IDE loads different DLLs from those it includes in standalones. So there is a revsecurity.dll (near/next to) the IDE engine on Windows, and also one in the Runtime/Windows... folder. The latter is copied into standalones, the former is only used by the IDE. It suggests that you have previously copied a newer DLL over the one near the IDE engine - so it works in the IDE... Then when you copied the same DLL into the runtime folder, it then works in standalones too. The DLLs from newer versions aren't guaranteed to be compatible with older versions - in the specific case of revsecurity it depends on whether OpenSSL has changed its API in a way which causes an incompatibility but it hasn't done this very often (fortunately in this case, it would seem!). Warmest Regards, Mark. -- Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ LiveCode: Everyone can create apps ___ 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: Server error? SOLVED
Hi all, we could finally solve the problem by copying the revsecurity.dll from LC 9 to the LC 5.x runtime folder! 8-) I really had no idea that they were compatible!? Nevertheless I will write to the mothership next week, just to get to know why everythings works fine in the IDE but not in a runtime. > Am 30.12.2020 um 16:09 schrieb Klaus major-k : > > Hi all, > > I am currently working on a stack in LC 5.x for a customer. > This stack only loads another stack from a server and displays it. > > Works fine in the IDE, but I get this error when trying this in the > standalone, alle externals etc. are in fact present. > The error reads: > -- > Cannot connect > error error:1407742E:SSL > routines:SSL23_GET_SERVER_HELLO:tlsv1 > alert protocol version > --- > Maybe this is a mismatch between the SSL version on the server > and the SSL version in LC5.x? > But then it should also not work in the IDE!? This is very strange. > Any insights and workarounds, if any, are very welcome, thanks! Best Klaus -- Klaus Major https://www.major-k.de 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
Re: Livecode Builder - passing lcs string to C functions
Thanks so much for this Trevor, I can now retrieve requests from and respond to a virtual threaded http server which is nice. Now trying to work out how not to block the engine when the function that calls the server waits for a new request to come in i..e callback functions purely within lcb Dan On Mon, Dec 28, 2020 at 10:09 PM Trevor DeVore via use-livecode < use-livecode@lists.runrev.com> wrote: > On Mon, Dec 28, 2020 at 7:02 AM Dan Brown via use-livecode < > use-livecode@lists.runrev.com> wrote: > > > Hi I'm stuck trying to find examples of passing lcs strings to a C > function > > via pointer and it's driving me mad! I can retrieve char * pointers from > C > > functions, convert to string and pass back to lcs but haven't come across > > any easy to grok examples of sending data to C. Any guidance would be > > appreciated > > > I've used MCStringConvertToBytes to convert strings to a value you can pass > in as const char*. I have a hunspell example you can reference. > > Here is a link to the Hunspell_spell definition: > > > https://github.com/hunspell/hunspell/blob/8a2fdfe5a6bb1cbafc04b0c8486abcefd17ad903/src/hunspell/hunspell.h#L69 > > ``` > LIBHUNSPELL_DLL_EXPORTED int Hunspell_spell(Hunhandle* pHunspell, const > char*); > ``` > > Here is a link to the LCB code that passes a UTF8 string to Hunspell_spell: > > https://github.com/trevordevore/lc-hunspell/blob/master/hunspell.lcb#L150 > > Here is a link to the MCStringConvertToBytes definition in the LCB file: > > https://github.com/trevordevore/lc-hunspell/blob/master/hunspell.lcb#L19 > > -- > Trevor DeVore > ScreenSteps > www.screensteps.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: Server error?
Hi Bob, > Am 31.12.2020 um 01:53 schrieb Bob Sneidar via use-livecode > : > > Just a shot in the dark, when you are working in the IDE, do you have a newer > version of Livecode running? no. > Bob S > ... > Am 30.12.2020 um 23:59 schrieb Bob Sneidar via use-livecode > mailto:use-livecode@lists.runrev.com>>: > > TLSv1 is dead. It uses the OpenSSL library that had the Heartbleed > vulnerability. Not sure if v5 libraries can use the latest encryption > libraries. I don’t know why not. > > the big question is: Why does it work in the IDE, but not in a runtime made > with the same IDE? > Seems that the IDE and the runtime use different "revSecurity.dll"s?! Best Klaus -- Klaus Major https://www.major-k.de 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
