Re: [Jmol-users] jmol-14.1.12_2014.03.21.zip -- important update
Same problem here as Jaime. Firefox on Win7 on page load, this is the error: Error: TypeError: this.stm.jmolStatusListener is undefined Source file: j2s/core/core.z.js Line: 2552 JSmol object is blank, no frank, popup menu does open normally. From the console, load =1crn the header is read in the console, but no display of the model with ?_USE=java there is no error -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
Re: [Jmol-users] jmol-14.1.12_2014.03.21.zip -- important update
On Mac 10.9.2, both Safari and Firefox 28.0, JSmol fails with message:
TypeError: 'undefined' is not an object (evaluating
'this.stm.jmolStatusListener.isStereoSlave')
JSmol loads, able to open popup menu, no frank.
Java version, Jmol_S, works Ok.
Jaim
On Mar 22, 2014, at 2:05 AM, Robert Hanson
hans...@stolaf.edumailto:hans...@stolaf.edu wrote:
Make that http://chemapps.stolaf.edu/jmol/zip/jmol-14.1.12_2014.03.21b.zip
This has the full file set.
On Fri, Mar 21, 2014 at 3:12 PM, Robert Hanson
hans...@stolaf.edumailto:hans...@stolaf.edu wrote:
http://chemapps.stolaf.edu/jmol/zip/jmol-14.1.12_2014.03.21.zip
Soon-to-be released as Jmol 14.0.12/14.1.12, this update fixes the bug Angel
just reported, improves performance, and adds some pretty nifty ZIP-file
capabilities.
I decided that if I am adding features, I should also put time into reducing
code size. So that's what I've been doing the past two days. Happy to report
that despite those improvements, this version reduces the base load size by 43K
(since last week), and the full package size by about 100K (since last year).
In addition, my careful checking of what modules were being loaded and seeing
what I could do about that means that PDB files will require about 200K less
upon download, so they should load much faster. Mostly this is just be giving
field variables more compact names, like this.mshttp://this.ms/ instead of
this.modelSet (2K), this.ce instead of this.propertyColorEncoder (1.6K),
etc. A little harder to decipher the code, but I can live with that.
With last week's 900% speed-up in molecular isosurface creation in Java (about
300% in HTML5), the performance is really coming along. Every time I test JSmol
it seems to be faster and smoother and more Java-like. Sure has come a long way
in a year and a half. Very satisfying!
Fixes since 3.17 include:
___JmolVersion=14.1.12_2014.03.21
bug fix: getProperty() function does not recognize a list as a variable and
returns it as a string (Angel)
bug fix: Dsn6Reader.java misnamed, causing EDS map file load error
in JavaScript only. (I did not know that was even possible!)
(Dale Tronrud)
New features:
The real news is that now we have some very powerful PNGJ/ZIP capabilities. You
can unpack PNGJ files and repack them, adding files if you like, and you can
create and modify ZIP files -- in JavaScript, of course. Thanks to Chuck
Shubert and Ivan Ceraj (MIT) for getting me going on that.
new feature: x= format(JSON, data)
-- simple way to generate JSON code.
new feature: x = format(base64, data)
-- creates base64-encoding of the data
-- prepends the string with ;base64,
new feature; binary byte array
-- from array(s) where s starts with ;base64,
-- from binary associative arrays
new feature: binary associative arrays
-- Any array containing $_BINARY_$ as a key.
-- Values may contain raw byte array data, but need not.
-- Can be expanded or changed, just like any associative array.
-- Seen in string form when in a string context.
-- .type of elements will report byteArray
new feature: x = write(PNGJ)
-- Creates a binary associative array equivalent to writing a PNGJ file
-- Contains keys _IMAGE_, JmolManifest.txt, state.spt
and all associated files.
new feature: write VAR x filename
or write @x filename
-- Where x is a binary array or a binary associative array.
-- When x is a binary array, writes binary data to a file.
-- When x is an array, creates a ZIP file
(or PNGJ file, if _IMAGE_ is present and is PNG format),
automatically converting strings starting with ;base64, to
byte arrays in the ZIP file. To do the same with x a binary
array, just use @{array(x)} instead of @x.
new feature: x = load(myfile,true)
-- Creates a binary associative array variable x that contains the contents of
the file file.
-- data are stored as raw bytes.
-- If the file is a standard file, the key _DATA_ will hold the file data.
-- If the file is a PNGJ file, the key _IMAGE_ will hold the image data,
and additional files are keyed by file name.
-- If the file is a zip file, the files are keyed by file name.
-- Note that x = load(myfile) without true loads the contents of
the file into x and, if the file is a PNGJ or ZIP file, just loads
the list of files in the collection, not the actual data.
Actually, the really really interesting news is that the reorganizing of the
code that I am doing is making for capabilities that go way beyond Jmol. Want
to create Zip files for any purpose? You can do that. Pull an image out of a
Word document? Sure. Want to create PDF files from data on a web page? Have
that.
That's because the way this works, I've basically produced a JavaScript library
that can do anything Java can do. Very interesting...
Have a good weekend. I'm taking a break!
Bob
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Re: [Jmol-users] jmol-14.1.12_2014.03.21.zip -- important update
Make that http://chemapps.stolaf.edu/jmol/zip/jmol-14.1.12_2014.03.21b.zip
This has the full file set.
On Fri, Mar 21, 2014 at 3:12 PM, Robert Hanson hans...@stolaf.edu wrote:
http://chemapps.stolaf.edu/jmol/zip/jmol-14.1.12_2014.03.21.zip
Soon-to-be released as Jmol 14.0.12/14.1.12, this update fixes the bug
Angel just reported, improves performance, and adds some pretty nifty
ZIP-file capabilities.
I decided that if I am adding features, I should also put time into
reducing code size. So that's what I've been doing the past two days. Happy
to report that despite those improvements, this version reduces the base
load size by 43K (since last week), and the full package size by about 100K
(since last year). In addition, my careful checking of what modules were
being loaded and seeing what I could do about that means that PDB files
will require about 200K less upon download, so they should load much
faster. Mostly this is just be giving field variables more compact names,
like this.ms instead of this.modelSet (2K), this.ce instead of
this.propertyColorEncoder (1.6K), etc. A little harder to decipher the
code, but I can live with that.
With last week's 900% speed-up in molecular isosurface creation in Java
(about 300% in HTML5), the performance is really coming along. Every time I
test JSmol it seems to be faster and smoother and more Java-like. Sure has
come a long way in a year and a half. Very satisfying!
Fixes since 3.17 include:
___JmolVersion=14.1.12_2014.03.21
bug fix: getProperty() function does not recognize a list as a variable
and returns it as a string (Angel)
bug fix: Dsn6Reader.java misnamed, causing EDS map file load error
in JavaScript only. (I did not know that was even possible!)
(Dale Tronrud)
New features:
The real news is that now we have some very powerful PNGJ/ZIP
capabilities. You can unpack PNGJ files and repack them, adding files if
you like, and you can create and modify ZIP files -- in JavaScript, of
course. Thanks to Chuck Shubert and Ivan Ceraj (MIT) for getting me going
on that.
new feature: x= format(JSON, data)
-- simple way to generate JSON code.
new feature: x = format(base64, data)
-- creates base64-encoding of the data
-- prepends the string with ;base64,
new feature; binary byte array
-- from array(s) where s starts with ;base64,
-- from binary associative arrays
new feature: binary associative arrays
-- Any array containing $_BINARY_$ as a key.
-- Values may contain raw byte array data, but need not.
-- Can be expanded or changed, just like any associative array.
-- Seen in string form when in a string context.
-- .type of elements will report byteArray
new feature: x = write(PNGJ)
-- Creates a binary associative array equivalent to writing a PNGJ file
-- Contains keys _IMAGE_, JmolManifest.txt, state.spt
and all associated files.
new feature: write VAR x filename
or write @x filename
-- Where x is a binary array or a binary associative array.
-- When x is a binary array, writes binary data to a file.
-- When x is an array, creates a ZIP file
(or PNGJ file, if _IMAGE_ is present and is PNG format),
automatically converting strings starting with ;base64, to
byte arrays in the ZIP file. To do the same with x a binary
array, just use @{array(x)} instead of @x.
new feature: x = load(myfile,true)
-- Creates a binary associative array variable x that contains the
contents of
the file file.
-- data are stored as raw bytes.
-- If the file is a standard file, the key _DATA_ will hold the file
data.
-- If the file is a PNGJ file, the key _IMAGE_ will hold the image
data,
and additional files are keyed by file name.
-- If the file is a zip file, the files are keyed by file name.
-- Note that x = load(myfile) without true loads the contents of
the file into x and, if the file is a PNGJ or ZIP file, just loads
the list of files in the collection, not the actual data.
Actually, the really really interesting news is that the reorganizing of
the code that I am doing is making for capabilities that go way beyond
Jmol. Want to create Zip files for any purpose? You can do that. Pull an
image out of a Word document? Sure. Want to create PDF files from data on a
web page? Have that.
That's because the way this works, I've basically produced a JavaScript
library that can do anything Java can do. Very interesting...
Have a good weekend. I'm taking a break!
Bob
--
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
--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
