LiveCode Forums.

Livecode 9.5.0 "stable": HA HA!

Recipe?

Without that no diagnostics are possible.

I am still in 9.0.4, and only have a crash every few weeks. Same with 8.x.

Not stable like HC, which never crashed, but when I am happy with a change I make in a LC stack, I rush to save it. That says something.

Craig

Hi All,
No crash for me (LC 9.5.0, OS X 10.13)
Best
Jean-Marc

dunbarx wrote: ↑

Wed Oct 23, 2019 6:13 pm

Not stable like HC

Not at all, and quite consciously so: the LC team is using the term "stable" not in a colloquial sense, but in a software engineering sense common with many large projects.

No non-trivial software can claim to be bug-free. And none do. Every major application, every operating system, all major software projects ship with bugs, and some are even crashers. Including HC. While it's great that you had the fortunate experience of never encountering a bug, those who've worked in tech support for HC can tell a different story. This doesn't mean there's anything all that bad about HC, merely that it's a complex work like all other complex works, and complex works always have bugs.

In engineering, a software in labeled "stable" when no further new features will be added, and all reports against new features in that build have been addressed. It is the state of feature development being labeled "stable", not to be confused with an unsupportable claim of having verified robustness of all possible combinations of features on all possible combinations of hardware, OSes, etc.

This is why I spend most of my time with the latest builds whenever they become available: if I find a bug in a DP build it can be addressed before it goes Stable. If I put off my testing until after Stable, I would be making the only choice that guarantees postponement of the fix until the next version.

FourthWorld wrote: ↑

Wed Oct 23, 2019 7:34 pm

if I find a bug in a DP build it can be addressed before it goes Stable.

Considering some of the dates on some of the bugs I've seen in the db, I'm sure "can be" should be interpreted with a grain of salt, like hitting the lotto.

And before anyone goes off, or gets the wrong impression, I am not saying that in an unkindly or even sarcastic manner, nor is it a swipe at anyone.

bogs wrote: ↑

Wed Oct 23, 2019 8:09 pm

FourthWorld wrote: ↑

Wed Oct 23, 2019 7:34 pm

if I find a bug in a DP build it can be addressed before it goes Stable.

Considering some of the dates on some of the bugs I've seen in the db, I'm sure "can be" should be interpreted with a grain of salt, like hitting the lotto.

And before anyone goes off, or gets the wrong impression, I am not saying that in an unkindly or even sarcastic manner, nor is it a swipe at anyone.

Not at all. Legacy bugs are a valid concern. What you see there is merely my attempt at brevity, having defined "Stable" earlier as the fixing of bugs reported against new features introduced in that version.

The core issue here isn't as much the process, as the use of the term "Stable" in a specialized sense. I just filed a bug report for that, suggesting an alternative would solve many both perceived and actual impediments to the QA process:
https://quality.livecode.com/show_bug.cgi?id=22423

With the process itself, imperfect as such things are industry-wide, I've found almost no one who takes serious exception for how it's practiced at LC Ltd. Once all relevant factors are taken into account, while we all strive for and contribute to ever-improved quality, no one has presented any viable alternative that's substantially different from what the core team is already doing.

But as long as "Stable" is used to describe a build that cannot logically assure stability in the colloquial sense, the word will from time to time be weaponized in complaints, taking time and energy away from actually reporting and fixing bugs.

Totally subjective thoughts below:

FWIW, I find 9.5 the most "stable" of the 9.x series.

I use Windows almost exclusively. There is a recurring impression I found that some feedback suggests that most development and testing is on Mac and occasionally Windows anomalies are not caught as they don't present consistently enough for the development and testing time allocated to Windows. This may be erroneous, and not meant to suggest that I feel like Windows issues are given 2nd class treatment. (Well, apart from pre 1970 date/time handling, anyway.)

I know that recent versions have made a goodly number of fixes to memory leaks in particular that are difficult to provide a recipe for. There are still a number of anomalies and problems that occur at seemingly random intervals but I do feel that things are in one of the upturns for fixing stability issues.

I think the development team is doing a good job generally. In my opinion, a slightly greater focus on older bugs versus introduction of new features (which may then need debugging) would be desirable. The trouble is, the goalposts are constantly moving, and it's not possible for the team to hold back from keeping up to date with changing compliance with O/S requirements.

Interesting bug report, but I'm not sure how it resolves expectations.

From Lc's dl page (emphasis mine):

Below are links to all releases put out by the engineers at LiveCode.com. All versions of LiveCode have been provided including 'release candidates' and 'developer previews'. If you are new to LiveCode we recommend starting out by downloading the latest stable release.

STABLE - These releases are stable public releases.

If you changed the word 'stable' to any of the following...
"Final"
"Release"
or something else that better reflects **common colloquial use
**{Not sure what your defining as the "colloquial" use?}

...People who download it would, I imagine, expect what they expect now, that it is free of major bugs, not that it is completely bug free.

When I say 'major bugs', I am not talking about a mis-placed comma in a label of the IDE, or even an anomaly happening when you open a message box with no stack open, which would certainly be a bug but doesn't stop you from producing software (i.e., not a show stopper).

I am talking about an IDE that has a bug severe enough to crash multiple times in a coding session, or a bug that causes the IDE to slow down to the point it is un-usable (say by introducing a 3-5 second wait into the editor just because you have the project browser open), or the great and longstanding breakpoint issue in the debugger
- AND -
those things aren't fixed not just by the next release, but after several releases (or longer), then people *might* come to just the conclusion you dearly want to avoid.

