Re: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)
On 2/20/20 7:34 PM, Richard Gaskin via use-livecode wrote: Thank you, Mark. Receiving the corrupted stack might be interesting, A doubtful prospect at best. Do you have a recipe I can follow for this? Absolutely no recipe. These things just sneak up on me, and by the time I can notice them I've already relaunched the IDE. That's what's most frustrating. If I had a recipe there would be something to fix. -- 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: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)
Thank you, Mark. Receiving the corrupted stack might be interesting, but what would certainly be most interesting would be to re-create that here. Do you have a recipe I can follow for this? Do you see the same behavior if plugins are disabled? -- Richard Gaskin Fourth World Systems Mark Wieder wrote: On 2/20/20 11:56 AM, Richard Gaskin via use-livecode wrote: On the forums we see a another, with surprising frequency: when the behavior of a script is not understood, the poster will sometimes surmise that the cause is somehow file format corruption. Many cases turn out to be just syntax errors, and IIRC few or none of those have turned out to be file format corruption. So here's one for you: As I've mentioned before, I don't use 9.6dpx for anything serious. I've been working with LC9.6dp2 lately to see if my stacks still work with the latest builds and I've been coming up with interesting results. At least twice now I've been editing scripts with two tabs open in the script editor. After dutifully saving my changes I close the IDE and relaunch to ensure a clean slate. I see that my stack crashes horribly because the script I was editing has been saved into the wrong object (the other script I was editing). Luckily backups saved me. I have two different corrupted stacks after editing them (one of the corrupted stacks is your 4wdevolution stack - happy to send it your way if desired). Again backups saved the day. Made the same changes to the stack and it works fine. One of my stacks that behaved properly in LC9.5.1 consistently crashed my distro's desktop manager in LC9.6dp2 (any edition), having to be restarted. I just spent two days trying to figure out if I was doing something wrong or something changed in LC itself, and it turns out to be a combination. The cef browser code has changed enough that just instantiating a browser widget is enough to cause havoc, so I now sidestep some previously-working code and hope that still works when we get dp3. Yes, I realize that these are dp releases and shouldn't be considered stable, but it's gotten to the point where I don't know whether problems I come across are bugs in my code, bugs in the latest LC build, or upcoming changes to The Way Things Work. ___ 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: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)
On 2/20/20 11:56 AM, Richard Gaskin via use-livecode wrote: On the forums we see a another, with surprising frequency: when the behavior of a script is not understood, the poster will sometimes surmise that the cause is somehow file format corruption. Many cases turn out to be just syntax errors, and IIRC few or none of those have turned out to be file format corruption. So here's one for you: As I've mentioned before, I don't use 9.6dpx for anything serious. I've been working with LC9.6dp2 lately to see if my stacks still work with the latest builds and I've been coming up with interesting results. At least twice now I've been editing scripts with two tabs open in the script editor. After dutifully saving my changes I close the IDE and relaunch to ensure a clean slate. I see that my stack crashes horribly because the script I was editing has been saved into the wrong object (the other script I was editing). Luckily backups saved me. I have two different corrupted stacks after editing them (one of the corrupted stacks is your 4wdevolution stack - happy to send it your way if desired). Again backups saved the day. Made the same changes to the stack and it works fine. One of my stacks that behaved properly in LC9.5.1 consistently crashed my distro's desktop manager in LC9.6dp2 (any edition), having to be restarted. I just spent two days trying to figure out if I was doing something wrong or something changed in LC itself, and it turns out to be a combination. The cef browser code has changed enough that just instantiating a browser widget is enough to cause havoc, so I now sidestep some previously-working code and hope that still works when we get dp3. Yes, I realize that these are dp releases and shouldn't be considered stable, but it's gotten to the point where I don't know whether problems I come across are bugs in my code, bugs in the latest LC build, or upcoming changes to The Way Things Work. -- 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: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)
Crashers are of course serious, but the good news is that you're only seeing it in one project. Feel free to email me directly if you're in a position to allow me to review the errant code, and I'll see what we can do to both find a workaround to keep your progress moving along well, and submit a report for the underlying cause once we find it. Richard. This happens all over the place, and seems to occur only after the stack has been fiddled with for a while. I cannot imagine that anything can be gleaned from the code base, which is 9000 lines of straight LC, with only a smattering of printing, printing to PDF, creating text files and reading and writing to them. In fact, none of those "outside LC" gadgets have ever caused a crash. The bugaboo is inside somewhere; I do not believe it is something I wrote. I have seen this in my other projects. They are not free of this issue. They just are not worked as hard, Can I say "bugaboo" which is not a bug, but rather something that just bugs me? I save often, and thereby save myself a lot of trouble. Craig -Original Message- From: Richard Gaskin via use-livecode To: use-livecode Cc: Richard Gaskin Sent: Thu, Feb 20, 2020 2:57 pm Subject: Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?) dunbarx wrote: > Several threads on the forum have bemoaned what is labeled an > overarching bug issue in LC. ... > I am really only concerned that LC not get a reputation for being > unstable. Most of us share that concern. To assess the issue soberly compels us to examine the nature and sources of reputation. Reputation is only partly a reflection of actual technical fitness. The rest is a mix of factors that lie far outside of computer science, into the realms of psychology, sociology, and political science. This thread is a good example: What might have seemed at first like a bug in LC turned out to be a limitation inherent in the nature of PDF itself. On the forums we see a another, with surprising frequency: when the behavior of a script is not understood, the poster will sometimes surmise that the cause is somehow file format corruption. Many cases turn out to be just syntax errors, and IIRC few or none of those have turned out to be file format corruption. We see a similar pattern with the documentation: many posts point to a need for additional information being added to the docs, with recommendations for learning basics linking to any of a wide range of resources spread out across the web, but on further examination we find that the fairly comprehensive 655-page User Guide included with the install hadn't yet been consulted at all. None of this is to suggest that LiveCode is the world's first million-line code base that's completely bug-free. But neither is it a roach motel when we consider the scope and complexity of the system with common metrics like bugs/kloc. In the vast gulf between needlessly contentious allegations of "apologists" at one extreme and "Henny Pennys" on the other is a middle ground where meaningful product improvement can actually happen: - Let questions be questions: When an unexpected outcome is observed, we can keep an open mind about possible causes until the issue is diagnosed. If we keep telling new users in advance that every unexpected outcome is a bug in LC they'll eventually believe it, even in the many cases where that isn't true. - Let learning happen right in the box: We are blessed with a great many contributions from community members all across the web. But to be clear, many of these predate the expanded documentation effort the team undertook several versions ago. Moreover, those written after LC adopted an open source workflow missed the opportunity for greater readership, keeping them in a relatively small corner of the possibly-discoverable web rather than submitting them to the core docs every user is directed to right in the Help menu. The docs are good, and can always be made even better. We can help. Of course we want to see as much LC info everywhere, but core basics might just as well be in the box, and we do a good service to the learner to let them know when they already are. - Let pre-release builds realize their value: use them, whenever practical. Putting off trying a new version until after Stable is the one choice that guarantees any issues affecting your specific work won't be fixed in that version. We know from our own experiences and decades of industry literature that the earlier in the process bugs are identified, the less impact they have, and thus the total systemic cost to address them is much lower. These are just suggestions, and certainly not any attempt at establishing any sort of "rules". I have no authority to require anyone to do anything, nor would I even try, as I understand that from time to time t
Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)
dunbarx wrote: > Several threads on the forum have bemoaned what is labeled an > overarching bug issue in LC. ... > I am really only concerned that LC not get a reputation for being > unstable. Most of us share that concern. To assess the issue soberly compels us to examine the nature and sources of reputation. Reputation is only partly a reflection of actual technical fitness. The rest is a mix of factors that lie far outside of computer science, into the realms of psychology, sociology, and political science. This thread is a good example: What might have seemed at first like a bug in LC turned out to be a limitation inherent in the nature of PDF itself. On the forums we see a another, with surprising frequency: when the behavior of a script is not understood, the poster will sometimes surmise that the cause is somehow file format corruption. Many cases turn out to be just syntax errors, and IIRC few or none of those have turned out to be file format corruption. We see a similar pattern with the documentation: many posts point to a need for additional information being added to the docs, with recommendations for learning basics linking to any of a wide range of resources spread out across the web, but on further examination we find that the fairly comprehensive 655-page User Guide included with the install hadn't yet been consulted at all. None of this is to suggest that LiveCode is the world's first million-line code base that's completely bug-free. But neither is it a roach motel when we consider the scope and complexity of the system with common metrics like bugs/kloc. In the vast gulf between needlessly contentious allegations of "apologists" at one extreme and "Henny Pennys" on the other is a middle ground where meaningful product improvement can actually happen: - Let questions be questions: When an unexpected outcome is observed, we can keep an open mind about possible causes until the issue is diagnosed. If we keep telling new users in advance that every unexpected outcome is a bug in LC they'll eventually believe it, even in the many cases where that isn't true. - Let learning happen right in the box: We are blessed with a great many contributions from community members all across the web. But to be clear, many of these predate the expanded documentation effort the team undertook several versions ago. Moreover, those written after LC adopted an open source workflow missed the opportunity for greater readership, keeping them in a relatively small corner of the possibly-discoverable web rather than submitting them to the core docs every user is directed to right in the Help menu. The docs are good, and can always be made even better. We can help. Of course we want to see as much LC info everywhere, but core basics might just as well be in the box, and we do a good service to the learner to let them know when they already are. - Let pre-release builds realize their value: use them, whenever practical. Putting off trying a new version until after Stable is the one choice that guarantees any issues affecting your specific work won't be fixed in that version. We know from our own experiences and decades of industry literature that the earlier in the process bugs are identified, the less impact they have, and thus the total systemic cost to address them is much lower. These are just suggestions, and certainly not any attempt at establishing any sort of "rules". I have no authority to require anyone to do anything, nor would I even try, as I understand that from time to time there can be good reason to ignore each of these, and any other common practices observable in healthy software communities. But most of us have been around the block enough times to recognize the value of such ordinary practices. And all of us want LC to improve - both in terms of actual product quality, and its *perceived* quality, its reputation. LiveCode is moving its way up the TIOBE Index of programming language popularity, slowly but steadily. For all the reasons Geoff Moore outlined in Crossing the Chasm and many more, expanding LC's audience benefits all of us: more tools, more libraries, more eyeballs, more hands. There isn't a single language on the TIOBE Index that's bug-free, and yes, that includes LiveCode. We the community have at least as much power and influence over LiveCode adoption as anything the core team can do, by virtue of our numbers and reach. With any programming tool, the number of end-users who ultimately benefit is orders of magnitude larger than the number of developers using it. Let's produce great work, and build upon those practices proven across the industry to expand both real and perceived quality. Along those lines, I'll extend an offer here: > For my part, I only notice that LC 9x crashes intermittently, though > regularly. I must add that I am working mainly on a single project >
