|
From: Vampire <Vam...@gm...> - 2007-12-21 18:48:37
|
SVN is a _Source Code_ Management tool, not a _Results_ Management tool. You also do not put the warnings that javac produces into SVN. Or the warnings that javadoc produces. SVN is for source code, and not for results of a tool that is run on the source code. At least that is my opinion. It is not so hard to download and run FindBugs. And for the muuuch time it needs, hey, just start it, go to dinner or lunch and then work on the results when you come back. ;-) Shlomy Reinstein schrieb: > There are two reasons why I think it's useful to have the findbugs > output in SVN: > 1. jEdit is a relatively large project, and it takes FindBugs a lot of > time to process the entire jEdit source code and generate the results. > 2. If the output file is checked in, it's enough for one developer to > run it and keep the output file updated in SVN from time to time; no > need for all developers who want to fix these problems to install / > download / run FindBugs. > > Shlomy > >> The output should not be added to SVN. You can get the output by running >> findbugs. You also don't put the compiled class files or the pdf user's >> guide into SVN. ;-) >> >> Shlomy Reinstein schrieb: >> >> I just ran the FindBugs utility (http://findbugs.sourceforge.net/) on >> jEdit and it has found quite a few threading/synchronization problems, >> some of them in the thread/thread-pool classes. I will check them, but >> for those who are interested, FindBugs usually reports real problems. >> It helped me detect threading problems quickly when I developed the >> GdbPlugin. >> How about adding the FindBugs output for jEdit to SVN? It's an XML >> file as far as I remember, which can be loaded by anyone. As problems >> are fixed, we can redo the processing and save the updated FindBugs >> output. >> >> Shlomy >> >> On Dec 20, 2007 7:40 AM, Marcelo Vanzin <mmv...@gm...> wrote: >> >> >> >> This might be related to an issue I've seen a few times. Basically >> when I have a lot of project files opened, and switch to another >> project (thus causing PV to close all those files), sometimes the UI >> will get all messed up. That generally hints at some threading issue >> (i.e., some non-AWT thread calling AWT code). >> >> It might be unrelated, but just thought I'd mention that. I don't >> remember seeing that in 4.2, but I've noticed it on pretty much every >> 4.3 pre-release version from time to time. >> >> >> On Dec 19, 2007 7:24 AM, Shlomy Reinstein <sre...@gm...> wrote: >> >> >> >> >> It seems to me, in 2nd thought, that what I've found by debugging IS >> the problem - the creation of the ProjectViewer dockable window >> probably takes place in the AWT thread, and this very thread blocks on >> the call to jEdit.closeBuffer(). The later is waiting for the buffer >> to complete loading and invoke the Runnable from Buffer.load(), which >> is supposed to run in the AWT thread and mark the buffer as "finished >> loading". But since the AWT thread is blocked by closeBuffer(), this >> will never happen. >> Does this make sense? I don't understand, though, how Buffer.load() >> ensures that the runnable that marks the buffer as "finished loading" >> is executed only after the buffer is fully loaded from disk. If >> there's some diagram or document somewhere describing the sequence of >> operations and their distribution to threads, please let me know. >> Shlomy >> >> >> ---------- Forwarded message ---------- >> From: Shlomy Reinstein <sre...@gm...> >> Date: Dec 19, 2007 4:55 PM >> Subject: jEdit fails to start >> To: jEdit dev <jEd...@li...> >> >> >> Hi, >> >> Recently, with the SVN trunk version of jEdit, and with the released >> version of ProjectViewer (not the SVN trunk version, which is not >> stable), I started to have a problem with jEdit startup. Frequently it >> freezes during the last phase of the startup, when it tries to restore >> the configuration of the view from perspective.xml. It tries to show >> the ProjectViewer dockable, and this causes a series of operations >> that cause jEdit to freeze. >> I tried to debug it, and found out that jEdit freezes when the >> ProjectViewer initialization tries to set the active project, closing >> the open buffers along the way ("Close files on project change" option >> is set). It calls "jEdit.closeBuffer(...)", which in turn finds that >> the buffer is performing an I/O operation and calls >> VFSManager.waitForRequests() which never returns. >> >> Has anyone encountered such problems? I've been using this version of >> ProjectViewer for a long time, always with this option set, and never >> had this problem, so probably this is something that was changed in >> jEdit recently. >> >> Erasing the perspective.xml file makes the problem go away, but then I >> don't have my saved perspective, of course... >> >> Thanks, >> Shlomy >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services >> for just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> -- >> ----------------------------------------------- >> jEdit Developers' List >> >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> >> >> >> -- >> Marcelo Vanzin >> mmv...@gm... >> "Life's too short to drink cheap beer." >> >> >> >> ------------------------------------------------------------------------- >> SF.Net email is sponsored by: >> Check out the new SourceForge.net Marketplace. >> It's the best place to buy or sell services >> for just about anything Open Source. >> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2005. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> -- >> ----------------------------------------------- >> jEdit Developers' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-devel >> >> >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > |