On Sat, Mar 6, 2010 at 10:17 PM, Pavel Sanda <sa...@lyx.org> wrote: > John McCabe-Dansted wrote: >> IMHO we should >> #define EXPORT_in_THREAD 0 > > no we should collect as many bugs as possible for new features.
But we need some exciting new feature to announce with the second Alpha! :P >> #6427. On my machine each threaded export has a roughly 50% chance of >> crashing LyX. We don't need users tell us that EXPORT_in_THREAD is >> broken. We already know it is. Actually, I think I am hitting #6516 more often than #6427. > i dont have those crashes. at least we could identify group of people > reporting the same and try to find what is the common denominator. My first impression was that we had already found the major bugs in EXPORT_in_THREAD and were mainly waiting on fixes, but I guess I don't know that. >> Another thing: will the alphas abort on assertions? > > the default should be yes for all prereleases. > on the other hand its after all choice of the testers what build type > ./configure --enable-build-type=[rel(ease), dev(elopment), pre(release)] > they choose. > >>We know that there >> are some mostly harmless assertions that popup without warning such as >> #6172 >> lassert.cpp(21): ASSERTION y > -1000000 VIOLATED IN CoordCache?.cpp:31 >> There seems to be little gain in triggering a SIGABRT on such >> assertions. > > assertion means we do something really badly and prerelease is good time > to catch it. But we have already caught/reported this bug. I am not sure how making a users window disappear would help us further. It seems that a dialog box allowing the user to choose what to do on a case by case basis would be nicer than the LyX window disappearing without any warning. Is there a disadvantage? >>If we do not want these assertions being buried in some >> xsession file no-one reads, perhaps we could modify LASSERT to popup a >> dialog like the following.: > > if they find reproducible assertion, the recipy is enough; if its not > reproducible > then assertion msg itself is usually not much useful... Well how about the search option? As a tester an option to quickly tell whether a bug has already been reported would seem quite useful. Also the report option could inform the user that if they do not know how to reproduce the bug they need not report it. FYI, I have search and report links in keytest like this: http://gmatht.homelinux.net/xp/html_out/out/t4/html/ The report fills in a "How to reproduce" stub that may also encourage the user to look for a way to reproduce. (Since I am currently the only user of keytest this is hardly necessary for keytest yet). -- John C. McCabe-Dansted
