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
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Angel H. <ang...@ua...> - 2024-02-08 07:12:42
|
Good! and cleaner too regarding web server setup of files [cid:2a91fb5e-98dc-4b09-9301-920922c4dd25] |
From: Robert H. <ha...@st...> - 2024-02-07 23:44:36
|
Angel, you can try it here: https://chemapps.stolaf.edu/jmol/jsmol/jsmol/htm Maybe clear your browser cache. It was a simple fix -- just needed to adjust a bit of code in org.jmol.i18n.Resource so that JSmol no longer gets the .po files from that special idioma directory. Both Java and JavaScript now handle localization the same way. The files are in j2s/J/translation/JmolApplet. Thanks again for spotting this. Bob |
From: Angel H. <ang...@ua...> - 2024-02-07 19:29:18
|
Great. I will test with the next release Dr. Angel Herráez Biochemistry and Molecular Biology, Dept. of Systems Biology, University of Alcalá E-28805 Alcalá de Henares (Madrid), Spain ________________________________ De: Robert Hanson via Jmol-developers <jmo...@li...> Enviado: miércoles, 7 de febrero de 2024 18:40 Para: jmo...@li... <jmo...@li...> Cc: Robert Hanson <ha...@st...> Asunto: Re: [Jmol-developers] localization missing in 16.1.53 ATENCIÓN: Este correo electrónico se envió desde fuera de la UAH. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro. Angel, the problem was that I got rid of that directory in favor of just leaving it where it resides in org/jmol/translation/JmolApplet, but forgot to then connect that up with the menu. That is corrected. Bob |
From: Robert H. <ha...@st...> - 2024-02-07 18:47:26
|
Angel, the problem was that I got rid of that directory in favor of just leaving it where it resides in org/jmol/translation/JmolApplet, but forgot to then connect that up with the menu. That is corrected. Bob |
From: Robert H. <ha...@st...> - 2024-02-07 16:59:39
|
OK, thanks, Angel. |
From: Angel H. <ang...@ua...> - 2024-02-07 13:58:39
|
Hi Bob I just downloaded 16.1.53 zip distribution and I notice the absence of the "idioma" folder inside jsmol.zip · Dr. Angel Herráez Biochemistry and Molecular Biology, Dept. of Systems Biology, University of Alcalá E-28805 Alcalá de Henares (Madrid), Spain https://biomodel.uah.es/ FEBS Education and Training Conference <https://FEBSETC.org> |
From: Angel H. <ang...@ua...> - 2023-11-17 11:50:03
|
Hi Bob Congratulations, as that sounds as a big progress and success. I will nonetheless need a lot of spirits to digest the explanations ;-) All good here. Now starting a relatively easy period without teaching, till February. Best, · Dr. Angel Herráez Biochemistry and Molecular Biology, Dept. of Systems Biology, University of Alcalá E-28805 Alcalá de Henares (Madrid), Spain https://biomodel.uah.es/ El 16/11/2023 a las 18:59, Robert Hanson via Jmol-developers escribió: > *ATENCIÓN*: Este correo electrónico se envió desde fuera de la UAH. No > haga clic en enlaces ni abra archivos adjuntos a menos que reconozca > al remitente y sepa que el contenido es seguro. > Jmol Developers, > > Not sure if you are on this list you still have any interest in Jmol, > but I hope some of you do. > > Well, it's done. The JSmol sourceforge project at > https://sourceforge.net/p/jsmol > <https://sourceforge.net/p/jsmol> > is now no longer needed. I've placed all the files that were in that > project into the /unused/ folder there. This is so that we still can > track the histories of the files if we need to. But probably that will > not be necessary. > > This past week I totally overhauled the way the transpiler works. For > the past 10 years, the transpiler that was being used for Jmol only > worked in a very old version of Eclipse "Juno" from (I think) 2013. > This has been an enormous pain. For at least eight years I have > avoided doing anything with this old transpiler. > > I finally took the step to revisit the prototype "java2script 4.2" > code from 2013, and I realized that it was not so bad and that would > be possible to add that code to the SwingJS transpiler plugin as an > alternative transpiler option. > > That has worked perfectly. The new plugin is j2s.core_5.0.1.jar, at > https://github.com/BobHanson/java2script/tree/master/sources/net.sf.j2s.core > <https://github.com/BobHanson/java2script/tree/master/sources/net.sf.j2s.core> > > And, as a bonus, we now can adapt the legacy 4.2 transpiler, which is > only ever to be used with Jmol anyway, to future needs. The first > thing I did was move it up to Java 8 (Though it still only recognizes > Java 6 syntax.) One of the things I did was to give it a way to > deliver JavaScript code ready for running directly into the site/ > directory. This was huge, because previously there were a series of > ANT tasks that had to be run to do all sorts of minor tweaking of that > output before one could test in JavaScript. > > But now, it's very clean and simple. You modify Java code for Jmol, > save the .java file, and open your browser to see how it runs in > JavaScript. Your changes are instantly there. Full integration. The > way it should be. Hooray! > > And then I realized that we didn't need the JSmol project at all. > Originally, the idea was to do all the transpiling in this separate > project, just using the code that relates to the applet. But now this > is not necessary. Once I got the transpiler doing what the ANT tasks > were doing (and I was able to fix the various bugs in the 4.2 > transpiler that were causing these problems in the first place), I > realized that the only thing the JSmol project was doing (yesterday) > was to add some more files. So I figured I would just put those files > in the Jmol project (into site-resources/ and site-resources-zip). > That's all checked in now. > > Happy to report that that went smoothly, and I was able to fix a few > more bugs while at it. > > So, in short, the Jmol project is alive and well at SourceForge, now > using the same transpiler plugin as SwingJS. Just the two projects - > Jmol, on SourceForge, and java2script on GitHub. (OK, there's also the > Jmol-SwingJS GitHub project, that's true.) No old versions of Eclipse > are necessary. So long, Luna!! There's just the one plugin. > > And my life is way easier. Retirement (from teaching) is just > terrific. The bicycling season is just about over here; looks like I > will hit 4000 km this year. > > Drop me a line and tell me how you are doing. > > Bob > > -- > Robert M. Hanson > Professor of Chemistry, Emeritus > St. Olaf College > Northfield, MN > http://www.stolaf.edu/people/hansonr > <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: Jonathan G. <gu...@uw...> - 2023-11-17 00:15:49
|
Bob, This sounds great. I don’t have time currently to do anything with Jmol, but I hope to be able to take advantage of these changes in the future. Also thanks for rubbing it in…:) I’m a few years yet from retirement. My biking season ended many weeks ago because I could not get home before sunset…I’m way behind on miles. I’m jealous. Jonathan Dr. Jonathan Gutow Halsey Science Room 412 Chemistry Department UW Oshkosh web: https://cms.gutow.uwosh.edu/Gutow e-mail: gu...@uw... Ph: 920-424-1326 On Nov 16, 2023, at 11:59 AM, Robert Hanson via Jmol-developers <jmo...@li...> wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Jmol Developers, Not sure if you are on this list you still have any interest in Jmol, but I hope some of you do. Well, it's done. The JSmol sourceforge project at https://sourceforge.net/p/jsmol is now no longer needed. I've placed all the files that were in that project into the /unused/ folder there. This is so that we still can track the histories of the files if we need to. But probably that will not be necessary. This past week I totally overhauled the way the transpiler works. For the past 10 years, the transpiler that was being used for Jmol only worked in a very old version of Eclipse "Juno" from (I think) 2013. This has been an enormous pain. For at least eight years I have avoided doing anything with this old transpiler. I finally took the step to revisit the prototype "java2script 4.2" code from 2013, and I realized that it was not so bad and that would be possible to add that code to the SwingJS transpiler plugin as an alternative transpiler option. That has worked perfectly. The new plugin is j2s.core_5.0.1.jar, at https://github.com/BobHanson/java2script/tree/master/sources/net.sf.j2s.core And, as a bonus, we now can adapt the legacy 4.2 transpiler, which is only ever to be used with Jmol anyway, to future needs. The first thing I did was move it up to Java 8 (Though it still only recognizes Java 6 syntax.) One of the things I did was to give it a way to deliver JavaScript code ready for running directly into the site/ directory. This was huge, because previously there were a series of ANT tasks that had to be run to do all sorts of minor tweaking of that output before one could test in JavaScript. But now, it's very clean and simple. You modify Java code for Jmol, save the .java file, and open your browser to see how it runs in JavaScript. Your changes are instantly there. Full integration. The way it should be. Hooray! And then I realized that we didn't need the JSmol project at all. Originally, the idea was to do all the transpiling in this separate project, just using the code that relates to the applet. But now this is not necessary. Once I got the transpiler doing what the ANT tasks were doing (and I was able to fix the various bugs in the 4.2 transpiler that were causing these problems in the first place), I realized that the only thing the JSmol project was doing (yesterday) was to add some more files. So I figured I would just put those files in the Jmol project (into site-resources/ and site-resources-zip). That's all checked in now. Happy to report that that went smoothly, and I was able to fix a few more bugs while at it. So, in short, the Jmol project is alive and well at SourceForge, now using the same transpiler plugin as SwingJS. Just the two projects - Jmol, on SourceForge, and java2script on GitHub. (OK, there's also the Jmol-SwingJS GitHub project, that's true.) No old versions of Eclipse are necessary. So long, Luna!! There's just the one plugin. And my life is way easier. Retirement (from teaching) is just terrific. The bicycling season is just about over here; looks like I will hit 4000 km this year. Drop me a line and tell me how you are doing. Bob -- Robert M. Hanson Professor of Chemistry, Emeritus 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...> - 2023-11-16 23:04:43
|
That's certainly the idea! On Thu, Nov 16, 2023 at 4:00 PM Mark Perri <pe...@so...> wrote: > That's great! I did once try to compile Jmol, but I ran into those issues > (Eclipse version, Java 6, etc). This should make it easier for others to > contribute. > > Thanks, > Mark > > On Thu, Nov 16, 2023 at 9:59 AM Robert Hanson via Jmol-developers < > jmo...@li...> wrote: > >> Jmol Developers, >> >> Not sure if you are on this list you still have any interest in Jmol, but >> I hope some of you do. >> >> Well, it's done. The JSmol sourceforge project at >> https://sourceforge.net/p/jsmol is now no longer needed. I've placed all >> the files that were in that project into the /unused/ folder there. This is >> so that we still can track the histories of the files if we need to. But >> probably that will not be necessary. >> >> This past week I totally overhauled the way the transpiler works. For the >> past 10 years, the transpiler that was being used for Jmol only worked in a >> very old version of Eclipse "Juno" from (I think) 2013. This has been an >> enormous pain. For at least eight years I have avoided doing anything with >> this old transpiler. >> >> I finally took the step to revisit the prototype "java2script 4.2" code >> from 2013, and I realized that it was not so bad and that would be possible >> to add that code to the SwingJS transpiler plugin as an alternative >> transpiler option. >> >> That has worked perfectly. The new plugin is j2s.core_5.0.1.jar, at >> https://github.com/BobHanson/java2script/tree/master/sources/net.sf.j2s.core >> >> And, as a bonus, we now can adapt the legacy 4.2 transpiler, which is >> only ever to be used with Jmol anyway, to future needs. The first thing I >> did was move it up to Java 8 (Though it still only recognizes Java 6 >> syntax.) One of the things I did was to give it a way to deliver JavaScript >> code ready for running directly into the site/ directory. This was huge, >> because previously there were a series of ANT tasks that had to be run to >> do all sorts of minor tweaking of that output before one could test in >> JavaScript. >> >> But now, it's very clean and simple. You modify Java code for Jmol, save >> the .java file, and open your browser to see how it runs in JavaScript. >> Your changes are instantly there. Full integration. The way it should be. >> Hooray! >> >> And then I realized that we didn't need the JSmol project at all. >> Originally, the idea was to do all the transpiling in this separate >> project, just using the code that relates to the applet. But now this is >> not necessary. Once I got the transpiler doing what the ANT tasks were >> doing (and I was able to fix the various bugs in the 4.2 transpiler that >> were causing these problems in the first place), I realized that the only >> thing the JSmol project was doing (yesterday) was to add some more files. >> So I figured I would just put those files in the Jmol project (into >> site-resources/ and site-resources-zip). That's all checked in now. >> >> Happy to report that that went smoothly, and I was able to fix a few more >> bugs while at it. >> >> So, in short, the Jmol project is alive and well at SourceForge, now >> using the same transpiler plugin as SwingJS. Just the two projects - Jmol, >> on SourceForge, and java2script on GitHub. (OK, there's also the >> Jmol-SwingJS GitHub project, that's true.) No old versions of Eclipse are >> necessary. So long, Luna!! There's just the one plugin. >> >> And my life is way easier. Retirement (from teaching) is just terrific. >> The bicycling season is just about over here; looks like I will hit 4000 km >> this year. >> >> Drop me a line and tell me how you are doing. >> >> Bob >> >> -- >> Robert M. Hanson >> Professor of Chemistry, Emeritus >> 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 >> > -- Robert M. Hanson Professor of Chemistry, Emeritus 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...> - 2023-11-16 22:00:37
|
That's great! I did once try to compile Jmol, but I ran into those issues (Eclipse version, Java 6, etc). This should make it easier for others to contribute. Thanks, Mark On Thu, Nov 16, 2023 at 9:59 AM Robert Hanson via Jmol-developers < jmo...@li...> wrote: > Jmol Developers, > > Not sure if you are on this list you still have any interest in Jmol, but > I hope some of you do. > > Well, it's done. The JSmol sourceforge project at > https://sourceforge.net/p/jsmol is now no longer needed. I've placed all > the files that were in that project into the /unused/ folder there. This is > so that we still can track the histories of the files if we need to. But > probably that will not be necessary. > > This past week I totally overhauled the way the transpiler works. For the > past 10 years, the transpiler that was being used for Jmol only worked in a > very old version of Eclipse "Juno" from (I think) 2013. This has been an > enormous pain. For at least eight years I have avoided doing anything with > this old transpiler. > > I finally took the step to revisit the prototype "java2script 4.2" code > from 2013, and I realized that it was not so bad and that would be possible > to add that code to the SwingJS transpiler plugin as an alternative > transpiler option. > > That has worked perfectly. The new plugin is j2s.core_5.0.1.jar, at > https://github.com/BobHanson/java2script/tree/master/sources/net.sf.j2s.core > > And, as a bonus, we now can adapt the legacy 4.2 transpiler, which is only > ever to be used with Jmol anyway, to future needs. The first thing I did > was move it up to Java 8 (Though it still only recognizes Java 6 syntax.) > One of the things I did was to give it a way to deliver JavaScript code > ready for running directly into the site/ directory. This was huge, because > previously there were a series of ANT tasks that had to be run to do all > sorts of minor tweaking of that output before one could test in JavaScript. > > But now, it's very clean and simple. You modify Java code for Jmol, save > the .java file, and open your browser to see how it runs in JavaScript. > Your changes are instantly there. Full integration. The way it should be. > Hooray! > > And then I realized that we didn't need the JSmol project at all. > Originally, the idea was to do all the transpiling in this separate > project, just using the code that relates to the applet. But now this is > not necessary. Once I got the transpiler doing what the ANT tasks were > doing (and I was able to fix the various bugs in the 4.2 transpiler that > were causing these problems in the first place), I realized that the only > thing the JSmol project was doing (yesterday) was to add some more files. > So I figured I would just put those files in the Jmol project (into > site-resources/ and site-resources-zip). That's all checked in now. > > Happy to report that that went smoothly, and I was able to fix a few more > bugs while at it. > > So, in short, the Jmol project is alive and well at SourceForge, now using > the same transpiler plugin as SwingJS. Just the two projects - Jmol, on > SourceForge, and java2script on GitHub. (OK, there's also the Jmol-SwingJS > GitHub project, that's true.) No old versions of Eclipse are necessary. So > long, Luna!! There's just the one plugin. > > And my life is way easier. Retirement (from teaching) is just terrific. > The bicycling season is just about over here; looks like I will hit 4000 km > this year. > > Drop me a line and tell me how you are doing. > > Bob > > -- > Robert M. Hanson > Professor of Chemistry, Emeritus > 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...> - 2023-11-16 17:59:25
|
Jmol Developers, Not sure if you are on this list you still have any interest in Jmol, but I hope some of you do. Well, it's done. The JSmol sourceforge project at https://sourceforge.net/p/jsmol is now no longer needed. I've placed all the files that were in that project into the /unused/ folder there. This is so that we still can track the histories of the files if we need to. But probably that will not be necessary. This past week I totally overhauled the way the transpiler works. For the past 10 years, the transpiler that was being used for Jmol only worked in a very old version of Eclipse "Juno" from (I think) 2013. This has been an enormous pain. For at least eight years I have avoided doing anything with this old transpiler. I finally took the step to revisit the prototype "java2script 4.2" code from 2013, and I realized that it was not so bad and that would be possible to add that code to the SwingJS transpiler plugin as an alternative transpiler option. That has worked perfectly. The new plugin is j2s.core_5.0.1.jar, at https://github.com/BobHanson/java2script/tree/master/sources/net.sf.j2s.core And, as a bonus, we now can adapt the legacy 4.2 transpiler, which is only ever to be used with Jmol anyway, to future needs. The first thing I did was move it up to Java 8 (Though it still only recognizes Java 6 syntax.) One of the things I did was to give it a way to deliver JavaScript code ready for running directly into the site/ directory. This was huge, because previously there were a series of ANT tasks that had to be run to do all sorts of minor tweaking of that output before one could test in JavaScript. But now, it's very clean and simple. You modify Java code for Jmol, save the .java file, and open your browser to see how it runs in JavaScript. Your changes are instantly there. Full integration. The way it should be. Hooray! And then I realized that we didn't need the JSmol project at all. Originally, the idea was to do all the transpiling in this separate project, just using the code that relates to the applet. But now this is not necessary. Once I got the transpiler doing what the ANT tasks were doing (and I was able to fix the various bugs in the 4.2 transpiler that were causing these problems in the first place), I realized that the only thing the JSmol project was doing (yesterday) was to add some more files. So I figured I would just put those files in the Jmol project (into site-resources/ and site-resources-zip). That's all checked in now. Happy to report that that went smoothly, and I was able to fix a few more bugs while at it. So, in short, the Jmol project is alive and well at SourceForge, now using the same transpiler plugin as SwingJS. Just the two projects - Jmol, on SourceForge, and java2script on GitHub. (OK, there's also the Jmol-SwingJS GitHub project, that's true.) No old versions of Eclipse are necessary. So long, Luna!! There's just the one plugin. And my life is way easier. Retirement (from teaching) is just terrific. The bicycling season is just about over here; looks like I will hit 4000 km this year. Drop me a line and tell me how you are doing. Bob -- Robert M. Hanson Professor of Chemistry, Emeritus 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...> - 2023-05-19 10:18:22
|
Please send the file to ha...@st... On Fri, May 19, 2023, 3:24 AM Angel Herraez <ang...@ua...> wrote: > Hello, Sinchul > > Unfortunately, the administrative interface of the email lists does not > allow us to see the list of email addresses of members. > Are you sure you signed up for the developers list in addition to the > users list? They are independent. > On the other hand, there is a separate interface for bug reports, under > "Tickets" > https://sourceforge.net/p/jmol/bugs/ > > Regarding your problem, I cannot offer you advice, I am not familiar with > that format but some else may do. > It will always be helpful to share your file where you see the problem. > > Regards, > > ------------------------------ > *De:* Sinchul Yeom <ta...@gm...> > *Enviado:* viernes, 19 de mayo de 2023 8:42 > *Para:* jmo...@li... < > jmo...@li...> > *Asunto:* Re: load fill bug (v >= 14.32?) > > Hi, > > I'd like to report this bug and I'm in the user list. > > Thanks! > Sinchul > > On Fri, May 19, 2023 at 2:35 AM < > jmo...@li...> wrote: > > You are not allowed to post to this mailing list, and your message has > been automatically rejected. You will be able to post if you sign up > as a user of the list. If you think that your messages are being > rejected in error, contact the mailing list owner at > jmo...@li... > > > > > ---------- Forwarded message ---------- > From: Sinchul Yeom <ta...@gm...> > To: jmo...@li... > Cc: > Bcc: > Date: Fri, 19 May 2023 02:34:47 -0400 > Subject: load fill bug (v >= 14.32?) > Hi, > > I'm a big fan of jmol script. I admire the Jmol script's very systematic > design and flexibility and extensibility!! Anyway, I would like to report > load fill bugs. > > ** I found loading a certain aims geometry file with fill command fails > with the following error:* > Script ERROR: No atoms found > for file /home/taegul/.bin/jmol-16.1.9/geometry_4.in > type Aims > ---- > load "geometry_4.in" fill [ { 0 0 0 } { 20 20 20 } <<<<] > $ > Considering the lattice parameter is 4.45, 20 is enough length to include > atoms. > > * *Also, if some of the atoms are outside of the unit cell, several atoms > don't appear when loaded with the fill command. * > > It looks like this started happening since version 14.32.xx. I found > 14.31.36 doesn't have this problem, but 14.32.83, 16.1.9, and 16.1.11 have > this bug. > > This is my geometry file and I also attach it. > Thank you, > Sinchul > > geometry_4.in > ============================================ > lattice_vector 4.4530751600000000 -0.0000000000000000 -0.0000000000000000 > lattice_vector -0.0000000000000000 4.4530793900000001 0.0000000000000000 > lattice_vector -0.0000000000000000 -0.0000000000000000 4.4530793900000001 > atom_frac 0.9999856499999999 0.9999968500000002 0.9999966400000001 Sc > atom_frac 0.9999855000000001 0.5000029300000000 0.5000035800000000 Sc > atom_frac 0.5000142900000000 0.9999965799999999 0.5000034300000000 Sc > atom_frac 0.5000145499999999 0.5000036400000000 0.9999963500000002 Sc > ============================================ > > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers > |
From: Angel H. <ang...@ua...> - 2023-05-19 08:23:57
|
Hello, Sinchul Unfortunately, the administrative interface of the email lists does not allow us to see the list of email addresses of members. Are you sure you signed up for the developers list in addition to the users list? They are independent. On the other hand, there is a separate interface for bug reports, under "Tickets" https://sourceforge.net/p/jmol/bugs/ Regarding your problem, I cannot offer you advice, I am not familiar with that format but some else may do. It will always be helpful to share your file where you see the problem. Regards, ________________________________ De: Sinchul Yeom <ta...@gm...> Enviado: viernes, 19 de mayo de 2023 8:42 Para: jmo...@li... <jmo...@li...> Asunto: Re: load fill bug (v >= 14.32?) Hi, I'd like to report this bug and I'm in the user list. Thanks! Sinchul On Fri, May 19, 2023 at 2:35 AM <jmo...@li...<mailto:jmo...@li...>> wrote: You are not allowed to post to this mailing list, and your message has been automatically rejected. You will be able to post if you sign up as a user of the list. If you think that your messages are being rejected in error, contact the mailing list owner at jmo...@li...<mailto:jmo...@li...> ---------- Forwarded message ---------- From: Sinchul Yeom <ta...@gm...<mailto:ta...@gm...>> To: jmo...@li...<mailto:jmo...@li...> Cc: Bcc: Date: Fri, 19 May 2023 02:34:47 -0400 Subject: load fill bug (v >= 14.32?) Hi, I'm a big fan of jmol script. I admire the Jmol script's very systematic design and flexibility and extensibility!! Anyway, I would like to report load fill bugs. * I found loading a certain aims geometry file with fill command fails with the following error: Script ERROR: No atoms found for file /home/taegul/.bin/jmol-16.1.9/geometry_4.in<http://geometry_4.in/> type Aims ---- load "geometry_4.in<http://geometry_4.in/>" fill [ { 0 0 0 } { 20 20 20 } <<<<] $ Considering the lattice parameter is 4.45, 20 is enough length to include atoms. * Also, if some of the atoms are outside of the unit cell, several atoms don't appear when loaded with the fill command. It looks like this started happening since version 14.32.xx. I found 14.31.36 doesn't have this problem, but 14.32.83, 16.1.9, and 16.1.11 have this bug. This is my geometry file and I also attach it. Thank you, Sinchul geometry_4.in<http://geometry_4.in/> ============================================ lattice_vector 4.4530751600000000 -0.0000000000000000 -0.0000000000000000 lattice_vector -0.0000000000000000 4.4530793900000001 0.0000000000000000 lattice_vector -0.0000000000000000 -0.0000000000000000 4.4530793900000001 atom_frac 0.9999856499999999 0.9999968500000002 0.9999966400000001 Sc atom_frac 0.9999855000000001 0.5000029300000000 0.5000035800000000 Sc atom_frac 0.5000142900000000 0.9999965799999999 0.5000034300000000 Sc atom_frac 0.5000145499999999 0.5000036400000000 0.9999963500000002 Sc ============================================ |
From: Angel H. <ang...@ua...> - 2023-02-03 17:27:01
|
We are aware. Jaime Prilusky has the control of the wiki server and already has the plan to update the security certificate. Meanwhile, the wiki works fine if you use your browser's dialogues to accept the server as an exception. Dr. Angel Herráez Biochemistry and Molecular Biology, Dept. of Systems Biology, University of Alcalá E-28805 Alcalá de Henares (Madrid), Spain http://biomodel.uah.es/ |
From: Robert H. <ha...@st...> - 2023-02-03 16:00:28
|
Not by me, Bruce. Who knows how to do this? On Fri, Feb 3, 2023 at 7:57 AM Bruce Tattershall < bru...@ne...> wrote: > I am getting a warning that the security certificate for the Jmol https: > wiki website has expired. Please can this be fixed? > > Thanks > Bruce > > Sent from Tablet > _______________________________________________ > Jmol-users mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-users > -- 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: Jonathan G. <gu...@uw...> - 2022-10-25 03:48:07
|
I am running into issues getting a development environment up and running and successfully building Jmol. I have backed down to the simplest thing I think I can build, just the test applet using GIT/Jmol-SwingJS/build-app-only.xml. Once I get that to work, I will proceed to more complex builds with translation, etc. Running this build on the latest commit gives about 100 deprecation warnings and the following errors: [javac] /home/jonathan/GIT/Jmol-SwingJS/src/jspecview/application/AwtTreeNode.java:21: error: children() in AwtTreeNode cannot override children() in DefaultMutableTreeNode [javac] public Enumeration<JSVTreeNode> children() { [javac] ^ [javac] return type Enumeration<JSVTreeNode> is not compatible with Enumeration<TreeNode> [javac] /home/jonathan/GIT/Jmol-SwingJS/src/jspecview/application/AwtTreeNode.java:22: error: incompatible types: Enumeration<TreeNode> cannot be converted to Enumeration<JSVTreeNode> [javac] return super.children(); [javac] /home/jonathan/GIT/Jmol-SwingJS/src/org/jmol/applet/Jmol.java:303: error: cannot find symbol [javac] jsoWindow = JSObject.getWindow(applet); [javac] ^ [javac] symbol: method getWindow(JApplet) [javac] location: class JSObject Am I even remotely on the correct track? It looks like problems in both Jmol and jspecview. Thanks, Jonathan Dr. Jonathan Gutow Halsey Room 412 Chemistry Department UW Oshkosh web: https://cms.gutow.uwosh.edu/Gutow<https://cms.uwosh.edu/G> e-mail: gu...@uw... Ph: 920-424-1326 |
From: Jonathan G. <gu...@uw...> - 2022-10-07 14:32:23
|
One of my colleagues is trying to use the Jmol Export to Web function in a class. They are using one of the recent releases. Something has broken in building the webpage directories after 14.30.2, where I can still get it to work. Sometime after that something changed that terminates the file creation after adding the support javascript file(s) and the .png files. The following files are not created or copied and should be: jsmol.zip, data files or gz compressed versions, .spt files and the .html file. I am just going to tell her to downgrade to 14.30.2, but if anybody has a clue as to what has happened I would appreciate it. I wrote much of the code for that package, but have not worked on it in ages. If I can find some time, I will try to fix it. I think the object containing the list of files to write got deleted from the code. Thanks, Jonathan Dr. Jonathan Gutow Halsey Science Room 412 Chemistry Department UW Oshkosh web: https://cms.gutow.uwosh.edu/Gutow e-mail: gu...@uw...<mailto:gu...@uw...> Ph: 920-424-1326 |
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 |