From: <rka...@ri...> - 2006-03-29 22:39:49
|
Hi, I was wondering whether it was deliberate that the modifications that =20= Bob and I made to the SpartanSmolReader (reading the ARCHIVE =20 information) is not in the repository anymore... Also the GaussianReader is rolled back to a version that in =20 combination with the Resolver older version will not be able to read =20 all the Gaussian test files... Ren=E9 |
From: Miguel <mi...@jm...> - 2006-03-30 01:29:07
|
Ren=E9 wrote: > I was wondering whether it was deliberate that the modifications that > Bob and I made to the SpartanSmolReader (reading the ARCHIVE > information) is not in the repository anymore... Rene, I rolled back to 10.00.48 and reapplied patches selectively. These enhancements are still on the list of things I need to look at and reapply. > Also the GaussianReader is rolled back to a version that in > combination with the Resolver older version will not be able to read > all the Gaussian test files... I'll let you know if I have any questions. Miguel |
From: Bob H. <ha...@st...> - 2006-03-30 10:58:19
|
Miguel, could you please give us a full rundown of what's on your list? Thanks, Bob Miguel wrote: > Ren=E9 wrote: >=20 >=20 >>I was wondering whether it was deliberate that the modifications that >>Bob and I made to the SpartanSmolReader (reading the ARCHIVE >>information) is not in the repository anymore... >=20 >=20 > Rene, >=20 > I rolled back to 10.00.48 and reapplied patches selectively. >=20 > These enhancements are still on the list of things I need to look at an= d > reapply. >=20 >=20 >>Also the GaussianReader is rolled back to a version that in >>combination with the Resolver older version will not be able to read >>all the Gaussian test files... >=20 >=20 > I'll let you know if I have any questions. >=20 >=20 > Miguel >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live we= bcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd____________________________________= ___________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers --=20 -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2006-03-30 14:22:14
|
Bob wrote: > Miguel, could you please give us a full rundown of what's on your list?= Bob, thank you for your recommendation that I organize and publish the punch list. Despite some strong evidence to the contrary (e.g. my unilateral decision= to roll back the codebase), I *am* interested in people's input and assistance in getting this release out the door. I would like to do the 10.1 release on or before Mon 3 April 2006. I would like to fix bugs and reintroduce a few isolated features prior to= the 10.1 release. My rule-of-thumb criteria (or wishes) are: * Bug fixes should be isolated to 1 or 2 source files. * Features should be isolated to something like 4 source files ... major= changes in 1 source file + minor edits in 3 source files. This list shows my current thinking on submissions to the repository in Feb & March 2006. It is separated into 'prior' and 'post' the 10.1 release. There is a lot of stuff here. I am interested in your thoughts/feedback. Miguel Review prior to 10.1 release =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Bug related ----------- r4556,r4557 - hbond problems r4527 - restrict with backbone + atomPicked status report r4508 - colorConvex r4686 - statementLength checks Reader/File related ------------------- r4657 - Gaussian + resolver r4624,r4625,r4630 - auxiliaryInfo r4623,r4635,r4640 - SpartanSmolReader r4501 - modelNumber for non-pdb + getCurrentFileContents Script related -------------- r4507 - multiple expressions for connect and monitor r4522 - adds radius to connect r4551,r4555 - monitor changes r4664,r4666 - connected() script operator + within() changes Feature related --------------- r4504,r4506 - frame play ?? Don't mnow whether or not this involved changes to the threading model ?? r4659,r4662,r4663,r4668,r4669,r4674 - polyhedra ?? Why was an Atom constructor introduced that creates a fake/artificial atom ?? Review post 10.1 release =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Applet event model + model info ------------------------------- r4445-r4461 - getAppletInfo work - at a minimum needs a method name chang= e because getAppletInfo is part of java.awt.Applet public interface. Perhap= s this was replaced by some form of getProperty. r4447-r4470 - applet getProperty r4472 - JSON r4475,r4476 - applet.loadLinee + getProperty r4477,r4560,r4651 - event queuing/polling - applet synchronization r4480,r4483 - statusManager / propertyManager r4500 - scriptWait with JSON r4509 - isPredefining + atomInfo r4512 - statusManager + animation + compiler define/=40 r4516-r4519 - atomInfo + JSON r4523,r4525 - getProperty(=22modelInfo=22) r4528 - statusManager + pmesh r4530 - orientationInfo change r4531 - statusManager + propertyManager r4533 - refresh() in evalExpression r4545 - getProperty() r4550 - viewer.script() -> viewer.evalStringQuiet() Atom visibility --------------- r4537,r4539,r4541,r4543,r4545,r4598,r4599 - atom visibility + tainted transformation/spin/camera related ---------------------------------- r4586,r4587,r4591,r4593,r4606,r4608,r4610,r4627,r4633,r4638,r4650, r4688,r4689,r4690, - spin, rotate, internal coordinates, windowCentered Reader/File related ------------------- r4558 - amino read Featire related --------------- r4562,r4563,r4567,r4570,r4658 - draw r4614,r4621 - =23jmolscript in AtomSetCollectionReader Unknown ------- r4655 - ? spin + compiler + bug + Float.MIN_VALUE r4685 - ? movement of code from Eval to Viewer r4529 - ? multifile not showing bonds Deprecated (not a complete list) -------------------------------- r4474 - connect STATIC - deprecated bondorder - deprecated |
From: Bob H. <ha...@st...> - 2006-03-30 15:29:55
|
Thanks, Miguel. This is a good starting point, I think. Miguel wrote: My rule-of-thumb criteria (or wishes) are: * Bug fixes should be isolated to 1 or 2 source files. One would hope. * Features should be isolated to something like 4 source files ... major changes in 1 source file + minor edits in 3 source files. This latter won't always be possible. In general, a new script command requires changes to Token, Eval, Viewer, JmolConstants, Frame, ModelManager, and possibly new classes. I would like to add: * All new features to be discussed and agreed upon by consensus on this list prior to implementation. * All commits isolated to one specific topic. * Use of Eclipse autoformating requested at least as a starting point for all new methods. * No use of file-wide autoformating. Ever. * No changes "just to clean up the formatting." Miguel wrote: > > Script related > -------------- > > r4507 - multiple expressions for connect and monitor > > r4522 - adds radius to connect > > r4551,r4555 - monitor changes > > r4664,r4666 - connected() script operator + within() changes connected() is fantastic. Please restore as implemented. > > > Feature related > --------------- > > r4504,r4506 - frame play ?? Don't mnow whether or not this involved > changes to the threading model ?? Key here is the concept of frame RANGE, which was difficult to implement correctly. Substantial changes here to all handling of current model display and handling of model visibility. Not sure what you mean by "threading model" in this context, but the changes implemented are important. What is changed is not the model, as I see it, but the way the "next frame" is selected. Please restore this in its entirety. > > r4659,r4662,r4663,r4668,r4669,r4674 - polyhedra ?? Why was an Atom > constructor introduced that creates a fake/artificial atom ?? > This is necessary because the centerpoint of the "collapsed" polyhedron is not an atom, it is a projected point from the central atom. So it has xyz and screen coordinates only. I like your idea that "Atom" should be an extension of "Point" and that this should be a Point. > > > Review post 10.1 release > ======================== > > Applet event model + model info > ------------------------------- > > r4445-r4461 - getAppletInfo work - at a minimum needs a method name change > because getAppletInfo is part of java.awt.Applet public interface. Perhaps > this was replaced by some form of getProperty. I originally introduced this as a sort of getProperty, but then in response to your concerns changed it to the standard: Syntax: String getAppletInfo() Returns: String Description: This method returns the Applet producer and copyright I would like that functionality returned (involves Viewer functions that can deliver this information) so that JavaScript and other apps can read the Jmol version/date and OS information as I had set up. > > r4447-r4470 - applet getProperty this was later also introduced as a script command. That will be quite useful. > > r4472 - JSON > > r4475,r4476 - applet.loadLinee + getProperty > > r4477,r4560,r4651 - event queuing/polling - applet synchronization > > r4480,r4483 - statusManager / propertyManager I'm looking forward to your implementation ideas here. > > r4500 - scriptWait with JSON or not -- just don't return a Java object to JavaScript. It will be a true support headache. > > r4509 - isPredefining + atomInfo > > r4512 - statusManager + animation + compiler define/@ (Two together.) The key here is that we have a fundamental flaw in the handling of user-defined terms. If we allow this, which we must, then we need to allow people to override current Tokenized terms, only warning them via System.out. Otherwise, as we add new tokens, SOMEONE out there might have an instantly broken page. We must reserve the right to add new tokens; we should not make that break pages. The compromise is that introduction of a new token, in this case "prev" for the frame business, if it conflicts with a user definition (Otto's, as I recall), should gracefullly notify but not disallow that overloading. Chances are the functionality introduced are not used in any current application EXCEPT in this "define" context. Please restore. > > r4516-r4519 - atomInfo + JSON > > r4523,r4525 - getProperty("modelInfo") > etc., etc. > r4528 - statusManager + pmesh The inline pmesh idea may be unnecessary now with draw; Easy enough to put in though, and it allows for simple testing of pmesh. Not a priority > > r4530 - orientationInfo change > > r4531 - statusManager + propertyManager > Somewhere in there is the whole business of "state" that I introduced. Please restore. > r4533 - refresh() in evalExpression no longer necessary. This should be handled by the Viewer modifications that checks model visibility, with abstraction of all unnecessary checking of states in renderers and the addition of Atom and other class visibility flags. > > r4545 - getProperty() > > r4550 - viewer.script() -> viewer.evalStringQuiet() This has to do with the App not notifying the status manager when menu items are selected, I think. > > > Atom visibility > --------------- > > r4537,r4539,r4541,r4543,r4545,r4598,r4599 - atom visibility + tainted critical. > > > transformation/spin/camera related > ---------------------------------- > r4586,r4587,r4591,r4593,r4606,r4608,r4610,r4627,r4633,r4638,r4650, > r4688,r4689,r4690, - spin, rotate, internal coordinates, windowCentered > This will keep you busy. :) changes we discussed on Sunday involving Viewer.getDefaultRotationCenter() that fixes Frieda-like jumps and permanently stabilizes model from "walking" into the camera. > > > Reader/File related > ------------------- > > r4558 - amino read I don't think this is mine. > > Featire related > --------------- > > r4562,r4563,r4567,r4570,r4658 - draw This should be relatively painless. Add the classes; stitch in the Compiler/Eval/Token/JmolConstants business. > > r4614,r4621 - #jmolscript in AtomSetCollectionReader and Spartan SMOL reader and Xyz reader and related functions; > > > Unknown > ------- > > r4655 - ? spin + compiler + bug + Float.MIN_VALUE You'll have to look carefully at the compiler code changes there; I can't remember specifically. If you mean "the smallest positive number" -- something like 1E-45, then leave it; if you mean "the most negative number" (which I think you do, in some cases) then you want -Float.MAX_VALUE > > r4685 - ? movement of code from Eval to Viewer Actually, this is all to Frame, via Viewer and modelManager. The programming model had been "just do atom-bitset construction in Eval" such as getNucleic() getProtein() and such (I can't remember the exact names) even though all these have nothing to do with scripting. I moved them to Frame and then created a standard set of interfaces via Viewer that accessed them using just a couple of generic functions. We need to do this because there is a general need to create bitsets outside of the Eval framework. I'm forgetting the exact point of need, but once one was needed, the rest naturally followed. As I did this I found a bug in the resno/chain specification business. That needs fixing prior to 10.1. > > r4529 - ? multifile not showing bonds These are ongoing changes needed to display multiple files. It's a work in progress. Please restore it. > > > Deprecated (not a complete list) > -------------------------------- > > r4474 - connect STATIC - deprecated That's connect EXISTS, right? > > bondorder - deprecated > I guess I'm OK with that. It does have a use, vaguely. Other concerns Bob has ---------------------- --Your schedule is very ambitious. --The frame business was especially tricky. It's very important functionality but quite complex. I would like all of the model display and visibility flag business that I introduced to be restored, as it is critical functionality and needs very careful implementation. I think part of this is in JmolConstants. Check the end of ModelManager for the central methods. --The new streamlined handling of all transformations in terms of two entrant "internal" an "fixed" methods is critical. There are important tie-ins to the MouseManager or PickingManager (can't remember which). --I'd like to add dipoles before 10.1. The code is all there (on my local set); it just needs inclusion. This was discussed at the ACS meeting, and I promised it to John Gelder. It involves three classes: Dipole, Dipoles, and DipolesRenderer, and Eval. It's a fundamentally new class -- sort of a mix of Rasmol-like cartoon and atom-based vector. The dipole information from Spartan SMOL files is read and stored in atomSetCollectionAuxiliaryInfo. Spartan partial charges are also read, and general utilities to install auxiliaryInfo into the partialCharges array are included. Bond dipoles are calculated from partial charges. --I'm assuming this is the full list of commits, including those prior to SVN implemenation. -- -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2006-03-30 17:12:13
|
Bob wrote: > This latter won't always be possible. In general, a new > script command requires changes to Token, Eval, Viewer, > JmolConstants, Frame, ModelManager, and > possibly new classes. Changes of this magnitude are particularly the ones that I am uncomfortable with. > I would like to add: > > * All new features to be discussed and agreed upon by > consensus on this list prior to implementation. > * All commits isolated to one specific topic. > * Use of Eclipse autoformating requested at least as > a starting point for all new methods. > * No use of file-wide autoformating. Ever. > * No changes =22just to clean up the formatting.=22 Good topics of discussion for going forward ... after this release. =5Bsnip=5D >> Feature related >> --------------- >> r4504,r4506 - frame play ?? Don't mnow whether >> or not this involved changes to the threading model ?? =5Bsnip=5D >> r4659,r4662,r4663,r4668,r4669,r4674 - polyhedra >> ?? Why was an Atom constructor introduced that creates >> a fake/artificial atom ?? Based upon your characterization of the complexity, neither of these features will make it in to the 10.1 release. =5Bsnip=5D > Other concerns Bob has > ---------------------- > > --Your schedule is very ambitious. The whole purpose of my 'rollback' decision was to make an attempt to be less ambitious. There are a number of Jmol users who are still running the 10.00 release ... from over a year ago. Those users should get a new release, especial= ly prior to the addition of lots of new features and potential restructuring= of system internals. I made a mistake by not releasing 'official' releases more frequently. We will make 'official' releases more frequently going forward. The exact= schedule will be a good topic of discussion ... after this release. > --I'd like to add dipoles before 10.1. The code is all > there (on my local set); Bob, I am sure that it is great ... like all of the features that you hav= e worked on in the past 2 months. But this feature will not go into the 10.1 release. These major features are exactly the things that I am eliminating from the release. There was over a year of changes prior to your getting actively involved in coding in Feb 2006. Those changes, in and of themselves, are some caus= e for concern. As I have said, it is clear that I should have made more frequent 'official' releases and that would have avoided some of this. I believe that it is best for Jmol that we release stable code. I believe= that it is best for Jmol if we have a good reputation for code quality so= that people are eager to upgrade, not reluctant to upgrade. You may disagree with my decision. But please believe that my intentions are good and are based upon my experience in the software industry. I am going to push out the 10.1 release ... then we will talk about how w= e should structure things going forward. Miguel |
From: Bob H. <ha...@st...> - 2006-03-30 17:39:17
|
Miguel wrote: > Bob wrote: > >>This latter won't always be possible. In general, a new >>script command requires changes to Token, Eval, Viewer, >>JmolConstants, Frame, ModelManager, and >>possibly new classes. > > > Changes of this magnitude are particularly the ones that I am > uncomfortable with. This isn't large; it's just some stitching that has to be done. Eval needs a token and possibly a constant; doing anything in Frame requires relay functions from Viewer through ModelManager. Shouldn't be a big deal. > > >>--I'd like to add dipoles before 10.1. The code is all >>there (on my local set); > > > But this feature will not go into the 10.1 release. These major features > are exactly the things that I am eliminating from the release. not a problem. Get as much as you feel comfortable with into 10.1. -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2006-03-30 18:46:27
|
> Review prior to 10.1 release > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =5Bsnip=5D > Reader/File related > ------------------- > > r4657 - Gaussian + resolver reintroduced in r4854 Q: Which Gaussian file had a problem so that it required reading 16 lines= in order to resolve the file format? Miguel |
From: <rka...@ri...> - 2006-03-31 00:27:22
|
Hi Miguel, the file in question was: ch2chfme_reagent.out which has some =20 additional lines in the beginning because I think it was run from a =20 batch system (nice), so the 'Entering Gaussian System' comes in a bit =20= later. Ren=E9 On Mar 30, 2006, at 1:46 PM, Miguel wrote: >> Review prior to 10.1 release >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > [snip] > >> Reader/File related >> ------------------- >> >> r4657 - Gaussian + resolver > > reintroduced in r4854 > > Q: Which Gaussian file had a problem so that it required reading 16 =20= > lines > in order to resolve the file format? > > > Miguel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers |
From: Bob H. <ha...@st...> - 2006-03-31 02:20:27
|
by the way, this is generating error flags in the XYZreader for small fil= es.=20 (Load H2O.xyz and check for system.out messages.) At least it was recentl= y. Ren=E9 Kanters wrote: > Hi Miguel, >=20 > the file in question was: ch2chfme_reagent.out which has some =20 > additional lines in the beginning because I think it was run from a =20 > batch system (nice), so the 'Entering Gaussian System' comes in a bit =20 > later. >=20 > Ren=E9 >=20 >=20 > On Mar 30, 2006, at 1:46 PM, Miguel wrote: >=20 >>> Review prior to 10.1 release >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >> >> >> [snip] >> >>> Reader/File related >>> ------------------- >>> >>> r4657 - Gaussian + resolver >> >> >> reintroduced in r4854 >> >> Q: Which Gaussian file had a problem so that it required reading 16 =20 >> lines >> in order to resolve the file format? >> >> >> Miguel >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 >> language >> that extends applications into web and mobile media. Attend the live=20 >> webcast >> and join the prime developer group breaking into this new coding =20 >> territory! >> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=1216= 42 >> _______________________________________________ >> Jmol-developers mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-developers >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live=20 > webcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd____________________________________= ___________=20 >=20 > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers --=20 -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: <rka...@ri...> - 2006-03-31 02:45:26
|
Bob, I do not see an H2O.xyz file in the Jmol-datafiles. I do see a =20 CS2.xyz but that seems to read fine. Ren=E9 On Mar 30, 2006, at 9:20 PM, Bob Hanson wrote: > by the way, this is generating error flags in the XYZreader for =20 > small files. (Load H2O.xyz and check for system.out messages.) At =20 > least it was recently. > > > > Ren=E9 Kanters wrote: > >> Hi Miguel, >> the file in question was: ch2chfme_reagent.out which has some =20 >> additional lines in the beginning because I think it was run from =20 >> a batch system (nice), so the 'Entering Gaussian System' comes in =20= >> a bit later. >> Ren=E9 >> On Mar 30, 2006, at 1:46 PM, Miguel wrote: >>>> Review prior to 10.1 release >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>> >>> >>> [snip] >>> >>>> Reader/File related >>>> ------------------- >>>> >>>> r4657 - Gaussian + resolver >>> >>> >>> reintroduced in r4854 >>> >>> Q: Which Gaussian file had a problem so that it required reading =20 >>> 16 lines >>> in order to resolve the file format? >>> >>> >>> Miguel >>> >>> >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by xPML, a groundbreaking =20 >>> scripting language >>> that extends applications into web and mobile media. Attend the =20 >>> live webcast >>> and join the prime developer group breaking into this new coding =20= >>> territory! >>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=1216= 42 >>> _______________________________________________ >>> Jmol-developers mailing list >>> Jmo...@li... >>> https://lists.sourceforge.net/lists/listinfo/jmol-developers >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20= >> language >> that extends applications into web and mobile media. Attend the =20 >> live webcast >> and join the prime developer group breaking into this new coding =20 >> territory! >> http://sel.as-us.falkag.net/sel?=20 >> cmd_______________________________________________ Jmol-developers =20= >> mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-developers > > --=20 > -- > > Robert M. Hanson, ha...@st..., 507-646-3107 > Professor of Chemistry, St. Olaf College > 1520 St. Olaf Ave., Northfield, MN 55057 > mailto:ha...@st... > http://www.stolaf.edu/people/hansonr > > "Imagination is more important than knowledge." - Albert Einstein > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 > language > that extends applications into web and mobile media. Attend the =20 > live webcast > and join the prime developer group breaking into this new coding =20 > territory! > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642= > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers |
From: Miguel <mi...@jm...> - 2006-03-31 03:18:31
|
> Bob, > > I do not see an H2O.xyz file in the Jmol-datafiles. I do see a > CS2.xyz but that seems to read fine. > > Ren=E9 > > On Mar 30, 2006, at 9:20 PM, Bob Hanson wrote: > >> by the way, this is generating error flags in the XYZreader for >> small files. (Load H2O.xyz and check for system.out messages.) At >> least it was recently. It is complaining because the input buffer is too short. The resolver used to read only 4 lines from each file. With the change to 16 lines, the resolver is complaining that it is not getting enough lines from short files. We can turn off the logged complaints. Miguel |
From: Bob H. <ha...@st...> - 2006-03-31 10:59:52
|
please turn off the logger. Miguel wrote: >>Bob, >> >>I do not see an H2O.xyz file in the Jmol-datafiles. I do see a >>CS2.xyz but that seems to read fine. >> >>Ren=E9 >> >>On Mar 30, 2006, at 9:20 PM, Bob Hanson wrote: >> >> >>>by the way, this is generating error flags in the XYZreader for >>>small files. (Load H2O.xyz and check for system.out messages.) At >>>least it was recently. >=20 >=20 > It is complaining because the input buffer is too short. >=20 > The resolver used to read only 4 lines from each file. >=20 > With the change to 16 lines, the resolver is complaining that it is not > getting enough lines from short files. >=20 > We can turn off the logged complaints. >=20 >=20 > Miguel >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live we= bcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd____________________________________= ___________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers --=20 -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Bob H. <ha...@st...> - 2006-03-31 11:00:21
|
sorry, CS2.xyz is fine. Ren=E9 Kanters wrote: > Bob, >=20 > I do not see an H2O.xyz file in the Jmol-datafiles. I do see a CS2.xyz= =20 > but that seems to read fine. >=20 > Ren=E9 >=20 > On Mar 30, 2006, at 9:20 PM, Bob Hanson wrote: >=20 >> by the way, this is generating error flags in the XYZreader for small= =20 >> files. (Load H2O.xyz and check for system.out messages.) At least it=20 >> was recently. >> >> >> >> Ren=E9 Kanters wrote: >> >>> Hi Miguel, >>> the file in question was: ch2chfme_reagent.out which has some =20 >>> additional lines in the beginning because I think it was run from a = =20 >>> batch system (nice), so the 'Entering Gaussian System' comes in a=20 >>> bit later. >>> Ren=E9 >>> On Mar 30, 2006, at 1:46 PM, Miguel wrote: >>> >>>>> Review prior to 10.1 release >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D >>>> >>>> >>>> >>>> [snip] >>>> >>>>> Reader/File related >>>>> ------------------- >>>>> >>>>> r4657 - Gaussian + resolver >>>> >>>> >>>> >>>> reintroduced in r4854 >>>> >>>> Q: Which Gaussian file had a problem so that it required reading =20 >>>> 16 lines >>>> in order to resolve the file format? >>>> >>>> >>>> Miguel >>>> >>>> >>>> >>>> ------------------------------------------------------- >>>> This SF.Net email is sponsored by xPML, a groundbreaking scripting = =20 >>>> language >>>> that extends applications into web and mobile media. Attend the =20 >>>> live webcast >>>> and join the prime developer group breaking into this new coding =20 >>>> territory! >>>> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=12= 1642 >>>> _______________________________________________ >>>> Jmol-developers mailing list >>>> Jmo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers >>> >>> ------------------------------------------------------- >>> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 >>> language >>> that extends applications into web and mobile media. Attend the live= =20 >>> webcast >>> and join the prime developer group breaking into this new coding =20 >>> territory! >>> http://sel.as-us.falkag.net/sel?=20 >>> cmd_______________________________________________ Jmol-developers =20 >>> mailing list >>> Jmo...@li... >>> https://lists.sourceforge.net/lists/listinfo/jmol-developers >> >> >> --=20 >> --=20 >> >> Robert M. Hanson, ha...@st..., 507-646-3107 >> Professor of Chemistry, St. Olaf College >> 1520 St. Olaf Ave., Northfield, MN 55057 >> mailto:ha...@st... >> http://www.stolaf.edu/people/hansonr >> >> "Imagination is more important than knowledge." - Albert Einstein >> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20 >> language >> that extends applications into web and mobile media. Attend the live=20 >> webcast >> and join the prime developer group breaking into this new coding =20 >> territory! >> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=1216= 42 >> _______________________________________________ >> Jmol-developers mailing list >> Jmo...@li... >> https://lists.sourceforge.net/lists/listinfo/jmol-developers >=20 >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting lang= uage > that extends applications into web and mobile media. Attend the live=20 > webcast > and join the prime developer group breaking into this new coding territ= ory! > http://sel.as-us.falkag.net/sel?cmd____________________________________= ___________=20 >=20 > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers --=20 -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: <rka...@ri...> - 2006-03-31 11:22:00
|
yes, but if the too low number of lines in a file is causing the =20 problem, shouldn't CS2.xyz have the same issues as H2O.xyz? (I assume =20= that since they are both triatomics the number of lines would be the =20 same in an xyz file, give or take an empty line at the end....) Ren=E9 On Mar 31, 2006, at 6:00 AM, Bob Hanson wrote: > sorry, CS2.xyz is fine. |
From: Bob H. <ha...@st...> - 2006-03-31 12:31:39
|
I meant "fine for testing" -- anyway, it's a moot point. Ren=E9 Kanters wrote: > yes, but if the too low number of lines in a file is causing the=20 > problem, shouldn't CS2.xyz have the same issues as H2O.xyz? (I assume=20 > that since they are both triatomics the number of lines would be the=20 > same in an xyz file, give or take an empty line at the end....) >=20 > Ren=E9 >=20 > On Mar 31, 2006, at 6:00 AM, Bob Hanson wrote: >=20 >> sorry, CS2.xyz is fine. >> >=20 --=20 -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2006-03-30 19:07:54
|
> Review prior to 10.1 release > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =5Bsnip=5D > Reader/File related > ------------------- > r4501 - modelNumber for non-pdb + getCurrentFileContents Bob, In this commit you changed the interpretation of the 'model' for non-pdb files to be strictly numeric. Formerly the code was always trying to convert the 'model tag' into an integer. Now it only tries the conversion if the file is .pdb Q: Can you tell me a little about what problem was being caused and the motivation behind the change? Thanks, Miguel |
From: Bob H. <ha...@st...> - 2006-03-30 19:27:29
|
This fixed a bug in labels with the %M format. Formerly it was inserting the full model name, which could be very long, into the %M atom label format. (Which reminds me, please redo my fix of %m.) Atom.atomLabelFormat(): case 'M': strT = "" + getModelTagNumber(); break; case 'm': strT = getGroup1(); %M is supposed to return a number, not a model name. Please redo that fix. There are some reader files fixes that go along with this, as I recall. Check the commit trail. I believe I made the distinction now between modelTag and modelTagNumber. That's important. Miguel wrote: >>Review prior to 10.1 release >>============================ > > [snip] > >>Reader/File related >>------------------- >>r4501 - modelNumber for non-pdb + getCurrentFileContents > > > Bob, > > In this commit you changed the interpretation of the 'model' for non-pdb > files to be strictly numeric. > > Formerly the code was always trying to convert the 'model tag' into an > integer. > > Now it only tries the conversion if the file is .pdb > > Q: Can you tell me a little about what problem was being caused and the > motivation behind the change? > > > Thanks, > Miguel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd_______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2006-03-30 19:56:32
|
> This fixed a bug in labels with the %M format. Formerly it was > inserting the full model name, which could be very long, into the %M atom label format. OK ... that makes sense for %M formatting > (Which reminds me, please redo my fix of %m.) This was reintroduced in the 10.00.50 release > Please redo that fix. There are some reader files fixes that go along with this, as I recall. Check the commit trail. %M will now report modelTagNumber instead of modelTag. The implementation of getModelTagNumber() is another question. > I believe I made the > distinction now between modelTag and modelTagNumber. That's important. getModelTagNumber() already existed. Here is the diff ... int getModelTagNumber() =7B - try =7B - return Integer.parseInt(group.chain.model.modelTag); - =7D catch (NumberFormatException nfe) =7B - return modelIndex + 1; - =7D + if (group.chain.frame.isPDB) =7B + try =7B + return Integer.parseInt(group.chain.model.modelTag); + =7D finally =7B=7D + =7D + return getModelNumber(); =7D The old code would return number if the model tag was *exactly* an intege= r. The new code only tries to do this conversion if the file is a .pdb file The question is ... what should the appropriate behavior be? If the modelTag in the file is =224567=22 then I think that the modelTagN= umber should be 4567 ... regardless of the file type ... so that the modelTagNumber reflects the number in the file if it is a number. Q: Do you agree? Miguel |
From: Bob H. <ha...@st...> - 2006-03-30 21:17:04
|
The conversion should only be done for PDB files, because only in that case is it reading the MODEL line, which must be a number. (I didn't check into what CIF files do or if .isPDB is absolutely inclusive.) The issue was the distinction between PDB model number listed and sequential model number. So you will see methods in Atom, Viewer, ModelManager, and RepaintManager (where the frame stuff is) that convert model number to model index. The model tag for XYZ files is being drawn from the 2nd line, and I think MOL files from the first line -- you should see important comments added to MolFileReader that indicate the MDL format information for reference. Some changes were made there that are important. I'd like to keep those comments there. Check for all occurances of .isPDB and getModelNumber() in Bob200603. You'll see that there are other references to it. I also set up ModelManager.isPDB() --> Frame.isPDB() that could be used in general instead of group.chain.frame.isPDB, but I didn't ever implement a call to it. Miguel wrote: >>This fixed a bug in labels with the %M format. Formerly it was >>inserting the full model name, which could be very long, into the %M > > atom label format. > > OK ... that makes sense for %M formatting > > >>(Which reminds me, please redo my fix of %m.) > > > This was reintroduced in the 10.00.50 release > > >>Please redo that fix. There are some reader files fixes that go along > > with this, as I recall. Check the commit trail. > > %M will now report modelTagNumber instead of modelTag. > > > The implementation of getModelTagNumber() is another question. > > >>I believe I made the >>distinction now between modelTag and modelTagNumber. That's important. > > > getModelTagNumber() already existed. > > Here is the diff ... > > int getModelTagNumber() { > - try { > - return Integer.parseInt(group.chain.model.modelTag); > - } catch (NumberFormatException nfe) { > - return modelIndex + 1; > - } > + if (group.chain.frame.isPDB) { > + try { > + return Integer.parseInt(group.chain.model.modelTag); > + } finally {} > + } > + return getModelNumber(); > } > > > The old code would return number if the model tag was *exactly* an integer. > > The new code only tries to do this conversion if the file is a .pdb file > > The question is ... what should the appropriate behavior be? > > If the modelTag in the file is "4567" then I think that the modelTagNumber > should be 4567 ... regardless of the file type ... so that the > modelTagNumber reflects the number in the file if it is a number. > > Q: Do you agree? > > > Miguel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd_______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2006-03-30 21:42:50
|
> The conversion should only be done for PDB files, because > only in that case is it reading the MODEL line, > which must be a number. That is not necessarily true. Most formats use the modelTag. Other formats could place a number in that= field. I could easily create a .xyz file and use numbers to identify the models. A less-contrived example is pdbxml. > (I didn't check into what CIF > files do or if .isPDB is absolutely inclusive.) It is not. (If it is, then the flag is mis-named) > The issue was the distinction between PDB model > number listed and sequential model number. I disagree slightly. I don't see that the issue is specific to .PDB files= . I think the question is ... If any file format uses numbers to distinguis= h between the models then would you want to use that number as the modelTagNumber so that you would see it formatted with %M ? Look, if the tag presented by other file types is not a number then the behavior will be exactly the same as you desire. If you believe that no other file type will ever use a number for a model identifier then the behavior will be exactly the same as you desire. I am not saying that I know the absolutely correct answer to this, becaus= e I have struggled with it. But I see no reason to make the change to restrict the behavior to .pdb files at this point. Miguel |
From: Bob H. <ha...@st...> - 2006-03-30 21:54:18
|
Miguel wrote: >>The conversion should only be done for PDB files, because >>only in that case is it reading the MODEL line, >>which must be a number. > > > That is not necessarily true. > > Most formats use the modelTag. Other formats could place a number in that > field. I could easily create a .xyz file and use numbers to identify the > models. perhaps, but you shouldn't, and it is totally improper to assume that a number there somehow identifies a model. > > A less-contrived example is pdbxml. > > >>(I didn't check into what CIF >>files do or if .isPDB is absolutely inclusive.) > > > It is not. (If it is, then the flag is mis-named) > > >>The issue was the distinction between PDB model >>number listed and sequential model number. > > > I disagree slightly. I don't see that the issue is specific to .PDB files. then rename the tag, but do not pull this number for XYZ files. > > I think the question is ... If any file format uses numbers to distinguish > between the models then would you want to use that number as the > modelTagNumber so that you would see it formatted with %M ? Only if the file format REQUIRES this (as in PDB) > > Look, if the tag presented by other file types is not a number then the > behavior will be exactly the same as you desire. If you believe that no > other file type will ever use a number for a model identifier then the > behavior will be exactly the same as you desire. The documentation is correct; %M should deliver the model number. This must be the number that is used for selecting a model with the /n designator. Any other number in that %M field is improper and misleading. The key is the connection between %m and select. For PDB files or other formats that allow for "Model number" to be EXPLICITLY indicated, this number should be determined at the time of file load, not simply placed into the modelTag field for later possible retrieval. If a place is not there for modelNumber in AtomSet (and, in the case of simple files, I think, AtomSetCollection -- not sure there) then it should be added. For all other file formats, this field should hold (modelIndex + 1). In particular, an integer that just happens to be on the second line of an XYZ file must not be used here. That's just a comment field; typically it holds information such as energies and all sorts of other things, but it is not up to Jmol to decide what should be there for selecting a specfic model. > > I am not saying that I know the absolutely correct answer to this, because > I have struggled with it. But I see no reason to make the change to > restrict the behavior to .pdb files at this point. > > > Miguel > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd_______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: Miguel <mi...@jm...> - 2006-03-30 23:12:17
|
> Review prior to 10.1 release > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =5Bsnip=5D > Reader/File related > ------------------- =5Bsnip=5D > r4624,r4625,r4630 - auxiliaryInfo > > r4623,r4635,r4640 - SpartanSmolReader OK r4623 was reintroduced in r4854. The JUnit tests run fine on all of th= e SpartanSmol files. I uncovered a problem when looking into auxiliaryInfo and the other reade= r changes that depend upon it ... The problem is actually with getAtomSetCollectionProperties and getAtomSetProperties ... those entry points were intended to be used for passing more complicated information from the Readers to the Viewer. Bob pointed out that he could not use getAtomSetCollectionProperties because he needed to pass more complicated data structures. So he created= auxiliaryInfo methods that use Hashtable. This is something that we need to take a look at and consider. These two things need to be consolidated ... because they are trying to provide the= same functionality. This is also related to the API and data structures that we use to exchange information between the viewer and JavaScript or the viewer and Java. I strongly suspect that the Hashtable solution is the right one and that we will replace the use of java.util.Properties in org.jmol.api.* with java.util.Hashtable. This will need to be reviewed after the 10.1 release= . So, this auxiliaryInfo API enhancement will not make it into the 10.1 release. Nor will the reader changes (SpartanSmol + Gaussian ?) that depend upon it. These are revisions r4624,r4625,r4630,r4635,r4640 Miguel |
From: Bob H. <ha...@st...> - 2006-03-30 23:22:36
|
Miguel wrote: > > The problem is actually with getAtomSetCollectionProperties and > getAtomSetProperties ... those entry points were intended to be used for > passing more complicated information from the Readers to the Viewer. right - they only pass strings. That's pretty much useless. These should probably be abandoned. > > Bob pointed out that he could not use getAtomSetCollectionProperties > because he needed to pass more complicated data structures. So he created > auxiliaryInfo methods that use Hashtable. > > This is something that we need to take a look at and consider. These two > things need to be consolidated ... because they are trying to provide the > same functionality. > > This is also related to the API and data structures that we use to > exchange information between the viewer and JavaScript or the viewer and > Java. Right. > > I strongly suspect that the Hashtable solution is the right one and that > we will replace the use of java.util.Properties in org.jmol.api.* with > java.util.Hashtable. This will need to be reviewed after the 10.1 release. Great. This is a rich source of information. Costs next to nothing. Useless of course without getProperty()! > > So, this auxiliaryInfo API enhancement will not make it into the 10.1 > release. Nor will the reader changes (SpartanSmol + Gaussian ?) that > depend upon it. > Fine, as long as it's a priority right after. Along with getProperty(). getProperty() and draw should have top billings after 10.1; frame/visibility very close 3rd in my opinion. Spin right up there, too. Bob -- -- Robert M. Hanson, ha...@st..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:ha...@st... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein |
From: <rka...@ri...> - 2006-03-31 00:34:45
|
On Mar 30, 2006, at 6:22 PM, Bob Hanson wrote: > > > Miguel wrote: > >> The problem is actually with getAtomSetCollectionProperties and >> getAtomSetProperties ... those entry points were intended to be >> used for >> passing more complicated information from the Readers to the Viewer. > > right - they only pass strings. That's pretty much useless. These > should probably be abandoned. Actually Miguel and I had a long discussion about that when he added the properties as strings only. His reasoning, which I now agree with (since I make use of that in the AtomSetChooser feedback) is that it would be hard to communicate the values of the properties to users if they can not be cast in a easily interpretable format (i.e., human readable string). > >> Bob pointed out that he could not use getAtomSetCollectionProperties >> because he needed to pass more complicated data structures. So he >> created >> auxiliaryInfo methods that use Hashtable. >> This is something that we need to take a look at and consider. >> These two >> things need to be consolidated ... because they are trying to >> provide the >> same functionality. >> This is also related to the API and data structures that we use to >> exchange information between the viewer and JavaScript or the >> viewer and >> Java. > > Right. > >> I strongly suspect that the Hashtable solution is the right one >> and that >> we will replace the use of java.util.Properties in org.jmol.api.* >> with >> java.util.Hashtable. This will need to be reviewed after the 10.1 >> release. > > Great. This is a rich source of information. Costs next to nothing. > Useless of course without getProperty()! > >> So, this auxiliaryInfo API enhancement will not make it into the 10.1 >> release. Nor will the reader changes (SpartanSmol + Gaussian ?) that >> depend upon it. > > Fine, as long as it's a priority right after. Along with getProperty > (). getProperty() and draw should have top billings after 10.1; > frame/visibility very close 3rd in my opinion. Spin right up there, > too. > > Bob > > > > -- > -- > > Robert M. Hanson, ha...@st..., 507-646-3107 > Professor of Chemistry, St. Olaf College > 1520 St. Olaf Ave., Northfield, MN 55057 > mailto:ha...@st... > http://www.stolaf.edu/people/hansonr > > "Imagination is more important than knowledge." - Albert Einstein > > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting > language > that extends applications into web and mobile media. Attend the > live webcast > and join the prime developer group breaking into this new coding > territory! > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Jmol-developers mailing list > Jmo...@li... > https://lists.sourceforge.net/lists/listinfo/jmol-developers |