LC8.1 crashes on Color Palette; please confirm

[sritcp]

LC 8.1 stable (on Mojave 10.14.5)

1. Create a stack
2. Drag an object in (rectangular graphic, text field, ....)
3. Open object inspector; click on background color
4. Color palette opens; you can set a color or simply click "Cancel"
5. LC crashes.
(You can set the color by script without a hitch).

Could you confirm if this is an actual bug?

Thanks,
Sri

[FourthWorld]

Version 8.1 is more than three years old, with many bug fixes in the engine since. You might try that recipe in the latest version, 9.6dp2:
https://downloads.livecode.com/livecode/

[jmburnod]

Hi,
Color palette works as expected with LC 9.5.0 stable on OS X 10.13
Best regards
Jean-Marc

[sritcp]

Version 8.1 is more than three years old, with many bug fixes in the engine since. You might try that recipe in the latest version, 9.6dp2:

Richard:

I was under the impression that newer versions are more liable to be buggy and are more suitable for people who know what they are doing (especially, developer previews), and that older, stable versions are more proven and reliable, if less feature-rich! Given that I am a hobbyist, I steer clear of DPs. Evidently, I am mistaken!

Is there a downside to using LC9.5 vs LC8.x (other than slower speed)?

Thanks,
Sri

[sritcp]

Color palette works as expected with LC 9.5.0 stable on OS X 10.13

Thanks, Jean-Marc!

[SparkOut]

Is there a downside to using LC9.5 vs LC8.x (other than slower speed)? 

There ARE some regressive bugs in existence, such as https://quality.livecode.com/show_bug.cgi?id=20707 which have yet to be dealt with. However, unless you are particularly hampered by a particular problem, it is usually best to be on at least the most recent stable release. There are generally more fixes than problems introduced. IDE performance has particularly improved in the latest DP on Windows. (I have seen some new reports about Mac IDE performance deterioration though.)
The more people who use DP editions and REPORT ANY BUGS the better, as that is the best way to get action on fixing any problems. (It is sometimes disheartening that if a bug isn't immediately squashed then it seems like it gets left in the list while lower-hanging fruit is picked.) That being said, I think it is mostly heading the right way for the newer versions to be the best suggestion for all users.

[FourthWorld]

I was under the impression that newer versions are more liable to be buggy and are more suitable for people who know what they are doing (especially, developer previews), and that older, stable versions are more proven and reliable, if less feature-rich! Given that I am a hobbyist, I steer clear of DPs. Evidently, I am mistaken!

I generally use the latest DP for day-to-day work, and ship with the most recent Stable.

As you've discovered, if an issue from an older version has been fixed, you'll never see that fix if you stick with the older version that contained it.

From time to time you will see regressions, as you will with any software, esp. in a code base with nearly a millions lines in it. But think about it: if the number of regressions exceeded the number of fixes, no one would be using LiveCode. What we see instead is that LiveCode is steadily moving its way up the TIOBE Index of programming language popularity, and most newcomers use the latest version. This anecdotal observation is reinforced by direct hands-on experience, and reflected quantitatively in the progress observable in the bug DB and in GitHub pull requests.

One of the key advantages of doing daily work in the latest build is that if you do stumble across a regression it'll likely be fixed very quickly. At that point the team member who introduced it still has the code fresh in their mind, is probably still working on it, and the team gives a high priority to new bugs introduced in the version being developed.

If you wait until after it's final to see how well a given version works with your app's requirements, that choice guarantees it won't be fixed before it goes final.

And if you find an issue in an older version, you'll need to test it in the current version anyway before submitting a bug report.

Since v8.1, I'd estimate more than 150 issues have been fixed. And I'd guess the number of regressions is less than 3% of that.

As for speed, the v8 series is among the slowest ever, with the possible exception of some features under v7. The v7-8 series took on the Herculean task of completely revising all text handling to support modern Unicode encoding. As with PHP, Python, and most others, the first pass at Unicode adoption meant a loss of performance. And like those others, subsequent optimizations have regained a lot of performance. LiveCode's v9 series represents the current state of those optimizations.

[sritcp]

Thanks, Richard and Sparkout! That certainly changes my perspective!

Two points, though:
1. Regressions vs fixes: You can’t weight them equally. It is one thing not being able to do something to begin with (existing bug or lack of a feature); it is an entirely different matter if my existing program (which I am using every day) suddenly acts up due to a regression. You have to scramble to put out the fire — which brings me to my second point…

2. Developers vs hobbyists: As a hobbyist, I lack the expertise as well as the constant touch that is required to deal with situations when what was working suddenly breaks. Just to diagnose the problem may be out my range of expertise and time availability. About a year ago, I remember an incident on the usenet when an experienced programmer went into a panic because LC wouldn’t do what he thought it could. Not exactly the situation we are discussing here, nevertheless it made an impression on me.

I have been managing online workshops (taught by my wife) for 10 years now, using an LC program I wrote on the mac. I use it from promotion, registration, payment, AR, pre-workshop communications to CEUs, historic data, and everything in between! I find it a snap to manage 3000 alumni records, and it has saved me a lot of trouble in terms of both speed and accuracy. The point is that, I am out of touch with LC for weeks at a time, may be longer. But when I need to do something with the program, I can get up to speed in no time, thanks to LC’s intuitive logic, English-like language, and my discipline in descriptive naming of variables and comprehensive annotation. I don’t know much about other programming languages, but I doubt I would be able to do come back cold and and pick up where I left off with minimal effort with any other language. This why I have a lifetime Indy-license. (I am at a point where I am trying to write an iOS app; this brings additional issues, thanks to Apple — compatibility between LC, Xcode, and MacOS versions!).

Anyway, just thought I’d share some background that shows LC users come in many shapes and sizes. A user like me couldn’t do this without the active support of forum members such as yourself.

Now, off to the download page for 9.5 stable (not yet brave enough for 9.6dp2 !!)

Thanks,
Sri

[SparkOut]

Re: regressions vs fixes

I didn't mean to suggest that there are a lot of regressions in later versions, I just didn't want to convey the blinkered view that newer versions are guaranteed not to have problems. By and large, newer = more fixes. It's just that there could be a reason why a specific older version is needed, but generally it is better to go for the most recent base version, and for quality control feedback, it's helpful to try the latest DP.