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
------------------------------------------------------------------------------
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
