-- Originally posted by (AT sourceforge.net): *anonymous -- -- This ticket was imported from http://sourceforge.net/p/rkward/bugs/73 on 2017-05-30 15:26:50 +0100 -- This works fine in a stand alone R console: library\(XML\) xmlDoc <- xmlTreeParse\("http://www.unimod.org/xml/unimod\_tables.xml"\) rkward \(fresh checkout/build from svn\) crashes or freezes on it \(couldn't figure out why one or the other is happening\).-- Labels: data handling --
Thanks for reporting this issue. I can reproduce the freeze \(see below\), but not the crash. Could you give some more detail on this? \- How much of the time does it crash? \- Does it crash without further interaction, or only after trying something else \(e.g. quitting RKWard\)? \- Do you get a "KCrash handler" window? If so, could you please attach the backtrace from that? Regarding the freeze: It's actually not a freeze, but it's just slooooow. Basically the problem is that xmlDoc contains a lot of nodes, and extracting each single node is very slow for some reason. This is only partially the fault of RKWard: The slowness probably comes from the XML-package code. The problem in RKWard is that it is too proactive about gathering information about xmlDoc, and therefore triggers all those slow operations. Roughly speaking, what RKWard does is the equivalent of str \(xmlDoc, list.len=10000\) which takes a very long time in a plain R session, too \(note that the bottleneck is not the printing of all that output, but gathering it in the first place\). I plan on making RKWard less pro-active in gathering this information about objects, but this is not going to be trivial, and will not happen too soon. For the time being, the generic advice to work around this type of problem is to use local variables \(e.g. by placing your code inside a function, instead of at the top level\). Regards Thomas
- **summary**: XML: Crashes/freezes on xmlTreeParse --> NEEDINFO: Crashes/freezes on xmlTreeParse
To the best of my knowledge, this has never been an actual crash, but "only" an extreme inefficiency which could make RKWard stop responding for a long period of time, thus creating the impression of a freeze. The underlying issue should be fixed since RKWard 0.5.6. Closing the report. If you see this, or anything similar, again, with RKWard 0.5.6 or later, please open a new report.
- **assigned_to**: nobody --> tfry - **status**: open --> closed-fixed