How can we help Xojo to eliminate bugs?

Each one of us has “pet bugs” that affect our particular Xojo use cases, and I can’t help but wonder why the staff at Xojo hasn’t thought to parcel-out routines to motivated Xojo users (under NDA) to analyze and correct the bugs that they have an interest in seeing fixed?

I’m not talking about open-sourcing Xojo’s code but rather giving individual users an opportunity to fix specific routines that are broken. Once the routine is fixed it could be submitted back to Xojo for evaluation and possible inclusion into the canon of Xojo code. There are several routines that I’ve come across that would be worth my time to sort out if given the opportunity.

Is this even a remote possibility?

Considering the fact that a brand new engineer needs at least six months of exposure to the IDE and frameworks before they have enough information and experience to start altering code without breaking other things, what you are suggesting really is a non-starter.

The best thing you can do is file good and complete bug reports and feature requests up front so we don’t need to ask for more information. What I mean by this is:

  • Framework bug reports need to have an example project that shows the issue and nothing else. Most of all, don’t make us take 15 steps to show the problem when two will do.
  • IDE bug reports need to include a project with consiste instructions or a step by step video.
  • Feature Requests should include a description of the problem you are trying to solve as opposed to just telling us how to fix it.

Something else that I’d like to point out, which I know that many of you already know, is that just because a feature request gets filed doesn’t mean that the item will actually get implemented. We get more than 50 feature requests per month. Please remember that not every idea that we get from users fits into our master plan or adds enough value to enough users to warrant adding it to the product. If someone closes a case as Won’t Implement, it’s not just one person’s decision, but our system doesn’t have a way to say “closed by engineering” or “closed by administration”.

Very clear information Greg, thank you, now I know why my feedback is not liked, it is not done correctly.

Are you interested in Apple crash dumps? For example, under a specific set of circs my app crashes (segmentation fault) some time after quit, indeed even after Application.Close is called. If Xojo can tell me what the Framework is doing at the crash, I might be able to reproduce it in a simple project. Happens in all versions from 2019r1.1 to latest test build of the IDE.

Crash dumps are useful as additional evidence, but are rarely useful in a vacuum. It’s just looking at a stack trace like you would a Xojo exception. It doesn’t say why something is wrong or how to reproduce it, just a very vague what is wrong and where.

When I was with Xojo, I would tell people “make it easy for us and it’ll get fixed.” We’d like low hanging fruit. Greg’s advice is excellent.

I would hope that Xojo isn’t such a tangled mess that individual units of code that operate over a very limited domain of data can’t be extracted and modified without breaking code outside of that domain. That is usually an indication of trouble ahead as the codebase grows. 'Nuff said. It’s your baby and you’ll have to deal with it.

By the time this crashes, all my code - or opportunities for me to even include code - are done and dusted. All I can say is its something to with menus - menus that are empty when the app starts and whose menu items are created at runtime.

After Application.Close, I assume the Framework is busy destroying items and generally unwinding everything. A hint as to where it’s at at crash time could be very helpful.

It’s a huge and complicated project. Sure, there are always things that could be better organized, but those bring new challenges. I don’t want to reveal too many specifics because I shouldn’t, but a good example of this is how controls are rendered. With the desktop controls, their rendering and data organization are all handled by the same class. For every single control. That might sound like a mess, but it works because the OS is doing pretty much all of the heavy lifting. When the web controls were introduced, that wasn’t going to be practical. So there are difference classes for each control, because each needs it’s own rendering code. Two controls can interpret the effects of a style differently, for example. This sounds good on paper, but presented problems loading projects because now each view needs to know the full project hierarchy before it can create its controls. With desktop, it could just create the control object and worry about the specific control’s super later.

Understanding that these differences exist and WHY they exist are what takes all the time. It’s absolutely possible to fix little things in the IDE sooner, but it takes a lot of time to truly become productive.

[quote=489813:@Wes Westhaver]Each one of us has “pet bugs” that affect our particular Xojo use cases, and I can’t help but wonder why the staff at Xojo hasn’t thought to parcel-out routines to motivated Xojo users (under NDA) to analyze and correct the bugs that they have an interest in seeing fixed?

I’m not talking about open-sourcing Xojo’s code but rather giving individual users an opportunity to fix specific routines that are broken. Once the routine is fixed it could be submitted back to Xojo for evaluation and possible inclusion into the canon of Xojo code. There are several routines that I’ve come across that would be worth my time to sort out if given the opportunity.

Is this even a remote possibility?[/quote]
If only. I’d love to have a crack at fixing the various regressions in performance that the IDE has suffered from over the past 2 - 3 years.

That’s a really good example of this very problem because I just tackled one of these last week. It would be really easy for an unfamiliar user to find where the problem is and add a lookup cache, but without having the extended knowledge of the rest of the IDE, you wouldn’t know that there are certain circumstances where you cannot use said cache and doing so could risk subtle project corruption. Not just the IDE, but end-user projects. This is part of the reason that new engineers have a break-in period where they work in a branch and checkins are reviewed.

