Re: [Jmol-users] Out of Memory Error Handling

[Robert H. <ha...@st...>]

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