Re: [Jmol-developers] Distinction between script error and freezing
> As long as it is not assured that Jmol can work normally afterwards,
> freezing might be better (possibly after sending an appropriate error
> message).
freezing is never better. I'll look into that error message. I did
make a few changes just this morning. So take a look at that.
Note that it will NEVER be safe to continue after an out-of-memory
error. The page must be reloaded.
>
> For my interface it is essential to know what kind of error occured and
> which interface command (which is never a single Jmol comand) provoked
> it. Only then it is possible to make proper suggestions to the user
> about possible solutions.
I'll check on that error message.
>
> I currently don't have the time but will later try to explain again why
> I would like to have a more defined error tracking system than just
> trying to parse the message stream.
I've fixed a but in the scriptCallback that was not indicating errors
in compilation. But in general you can check the fourth parameter of
the scriptCallback, which is -2 for starting the script, -1 for
completing the script, 0 for script messages, and >0 for termination.
Then when it terminates, check the third parameter. If this is null,
there was no error. If it is not null, then it gives the error
message. Or is supposed to.
JavaScript here:
function scriptCallback(app, status, message, millisec) {
// this filters out the "script completed" messages and only passes
the real messages along
millisec = parseInt("" + millisec)
ttest1 += "scriptcallback:" + millisec + "|" + message + "|" +
status + "|" + ((""+message) == "null")
if (millisec > 0 && (""+message) != "null")alert(message)
if (millisec == 0) showmsg(app, status, message, 0)
}
Bob
--
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
-
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-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
Re: [Jmol-developers] Distinction between script error and freezing
Robert Hanson wrote:
> sorry -- pressed SEND prematurely.
>
> Rolf, please check what I just checked in for Jmol 11.7.14. I think it
> just might work for you.
>
>
> -- Out of Memory errors -- "Java heap space" -- now caught by the
> script processor and image creator.
>
> -- jmolGetPropertyAsString("errorMessage") returns the error message
> or "null" if there was none.
>
> Still could be some problems here, but I'm betting this goes a long
> way to solving the problem.
>
I have tried revision 10376 and it is even worse than before.
When I tried to load a structure into the application that provokes an
"out of memory" error I just got the following error message:
eval ERROR:
load >> "1if0.pdb1.gz" <<
So I could not even recognize that insufficient memory was the problem
here. And although Jmol didn't freeze it also didn't behave well. For
example the automatic screen refresh didn't work any more.
As long as it is not assured that Jmol can work normally afterwards,
freezing might be better (possibly after sending an appropriate error
message).
For my interface it is essential to know what kind of error occured and
which interface command (which is never a single Jmol comand) provoked
it. Only then it is possible to make proper suggestions to the user
about possible solutions.
I currently don't have the time but will later try to explain again why
I would like to have a more defined error tracking system than just
trying to parse the message stream.
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-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
Re: [Jmol-developers] Distinction between script error and freezing
Oh, it is true that translations can change the "ERROR" message to
something else. So perhaps jmolGetPropertyAsString("errorMessage") is
a particularly good idea. If you execute that you should be able to
tell immediately whenever an error has occurred, including out of
memory. What you do after an out-of-memory error, I don't know.
Bob
On Wed, Nov 26, 2008 at 1:22 PM, Robert Hanson <[EMAIL PROTECTED]> wrote:
> sorry -- pressed SEND prematurely.
>
> Rolf, please check what I just checked in for Jmol 11.7.14. I think it
> just might work for you.
>
>
> -- Out of Memory errors -- "Java heap space" -- now caught by the
> script processor and image creator.
>
> -- jmolGetPropertyAsString("errorMessage") returns the error message
> or "null" if there was none.
>
> Still could be some problems here, but I'm betting this goes a long
> way to solving the problem.
>
> Bob
>
>
>>> How can the interface distinguish between a script error and freezing?
>
> There should be no more freezing, though I don't guarantee that.
>
>>>
>>> The interface could try to analyze the message callback stream to detect
>>> script errors. But since the complexity of the messages was increased
>>> during the last years it will be rather insecure and will also slow down
>>> the interface.
>
> I'm not convinced it does slow down the interface. The message
> callback stream is a dependable way to do this. All scripting errors
> contain the characters "ERROR" and can be read using messageCallback
> or scriptCallback
>
>
>>>
>>> So I would like to propose to implement a kind of error trapping system.
>>> A possible approach would be that Jmol would look for a specific
>>> function when a script error would occur. If this function would be
>>> defined it would run the commands within this function.
>
> Not sure I understand this idea.
>
>>>
>>> Q: What do you think about this idea?
>
> See how it works for you now -- again, I recommend using
> scriptCallback and just checking for ERROR
>
>
>
>>>
>>> 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-developers mailing list
>>> Jmol-developers@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> 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
>
--
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
-
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-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
Re: [Jmol-developers] Distinction between script error and freezing
sorry -- pressed SEND prematurely.
Rolf, please check what I just checked in for Jmol 11.7.14. I think it
just might work for you.
-- Out of Memory errors -- "Java heap space" -- now caught by the
script processor and image creator.
-- jmolGetPropertyAsString("errorMessage") returns the error message
or "null" if there was none.
Still could be some problems here, but I'm betting this goes a long
way to solving the problem.
Bob
>> How can the interface distinguish between a script error and freezing?
There should be no more freezing, though I don't guarantee that.
>>
>> The interface could try to analyze the message callback stream to detect
>> script errors. But since the complexity of the messages was increased
>> during the last years it will be rather insecure and will also slow down
>> the interface.
I'm not convinced it does slow down the interface. The message
callback stream is a dependable way to do this. All scripting errors
contain the characters "ERROR" and can be read using messageCallback
or scriptCallback
>>
>> So I would like to propose to implement a kind of error trapping system.
>> A possible approach would be that Jmol would look for a specific
>> function when a script error would occur. If this function would be
>> defined it would run the commands within this function.
Not sure I understand this idea.
>>
>> Q: What do you think about this idea?
See how it works for you now -- again, I recommend using
scriptCallback and just checking for ERROR
>>
>> 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-developers mailing list
>> Jmol-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>
>
>
>
> --
> 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
>
--
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
-
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-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
Re: [Jmol-developers] Distinction between script error and freezing
Rolf, it is great that you are tackling this.
On Wed, Nov 26, 2008 at 8:02 AM, Rolf Huehne <[EMAIL PROTECTED]> wrote:
> Hi developers,
>
> the increasing power of Jmol is fantastic. But if this power is used
> within the applet it greatly enhances the danger of freezing Jmol by an
> "out of memory error".
>
> When I started to build the JenaLib Jmol Viewer interface (now Jena3D)
> about 3 years ago there was only one really critical risk of getting an
> "out of memory" error: during file loading.
>
> But now there are plenty of other critical commands, e.g.:
>
> 1) set antialiasDisplay on
> 2) set fontScaling on
> 3) image export, e.g. 'jmolGetPropertyAsString("image")'
> 4) save STATE
>
> In order to avoid that users will stop working with the Jena3D interface
> because it often just stops working (caused by an "out of memory" error
> not visible for most of the users), I am currently trying to develop a
> system that detects freezing of Jmol. Then the user will at least get a
> message about the problem and how it might be avoided in the future.
>
> The general idea is the following:
>
> 1) Javascript interface side
> Each time a critical script command set is started, a timeout is set.
> After the timeout a subroutine checks if the command was completed.
> The check is repeated regularly until a defined time limit is reached.
> In this case the interface displays a message that Jmol might be freezed
> and what could be done to avoid it.
>
> 2) Jmol side
> At the end of each critical command set, the last command sets a
> javascript variable or starts a javascript function that indicates success.
>
> The basic approach works already, but there is (at least) one problem
> remaining:
>
> How can the interface distinguish between a script error and freezing?
>
> If there occurs a script error within the critical command set, Jmol
> will stop processing and will not reach the last command. And then the
> interface will finally tell the user that Jmol is frozen.
>
> The interface could try to analyze the message callback stream to detect
> script errors. But since the complexity of the messages was increased
> during the last years it will be rather insecure and will also slow down
> the interface.
>
> So I would like to propose to implement a kind of error trapping system.
> A possible approach would be that Jmol would look for a specific
> function when a script error would occur. If this function would be
> defined it would run the commands within this function.
>
> Q: What do you think about this idea?
>
> 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-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>
--
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
-
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-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers
