Re: Musings on Architect, MVC, Nested Behaviors
Well, this stimulated a quite a discussion. @Trevor: Thank you about tips on staying organized. An very good points on how useful it could be the have nested behaviors though you have not used it yet this was an important observation :" If you use a library script you have to pass a model instance identifier to every handler in the library. Using a behavior script attached to a card could remove that need as each behavior has it's own instance of the script local variables used in the model behavior script. The approach could also simplify callbacks because the target would always be the object the model behavior is attached to." Wow... BUT: " A new developer may be more likely to see the chained behavior if the behaviors are explicitly assigned in code vs having to use vs going to the IDE to look up what the behavior chain is." That is a problem using "Navigator" (does not show nested behaviors) or the Project Browser which simply as (2)(1)(5) too obscure " if the behaviors are explicitly assigned in code" How would you do that? Currently it is obfuscated from the developer by the IDE " script "behavior_MyAudio" with behavior "behavior_ListenUI" Does not appear in the Script Editor. I consider that a "deficit" attribute of the "whole system" of nested behaviors. I put comments at the top of my "child" behavior, so that it appears the SE. //> This script has a parent behavior //> behavior_ListenUI @ Richard "Or maybe I misunderstand. Is the issue with script-only stacks, or with deeply-nested parentScript chains?" The "scary" thing about the original project, ( that Jacqueline referred to) was code,( not written by me or anyone here), that used Get and Set properties that sometimes went through four-five libraries before they "resolved themselves" to get what the calling function "wanted" and when one function call to a library would have done the same. Or to use, Jacque MO, to one huge stack script. It was not about script-only and deeply nested-parentScript chain. @ Jacqueline: I have refactored 95% of the code that drove us nuts before. Now debugging that is to 1- 3 libraries at the most. There are many libraries, but discovering "what is wrong" will take to you one or two at the most, "whew!" -- GIT has been indispensable, not only for collaboration, but the way it handles branches, being about to fetch revisions. @ Bob S. Very good and useful examples (dategrid) of how and why to use nested behaviors. I think my query was too generalized, like everything else "depends what you are trying to do" @at all -- Andre's "aagNetTracer" is the "bomb" for debugging, on the desk top and on the phone. He has "leaped frogged" far beyond the whole issue of breakpoint in code. @ y'all about revision control of binary stacks and YAML properities (front matter) for text only scripts.. cool musings! but they might want/need different threads? BR ___ 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: Musings on Architect, MVC, Nested Behaviors
Part of the reason is that it is a “script only stack” and as soon as you start adding other things it is no longer script only. If you need to store other things, then why not just use a binary stack file? Version control... use ScriptTracker (or some other method of script export that allows it). If you want to version control those other properties, then a more general solution would be warranted (like Monte’s work). I’ve briefly looked at the load/save code and think that it would be doable to extend the export code from just covering widgets to covering entire stack files. That would yield a regular array that could be exported as YAML, XML, JSON or some other format that would be Git compatible. (Only real issue is ID conflict resolution on import - my take would be to allow the developer to specify merge, replace, skip, or deconflict ID.) This solution would allow a dev to export the stack, remove the keys they don’t want saved, and create a file with these properties that can be loaded at runtime. The script itself would be left separate and the other properties would be merged. Of course this can be done now in pieces. But if import was in the engine and you didn’t need to version control the individual properties, it would be a one liner to import a LSON property file. Thanks, Brian On Dec 27, 2018, 9:53 PM -0500, Richard Gaskin via use-livecode , wrote: > J. Landman Gay wrote: > > > On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode > > wrote: > > > > > > Sounds like one more reason to allow stack properties as YAML > > > frontmatter in the file. Ever since I suggested that a couple > > > years back, the range of valuable use-cases keeps growing. > > > > I wouldn't mind if you poked them again about it. > > At your prompting I started to open an enhancement request for this, but > not long into it I hit on why they probably haven't done this yet: > > By what means would be indicate which properties we want saved there and > which ones we don't care about? > > For example, we only care about the behavior property if it's non-empty. > > Should that same rule apply to breakpoints? Would there be cases where > we wouldn't want them included? > > We probably don't want the rect saved, but what if someone does? How > would they indicate to save the rect? > > And so on for colors, and the rest. > > I'm assuming customProps should always be there, yes? Are there cases > where they shouldn't? > > Help answer these and I'll submit the request for their consideration. > > -- > 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
JIGSAW PUZZLE 2d-video v_100
JigsawPuzzle2d-video is a HTML5 standalone that demoes what LC is able to do. I have seen such "live" computed puzzle pieces until now only in specialized native apps. Images. You can choose a built-in image or import a local one into the standalone. Moreover choose the base width for the pieces and whether to rotate the pieces. The base width determines the number of pieces. If for example the image has size 480x360 then a square width of 60 yields 8x6 = 48 pieces. As a help you can be notified (the image will be inverted) whenever you are very close to the correct location. Videos. As above but without importing, use one of the nine built-in looping videos. The segmenting of the video frames is done with canvas methods in javascript. This will stress your CPU/GPU! It runs at about ten times faster in the IDE with a browser widget, but sadly this is memory-leaking (5 MBytes per second). The HTML5 standalone runs at about two times faster in Safari than Firefox or Chrome/Opera. Reduce the number of pieces if you have less than 2-3 frames per second. Technique used: The pieces are live in LC computed polygon graphics of linear and cubic bezier curves. They are filled with backpattern-images from portions of the whole imagedata. Only this last imagedata part is for the videos "outsourced" to javascript. A pure LC version of the technique used is available in "Sample stacks". This has images only but is even fast enough for the slowest Raspi. Test (and download the source and the calling HTML page (contains short but important javascripts) from (US) http://hh.on-rev.com/html5/jigsawPuzzle2d-video-9.0.2hhX.html or (EU) http://hyperhh.de/html5/jigsawPuzzle2d-video-9.0.2hhX.html ___ 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: Musings on Architect, MVC, Nested Behaviors
J. Landman Gay wrote: > On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode > wrote: >> >> Sounds like one more reason to allow stack properties as YAML >> frontmatter in the file. Ever since I suggested that a couple >> years back, the range of valuable use-cases keeps growing. > > I wouldn't mind if you poked them again about it. At your prompting I started to open an enhancement request for this, but not long into it I hit on why they probably haven't done this yet: By what means would be indicate which properties we want saved there and which ones we don't care about? For example, we only care about the behavior property if it's non-empty. Should that same rule apply to breakpoints? Would there be cases where we wouldn't want them included? We probably don't want the rect saved, but what if someone does? How would they indicate to save the rect? And so on for colors, and the rest. I'm assuming customProps should always be there, yes? Are there cases where they shouldn't? Help answer these and I'll submit the request for their consideration. -- 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: Musings on Architect, MVC, Nested Behaviors
On 12/27/18 4:13 PM, Mark Wieder via use-livecode wrote: Especially since there's already code in the engine to handle the "metadata" keyword for LCS. Er... I meant, of course, LCB. -- 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: Musings on Architect, MVC, Nested Behaviors
On 12/27/18 3:18 PM, J. Landman Gay via use-livecode wrote: On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode wrote: Sounds like one more reason to allow stack properties as YAML frontmatter in the file. Ever since I suggested that a couple years back, the range of valuable use-cases keeps growing. I wouldn't mind if you poked them again about it. Especially since there's already code in the engine to handle the "metadata" keyword for LCS. Seems like that could easily be misused^H^H^Hrepurposed to handle properties, breakpoints... -- 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: Musings on Architect, MVC, Nested Behaviors
On December 27, 2018 2:36:16 PM Richard Gaskin via use-livecode wrote: Sounds like one more reason to allow stack properties as YAML frontmatter in the file. Ever since I suggested that a couple years back, the range of valuable use-cases keeps growing. I wouldn't mind if you poked them again about it. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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: Musings on Architect, MVC, Nested Behaviors
:-) > On Dec 27, 2018, at 14:37 , J. Landman Gay via use-livecode > wrote: > > It's to keep you safe, like the TSA. And if you complain they'll make you > debug with your shoes and belt off. ___ 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: Remote Debugging (Was Re: Musings on Architect, MVC, Nested Behaviors)
I should have guessed why you wrote that. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 27, 2018 2:40:30 PM Andre Alves Garzia via use-livecode wrote: Dear Jacque, I know too well the rabbit holes that lies deep into some LC projects. As Richard have guessed, by using a ton of behaviors and libraries, you can end up with code that you can't easily trace and also which becomes quite hard to debug. As Jacque and I worked on the same project, one that is quite hard to debug on mobile, I came to realize that we needed some better tools. To solve that I made a "Network Tracer" tool to help me debug exact those apps. Think of it as a message box with more features, allowing you to not only display text and variable contents but also trace back where those texts are coming from. The network tracer work over LAN so you can have the phone and LC IDE on the same wifi network and should just work. I made a video showing it working at: https://vimeo.com/296722452 There is more information about it at my homepage at: http://andregarzia.com/livecode/ Cheers andre On 27/12/2018 18:21, J. Landman Gay via use-livecode wrote: The issue is remote debugging. Script only stacks save nothing but scripts. Breakpoints are stored as custom properties which are lost when the stack is saved as part of a standalone, so when testing a mobile app they are gone and the debugger is unavailable. I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) Another way, which I did try, is to insert a temporary red dot breakpoint into the binary stack script and then step into the handlers in the script only stack from there, but in my case that meant stepping over a few hundred lines, which was tedious, and then when I got to the handler in question, the erroring line took over and ran to the end without stopping. I'd heard that once the debugger is triggered you should be able to add new temporary breakpoints dynamically, but when I tried that after stepping into the script only stack it didn't work. This was before the fix that removed the ghosted remote scripts, so maybe it would work now. At any rate, remote debugging a script only stack isn't easy and is sometimes impossible. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 26, 2018 10:51:25 PM Richard Gaskin via use-livecode wrote: ___ 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: Musings on Architect, MVC, Nested Behaviors
It's to keep you safe, like the TSA. And if you complain they'll make you debug with your shoes and belt off. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 27, 2018 3:48:41 PM Bob Sneidar via use-livecode wrote: Wait, they made that into a law?? Can't I even just be free to screw up anymore??? So oppressive! Bob S On Dec 27, 2018, at 13:37 , Mark Wieder via use-livecode wrote: That said, it's probably good practice to remove them before shipping anyway because of the Law of Unintended Consequences. -- 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 ___ 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: Musings on Architect, MVC, Nested Behaviors
Yeah, I know breakpoints don't hurt in standalones but during active debugging you have to keep moving them around or deleting them to avoid unintended breaks. At least with red dots you can zap them all at once with a menu selection. I've had more than one brush with the law you mentioned. :) -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 27, 2018 3:40:31 PM Mark Wieder via use-livecode wrote: On 12/27/18 10:21 AM, J. Landman Gay via use-livecode wrote: I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) If you don't have remote debugging enabled then hard-coded breakpoints in a standalone app should have (almost) no effect. The mechanism in the engine that triggers breaks will fire, but if nothing is there to catch it then execution will continue as if nothing happened. That said, it's probably good practice to remove them before shipping anyway because of the Law of Unintended Consequences. -- 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 ___ 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: Musings on Architect, MVC, Nested Behaviors
Wait, they made that into a law?? Can't I even just be free to screw up anymore??? So oppressive! Bob S > On Dec 27, 2018, at 13:37 , Mark Wieder via use-livecode > wrote: > > That said, it's probably good practice to remove them before shipping anyway > because of the Law of Unintended Consequences. > > -- > 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
Map Widget
Merry Christmas and happy new year 2019 I have a problem with map widget, on android the app close, when I´ll try to create a map widget by a button create widget as "com.livecode.widget.native.map" best regards Jose Enrique Montero ___ 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: Musings on Architect, MVC, Nested Behaviors
On 12/27/18 10:21 AM, J. Landman Gay via use-livecode wrote: I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) If you don't have remote debugging enabled then hard-coded breakpoints in a standalone app should have (almost) no effect. The mechanism in the engine that triggers breaks will fire, but if nothing is there to catch it then execution will continue as if nothing happened. That said, it's probably good practice to remove them before shipping anyway because of the Law of Unintended Consequences. -- 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
Remote Debugging (Was Re: Musings on Architect, MVC, Nested Behaviors)
Dear Jacque, I know too well the rabbit holes that lies deep into some LC projects. As Richard have guessed, by using a ton of behaviors and libraries, you can end up with code that you can't easily trace and also which becomes quite hard to debug. As Jacque and I worked on the same project, one that is quite hard to debug on mobile, I came to realize that we needed some better tools. To solve that I made a "Network Tracer" tool to help me debug exact those apps. Think of it as a message box with more features, allowing you to not only display text and variable contents but also trace back where those texts are coming from. The network tracer work over LAN so you can have the phone and LC IDE on the same wifi network and should just work. I made a video showing it working at: https://vimeo.com/296722452 There is more information about it at my homepage at: http://andregarzia.com/livecode/ Cheers andre On 27/12/2018 18:21, J. Landman Gay via use-livecode wrote: The issue is remote debugging. Script only stacks save nothing but scripts. Breakpoints are stored as custom properties which are lost when the stack is saved as part of a standalone, so when testing a mobile app they are gone and the debugger is unavailable. I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) Another way, which I did try, is to insert a temporary red dot breakpoint into the binary stack script and then step into the handlers in the script only stack from there, but in my case that meant stepping over a few hundred lines, which was tedious, and then when I got to the handler in question, the erroring line took over and ran to the end without stopping. I'd heard that once the debugger is triggered you should be able to add new temporary breakpoints dynamically, but when I tried that after stepping into the script only stack it didn't work. This was before the fix that removed the ghosted remote scripts, so maybe it would work now. At any rate, remote debugging a script only stack isn't easy and is sometimes impossible. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 26, 2018 10:51:25 PM Richard Gaskin via use-livecode wrote: ___ 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: Musings on Architect, MVC, Nested Behaviors
J. Landman Gay wrote: > The issue is remote debugging. Script only stacks save nothing but > scripts. > Breakpoints are stored as custom properties which are lost when the > stack is saved as part of a standalone, so when testing a mobile app > they are gone and the debugger is unavailable. Ah, yes. Now I understand. Thank you. Sounds like one more reason to allow stack properties as YAML frontmatter in the file. Ever since I suggested that a couple years back, the range of valuable use-cases keeps growing. -- 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: Probably a No-Brainer
Wait a minute . . I think I got it: on mouseUp put 0 into m repeat 3 --(or any number) get fld "genFctn" put it&"+" after field "explFctn" replace n with m in fld "explFctn" add 1 to m end repeat delete last char of fld "explFctn" end mouseUp Roger > On Dec 27, 2018, at 11:31 AM, Roger Guay via use-livecode > wrote: > > You are so clever, Herman! Yes, the idea is to write it out into a field. > > This is great for the Taylor series, but how would one generalize this so > that we could expand any fctn of x and n in the “genFctn” field into the > “expandedFctn” field > > Sorry to take up so much of your time. > > Thanks, > > Roger > >> On Dec 27, 2018, at 11:02 AM, hh via use-livecode >> wrote: >> >> You don't want to compute it but want to write it out into a field? >> >> on mouseUp >> put taylorsum(4,"x") into fld "OUT" >> end mouseUp >> >> function taylorsum n,x -- n is the degree, x the function argument >> put "1" into s -- or: put x &"^0/0!" into s >> repeat with i=1 to n >> put " + " & x &"^"& i &"/"& i &"!" after s >> end repeat >> return char 1 to -1 of s >> end taylorsum >> >> taylorsum(4,"x") yields --> 1 + x^1/1! + x^2/2! + x^3/3! + x^4/4! >> taylorsum(4,"2") yields --> 1 + 2^1/1! + 2^2/2! + 2^3/3! + 2^4/4! >> >> >> ___ >> 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: Probably a No-Brainer
You are so clever, Herman! Yes, the idea is to write it out into a field. This is great for the Taylor series, but how would one generalize this so that we could expand any fctn of x and n in the “genFctn” field into the “expandedFctn” field Sorry to take up so much of your time. Thanks, Roger > On Dec 27, 2018, at 11:02 AM, hh via use-livecode > wrote: > > You don't want to compute it but want to write it out into a field? > > on mouseUp > put taylorsum(4,"x") into fld "OUT" > end mouseUp > > function taylorsum n,x -- n is the degree, x the function argument > put "1" into s -- or: put x &"^0/0!" into s > repeat with i=1 to n >put " + " & x &"^"& i &"/"& i &"!" after s > end repeat > return char 1 to -1 of s > end taylorsum > > taylorsum(4,"x") yields --> 1 + x^1/1! + x^2/2! + x^3/3! + x^4/4! > taylorsum(4,"2") yields --> 1 + 2^1/1! + 2^2/2! + 2^3/3! + 2^4/4! > > > ___ > 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: Probably a No-Brainer
You don't want to compute it but want to write it out into a field? on mouseUp put taylorsum(4,"x") into fld "OUT" end mouseUp function taylorsum n,x -- n is the degree, x the function argument put "1" into s -- or: put x &"^0/0!" into s repeat with i=1 to n put " + " & x &"^"& i &"/"& i &"!" after s end repeat return char 1 to -1 of s end taylorsum taylorsum(4,"x") yields --> 1 + x^1/1! + x^2/2! + x^3/3! + x^4/4! taylorsum(4,"2") yields --> 1 + 2^1/1! + 2^2/2! + 2^3/3! + 2^4/4! ___ 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: Musings on Architect, MVC, Nested Behaviors
The issue is remote debugging. Script only stacks save nothing but scripts. Breakpoints are stored as custom properties which are lost when the stack is saved as part of a standalone, so when testing a mobile app they are gone and the debugger is unavailable. I've heard you can insert hard-coded breakpoint commands in the script instead but I haven't tried that yet. (Then you need to track them down and remove them when they are no longer needed.) Another way, which I did try, is to insert a temporary red dot breakpoint into the binary stack script and then step into the handlers in the script only stack from there, but in my case that meant stepping over a few hundred lines, which was tedious, and then when I got to the handler in question, the erroring line took over and ran to the end without stopping. I'd heard that once the debugger is triggered you should be able to add new temporary breakpoints dynamically, but when I tried that after stepping into the script only stack it didn't work. This was before the fix that removed the ghosted remote scripts, so maybe it would work now. At any rate, remote debugging a script only stack isn't easy and is sometimes impossible. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com On December 26, 2018 10:51:25 PM Richard Gaskin via use-livecode wrote: J. Landman Gay jacque at hyperactivesw.com I know there is enthusiasm for script only stacks and they are really helpful for those who use git. But when git isn't a target, the old fashioned way is really much easier to follow and debug. Being script-only is just the storage format on disk. Operationally, stacks are stacks, regardless of the storage format. Or maybe I misunderstand. Is the issue with script-only stacks, or with deeply-nested parentScript chains? -- 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: Probably a No-Brainer
Thanks to Herman and Håkan but I haven’t got it yet. Consider the sum from n=0 to 2 of x^n/n!. What I want to do is expand this into the series x^0/0! + x^1/1! + x^2/2! etc. I can’t seem to wrap my head around this one!! Thanks very much, Roger > On Dec 27, 2018, at 8:25 AM, ha...@exformedia.se wrote: > > replace "x^n" with "x^" & n in field "formula" > > might do the trick… > > :-Håkan > On 27 Dec 2018, 04:34 +0100, Roger Guay via use-livecode > , wrote: >> As an example, I want to replace the contents of a field that contains x^n >> with x^1 or x^2 or x^3 as n= 1 or 2 or 3 etc. >> But I can’t seem to find find a script that works. Help please?? >> >> 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 ___ 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: Musings on Architect, MVC, Nested Behaviors
What I did to make this easier is I created a Development menu in the stack menu that I remove in standalones. Openstack builds a submenu in the Development menu for all the behavior buttons (but they could be script only stacks) so that I can click Development/Scripts/ to edit the script of any of my behaviors. Obviously this approach could be expanded to include behaviors that the IDE is presently using. Bob S > On Dec 26, 2018, at 21:31 , Trevor DeVore via use-livecode > wrote: > > See my comments above about organizing your files. If you have clearly > organized your files and you explicitly set up nested behaviors in your > code that initializes a stack when it opens, then it may be clear enough > for a new developer. A new developer may be more likely to see the chained > behavior if the behaviors are explicitly assigned in code vs having to use > vs going to the IDE to look up what the behavior chain is. ___ 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: Musings on Architect, MVC, Nested Behaviors
Precicely why I wanted to nest datagrid behaviors. This is working really well for me by the way. I have about 8 datagrids on what I call the Main Form, all running the same nested behavior inserted before the default datagrid behavior. If I need grid-specific code called from the behaviors I simply put that code in the datagrid script itself, then use dispatch, as it will not fail if it cannot find the handler (brilliant idea that). My other "form" stacks all have another nested behavior. Bob S > On Dec 26, 2018, at 21:20 , Trevor DeVore via use-livecode > wrote: > >> 3) What do you think of nested behaviors, where the "uber parent" is a >> model and the child behavior is a view/UI behavior, controller VS just >> keeping that model in libraries that remain open all the time? Goes to #2 >> above. >> > > While I've never done it that way (I have defined my model interfaces in > library stacks out of habits established prior to behaviors) there could be > value in that approach. Take a model interface that can have multiple > instances of the model. If you use a library script you have to pass a > model instance identifier to every handler in the library. Using a behavior > script attached to a card could remove that need as each behavior has it's > own instance of the script local variables used in the model behavior > script. The approach could also simplify callbacks because the target would > always be the object the model behavior is attached to. ___ 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: Probably a No-Brainer
replace "x^n" with "x^" & n in field "formula" might do the trick… :-Håkan On 27 Dec 2018, 04:34 +0100, Roger Guay via use-livecode , wrote: > As an example, I want to replace the contents of a field that contains x^n > with x^1 or x^2 or x^3 as n= 1 or 2 or 3 etc. > But I can’t seem to find find a script that works. Help please?? > > 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 ___ 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: Probably a No-Brainer
> Roger wrote: > I want to replace the contents of a field that contains x^n > with x^1 or x^2 or x^3 as n= 1 or 2 or 3 etc. You could try to write in the file "x^[[n]] + x^[[n+1]]" and then script put 2 into n put merge(fld 1) into fld 1 --> yields "x^2 + x^3" ___ 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: Websockets Problem on LiveCode
> Todd wrote: > I assume that it is a memory leaking error. Has anyone had this problem of > calling LiveCode function from a JavaScript function in the browser?? This > is a HUGE problem for us as the app cannot be shipped. Libbrowser eats on desktop up to 5 MByte of memory per second. Bug #20012. ___ 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
