Re: [Jmol-developers] inline clarification

[Robert H. <ha...@st...>]

Hmm. Do you get an indication of where? Do you get a stack trace? Is it in
Jmol? Make sure the debug setting is TRUE in build.xml

That doesn't sound like a version issue. More a data issue. If you

set debug

then you should get a debug line for every line read in the file.

Bob

On Thu, Nov 5, 2009 at 2:52 AM, Joe Gatewood <jm...@se...> 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:ha...@st...]
> *Sent:* Wednesday, November 04, 2009 8:28 PM
>
> *To:* jmo...@li...
> *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 <jm...@se...> wrote:
>
> GREAT
>
>
>
>
>   ------------------------------
>
> *From:* Robert Hanson [mailto:ha...@st...]
> *Sent:* Wednesday, November 04, 2009 1:06 PM
>
>
> *To:* jmo...@li...
> *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 <jm...@se...> 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:ha...@st...]
> *Sent:* Wednesday, November 04, 2009 11:46 AM
>
>
> *To:* jmo...@li...
> *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 <jm...@se...> 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:ha...@st...]
> *Sent:* Monday, November 02, 2009 12:01 PM
>
>
> *To:* jmo...@li...
> *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
> Jmo...@li...
> 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
> Jmo...@li...
> 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
> Jmo...@li...
> 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
> Jmo...@li...
> 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