From: Dale A. <da...@gr...> - 2011-06-24 16:32:12
|
Oops. Apparently I didn't actually check in my changes in SideKick, so getting the latest won't let you see what I've done so far. Shlomy, yes, the threads terminate cleanly -- mostly. I'm using SwingWorker, which has a cancel method. In the case of a cancel, 'stop' is called on the parser. I did notice that the XML plugin throws an interrupted exception when it is cancelled and I haven't looked into it yet. It could be there are other SideKick plugins with similar issues. Dale On Fri, Jun 24, 2011 at 3:09 AM, Shlomy Reinstein <sre...@gm...>wrote: > Thanks, Dale, for doing this change in SideKick. Do the parser threads have > a way of terminating cleanly? (e.g. by catching an interrupted exception) > > Shlomy > > 2011/6/24 Dale Anson <da...@gr...> > >> Hi Eric, >> >> I updated XML plugin to the latest from svn. It looks like there is an >> issue at XMLParsedData.java in the sort() method. I think the contents of >> this method needs wrapped in a SwingWorker. I was testing some changes I >> made in SideKick and was using the big movie xml file that Eric Berry has >> posted a link to a few times. I wanted the file to be bigger since it was >> parsing fairly fast for me, so I copied all of the "movie" nodes and tried >> to paste them at the bottom of the file after the last "movie" node. This >> causes jEdit to hang. A thread dump shows it's stuck in the sort() method. >> >> Also, I've done some work on the threading in SideKick, so the "Stop" >> button that Shlomy added works well -- or at least, it seems to work well >> for me. I'd appreciate if you could grab the latest SideKick code and test >> it out. >> >> Thanks, >> >> Dale >> >> >> >> On Mon, Jun 20, 2011 at 2:37 PM, Eric Le Lay < >> ker...@us...> wrote: >> >>> Le 04/06/2011 21:00, Mike Maxwell a écrit : >>> > On 6/3/2011 12:25 PM, Eric Le Lay wrote: >>> >> I've implemented a version of tag-matching based on the already >>> >> available sidekick information. It's performing better for big XML >>> >> files but it's less accurate than the original version when you are >>> >> editing the buffer, since the sidekick tree becomes outdated so I >>> >> haven't committed it yet. >>> > >>> > Clearly there's a trade-off, but for me at least it would be an >>> > acceptable trade-off when editing large files. Especially if there >>> were >>> > a way to tell it to re-parse the file while I made my coffee :-) >>> > >>> Hi Mike, >>> >>> you can try the latest (2011-06-21 >>> >>> http://www.tellurianring.com/projects/jedit-daily/index.php?dir=XML%2F2011-06-20_12-02-05%2F >>> ) >>> XMLPlugin build : >>> I hope it will be much faster at navigating through the file, once >>> parsing has been done, >>> since has the new tag-matching mechanism on by default. >>> >>> To get the old tag-matching back, go to Utilities > Evaluate Beanshell >>> and type >>> jEdit.setProperty("xml.structure-matcher","old"). It should also be a >>> bit faster... >>> >>> Cheers, >>> Eric >>> >>> >>> ------------------------------------------------------------------------------ >>> EditLive Enterprise is the world's most technically advanced content >>> authoring tool. Experience the power of Track Changes, Inline Image >>> Editing and ensure content is compliant with Accessibility Checking. >>> http://p.sf.net/sfu/ephox-dev2dev >>> -- >>> ----------------------------------------------- >>> jEdit Users' List >>> jEd...@li... >>> https://lists.sourceforge.net/lists/listinfo/jedit-users >>> >> >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense.. >> http://p.sf.net/sfu/splunk-d2d-c1 >> >> -- >> ----------------------------------------------- >> jEdit Users' List >> jEd...@li... >> https://lists.sourceforge.net/lists/listinfo/jedit-users >> >> > |