I know what it is:
public final static String cvsDate = "$Date: 2009-10-28 11:43:37 -0500
(Wed, 28 Oct 2009) $";
public final static String date = cvsDate.substring(7, 23);
It's a problem in the build.
Nico, Egon -- how does that date get inserted?
Bob
On Thu, Nov 5, 2009 at 1:00 PM, Robert Hanson <[email protected]> wrote:
> Joe, please rebuild and run that again with
> <property name="debug" value="on" />
> in build.xml
>
>
>
> On Thu, Nov 5, 2009 at 12:54 PM, Robert Hanson <[email protected]> wrote:
>
>> I'm using 1.6.0_12, so I don't think that's the problem.
>>
>>
>> On Thu, Nov 5, 2009 at 2:52 AM, Joe Gatewood <[email protected]> wrote:
>>
>>> Bob,
>>>
>>> I am getting a libgcj.so.90 StringIndexOutOf BoundsException on my build
>>> of 11.9.8_dev. I get the exception when running jmol from the command or
>>> from within genTELLECT. My guess is we are using different jdk versions. I
>>> built with 1.6.0_13.
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> *From:* Robert Hanson [mailto:[email protected]]
>>> *Sent:* Wednesday, November 04, 2009 8:28 PM
>>>
>>> *To:* [email protected]
>>> *Subject:* Re: [Jmol-developers] inline clarification
>>>
>>>
>>>
>>> I've uploaded modifications for Jmol 11.9.8_dev that you can try. I think
>>> it's basically the same idea you describe above, along with a read() method
>>> in order to check the file type. I suppose for a single file you could also
>>> designate the file type, but this is in keeping with Jmol's automatic file
>>> type check. I guess that means you can't use it to force a type. But it
>>> should be just fine with standard file types. In principle, we could add a
>>> special comment in the 0-element of the array to indicate the type. For now,
>>> let's do it this simple standard way.
>>>
>>> This adds one new method to Viewer and JmolViewer:
>>>
>>> # public String loadInline(Vector arrayData, boolean isAppend);
>>> #
>>> # @param arrayData a Vector of models, where each model is either a
>>> String
>>> # or a String[]
>>> # @param isAppend TRUE to append models (no ZAP)
>>> # @return null or error message
>>> #
>>> ##### NOTE: THIS METHOD DOES NOT PRESERVE THE STATE
>>> ##### BECAUSE IT DOES NOT SAVE THE READ DATA IN A SCRIPT COMMAND.
>>> ##### FOR THAT FUNCTIONALITY USE loadInline(String[] modelData, boolean
>>> isAppend);
>>>
>>>
>>> The idea is that you take your String[] data and wrap it in a Vector. The
>>> reason for this is so that, should you ever want to, you can append a set of
>>> models -- some String[] format and some String format -- and not just one of
>>> one type. Just seemed like a simple enough thing to do. Basically it just
>>> adds an ArrayDataReader class that subclasses BufferedReader and overrides
>>> its read and readLine methods. These are used by Resolver and the various
>>> file readers to read the data.
>>>
>>> The read() method is just a hack. It doesn't advance the pointer by
>>> characters but instead advances it by lines. So a read() of a partial line
>>> ends up ignoring the rest of that line if another read() or readLine()
>>> method is called next.
>>>
>>> Generally, fileManager makes a copy of an inline string so that it can
>>> reproduce the state; with this method that is not enabled -- the state will
>>> not be properly reproduced. This is because the whole idea of the method is
>>> to save memory and not bother with preserving the state.
>>>
>>> Joe, please let me know if this works.
>>>
>>> Bob
>>>
>>> On Wed, Nov 4, 2009 at 2:15 PM, Joe Gatewood <[email protected]> wrote:
>>>
>>> GREAT
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> *From:* Robert Hanson [mailto:[email protected]]
>>> *Sent:* Wednesday, November 04, 2009 1:06 PM
>>>
>>>
>>> *To:* [email protected]
>>> *Subject:* Re: [Jmol-developers] inline clarification
>>>
>>>
>>>
>>> I have a similar idea, but it will be more integrated. Cannot work on
>>> this for 5 hours now, but I'm sure I can get it. Definitely not quite that
>>> simple, but close.
>>>
>>> Bob
>>>
>>> On Wed, Nov 4, 2009 at 1:19 PM, Joe Gatewood <[email protected]> wrote:
>>>
>>> Bob,
>>>
>>>
>>>
>>> I was looking though the code and found viewer.openReader calling
>>> FileManager.createAtomSetCollectionFromReader
>>>
>>> I created a Reader extension than read an array.
>>>
>>>
>>>
>>>
>>>
>>> I was able to wrap my class with a BufferedReader and read the array. I
>>> thought I had a solution but createAtomSetCollectionFromReader opens the
>>> file that Reader is accessing to determine the file type, I think. The need
>>> to access the file to determine type when the Reader is at hand seems very
>>> odd. Anyway if I could pass the data type ie “pdb” ,etc to openReader and
>>> then createAtomSetCollectionFromReader used that type instead of setting
>>> type to null as currently implemented I think I would be OK.
>>>
>>>
>>>
>>> On the other hand I could hand you a String[] or List<String> and leave
>>> the details to you.
>>>
>>>
>>>
>>> Whatever you think best is fine with me.
>>>
>>>
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> *From:* Robert Hanson [mailto:[email protected]]
>>> *Sent:* Wednesday, November 04, 2009 11:46 AM
>>>
>>>
>>> *To:* [email protected]
>>> *Subject:* Re: [Jmol-developers] inline clarification
>>>
>>>
>>>
>>> It's certainly an interesting idea. The reader is a linear reader, so it
>>> should not matter. I think the method might exclude XML formats and, of
>>> course binary formats, just because those aren't line oriented, but all the
>>> rest are. I wonder.... So what you suggest is replacing a "BufferedReader"
>>> with a "StringArrayReader" in effect. I probably have just enough time to
>>> try that.
>>>
>>> So you will give me a String[] or a Vector?
>>>
>>> Bob
>>>
>>>
>>> On Wed, Nov 4, 2009 at 10:53 AM, Joe Gatewood <[email protected]> wrote:
>>>
>>> Bob,
>>>
>>> I managed to get the data sets with multiple models to load inline. I
>>> had to increase the heap size.
>>>
>>>
>>>
>>> I am currently of the opinion however that loading files from arrays
>>> could be made more efficient.
>>>
>>> As you obviously know using the inline approach includes
>>>
>>>
>>>
>>> Convert the array of lines to a “really big string” with some form of
>>> line delimiters
>>>
>>> Pass this “really big string” to Jmol which then looks for the delimiters
>>> and breaks the string back into an array.
>>>
>>>
>>>
>>> All this is just to get the data back into the starting form.
>>>
>>>
>>>
>>> Is there a reason we can not just pass an array of data directly to Jmol?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------
>>>
>>> *From:* Robert Hanson [mailto:[email protected]]
>>> *Sent:* Monday, November 02, 2009 12:01 PM
>>>
>>>
>>> *To:* [email protected]
>>> *Subject:* Re: [Jmol-developers] inline clarification
>>>
>>>
>>>
>>> Joe, there shouldn't be any need to write a file - you are correct; you
>>> should be able to use those directly. The Java StringBuffer is a very
>>> efficient mechanism. Don't use String = String + line. Use
>>>
>>>
>>> StringBuffer sb = new StringBuffer();
>>> int nLines = myArrayList.size();
>>> for (int i = 0; i < nLines; i++)
>>> sb.append(myArrayList.get(nLines)).append('\n');
>>>
>>> viewer.loadInline(sb.toString());
>>>
>>>
>>> That should be equivalent to loading the multiple models as separate
>>> models -- it will automatically create a model for each MODEL statement.
>>>
>>> Bob
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Jmol-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>>
>>>
>>> --
>>> Robert M. Hanson
>>> Professor of Chemistry
>>> St. Olaf College
>>> 1520 St. Olaf Ave.
>>> Northfield, MN 55057
>>> http://www.stolaf.edu/people/hansonr
>>> phone: 507-786-3107
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Jmol-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>>
>>>
>>> --
>>> Robert M. Hanson
>>> Professor of Chemistry
>>> St. Olaf College
>>> 1520 St. Olaf Ave.
>>> Northfield, MN 55057
>>> http://www.stolaf.edu/people/hansonr
>>> phone: 507-786-3107
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Jmol-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>>
>>>
>>> --
>>> Robert M. Hanson
>>> Professor of Chemistry
>>> St. Olaf College
>>> 1520 St. Olaf Ave.
>>> Northfield, MN 55057
>>> http://www.stolaf.edu/people/hansonr
>>> phone: 507-786-3107
>>>
>>>
>>> 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
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>>> 30-Day
>>> trial. Simplify your report design, integration and deployment - and
>>> focus on
>>> what you do best, core application coding. Discover what's new with
>>> Crystal Reports now. http://p.sf.net/sfu/bobj-july
>>> _______________________________________________
>>> Jmol-developers mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/jmol-developers
>>>
>>>
>>
>>
>> --
>> Robert M. Hanson
>> Professor of Chemistry
>> St. Olaf College
>> 1520 St. Olaf Ave.
>> Northfield, MN 55057
>> http://www.stolaf.edu/people/hansonr
>> phone: 507-786-3107
>>
>>
>> If nature does not answer first what we want,
>> it is better to take what answer we get.
>>
>> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>>
>
>
>
> --
> Robert M. Hanson
> Professor of Chemistry
> St. Olaf College
> 1520 St. Olaf Ave.
> Northfield, MN 55057
> http://www.stolaf.edu/people/hansonr
> phone: 507-786-3107
>
>
> If nature does not answer first what we want,
> it is better to take what answer we get.
>
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>
--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107
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
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers
