From: Dale A. <da...@gr...> - 2011-06-25 15:35:46
|
On Fri, Jun 24, 2011 at 7:35 PM, Alan Ezust <ala...@gm...> wrote: > I tried opening a 4gb xml file and it still blocks the GUI for quite some > time while it is building its data structures. It has to wait for the > initial IO request to complete before it can even start parsing, and > once it starts, it can't show the tree for quite some time. Then it shows > the tree, but it appears to still be building some other structures. > In my testing, I separated the buffer load time from the parsing time. Sidekick really can't do anything until the buffer is loaded anyway. What do you mean by "it appears to still be building some other structures"? > > Perhaps it should not show the tree until all the structures are built, and > do all this in a Task, one that can be viewed in the Task Monitor and > cancelled that way? > I haven't looked at the new task monitor yet. I still think it would be odd to look outside of sidekick for a way to stop something sidekick can stop by itself. > > I don't like that the sidekick has a cancel parsing button. It's taking up > too much space and it is almost never needed. If anything, the "parse" > button should CHANGE into a cancel button while it is parsing and change > back to a parse button when it is done. Good idea about combining the buttons. > > > 2011/6/24 Dale Anson <da...@gr...> > >> I have checked in my changes for SideKick. I'm still seeing issues in the >> XML plugin, but the others I've tested all seem fine. Using the 1 MB movie >> xml file as a test, it loads very fast, like in 2 or 3 seconds. I did a few >> copy and pastes and made it a 10 MB file, it still loads and parses in XML >> SideKick in less than a minute on my laptop. The problems I'm seeing are a >> combination of out of memory errors from testing with large files and some >> things in XML sidekick getting run on the EVT that shouldn't be. Eric, if >> you don't mind, I'll look into those next. >> >> Dale >> >> >> >> On Fri, Jun 24, 2011 at 10:32 AM, Dale Anson <da...@gr...> wrote: >> >>> 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 >>>>> >>>>> >>>> >>> >> >> >> ------------------------------------------------------------------------------ >> 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 >> >> > |