You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(20) |
Jun
(13) |
Jul
(45) |
Aug
|
Sep
(3) |
Oct
(5) |
Nov
(1) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(20) |
Feb
(8) |
Mar
(10) |
Apr
(38) |
May
(8) |
Jun
(1) |
Jul
|
Aug
(8) |
Sep
(45) |
Oct
(116) |
Nov
(195) |
Dec
(67) |
2003 |
Jan
(94) |
Feb
(84) |
Mar
(23) |
Apr
(21) |
May
(246) |
Jun
(100) |
Jul
(23) |
Aug
(54) |
Sep
(73) |
Oct
(166) |
Nov
(52) |
Dec
(46) |
2004 |
Jan
(138) |
Feb
(175) |
Mar
(194) |
Apr
(76) |
May
(423) |
Jun
(412) |
Jul
(127) |
Aug
(133) |
Sep
(172) |
Oct
(273) |
Nov
(192) |
Dec
(272) |
2005 |
Jan
(178) |
Feb
(178) |
Mar
(97) |
Apr
(76) |
May
(138) |
Jun
(57) |
Jul
(130) |
Aug
(88) |
Sep
(168) |
Oct
(61) |
Nov
(52) |
Dec
(120) |
2006 |
Jan
(37) |
Feb
(259) |
Mar
(426) |
Apr
(175) |
May
(299) |
Jun
(135) |
Jul
(79) |
Aug
(145) |
Sep
(390) |
Oct
(142) |
Nov
(98) |
Dec
(50) |
2007 |
Jan
(52) |
Feb
(129) |
Mar
(77) |
Apr
(84) |
May
(122) |
Jun
(91) |
Jul
(39) |
Aug
(62) |
Sep
(63) |
Oct
(95) |
Nov
(67) |
Dec
(69) |
2008 |
Jan
(72) |
Feb
(41) |
Mar
(107) |
Apr
(22) |
May
(28) |
Jun
(33) |
Jul
(68) |
Aug
(144) |
Sep
(39) |
Oct
(123) |
Nov
(78) |
Dec
(24) |
2009 |
Jan
(58) |
Feb
(45) |
Mar
(78) |
Apr
(95) |
May
(50) |
Jun
(82) |
Jul
(52) |
Aug
(46) |
Sep
(102) |
Oct
(42) |
Nov
(94) |
Dec
(59) |
2010 |
Jan
(48) |
Feb
(102) |
Mar
(190) |
Apr
(69) |
May
(68) |
Jun
(106) |
Jul
(126) |
Aug
(46) |
Sep
(87) |
Oct
(66) |
Nov
(136) |
Dec
(92) |
2011 |
Jan
(83) |
Feb
(25) |
Mar
(46) |
Apr
(18) |
May
(24) |
Jun
(30) |
Jul
(17) |
Aug
(21) |
Sep
(45) |
Oct
(107) |
Nov
(61) |
Dec
(35) |
2012 |
Jan
(33) |
Feb
(34) |
Mar
(46) |
Apr
(38) |
May
(84) |
Jun
(58) |
Jul
(40) |
Aug
(82) |
Sep
(21) |
Oct
(74) |
Nov
(20) |
Dec
(10) |
2013 |
Jan
(55) |
Feb
(57) |
Mar
(45) |
Apr
(77) |
May
(18) |
Jun
(9) |
Jul
(6) |
Aug
(10) |
Sep
(33) |
Oct
(29) |
Nov
(48) |
Dec
(25) |
2014 |
Jan
(17) |
Feb
(15) |
Mar
(35) |
Apr
(22) |
May
(17) |
Jun
(25) |
Jul
(32) |
Aug
(16) |
Sep
(43) |
Oct
(16) |
Nov
|
Dec
(8) |
2015 |
Jan
(20) |
Feb
(10) |
Mar
(24) |
Apr
(24) |
May
(1) |
Jun
(19) |
Jul
(24) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(14) |
2016 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
(39) |
Jun
(14) |
Jul
|
Aug
(9) |
Sep
(22) |
Oct
(10) |
Nov
(6) |
Dec
(2) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
(11) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(6) |
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(2) |
Dec
(1) |
2019 |
Jan
(3) |
Feb
|
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(5) |
Jul
(13) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(8) |
Dec
(8) |
2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(13) |
2021 |
Jan
(2) |
Feb
|
Mar
(9) |
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2022 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
2023 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
2024 |
Jan
|
Feb
(6) |
Mar
|
Apr
(1) |
May
(2) |
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: <tho...@ya...> - 2022-03-21 16:36:41
|
Hello all. I am contacting you to see if you can direct me to some information on integration of Jmol into a java applicaiton. I would like to use Jmol as a viewer for a collection of small molecule 3D structures that I have computed by quantum chemistry. I have searched the Jmol website and Jmol wiki site and have found only dead links or links toinformation that is at least 10 years old, some approaching 20 years. >From various sources I have found by searching the internet, I have pieced together something that works after a fashion. The structures I would like to display have been calculated by AMPAC, MOPAC and Guassian, and are currently stored in a relational database. (Access to the database is via a java application.) I am using components of the ChemistryDevelopment Kit and JFreeChart integrated into my software. It makes sense to use an already-developed 3D, such as Jmol, rather than trying to develop my own. Snippets of example code using current releases of Jmol, javadocs of the Jmol API, any guidance to literature or documentation would be greatly appreciated and extremely useful. Thomas -------------------------------- Thomas R. Sharp, Ph.D. 63 Bunny Road Preston, Connecticut 06365 |
From: Angel H. <ang...@ua...> - 2022-01-27 21:17:28
|
Hello, Mark, and welcome to this community Jmol code is written in Java. That leads to the Jmol application. But the Java code is also used to (automatically) generate JavaScript code that makes it possible to have JSmol (for embedding in web pages) Bob Hanson will be able to give you more precise details, if you need them. Dr. Angel Herráez Biochemistry and Molecular Biology, Dept. of Systems Biology, University of Alcalá E-28805 Alcalá de Henares (Madrid), Spain |
From: Mark P. <pe...@so...> - 2022-01-27 21:05:07
|
Hi Mark, As far as I know it is only Java (and transpiled to Javascript). But there is a server mode where you can send api requests over a port, so I think you could control a running Jmol server using a client written in another language through that mechanism. https://chemapps.stolaf.edu/jmol/docs/#sync There is also a headless JmolData.jar that you can call from another application by passing a script on the command line and parse the output. I always meant to figure out how to use the server sync, but I use this way because it was simpler to setup. Thanks, Mark On Thu, Jan 27, 2022 at 12:29 PM Rodriguez, Mark A via Jmol-developers < jmo...@li...> wrote: > Hello Jmol developers, > > I am new to the list. > > I am happy that Jmol is open source! > > I was curious if Jmol is exclusively written in Java, or if there are > codes available in other programming languages. > > I am guessing it is Java only, but I wanted to check. > > > Thanks! > > > > Mark A. Rodriguez > Sandia National Laboratories > PO Box 5800, MS 1411 > Albuquerque, NM 87185-1411 > > > > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > |
From: Rodriguez, M. A <ma...@sa...> - 2022-01-27 20:29:51
|
Hello Jmol developers, I am new to the list. I am happy that Jmol is open source! I was curious if Jmol is exclusively written in Java, or if there are codes available in other programming languages. I am guessing it is Java only, but I wanted to check. Thanks! Mark A. Rodriguez Sandia National Laboratories PO Box 5800, MS 1411 Albuquerque, NM 87185-1411 |
From: Robert H. <ha...@st...> - 2022-01-08 19:29:29
|
On Sat, Jan 8, 2022 at 12:12 PM Amr ALHOSSARY <amr...@ho...> wrote: > bioJava-structure-gui latest version (6.0.4) is released last week and it > depends on Jmol 14.31.10 (the latest available on Maven central repository). > > I tried today to update it to the newly released "14.32.10" or “15.2.10”, > but neither of them is found in Maven Central repository. > > > That could be. I don't know how those get published to Maven Central. > It is actually one viewer and one GUI Event Dispatching Thread (EDT). > However the EDT may dispatch several calls too fast to be processed. > > > > The story starts with a list of PDB IDs in a JList. When the user selects > one of them, that PDB file is opened, passed to Jmol by creating a mmCif > dictionary file in a string on the fly and calling > > *synchronized*(*this*) { > > viewer.openStringInline(serializedMmCif); > > viewer.evalString(rasmolScript); > > } > > where viewer is a JmolViewer. > > > OK. You can improve on that. OpenStringInLine is not thread safe. It will immediately initiate a file reading. Better is to put it all in your script: String s = "load DATA \"mydata\" " + serializedMmCif + "\nEND \"mydata\";" + rasmolScript; viewer.evalString(s); evalString will schedule the script for execution, holding off on rendering until that is complete. > > > [image: A screenshot of a computer Description automatically generated > with medium confidence] > > > > > > The calls are done in a synchronized block, so even if there are several > threads (which is NOT the case) they won’t interfere with each other. > > The problem is that Jmol takes the commands and returns immediately, > leaving the evaluation process to be completed ((asynchronously)) in > another thread (at least this is how it seems to me). > Right -- there is a daemon thread for the script processor. Now if the user clicks the first item in the JList, then presses (and keeps > pressing) the down arrow key, the whole list would be traversed in seconds; > leading to frequent subsequent calls to the function that loads and > visualizes the PDB files (especially when the list is long enough, or there > are big PDB files being loaded). > Ah, that was what I was wondering about. You could avoid that with a bit of a time delay on processing. Or by waiting until a mouse-up to process. > > I can not depend on synchronizing the calling , because calling is > synchronized already. But I need to ensure that no new command is initiated > until the previous command(s) have been called ((and processed)) already. > > This was a simplified version of the problem. > > I think the only problem was the use of openStringInline, which does not (should?) use the script processor. > > > A more complicated version is that the JList itself is populated by > several threads scanning the PDB for something. Whenever a thread finds the > target they are searching for, it adds the PDB ID to the list and selects > this new item (which simulates a user click on the newly added item). > Yeah, I don't know about that. Do you consider that an expected behavior by the user? Wouldn't that be rather annoying? Basically, if you want anything from Viewer in terms of model changes or rendering, you should do that via scripting. This ensures that everything is sequenced correctly. Also, if you send "!exit" as a script, it will clear all scripts in the queue. Or if you start a script with "!exit;" then this script will interrupt any running script after the currently-running command is completed, clear the queue, and start this script, basically gracefully clearing the way for itself and then running. Bob |
From: Amr A. <amr...@ho...> - 2022-01-08 18:28:29
|
bioJava-structure-gui latest version (6.0.4) is released last week and it depends on Jmol 14.31.10 (the latest available on Maven central repository). I tried today to update it to the newly released "14.32.10" or “15.2.10”, but neither of them is found in Maven Central repository. It is actually one viewer and one GUI Event Dispatching Thread (EDT). However the EDT may dispatch several calls too fast to be processed. The story starts with a list of PDB IDs in a JList. When the user selects one of them, that PDB file is opened, passed to Jmol by creating a mmCif dictionary file in a string on the fly and calling synchronized(this) { viewer.openStringInline(serializedMmCif); viewer.evalString(rasmolScript); } where viewer is a JmolViewer. [A screenshot of a computer Description automatically generated with medium confidence] The calls are done in a synchronized block, so even if there are several threads (which is NOT the case) they won’t interfere with each other. The problem is that Jmol takes the commands and returns immediately, leaving the evaluation process to be completed ((asynchronously)) in another thread (at least this is how it seems to me). Now if the user clicks the first item in the JList, then presses (and keeps pressing) the down arrow key, the whole list would be traversed in seconds; leading to frequent subsequent calls to the function that loads and visualizes the PDB files (especially when the list is long enough, or there are big PDB files being loaded). I can not depend on synchronizing the calling , because calling is synchronized already. But I need to ensure that no new command is initiated until the previous command(s) have been called ((and processed)) already. This was a simplified version of the problem. A more complicated version is that the JList itself is populated by several threads scanning the PDB for something. Whenever a thread finds the target they are searching for, it adds the PDB ID to the list and selects this new item (which simulates a user click on the newly added item). However, I believe fixing the simplified version is enough to fix the complicated version. I hope that explains the problem clearly enough. Regards Amr From: Robert Hanson via Jmol-developers <jmo...@li...> Sent: Saturday, 8 January, 2022 9:56 PM To: jmo...@li...; Jmol Developers <jmo...@li...> Cc: Robert Hanson <ha...@st...> Subject: Re: [Jmol-developers] [Jmol-users] Synchronizing multiple threads Welcome, Amr! FYI there is another list for developers. jmol-developers. But I will answer your questions here. Users can disregard. I do apologize for not spotting this message until now. Bob Hanson On Thu, Dec 2, 2021 at 8:33 PM Amr ALHOSSARY <amr...@ho...<mailto:amr...@ho...>> wrote: Dear valued list member especially Prof Robert Hanson, This is my first message to the list. I am developing a Java-based HPC searching and viewing application. In my application, multiple threads from multiple cores are running. I have a Jmol Viewer (from BioJava-Structure-GUI), created using: viewer = JmolViewer.allocateViewer(this, adapter, null,null,null,null, statusListener) I am not at all certain what the BioJava-Structure-GUI has for Jmol. This could be a VERY old version. When every thread starts, it reads a PDB/mmCif structure (using BioJava) and calls viewer.openStringInline(serialized); so far, so good. And each thread should probably have its own Viewer object, if they are going to be interrupting each other. Then when it finds target cross links, it: 1. Sets the structure again by calling jmolPanel.setStructure(structure); I do not know what this method is (spot checking back to 2006). What version of Jmol are you using? Or is this your subclass method? What does it mean to "set" a structure, and what is the class of "structure" here? Or is "jmolPanel" not a org.openscience.jmol.app.jmolpanel.JmolPanel? 1. Creates a Jmol script formatting to format the structure. String buffer = ResultManager.generateAfterLoadingJMolScriptString(pdbId); 1. Execute the generated script using: jmolPanel.executeCmd(buffer); The 3 steps are done in a synchronized block. However, when the number of threads is above a certain limit (say 8 threads), I encounter exceptions like this: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.jmol.shape.Balls.setProperty(Balls.java:74) at org.jmol.viewer.ShapeManager.setShapePropertyBs(ShapeManager.java:202) at org.jmol.script.ScriptEval.setShapeProperty(ScriptEval.java:9245) at org.jmol.script.ScriptEval.colorShape(ScriptEval.java:8591) at org.jmol.script.ScriptEval.cmdColor(ScriptEval.java:3266) at org.jmol.script.ScriptEval.processCommand(ScriptEval.java:2360) at org.jmol.script.ScriptEval.commandLoop(ScriptEval.java:2310) at org.jmol.script.ScriptEval.dispatchCommands(ScriptEval.java:2173) at org.jmol.script.ScriptEval.executeCommands(ScriptEval.java:421) at org.jmol.script.ScriptEval.evaluateCompiledScript(ScriptEval.java:407) at org.jmol.script.ScriptManager.evalStringWaitStatusQueued(ScriptManager.java:364) at org.jmol.viewer.Viewer.evalStringWaitStatusQueued(Viewer.java:3979) at org.jmol.script.ScriptQueueThread.runNextScript(ScriptQueueThread.java:118) at org.jmol.script.ScriptQueueThread.run1(ScriptQueueThread.java:80) at org.jmol.thread.JmolThread.run(JmolThread.java:105) Yes, certainly a threading issue there. You seem to be sharing a single viewer with multiple processes. I don’t think there are any problems in the formatting scripts, because when there are no multiple threads, everything renders well. My understanding is that a thread is trying to load and format another structure, while the first is in the middle of formatting its own structure (it seems that the formatting is performed asynchronously. How can I ensure that no two threads will be executing simultaneously? Good question. I think you will have to use semiphores or your end and just not let one get to the Jmol code until another is complete. Q: How are you displaying all these simultaneously generated renderings? Bob |
From: Amr A. <amr...@ho...> - 2022-01-08 14:15:54
|
Thank you, Dr. Robert. I thought that Jmol-developers is used to discuss Jmol design decisions and such internal stuff. I will continue the conversation on jmol-developers list. Amr From: Robert Hanson via Jmol-developers <jmo...@li...> Sent: Saturday, 8 January, 2022 9:56 PM To: jmo...@li...; Jmol Developers <jmo...@li...> Cc: Robert Hanson <ha...@st...> Subject: Re: [Jmol-developers] [Jmol-users] Synchronizing multiple threads Welcome, Amr! FYI there is another list for developers. jmol-developers. But I will answer your questions here. Users can disregard. I do apologize for not spotting this message until now. Bob Hanson On Thu, Dec 2, 2021 at 8:33 PM Amr ALHOSSARY <amr...@ho...<mailto:amr...@ho...>> wrote: Dear valued list member especially Prof Robert Hanson, This is my first message to the list. I am developing a Java-based HPC searching and viewing application. In my application, multiple threads from multiple cores are running. I have a Jmol Viewer (from BioJava-Structure-GUI), created using: viewer = JmolViewer.allocateViewer(this, adapter, null,null,null,null, statusListener) I am not at all certain what the BioJava-Structure-GUI has for Jmol. This could be a VERY old version. When every thread starts, it reads a PDB/mmCif structure (using BioJava) and calls viewer.openStringInline(serialized); so far, so good. And each thread should probably have its own Viewer object, if they are going to be interrupting each other. Then when it finds target cross links, it: 1. Sets the structure again by calling jmolPanel.setStructure(structure); I do not know what this method is (spot checking back to 2006). What version of Jmol are you using? Or is this your subclass method? What does it mean to "set" a structure, and what is the class of "structure" here? Or is "jmolPanel" not a org.openscience.jmol.app.jmolpanel.JmolPanel? 1. Creates a Jmol script formatting to format the structure. String buffer = ResultManager.generateAfterLoadingJMolScriptString(pdbId); 1. Execute the generated script using: jmolPanel.executeCmd(buffer); The 3 steps are done in a synchronized block. However, when the number of threads is above a certain limit (say 8 threads), I encounter exceptions like this: java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0 at org.jmol.shape.Balls.setProperty(Balls.java:74) at org.jmol.viewer.ShapeManager.setShapePropertyBs(ShapeManager.java:202) at org.jmol.script.ScriptEval.setShapeProperty(ScriptEval.java:9245) at org.jmol.script.ScriptEval.colorShape(ScriptEval.java:8591) at org.jmol.script.ScriptEval.cmdColor(ScriptEval.java:3266) at org.jmol.script.ScriptEval.processCommand(ScriptEval.java:2360) at org.jmol.script.ScriptEval.commandLoop(ScriptEval.java:2310) at org.jmol.script.ScriptEval.dispatchCommands(ScriptEval.java:2173) at org.jmol.script.ScriptEval.executeCommands(ScriptEval.java:421) at org.jmol.script.ScriptEval.evaluateCompiledScript(ScriptEval.java:407) at org.jmol.script.ScriptManager.evalStringWaitStatusQueued(ScriptManager.java:364) at org.jmol.viewer.Viewer.evalStringWaitStatusQueued(Viewer.java:3979) at org.jmol.script.ScriptQueueThread.runNextScript(ScriptQueueThread.java:118) at org.jmol.script.ScriptQueueThread.run1(ScriptQueueThread.java:80) at org.jmol.thread.JmolThread.run(JmolThread.java:105) Yes, certainly a threading issue there. You seem to be sharing a single viewer with multiple processes. I don’t think there are any problems in the formatting scripts, because when there are no multiple threads, everything renders well. My understanding is that a thread is trying to load and format another structure, while the first is in the middle of formatting its own structure (it seems that the formatting is performed asynchronously. How can I ensure that no two threads will be executing simultaneously? Good question. I think you will have to use semiphores or your end and just not let one get to the Jmol code until another is complete. Q: How are you displaying all these simultaneously generated renderings? Bob |
From: Robert H. <ha...@st...> - 2022-01-08 13:56:13
|
Welcome, Amr! FYI there is another list for developers. jmol-developers. But I will answer your questions here. Users can disregard. I do apologize for not spotting this message until now. Bob Hanson On Thu, Dec 2, 2021 at 8:33 PM Amr ALHOSSARY <amr...@ho...> wrote: > Dear valued list member especially Prof Robert Hanson, > > > > This is my first message to the list. > > I am developing a Java-based HPC searching and viewing application. > > In my application, multiple threads from multiple cores are running. > > I have a Jmol Viewer (from BioJava-Structure-GUI), created using: > > viewer = JmolViewer.*allocateViewer*(*this*, adapter,* null*,*null*,*null* > ,*null*, statusListener) > > > I am not at all certain what the BioJava-Structure-GUI has for Jmol. This could be a VERY old version. > When every thread starts, it reads a PDB/mmCif structure (using BioJava) > and calls > > viewer.openStringInline(serialized); > > so far, so good. And each thread should probably have its own Viewer object, if they are going to be interrupting each other. > > Then when it finds target cross links, it: > > 1. Sets the structure again by calling > > jmolPanel.setStructure(structure); > I do not know what this method is (spot checking back to 2006). What version of Jmol are you using? Or is this your subclass method? What does it mean to "set" a structure, and what is the class of "structure" here? Or is "jmolPanel" not a org.openscience.jmol.app.jmolpanel.JmolPanel? > 1. Creates a Jmol script formatting to format the structure. > > String buffer = ResultManager. > *generateAfterLoadingJMolScriptString*(pdbId); > > 1. Execute the generated script using: > > jmolPanel.executeCmd(buffer); > > The 3 steps are done in a synchronized block. > > However, when the number of threads is above a certain limit (say 8 > threads), I encounter exceptions like this: > > > > java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length > 0 > > at org.jmol.shape.Balls.setProperty(Balls.java:74) > > at > org.jmol.viewer.ShapeManager.setShapePropertyBs(ShapeManager.java:202) > > at > org.jmol.script.ScriptEval.setShapeProperty(ScriptEval.java:9245) > > at > org.jmol.script.ScriptEval.colorShape(ScriptEval.java:8591) > > at > org.jmol.script.ScriptEval.cmdColor(ScriptEval.java:3266) > > at > org.jmol.script.ScriptEval.processCommand(ScriptEval.java:2360) > > at > org.jmol.script.ScriptEval.commandLoop(ScriptEval.java:2310) > > at > org.jmol.script.ScriptEval.dispatchCommands(ScriptEval.java:2173) > > at > org.jmol.script.ScriptEval.executeCommands(ScriptEval.java:421) > > at > org.jmol.script.ScriptEval.evaluateCompiledScript(ScriptEval.java:407) > > at > org.jmol.script.ScriptManager.evalStringWaitStatusQueued(ScriptManager.java:364) > > at > org.jmol.viewer.Viewer.evalStringWaitStatusQueued(Viewer.java:3979) > > at > org.jmol.script.ScriptQueueThread.runNextScript(ScriptQueueThread.java:118) > > at > org.jmol.script.ScriptQueueThread.run1(ScriptQueueThread.java:80) > > at org.jmol.thread.JmolThread.run(JmolThread.java:105) > > > Yes, certainly a threading issue there. You seem to be sharing a single viewer with multiple processes. I don’t think there are any problems in the formatting scripts, because > when there are no multiple threads, everything renders well. > > > > My understanding is that a thread is trying to load and format another > structure, while the first is in the middle of formatting its own structure > (it seems that the formatting is performed asynchronously. > > > > > How can I ensure that no two threads will be executing simultaneously? > > Good question. I think you will have to use semiphores or your end and just not let one get to the Jmol code until another is complete. Q: How are you displaying all these simultaneously generated renderings? Bob |
From: Robert H. <ha...@st...> - 2021-12-16 13:49:10
|
This message is to confirm that Jmol.jar (any version) is not affected by the CVE-2021-45046 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046>: *Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack* as described by Apache <https://logging.apache.org/log4j/2.x/security.html>, or any other Log4j2 vulnerability. Several checks support this finding: 1) Jmol is compiled using Java 6. Log4j2.x requires at least Java 7. 2) Jmol itself does not use Log4j. We use a much simpler, extremely streamlined custom class, org.jmol.util.Logger, with only a very simple interface. 3) Jmol does incorporate JNI-InChI 1.03_1, which does utilize Log4j. However, JNI-InChI 1.03_1 utilizes Log4j1, not Log4j2. 4) Log4j1.x is not impacted by this vulnerability. 5) The suggested mitigation -- simply removing org/apache/logging/log4j/core/lookup/JndiLookup.class from the distributed JAR file (Jmol.jar, JmolData.jar) is unnecessary, as Jmol.jar does not contain even the org/apache/logging package, much less any class file that starts with "Jndi". 6) Jmol does not just incorporate dependency JAR files; they are unpacked. As part of this unpacking, the ANT task <delete file="${appjars.dir}/org/apache/logging/log4j/core/lookup/JndiLookup.class" /> has been added to build.xml in the next release of Jmol (14.32.5/15.2.5) Bob Hanson |
From: Egon W. <ego...@gm...> - 2021-08-17 06:18:49
|
On Sat, Aug 14, 2021 at 1:19 AM Mark Perri <pe...@so...> wrote: > I know sourceforge is already setup, but if you went wholly over to github > I believe they have a way to distribute binaries. I've never tried it > though: > https://docs.github.com/en/github/administering-a-repository/releasing-projects-on-github/about-releases > When you make a release based on a tag, you have the option to "attach" binary files. If not mistaken, if the integration with Zenodo is setup (highly recommended; btw, I believe an integration with Figshare for the same purpose is possible too, but never tried that yet), these binaries get archived too. Egon -- This year I am stepping down as co-Editor-in-Chief of the Journal of Cheminformatics, because of a conflict of interest with Springer Nature. See https://twitter.com/egonwillighagen/status/1403299501947899907 ----- E.L. Willighagen Department of Bioinformatics - BiGCaT Maastricht University (http://www.bigcat.unimaas.nl/) Twitter/Mastodon: @egonwillighagen <https://twitter.com/egonwillighagen> / @egonw <https://scholar.social/@egonw> Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: https://www.zotero.org/egonw ORCID: 0000-0001-7542-0286 <http://orcid.org/0000-0001-7542-0286> ImpactStory: https://impactstory.org/u/egonwillighagen |
From: Mark P. <pe...@so...> - 2021-08-13 23:19:11
|
Hi Bob, I know sourceforge is already setup, but if you went wholly over to github I believe they have a way to distribute binaries. I've never tried it though: https://docs.github.com/en/github/administering-a-repository/releasing-projects-on-github/about-releases Thanks, Mark On Thu, Aug 12, 2021 at 11:35 AM Robert Hanson via Jmol-developers < jmo...@li...> wrote: > OK, I found it. > > On Thu, Aug 12, 2021 at 1:20 PM Robert Hanson <ha...@st...> wrote: > >> Does anyone have any idea why my commit messages are requiring >> moderator's decision - and, for that matter, why none of my commit messages >> have been recorded for the past four years? I had just ignored this, but >> now I am finding it quite annoying that the SVN page >> https://sourceforge.net/p/jmol/mailman/jmol-commits/ makes it look like >> almost nothing is being done on Jmol. >> >> Bob >> >> >> >> >> On Thu, Aug 12, 2021 at 10:23 AM < >> jmo...@li...> wrote: >> >>> Your mail to 'Jmol-commits' with the subject >>> >>> SF.net SVN: jmol:[22218] trunk/Jmol/src/org/jmol >>> >>> Is being held until the list moderator can review it for approval. >>> >>> The reason it is being held: >>> >>> Post by non-member to a members-only list >>> >>> Either the message will get posted to the list, or you will receive >>> notification of the moderator's decision. If you would like to cancel >>> this posting, please visit the following URL: >>> >>> >>> https://lists.sourceforge.net/lists/confirm/jmol-commits/c123ca6b9f2855f7330e89d1de0eafe8fcd33db0 >>> >>> >> >> -- >> Robert M. Hanson >> 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 >> >> *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We >> honor with gratitude the people who have stewarded the land throughout the >> generations and their ongoing contributions to this region. We acknowledge >> the ongoing injustices that we have committed against the Dakota Nation, >> and we wish to interrupt this legacy, beginning with acts of healing and >> honest storytelling about this place.* >> > > > -- > Robert M. Hanson > 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 > > *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We > honor with gratitude the people who have stewarded the land throughout the > generations and their ongoing contributions to this region. We acknowledge > the ongoing injustices that we have committed against the Dakota Nation, > and we wish to interrupt this legacy, beginning with acts of healing and > honest storytelling about this place.* > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > |
From: <ang...@ua...> - 2021-08-13 10:35:22
|
Bob, I really am not sure but, maybe a change in the email address? This is what I see Jmol-commits list run by hansonr at users.sourceforge.net assigned as admin and moderator It says there are : jmol-commits 3 subscribers but no way to know who they are And some of our messages appear to come from Robert Hanson via Jmol-developers <jmo...@li...> On 12 Aug 2021 at 13:20, Robert Hanson via Jmol-developers wrote: > > Does anyone have any idea why my commit messages are requiring moderator's decision - and, > for that matter, why none of my commit messages have been recorded for the past four years? I > had just ignored this, but now I am finding it quite annoying that the SVN page > https://sourceforge.net/p/jmol/mailman/jmol-commits/ makes it look like almost nothing is being > done on Jmol. > > Bob > > > > > > On Thu, Aug 12, 2021 at 10:23 AM <jmo...@li... > wrote: > Your mail to 'Jmol-commits' with the subject > > SF.net SVN: jmol:[22218] trunk/Jmol/src/org/jmol > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > > https://lists.sourceforge.net/lists/confirm/jmol-commits/c123ca6b9f2855f733 > 0e89d1de0eafe8fcd33db0 > > > -- > Robert M. Hanson > 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 > > We stand on the homelands of the Wahpekute Band of the Dakota Nation. We honor with > gratitude the people who have stewarded the land throughout the generations and their ongoing > contributions to this region. We acknowledge the ongoing injustices that we have committed > against the Dakota Nation, and we wish to interrupt this legacy, beginning with acts of healing and > honest storytelling about this place. -- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus |
From: Robert H. <ha...@st...> - 2021-08-12 18:35:46
|
OK, I found it. On Thu, Aug 12, 2021 at 1:20 PM Robert Hanson <ha...@st...> wrote: > Does anyone have any idea why my commit messages are requiring moderator's > decision - and, for that matter, why none of my commit messages have been > recorded for the past four years? I had just ignored this, but now I am > finding it quite annoying that the SVN page > https://sourceforge.net/p/jmol/mailman/jmol-commits/ makes it look like > almost nothing is being done on Jmol. > > Bob > > > > > On Thu, Aug 12, 2021 at 10:23 AM <jmo...@li...> > wrote: > >> Your mail to 'Jmol-commits' with the subject >> >> SF.net SVN: jmol:[22218] trunk/Jmol/src/org/jmol >> >> Is being held until the list moderator can review it for approval. >> >> The reason it is being held: >> >> Post by non-member to a members-only list >> >> Either the message will get posted to the list, or you will receive >> notification of the moderator's decision. If you would like to cancel >> this posting, please visit the following URL: >> >> >> https://lists.sourceforge.net/lists/confirm/jmol-commits/c123ca6b9f2855f7330e89d1de0eafe8fcd33db0 >> >> > > -- > Robert M. Hanson > 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 > > *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We > honor with gratitude the people who have stewarded the land throughout the > generations and their ongoing contributions to this region. We acknowledge > the ongoing injustices that we have committed against the Dakota Nation, > and we wish to interrupt this legacy, beginning with acts of healing and > honest storytelling about this place.* > -- Robert M. Hanson 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 *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We honor with gratitude the people who have stewarded the land throughout the generations and their ongoing contributions to this region. We acknowledge the ongoing injustices that we have committed against the Dakota Nation, and we wish to interrupt this legacy, beginning with acts of healing and honest storytelling about this place.* |
From: Robert H. <ha...@st...> - 2021-08-12 18:20:40
|
Does anyone have any idea why my commit messages are requiring moderator's decision - and, for that matter, why none of my commit messages have been recorded for the past four years? I had just ignored this, but now I am finding it quite annoying that the SVN page https://sourceforge.net/p/jmol/mailman/jmol-commits/ makes it look like almost nothing is being done on Jmol. Bob On Thu, Aug 12, 2021 at 10:23 AM <jmo...@li...> wrote: > Your mail to 'Jmol-commits' with the subject > > SF.net SVN: jmol:[22218] trunk/Jmol/src/org/jmol > > Is being held until the list moderator can review it for approval. > > The reason it is being held: > > Post by non-member to a members-only list > > Either the message will get posted to the list, or you will receive > notification of the moderator's decision. If you would like to cancel > this posting, please visit the following URL: > > > https://lists.sourceforge.net/lists/confirm/jmol-commits/c123ca6b9f2855f7330e89d1de0eafe8fcd33db0 > > -- Robert M. Hanson 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 *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We honor with gratitude the people who have stewarded the land throughout the generations and their ongoing contributions to this region. We acknowledge the ongoing injustices that we have committed against the Dakota Nation, and we wish to interrupt this legacy, beginning with acts of healing and honest storytelling about this place.* |
From: Mark P. <pe...@so...> - 2021-05-15 21:48:37
|
Thanks! PS There is an error in the tar file for the full version. It looks like not all the files got included and it gives an EOF error. The binary is fine. Thanks, Mark On Sat, May 15, 2021 at 5:23 AM Robert Hanson via Jmol-developers < jmo...@li...> wrote: > This is fixed. > Jmol-14.31.39-binary.zip (57.9 MB) > <https://sourceforge.net/projects/jmol/files/latest/download> > > There was also a problem with {*}.atomName for GAMESS in Jmol/Java. > > It turns out that Java and JavaScript DO have a difference in string > concatenation: > > > Java: null + 1 = "null1" > JavaScript: null + 1 = 1 > > JavaScript: Thus the "indexOf method does not exist" message. > Java+JavaScript: This was not supposed to be null in the first place in > GamessUS.java. Broken in 14.31.35 2021.03.17 > > <https://sourceforge.net/projects/jmol/files/latest/download> > > Bob > > > On Fri, May 14, 2021 at 9:56 PM Robert Hanson <ha...@st...> wrote: > >> Just to be clear, this example is from the SwingJS version of JSmol, not >> the release version on SourceForge. >> I do see a Gamess reader error in both of those cases, though. I will >> look into it. >> >> Bob >> >> >> > > -- > Robert M. Hanson > 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 > > *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We > honor with gratitude the people who have stewarded the land throughout the > generations and their ongoing contributions to this region. We acknowledge > the ongoing injustices that we have committed against the Dakota Nation, > and we wish to interrupt this legacy, beginning with acts of healing and > honest storytelling about this place.* > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > |
From: Robert H. <ha...@st...> - 2021-05-15 12:23:20
|
This is fixed. Jmol-14.31.39-binary.zip (57.9 MB) <https://sourceforge.net/projects/jmol/files/latest/download> There was also a problem with {*}.atomName for GAMESS in Jmol/Java. It turns out that Java and JavaScript DO have a difference in string concatenation: Java: null + 1 = "null1" JavaScript: null + 1 = 1 JavaScript: Thus the "indexOf method does not exist" message. Java+JavaScript: This was not supposed to be null in the first place in GamessUS.java. Broken in 14.31.35 2021.03.17 <https://sourceforge.net/projects/jmol/files/latest/download> Bob On Fri, May 14, 2021 at 9:56 PM Robert Hanson <ha...@st...> wrote: > Just to be clear, this example is from the SwingJS version of JSmol, not > the release version on SourceForge. > I do see a Gamess reader error in both of those cases, though. I will look > into it. > > Bob > > > -- Robert M. Hanson 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 *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We honor with gratitude the people who have stewarded the land throughout the generations and their ongoing contributions to this region. We acknowledge the ongoing injustices that we have committed against the Dakota Nation, and we wish to interrupt this legacy, beginning with acts of healing and honest storytelling about this place.* |
From: Robert H. <ha...@st...> - 2021-05-15 02:56:29
|
Just to be clear, this example is from the SwingJS version of JSmol, not the release version on SourceForge. I do see a Gamess reader error in both of those cases, though. I will look into it. Bob |
From: Mark P. <pe...@so...> - 2021-05-15 00:24:36
|
Hi Bob, I was preparing to update my JSmol version, but there is a problem loading GAMESS files now (14.31.38). It works just fine in Jmol, but not in JSmol. In JSmol I get: ERROR creating model: TypeError: e.indexOf is not a function. I tried in the latest Github version (15303) and get a similar error: ERROR creating model: TypeError: h.indexOf$I is not a function. Here's the system.out from the github version: The Resolver thinks GamessUS * GAMESS VERSION = 30 JUN 2019 (R1) * 1 ELECTRON INTEGRALS ...... END OF ONE-ELECTRON INTEGRALS ...... transpiler was 3.2.9-v1 now 3.3.1-v1 for java.util.DualPivotQuicksort 19 molecular orbitals read in model 2 Energy for model 2 = -76.3718260301 Molecular dipole for model 2 = {0.0, 0.0, -2.097674} 15 molecular orbitals read in model 6 Energy for model 6 = -76.3718284924 Molecular dipole for model 6 = {0.0, 0.0, -2.094662} THE HESSIAN WILL NOW BE COMPUTED AT THE STATIONARY POINT. 45.24 cm^-1 35.74 cm^-1 27.63 cm^-1 0.010000000000000002 cm^-1 0.07 cm^-1 0.21 cm^-1 1712.26 cm^-1 3725.4 cm^-1 3847.23 cm^-1 Time for openFile(cache://localLOAD_water (6).out): 1790 ms reading 42 atoms ModelSet: haveSymmetry:false haveUnitcells:false haveFractionalCoord:false 14 models in this collection. Use getProperty "modelInfo" or getProperty "auxiliaryInfo" to inspect them. 0 function(e, clazz) at Object.Clazz._getStackTrace ( https://beta.chemcompute.org/site/swingjs/swingjs2.js:15969:8) 1 org.jmol.viewer.Viewer.createModelSetAndReturnError$O$Z$javajs_util_SB$java_util_Mapfunction(a,b,c,g) at Clazz.exceptionOf ( https://beta.chemcompute.org/site/swingjs/swingjs2.js:14407:32) 2 org.jmol.viewer.Viewer.loadModelFromFile$S$S$SA$O$Z$java_util_Map$javajs_util_SB$javajs_util_SB$I$Sfunction(a,b,c,g,f,h,l,k,n,s) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:10726:104) 3 org.jmol.script.ScriptEval.cmdLoad$function() at clazz.eval [as loadModelFromFile$S$S$SA$O$Z$java_util_Map$javajs_util_SB$javajs_util_SB$I$S] (swingjs/j2s/core/core_jmol.z.js:10710:230) 4 org.jmol.script.ScriptEval.processCommand$Ifunction(a) at clazz.eval [as cmdLoad$] (swingjs/j2s/core/core_jmol.z.js:9128:178) 5 org.jmol.script.ScriptEval.commandLoop$Zfunction(a) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:9056:370) 6 org.jmol.script.ScriptEval.dispatchCommands$Z$Z$Zfunction(a,b,c) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:9051:339) 7 org.jmol.script.ScriptEval.executeCommands$Z$Zfunction(a,b) at clazz.eval [as dispatchCommands$Z$Z$Z] (swingjs/j2s/core/core_jmol.z.js:9045:49) 8 org.jmol.script.ScriptEval.resumeEval$Ofunction(a) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:8978:218) 9 function() at clazz.eval [as resumeEval$O] (swingjs/j2s/core/core_jmol.z.js:8981:448) see Clazz._stack transpiler was 3.3.1-v1 now 3.2.9-v1 for org.jmol.shape.Echo vwr handling error condition: TypeError: h.indexOf$I is not a function TypeError: h.indexOf$I is not a function TypeError: h.indexOf$I is not a function at clazz.eval (swingjs/j2s/core/core_jmol.z.js:8385:12) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:8381:423) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:8359:489) at clazz.eval [as c$$org_jmol_viewer_Viewer$S$javajs_util_SB$O$org_jmol_modelset_ModelSet$javajs_util_BS] (swingjs/j2s/core/core_jmol.z.js:8349:336) at Clazz.new_ ( https://beta.chemcompute.org/site/swingjs/swingjs2.js:14777:19) at clazz.eval [as createModelSet$S$S$javajs_util_SB$O$javajs_util_BS$Z] (swingjs/j2s/core/core_jmol.z.js:10271:248) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:10725:127) at clazz.eval [as loadModelFromFile$S$S$SA$O$Z$java_util_Map$javajs_util_SB$javajs_util_SB$I$S] (swingjs/j2s/core/core_jmol.z.js:10710:230) at clazz.eval [as cmdLoad$] (swingjs/j2s/core/core_jmol.z.js:9128:178) at clazz.eval (swingjs/j2s/core/core_jmol.z.js:9056:370) File Error:ERROR creating model: TypeError: h.indexOf$I is not a function Time for creating model: 759 ms eval ERROR: ---- load <<<<"?" Eval pc:0 1 statements ---- Token[keyword(1/0x8001401) value="load"] Token[string(4/0x4) value="?"] END script ERROR: ERROR creating model: TypeError: h.indexOf$I is not a function ---- load <<<<"?" Thanks, Mark |
From: Mark P. <pe...@so...> - 2021-03-16 00:57:12
|
No, just a .dat file (attached). There's an option NPRINT=1 to print out extra basis info, but it doesn't seem to add that info. Thanks, Mark On Mon, Mar 15, 2021 at 5:30 PM Robert Hanson <ha...@st...> wrote: > I'm looking into this. I don't suppose this output file comes with a file > with extension MGF or GPT2. Does it? > > > |
From: Robert H. <ha...@st...> - 2021-03-16 00:30:25
|
I'm looking into this. I don't suppose this output file comes with a file with extension MGF or GPT2. Does it? |
From: Mark P. <pe...@so...> - 2021-03-15 23:12:14
|
Hi Bob, Jmol doesn't display any molecular orbitals from GAMESS PM6 calculations (and I suspect AM1 and PM3). The output file has Eigenvector and Molecular orbital sections. It looks like Jmol is looking for an ATOMIC BASIS SET section to setup shells. All the PM6 calculation says is: THE PARAMETERS USED IN THIS CALCULATION ARE DESCRIBED IN: H: (PM6) J. J. P. STEWART, J Mol Model (2007) 13:1173-1213 C: (PM6) J. J. P. STEWART, J Mol Model (2007) 13:1173-1213 If I dig out the shell information for these methods and add them into GamessReader.java similar to readGaussianBasis() will Jmol display the MOs? Or is there something else I'm missing? I don't have much experience with semi-empirical, so let me know if that's not a good idea. Thanks, Mark |
From: Robert H. <ha...@st...> - 2021-03-08 15:26:48
|
So the advise, I guess, if someone were to use the applet for some reason (probably testing?) that they use JmolApplet.jar, because I do think the JmolAppletSigned*.* set will deactivate. On Mon, Mar 8, 2021 at 9:24 AM Robert Hanson <ha...@st...> wrote: > OK. Angel, I think you are right -- while we have been singing Jmol.jar, > I'm pretty sure the worst thing that can happen is that when I don't renew > the certificate, the already signed versions of those stop working. And > people will want to get a new version. I'm trying to remember how this > worked when GoDaddy accidentally revoked my certificate. As I recall, all > the applets in the field died instantly, but there was no disruption for > Jmol.jar. > > The applets are all still available on SourceForge through 14.31.2. I have > no plans to get rid of those. > > Bob > > -- Robert M. Hanson 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 *We stand on the homelands of the Wahpekute Band of the Dakota Nation. We honor with gratitude the people who have stewarded the land throughout the generations and their ongoing contributions to this region. We acknowledge the ongoing injustices that we have committed against the Dakota Nation, and we wish to interrupt this legacy, beginning with acts of healing and honest storytelling about this place.* |
From: Robert H. <ha...@st...> - 2021-03-08 15:24:51
|
OK. Angel, I think you are right -- while we have been singing Jmol.jar, I'm pretty sure the worst thing that can happen is that when I don't renew the certificate, the already signed versions of those stop working. And people will want to get a new version. I'm trying to remember how this worked when GoDaddy accidentally revoked my certificate. As I recall, all the applets in the field died instantly, but there was no disruption for Jmol.jar. The applets are all still available on SourceForge through 14.31.2. I have no plans to get rid of those. Bob |
From: Angel H. <ang...@ua...> - 2021-03-08 10:28:17
|
Hi all Since it is hardly possible to run applets inside browsers, I see no major problem in stopping delivery of the (signed) JmolApplet. For intensive computation tasks, one should use the Jmol.jar application, which has nothing to do with signing. I agree that paying for this is too much -- and thanks, Bob for keeping that so far. We owe you one more meal and drinks! What I would ensure is that the latest signed version of the applet is not lost from the repository. If one should need that, they can likely do with any non-current version. |
From: Rzepa, H. S <h....@im...> - 2021-03-08 06:14:01
|
From my point of view there are operations that can ONLY be done using Java.jar such as processing a cube file which is > 100 mbyte in size (they can grow to 1G byte) But $250 pa is too much to pay for doing that! It would be good to have some idea of how browser-based JSmol might be able to handle large cube files though! Is there a JavaScript RTE equivalent that could be used to invoke JSmol outside of a browser? Henry Rzepa On 7 Mar 2021, at 21:17, Robert Hanson via Jmol-developers <jmo...@li...> wrote: I have not been signing the Jmol.jar file for some time now. No one has complained. How do others feel about my continuing to do that? I know it was important for the applet, but we are not distributing the Java applet anymore. So can we be done with signing? This has been an expense of about $250 for me each year for the past many years. Bob -- Robert M. Hanson 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 We stand on the homelands of the Wahpekute Band of the Dakota Nation. We honor with gratitude the people who have stewarded the land throughout the generations and their ongoing contributions to this region. We acknowledge the ongoing injustices that we have committed against the Dakota Nation, and we wish to interrupt this legacy, beginning with acts of healing and honest storytelling about this place. _______________________________________________ Jmol-developers mailing list Jmo...@li... https://lists.sourceforge.net/lists/listinfo/jmol-developers |