From: Robert H. <ha...@st...> - 2008-12-03 16:51:49
|
I'm so glad to see that the resizing does that. Yes, that's right -- for now at least an error in rendering is not sent out in any other way -- there could be hundreds of these as the applet continues to try to repaint during resizing. Question: Did it go back to normal after you resized it back to an acceptable value? Or was the end of the show? For now, the scriptCallback is very specific and always reports any error that occurred of any sort in its "termination" callback (with a fourth parameter -- the execution time, provided the error was due to a script command. It wasn't doing that earlier, and probably still doesn't in Jmol 11.6, but it does in Jmol 11.7. The rendering errors are different, and I propose we create an errorCallback method to handle those. This should be reliable, because rendering errors almost certainly involve too large a screen, and that buffer can be cleared to provide more memory for the callback. An errorCallback option could clearly distinguish between Java Errors, Java Exceptions (as in file loading), and Jmol scripting errors. There will be no translation problems there. >> > The examples work well with Java 1.4.2_18 and Firefox 3.0.4 on Linux. great. > > If I provoke an out-of-memory error by resizing the applet to 6000x6000 > pixel > (http://www.imb-jena.de/cgi-bin/3d_mapping.pl?CODE=1deh&JMOLVERSION=11.7.16_dev) > Jmol traps the error but the message (see below) is only displayed in > the java console and for example not in the messageCallback stream. > > ======= error message =========== > viewer handling error condition: java.lang.OutOfMemoryError > Error during rendering: java.lang.OutOfMemoryError > ================================= that's what I like to see! I'm a little surprised it didn't say the full java.lang.OutOfMemoryError: Java heap space but that's still what we need -- "OutOfMemoryError" will NOT be translated. > > I havn't found a resolution yet for the internationalization problem of > all kinds of error messages: > The messages sent by "messageCallback", "scriptCallback" and > 'jmolGetPropertyAsString("errorMessage")' are translated. This makes > writing a parser very difficult because it must understand all error > messages in all languages. And it must be adapted to each new language > added. I have a solution for you for that. The part "script ERROR:" is being translated, but the part after that is not. In any case, it's not the message callback that you want for this -- it's the scriptCallback. With that callback there is a numeric parameter that indicates script starting (-2), script processing (0), script ending (-1), or script terminated (milliSeconds n > 0). If it's a memory error the message will will be present in the script termination callback and definitely include "java.lang.OutOfMemoryError" in it. > > The additional problem with 'jmolGetPropertyAsString("errorMessage")' is > for me to know when to run it and to connect the error message to the > right command. yes, so that's why we need the errorCallback. > > Regards, > Rolf > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > -- Robert M. Hanson Professor of Chemistry St. Olaf College 1520 St. Olaf Ave. Northfield, MN 55057 http://www.stolaf.edu/people/hansonr phone: 507-786-3107 If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 |