I am not saying anywhere in the above that this is (take your pick) -
easily resolvable
penny ante
someone specifics fault
cheap to fix
not time consuming
not desired (from a company standpoint, not just the consumer base)

but to say that 'stable' shouldn't mean that you can expect the software to be reasonably stable, I'm not sure that makes any kind of sense.

* Disclaimer - I have done many years of alpha and beta software testing several years ago, for many companies, including (but not limited to) Blizzard, EA, Borland, and even MS. I have never heard anyone at any of those testings refer to stable as anything other than software considered reliable enough for general use. The definition your applying to 'stable' to me is the definition applied to a RC, generally this definition -

RC - Short for "Release Candidate", these releases are feature complete and have been made public to allow LiveCode developers to test whether they think the release is stable.

I'm not suggesting that changing the label will fix bugs. My report is merely noting that the engineering use of the word is out of alignment with colloquial use.

What will fix bugs will be for more people to use the latest DPs and report issues they find in their work BEFORE it reaches Final/Stable/WhateverWeCallIt.

That, and bug fixers. Which either means hiring more staff or encouraging more pull requests from the community.

When discussing specific bugs it's especially helpful to note the bug ID, or even more conveniently include the URL, so we can assess progress.

For example, I can recall several issues with red-dot breakpoints, and AFAIK they've either been fixed long ago or are currently in progress for the next release.

That said, it's been a few months since I did a comprehensive inventory of outstanding issues, so if you have one in mind that doesn't fall into those categories it would be useful to be able to see where it got stalled, and perhaps find ways to move it forward.

OSX 10.14.6 LC 9.5.0 stable
Most of my crashes, happens on clicking on the script editor. I must say that I have 2 clocks updating every seconds with send...but I do clean behind me and crashes happens also while the clocks are stopped

My daily work:
Modify script
save
Modify script
save
Modify script
save
...
crash
and so on...No recipe. Same on 9.0.x Cannot go back to 8.x
I sent the crash reports, but quality say that they are useless to understand the culprit (what is their use then?)

I am not entering the discussion on the use of the "stable" word, since I know too little and LC is the only language that I use.
But my opinion is that since Livecode is not only an Application, but is an Application used to build Applications, it should be more bug free then average, targeting the stability of a Photoshop.
Without that, a developer alway have to imagine if a bug or crash is its fault or the fault of the development environment.
Not to speak of the many leftover bugs like "poperty profiles" (estensivly used in multi language), undo, copy and paste, fill gradient, the project browser, the "inclusions" that cannot be sorted and have have no explanation of any kind, the LC guide without a seach mode, etc, etc.

I think the development team is doing a good job generally. In my opinion, a slightly greater focus on older bugs versus introduction of new features (which may then need debugging) would be desirable.

Coudn't agree more.

Sorry for the rant
Trevix

FourthWorld wrote: ↑

Wed Oct 23, 2019 10:05 pm

I'm not suggesting that changing the label will fix bugs.

I didn't say or imply that you suggested any such a thing. The only way to fix bugs is as you state above. Well, the only way I know of anyhow.

You managed to post while I was writing this one heh.

For example, I can recall several issues with red-dot breakpoints, and AFAIK they've either been fixed long ago or are currently in progress for the next release.

I've never encountered it myself, but I saw the history on how long it was around. The point I was making was just that, how long it took to resolve it, nothing more, nothing less. I could, I am pretty confident, come up with several bugs that are still ongoing and have been since 2013 (or earlier) that I would consider to be more (and less) major bugs. Are you asking me to do so? It shouldn't take more than a couple hours. The table cells one comes to mind off the top of my head, but just to use that as an example, even that one I don't consider "MAJOR", as it takes a very specific course to reach it your unlikely to hit in regular coding.

If I remember correctly, Craig found it (and also figured out a work around for it). I consider his ... research I guess you'd say, to be fascinating. The man is a one man edge case bonanza. Stunning

trevix wrote: ↑

Wed Oct 23, 2019 10:11 pm

OSX 10.14.6 LC 9.5.0 stable
Most of my crashes, happens on clicking on the script editor. I must say that I have 2 clocks updating every seconds with send...but I do clean behind me and crashes happens also while the clocks are stopped

My daily work:
Modify script
save
Modify script
save
Modify script
save
...
crash
and so on...No recipe. Same on 9.0.x

Do you use breakpoints in the Script Editor?

There is a known issue with that, and it fits the frequency you describe. I believe that fix may have been addressed in the recent 9.0.5 build, and will be in the 9.5.1 build coming up soon.

If you're not using breakpoints, we might be able to pinpoint it if you can find any pattern at all to how the crash occurs. Extra bonus points if you can get the crash logs to add to a bug report when we're at that point.

Cannot go back to 8.x

With Save As you can revert to any stack file format used over the last 10 years or more.

But with so many enhancements, optimizations, and fixes between 8.0 and 9.5, there's little benefit in doing so.

Let's see what we can do to get this one bug squared away so you can get back to enjoying all the other fixes.

Bogs.

I've never encountered it myself,

The failure was always intermittent; you were lucky, I guess. This has driven me nuts for years, and seems to have been fixed in v9x.

Craig