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. 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. 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! 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. 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. Alec 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.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.
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
