OK, OK. I just had to say that. For those intrepid souls who enjoy
programming, here's a twist on the old try/throw/catch idea. Not released
yet, but it's been a good day's work putting it together, and it seems to
be working flawlessly. And, by the way, the little bit of code that was
necessary is less than this email message, for sure!
The basic idea: There's a new command in Jmol scripting, THROW.
This command, as in JavaScript and Java allows one to "throw an error" and
either let it stop a running script or catch it with the CATCH command,
because the throw was within the TRY part of a try/catch syntax.
So if Jmol executes
* throw "my error"*
That will stop processing at that point in the code, and you can catch
that, or just let Jmol report the error.
But here's the twist: It seemed to me that the system I set up to handle
all this threading business -- animation, moveto, zoom, load async, etc. --
could also be used outside of that context. So the way it works is that if
you use
*throw CONTEXT test*
the processing stops, and you get a Jmol variable "test" that holds all the
context variables. (Those are the ones that are in functions, for example,
as arguments or VAR definitions local to that context.) You can say:
*test["x"] = 5print test["x"]*
and such. It looks like an associative array. In fact, you can print it and
see all the local variables defined for that context:
*print test*
_path : [script] >> t.spt >> function test2 >> function testing
_retval : from testing: x=11 vret[1]=10
a : 3
b : 4
x : 5
So you have full access to what the variables were when that was thrown.
That seems like it might be useful....
But it gets better! By entering:
*&test*
you can now *resume* that running script exactly where it left off. Whoah!
So that's like God's gift to debugging, right? Check variables, change
them, continue. Kind of like a "super, flexible, designer break point."
Which means this is an alternative to callbacks. Why wait until the end of
a process to get a callback? Just throw this "event" and do something with
it, then continue.
And, interestingly, you can now run
*&test*
as many times as you like. It will just go right back to where it was and
repeat the process.
In addition if instead of THROW you use SAVE, that doesn't stop the
processing, but the context variable is still created:
*save CONTEXT test*
Now the process will complete, but we will have a sort of "tag" to this
particular point in the code.
More examples below. I'm guessing someone on this list will know what to do
with this....
Bob
___JmolVersion="14.1.11_2014.02.21"
*new feature: catchable THROW*
-- as in Java or JavaScript, allows a way of jumping
out of a process.
-- outside of try/catch gives the expected error report:
$ print "testing"
$ throw "testing here"
$ print "we will never see this"
testing
script ERROR: testing here
----
throw >> "testing here" <<
-- passes a string as the variable thrown_value
$ print thrown_value
testing here
-- can be trapped with try/catch:
try{
print "testing"
throw "testing here"
print "continuing"
} catch(e) {
print "thown_value=" + thrown_value;
}
results in:
testing
thrown_value=testing here
*new feature: asynchronous resumable processes*
-- THROW CONTEXT contextName
-- throws a catchable error, but in the process of doing so,
creates a script context that allows RESUMING
at the point of the throw, unlike anything in JavaScript
or Java (or perhaps like a debug mode).
-- if within a try/catch phrase, is handled by user.
-- if not within a try/catch phrase just reports
to resume, enter: &contextName
-- essentially provides a callback into the running
script, so you could, for example, put a running script
on hold while you load a file, check variables, etc.,
then continue.
-- can be resumed using RESUME CONTEXT or just & followed
by the name of the context:
&test
resume context test
-- replaces PAUSE/RESUME, now deprecated.
-- The current context returns to the highest level, however
the variables in the context that was thrown are
accessible as though the context variable was an
associative array. So, for example, if we have
function f(a, b, c) {
var x = 5
throw context testing
print "x=" + x
}
f(1,2,3)
print "done"
The context will be saved as the variable "testing", and
we can then test all the variables in that saved context,
(and change them before continuing):
print testing["x"]
5
testing["x"]++
print testing
_path : [script] >> function f
_retval : 0
a : 2
b : 2
c : 3
x : 6
-- contexts can be restored using
&contextName
In the above case, we would get the report:
x=6
done
*new feature: SAVE CONTEXT contextName* -- similar to THROW, but does not
stop processing.
So in the above example, if we change THROW to SAVE,
the processing continues, but after it has completed,
we can change context variables and run it again.
*new feature: show SAVED* -- same as show SAVE
*new feature: delete $SAVED savedName*
delete $SAVED Context_xxxx
-- $ is important; case is not.
-- allows selective deletion of saved objects
-- Contexts always start with "Context_" but the subname
"xxxx" in this case will work as well.
*new feature: RESUME with arguments is synonymous with RESTORE *
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr
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
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
