The zip file business is complete. What you do is, in 11.5.2,
set defaultdirectory "whateverfile.zip"
then when you issue
load myfile.xyz
or
script "test.spt"
those files are drawn from the zip file, just as though it were a real
directory. To go back to normal operation, issue
set defaultDirectory ""
Also, I modified the pmesh binary specs just a bit. I decided we really
needed four full bytes of magic number, so it's the fifth byte that
indicates big/little-endian.
We could compress this a bit more by using bytes instead of ints for
each polygon # of vertices, but maybe that's not necessary?
For now, consider this binary format HIGHLY experimental and subject to
change.
Bob
# new feature: pmesh BINARY "filename"
# BINARY keyword is optional, but recommended for efficiency
#
# * 4 bytes: P M \1 \0
# * 1 byte: \0 for bigEndian
# * 3 bytes: reserved
# * 4 bytes: (int) vertexCount
# * 4 bytes: (int) polygonCount
# * 64 bytes: reserved
# * ------------------------------
# * float[vertexCount*3]vertices {x,y,z}
# * [polygonCount] polygons
# * --each polygon--
# * 4 bytes: (int)nVertices (1,2,3, or 4)
# * [4 bytes * nVertices] int[nVertices]
# *
# * note that there is NO redundant extra vertex in this format
#
# see little-endian example at
http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin
# and http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt
Nico will release 11.5.2 probably later today.
Bob
Robert Bradshaw wrote:
> Thanks. Looks good to me. Where can I get some jars to play around
> with this?
>
> Any more work on the zip file stuff?
>
> - Robert
>
>
> On Dec 31, 2007, at 8:23 PM, Bob Hanson wrote:
>
>> Jmol 11.5.1 has
>>
>> pmesh binary "filename"
>>
>> It's just experimental -- totally up to you what you want there, Robert
>> -- but for now it looks like this:
>>
>> http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin
>>
>> described here:
>>
>> http://chemapps.stolaf.edu/jmol/docs/misc/pmesh.bin.txt
>>
>> seems to work with that one file. I'm hoping you can work with this and
>> see how it goes. I'm done for some time now.
>>
>> Bob
>>
>>
>>
>> Robert Bradshaw wrote:
>>
>>> On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote:
>>>
>>>> I'm a bit lost on this thread, but I wanted to respond to the
>>>> binary/multiple file issue.
>>>>
>>>> First, it's a fine idea to create a binary Pmesh file format. If
>>>> we do
>>>> that, though, let's not rush into it and just "create a binary
>>>> equivalent
>>>> of a Pmesh file." If this is really useful, then let's create a
>>>> format that
>>>>
>>>>
>>>> 1) allows for multiple pmesh objects
>>>
>>>
>>>
>>> Sure, though if the zip file thing is working I think it is fine to
>>> have one object per file too (as we also want to specify color, etc.
>>> and will probably have spheres, labels, etc. too, so we'll be dealing
>>> with multiple files anyway and it probably isn't worth trying to
>>> figure out a way to encode this as scripts work so nice).
>>>
>>>> 2) includes a header that clearly distiguishes the file format
>>>> within the
>>>> first 4 bytes -- the "magic number" idea.
>>>
>>>
>>>
>>> Yes, this is a good idea. One or two non-ascii bytes maybe (so other
>>> readers can detect that it's binary data). Perhaps a flag that
>>> specifies floats vs. doubles. Java already stores things in a endian-
>>> consistant way, so we don't need to deal with that.
>>>
>>>> 3) allows for a simpler polygon definition -- for example, there
>>>> should not
>>>> be the need to redundantly specify the first vertex twice, as is
>>>> part of
>>>> the pmesh file format.
>>>
>>>
>>>
>>> Certainly. Other than that the format is very simple to implement,
>>> and I can't think of any changes that need to be made.
>>>
>>>>
>>>> I recently added ZIP (JAR) file reading capability to Jmol -- no
>>>> need for
>>>> gzip here -- we can now read a zip file directory directly if we
>>>> wanted to
>>>> -- but that seems to me to be an unnecessary complication in this
>>>> case. All
>>>> we really need is a new binary pmesh format.
>>>
>>>
>>>
>>> I often have more than just pmeshes that I want to include, and
>>> presentation stuff (color, wireframe or not, etc.) is nicely kept
>>> separate from the data in an easy-to-read ascii file.
>>>
>>>> Note that Jmol must be able to distinguish the file type from the
>>>> initial
>>>> few bytes of data, not the file extension. That's the role of the
>>>> header.
>>>>
>>>> I'd be very happy to write this reader; but before we do so, let's
>>>> brainstorm a bit on what would be optimal.
>>>
>>>
>>>
>>> This would be great.
>>>
>>>>
>>>>
>>>> On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel" <[EMAIL PROTECTED]>
>>>> wrote:
>>>>
>>>>>
>>>>> zip (jar) would be better for sets of files ... although Jmol
>>>>> currently
>>>>> doesn't have any mechanism to deal with a directory of files. That
>>>>> is, it
>>>>> wouldn't know which of the files you wanted to *open* and what you
>>>>> would
>>>>> want to do with the other files.
>>>>>
>>>>
>>>> Jmol 11.3.65 can and does read ZIP files and their directories,
>>>> and for
>>>> model files, if the ZIP file contains a "manifest" then specific
>>>> files can
>>>> be read or skipped, then the directory contents may be investigated
>>>> prior
>>>> to model loading. This capability is iterative, so zip files
>>>> contained in
>>>> zip files contained in zip files.... can be read.
>>>
>>>
>>>
>>> This sounds perfect--where is this documented?
>>>
>>> - Robert
>>>
>>
>>
>> --
>> Robert M. Hanson
>> Professor of Chemistry
>> St. Olaf College
>> Northfield, MN
>> http://www.stolaf.edu/people/hansonr
>>
>>
>> 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
Northfield, MN
http://www.stolaf.edu/people/hansonr
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
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
