LiveCode Forums.

Is there a list of currently open bugs anywhere? It seems prudent to know what is still problematical on which system before/during/release while developing for that system.

I suggested this a few months ago. It met with no enthusiasm.

You can just do an advanced search on the quality.livecode.com bug tracker with a choice of the "state" option as everything that isn't resolved or closed or other selections.

Surely this can't be right .. https://quality.livecode.com/buglist.cg ... _id=101320

Erm.... did I hear a bubble just burst?

2382 bugs if you override the 500 limit.

I would be happier if they added nothing to the language for 2 years (they’ll need it) and fixed the outstanding bugs and the IDE.

They can also have just 1 developer working on only plugins and widgets suggested by the community for the same amount of time , voted on but with extra points added when people donate “credits” or money . At the same time if while coding the widgets / plugins a bug is found it takes priority over all others - by doing this the team are really eating their own dog food.

I can see this would mean we won’t get the promised (and paid for) new SQLite framework (and the other stuff I can’t be arsed to list) of nearly 4 years ago but I’m not holding my breath anymore. - forget the rest of the promises.

Oh and before Bernard jumps in to tear me to shreds for whining - I just paid nearly £500 to livecode so I do have some skin in the game.

Regards Lagi

They can also have just 1 developer working on only plugins and widgets suggested by the community

One of the reasons the much vaunted 'community' version was done away with is that, although LC complain about lack of
input from the 'cummunity', the big reports that filed by the 'community' were almost totally ignored; but, now, as the
'community' is a thing of the past, those bugs can be shelved and ignored with even more impunity than previously.

Lagi Pittas wrote: ↑

Sun Oct 10, 2021 1:26 pm

2382 bugs if you override the 500 limit.

Oh and before Bernard jumps in to tear me to shreds for whining - I just paid nearly £500 to livecode so I do have some skin in the game.

Paying customers who point out that bugs need fixing and that promised enhancements are missing are not IMO whining. Those are paying customers with justified complaints. Those who refuse to contribute anything but complain are IMO whining - they will the ends but don't will the means. I spent months on a project which I had to shelve at the final stage because LC does not provide secure sockets, something that was promised 14 years ago (and is even included in the Dictionary as existing).

I have little patience when people demand that the website be re-designed, or more documentation be added, or social media campaigns undertaken, whilst bug fixes/promised enhancements are missing.

Paying customers who point out that bugs need fixing and that promised enhancements are missing are not IMO whining.

NOR, my friend, are those Community users who have donated to the Kickstarters or purchased Indy licences that they did not subsequently use.

NOR, my friend, are those Community users, while having contributed no money have shared know-how and skills,
as well as beta-testing for bugs.

My son, Alexander Mathewson, has hosted a Music festival in Plovdiv, Bulgaria, twice, and during the last one in 2019,
a gypsy street-cleaner gave him 1 lev (that's about 35 cents US) and apologised that she could spare nothing more to help the festival.

As Alexander said, "That's worth more than anything from all the corporate sponsors."

Jesus's widow's mite; https://en.wikipedia.org/wiki/Lesson_of ... w%27s_mite

In the modern world no software is an island. Free Open Source Software makes most of the software world possible, whether the resulting work is released under FOSS license, a proprietary one, or dual-licensed.

This is why Adobe, Microsoft, Oracle, and many other major tech brands are paying members of the Linux Foundation, even as they earn the money to support the project that drives their infrastructure from mostly proprietary software. FWIW Apple's infrastructure also runs on Linux, but they do not appear among the names of contributing Foundation members.
https://www.linuxfoundation.org/join/members/

Inside the LC app bundle is a file named "Open Source Licenses.txt", listing the many FOSS packages LC relies on to deliver their good work to us. I have not seen a list of upstream contributions LiveCode Ltd has made to those projects, nor would I expect to.

People contribute to the things they use in many ways, reflecting their priorities, abilities, and other factors.

As I've said here long before LC went FOSS and during the years they had a FOSS edition, the most important contribution anyone can make to a platform is to simply use it, make great work with it, and when people ask you how you did it tell them.

If one is in a position to also make other contributions, even better. But I would not shame Apple, nor LC, nor any LC user if their contributions are limited to use as the license grants, and the inevitable evangelism that comes from good use.

I'd like to ask that we please refrain from denigrating any member of our community who used the software under the terms it was offered.

Harder than paying the bills when you've chosen to give away a version at no cost is attempting to convert prospects to a platform few have even heard of.

Everyone using LiveCode has always been a de facto contributor.

Let's please leave the FOSS past behind us, embrace the fully-proprietary world we're in now, and support one another by focusing on sharing tips and tools for using this platform well.

Back on topic:

dalkin wrote: ↑

Sun Oct 10, 2021 12:22 pm

Surely this can't be right .. https://quality.livecode.com/buglist.cg ... _id=101320

Your query seems reasonably good, but will contain a great many things that might be outside the scope of your assessment interest.

For example, I don't believe that query differentiates between bugs and feature requests.

And I know from first-hand reading of a great many reports that there's a surprising number that are outdated. There can be many reasons for this, such as issues relating to OS features dropped by the OS vendor, or deprecated features, or things fixed with new enhancements, and sometimes even things fixed in the course of other fixes and no one's had the time to go back through every report to identify other affected reports, test them, and close them.

There are also some that are not trivial matters, and take some deep re-architecture to address. One of those I know of off-hand is one I reported about font init affecting resource consumption in LC Server:
https://quality.livecode.com/show_bug.cgi?id=14115

That report also serves as a good example of how a wide range of factors affect prioritization. While the nature of the issue does indeed affect every CGI made with LC, the effects are not noticeable for most, really only seriously problematic depending on very specific server configurations outside the scope of what LC Ltd can be expected to address. So while it would be great to have it fixed, and doing so would boost performance for every LC Server instance, AFAIK I'm the only one who's even complained about it, and Node.js provided a solution suitable for my needs so I can't say I'm really even affected anymore.

Scope (number of affected users) and severity (how it affects product use) are two of the key factors that affect prioritization. If I'm the only one affected by an issue it may never be addressed, unless I'm in a position to cover the additional engineering cost of doing so.

But that also means that critical issues like crashes and memory leaks tend to get fixed quickly. Even though the number of affected users may be currently small for some such reports, the severity is high and weighs heavily in deciding where it fits in the work queue.

And all along, OS keep pulling the rug out from under LC, with small but frequent changes like iOS tooling interfaces that need to be updated with every iOS version, to infrequent but large issues like changing the entire structure of a delivered app for the Android app store. All those eat up significant time, just keeping up with the constant change across so many OSes.

TL/DR:

Having spent more time with the bug DB than most, I can say the best way to use it to assess fitness in a given area of functionality is to do a search for terms related to that topic.

And many times you'll find that doing a similar search here in these forums, on Stack Overflow, or even the open web at DuckDuckGo or Google, will yield very useful results.

Nothing beats a thorough explanation (except maybe beer), so thanks to everyone who is helping me understand the way the LC world works.