Re: [Dev] Propose getting rid of developer release

[John Anderson]

Alec Flett wrote: John Anderson wrote: I find the C++ asserts quite useful. In fact, using them over the weekend I discovered a crashing bug that I wouldn't have noticed without them: edit a field in the summary or sidebar and quit causes a crash. I suspect this bug has been around for a very long time. I don't doubt you find them useful. In fact I'm glad you do. But you hack wx! Honestly, if I could consistently reproduce that crash, I would have just filed a bug, and it would have eventually gotten assigned to you or David... that's how the system works. I wouldn't have to run a debug build and I could focus on the calendar. How would you distinguish between chandler crashing when you exit and it quiting normally? They are indistinguishable in the release version, unless you happen to notice that your last change wasn't saved. In the debug version you happen to get an assert. I wish we could get people more comfortable debugging wx because it's a lot more productive than beating your head against the wall when you can't figure why something in wx doesn't work like you expect. I find it very liberating to be able to debug wx, and fixing a bug in wx instead of adding a bunch of python hack to work around it feels good. Now imagine that instead of me, a full-time chandler developer who never uses debug builds, we have Joe Python, who could give less than a damn about wx, and just wants to fix a calendar bug or write an extension. They might not even file the bug, and having a debug build certainly wouldn't motivate them any more to do so - if anything the slowness of it would de-motivate them to work on chandler in the first place. I think that anytime you fix a bug or write an extension -- assuming that it's going to be adopted by OSAF, or other people besides Joe -- it's prudent to test it using the debug version. I'm not proposing that people do all their development in the release version Think of it this way: If I'm developing an end-user app that runs on linux, do I need to run with the linux kernel in debug mode? is it useful for me to catch asserts in the kernel if I'm writing a PIM? No. If in development I happen upon a kernel panic, then I do my best to work around it. And does Linus care about asserts in the kernel? of course he does! If we actually had good coverage testing the debug versions of Chandler like they do for linux debug builds, then I wouldn't be so concerned. But unfortuantely, we have very little testing with the debug builds. The idea I was trying to make by my comment is that if nobody ever runs codes with asserts, what's the point of having them? For my development on windows and linux, spending part of my time running the debug builds has really been worth it in terms of finding bugs. I suspect this works for me and not you might be because I have a faster computer. No, the reason I don't run the debug build is not because I have a 1.6Ghz machine. It is because I DON'T CARE about any of the information that it would give me, so its not worth my time. I don't have to get distracted with all this running-a-compiler stuff that would slow me down every time davids checks in, seeing wx asserts that I don't care about, and I can just type "make install" to get whatever it is I need. To run the debug versions I usually just do the make install DEBUG=1, not doing a full build. So if you don't run debug to see asserts and QA doesn't run the debug versions, then who's going to find an assert if it's caused by your code? But my point is not that my way is better than yours. My point is that my development pattern is the one that we want to encourage pythonic Chandler developers to use, who don't know if wx asserts are important or not, who don't know the internals of wx, who are already confused by the use of "Kind" as a proper noun. I'm VERY glad someone such as yourself runs the debug builds though - because you're fixing valuable bugs. When I file a bug, there's someone there who knows what they're doing and cares enough about wx to fix it. Probably the only disagreement here is that I think making a prebuilt debug verison available to people outside OSAF will be useful in narrowing down problems and/or testing their python extensions. I'm certainly not proposing that we force people to test anything or force them to run any version -- and I'm all for telling people the debug version is way slow. However, if we make it easier for people to get the debug version we make it more likely that people will use it and find bugs for us. Alec Am I missing something? Is there perhaps a mode that the python interpreter runs in that bypasses asserts? if so, we should not be bypassing asserts except in actual releases (i.e. 0.7 itself) Running python with the -O option (optimize) ignores python asserts. The release launchers run -O and ignore asserts. The debug launchers run without -O and pop up everything that goes to stdout to a dialog so it isn't missed by people who don't run in a shell. You can get python asserts if you run Chandler without -O in the release version -- which is how I normally run. Right, that's how I run. I guess what I'm saying is that we don't need debug symbols to catch python asserts. Perhaps only milestones should run with -O, and nightly builds that QA uses should keep -O on. I think I'm confused here. All the version are build so you can run with or without python -O. It's decided by the launcher, or by you if you decide to run Chandler with your own command line arguments, so I don't see how you're proposing milestones and nightly builds differ. Symbols are another story, they are currently included only in the debug C++ libraries -- and yes, I agree they are only useful if you run the debugger or get a crash backtrace. Alec

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev