Already I break my promise!
Please note that I built a 1 second delay into the PubChem call. PubChem is not
as slow as my page suggests. I’m just trying to keep enthusiastic fast drawing
users from exceeding PubChem's 3 request per second red flag. This would not be
a problem in a click to get
OK, I promise I’ll drop this subject after this note!
I put together a quick and dirty head to head JSME SMILES to IUPAC competition
between Resolver and PubChem. I simply added PubChem IUPAC to Peter Ertl’s
Resolver IUPAC test page:
http://chemagic.org/molecules/jsme9.htm
Don’t go bonkers wit
ps; adding
info = eval("JSON",x)
much faster JSON parsing than just eval(x);
On Mon, May 9, 2016 at 6:39 PM, Otis Rothenberger
wrote:
> Bob,
>
> They know it! They are the ones who pointed this out to me after my
> conventional JSON extraction failed on some compounds. They explained the
> ne
Bob,
They know it! They are the ones who pointed this out to me after my
conventional JSON extraction failed on some compounds. They explained the
necessity of this type of loop to me:
var p = data.PC_Compounds[0].props;
pubCid = data.PC_Compounds[0].id.id.cid;
for (var
On Mon, May 9, 2016 at 4:30 PM, Otis Rothenberger
wrote:
> I’ve hinted at this before, but Pierluigi’s note gives me cause to be
> specific: Let’s not forget PubChem as a source of data other than 3d
> coordinates!
>
> Over the years, Jmol has become research and teaching powerful - no VERY
> pow
I’ve hinted at this before, but Pierluigi’s note gives me cause to be specific:
Let’s not forget PubChem as a source of data other than 3d coordinates!
Over the years, Jmol has become research and teaching powerful - no VERY
powerful. Resolver was a logical partner for Jmol because it is also po
I note that JSmol now includes a client-side InChI calculator. See
http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm
for more.
Bob
On Mon, May 9, 2016 at 12:51 PM, Otis Rothenberger
wrote:
> One more JSME point on this subject. The JSME call backs that I mentioned
> in this chain can handle the
You can get this from
x = show("state/echo")
also, if you know what you are looking for.
set echo off;
set echo ID "myecho" 0 0; echo "hmm";
font echo 20.0 Serif Plain; color echo [xff];
set echo top left; echo "OK";
font echo 20.0 Serif Plain; color echo [xff];
On Mon, May
Dear Bob,
Under "set echo"
section "scaling"
Is a red link to "set fontScaling true" but the link incorrectly goes to
"#setmisc".
It should go to "#setlabels".
Thanks, Eric
--
Find and fix application performance is
One more JSME point on this subject. The JSME call backs that I mentioned in
this chain can handle the IUPAC dynamically as the structure is edited. Again,
here are all the new callbacks:
BeforePaste, AfterPaste, AfterStructureModified, AtomHighlight, BondHighlight,
AtomClicked, BondClicked
An
getproperty shapeinfo is supposed to be delivering that, but it is not. Bug
fix
On Mon, May 9, 2016 at 11:53 AM, Eric Martz
wrote:
> Is there a way to message or print (or show) the text currently displayed
> at a named echo position?
>
> For example, something like
>
> set echo top left
>
>
On Mon, May 9, 2016 at 11:39 AM, Otis Rothenberger
wrote:
> Hi Pierluigi-
>
> For reasons that I do not fully understand, OPSIN returns InChI - not
> standard InChI. It does, however, return standard InChIKey! In general, I’d
> be very nervous about comparing InChI strings created by different
>
Is there a way to message or print (or show) the text currently
displayed at a named echo position?
For example, something like
set echo top left
echo "1d66"
message echo top
but that message command doesn't work and I haven't found a method.
Of course I can keep what I echo in a v
Hi Pierluigi-
For reasons that I do not fully understand, OPSIN returns InChI - not standard
InChI. It does, however, return standard InChIKey! In general, I’d be very
nervous about comparing InChI strings created by different resources.
In the realm of Chemical Identifiers, molfile and SMILES
14 matches
Mail list logo
