Oh, I see -- that is updated by Eclipse when the file is uploaded.
Joe, this is in org.jmol.viewer.JmolConstants.java
public final static String cvsDate = "$Date: 2009-11-05 13:25:06 -0600
(Thu, 05 Nov 2009) $"; //
public final static String date = cvsDate.substring(7, 23);
Make sure that is there in your version, and it should build just fine.
Apparently your version has that date missing or truncated so that the
substring(7,23) is not working.
Bob
On Thu, Nov 5, 2009 at 1:17 PM, Robert Hanson <[email protected]> wrote:
> 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
>
--
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
