Re: hair-pulling frustration
On 13 Nov 2014, at 20:09, J. Landman Gay jac...@hyperactivesw.com wrote: On 11/13/2014, 2:27 AM, Mark Schonewille wrote: Really, why wouldn't it be realistic to pay a bunch of students for a few hours of beta-testing (or should I say alpha-testing) some time in a development cycle? There's no way a few hours would catch much in a system as complex and large as LiveCode. It wouldn't make a dent. Whenever I sit down with LC, I find several problems/bugs/unwanted behaviours. Usually, after filing one or two bug reports, I stop using LC, because it's just too annoying to run into problems so often, and not being able to concentrate on my own tasks. -- Use an alternative Dictionary viewer: http://bjoernke.com/bvgdocu/ Chat with other RunRev developers: http://bjoernke.com/chatrev/ ___ 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: hair-pulling frustration
Hi Ralph, Thanks for your fantastic suggestion! I've had a quick chat with our testing master, Hanson, and he is more than happy to look at into integrating any advance query stacks you may have into our current test system. If you do get a chance to create any of these, please fire them over to supp...@livecode.com and we will then forward them onto Hanson. We're also in the process of integrating a system that allows the community to submit tests with any reports they create. This means that they should be automatically included during any internal testing we do. Kind Regards, Neil Roger -- LiveCode Support Team ~ http://www.livecode.com -- On 13/11/2014 21:14, Ralph DiMola wrote: Neil, With user input and Richard's moderating this thread has started to bear some fruit. After writing HW diagnostics for years I know how challenging is to come with thorough testing scenarios. I don't know what your QC process for databases is but might I suggest using challenging queries. I would be happy to set up a stack to test them along with the DBs. For example: SELECT Table1.*, Table2.*,Table3.* FROM Table1 LEFT JOIN Table2 ON Table1.Designation = Table2.Designation LEFT JOIN Table3 ON Table1.State = Table3.State AND Table1.County = Table3.County WHERE (Table3.Region = 'Foo') or ATTACH DATABASE Table3.db AS Table3DB SELECT Table3.*,Table1.* from Table3DB.Table3 JOIN Table1 ON Table3.CourseID = Table1.CourseID JOIN Table2 ON Table2.County = Table1.County AND Table2.State = Table1.State WHERE (Table3.Favorite or Table3.frog '') Mr. Haworth and all you other DB gurus out there, what other testing scenarios do think should be included in the RR DB QC process? The way I look at it the more we help RR the more we help ourselves. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Neil Roger Sent: Thursday, November 13, 2014 2:59 PM To: How to use LiveCode Subject: Re: hair-pulling frustration Hi Richard, I've attempted to replicate the semicolon issue without any success. This could be why we have not come accross it during testing in-house. The script that I tested with is- global gConnectionID on mouseUp global gConnectionID if gConnectionID is not a number then answer error Please connect to the database first. exit to top end if put Table1 into tTableName put SELECT * FROM tTableName into tSQL put revDataFromQuery(,,gConnectionID,SELECT * FROM Table1;) into tData if item 1 of tData = revdberr then answer error There was a problem querying the database: cr tData else put tData into field Data end if end mouseUp Both the inclusion and exclusion of the semi-colon return data as expected. If possible, could you supply a stack for me to test with and I will happily look into this further. Kind Regards, Neil 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: hair-pulling frustration
OK, so you mean this: revDataFromQuery(,,17,SELECT * FROM vader_darth__001_dna;) revDataFromQuery is a function, you need to either put it or get it or set a cprop to it. If I type the above statement into the message box I get exactly the same error as you whether there's a semicolon or not. If I add put before it, everything works with or without the semicolon.. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Thu, Nov 13, 2014 at 5:28 PM, Dr. Hawkins doch...@gmail.com wrote: On Thu, Nov 13, 2014 at 4:32 PM, Peter Haworth p...@lcsql.com wrote: I just tried it under 7.0 and same result - no problems with or without the semicolon. There must be something else going on in Dr Hawkins code. The ones I posted today were typed into the message box! -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
The way I see things, RunRev is not an overly large company. To remain solvent (something that benefits us all) they probably have to prioritize what they can and cannot do. In House testing of every possible scenario cannot be one of the do’s. Frankly I am thrilled at the progress made since version 2.0. I can live with a few bugs. After all, no one *has* to adopt a new version of LC! If your older version works, use it for production. If the newer version causes you problems, don’t. And file a bug report while you are at it. Now if RunRev were as large as Microsoft, then I could see holding them accountable for every serious bug in their product. I’m not seeing the major issue here. I think a few more pats on the back of these guys might do more to help them excel then criticisms. After all, they are likely just as much raving egomaniacs (as Richmond put it) as most of us are. :-) Bob S On Nov 13, 2014, at 14:24 , Alex Tweedly a...@tweedly.net wrote: Note to self : I am *not* getting involved in this thread. I am *not* getting involved in this thread. I am *not* getting involved in this thread. I am *not* getting involved in this thread. I do *not* have time to read, never mind get involved in, this thread. :-) OK. Having said that to myself - one small suggestion. It would seem touchy-feely for there to be more response on this list from RR. You (Richard) are doing a great job as Community Manager, and responding here. How about you get an email address like rich...@runrev.com so that it does feel more like a RR response :-) I suspect this list is mostly us old dinosaurs, and most of the newer users are on the forums, and *we* should all know who you are - but it would maybe help remind us that you have a role within RR and are effectively part of the RR team taking in our input. Regards, -- Alex. On 13/11/2014 22:11, Richard Gaskin wrote: Richmond wrote: What might do some good is point out to RunRev that when they released their Open Source version of LiveCode they undertook to be more touchy-feely and more responsive to their users . . . and, just possibly, they may be falling short of this. Perhaps. What should touchy-feely ideally translate to in terms of specific actions? ___ 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: hair-pulling frustration
On Fri, Nov 14, 2014 at 9:21 AM, Peter Haworth p...@lcsql.com wrote: revDataFromQuery(,,17,SELECT * FROM vader_darth__001_dna;) Somehow, an earlier version of my reply was sent. Here's what I meant to send. Knowing that you used the message box makes a big difference, Everyone who has checked this out used a script. I was surprised your statement worked at all in the message box since revDataFromQuery is a function and seems like it should need a put or get or set, so I tried various LC versions, with/without semicolon, with/without put, all in the message box. LC 5.5 All combinations of put/semicolon worked. LC 6.1 No put, with semicolon, failed error executing expression No put, no semicolon, worked With put, with semicolon, failed can't find handler With put, no semicolon, failed can't find handler LC 6.6 No put, with semicolon, failed error executing expression No put, no semicolon, worked With put, with semicolon, failed can't find handler With put, no semicolon, worked If it had something to do with the new SQLite library, there would have been an SQL error message but it never gets as far as executing revDataFromQuery. My feeling is that something changed in the message box parsing routines and the semicolon is being taken as a separator between two statements. However, bottom line is that all works fine in a script with or without the semicolon. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.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: hair-pulling frustration
On 11/14/2014, 11:58 AM, Peter Haworth wrote: My feeling is that something changed in the message box parsing routines and the semicolon is being taken as a separator between two statements. A semicolon in any script is interpreted as a line ending, except when within quotation marks. If the example failed (where the semicolon is within the quotes) then that would be a problem with the scripts that interpret the message box content. That said, it is very tricky to implement code correctly in all cases from the message box because of the do statements and other contortions it needs to use. Ideally, tests should always be conducted from the script editor where the intermediate interpretive layer isn't present. -- 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: hair-pulling frustration
On 11/13/2014, 10:26 PM, Geoff Canyon wrote: On Thu, Nov 13, 2014 at 3:10 PM, J. Landman Gay jac...@hyperactivesw.com wrote: I blame myself for the omissions (except when Richard G. forgives me.) :) Bless me Richard, for I have sinned. It has been two weeks since my last bug report. Since then I wrote three undocumented functions and one 80-line behemoth that was filled with hard-coded situation-specific functionality. I also used repeat-with when I should have used repeat-for-each twice. File two bug reports and say ten Our Kevins. LOL! Okay. Our Kevin, who art at RunRev, Hollowed be thy frame By coding done Yet still undone in engine, As it is in IDE. Give us this day our weekly upgrade And forgive us our complaints As we forgive the multitude of releases. And lead us not to false expectations, But deliver us from errors, For thine is the vision, The power, and the glory For all generations. -- 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: hair-pulling frustration
Hah hah! I would have used “For all permutations” instead! Bob S On Nov 14, 2014, at 10:47 , J. Landman Gay jac...@hyperactivesw.commailto:jac...@hyperactivesw.com wrote: LOL! Okay. Our Kevin, who art at RunRev, Hollowed be thy frame By coding done Yet still undone in engine, As it is in IDE. Give us this day our weekly upgrade And forgive us our complaints As we forgive the multitude of releases. And lead us not to false expectations, But deliver us from errors, For thine is the vision, The power, and the glory For all generations. -- Jacqueline Landman Gay | jac...@hyperactivesw.commailto:jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.comhttp://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: hair-pulling frustration
Right, it looks like something in the message box message box interpretation scripts changed between the various releases I tested. I guess I should file a bug report. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Fri, Nov 14, 2014 at 10:38 AM, J. Landman Gay jac...@hyperactivesw.com wrote: On 11/14/2014, 11:58 AM, Peter Haworth wrote: My feeling is that something changed in the message box parsing routines and the semicolon is being taken as a separator between two statements. A semicolon in any script is interpreted as a line ending, except when within quotation marks. If the example failed (where the semicolon is within the quotes) then that would be a problem with the scripts that interpret the message box content. That said, it is very tricky to implement code correctly in all cases from the message box because of the do statements and other contortions it needs to use. Ideally, tests should always be conducted from the script editor where the intermediate interpretive layer isn't present. -- 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 ___ 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: hair-pulling frustration
On 11/14/2014, 1:39 PM, Bob Sneidar wrote: Hah hah! I would have used “For all permutations” instead! Ooh. Like. It is revised: Our Kevin, who art at RunRev, Hollowed be thy frame By coding done Yet still undone in engine, As it is in IDE. Give us this day our weekly upgrade And forgive us our complaints As we forgive the multitude of releases. And lead us not to false expectations, But deliver us from errors, For thine is the vision, The power, and the glory For all permutations. -- 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: hair-pulling frustration
On Fri, Nov 14, 2014 at 10:38 AM, J. Landman Gay jac...@hyperactivesw.com wrote: A semicolon in any script is interpreted as a line ending, except when within quotation marks. If the example failed (where the semicolon is within the quotes) then that would be a problem with the scripts that interpret the message box content. I *initially* found this in a script, which worked fine once I removed the semicolon (which was inside the parenthesis). I removed the semicolon, and it began working. Also, I always have strict compilation on. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
Can you send us the relevant script lines? So far, it has worked in my script with or without semicolons in various versions from 5.5 and up in my testing so there must be something different in your script and mine. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Fri, Nov 14, 2014 at 1:18 PM, Dr. Hawkins doch...@gmail.com wrote: On Fri, Nov 14, 2014 at 10:38 AM, J. Landman Gay jac...@hyperactivesw.com wrote: A semicolon in any script is interpreted as a line ending, except when within quotation marks. If the example failed (where the semicolon is within the quotes) then that would be a problem with the scripts that interpret the message box content. I *initially* found this in a script, which worked fine once I removed the semicolon (which was inside the parenthesis). I removed the semicolon, and it began working. Also, I always have strict compilation on. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
If this were a realistic option, Edinburgh would have permanent testing staff. The language, syntax and interaction permutations are simply too vast for any automated testing whether by machine or human. As Richard G says, ensure your own software is robust with each new version and log any issues. The cumulative effect covers as much as is feasible. If you find a problem, log it don't hog it. Hugh Senior FLCo -- I agree. I have always felt that RunRev should occasionally hire one or two people for beta-testing. They could test new releases before they are labelled pre-release. This would cost only a little money and safe hundreds, if not thousands of people lots of frustrations. -- 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: hair-pulling frustration
Really, why wouldn't it be realistic to pay a bunch of students for a few hours of beta-testing (or should I say alpha-testing) some time in a development cycle? I'm sure they could detect the bugs that every other developer would detect right-away, but without frustrating those developers because the people paid by RunRev have sorted them out already! -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Installer Maker for LiveCode: http://qery.us/468 Buy my new book Programming LiveCode for the Real Beginner http://qery.us/3fi LiveCode on Facebook: https://www.facebook.com/groups/runrev/ On 11/13/2014 09:13, FlexibleLearning.com wrote: If this were a realistic option, Edinburgh would have permanent testing staff. The language, syntax and interaction permutations are simply too vast for any automated testing whether by machine or human. As Richard G says, ensure your own software is robust with each new version and log any issues. The cumulative effect covers as much as is feasible. If you find a problem, log it don't hog it. Hugh Senior FLCo -- I agree. I have always felt that RunRev should occasionally hire one or two people for beta-testing. They could test new releases before they are labelled pre-release. This would cost only a little money and safe hundreds, if not thousands of people lots of frustrations. -- 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 ___ 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: hair-pulling frustration
Hello, I do agree that more testing (non automatic testing) should be made before releasing a commercial product. But I’m not sure RunRev will listen. When the CEO says: I really would urge everyone in our community to move to 7 as soon as possible. We spent 18 months building it and considering the amount of change its getting very good results stability wise. There are issues but they are mostly minor. When minor bugs are so many, I don’t consider it is minor to test and fix before releasing a commercial product. And by fixing I mean test if the fix really fixes the bug so it doesn’t have to be reopened immediately. It is not the amount of time spent on a product that is an indicator of quality. My 2 cents. Best, ÉrIC -- My NeXT computer will Be a Mac too! -- Le 13 nov. 2014 à 10:27, Mark Schonewille m.schonewi...@economy-x-talk.com a écrit : Really, why wouldn't it be realistic to pay a bunch of students for a few hours of beta-testing (or should I say alpha-testing) some time in a development cycle? I'm sure they could detect the bugs that every other developer would detect right-away, but without frustrating those developers because the people paid by RunRev have sorted them out already! -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Installer Maker for LiveCode: http://qery.us/468 Buy my new book Programming LiveCode for the Real Beginner http://qery.us/3fi LiveCode on Facebook: https://www.facebook.com/groups/runrev/ On 11/13/2014 09:13, FlexibleLearning.com wrote: If this were a realistic option, Edinburgh would have permanent testing staff. The language, syntax and interaction permutations are simply too vast for any automated testing whether by machine or human. As Richard G says, ensure your own software is robust with each new version and log any issues. The cumulative effect covers as much as is feasible. If you find a problem, log it don't hog it. Hugh Senior FLCo -- I agree. I have always felt that RunRev should occasionally hire one or two people for beta-testing. They could test new releases before they are labelled pre-release. This would cost only a little money and safe hundreds, if not thousands of people lots of frustrations. -- 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 ___ 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: hair-pulling frustration
I'll give you 2 cents for that, Éric. I also don't think that RunRev will listen. Yet, I think a company should not rely on its user base for testing. A company can't blame its user base for not testing, if something appears not to work, but a user base can blame the company for delivering broken software. Therefore, it would be wise to listen. -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Installer Maker for LiveCode: http://qery.us/468 Buy my new book Programming LiveCode for the Real Beginner http://qery.us/3fi LiveCode on Facebook: https://www.facebook.com/groups/runrev/ On 11/13/2014 10:00, Éric Miclo wrote: Hello, I do agree that more testing (non automatic testing) should be made before releasing a commercial product. But I’m not sure RunRev will listen. When the CEO says: I really would urge everyone in our community to move to 7 as soon as possible. We spent 18 months building it and considering the amount of change its getting very good results stability wise. There are issues but they are mostly minor. When minor bugs are so many, I don’t consider it is minor to test and fix before releasing a commercial product. And by fixing I mean test if the fix really fixes the bug so it doesn’t have to be reopened immediately. It is not the amount of time spent on a product that is an indicator of quality. My 2 cents. Best, ÉrIC ___ 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: hair-pulling frustration
Geoff Canyon wrote: I'm just expressing frustration about barriers to reporting bugs. For example, a login is required to file a bug... ...as it is for this list, which the bug system is being compared to. Just about any publicly-accessible venue that displays user-generated content will either require some form of authentication, or be overrun to the point of uselessness by spambots. Like this list and the forums, the account setup for RunRev's Bugzilla DB is just a one-time thing. And like the forums, you can choose to have it remember your login, so from that moment forward you'll never need to log in again. ...and the bug submission form all but requires an example stack. But seems the key word there, because while it can sometimes be useful to submit an example stack it isn't a requirement. Most of the reports there have no attachments at all, even those submitted by RunRev staff themselves. All that's truly needed is any description of the issue clear enough to allow it to be reproduced by the maintainers. Like nearly all bug reporting systems they suggest a step-by-step recipe, but sometimes that's not needed. Many submissions are just a single line, like Run this in the Message Box: some command. In some cases, like the report Dr. Hawkins referred to that Peter had submitted about breakpoints, the issue may elude a reliable recipe. In that report many from both the community and RunRev have worked toward arriving at a repeatable recipe, yet even now there appears to be some disagreement as to whether the recipes there actually work. But even in those cases, Ben, Kevin and others at RunRev have encouraged us to go ahead and submit the issue anyway. Just include the best info you have, and the core team and the community can continue to add notes there as they work toward an actionable diagnosis. When a recipe is truly elusive, that's when this list and the forums become very valuable: By describing the issue among peers, we can solicit feedback from others who may have experienced what we're seeing, or something similar enough to be relevant, and together we can work toward an actionable description of the problem. I understand the desire to get clear, actionable bug reports, and I understand the need to not waste limited team resources on bad bug reports, but if the requirements are causing Jacque to fail to report a bug, that's a huge issue. In this comparison between posting bugs to this user-to-user discussion list vs. putting them into the bug DB where they can be acted on, I don't think Jacque's comment applies. After all, it's not like she choose to take the time to report it here either. All she noted was that sometimes when she's under a heavy deadline to ship something with the version she has, she doesn't take the time to submit a bug report at all, either here or in the bug DB. I noted in reply to her post that I often to do the same, as we all do when we're busy. None of us is obliged to submit bug reports. We can choose to submit them when a bug impacts our work to the point that it benefits us to see it resolved. Or not. It's entirely voluntary. Looking forward As you noted the current version of the Bugzilla implementation RunRev has is much improved over earlier versions, and there may be ways it could be streamlined further still. Many years ago one of our community members, Ken Ray, made a nifty plugin stack to submit and review Bugzilla posts from within the IDE. It's long since outdated and he's been too busy with other commitments to maintain it, and like myself and others, he's found the Web implementation usable enough that it hasn't been an impediment for him. But if going to the Web page is holding folks back from submitting a bug, I'm sure Ken would grant permission for anyone with sufficient time and interest to rewrite his stack to work with the current bug DB. It's available as Revzilla, the first link on this page: http://www.sonsothunder.com/devres/livecode/downloads.htm If there's interest I'd be happy to contact him to get explicit permission for such a revision. That's just one option. There may be others. What other things might we consider to make filing bug reports into the bug DB significantly more efficient than filing them here in this user-to-user list? -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
HI Richard, I have a suggestion for this, having just read the entire thread. I too find it hard at times to get the time to even write here let alone fill out a report on Bugzilla. And then to go through the process of creating a recipe or sample stack. The reason for this is obvious, that like many others here we are too busy actually making products (or trying to) for our paying clients to set deadlines (often unreasonable, mostly due to their ongoing misconception to the time it takes to make software despite attempts to help them appreciate or understand it). The Bugzilla form is, I'm sure you'd agree, far more involved than writing an email. And I in turn appreciate that protocols need to be in place to avoid spammers, etc. How about this approach (which is nothing new - Apple use a similar system and I personally have had much success with it). In the LiveCode app itself (both Commercial and Community) in the Help menu should be a button to submit a report. This can either take you to a basic form on the web or internally in the app itself (a better option to keep down spam). This goes through to a private list that only those on the RunRev development team can read. This form should be far simpler than that found on Bugzilla, i.e., Name, email, symptoms noticed, option to upload stack. If it was included in the IDE then it would automatically gather data like the platform, version number, etc. The team member that picks it up can then decide if it is worth adding to Bugzilla, adding the submitters email to the list and requesting more info via the Bugzilla repository if needed. Psychologically this works in favour of the end user. They would be more likely to provide feedback willingly if the thought that it was easy and involved far less steps. You could even have a button on the form to provide more details that could log you right into your Bugzilla account in a one step process filling in any data you'd already provided and those acquired from the system. I have a bug (Bug 13801 http://quality.runrev.com/show_bug.cgi?id=13801) I reported a little while back that, because I had no time because of my clients demands on my time, has been marked as 'Resolved' due to my not responding to their request for a sample stack. When my time is a little more free'd up (i.e., not now, despite my ability to write this email - proof that what you said earlier was bumpkin and unfair - emails are easier to write than are sample stacks that can replicate issues along with recipes.) I will be able to reopen the report and prove that it is indeed an issue that needs resolving. Here are some more reasons I find using Bugzilla so frustrating (infuriating at times). The search feature (a term I use lightly) is appalling. Loading it (bearing in mind I have a 150MB internet line) takes over 10 seconds to load. Every. Single. Time. That. I. Want. To. Do. A. New. Search!! So, trying to track down if someone else has already done one is laborious. If i enter my search in the bar at the top of the page it only returns new and pending results. So resolved ones are not shown. But that is not made clear in the search bar. So then you have to go to the advanced search which is not clear on how to access (at the top we have buttons for Home, New Search then a Search Button after the search dialogue - Is that clear?). When I add a comment to a bug and click the 'save changes' button it saves but then takes me to the next bug in the list. As an alternative I can write a rant on here with far more satisfaction and far less time wasted ;) Simple is best, my favourite philosophy. A simple form in the IDE that gets submitted for review and/or follow up. Far more likely to get results. All the best On 13 November 2014 14:39, Richard Gaskin ambassa...@fourthworld.com wrote: I'm just expressing frustration about barriers to reporting bugs. For example, a login is required to file a bug... ...as it is for this list, which the bug system is being compared to. Just about any publicly-accessible venue that displays user-generated content will either require some form of authentication, or be overrun to the point of uselessness by spambots. Sean Cole *Pi Digital Productions Ltd* www.pidigital.co.uk +44(1634)402193 +44(7702)116447 π 'Don't try to think outside the box. Just remember the truth: There is no box!' 'For then you realise it is not the box you are trying to look outside of, but it is yourself!' This email and any files transmitted with it may be confidential and are intended solely for the use of the individual to whom it is addressed. You are hereby notified that if you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Any distribution, reproduction, modification or publication of this communication is strictly prohibited. If you have received this in error, please notify the sender and delete the message from your
Re: hair-pulling frustration
Éric Miclo wrote: I do agree that more testing (non automatic testing) should be made before releasing a commercial product. But I’m not sure RunRev will listen. When the CEO says: I really would urge everyone in our community to move to 7 as soon as possible. We spent 18 months building it and considering the amount of change its getting very good results stability wise. There are issues but they are mostly minor. When minor bugs are so many, I don’t consider it is minor to test and fix before releasing a commercial product. And by fixing I mean test if the fix really fixes the bug so it doesn’t have to be reopened immediately. It is not the amount of time spent on a product that is an indicator of quality. My 2 cents. Best, ÉrIC -- My NeXT computer will Be a Mac too! -- Re/Code recently posted the full video of their interview with Apple VP Greg Joswiak, discussing iOS 8.0.1 bugs among other things: http://www.macrumors.com/2014/11/12/greg-joswiak-full-interview/ iOS 8.0.1 was sent out in response to critical bugs in v8.0, and it turned out that the fix itself required fixing, as 8.0.1 wound up bricking some user's phones. In the video the interviewer raises the larger question of overall QA, and we're all familiar with recent issues there from iMaps forward. Watching the video, I don't feel Joswiak's obvious pride in Apple is at all misplaced. Sure, there have been many issues, sometimes critical ones, in both iOS and OS X in recent years, and this may seem surprising given the wealth of resources Apple has at their disposal which would seem more than sufficient to prevent such things. Software is complex stuff. I don't think it was a mistake for Tim Cook to suggest we upgrade our Apple devices to the latest software version which later bricked some phones, and I don't think it was a mistake for Kevin to suggest that we use the latest version of his company's software. Obviously, with the benefit of hindsight, both CEOs were mistaken about the fitness of the final deliverable, and both companies have devoted considerable resources to addressing the issues once they became evident. I'd wager that Apple has now added additional QA review steps to prevent the specific issues that affected iOS 8.0.1, and I'd wager RunRev has done the same with the issues evident in 7.0. Late-stage regressions are especially troubling for all of us. developers and users alike, because in the late stages it's especially hard to detect such things as might have happened during earlier Beta periods. When unpredictable events occurs late-stage it becomes more likely that a software will be delivered that makes standalones unable to quit, or bricks people's phones. I wouldn't assume that either Apple or RunRev spends nothing on internal testing. On the contrary, as a percentage of payroll I'd be surprised if RunRev's costs for that weren't a multiple of Apple's. I volunteered for this role of Community Manager because LiveCode is very important to my own business interests and those of my clients. Part of this role is to advocate for community concerns, and I agree that QA is critical. We *all* want to see QA improved, ever more so going forward. The folks at RunRev have more at stake in this than most of us. Those of us who read the bug DB regularly have a good appreciation for the level of engagement the core team has in the QA process. That v7.0 shipped with show-stoppers is annoying to all of us, and exploring ways to improve the QA process is the focus of my meeting with Ben later today. Sean's suggestion of including a reporting item in the Help menu is a very good one, and I'll be sure to raise it at the meeting. Any other specific actionable items like that are very welcome, and can help us all refine the process of making complex software ever more robust. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
Sean Cole wrote: I have a suggestion for this, having just read the entire thread. How about this approach (which is nothing new - Apple use a similar system and I personally have had much success with it). In the LiveCode app itself (both Commercial and Community) in the Help menu should be a button to submit a report. This can either take you to a basic form on the web or internally in the app itself (a better option to keep down spam). That's an excellent suggestion - I'll pursue that with Ben later this morning. I have a bug (Bug 13801 http://quality.runrev.com/show_bug.cgi?id=13801) I reported a little while back that, because I had no time because of my clients demands on my time, has been marked as 'Resolved' due to my not responding to their request for a sample stack. When my time is a little more free'd up (i.e., not now, despite my ability to write this email - proof that what you said earlier was bumpkin and unfair - emails are easier to write than are sample stacks that can replicate issues along with recipes.) I will be able to reopen the report and prove that it is indeed an issue that needs resolving. My apologies if what I wrote seemed unfair. It's statistically accurate to note that an overwhelming majority of issues in the bug DB do not have example stacks attached, and that includes the 1600+ items fixed over the last year. From time to time a given issue may elude a simple recipe, and in those cases it may be beneficial to provide an example stack. It's helpful that you provided the link to the report, as we can see there that while Hanson asked if you had a sample stack he never required it for you to re-open the report if you choose to do so. The one thing he did require is that you please try to see the issue in the latest build, and given the scope of changes between builds lately it's not impossible it may have been addressed while fixing other things. One of the benefits of an open source project having a Community Manager is that you get another whipping post: yours truly. :) I'm happy to advocate any community concern that hasn't been sufficiently addressed through other channels. In this case, however, the only action needed is to verify that the issue remains in the latest version, and to write one sentence there noting if that's the case. I haven't seen this myself, so I'll have to rely on your help on that. As Hanson wrote there, with your notice that the issue remains they'll devote internal resources to trying to reproduce it. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
On 13/11/14 18:22, Richard Gaskin wrote: snip Software is complex stuff. I don't think it was a mistake for Tim Cook to suggest we upgrade our Apple devices to the latest software version which later bricked some phones, and I don't think it was a mistake for Kevin to suggest that we use the latest version of his company's software. snip Certainly, slagging off RunRev does nobody any good at all. What might do some good is point out to RunRev that when they released their Open Source version of LiveCode they undertook to be more touchy-feely and more responsive to their users . . . and, just possibly, they may be falling short of this. Also, as I mentioned earlier, some of us are raving egomaniacs who aren't going to do anything unless we get our egos tickled as a result; hence my suggestion about T-shirts and so on. One of the more important reasons Communism failed was its refusal to acknowledge that complete, uninterested altruism only exists in fairy stories, and the profit motive is very deeply entrenched in human nature . . . I believe there needs to be: 1. a set list of incentives on offer for bug detection. 2. a strictly defined procedure [a detailed bug-report form online ] for bug reporting. 3. a regular interval between dp/rc releases so that beta-testers are aware of how much time they have at their disposal to do any testing. As I mentioned earlier, WINE have a rather good way of doing things, and Canonical do with Ubuntu: https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule maybe RunRev could do something like that. Richmond. ___ 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: hair-pulling frustration
On 11/13/2014, 1:50 AM, Geoff Canyon wrote: if the requirements are causing Jacque to fail to report a bug, that's a huge issue. Well, to be fair, it doesn't always prevent me from reporting things. If I have time I do create an example stack, especially if my current work can't proceed without a bug fix. But I've also found that if a problem is pretty obvious, about 80% of the time someone else will report it. The failure of the command keys is one example where there were multiple reports without my help. -- 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: hair-pulling frustration
On 11/13/2014, 2:27 AM, Mark Schonewille wrote: Really, why wouldn't it be realistic to pay a bunch of students for a few hours of beta-testing (or should I say alpha-testing) some time in a development cycle? There's no way a few hours would catch much in a system as complex and large as LiveCode. It wouldn't make a dent. -- 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: hair-pulling frustration
On Wed, Nov 12, 2014 at 11:22 AM, Peter Haworth p...@lcsql.com wrote: On Tue, Nov 11, 2014 at 3:13 PM, Dr. Hawkins doch...@gmail.com wrote: SELECT * FROM sometable; worked before the change with SQLite. Now, it is necessary to remove the semicolon. I just tried this using LC 5.5.4 (prior to the SQLite library change) and LC 6.6.2 (after the SQLite library change), with and without the semicolon and all tests worked fine. You mentioned a parsing error - did you mean an LC compile error or an SQLite error? Either way, what was the error? revDataFromQuery(,,17,SELECT * FROM vader_darth__001_dna;) yields Message execution error: Error description: value: error executing expression Hint: ) While if I leave out the semicolon, it gives me all the data in the table. This from 7.0-RC2 moments ago -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On 11/13/2014, 12:20 PM, Richmond wrote: I believe there needs to be: 1. a set list of incentives on offer for bug detection. I wonder if it would be possible to extend a user's license for a short period after a certain number of verified bug reports has been submitted. For community edition users, perhaps a larger number of verified bugs would allow a week or so of commercial access. I suspect this would be difficult or too time-consuming to implement on RR's end though. But I think it would be a better incentive than a tee shirt and wouldn't cost the company much outside of the time to maintain 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: hair-pulling frustration
Hi Richard, I've attempted to replicate the semicolon issue without any success. This could be why we have not come accross it during testing in-house. The script that I tested with is- global gConnectionID on mouseUp global gConnectionID if gConnectionID is not a number then answer error Please connect to the database first. exit to top end if put Table1 into tTableName put SELECT * FROM tTableName into tSQL put revDataFromQuery(,,gConnectionID,SELECT * FROM Table1;) into tData if item 1 of tData = revdberr then answer error There was a problem querying the database: cr tData else put tData into field Data end if end mouseUp Both the inclusion and exclusion of the semi-colon return data as expected. If possible, could you supply a stack for me to test with and I will happily look into this further. Kind Regards, Neil Roger -- LiveCode Support Team ~ http://www.livecode.com -- On 13/11/2014 19:09, Dr. Hawkins wrote: revDataFromQuery(,,17,SELECT * FROM vader_darth__001_dna;) yields Message execution error: Error description: value: error executing expression Hint: ) ___ 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: hair-pulling frustration
On Thu, Nov 13, 2014 at 11:09 AM, Dr. Hawkins doch...@gmail.com wrote: revDataFromQuery(,,17,SELECT * FROM vader_darth__001_dna;) yields Message execution error: Error description: value: error executing expression Hint: ) While if I leave out the semicolon, it gives me all the data in the table. This from 7.0-RC2 moments ago Thanks for the clarification. SInce this works in 6.6.2 which uses the new SQLite library but not in 7.0rc2, it looks to be a 7.0rc2 bug. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.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: hair-pulling frustration
On Thu, Nov 13, 2014 at 1:06 PM, J. Landman Gay jac...@hyperactivesw.com wrote: On 11/13/2014, 1:50 AM, Geoff Canyon wrote: if the requirements are causing Jacque to fail to report a bug, that's a huge issue. Well, to be fair, it doesn't always prevent me from reporting things. If I have time I do create an example stack, especially if my current work can't proceed without a bug fix. But I've also found that if a problem is pretty obvious, about 80% of the time someone else will report it. The failure of the command keys is one example where there were multiple reports without my help. I didn't mean to imply that the system is preventing you from entering any bugs; I'm saying that given your many years of experience and dedication to the platform if the system prevents you from entering even a single bug, that's bad. ___ 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: hair-pulling frustration
On 11/13/2014, 2:32 PM, Geoff Canyon wrote: I didn't mean to imply that the system is preventing you from entering any bugs; I'm saying that given your many years of experience and dedication to the platform if the system prevents you from entering even a single bug, that's bad. The thing is, I don't blame the system at all, I think it's my own fault. As a developer, I always need a reproducible recipe to fix bugs, and requiring a stack that provides the recipe is reasonable. I blame myself for the omissions (except when Richard G. forgives me.) :) -- 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: hair-pulling frustration
Neil, With user input and Richard's moderating this thread has started to bear some fruit. After writing HW diagnostics for years I know how challenging is to come with thorough testing scenarios. I don't know what your QC process for databases is but might I suggest using challenging queries. I would be happy to set up a stack to test them along with the DBs. For example: SELECT Table1.*, Table2.*,Table3.* FROM Table1 LEFT JOIN Table2 ON Table1.Designation = Table2.Designation LEFT JOIN Table3 ON Table1.State = Table3.State AND Table1.County = Table3.County WHERE (Table3.Region = 'Foo') or ATTACH DATABASE Table3.db AS Table3DB SELECT Table3.*,Table1.* from Table3DB.Table3 JOIN Table1 ON Table3.CourseID = Table1.CourseID JOIN Table2 ON Table2.County = Table1.County AND Table2.State = Table1.State WHERE (Table3.Favorite or Table3.frog '') Mr. Haworth and all you other DB gurus out there, what other testing scenarios do think should be included in the RR DB QC process? The way I look at it the more we help RR the more we help ourselves. Ralph DiMola IT Director Evergreen Information Services rdim...@evergreeninfo.net -Original Message- From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] On Behalf Of Neil Roger Sent: Thursday, November 13, 2014 2:59 PM To: How to use LiveCode Subject: Re: hair-pulling frustration Hi Richard, I've attempted to replicate the semicolon issue without any success. This could be why we have not come accross it during testing in-house. The script that I tested with is- global gConnectionID on mouseUp global gConnectionID if gConnectionID is not a number then answer error Please connect to the database first. exit to top end if put Table1 into tTableName put SELECT * FROM tTableName into tSQL put revDataFromQuery(,,gConnectionID,SELECT * FROM Table1;) into tData if item 1 of tData = revdberr then answer error There was a problem querying the database: cr tData else put tData into field Data end if end mouseUp Both the inclusion and exclusion of the semi-colon return data as expected. If possible, could you supply a stack for me to test with and I will happily look into this further. Kind Regards, Neil Roger -- LiveCode Support Team ~ http://www.livecode.com -- On 13/11/2014 19:09, Dr. Hawkins wrote: revDataFromQuery(,,17,SELECT * FROM vader_darth__001_dna;) yields Message execution error: Error description: value: error executing expression Hint: ) ___ 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: hair-pulling frustration
Richmond wrote: What might do some good is point out to RunRev that when they released their Open Source version of LiveCode they undertook to be more touchy-feely and more responsive to their users . . . and, just possibly, they may be falling short of this. Perhaps. What should touchy-feely ideally translate to in terms of specific actions? Also, as I mentioned earlier, some of us are raving egomaniacs who aren't going to do anything unless we get our egos tickled as a result; hence my suggestion about T-shirts and so on. That's a good idea. Ego is very important, a key motivator in so many aspects of life. Mention in the About box is a start, but if a t-shirt helps that seems easy enough to do. I'd also like to see a Community Contributors page listing those who've contributed to the project, and Steven at RunRev is keen to add that with some other changes they're making to clean up the site's taxonomy. As I mentioned earlier, WINE have a rather good way of doing things, and Canonical do with Ubuntu: https://wiki.ubuntu.com/UtopicUnicorn/ReleaseSchedule maybe RunRev could do something like that. You know I loves me some Ubuntu, but I have to acknowledge that their six-month fixed cadence is a highly controversial thing, not least of all within their office. Last I heard they've decided to stick with the six-month cycle, but they've discussed many other models and apparently got close to choosing one of the alternatives a little while ago. A fixed schedule is helpful in some respects, but is also limiting on others. Among other things it requires that work be broken up into six-month blocks (or actually about 4 months, since the first month after release requires planning the work for the next one, and the last month is feature-freeze), and not everything fits into blocks of a fixed size. They do manage to pursue bigger objectives, like Ubuntu Mobile, Mir, and other projects, but if those finish later than mid-way through a cycle they may have to postpone rollout until the next one, losing time that a different model wouldn't require them to. Speaking of: This week is the Ubuntu Online Summit, where v15.04 is being planned. If you want to participate, or even list listen in to learn the process by which Ubuntu is made, the schedule is here: http://summit.ubuntu.com/uos-1411/ Yesterday I attended the File Manager session and Mark Shuttleworth's keynote. Learned a lot from both. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
Note to self : I am *not* getting involved in this thread. I am *not* getting involved in this thread. I am *not* getting involved in this thread. I am *not* getting involved in this thread. I do *not* have time to read, never mind get involved in, this thread. :-) OK. Having said that to myself - one small suggestion. It would seem touchy-feely for there to be more response on this list from RR. You (Richard) are doing a great job as Community Manager, and responding here. How about you get an email address like rich...@runrev.com so that it does feel more like a RR response :-) I suspect this list is mostly us old dinosaurs, and most of the newer users are on the forums, and *we* should all know who you are - but it would maybe help remind us that you have a role within RR and are effectively part of the RR team taking in our input. Regards, -- Alex. On 13/11/2014 22:11, Richard Gaskin wrote: Richmond wrote: What might do some good is point out to RunRev that when they released their Open Source version of LiveCode they undertook to be more touchy-feely and more responsive to their users . . . and, just possibly, they may be falling short of this. Perhaps. What should touchy-feely ideally translate to in terms of specific actions? ___ 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: hair-pulling frustration
On Thu, Nov 13, 2014 at 11:58 AM, Neil Roger n...@livecode.com wrote: Both the inclusion and exclusion of the semi-colon return data as expected. If possible, could you supply a stack for me to test with and I will happily look into this further. I'll see what I can pop together. And now, I am getting an empty return (rather than data or error) when I include the semicolon . . . -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
Alex Tweedly wrote: It would seem touchy-feely for there to be more response on this list from RR. I tend to feel the same, but as with so many things it's a balancing act - after all, one of the reasons we want them here is to tell them to go away so they can spend their time fixing bugs. :) We have seen a strong increase in other communications like the newsletters and the blog, and from time to time we see Fraser, Neil, Ben, and once in a while even Kevin here, more so than in years past. Certainly wouldn't hurt to see more of them (though Neil posted here just this morning), but with all they've been doing it's not always easy to get the time for more posts here and in the forums than they make already. You (Richard) are doing a great job as Community Manager, and responding here. How about you get an email address like richard at runrev.com so that it does feel more like a RR response :-) Two reasons: 1. I'm not an employee of RunRev, and volunteered primarily to support community contributions to the open source project. I feel it's important in a role of community advocacy to be able to speak candidly, and an address at the corporate domain might seem a mixed message. 2. I'm lazy. I do have an address at livecode.org (the community side of things), but simply hadn't taken the time to set up a separate subscription to this list under that address. I get mail there, though, and note it in posts where I'm wearing the CM hat. That said, I took your advice and just set up a subscription from the .org address. If you can read this, it worked. As a practical matter (read, I still run a business in between these volunteer activities) I may not always remember to change my default address when replying, but I'll continue to try to use my CM sigline where appropriate. I suspect this list is mostly us old dinosaurs, and most of the newer users are on the forums, and *we* should all know who you are - but it would maybe help remind us that you have a role within RR and are effectively part of the RR team taking in our input. Unless you spend a lot of time hanging out with FOSS geeks, it's not always clear what a Community Manager even is. I didn't really know either until I met Jono Bacon back when he was the Ubuntu Community Manager, and I didn't really understand the scope of the role until I read his book, The Art of Community. Ubuntu has been a very liberating platform for many of my business activities, both client and server, and the more I learn about how it's made the more it's become clear that it would be very difficult to pull that off if it were solely a corporate effort or solely a community effort. Many such projects really benefit a lot from the partnership between the corporate stewards and a supportive community, accomplishing more together than they could alone. When Kevin announced that LC was going FOSS, he can tell you how annoying I became in my insistence that the project could use a CM to really make the most of this new community focus. After enough times of him reminding me that he needs to keep his staff on engineering and QA, I finally just volunteered for the role as my own contribution to the project. I justify the expense in the same way I donate resources to the Ubuntu project: I run a business dependent on technology, and it benefits the work I do to see the tech I need thrive. In an environment in which most of the current audience spends most of our time making and using proprietary software, there's a lot for all of us to learn about how this collaboration between the business and the community can work to the greatest benefit of our own goals. When I first took on this role we put an outline of some of that into the newsletter: http://newsletters.livecode.com/april/issue169/newsletter1.html But that's not enough. There's so much to learn and discover. LiveCode is a very big deal, not only in the scope of its code base but in its potential impact on the world. Together I believe we can see a world in which anyone with a computing device can get more out of it by truly mastering it through LiveCode. As we go forward, with good suggestions like Sean's this morning and the others that come along, step by step we'll get there. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
I just tried it under 7.0 and same result - no problems with or without the semicolon. There must be something else going on in Dr Hawkins code. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Thu, Nov 13, 2014 at 11:58 AM, Neil Roger n...@livecode.com wrote: Hi Richard, I've attempted to replicate the semicolon issue without any success. This could be why we have not come accross it during testing in-house. The script that I tested with is- global gConnectionID on mouseUp global gConnectionID if gConnectionID is not a number then answer error Please connect to the database first. exit to top end if put Table1 into tTableName put SELECT * FROM tTableName into tSQL put revDataFromQuery(,,gConnectionID,SELECT * FROM Table1;) into tData if item 1 of tData = revdberr then answer error There was a problem querying the database: cr tData else put tData into field Data end if end mouseUp Both the inclusion and exclusion of the semi-colon return data as expected. If possible, could you supply a stack for me to test with and I will happily look into this further. Kind Regards, Neil Roger -- LiveCode Support Team ~ http://www.livecode.com -- On 13/11/2014 19:09, Dr. Hawkins wrote: revDataFromQuery(,,17,SELECT * FROM vader_darth__001_dna;) yields Message execution error: Error description: value: error executing expression Hint: ) ___ 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: hair-pulling frustration
On Thu, Nov 13, 2014 at 4:32 PM, Peter Haworth p...@lcsql.com wrote: I just tried it under 7.0 and same result - no problems with or without the semicolon. There must be something else going on in Dr Hawkins code. The ones I posted today were typed into the message box! -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On Thu, Nov 13, 2014 at 3:10 PM, J. Landman Gay jac...@hyperactivesw.com wrote: I blame myself for the omissions (except when Richard G. forgives me.) :) Bless me Richard, for I have sinned. It has been two weeks since my last bug report. Since then I wrote three undocumented functions and one 80-line behemoth that was filled with hard-coded situation-specific functionality. I also used repeat-with when I should have used repeat-for-each twice. File two bug reports and say ten Our Kevins. ___ 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: hair-pulling frustration
I agree. I have always felt that RunRev should occasionally hire one or two people for beta-testing. They could test new releases before they are labelled pre-release. This would cost only a little money and safe hundreds, if not thousands of people lots of frustrations. -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Installer Maker for LiveCode: http://qery.us/468 Buy my new book Programming LiveCode for the Real Beginner http://qery.us/3fi LiveCode on Facebook: https://www.facebook.com/groups/runrev/ On 11/11/2014 20:25, Dr. Hawkins wrote: I can't help but wonder what it would take to get runrev to follow normal practice and actually get something to alpha level before calling it a developer preview, beta by a release candidate (ok, that still wouldn't be normal), and working rather than early beta before release. If I sold something at these stages, I'd be out of business by sundown. Do the developers even pretend to use the IDE before slapping release candidate on it? Do they even have some kind of test suite? The sheer number of pieces of working code that have broken when going from 5.5 to 7.0 is beyond belief, as is the giant step backward in the IDE. I used to have to kill livecode frequently for the phantom shadow variable problem. While that happens more often under 6 (which is why I could never use it) and 7, I now usually have to kill the whole thing before that happens, as I can't get it to set a breakpoint, or even acknowedge that I've clicked anything, delays of several seconds, and so forth. In addition to the others I've mentioned here an in other recent posts, the recompile of sqlite is not quite compatible with the old, and behaves differently. For example, a semicolon at the end of an entry without begin/end transaction now causes a parsing error. Moving forward is one thing, but the only near release grade version is 5.x, which itself isn't quite ready for primetime. OK, I'll stop venting, but the amount of time I'm losing to bugs that never should have seen a public preview is getting increasingly frustrating. ___ 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: hair-pulling frustration
Jacque, I teach a class for free and if one student doesn't understand one word, I spend some extra time with that student to make sure he or she understands it. If I didn't do this, I would lose the students one by one and in the end I'd be the only one understanding the lesson. So, I guess it means I slow down until every student understands all words. -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Installer Maker for LiveCode: http://qery.us/468 Buy my new book Programming LiveCode for the Real Beginner http://qery.us/3fi LiveCode on Facebook: https://www.facebook.com/groups/runrev/ On 11/11/2014 22:53, J. Landman Gay wrote: On 11/11/2014, 3:23 PM, Richmond wrote: Several times I have stated that in my opinion RunRev are being swept along into a sort of feature bloat which prevents them from sorting out little 'niggles' in existing features. I se no reason to change that opinion. Suppose while teaching English, you were not paid by the time you put in, but rather by the number of students who learn each word. If you teach 10 students and they all learn the word, you get paid for 10 words. If one student does not learn the word, then you must go back and re-teach it until the student understands it. You don't get paid for his word until that happens. If 9 of your students learn the word but one does not, would you stop introducing new words in class until the one student understands it? Or would you re-teach that student on your own time? Or would you just postpone it for a while because it affects only one person? Suppose 6 students don't understand the word. In that case you would probably decide to re-teach it during class time because so many students are affected. The four remaining students would be idle until that is done and may feel you are depriving them of a full education. Suppose 3 students don't understand it. Where would you draw the line? Remember, you get paid by the word. ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 11:15 PM, J. Landman Gay jac...@hyperactivesw.com wrote: An unresponsive IDE was mentioned. The editor and the IDE can both become frozen if you are debugging and you try to do something else without exiting debug mode. Not only can you not type into the editor, which is to be expected, but most of your stack and even the IDE won't respond either (though the message box still works, and the app browser.) Almost everything else just stops and you are in a state of suspension while the engine waits for debugging to finish. The solution is to hit the blue square to stop debugging, or to hit the Run button to execute the rest of the handler, and everything picks up again. I've never seen the IDE freeze up outside of that situation. What works, however, is far more limited than in 5.5. The freezes I see include while editing or scrolling, when it freezes for 2-5 seconds before accepting clicks or keys, and just plain locking up *after* exiting debugging and refusing evermore to make any changes, requiring a restart of livecode. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On 11/12/2014 04:25 PM, Mark Schonewille wrote: Jacque, I teach a class for free and if one student doesn't understand one word, I spend some extra time with that student to make sure he or she understands it. If I didn't do this, I would lose the students one by one and in the end I'd be the only one understanding the lesson. So, I guess it means I slow down until every student understands all words. I have parents who ask me how long it will take me to get through a textbook, and I always tell them I don't know . . . because pupils are all different and one must work at the rate that is best for the slowest. Richmond. -- Best regards, Mark Schonewille Economy-x-Talk Consulting and Software Engineering Homepage: http://economy-x-talk.com Twitter: http://twitter.com/xtalkprogrammer KvK: 50277553 Installer Maker for LiveCode: http://qery.us/468 Buy my new book Programming LiveCode for the Real Beginner http://qery.us/3fi LiveCode on Facebook: https://www.facebook.com/groups/runrev/ On 11/11/2014 22:53, J. Landman Gay wrote: On 11/11/2014, 3:23 PM, Richmond wrote: Several times I have stated that in my opinion RunRev are being swept along into a sort of feature bloat which prevents them from sorting out little 'niggles' in existing features. I se no reason to change that opinion. Suppose while teaching English, you were not paid by the time you put in, but rather by the number of students who learn each word. If you teach 10 students and they all learn the word, you get paid for 10 words. If one student does not learn the word, then you must go back and re-teach it until the student understands it. You don't get paid for his word until that happens. If 9 of your students learn the word but one does not, would you stop introducing new words in class until the one student understands it? Or would you re-teach that student on your own time? Or would you just postpone it for a while because it affects only one person? Suppose 6 students don't understand the word. In that case you would probably decide to re-teach it during class time because so many students are affected. The four remaining students would be idle until that is done and may feel you are depriving them of a full education. Suppose 3 students don't understand it. Where would you draw the line? Remember, you get paid by the word. ___ 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: hair-pulling frustration
Let me just say that for some folks who do not have enough time to report bugs, they certainly have found an abundance of time to post their frustrations to this list! Just sayin’. 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: hair-pulling frustration
On 12/11/14 19:50, Bob Sneidar wrote: Let me just say that for some folks who do not have enough time to report bugs, they certainly have found an abundance of time to post their frustrations to this list! Just sayin’. Bob S ___ Ooo! Bi*chy :) The point that came out of this discussion is that the LiveCode 'Community' are dividing into two camps: 1. The Open Source, willing-to-pitch-in-and-help brigade, who pay for their LiveCode by contributing, bug-hunting and so forth. 2. The Commercial, I-pay-and-I-expect quality brigade, who do not want to have to worry their pretty little heads about bugs. The latter group have just as much right to complain about bugs as the former one. Richmond. ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 3:13 PM, Dr. Hawkins doch...@gmail.com wrote: SELECT * FROM sometable; worked before the change with SQLite. Now, it is necessary to remove the semicolon. I just tried this using LC 5.5.4 (prior to the SQLite library change) and LC 6.6.2 (after the SQLite library change), with and without the semicolon and all tests worked fine. You mentioned a parsing error - did you mean an LC compile error or an SQLite error? Either way, what was the error? Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.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: hair-pulling frustration
Can't quite agree with that simplistic analysis. There are many Commercial users who test the dp and rc releases, especially if they contain fixes for bugs they reported. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Wed, Nov 12, 2014 at 10:49 AM, Richmond richmondmathew...@gmail.com wrote: On 12/11/14 19:50, Bob Sneidar wrote: Let me just say that for some folks who do not have enough time to report bugs, they certainly have found an abundance of time to post their frustrations to this list! Just sayin’. Bob S ___ Ooo! Bi*chy :) The point that came out of this discussion is that the LiveCode 'Community' are dividing into two camps: 1. The Open Source, willing-to-pitch-in-and-help brigade, who pay for their LiveCode by contributing, bug-hunting and so forth. 2. The Commercial, I-pay-and-I-expect quality brigade, who do not want to have to worry their pretty little heads about bugs. The latter group have just as much right to complain about bugs as the former one. Richmond. ___ 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: hair-pulling frustration
On Wed, Nov 12, 2014 at 11:50 AM, Bob Sneidar bobsnei...@iotecdigital.com wrote: Let me just say that for some folks who do not have enough time to report bugs, they certainly have found an abundance of time to post their frustrations to this list! Just sayin’. It takes far less time to send an email than it does to file a bug. This has gotten better with the new bug entry interface -- not sure when that went in. ___ 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: hair-pulling frustration
Geoff Canyon wrote: It takes far less time to send an email than it does to file a bug. If you just want to type, the difference is negligible. If you want to actually see the bug fixed, the ROI for filing a bug report is much higher. ;) -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
Any positive value is higher than zero, so sure. I'm just expressing frustration about barriers to reporting bugs. For example, a login is required to file a bug, and the bug submission form all but requires an example stack. I understand the desire to get clear, actionable bug reports, and I understand the need to not waste limited team resources on bad bug reports, but if the requirements are causing Jacque to fail to report a bug, that's a huge issue. On Wed, Nov 12, 2014 at 6:35 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Geoff Canyon wrote: It takes far less time to send an email than it does to file a bug. If you just want to type, the difference is negligible. If you want to actually see the bug fixed, the ROI for filing a bug report is much higher. ;) -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
WINE has an interesting release model: https://www.winehq.org/ Every 2 weeks, dead on time, they release another beta version, and whenever (and 'whenever' can mean anything between 2 weeks to 2 years) they release a stable version. The beta versions are labelled like this: 1.7.1, 1.7.2 and so on. The stable releases always have an even number in second place, so 1.6, 1.8 etc. They advise anybody except for nutty fruitcakes like myself to stick with the stable releases and explicitly state that they accept NO responsibility for anything the beta versions may do. Richmond. ___ 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: hair-pulling frustration
On 11/11/14 21:25, Dr. Hawkins wrote: I can't help but wonder what it would take to get runrev to follow normal practice and actually get something to alpha level before calling it a developer preview, beta by a release candidate (ok, that still wouldn't be normal), and working rather than early beta before release. If I sold something at these stages, I'd be out of business by sundown. Do the developers even pretend to use the IDE before slapping release candidate on it? Do they even have some kind of test suite? The sheer number of pieces of working code that have broken when going from 5.5 to 7.0 is beyond belief, as is the giant step backward in the IDE. I used to have to kill livecode frequently for the phantom shadow variable problem. While that happens more often under 6 (which is why I could never use it) and 7, I now usually have to kill the whole thing before that happens, as I can't get it to set a breakpoint, or even acknowedge that I've clicked anything, delays of several seconds, and so forth. In addition to the others I've mentioned here an in other recent posts, the recompile of sqlite is not quite compatible with the old, and behaves differently. For example, a semicolon at the end of an entry without begin/end transaction now causes a parsing error. Moving forward is one thing, but the only near release grade version is 5.x, which itself isn't quite ready for primetime. OK, I'll stop venting, but the amount of time I'm losing to bugs that never should have seen a public preview is getting increasingly frustrating. Dear Dr Hawkins, I hope RunRev listen to you: they certainly have shown little or no sign of listening when I have stated similar reservations about Stable releases. As a Mac PPC loony the fact that the 'last' Mac PPC compatible version (6.6.5) doesn't have an icon that shows up is, frankly, pathetic, and easily resolved . . . but it hasn't been. And that, as they say, is the smallest of all the bi*ches there are right across the stable releases. The problem of Unicode fonts being substituted for on past XP Windows shows no sign of being resolved, despite Microsoft having pumped out Vista, 7, 8 and *.1 since then. Boom, boom, and so it goes . . . Richmond. ___ 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: hair-pulling frustration
Dr. Hawkins wrote: OK, I'll stop venting, but the amount of time I'm losing to bugs that never should have seen a public preview is getting increasingly frustrating. I agree, which is why it benefits no one more than ourselves to test our work with pre-release versions. The SQLite issue may be more related to the new SQLite code base than with LiveCode. I can't say specifically - Mr. Haworth, what do you find with that? On the other issues, can you share the bug report numbers so we can follow them? -- 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: hair-pulling frustration
On 11/11/14 21:55, Richard Gaskin wrote: Dr. Hawkins wrote: OK, I'll stop venting, but the amount of time I'm losing to bugs that never should have seen a public preview is getting increasingly frustrating. I agree, which is why it benefits no one more than ourselves to test our work with pre-release versions. That is, of course, very true. Another idea that might not be bad, is to slow down the releases so there is more time for testing. I would love to do more testing (I do almost none) but do not have the time as I have a full work schedule both in terms of my teaching duties and my programming ones. Given more time between releases of development previews, release candidates and stable releases might allow many of us busy people slightly more time to do this sort of thing. Another idea would be to award brownie points to anyone who identifies and documents a bug, and, after somebody has collected enough points they could receive some sort tangible reward. The SQLite issue may be more related to the new SQLite code base than with LiveCode. I can't say specifically - Mr. Haworth, what do you find with that? On the other issues, can you share the bug report numbers so we can follow them? Richmond. ___ 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: hair-pulling frustration
Hi Dr. Hawkins, The whole computer industry is changing too rapidly now. Their is no such thing as “stable” as a result. What everyone wants is a “stable” OS, a “stable” language, a “stable” database, and stable hardware platforms to go with it all. If we had all of that, we’d already have a stable “AI” computer system. Instead it’s all becoming an upgrade hell for everyone except the people who at the top are making money from the entire circus they’ve created. Just my 2 cents. Thanks for letting all of us vent a little! LOL Rick On Nov 11, 2014, at 2:25 PM, Dr. Hawkins doch...@gmail.com wrote: I can't help but wonder what it would take to get runrev to follow normal practice and actually get something to alpha level before calling it a developer preview, beta by a release candidate (ok, that still wouldn't be normal), and working rather than early beta before release. If I sold something at these stages, I'd be out of business by sundown. Do the developers even pretend to use the IDE before slapping release candidate on it? Do they even have some kind of test suite? The sheer number of pieces of working code that have broken when going from 5.5 to 7.0 is beyond belief, as is the giant step backward in the IDE. I used to have to kill livecode frequently for the phantom shadow variable problem. While that happens more often under 6 (which is why I could never use it) and 7, I now usually have to kill the whole thing before that happens, as I can't get it to set a breakpoint, or even acknowedge that I've clicked anything, delays of several seconds, and so forth. In addition to the others I've mentioned here an in other recent posts, the recompile of sqlite is not quite compatible with the old, and behaves differently. For example, a semicolon at the end of an entry without begin/end transaction now causes a parsing error. Moving forward is one thing, but the only near release grade version is 5.x, which itself isn't quite ready for primetime. OK, I'll stop venting, but the amount of time I'm losing to bugs that never should have seen a public preview is getting increasingly frustrating. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 11:55 AM, Richard Gaskin ambassa...@fourthworld.com wrote: Dr. Hawkins wrote: OK, I'll stop venting, but the amount of time I'm losing to bugs that never should have seen a public preview is getting increasingly frustrating. I agree, which is why it benefits no one more than ourselves to test our work with pre-release versions. Two problems, though: 1) One can *either* stay with 5.5, *or* use any of the new features. Without maintaining two codebases (impossible with livecode's monolithic file), there is no way to do both. 2) These prereleases just aren't ready for what they're called and presented as. I simply cannot believe that anyone who uses the debugger would have signed off on it. I really can't give up any significant portion of my coding time to do livecode's work for them; these are things that are so basic that they never should have seen a release to the public. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 11:25 AM, Dr. Hawkins doch...@gmail.com wrote: In addition to the others I've mentioned here an in other recent posts, the recompile of sqlite is not quite compatible with the old, and behaves differently. For example, a semicolon at the end of an entry without begin/end transaction now causes a parsing error. I rarely, if ever, try to execute multiple SQL statements in one revDatabasexxx so haven't seen that particular problem. Could you give an example? I'd like to check it out as I don't want to get hit by the same bug. Thanks, Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.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: hair-pulling frustration
On Tue, Nov 11, 2014 at 11:55 AM, Richard Gaskin ambassa...@fourthworld.com wrote: The SQLite issue may be more related to the new SQLite code base than with LiveCode. I can't say specifically - Mr. Haworth, what do you find with that? Just asked for an example and will check it out. Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.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: hair-pulling frustration
Richmond wrote: On 11/11/14 21:55, Richard Gaskin wrote: I agree, which is why it benefits no one more than ourselves to test our work with pre-release versions. That is, of course, very true. Another idea that might not be bad, is to slow down the releases so there is more time for testing. Agreed. While v7 did have an unusually long test period as it was (first test build was release March 19), there are a couple rough edges in the Stable build that seem the sort of thing that might have been handled prior to that designation. I would love to do more testing (I do almost none) but do not have the time as I have a full work schedule both in terms of my teaching duties and my programming ones. True, we can only afford the time we can afford. Unicode's not very critical for my work, so most of my testing was with v6.7, testing v7 only on Ubuntu and really only focused on the new Linux-specific additions there. But when a given version has new features that seem useful to us, testing is critical to ensure that it'll do what we want to it do when the final build comes out. And testing needn't necessarily be all that deep. LiveCode has a lot going on, arguably more akin to an OS than to any consumer app. We all do different things with it, and no one can guess the exact interaction of language elements we'll be using in our own scripts. So while we can't be expected to test everything, if we only test our own apps with new builds that's usually all we need for our own work. Collectively, if we call just ensured that new features get implemented in ways we need, we'll all have what we want. Rather than thinking about testing LiveCode, big as it is, it may be more helpful to think of it as testing you own app's functionality in the sliver of LiveCode that it uses. Just test your own stuff, and your own needs will be addressed. Another idea would be to award brownie points to anyone who identifies and documents a bug, and, after somebody has collected enough points they could receive some sort tangible reward. That's a good idea, and one I know Ben is keenly interested in persuing. In fact, he's brought it up in a couple of our Community meetings, but maybe you can help us out with some of the details we've been stuck on: What sorts of perks would you find motivating, and at what level of testing effort or bug report count should they kick in? -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
On 11/11/14 22:59, Dr. Hawkins wrote: snip I really can't give up any significant portion of my coding time to do livecode's work for them; these are things that are so basic that they never should have seen a release to the public. I'm afraid, Richard Gaskin et al, the above is going to be a fairly widespread response. Obviously Dr Hawkins is not over-enamoured of the Open Source theory: LiveCode is paid for in a different way [the I'll scratch your back if you'll scratch mine way] than the 'standard' commercial way [I pay you, and you do ALL the work]. Part of the problem is that Livecode is NOT like GIMP (for instance): GIMP is 100% Open Source, while Livecode both IS and ISN'T Open Source, and RunRev has to play a terrible balancing act keeping both camps happy. - I can see this problem, and have to cope with it frequently in my 'real' job. I run an English as a Foreign Language school in Bulgaria, and have constantly to explain to parents that, in spite of the fact they pay me to teach English to their children, their children will not learn anything if only I do any work and the kids do nothing. One cannot learn English in the same way as a sponge soaks up water. - The difference between what I do and LiveCode is also quite important: Livecode is a product which can be used [rather like a car can be used to drive from place to place] without having to understand what goes on 'under the hood'. Language learning means constantly messing around under the hood. And, quite honestly, if I bought a car and then was supposed to beta test the thing and keep going back to buy replacements every time something went wrong with the car I would get pretty fed up pretty quickly. The reason I don't get fed up is I keep going back and getting free replacements, and that is the main difference. Now what I don't get with the free version is the ability to lock up my code so that other people cannot pinch it, and at present that doesn't fuss me. I can, however, imagine a time when it will matter, so I will stump up the money to buy the non-free version. If, on buying the non-free version and it turns out to be dicky I shall be even more trenchant in my response than Dr Hawkins. - Of course Dr Hawkins does not really make a distinction between 'developer previews' and 'release candidates' (which are marked as such to signal a lower level of confidence in their functional completeness than 'stable' versions. He does, however, state that 'stable' versions are not much better than the others, and that is where the problem lies. Several times I have stated that in my opinion RunRev are being swept along into a sort of feature bloat which prevents them from sorting out little 'niggles' in existing features. I se no reason to change that opinion. When or if I come to thinking about buying a commercial version of LiveCode I will be in a very odd position, not really knowing whether I am buying a version that is, really, stable, or just something beta-ish labelled 'stable' which will then cause all sorts of unforeseen problems with my product. Richmond. ___ 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: hair-pulling frustration
On 11/11/14 23:16, Richard Gaskin wrote: Richmond wrote: On 11/11/14 21:55, Richard Gaskin wrote: I agree, which is why it benefits no one more than ourselves to test our work with pre-release versions. That is, of course, very true. Another idea that might not be bad, is to slow down the releases so there is more time for testing. Agreed. While v7 did have an unusually long test period as it was (first test build was release March 19), there are a couple rough edges in the Stable build that seem the sort of thing that might have been handled prior to that designation. I would love to do more testing (I do almost none) but do not have the time as I have a full work schedule both in terms of my teaching duties and my programming ones. True, we can only afford the time we can afford. Unicode's not very critical for my work, so most of my testing was with v6.7, testing v7 only on Ubuntu and really only focused on the new Linux-specific additions there. But when a given version has new features that seem useful to us, testing is critical to ensure that it'll do what we want to it do when the final build comes out. And testing needn't necessarily be all that deep. LiveCode has a lot going on, arguably more akin to an OS than to any consumer app. We all do different things with it, and no one can guess the exact interaction of language elements we'll be using in our own scripts. So while we can't be expected to test everything, if we only test our own apps with new builds that's usually all we need for our own work. Collectively, if we call just ensured that new features get implemented in ways we need, we'll all have what we want. Rather than thinking about testing LiveCode, big as it is, it may be more helpful to think of it as testing you own app's functionality in the sliver of LiveCode that it uses. Just test your own stuff, and your own needs will be addressed. Another idea would be to award brownie points to anyone who identifies and documents a bug, and, after somebody has collected enough points they could receive some sort tangible reward. That's a good idea, and one I know Ben is keenly interested in persuing. In fact, he's brought it up in a couple of our Community meetings, but maybe you can help us out with some of the details we've been stuck on: What sorts of perks would you find motivating, and at what level of testing effort or bug report count should they kick in? How about a series of T-shirts with insects all over them and the LiveCode logo: and the words, I've helped squash X bugs. where 'X' is a number? Fairly childish, but fun and effective! Richmond. ___ 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: hair-pulling frustration
On 11/11/2014, 3:16 PM, Richard Gaskin wrote: So while we can't be expected to test everything, if we only test our own apps with new builds that's usually all we need for our own work. Collectively, if we call just ensured that new features get implemented in ways we need, we'll all have what we want. If it's easy to report a bug, I do it. The lack of command key functionality for example. I can just describe a procedure to follow. Demonstrating a problem with an image redraw is easy and only requires a single card with an image and a few lines of script. I jump on that sort of thing right away. What usually stops me is the need to create a separate, stripped-down stack to demonstrate a more complicated bug. I completely understand the need for this, especially in my case where the original stack is huge and complex, and I wouldn't expect RR to plow through all that. But extracting the exact set of circumstances that reproduce the problem without including all the surrounding code can sometimes be a whole afternoon's work or more, so I don't do it. I just hope someone else has a simpler example and will report it for me instead. I know when I do this that I'm not helping myself very much, but there's too much going on to do otherwise. -- 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: hair-pulling frustration
J. Landman Gay wrote: What usually stops me is the need to create a separate, stripped-down stack to demonstrate a more complicated bug. I completely understand the need for this, especially in my case where the original stack is huge and complex, and I wouldn't expect RR to plow through all that. But extracting the exact set of circumstances that reproduce the problem without including all the surrounding code can sometimes be a whole afternoon's work or more, so I don't do it. I just hope someone else has a simpler example and will report it for me instead. I know when I do this that I'm not helping myself very much, but there's too much going on to do otherwise. No shame in that, or if there is I'm just shameless 'cause I do that all the time. Like you, I recognize that not pinning down a recipe won't help me get it fixed, but like RunRev themselves we all have to balance the desire for completely air-tight work with the realities of keeping the doors open. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
On 11/11/2014, 3:23 PM, Richmond wrote: Several times I have stated that in my opinion RunRev are being swept along into a sort of feature bloat which prevents them from sorting out little 'niggles' in existing features. I se no reason to change that opinion. Suppose while teaching English, you were not paid by the time you put in, but rather by the number of students who learn each word. If you teach 10 students and they all learn the word, you get paid for 10 words. If one student does not learn the word, then you must go back and re-teach it until the student understands it. You don't get paid for his word until that happens. If 9 of your students learn the word but one does not, would you stop introducing new words in class until the one student understands it? Or would you re-teach that student on your own time? Or would you just postpone it for a while because it affects only one person? Suppose 6 students don't understand the word. In that case you would probably decide to re-teach it during class time because so many students are affected. The four remaining students would be idle until that is done and may feel you are depriving them of a full education. Suppose 3 students don't understand it. Where would you draw the line? Remember, you get paid by the word. -- 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: hair-pulling frustration
The student example Your comment is interesting BUT; Instructors need to test the curricula before, during and after the instruction. The question is, is it the instruction, the testing or the student having the problem. It all comes back to the testing. The teacher who does not test the instruction fails. The instruction that is not tested will fail. The student that is not learning from the instruction fails. The bottom line, no testing no learning. This forum is the best source for learning at this time, your comments allow the students to learn, the teachers You are helping us all to learn. Lastly you're wasting time explaining what your not doing. NOT TESTING! Thank you Vaughn Clement Apps by Vaughn Clement (Support) *http://www.appsbyvaughnclement.com/tools/home-page/ http://www.appsbyvaughnclement.com/tools/home-page/* On Target Solutions LLC Website: http://www.ontargetsolutions.biz Email: ontargetsoluti...@yahoo.com Skype: vaughn.clement FaceTime: vclem...@gmail.com Ph. 928-254-9062 On Tue, Nov 11, 2014 at 2:53 PM, J. Landman Gay jac...@hyperactivesw.com wrote: On 11/11/2014, 3:23 PM, Richmond wrote: Several times I have stated that in my opinion RunRev are being swept along into a sort of feature bloat which prevents them from sorting out little 'niggles' in existing features. I se no reason to change that opinion. Suppose while teaching English, you were not paid by the time you put in, but rather by the number of students who learn each word. If you teach 10 students and they all learn the word, you get paid for 10 words. If one student does not learn the word, then you must go back and re-teach it until the student understands it. You don't get paid for his word until that happens. If 9 of your students learn the word but one does not, would you stop introducing new words in class until the one student understands it? Or would you re-teach that student on your own time? Or would you just postpone it for a while because it affects only one person? Suppose 6 students don't understand the word. In that case you would probably decide to re-teach it during class time because so many students are affected. The four remaining students would be idle until that is done and may feel you are depriving them of a full education. Suppose 3 students don't understand it. Where would you draw the line? Remember, you get paid by the word. -- 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 ___ 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: hair-pulling frustration
Richmond wrote: Obviously Dr Hawkins is not over-enamoured of the Open Source theory: LiveCode is paid for in a different way [the I'll scratch your back if you'll scratch mine way] than the 'standard' commercial way [I pay you, and you do ALL the work]. I think you and I may be a rare breed. I know folks in both the proprietary and open source worlds who feel the other is the embodiment of evil, but I see only an inherent symbiosis in which each side not only benefits the other, but perhaps even to the point of mutually beneficial dependency. Where would open source be without support from proprietary vendors, and where would those vendors be without the tools and infrastructure the open source world provides? Heck, these days both Apple and Microsoft promote Linux - I think it's safe to say both worlds can get along well at this point by working together. With developer tools, the argument for open source is undeniable: of the Top 100 Programming Languages on the TIOBE list, all but a small handful from multi-billion-dollar companies are open source. Since the turn of the century, the range of great tools available under open source licenses has exploded. There's simply no way a smaller player like LiveCode could ever hope to make it into the Top 50 without at least an open source option. Part of the problem is that Livecode is NOT like GIMP (for instance): GIMP is 100% Open Source, while Livecode both IS and ISN'T Open Source, and RunRev has to play a terrible balancing act keeping both camps happy. This is another of the distinctions between consumer tools and developer tools: As a consumer took, GIMP does well under GPL because it doesn't need to support developers building proprietary apps with it. As a developer tool, LiveCode needs to provide an option for proprietary deployment. And as a complex work, it needs considerable resources to be maintained. The dual-license model used by MySQL and others seems a good fit covering both sides. If, on buying the non-free version and it turns out to be dicky I shall be even more trenchant in my response than Dr Hawkins. And perhaps rightly so. The issue with testing, however, is very different from the decision to move from Release Candidate to Stable (in which case it really ought to be stable): With testing, the primary beneficiary is ourselves. I've been a beta tester for Adobe, Asymetrix, Oracle, Triton, Silicon Graphics, Canonical, and others, and I've never been paid nor expected I would be. I did it because the quality of my own work is dependent on theirs, and I've been in the business long enough to appreciate how the complexity of software requires beta testing. When I have no serious investment in a tool, I don't bother. But for tools my business relies on, testing them to make sure they do what I need has never struck me as anything other that just part of running a business that relies on software. I also do a stress test on new hard drives before I put them into production. And I test drive cars before I buy them. Just seems like a prudent thing to do. He does, however, state that 'stable' versions are not much better than the others, and that is where the problem lies. To a degree I would agree with that. Obviously a quick review of the change logs shows how much effort is expended to fixing show-stoppers during the test cycle, but in all fairness to Dr. Hawkins the issue Chipp found with the Quit item on Mac is an odd one that one could reasonably be assumed would not warrant Stable. It'll be interesting to hear how that one happened. I think it's safe to say no one at RunRev saw it and said, Nah, good enough, ship it anyway. I'd wager that somehow it never showed up in their daily work for some reason, even with their large and growing set of automated regression testing tools, and no doubt this issue has been added to that suite since. Several times I have stated that in my opinion RunRev are being swept along into a sort of feature bloat which prevents them from sorting out little 'niggles' in existing features. I se no reason to change that opinion. Perfectly valid. We all have our own preferences, and one of the reasons I left the dev tools world long ago and have no intention of returning to it is that it's full of a great many very smart people who can each come up with compelling reasons to need very different things. Some prefer we aim for a completely bug-free version, holding off all new development until that's done. But there's never been a completely bug-free app of this scope in the history of software, and with things like Apple's deprecation of QT, their pending deprecation of Carbon, Ubuntu's pending deprecation of 32-bit, Windows' ever-changing rendering models, and other things in the business environment over which no one at RunRev has any control, it's hard for them to come back to us and demand we use
Re: hair-pulling frustration
On Tue, Nov 11, 2014 at 1:09 PM, Peter Haworth p...@lcsql.com wrote: I rarely, if ever, try to execute multiple SQL statements in one revDatabasexxx so haven't seen that particular problem. Could you give an example? I'd like to check it out as I don't want to get hit by the same bug. I routinely execute many synchronize with the remote, as latency is a big deal and stops the single-threaded livecode. SELECT * FROM sometable; worked before the change with SQLite. Now, it is necessary to remove the semicolon. I routinely code the semicolons in because I variously use both direct revDatabaseXxxx calls and my own routine which wraps with Begin/End. That way, I can, err, could, simply write my queries. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 1:34 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Dr. Hawkins wrote: On Tue, Nov 11, 2014 at 11:55 AM, Richard Gaskin wrote: I agree, which is why it benefits no one more than ourselves to test our work with pre-release versions. Two problems, though: 1) One can *either* stay with 5.5, *or* use any of the new features. Without maintaining two codebases (impossible with livecode's monolithic file), there is no way to do both. 2) These prereleases just aren't ready for what they're called and presented as. I simply cannot believe that anyone who uses the debugger would have signed off on it. I'd like to raise these concerns with Ben and Kevin at my next meeting. It would be very helpful if you could point me to the bug reports that describe these issues. That's the problem. These are at a level that never should have seen the outside to be reported as bugs. That something unusual happens under certain circumstances is a bug. That the IDE window regularly pauses for seconds at a time, or stops taking input, is impossible to not notice if you actually use it. This is a commercial product that was released without testing; *that* the paying customers are expected to file bug reports over what should have been done before is the fundamental problem. I have, however, added bugs 13997-9 about the failures of the checkpoints in the IDE -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 1:23 PM, Richmond richmondmathew...@gmail.com wrote: Obviously Dr Hawkins is not over-enamoured of the Open Source theory: LiveCode is paid for in a different way [the I'll scratch your back if you'll scratch mine way] than the 'standard' commercial way [I pay you, and you do ALL the work]. Actually, I published the seminal paper on the economics of open source software, and am quite familiar with it. I purchased a $1k/year commercial license before the kickstarter campaign, and have never used the community version (and given the GPL3, probably never will, at least not until there are US court cases). While I'm at it, instead of the you get the same license on the kickstarter campaign, I ended up with the newer, subscription license. But that's a whole separate issue. When I'm paying for a license, I expect things to generally work, not to be test cases. Of course Dr Hawkins does not really make a distinction between 'developer previews' and 'release candidates' (which are marked as such to signal a lower level of confidence in their functional completeness than 'stable' versions. He does, however, state that 'stable' versions are not much better than the others, and that is where the problem lies. Sure I do; but each is inflated. Normal parlance is that an alpha release executes, a beta release is feature complete and generally works but with bugs expected to be found, and that a release has been tested. LiveCode's developer previews simply execue (nightly snapshot that executed), the RC are alpha quality, the 5.5 series are late beta, and the 6.x and 7.x releases are early beta. When or if I come to thinking about buying a commercial version of LiveCode I will be in a very odd position, not really knowing whether I am buying a version that is, really, stable, or just something beta-ish labelled 'stable' which will then cause all sorts of unforeseen problems with my product. My attitude would probably be far different if I were using a community version . . . I understand the open source and mixed models quite well, but would be far better off with a fixed and working 5 than what the efforts have been spent on the last couple of years. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
Dr. Hawkins wrote: On Tue, Nov 11, 2014 at 1:34 PM, Richard Gaskin wrote: I'd like to raise these concerns with Ben and Kevin at my next meeting. It would be very helpful if you could point me to the bug reports that describe these issues. That's the problem. These are at a level that never should have seen the outside to be reported as bugs. Hard to say without knowing what the specific issue is. Peter's investigating the SQLite issue (thanks, Peter), and that may be a regression in LiveCode or it may be a change in SQLite itself. There are many changes logged for SQLite in recent builds, so hopefully Peter's analysis will help shed some light on that. Any other specific issues you feel are show-stoppers may well be worth looking into, and I'd be happy to help if I can. But to do that I'd need to know what they are. That something unusual happens under certain circumstances is a bug. That the IDE window regularly pauses for seconds at a time, or stops taking input, is impossible to not notice if you actually use it. Have you considered the possibility that things your app uses regularly may not be used as often by others? This is a commercial product that was released without testing; I think the hundreds of testers who put in thousands of hours testing over the last 8 months would disagree. *that* the paying customers are expected to file bug reports over what should have been done before is the fundamental problem. No one's obliged to test. If having bugs fixed isn't of interest, there's no need to let anyone know when you find them. If you prefer to wait until after release to find out if a build will suit your app's needs, any issues you find will, by definition, be post-release, and can only be addressed in yet another build later in the future. It's a choice we make with complete freedom, with any software, or any product, according to our own needs for such assessment. I never bother reporting bugs for software I don't rely on. But I never buy a car without driving it several miles first. I have, however, added bugs 13997-9 about the failures of the checkpoints in the IDE I saw that - thanks for filing the report. I'm sure by now you got notice that the lead engineer began researching it within 48 hours after you'd submitted it. I suspect this will soon join the other 1,700 reported issues that were fixed over the last year, now that it's been brought to their attention. This particular bug makes a good case study for the nature of testing in all software, whether it's LiveCode, or our own, or Apple's, or anyone else's: A given issue may seem obvious if it's something your app uses regularly, but it's worth noting that after 8 months of testing by hundreds of community members in addition to internal resources both human and automated at RunRev, this issue had never before been reported. I'd never seen it, nor heard anyone mention anything like it. And eight months is a long time. This is one of the tricky things about complex systems: with so many thousands of tokens that can be combined and recombined in nearly infinite variety, the likelihood that the specific intersection of features a given app needs will be easily found by others simply can't be assured. If you want to use a new version, it can help you get any issues that need resolving done before release if you choose to try the pre-release builds. No one's required to test. But many of us choose to do so because it benefits our own goals. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 4:38 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Any other specific issues you feel are show-stoppers may well be worth looking into, and I'd be happy to help if I can. But to do that I'd need to know what they are. That the IDE doesn't work? I filed those bugs, but can anyone really have used the IDE and breakpoints without noticing the hangs, and the inability to set these? And how many years has it been since a current version can watch a global variable without crashing? or the false failures to compile over shadowed names? If I spend a day programming, I have to kill livecode a dozen or more times. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
Folks: Just to chime in on this. I’ve been using version 7.0 for a couple of months. No problems. I’m not using many of the new features like unicode, but have found the IDE working fine for my purposes, so far. The slowdown in some operations has affected me, though. Picking out a byte from a large byte array is slower than older versions. That said, I’m glad you guys are finding the bugs in features I don’t use, because eventually, I will use them. Best, Bill William A. Prothero http://es.earthednet.org/ On Nov 11, 2014, at 4:46 PM, Dr. Hawkins doch...@gmail.com wrote: On Tue, Nov 11, 2014 at 4:38 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Any other specific issues you feel are show-stoppers may well be worth looking into, and I'd be happy to help if I can. But to do that I'd need to know what they are. That the IDE doesn't 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: hair-pulling frustration
Hi Richard, on Tue, 11 Nov 2014 Richard Gaskin wrote: [snip] On the other issues, can you share the bug report numbers so we can follow them? Does exist an automatic way to post every new bug report in this mail list? Could bugzilla do this? In this way, every bug will be noticed and reviewed by all mail list users. Al ___ 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: hair-pulling frustration
Dr. Hawkins wrote:
On Tue, Nov 11, 2014 at 4:38 PM, Richard Gaskin wrote:
Any other specific issues you feel are show-stoppers may well be worth
looking into, and I'd be happy to help if I can. But to do that I'd
need
to know what they are.
That the IDE doesn't work?
I'll run a search for IDE doesn't work and see what I can come up
with. ;)
I filed those bugs, but can anyone really have used the IDE and
breakpoints
without noticing the hangs, and the inability to set these?
Thanks for noting which bugs were concerning you.
The one I had referred to was about the card reference, which has
already been fixed:
http://quality.runrev.com/show_bug.cgi?id=13972
For those following this the breakpoint bugs are:
http://quality.runrev.com/show_bug.cgi?id=13997
http://quality.runrev.com/show_bug.cgi?id=13998
http://quality.runrev.com/show_bug.cgi?id=13999
I did a quick triage on those:
The first one ('97) was especially interesting because in all the years
I'd been using LC I'd never used that particular feature. The
description of that feature on p68 of the User Guide does seem to match
your expectations, and I was able to confirm your report.
The second one ('98) was one that could benefit from others here who've
used the debugger more than I have (Jacque, that means you g). I'm
not sure if it's a bug or merely needs more explanation in the docs.
The last one ('99) I was unable to reproduce, but if there are any
additional steps I can follow to reliably reproduce I'd be happy to
submit my notes there.
And how many years has it been since a current version can watch a
global
variable without crashing? or the false failures to compile over
shadowed
names?
Bug #s?
Anyone else experience those?
There was a recent comment about shadowed name warnings in the Facebook
group recently, but that seemed related to turning on the feature to
warn about those (Prefs - Script Editor - Strict Compilation Mode).
The person who noted the issue reported back that after restoring that
feature to its default off setting he was happy. Is that not working
for you?
--
Richard Gaskin
LiveCode Community Manager
rich...@livecode.org
___
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: hair-pulling frustration
On Nov 11, 2014, at 4:38 PM, Richard Gaskin ambassa...@fourthworld.com wrote: Any other specific issues you feel are show-stoppers may well be worth looking into, and I'd be happy to help if I can. But to do that I'd need to know what they are. Hi Richard, Thanks for taking this on. These are stopping us from using 7 either in shipping applications and in some cases development: Move command renders graphics improperly when screen has been recently locked http://quality.runrev.com/show_bug.cgi?id=13961 Player object should be able to transform video content http://quality.runrev.com/show_bug.cgi?id=13942 (We are currently relying on Trevor’s excellent QT External for this. Thus, this is really an enhancement.) Color overlay doesn't seem to be applied to alpha channel correctly http://quality.runrev.com/show_bug.cgi?id=11520 (Fixed but not released) Command keys not working correctly http://quality.runrev.com/show_bug.cgi?id=13847 This list does not include a serial port communication bug. The general issue is that serial communication is very slow. We rely on serial communication for our remote control system to communicate with the vision testing software. Just need to find the time to build a recipe stack this one. The overall slowness of 7 is also an issue. Thankfully plenty of benchmarking scripts are being created by the wonderful people on this list to show those issues. I personally think there should be more life applied to the 6.7 cycle. This will be important until 7 matures. A quick glance at which engine is used for some of our applications: Live Events Conference App: 6.6.3 20/20 Vision Testing Software: 6.1.1 LiveCloud Servers: 6.6.5 LiveCloud Manager: 6.5.1 Electronic Medical Records (under development): Shooting for 6.7 You might ask yourself why we are using such a range of engines. Why not use the latest or why not use only one or two? Selecting the right engine depends on a number of factors like: Is this for mobile or desktop. Then there are sub-factors like: Media playback features needed, serial port access, graphic overlay use, text manipulation, array features, and various bug fixes that affect your particular app. These are just the ones that come to mind. Best regards, Mark Talluto livecloud.io canelasoftware.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: hair-pulling frustration
On Nov 11, 2014, at 5:24 PM, Richard Gaskin ambassa...@fourthworld.com wrote: There was a recent comment about shadowed name warnings in the Facebook group recently, but that seemed related to turning on the feature to warn about those (Prefs - Script Editor - Strict Compilation Mode). The person who noted the issue reported back that after restoring that feature to its default off setting he was happy. Is that not working for you? I have seen this one too. My quick enough work around is copy the script to memory. Empty the script from the control that is complaining and compile. Then paste the script back into the control. The true issue will properly error at the bottom of the script editor. Fix that issue and compile again. Everything goes back to normal. Best regards, Mark Talluto livecloud.io canelasoftware.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: hair-pulling frustration
On 12/11/2014 11:00 am, Dr. Hawkins doch...@gmail.com wrote: LiveCode's developer previews simply execue (nightly snapshot that executed), the RC are alpha quality, the 5.5 series are late beta, and the 6.x and 7.x releases are early beta. I think that¹s a bit harsh. There are problems with every version but typically only a very small number effect individual users. Like many others I move to a newer version when a new feature that I want has been added or a bug that is holding me back gets fixed. If other problems emerge then I step back and monitor things for a bit longer. I don¹t really care how a release is named, alpha, beta, DP or RC - if it does enough of what I want then I use it. When or if I come to thinking about buying a commercial version of LiveCode I will be in a very odd position, not really knowing whether I am buying a version that is, really, stable, or just something beta-ish labelled 'stable' which will then cause all sorts of unforeseen problems with my product. My attitude would probably be far different if I were using a community version . . . I understand the open source and mixed models quite well, but would be far better off with a fixed and working 5 than what the efforts have been spent on the last couple of years. I guess it depends on what you want the software to do. While things move relatively slowly in the desktop world, mobile OSes are changing rapidly. A stable version 5 would be fairly useless to an iOS developer. I like the fact that LC is evolving - warts and all. If the alternative is what used to happen with Director (maybe still does), where Œstable¹ versions go unchanged for years, then I¹ll go for the LC model every time. Nevertheless, I wholeheartedly agree that it is annoying when you regularly butt up against bugs - old and new - and it would be good to get some useful info on these in an accessible and easily digestible format - that is, other than via the release notes and the bug database. Perhaps if these could be aggregated in some way and added as a Œknown issues¹ item to LC¹s help menu it would be easier for us to decide which version of LC to use and when to make the switch. The identification/verification of major new issues against a version (or multiple versions) or fixes in newly released versions could also perhaps appear as notifications in LC's start centre. Terry... ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 5:24 PM, Richard Gaskin ambassa...@fourthworld.com
wrote:
Dr. Hawkins wrote:
On Tue, Nov 11, 2014 at 4:38 PM, Richard Gaskin wrote:
Any other specific issues you feel are show-stoppers may well be worth
looking into, and I'd be happy to help if I can. But to do that I'd need
to know what they are.
That the IDE doesn't work?
I'll run a search for IDE doesn't work and see what I can come up with.
;)
:)
For those following this the breakpoint bugs are:
http://quality.runrev.com/show_bug.cgi?id=13997
http://quality.runrev.com/show_bug.cgi?id=13998
http://quality.runrev.com/show_bug.cgi?id=13999
I did a quick triage on those:
The first one ('97) was especially interesting because in all the years
I'd been using LC I'd never used that particular feature. The description
of that feature on p68 of the User Guide does seem to match your
expectations, and I was able to confirm your report.
The only reason *I* found it (the feature) was that I was trying to set
breakpoints, and my usual ways didn't work.
The second one ('98) was one that could benefit from others here who've
used the debugger more than I have (Jacque, that means you g). I'm not
sure if it's a bug or merely needs more explanation in the docs.
I suspect it may need someone running livecode itself in another debugger,
or massive checkpoint dumping in the IDE code.
The last one ('99) I was unable to reproduce, but if there are any
additional steps I can follow to reliably reproduce I'd be happy to submit
my notes there.
It seems to be some level of corruption that survives saving and reloading.
And how many years has it been since a current version can watch a global
variable without crashing? or the false failures to compile over shadowed
names?
Bug #s?
Anyone else experience those?
These get discussed here every few months.
There was a recent comment about shadowed name warnings in the Facebook
group recently, but that seemed related to turning on the feature to warn
about those (Prefs - Script Editor - Strict Compilation Mode). The
person who noted the issue reported back that after restoring that feature
to its default off setting he was happy. Is that not working for you?
!!!
No, not having strict compilation can't make me happy; I depend upon such
things. (I don't even like the lack of case sensitivity in names, or the
inability to apply types, but those only bite on the database side, and I
have scripts that watch my stacks for those on every build.
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: hair-pulling frustration
On Tue, Nov 11, 2014 at 5:31 PM, Terry Judd terry.j...@unimelb.edu.au wrote: On 12/11/2014 11:00 am, Dr. Hawkins doch...@gmail.com wrote: LiveCode's developer previews simply execue (nightly snapshot that executed), the RC are alpha quality, the 5.5 series are late beta, and the 6.x and 7.x releases are early beta. I think that¹s a bit harsh. *shrug* That's the normal meaning of alpha beta (for non-microsoft products) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
OK, I'll try with and without multiple statements in both versions. I do want to double check that you're not trying to access an SQLite database over a network because you WILL have major problems if you are :-) Pete lcSQL Software http://www.lcsql.com Home of lcStackBrowser http://www.lcsql.com/lcstackbrowser.html and SQLiteAdmin http://www.lcsql.com/sqliteadmin.html On Tue, Nov 11, 2014 at 3:13 PM, Dr. Hawkins doch...@gmail.com wrote: On Tue, Nov 11, 2014 at 1:09 PM, Peter Haworth p...@lcsql.com wrote: I rarely, if ever, try to execute multiple SQL statements in one revDatabasexxx so haven't seen that particular problem. Could you give an example? I'd like to check it out as I don't want to get hit by the same bug. I routinely execute many synchronize with the remote, as latency is a big deal and stops the single-threaded livecode. SELECT * FROM sometable; worked before the change with SQLite. Now, it is necessary to remove the semicolon. I routinely code the semicolons in because I variously use both direct revDatabaseXxxx calls and my own routine which wraps with Begin/End. That way, I can, err, could, simply write my queries. -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
Mark Talluto wrote: Thanks for taking this on. These are stopping us from using 7 either in shipping applications and in some cases development: Move command renders graphics improperly when screen has been recently locked http://quality.runrev.com/show_bug.cgi?id=13961 Player object should be able to transform video content http://quality.runrev.com/show_bug.cgi?id=13942 (We are currently relying on Trevor’s excellent QT External for this. Thus, this is really an enhancement.) Color overlay doesn't seem to be applied to alpha channel correctly http://quality.runrev.com/show_bug.cgi?id=11520 (Fixed but not released) Command keys not working correctly http://quality.runrev.com/show_bug.cgi?id=13847 This list does not include a serial port communication bug. The general issue is that serial communication is very slow. We rely on serial communication for our remote control system to communicate with the vision testing software. Just need to find the time to build a recipe stack this one. The overall slowness of 7 is also an issue. Thankfully plenty of benchmarking scripts are being created by the wonderful people on this list to show those issues. I personally think there should be more life applied to the 6.7 cycle. This will be important until 7 matures. Very helpful - thanks for posting that list. I've added them to my notes for my next Community meeting with them. The fixed item is good to see, but of course it would have been better to see it fixed before release. Do you happen to know offhand if that was a late-stage regression? The enhancement request seems very useful, though of course it'll likely play a minimal role in a discussion of show-stoppers. The other two are interesting, and I look forward to learning the challenges behind those. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
Dr. Hawkins wrote:
On Tue, Nov 11, 2014 at 5:24 PM, Richard Gaskin wrote:
The first one ('97) was especially interesting because in all the
years
I'd been using LC I'd never used that particular feature. The
description
of that feature on p68 of the User Guide does seem to match your
expectations, and I was able to confirm your report.
The only reason *I* found it (the feature) was that I was trying to set
breakpoints, and my usual ways didn't work.
I've always just clicked om the line number. I know you've reported an
issue doing that while the script is running, but are you also unable to
set the breakpoints by clicking the line number at all?
There was a recent comment about shadowed name warnings in the
Facebook
group recently, but that seemed related to turning on the feature to
warn
about those (Prefs - Script Editor - Strict Compilation Mode). The
person who noted the issue reported back that after restoring that
feature
to its default off setting he was happy. Is that not working for
you?
!!!
No, not having strict compilation can't make me happy; I depend upon
such things. (I don't even like the lack of case sensitivity in names,
or the inability to apply types, but those only bite on the database
side,
and I have scripts that watch my stacks for those on every build.
It seems I had misunderstood. What's the bug report number for that
one?
--
Richard Gaskin
LiveCode Community Manager
rich...@livecode.org
___
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: hair-pulling frustration
On Tue, Nov 11, 2014 at 5:49 PM, Peter Haworth p...@lcsql.com wrote: OK, I'll try with and without multiple statements in both versions. Now, to make matters worse, it appears that I've been using 7.0.0, not 7.0.1-RC-1 for an unknown period of time--it has managed to set itself as the default version more than once on this machine. Anyway, where this bit me was the single transaction with semicolon but without begin/end I do want to double check that you're not trying to access an SQLite database over a network because you WILL have major problems if you are :-) Been, there, done that, silkscreened the t-shirt. Interestingly, though, when simultaneously opened, come of the changes could be read by the other (come to think of it, it wasn't network, but two instances on the same machine). But, no, these are actually :memory: SQLite dbs. (now, I'm *dying* for multi-threading so that the second/slave process can handle synchronization) -- Dr. Richard E. Hawkins, Esq. (702) 508-8462 ___ 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: hair-pulling frustration
On Tue, Nov 11, 2014 at 6:21 PM, Richard Gaskin ambassa...@fourthworld.com
wrote:
Dr. Hawkins wrote:
On Tue, Nov 11, 2014 at 5:24 PM, Richard Gaskin wrote:
The first one ('97) was especially interesting because in all the years
I'd been using LC I'd never used that particular feature. The
description
of that feature on p68 of the User Guide does seem to match your
expectations, and I was able to confirm your report.
The only reason *I* found it (the feature) was that I was trying to set
breakpoints, and my usual ways didn't work.
I've always just clicked om the line number. I know you've reported an
issue doing that while the script is running, but are you also unable to
set the breakpoints by clicking the line number at all?
I filed that as a separate bug. Yes, once it's corrupted enough, it
ignores line-number clicking, which is why I discovered the other. I
experimented, and foudn it.
There was a recent comment about shadowed name warnings in the Facebook
group recently, but that seemed related to turning on the feature to warn
about those (Prefs - Script Editor - Strict Compilation Mode). The
person who noted the issue reported back that after restoring that
feature
to its default off setting he was happy. Is that not working for you?
!!!
No, not having strict compilation can't make me happy; I depend upon
such things. (I don't even like the lack of case sensitivity in names,
or the inability to apply types, but those only bite on the database side,
and I have scripts that watch my stacks for those on every build.
It seems I had misunderstood. What's the bug report number for that one?
To start with, Peter Hayworth filed *Bug 10511*
http://quality.runrev.com/show_bug.cgi?id=10511 in 2006 . . . but wee
discuss this every three or fourt months on this list.
--
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
___
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: hair-pulling frustration
Dr. Hawkins wrote: Now, to make matters worse, it appears that I've been using 7.0.0, not 7.0.1-RC-1 for an unknown period of time--it has managed to set itself as the default version more than once on this machine. If that's on a Mac, I don't believe there's anything a developer can do - that's a long-standing Finder feature, in which it uses rules known only to itself to determine which version to launch whenever a compatible file is double-clicked. For greater control over app versions I put all the ones I use in my Dock and launch them explicitly from there. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
Dr. Hawkins wrote: To start with, Peter Hayworth filed *Bug 10511* http://quality.runrev.com/show_bug.cgi?id=10511 in 2006 . . . but wee discuss this every three or fourt months on this list. I recall only vague descriptions with no clear outcome, and that amazingly long bug report evidences why. Apparently after a very long period of some of the best minds at RunRev and within this community exploring the issue from every angle, only fairly recently did a seemingly reliable recipe emerge, but with Peter's most recent note there it appears the root cause remains as the recipe. Many thanks to Peter, Ralph, Monte, and the others who contributed to that. Good reading about thorough diagnostic process in the face of a problem that for most had been unpredictably intermittent. Hopefully this can be worked out. Interesting problem. -- Richard Gaskin LiveCode Community Manager rich...@livecode.org ___ 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: hair-pulling frustration
For greater control over app versions I put all the ones I use in my Dock and launch them explicitly from there. I¹m sure you¹re not alone there. I have six versions of LC in my dock that I use for different projects and for testing. I have many more than that in my Applications folder. Terry... ___ 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: hair-pulling frustration
On 12/11/14 07:46, Terry Judd wrote: For greater control over app versions I put all the ones I use in my Dock and launch them explicitly from there. I¹m sure you¹re not alone there. I have six versions of LC in my dock that I use for different projects and for testing. I have many more than that in my Applications folder. Terry... I have 13 versions along the 'dock' on my Ubuntu Studio machine, all with differently coloured icons, as I develop my language tools with 4.5 and my educational in-house stuff with anything Open Source. And several versions of MetaCard. I have every version (dp, rc, gm, stable) since the first Open Source release installed as I am just too lazy to take the time to remove anything. SO, I NEVER double-click on a .rev, .mc or .livecode file as that would be like playing Russian roulette. Richmond. ___ 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: hair-pulling frustration
On 11/11/2014, 7:24 PM, Richard Gaskin wrote:
The second one ('98) was one that could benefit from others here who've
used the debugger more than I have (Jacque, that means you g). I'm
not sure if it's a bug or merely needs more explanation in the docs.
For reference: http://quality.runrev.com/show_bug.cgi?id=13998
I added a comment there. It is quite possible (and convenient!) to add a
breakpoint while debugging, I do it all the time. But I have never
right-clicked, I always just left-click normally on a line number and it
works. I just tested it again in 7.0.1 rc 1 and it still works here.
The next bug (13999) mentions a popup that should appear when
right-clicking a line number. I don't see one in 6.x either, and I'm not
sure I remember ever seeing it, though it vaguely rings a bell. That
said, right-clicking on an existing and active breakpoint *does* put up
the expected popup, the one that gives you debugging options. So I don't
see any problems here.
I don't know if the removal of the line-number popup was intentional or
even if I'm remembering it correctly. I may be thinking of the popup
that appears in the Breakpoints pane when you right-click. That one
still works in 7.0.
The last bug (13999) mentions a greyed-out breakpoint and a lack of
responsiveness in the script editor. A breakpoint will be grey if its
script has been edited but not recompiled yet. Since saving a stack will
also save any uncompiled scripts, the grey breakpoint and a confused
editor will persist across relaunches.
An unresponsive IDE was mentioned. The editor and the IDE can both
become frozen if you are debugging and you try to do something else
without exiting debug mode. Not only can you not type into the editor,
which is to be expected, but most of your stack and even the IDE won't
respond either (though the message box still works, and the app
browser.) Almost everything else just stops and you are in a state of
suspension while the engine waits for debugging to finish. The solution
is to hit the blue square to stop debugging, or to hit the Run button to
execute the rest of the handler, and everything picks up again. I've
never seen the IDE freeze up outside of that situation.
We used to get questions in the support queue about that. People didn't
realize they were still in debug mode.
--
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: hair-pulling frustration
On 11/11/2014, 11:46 PM, Terry Judd wrote: For greater control over app versions I put all the ones I use in my Dock and launch them explicitly from there. I¹m sure you¹re not alone there. I have six versions of LC in my dock that I use for different projects and for testing. I have many more than that in my Applications folder. I've only got four in the dock and maybe a dozen in Applications. Have you seen screenshots of the RR team's dock? They must have twenty in there. :) -- 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: hair-pulling frustration
On 11/12/2014, 1:15 AM, J. Landman Gay wrote: That said, right-clicking on an existing and active breakpoint *does* put up the expected popup, the one that gives you debugging options. So I don't see any problems here. I take that back, I didn't test far enough. The popup appears and the dialog is put up, but clicking OK after entering a line number does nothing. So yeah, this is a bug. -- 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