I’m not saying “no” to be mean, I’m saying that what you’re asking for just isn’t practical given the learning curve of a project the size of the IDE.

[quote=489842:@Greg O’Lone]That’s a really good example of this very problem because I just tackled one of these last week. It would be really easy for an unfamiliar user to find where the problem is and add a lookup cache, but without having the extended knowledge of the rest of the IDE, you wouldn’t know that there are certain circumstances where you cannot use said cache and doing so could risk subtle project corruption. Not just the IDE, but end-user projects. This is part of the reason that new engineers have a break-in period where they work in a branch and checkins are reviewed.

I’m not saying “no” to be mean, I’m saying that what you’re asking for just isn’t practical given the learning curve of a project the size of the IDE.[/quote]

https://forum.xojo.com/58472-slow-and-not-functional/p3#p475380

This one, in particular, would be my top priority. I am not sure what more information I can provide to help get it fixed. Looking at profiler dumps, it appears that it’s missing the cache somehow and causing direct file access each time the navigator is scrolled.

Scrolling the navigator up and down once cause tons of filesystem access. (2019r2+)

You can see it is way less in 2019r1.1 or lower.

some reasons for bugs:
a bad day
stress or disturbances
peoples mindset
private matters / worries
publish untested
the development language tend to chaos

sure other OS changes / updates / drivers
different runtime versions

[quote=489842:@Greg O’Lone]That’s a really good example of this very problem because I just tackled one of these last week. It would be really easy for an unfamiliar user to find where the problem is and add a lookup cache, but without having the extended knowledge of the rest of the IDE, you wouldn’t know that there are certain circumstances where you cannot use said cache and doing so could risk subtle project corruption. Not just the IDE, but end-user projects. This is part of the reason that new engineers have a break-in period where they work in a branch and checkins are reviewed.

I’m not saying “no” to be mean, I’m saying that what you’re asking for just isn’t practical given the learning curve of a project the size of the IDE.[/quote]
I’m sure the IDE is a very large project but could the learning curve be more to do with the state of the IDE’s code and not it’s size? We have a large system split over Xojo, PHP, Javascript, Perl & C which is by no way perfect but we have developers making contributions after a much shorter period of time.

I think there are a lot of talented and passionate Xojo users who are getting extremely frustrated by the downward spiral in quality and lack of progress on things that matter to them. I’m sure a lot of us would love to help make Xojo better but all we can do is log cases in Feedback knowing fine well that we are probably wasting our time.

Perhaps it is, but as Xojo is a closed system, I can’t really discuss that in detail.

We can’t please everyone all the time, but have you looked at the release notes of any of the main releases in the last year? In addition to new features, we routinely fix a high number of bugs. Yes, as Thom said, they’re sometimes low-hanging fruit, but sometimes what defines “low-hanging” is whether it’s easy to reproduce.

I’m sorry that this is frustrating for you. I review a lot of cases each week, Old and new, just to see if they’re in or around the code I’m working on for any given day to consolidate my efforts, so to me, filing reports is the best way to get things looked at.

[quote=489889:@Greg O’Lone]Perhaps it is, but as Xojo is a closed system, I can’t really discuss that in detail.

We can’t please everyone all the time, but have you looked at the release notes of any of the main releases in the last year? In addition to new features, we routinely fix a high number of bugs[/quote]
We always look at the release notes for the pre-releases & releases in the hope there are significant fixes or enhancements. Unfortunately, since 64 bit there has been very little that has been relevant / useful for us.
Any improvements made in the past year are actually worthless at the moment as the code editor is now so unresponsive we cannot use anything later than 2019r1.1 (even that is slow compared to older versions).

And we users find an ever increasing number of new bugs that is far higher than what you can fix.

Yup!!!

In the last years I asked to Xojo Inc. if we could help.
But they don’t let someone like me on the code.

I know someone needs to review change suggestion, but I bet I could help my clients more if I could look into code and debug directly. Currently we have too often use lldb or Visual Studio’s debugger to look for problems.
Or provide complete our own implementations of functionality to work around framework bugs.

I do not doubt that the IDE is a very complex project so probably only very experienced Xojo-engineers should touch it.
The most bugs are not related to the IDE. For example bugs in TextOutputstream, Textinputstream, FolderItem, Database plugins, Serial connection, Datatypes (like String, Currency, Date, etc.) etc. There surely are Xojo users who could help fix bugs in these items.

Do you remember the currency math bug we had to use decompilers to figure out the xojo framework/compiler was using wrong instruction and got wrong result?
That one got fixed :slight_smile:

A bug in a data type, reported and verified on 2015 and fixed until 2018 when you tell them how to :expressionless: