Rolf, what you describe IS the intended behavior of the
conformation
command. Sorry, I think I didn't make that clear.
conformation
by itself is supposed to do precisely what you wish, I think. (I see
that I have a bug there -- will be fixed momentarily.)
For example, say you have five mode
Bob Hanson wrote:
> Rolf Huehne wrote:
>> Bob Hanson wrote:
>>> load "1vwh" "alt/1VWH.cif" "alt/1VWH.cif";color altloc;restrict
>>> none;select *;cartoon on
>>> model 1001;conformation 1
>>> model 2001;conformation 2
>>> model 0
>>>
>>> Do you see what that is doing?
>>>
>>>
>>
>>
>> It first loads
On May 18, 2006, at 4:08 p, Bob Hanson wrote:
Cif data structure would not allow "?" or ".", because those mean
"empty", I think. (Or is there an escape mechanism for that, too? I
suppose there is) In any case, I think we need a wildcard. It's
just too useful.
agreed. wildcard good.
Cif data structure would not allow "?" or ".", because those mean
"empty", I think. (Or is there an escape mechanism for that, too? I
suppose there is) In any case, I think we need a wildcard. It's
just too useful. The author that uses "?" for an altloc deserves to
have his/her data mangled
On May 18, 2006, at 3:37 p, Bob Hanson wrote:
Rolf Huehne wrote:
At least in the PDB format file they are "A","B" for 1VWH. Since I am
not used to read mmCIF files I couldn't figure out yet if they were
changed to "1","2" there. Since the following characters
'*1234ABCDEFGHIJKLMNOPQRSTUVXYZ
ar
Rolf Huehne wrote:
Bob Hanson wrote:
load "1vwh" "alt/1VWH.cif" "alt/1VWH.cif";color altloc;restrict
none;select *;cartoon on
model 1001;conformation 1
model 2001;conformation 2
model 0
Do you see what that is doing?
It first loads "1VWH.cif" twice as separate models, setting "1vwh" as
Bob Hanson wrote:
> load "1vwh" "alt/1VWH.cif" "alt/1VWH.cif";color altloc;restrict
> none;select *;cartoon on
> model 1001;conformation 1
> model 2001;conformation 2
> model 0
>
> Do you see what that is doing?
>
>
It first loads "1VWH.cif" twice as separate models, setting "1vwh" as
the name dis
thanks, that's certainly interesting that extractModel gives that error.
Oh, I know -- you tried to make a MOL file with more than 999 atoms.
That's all. extractModel is admittedly a bit crude.
OK, well, then, that is good news. Now if Miguel would tell me the
same, I'd be quite pleased.
On May 17, 2006, at 1:50 p, Bob Hanson wrote:
Thank you very much for taking the time to do this, Tim.
Timothy Driscoll wrote:
first time at the page it does load, but after approx 10 seconds
of 'spinning beachball' (does not happen with Jmol usually). the
second time at the page had no
Rolf Huehne wrote:
Bob Hanson wrote:
Is everything working for you at
http://www.stolaf.edu/people/hansonr/jmol/test/proto/altloc.htm
?
Try some of those links in brackets on the left. They work? I'm
wondering if the problem with XTALX is just that it's really pushing
the whole Java/JavaSc
Thank you very much for taking the time to do this, Tim.
Timothy Driscoll wrote:
first time at the page it does load, but after approx 10 seconds of
'spinning beachball' (does not happen with Jmol usually). the second
time at the page had no beachball, and a very short page load time.
Thi
On May 14, 2006, at 2:21 p, Bob Hanson wrote:
Jmol Developers,
I made some changes to the JavaScript/Java interface and may be
onto something. I am no longer seeing any wild fluctuation in
memory whatsoever at the URL below. Loading reasonably large files
seems to result in only minimal m
Bob Hanson wrote:
> Is everything working for you at
> http://www.stolaf.edu/people/hansonr/jmol/test/proto/altloc.htm
>
> ?
>
> Try some of those links in brackets on the left. They work? I'm
> wondering if the problem with XTALX is just that it's really pushing
> the whole Java/JavaScript system
Thanks, Rolf. 1crn is loading because it's cached on my server. The
others aren't loading because for some reason my server is getting from
RCSB the message "302 page temporarily moved". The files are coming back
empty, so no data, thus the error message. This just started yesterday,
so I'm cur
Bob Hanson wrote:
> Jmol Developers,
>
> I made some changes to the JavaScript/Java interface and may be onto
> something. I am no longer seeing any wild fluctuation in memory
> whatsoever at the URL below. Loading reasonably large files seems to
> result in only minimal memory increases. Please ta
On Sunday 14 May 2006 14:21, Bob Hanson wrote:
> a) does http://fusion.stolaf.edu/chemistry/jmol/xtalx load OK for you?
Yes.
Kubuntu Dapper (2006-05-16 update)
Konqueror 3.5.2
Sun JRE 1.5.0 update 06
> b) does the "waiting for applet" title message disappear within a few
> seconds? (You may not
On May 14, 2006, at 2:21 PM, Bob Hanson wrote:
Jmol Developers,
I made some changes to the JavaScript/Java interface and may be
onto something. I am no longer seeing any wild fluctuation in
memory whatsoever at the URL below. Loading reasonably large files
seems to result in only minimal
Jmol Developers,
I made some changes to the JavaScript/Java interface and may be onto
something. I am no longer seeing any wild fluctuation in memory
whatsoever at the URL below. Loading reasonably large files seems to
result in only minimal memory increases. Please take a look and answer a
f
> Yes, probably.
> For example, if references to JavaScript objects are passed to other
> technologies, then JavaScript garbage collector is totally lost.
Yes.
> The memory usage of the browser is probably not in the Java Plugin.
> With JavaScript, last year I add a problem with the browser takin
Miguel wrote:
browser opened/Mb+page/Mb+1p84.pdb/Mb
MSIE6.0... 194362
Firefox1.5.0.3 184265-->47
Opera8.51 143757
So I would have to say that Opera is doing somethi
> browser opened/Mb+page/Mb+1p84.pdb/Mb
> MSIE6.0... 194362
> Firefox1.5.0.3 184265-->47
> Opera8.51 143757
>
> So I would have to say that Opera is doing something righ
I already had problems with memory deallocation with JavaScript.
In my situation, it was probably related to circular references with a
non-JavaScript object in the circular reference.
Then, JavaScript garbage collector doesn't work correctly.
You usually have to dereference yourself the object
thanks, Tim. It's good to have a "power Mac" user on the team. Take your
time. My finding both in Linux and Windows now is that the applet starts
at about 40Mb required memory allocation and then goes from there. One
large protein (1p84, 32000+ atoms) can push it to 64Mb instantly. The
colleag
On May 10, 2006, at 6:15 p, Bob Hanson wrote:
Well, that must be it. Sitting here at my PC I see the Opera memory
usage zoom to 76Mb as I build 27 crystals in the maleic.cif
collection up to 3x3x2, and Netscape is at 126Mb from similar use.
I'm certain these would have crashed that Linux br
OK, that makes sense. This is tricky. We may be up against a wall here.
Bob
Miguel wrote:
I'm worried that Jmol or Java is not properly dealing with memory
allocation, specifically DEallocating memory after large molecules are
replaced by small ones. What am I missing here?
Java does not h
> I'm worried that Jmol or Java is not properly dealing with memory
> allocation, specifically DEallocating memory after large molecules are
> replaced by small ones. What am I missing here?
Java does not have any memory leakage problems.
Jmol might ... but only if you can reproduce it in the Jmo
Well, that must be it. Sitting here at my PC I see the Opera memory
usage zoom to 76Mb as I build 27 crystals in the maleic.cif collection
up to 3x3x2, and Netscape is at 126Mb from similar use. I'm certain
these would have crashed that Linux browser long ago, and my guess is
that's the issue w
27 matches
Mail list logo
