Well, this Friday night I spent part of my evening over at Elissa's house. She's really stressed lately so I gave her a nice back massage. She seemed to appreciate the stress-relief.
Then I came home (about 9pm) and proceeded to work. I promised Mars I would give the new debugger a good pounding this weekend to find as many bugs with it as I could. I then proceeded to find 13 bugs in 20 minutes (only 5 of which were debugger related).
This makes me wonder why we even bother having a betas program. The bugs I am finding are very simple to find -- anyone starting a new project could find them just as easily. Or even testing existing projects! For example:
- A thread on a window means your application won't compile.
- A dictionary in your project causes failed assertions on launch.
- When making a new method that returns an array -- the declaration gets munged when the return field loses focus.
And there are other ones that are just as easy to run into that I found as well. And this is just in my first 20 minutes of playing with the new release.
You would think that for all the whining some of our beta testers were doing over the last few days we would get more reports on this stuff.
Oh well, time to get back to work. I still have to give the debugger a thrashing!
I think a good number of people on the beta list are there just to see the latest releases.
The reason I don't report any really obvious bugs is because I assume people already reported them! The online feedback system is a bit hard to wade through. Also, I only really test existing projects, which for the most part don't work at all yet, mainly because Mach-O apps crash on launch.
Hey, where's your new remote debugger stubs? I want to test them! ;-) Yesterday's release doesn't seem to work with the old debugger stubs.
Which says to me that those people need to be removed from the list. If I had my druthers, I'd kick everyone off the list who hasn't reported a bug in the last two alphas. There's over 300 people still waiting to get into the betas program who would probably be happy to report bugs for the chance to keep beta testing... But that's just a crabby me. ;-) At least I woke up this morning to see about 20 more bugs reported.
Never assume someone has reported an issue -- ever! I just heard of an issue this morning (not reported, of course) about someone who can't build because of menus. This is the first I've heard of it! And two other people popped up and said they've been having the same problems for a number of alphas! Ack! Tell me so I can fix it!
As for the remote debugger stubs, those will be made available for the next release I suspect. There's still a little bit of polish I have to put into the IDE side of things. Remote debugging is *not* meant to work with the old stubs (which is why we don't discover them either) because the whole protocol was rewritten. I plan on writing up a post mortem about the entire remote debugging process for giggles. Partly so people understand how it works, and partly so people can learn from my mistakes on how to design a protocol. :-P
Oh yeah, and if you're wondering how I plan to spend my Saturday -- I figure I'll go into work today and see just how many of the 20 bug reports I added last night + the 20 new bug reports from others I can get fixed today.
Yeah, I wonder about that too. It's immensely frustrating to hear people go on about how they're just waiting til we get the obvious bugs fixed before they start testing, and then it turns out that the "obvious" bug they're waiting for is something that's never been reported, that none of us knew about. GRR!
What shocks me is how little they bother listening to us. We tell people to report the bugs and send sample projects in, and we still get asked "Should I report this?" The one that bothers me most is when people take the time to report the bug and they put "run my project" as the steps to reproduce -- and don't include the project. If you're going to take the time to report something, why don't you give us the means to reproduce the issue?
You shouldn't be shocked. Many of the participants in the alpha/beta program were told repeatedly "don't report that" or "we're not interested in that", though exactly what RS was interested in was not entirely clear. I for one do not like spending a few of my hours isolating a bug in a product for which I have paid a few hundred dollars only to be told "don't bother".
As for failing to include a project -- here's how it has happened to me. I fill out a bug report and attach a project. Form validation fails because I forgot to set an operating system. I do so, and send again, having failed to notice that the example project icon is no longer at the bottom of the page. Okay, I can attach the file when the web site prompts me for it again. But I suspect other people think "oh I already uploaded it; this is a glitch".
I'm sorry, but we've had one mantra this entire release -- if it's not in the known issues or UI-related, report it ASAP. And until this release, we've only gotten a few hundred reports (most of which are ones RS employees have entered). This is the first release where I feel like the product is getting any testing.
And you're right, that web page bug needs to be addressed -- I can see that catching a lot of people. Of course, I can also see a lot of people just not bothering to upload projects as well. To be honest, there are some people who just understand how to test and when they file bug reports, we take note and fix them immediately. And there are others who just never quite seem to get the concept. I'm sure it's like that everywhere in the world though.
Sometimes it's a matter of quality vs quantity.
I know that a good bug report needs a very clear explanation and a simple way to reproduce the problem. But I may not have figured out the root cause of the symptom and so i don't report it until I have more info. Are bug report that just list the symptom useful, unless we can also provide a way to reproduce them???
I also had the Nil MenuBar problem yesterday, but all I knew at the time was that I was getting a long list of compile errors in my EnableMenuitems events. I didn't know why, and frankly I didn't even remember that the app class has a MenuBar property since I've never needed to change it. After I learned from the list that this problem was related to the MenuBar property, I was able to do further testing and submitted a report that the bug was related to loading projects in general and not just importing 5.5 projects. (Hope it helpled a little.)
I'll admit that I'm stuck on another problem that I haven' t reported yet. I get an error complaining that I have an Event with the same name as a Property. Since the only location info is , it makes it hard to track down in a large project. And since this is more of a partially implemented error reporting feature (ie not a bug) I'm assuming (hoping) that it's already on your list of things to address since the issue of better error reporting has been beaten to death on the list.
If you want us to do more bug reporting then it would be well worthwhile to shore up the error reporting to help us help you better. :-)
To be honest, at this point, if you're running into errors, you should be submitting your project that demonstrates the error. The projects we throw at it compile without a hitch, so we're sitting here wondering what everyone is talking about. I see these comments on the list that say projects don't compile for this reason or that, and I look in the bugbase and see no feedback about it. When I see that, my first assumption is that the user simply made a mistake somewhere and fixed it on their own (ie -- it's not really a bug).
For your project, you could strip out as much as you can to narrow down what class causes the issue and send us the stripped down project. You don't have to know why it happens (but if you do, it's nice) -- we can figure that out while fixing the issue. :-)