Re: Best Practice for Library Stacks - Found word(s) list error in the Text body
Not the way you are doing it. Only the STACK script is in the message path. Not every script of every object IN the stack! That being said, you could certainly insert the script of every card of the library stack, but that might be messy. An alternative might be to put all the handlers in the stack script, then name the handlers in such a way as they would sort in groups. All your math functions could start with calc. All your information handlers could begin with info, and so on. Now, I’m sure it’s just an example, and you aren’t really using a one line function called calcSum. Are you?? :-) Bob On Feb 13, 2014, at 03:13 , Ender Nafi Elekcioglu endern...@keehuna.com wrote: Hello, I have a library stack which consists all my common functions and commands. Calculations, text manipulation, getting device info, update procedures, etc. Stack’s script is close 5000+ line of code. I wanted to organize it and put related handlers into the script of respective cards. But it didn’t work, calling a function from my mainstack’s cards throws an error. I know that I can dispatch a function but it’s not effective. Here is an example: _main stack ___card 1 ___card 2 ___… __library stack ___card 1 ___card 2 ___… Script of card 1 of library stack: function calcSum pX, pY return pX + pY end function Script of card 2 of main stack: on answerSum answer calcSum(3, 5) end answerSum Is this possible? Can I distribute my handlers onto different cards of the library stack and still call them directly? Thanks, ~ Ender ___ 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: Best Practice for Library Stacks
Bob Sneidar-2 wrote Now, I’m sure it’s just an example, and you aren’t really using a one line function called calcSum. Are you?? :-) Bob :)) No, Bob, of course not :) It's 5062 lines of code. Following many advices in this thread; I've rearranged my code to benefit from backscripts. It's very convenient, I wonder why I didn't use it before. Now, I have an extra library card in my mainstack; no substacks. That card's buttons contain my lib scripts which are separated by their focus: - kafesNet which deals with server thingy, updates, http requests - kafesZip which extracts or creates zip's - kafesMath which has math functions, trigonometry, etc. - kafesLayout which is my own geometry manager and so on... Everything works fine; so far so good... Best, ~ Ender - _ Mac OS X 10.9.1 • LiveCode 6.5.1 xCode 5.0.1 -- View this message in context: http://runtime-revolution.278305.n4.nabble.com/Best-Practice-for-Library-Stacks-tp4675854p4676032.html Sent from the Revolution - User mailing list archive at Nabble.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: Best Practice for Library Stacks - Found word(s) check out in the Text body
What you are calling Scripts are actually Handlers. A Script is the entire chunk of code, containing 0 or more commands and/or functions, which belongs to an object. A handler is everything between and including an on/command/function statement and it’s corresponding end statement. In the past, I and others have often referred to handlers as Scripts, out of laziness I suppose, but now I try to catch myself doing it because it’s really a kind of bad habit. Bob On Feb 13, 2014, at 08:26 , Earthednet-wp proth...@earthednet.org wrote: Richard, My question was probably too elementary, but what I was really asking is: Do all of the handlers in a single button script count as a single script, or is a single handler in the button script counted as a script, for purposes of scriptLimits. If only 10 front scripts were allowed, the method wouldn't be very useful for library purposes. Bill William Prothero http://es.earthednet.org On Feb 13, 2014, at 7:46 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Earthednet-wp wrote: I like the idea of putting libraries into buttons, then copying them into the front script at startup. When you say there is a limit of some number of scripts, what counts for a script? Is a single script counted as all the handlers contained within a single button? There used to be limits; it remains to be seen if there still are, or if the Dictionary entry for scriptLimits just needs to be updated. You can check out that entry for details, but in short there were the following limits when running in a standalone, which do not apply in the IDE: 10 frontScripts 10 backScripts 50 libraries 10 executable lines in any string evaluated by do or value The latter doesn't include comments, and if a single statement is written across multiple lines with a continuation character (\) it still only counts as one line. ___ 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
Best Practice for Library Stacks
Hello, I have a library stack which consists all my common functions and commands. Calculations, text manipulation, getting device info, update procedures, etc. Stack’s script is close 5000+ line of code. I wanted to organize it and put related handlers into the script of respective cards. But it didn’t work, calling a function from my mainstack’s cards throws an error. I know that I can dispatch a function but it’s not effective. Here is an example: _main stack ___card 1 ___card 2 ___… __library stack ___card 1 ___card 2 ___… Script of card 1 of library stack: function calcSum pX, pY return pX + pY end function Script of card 2 of main stack: on answerSum answer calcSum(3, 5) end answerSum Is this possible? Can I distribute my handlers onto different cards of the library stack and still call them directly? Thanks, ~ Ender ___ 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: Best Practice for Library Stacks
Hi Ender, Stacks in use receive messages at stack level, not at card level. Use a button for each part of your library and use backscripts and frontscripts. -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Use Color Converter to convert CMYK, RGB, RAL, XYZ, H.Lab and other colour spaces. http://www.color-converter.com We have time for new software development projects. Contact me for a quote. On 13 feb 2014, at 12:13, Ender Nafi Elekcioglu wrote: Hello, I have a library stack which consists all my common functions and commands. Calculations, text manipulation, getting device info, update procedures, etc. Stack’s script is close 5000+ line of code. I wanted to organize it and put related handlers into the script of respective cards. But it didn’t work, calling a function from my mainstack’s cards throws an error. I know that I can dispatch a function but it’s not effective. Here is an example: _main stack ___card 1 ___card 2 ___… __library stack ___card 1 ___card 2 ___… Script of card 1 of library stack: function calcSum pX, pY return pX + pY end function Script of card 2 of main stack: on answerSum answer calcSum(3, 5) end answerSum Is this possible? Can I distribute my handlers onto different cards of the library stack and still call them directly? Thanks, ~ Ender ___ 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: Best Practice for Library Stacks
Mark, thanks for your quick reply. I have another question, if you don’t mind. Is there any difference, especially performance-wise, between these two approaches: 1. Library code is in the library stack’s script and it’s activated by _start using stack “libraryCode” 2. Library code is distributed to different buttons of a card of the main stack and it’s activated by _repeat with x=1 to the number of buttons of card “libraryCode” __insert the script of button x of card “libraryCode” into back _end repeat Thanks, ~ Ender From: Mark Schonewille Mark Schonewille Reply: Mark Schonewille m.schonewi...@economy-x-talk.com Date: February 13, 2014 at 13:19:32 To: How to use LiveCode use-livecode@lists.runrev.com Subject: Re: Best Practice for Library Stacks Hi Ender, Stacks in use receive messages at stack level, not at card level. Use a button for each part of your library and use backscripts and frontscripts. -- Best regards, Mark Schonewille ___ 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: Best Practice for Library Stacks
You can have more Library stacks loaded (via start using) than you can insert back scripts or front scripts. The numbers used to be 50 library stacks and 15 front and 15 back scripts. I am not sure if that has changed with recent releases. This may or may not make a difference for you depending upon how large your libraries grow and whether you want to break them up into multiple libraries Using a convention I first saw Richard Gaskin use, you can organize handlers within a script by using empty handlers as dividers. For example: on __MATH_ROUTINES__ # These are my math routines all collected together end __MATH_ROUTINES__ function calcSum pX, pY return pX + pY end function function kinetic pM, pV return 0.5 * pM * pV^2 end function on __USERINTERFACE_ROUTINES__ # These are my math routines all collected together end __USERINTERFACE_ROUTINES__ on answerSum answer calcSum(3, 5) end answerSum This provides for very visible section breaks in the list of scripts in the IDE between collections of handlers. There is of course nothing special about starting the handler names with underscore, it is really just to provide a visible difference from other handlers. ___ 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: Best Practice for Library Stacks
Paul Dupuis wrote: You can have more Library stacks loaded (via start using) than you can insert back scripts or front scripts. The numbers used to be 50 library stacks and 15 front and 15 back scripts. I am not sure if that has changed with recent releases. It seems that it has. I'd been meaning to test this since the first FOSS release with v6.0, and Ender's post prompted me to take a minute to check it out. In my test stack I was able to insert 16 scripts into the frontScripts, bringing a standalone's total to 20 frontScripts (the other four are inserted by the LC IDE at build time), and the scriptLimits show as 0,0,0 for both Community and Commercial editions. We would expect the scriptLimits to be 0,0,0 for the Community edition, since of course such a limit makes no sense with the GPL license. And given that the goal of the Commercial edition is that it's the same as the Community edition with the exception of being able to also encrypt scripts, it makes reasonable sense that the scriptLimits would be 0,0,0 there as well. However, the Dictionary entry for scriptLimits doesn't flag it as deprecated, and still notes the older limits that used to be enforced in standalones. The most recent change noted in that Dictionary entry is v2.5. So I filed a report against it, and will look forward to the team's clarification as to whether this is a functionality bug or a documentation bug: http://quality.runrev.com/show_bug.cgi?id=11797 I hope it's the latter, since with the LC IDE's insistence on adding so many of its own frontScript and backScripts, we're left with too few available slots for some complex apps that could make good use of them. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Best Practice for Library Stacks
Ender Nafi wrote: Is there any difference, especially performance-wise, between these two approaches: 1. Library code is in the library stack’s script and it’s activated by _start using stack “libraryCode” 2. Library code is distributed to different buttons of a card of the main stack and it’s activated by _repeat with x=1 to the number of buttons of card “libraryCode” __insert the script of button x of card “libraryCode” into back _end repeat I haven't measured that but I would expect any difference to be inconsequential. Access to handlers in behaviors measures slightly faster than in libraries, but this modest speed bump is possible because of their more limited scope so plan accordingly. FWIW, remember that even backscripts and libraries can use behaviors, and behavior can be chained as of v6.1, so if it helps clarify your design to think of the scripts as classes and subclasses this is now a powerful new option available to us. Using behaviors attached to backScripts may give you the greatest balance of flexibility and performance, depending on the particulars of your setup. I wouldn't recommend using behaviors solely for the speed bump, as it's only a few microseconds. But where behaviors can clarify your design, where limiting scope can be beneficial, it's great that we have them and can now nest them. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Best Practice for Library Stacks
I also am concerned with the organization of large script libraries. I like the idea of putting libraries into buttons, then copying them into the front script at startup. When you say there is a limit of some number of scripts, what counts for a script? Is a single script counted as all the handlers contained within a single button? Bill William Prothero http://es.earthednet.org On Feb 13, 2014, at 6:50 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Paul Dupuis wrote: You can have more Library stacks loaded (via start using) than you can insert back scripts or front scripts. The numbers used to be 50 library stacks and 15 front and 15 back scripts. I am not sure if that has changed with recent releases. It seems that it has. I'd been meaning to test this since the first FOSS release with v6.0, and Ender's post prompted me to take a minute to check it out. In my test stack I was able to insert 16 scripts into the frontScripts, bringing a standalone's total to 20 frontScripts (the other four are inserted by the LC IDE at build time), and the scriptLimits show as 0,0,0 for both Community and Commercial editions. We would expect the scriptLimits to be 0,0,0 for the Community edition, since of course such a limit makes no sense with the GPL license. And given that the goal of the Commercial edition is that it's the same as the Community edition with the exception of being able to also encrypt scripts, it makes reasonable sense that the scriptLimits would be 0,0,0 there as well. However, the Dictionary entry for scriptLimits doesn't flag it as deprecated, and still notes the older limits that used to be enforced in standalones. The most recent change noted in that Dictionary entry is v2.5. So I filed a report against it, and will look forward to the team's clarification as to whether this is a functionality bug or a documentation bug: http://quality.runrev.com/show_bug.cgi?id=11797 I hope it's the latter, since with the LC IDE's insistence on adding so many of its own frontScript and backScripts, we're left with too few available slots for some complex apps that could make good use of them. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Best Practice for Library Stacks
Earthednet-wp wrote: I like the idea of putting libraries into buttons, then copying them into the front script at startup. When you say there is a limit of some number of scripts, what counts for a script? Is a single script counted as all the handlers contained within a single button? There used to be limits; it remains to be seen if there still are, or if the Dictionary entry for scriptLimits just needs to be updated. You can check out that entry for details, but in short there were the following limits when running in a standalone, which do not apply in the IDE: 10 frontScripts 10 backScripts 50 libraries 10 executable lines in any string evaluated by do or value The latter doesn't include comments, and if a single statement is written across multiple lines with a continuation character (\) it still only counts as one line. These were initially added to the engine to solve what's become known in xTalk history as The Digital Chisel Problem, in which a SuperCard user once built an authoring system that directly competed with SuperCard using SuperCard itself. Ironically enough, SC won the MacEddy award for Best Multimedia Authoring Tool in 1995, and Digital Chisel won that award in '96. DC did well - at the expense of the company that provided 90% of their tool's functionality. Because of the impact DC had on SC sales, Allegiant Technologies (owners of SC at the time) negotiated an agreement with the makers of DC involving undisclosed royalty amounts in exchange for continued use of new versions of SC. Every xTalk vendor learned from that moment, and each put into place their own means of dealing with it in their EULA and in their product. MetaCard's solution (and since, LC's) was to use scriptLimits, seeking a balance between providing sufficient flexibility for most developers while reducing the likelihood of being able to make a product using MC which competes directly with MC. But now that LC is the first major xTalk to go open source, it may be that these limits are no longer relevant. LC's EULA still prohibits using LC's Commercial edition to make a product that directly competes with it, and of course the Community edition is governed by the GPL which grants all users the right to fork it however they like. We'll see what the team says in response to my bug report, but either way it's all good to me. The scriptLimits have never prevented me from shipping even complex apps, and Kevin has been very open about being willing to negotiate raising the scriptLimits for any serious developer who truly needs it; in fact, I think he did that once a few years ago for a developer making a product that relied on an unusual set of frontScripts. -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Best Practice for Library Stacks
I couldn’t decide which line to quote from Richard’s posts; You know, because of the 15kb limit of list :) In short, I’ve learned much. For my situation, using library stacks is less convenient. And the possibility of hooking chained behaviors to the backscripts seems very promising. I already started to design my library from scratch to be more scalable and flexible. By the way, Digital Chisel was an interesting story to read. Thank you all, ~ Ender ___ 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: Best Practice for Library Stacks
Richard- Thursday, February 13, 2014, 7:46:16 AM, you wrote: There used to be limits; it remains to be seen if there still are, or if the Dictionary entry for scriptLimits just needs to be updated. Last time I looked in the code, the script limits were commented out. -- -Mark Wieder ahsoftw...@gmail.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: Best Practice for Library Stacks
Richard, My question was probably too elementary, but what I was really asking is: Do all of the handlers in a single button script count as a single script, or is a single handler in the button script counted as a script, for purposes of scriptLimits. If only 10 front scripts were allowed, the method wouldn't be very useful for library purposes. Bill William Prothero http://es.earthednet.org On Feb 13, 2014, at 7:46 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Earthednet-wp wrote: I like the idea of putting libraries into buttons, then copying them into the front script at startup. When you say there is a limit of some number of scripts, what counts for a script? Is a single script counted as all the handlers contained within a single button? There used to be limits; it remains to be seen if there still are, or if the Dictionary entry for scriptLimits just needs to be updated. You can check out that entry for details, but in short there were the following limits when running in a standalone, which do not apply in the IDE: 10 frontScripts 10 backScripts 50 libraries 10 executable lines in any string evaluated by do or value The latter doesn't include comments, and if a single statement is written across multiple lines with a continuation character (\) it still only counts as one line. ___ 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: Best Practice for Library Stacks
Earthednet-wp wrote: Richard, My question was probably too elementary, but what I was really asking is: Do all of the handlers in a single button script count as a single script, or is a single handler in the button script counted as a script, for purposes of scriptLimits. There was no limit to the number of lines in a given frontScript, backScript, or library in terms of execution. But when setting an object's script, the total number of executable lines had the same limit as for do: ten executable lines, in any handler, comments and line wraps excluded. If only 10 front scripts were allowed, the method wouldn't be very useful for library purposes. It was only 10 lines of *new* code, either through do or setting an object's script. Both of those are fairly specialized cases, which is why we've not heard much of an uproar about scriptLimits in the 15+ year they were in place. Any amount of code written in a licensed development environment prior to building the standalone has always been allowed. And as Mark Wieder noted: Last time I looked in the code, the script limits were commented out ...so it looks like this is all just ancient history anyway. (Thanks for that, Mark) -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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: Best Practice for Library Stacks
Wasn't the ten lines of 'do' commands a very old demo version thing?... Designed to keep testers from do-ing too much without buying the product? And wasn't it removed long ago? Questions, questions, questions... ~Roger On Feb 13, 2014 12:11 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Earthednet-wp wrote: Richard, My question was probably too elementary, but what I was really asking is: Do all of the handlers in a single button script count as a single script, or is a single handler in the button script counted as a script, for purposes of scriptLimits. There was no limit to the number of lines in a given frontScript, backScript, or library in terms of execution. But when setting an object's script, the total number of executable lines had the same limit as for do: ten executable lines, in any handler, comments and line wraps excluded. If only 10 front scripts were allowed, the method wouldn't be very useful for library purposes. It was only 10 lines of *new* code, either through do or setting an object's script. Both of those are fairly specialized cases, which is why we've not heard much of an uproar about scriptLimits in the 15+ year they were in place. Any amount of code written in a licensed development environment prior to building the standalone has always been allowed. And as Mark Wieder noted: Last time I looked in the code, the script limits were commented out ...so it looks like this is all just ancient history anyway. (Thanks for that, Mark) -- Richard Gaskin Fourth World LiveCode training and consulting: http://www.fourthworld.com Webzine for LiveCode developers: http://www.LiveCodeJournal.com Follow me on Twitter: http://twitter.com/FourthWorldSys ___ 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
