Re: [Jmol-users] new InChI option

2016-03-10 Thread Robert Hanson
Otis, have you noticed any performance issues with the InChI add-on? I ask
because when  I was debugging it, I noticed that it was using a 16.5MB
integer array. I'm guessing that's the program's working heap space. Pretty
impressive.

On Thu, Mar 10, 2016 at 11:51 AM, Robert Hanson  wrote:

>
>
> On Thu, Mar 10, 2016 at 10:33 AM, Otis Rothenberger 
> wrote:
>
>> Bob,
>>
>> I currently get my non-stereo inchi’s by having JME load the Jmol
>> extracted molfile. Then I use the resulting JME non-stereo SMILES to get
>> the the non-stereo inchi from Resolver or ChemSpider's inchi resolver. I
>> guess I could now simply strip the stereo part of the inchi.js string, but
>> I don’t know enough about inchi structure. Is it as simple as that?
>>
>
> Sort of. They didn't make this trivial:
>
>
> https://en.wikipedia.org/wiki/International_Chemical_Identifier#Format_and_layers
>
>
> Bob
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department 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
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-10 Thread Robert Hanson
On Thu, Mar 10, 2016 at 10:33 AM, Otis Rothenberger 
wrote:

> Bob,
>
> I currently get my non-stereo inchi’s by having JME load the Jmol
> extracted molfile. Then I use the resulting JME non-stereo SMILES to get
> the the non-stereo inchi from Resolver or ChemSpider's inchi resolver. I
> guess I could now simply strip the stereo part of the inchi.js string, but
> I don’t know enough about inchi structure. Is it as simple as that?
>

Sort of. They didn't make this trivial:

https://en.wikipedia.org/wiki/International_Chemical_Identifier#Format_and_layers


Bob
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-10 Thread Otis Rothenberger
Bob,

I’m currently putting together a student model kit workbook for the upcoming 
BCCE. The process is helping me define a less Resolver dominated approach to 
model kit use. I’m not losing interest in Resolver, I just want to lean more on 
PubChem.

I currently get my non-stereo inchi’s by having JME load the Jmol extracted 
molfile. Then I use the resulting JME non-stereo SMILES to get the the 
non-stereo inchi from Resolver or ChemSpider's inchi resolver. I guess I could 
now simply strip the stereo part of the inchi.js string, but I don’t know 
enough about inchi structure. Is it as simple as that? My original thought was 
to send inchi.js JME’s 2D molfile.

My long term goal is to have users run locally, but Internet connected. That 
may seem strange, but the speed of running locally is nice. Internet 
connectivity is only for database stuff. So from my limited small molecule 
prospective, this new inchi development is really nice. For the workbook and 
most basic classroom usage, I only need the Internet for PubChem, Google, NIST, 
and NMRDB.ORG .

By the way, I can even run locally on an iPad - no Apple jail breaking required.

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 10, 2016, at 10:37 AM, Robert Hanson  wrote:
> 
> 
> 
> On Thu, Mar 10, 2016 at 9:12 AM, Otis Rothenberger  > wrote:
> Bob,
> 
> Very nice, thanks!
> 
> I still have a problem on first load, and I assume this has to do with the 
> async load of inchi.js.
> 
> Just make sure you do not automatically call for an inchi. Make sure it is a 
> user action.
>  
>  PubChem is an excellent source for these, and PubChem is the default model 
> load in the model kit.
> 
> Sure, as long as you have a short list of them, I guess. 
> Structure-from-IUPAC-name is only available at NCI, I believe. 
> 
>  
> I don’t want to put the weight of inchi.js on/in the model kit, so my plan is 
> to load a separate tab via a “Load Inchi Resolver” button. I’ll then have the 
> model kit “talk” to this tab/window via a local storage call back system - 
> i.e. addEventListener. With this approach, inchi.js should have plenty of 
> time to finish its load before it’s called into use, at least I hope so.
> 
> 
> that's a great idea. Or, you could certainly dynamically load it. I have not 
> tried that.
>  
> For reasons that I won’t go into here, non-stereo inchi’s are important to me 
> - more so than stereo inchi's. With this inchi.js addition, I potentially 
> have this all on board in the browser:
> 
> 
> I do not know the way to get nonstereo InChIs -- or is it just that you clip 
> off the last part?
> 
> Bob
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-10 Thread Robert Hanson
On Thu, Mar 10, 2016 at 9:12 AM, Otis Rothenberger 
wrote:

> Bob,
>
> Very nice, thanks!
>
> I still have a problem on first load, and I assume this has to do with the
> async load of inchi.js.
>

Just make sure you do not automatically call for an inchi. Make sure it is
a user action.


>  PubChem is an excellent source for these, and PubChem is the default
> model load in the model kit.
>
> Sure, as long as you have a short list of them, I guess.
Structure-from-IUPAC-name is only available at NCI, I believe.



> I don’t want to put the weight of inchi.js on/in the model kit, so my plan
> is to load a separate tab via a “Load Inchi Resolver” button. I’ll then
> have the model kit “talk” to this tab/window via a local storage call back
> system - i.e. addEventListener. With this approach, inchi.js should have
> plenty of time to finish its load before it’s called into use, at least I
> hope so.
>
>
that's a great idea. Or, you could certainly dynamically load it. I have
not tried that.


> For reasons that I won’t go into here, non-stereo inchi’s are important to
> me - more so than stereo inchi's. With this inchi.js addition, I
> potentially have this all on board in the browser:
>
>
I do not know the way to get nonstereo InChIs -- or is it just that you
clip off the last part?

Bob
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-10 Thread Otis Rothenberger
Bob,

Very nice, thanks!

I still have a problem on first load, and I assume this has to do with the 
async load of inchi.js. The page is trying to do stuff before inchi.js is fully 
loaded, so it breaks until reload. For what I have in mind, I don’t think this 
is going to be a problem. I simply want to try to implement inchi.js as an 
alternate inchi resolver. For the most part, the model kit does not use 
Resolver for sdf’s. The whole point is that the users make/study models from 
fairly common starting models.  PubChem is an excellent source for these, and 
PubChem is the default model load in the model kit.

I don’t want to put the weight of inchi.js on/in the model kit, so my plan is 
to load a separate tab via a “Load Inchi Resolver” button. I’ll then have the 
model kit “talk” to this tab/window via a local storage call back system - i.e. 
addEventListener. With this approach, inchi.js should have plenty of time to 
finish its load before it’s called into use, at least I hope so.

For reasons that I won’t go into here, non-stereo inchi’s are important to me - 
more so than stereo inchi's. With this inchi.js addition, I potentially have 
this all on board in the browser:

Jmol model 3d sdf > JME 2d sdf > inchi.js page inchi > Google, 
NIST, and other (via Google) web searches.

If it works, very nice, indeed, Bob.

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 10, 2016, at 12:13 AM, Robert Hanson  wrote:
> 
> It turned out to be just a really bad taxol file. inchi.js is working 
> perfectly -- provided it is given a decent file! Test is updated at 
> http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm 
> 
> 
> On Tue, Mar 8, 2016 at 6:55 PM, Otis Rothenberger  > wrote:
> Hi Phil,
> 
> I had convinced myself that the problem was timing related to all the async 
> stuff going on, but I think Bob is correct. There's a problem is the 
> inchi.js. Whatever problem the 2D taxol is creating, the main issue to me is 
> catching this type of problem and exiting gracefully.
> 
> Bob, I see Noel O'Boyle had a big hand in this also. He's mister Twirlymol, 
> and another great cheminformstic blogger - AKA Noel O'Blog! I'll try them 
> both.
> 
> By the way, inchi.js is running locally for me. For some reason that 
> surprised me. I really like the idea of Jmol speaking SMILES and InChI, so I 
> hope this all works out.
> 
> Otis
> 
> Sent from my iPad
> 
> On Mar 8, 2016, at 7:11 PM, J. Bays  > wrote:
> 
>> Just a question. Taxol is pretty a complex structure. Are you able to 
>> calculate and load others of equal complexity without crashing? Perhaps the 
>> error occurs in the calc part. 
>> 
>> J. Philip Bays
>> Emeritus Professor of Chemistry
>> Saint Mary's College
>> Norte Dame, IN
>> 
>> Sent from my iPad
>> 
>> On Mar 8, 2016, at 6:22 PM, Otis Rothenberger > > wrote:
>> 
>>> Bob,
>>> 
>>> I'm using the approach on github. The molfile and the calculated inchi are 
>>> in globals per their suggestions. For testing, I set the globals to "" 
>>> before each model load. This led to erroneous matches at the taxol break - 
>>> i.e. "" == "". 
>>> 
>>> I'm seeing all kinds of irratic behavior all related to taxol. Here's 
>>> what's pretty constant:
>>> 
>>> 1) Things work pretty well if you don't load taxol!
>>> 2) Loading taxol results in:
>>> 
>>> a) Taxol works.
>>> b) The next model load works (usually).
>>> c) Any model (usually) breaks it on a third load. Why 3rd load after the 
>>> taxol bomb?
>>> 
>>> 3) The ChemWriter demo at github does not like Taxol either - loaded via 
>>> paste Jmol taxol molfile.
>>> 
>>> 4) When the Jmol page breaks with Taxol (3rd load, go figure), I'm not 
>>> seeing any of the error messages listed in the .mem file. It just breaks.
>>> 
>>> 5) If I wrap the following inchi code (I'm using github suggested code):
>>> 
>>> calc = InChI.fromMolfile(molfile).trim();
>>> 
>>> in a try/catch, I get an error when the taxol related 3rd load break 
>>> happens:
>>> 
>>> type error: undefined is not an object (evaluating "a.stack")
>>> 
>>> I guess I can understand why that taxol molfile breaks the app. It's a 
>>> mess. I'd just like to catch this situation before the 3rd load break 
>>> starts.
>>> 
>>> Oh yeah, the first page load after a cache clear almost always throws an 
>>> error. This does not break the page however. It just means that you don't 
>>> get a page load inchi calculation.
>>> 
>>> Otis
>>> 
>>> Sent from my iPad
>>> 
>>> On Mar 8, 2016, at 3:50 PM, Robert Hanson >> > wrote:
>>> 
 huh?
 
 On Mon, Mar 7, 2016 at 7:17 PM, Otis Rothenberger > wrote:
 Bob,
 
 Rats! It’s reporting no 

Re: [Jmol-users] new InChI option

2016-03-09 Thread Robert Hanson
It turned out to be just a really bad taxol file. inchi.js is working
perfectly -- provided it is given a decent file! Test is updated at
http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm

On Tue, Mar 8, 2016 at 6:55 PM, Otis Rothenberger 
wrote:

> Hi Phil,
>
> I had convinced myself that the problem was timing related to all the
> async stuff going on, but I think Bob is correct. There's a problem is the
> inchi.js. Whatever problem the 2D taxol is creating, the main issue to me
> is catching this type of problem and exiting gracefully.
>
> Bob, I see Noel O'Boyle had a big hand in this also. He's mister
> Twirlymol, and another great cheminformstic blogger - AKA Noel O'Blog! I'll
> try them both.
>
> By the way, inchi.js is running locally for me. For some reason that
> surprised me. I really like the idea of Jmol speaking SMILES and InChI, so
> I hope this all works out.
>
> Otis
>
> Sent from my iPad
>
> On Mar 8, 2016, at 7:11 PM, J. Bays  wrote:
>
> Just a question. Taxol is pretty a complex structure. Are you able to
> calculate and load others of equal complexity without crashing? Perhaps the
> error occurs in the calc part.
>
> J. Philip Bays
> Emeritus Professor of Chemistry
> Saint Mary's College
> Norte Dame, IN
>
> Sent from my iPad
>
> On Mar 8, 2016, at 6:22 PM, Otis Rothenberger  wrote:
>
> Bob,
>
> I'm using the approach on github. The molfile and the calculated inchi are
> in globals per their suggestions. For testing, I set the globals to ""
> before each model load. This led to erroneous matches at the taxol break -
> i.e. "" == "".
>
> I'm seeing all kinds of irratic behavior all related to taxol. Here's
> what's pretty constant:
>
> 1) Things work pretty well if you don't load taxol!
> 2) Loading taxol results in:
>
> a) Taxol works.
> b) The next model load works (usually).
> c) Any model (usually) breaks it on a third load. Why 3rd load after the
> taxol bomb?
>
> 3) The ChemWriter demo at github does not like Taxol either - loaded via
> paste Jmol taxol molfile.
>
> 4) When the Jmol page breaks with Taxol (3rd load, go figure), I'm not
> seeing any of the error messages listed in the .mem file. It just breaks.
>
> 5) If I wrap the following inchi code (I'm using github suggested code):
>
> calc = InChI.fromMolfile(molfile).trim();
>
> in a try/catch, I get an error when the taxol related 3rd load break
> happens:
>
> type error: undefined is not an object (evaluating "a.stack")
>
> I guess I can understand why that taxol molfile breaks the app. It's a
> mess. I'd just like to catch this situation before the 3rd load break
> starts.
>
> Oh yeah, the first page load after a cache clear almost always throws an
> error. This does not break the page however. It just means that you don't
> get a page load inchi calculation.
>
> Otis
>
> Sent from my iPad
>
> On Mar 8, 2016, at 3:50 PM, Robert Hanson  wrote:
>
> huh?
>
> On Mon, Mar 7, 2016 at 7:17 PM, Otis Rothenberger 
> wrote:
>
>> Bob,
>>
>> Rats! It’s reporting no difference, but there is a difference. This seems
>> to be OK:
>>
>> $("#log").html(nci==calc ? "no difference" : "check differences?”);
>>
>> Calc seems to be OK. The problem is what’s printed on the screen for calc.
>>
>> Otis
>>
>> --
>> Otis Rothenberger
>> o...@chemagic.org
>> http://chemagic.org
>>
>> > On Mar 7, 2016, at 6:33 PM, Otis Rothenberger 
>> wrote:
>> >
>> > Bob,
>> >
>> > I think it may be a timing issue with the function below. When I
>> comment out the initial JQuery working… html replacements, the page no
>> longer “locks.” I don’t think it was really locking. I think those html
>> replacements somehow ran after the subsequent code. Which…
>> >
>> > makes absolutely no sense to me! Nevertheless, it seems to fix the
>> problem.
>> >
>> > function getInChI(app,url) {
>> >   //$("#inchi2div").html("working...");
>> >   //$("#inchi1div").html("working...");
>> >   //$("#log").html("working...");
>> >   if (!url) { return; }
>> >   nci = Jmol.evaluateVar(jmolApplet0,"show('chemical
>> stdinchi')").trim();
>> >   $("#inchi2div").html(nci + "(from
>> NCI/CADD)");
>> >   calc =
>> InChI.fromMolfile(Jmol.evaluateVar(jmolApplet0,"write('MOL')")).trim();
>> >   $("#inchi1div").html(calc + "(calculated
>> in JavaScript)");
>> >   $("#log").html(nci==calc ? "no difference" : "check
>> differences?");
>> > }
>> >
>> > Otis
>> >
>> > --
>> > Otis Rothenberger
>> > o...@chemagic.org
>> > http://chemagic.org
>> >
>> >> On Mar 7, 2016, at 4:37 PM, Robert Hanson  wrote:
>> >>
>> >> Otis, note that there is a bug there. If you ask for the models in
>> this order:
>> >>
>> >> $taxol
>> >> $morphine
>> >>
>> >> inchi.js seems to hang and just never respond. Something to do with
>> the fact that $taxol is pathologically 2D and not 3D. But
>> >>
>> >> $taxol
>> >> $methanol
>> >>
>> >> works, until 

Re: [Jmol-users] new InChI option

2016-03-08 Thread Philip Bays
Some time ago I made a comment here about taxol.   It was a molecule I went to 
when testing jsmol.  It always loaded a nice 3D structure.   Then, it changed 
to the 2D structure that now loads. 

 
> On Mar 8, 2016, at 9:29 PM, Robert Hanson  wrote:
> 
> Whatever the problem is, it has to do with loading a trashy 2D structure 
> instead of a good 3D structure, apparently. 
> 
> I have placed a taxol structure in jsmol/data so you can see that it does 
> work: http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm 
> 
> 
> I note that in creating this from the RCSB ligand TA1, I had to invent a new 
> way to write a MOL file:
> 
> load ==TA1
> write MOL0 "taxol.mol"
> 
> The new MOL0 format avoids use of the aromatic single and aromatic double 
> bond types 6 and 7. 
> (There is a bug in inchi.js that it cannot read these bond types.)
> 
> 
> Bob
> 
> 
> ​
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

Philip Bays
Emeritus Professor of Chemistry
Saint Mary's College
Notre Dame, IN 46556
pb...@saintmarys.edu


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-08 Thread Otis Rothenberger
Hi Phil,

I had convinced myself that the problem was timing related to all the async 
stuff going on, but I think Bob is correct. There's a problem is the inchi.js. 
Whatever problem the 2D taxol is creating, the main issue to me is catching 
this type of problem and exiting gracefully.

Bob, I see Noel O'Boyle had a big hand in this also. He's mister Twirlymol, and 
another great cheminformstic blogger - AKA Noel O'Blog! I'll try them both.

By the way, inchi.js is running locally for me. For some reason that surprised 
me. I really like the idea of Jmol speaking SMILES and InChI, so I hope this 
all works out.

Otis

Sent from my iPad

> On Mar 8, 2016, at 7:11 PM, J. Bays  wrote:
> 
> Just a question. Taxol is pretty a complex structure. Are you able to 
> calculate and load others of equal complexity without crashing? Perhaps the 
> error occurs in the calc part. 
> 
> J. Philip Bays
> Emeritus Professor of Chemistry
> Saint Mary's College
> Norte Dame, IN
> 
> Sent from my iPad
> 
>> On Mar 8, 2016, at 6:22 PM, Otis Rothenberger  wrote:
>> 
>> Bob,
>> 
>> I'm using the approach on github. The molfile and the calculated inchi are 
>> in globals per their suggestions. For testing, I set the globals to "" 
>> before each model load. This led to erroneous matches at the taxol break - 
>> i.e. "" == "". 
>> 
>> I'm seeing all kinds of irratic behavior all related to taxol. Here's what's 
>> pretty constant:
>> 
>> 1) Things work pretty well if you don't load taxol!
>> 2) Loading taxol results in:
>> 
>> a) Taxol works.
>> b) The next model load works (usually).
>> c) Any model (usually) breaks it on a third load. Why 3rd load after the 
>> taxol bomb?
>> 
>> 3) The ChemWriter demo at github does not like Taxol either - loaded via 
>> paste Jmol taxol molfile.
>> 
>> 4) When the Jmol page breaks with Taxol (3rd load, go figure), I'm not 
>> seeing any of the error messages listed in the .mem file. It just breaks.
>> 
>> 5) If I wrap the following inchi code (I'm using github suggested code):
>> 
>> calc = InChI.fromMolfile(molfile).trim();
>> 
>> in a try/catch, I get an error when the taxol related 3rd load break happens:
>> 
>> type error: undefined is not an object (evaluating "a.stack")
>> 
>> I guess I can understand why that taxol molfile breaks the app. It's a mess. 
>> I'd just like to catch this situation before the 3rd load break starts.
>> 
>> Oh yeah, the first page load after a cache clear almost always throws an 
>> error. This does not break the page however. It just means that you don't 
>> get a page load inchi calculation.
>> 
>> Otis
>> 
>> Sent from my iPad
>> 
>>> On Mar 8, 2016, at 3:50 PM, Robert Hanson  wrote:
>>> 
>>> huh?
>>> 
 On Mon, Mar 7, 2016 at 7:17 PM, Otis Rothenberger  
 wrote:
 Bob,
 
 Rats! It’s reporting no difference, but there is a difference. This seems 
 to be OK:
 
 $("#log").html(nci==calc ? "no difference" : "check differences?”);
 
 Calc seems to be OK. The problem is what’s printed on the screen for calc.
 
 Otis
 
 --
 Otis Rothenberger
 o...@chemagic.org
 http://chemagic.org
 
 > On Mar 7, 2016, at 6:33 PM, Otis Rothenberger  
 > wrote:
 >
 > Bob,
 >
 > I think it may be a timing issue with the function below. When I comment 
 > out the initial JQuery working… html replacements, the page no longer 
 > “locks.” I don’t think it was really locking. I think those html 
 > replacements somehow ran after the subsequent code. Which…
 >
 > makes absolutely no sense to me! Nevertheless, it seems to fix the 
 > problem.
 >
 > function getInChI(app,url) {
 >   //$("#inchi2div").html("working...");
 >   //$("#inchi1div").html("working...");
 >   //$("#log").html("working...");
 >   if (!url) { return; }
 >   nci = Jmol.evaluateVar(jmolApplet0,"show('chemical 
 > stdinchi')").trim();
 >   $("#inchi2div").html(nci + "(from 
 > NCI/CADD)");
 >   calc = 
 > InChI.fromMolfile(Jmol.evaluateVar(jmolApplet0,"write('MOL')")).trim();
 >   $("#inchi1div").html(calc + "(calculated 
 > in JavaScript)");
 >   $("#log").html(nci==calc ? "no difference" : "check differences?");
 > }
 >
 > Otis
 >
 > --
 > Otis Rothenberger
 > o...@chemagic.org
 > http://chemagic.org
 >
 >> On Mar 7, 2016, at 4:37 PM, Robert Hanson  wrote:
 >>
 >> Otis, note that there is a bug there. If you ask for the models in this 
 >> order:
 >>
 >> $taxol
 >> $morphine
 >>
 >> inchi.js seems to hang and just never respond. Something to do with the 
 >> fact that $taxol is pathologically 2D and not 3D. But
 >>
 >> $taxol
 >> $methanol
 >>
 >> works, until you ask for $morphine. Then 

Re: [Jmol-users] new InChI option

2016-03-08 Thread J. Bays
Just a question. Taxol is pretty a complex structure. Are you able to
calculate and load others of equal complexity without crashing? Perhaps the
error occurs in the calc part.

J. Philip Bays
Emeritus Professor of Chemistry
Saint Mary's College
Norte Dame, IN

Sent from my iPad

On Mar 8, 2016, at 6:22 PM, Otis Rothenberger  wrote:

Bob,

I'm using the approach on github. The molfile and the calculated inchi are
in globals per their suggestions. For testing, I set the globals to ""
before each model load. This led to erroneous matches at the taxol break -
i.e. "" == "".

I'm seeing all kinds of irratic behavior all related to taxol. Here's
what's pretty constant:

1) Things work pretty well if you don't load taxol!
2) Loading taxol results in:

a) Taxol works.
b) The next model load works (usually).
c) Any model (usually) breaks it on a third load. Why 3rd load after the
taxol bomb?

3) The ChemWriter demo at github does not like Taxol either - loaded via
paste Jmol taxol molfile.

4) When the Jmol page breaks with Taxol (3rd load, go figure), I'm not
seeing any of the error messages listed in the .mem file. It just breaks.

5) If I wrap the following inchi code (I'm using github suggested code):

calc = InChI.fromMolfile(molfile).trim();

in a try/catch, I get an error when the taxol related 3rd load break
happens:

type error: undefined is not an object (evaluating "a.stack")

I guess I can understand why that taxol molfile breaks the app. It's a
mess. I'd just like to catch this situation before the 3rd load break
starts.

Oh yeah, the first page load after a cache clear almost always throws an
error. This does not break the page however. It just means that you don't
get a page load inchi calculation.

Otis

Sent from my iPad

On Mar 8, 2016, at 3:50 PM, Robert Hanson  wrote:

huh?

On Mon, Mar 7, 2016 at 7:17 PM, Otis Rothenberger 
wrote:

> Bob,
>
> Rats! It’s reporting no difference, but there is a difference. This seems
> to be OK:
>
> $("#log").html(nci==calc ? "no difference" : "check differences?”);
>
> Calc seems to be OK. The problem is what’s printed on the screen for calc.
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> > On Mar 7, 2016, at 6:33 PM, Otis Rothenberger 
> wrote:
> >
> > Bob,
> >
> > I think it may be a timing issue with the function below. When I comment
> out the initial JQuery working… html replacements, the page no longer
> “locks.” I don’t think it was really locking. I think those html
> replacements somehow ran after the subsequent code. Which…
> >
> > makes absolutely no sense to me! Nevertheless, it seems to fix the
> problem.
> >
> > function getInChI(app,url) {
> >   //$("#inchi2div").html("working...");
> >   //$("#inchi1div").html("working...");
> >   //$("#log").html("working...");
> >   if (!url) { return; }
> >   nci = Jmol.evaluateVar(jmolApplet0,"show('chemical
> stdinchi')").trim();
> >   $("#inchi2div").html(nci + "(from
> NCI/CADD)");
> >   calc =
> InChI.fromMolfile(Jmol.evaluateVar(jmolApplet0,"write('MOL')")).trim();
> >   $("#inchi1div").html(calc + "(calculated
> in JavaScript)");
> >   $("#log").html(nci==calc ? "no difference" : "check differences?");
> > }
> >
> > Otis
> >
> > --
> > Otis Rothenberger
> > o...@chemagic.org
> > http://chemagic.org
> >
> >> On Mar 7, 2016, at 4:37 PM, Robert Hanson  wrote:
> >>
> >> Otis, note that there is a bug there. If you ask for the models in this
> order:
> >>
> >> $taxol
> >> $morphine
> >>
> >> inchi.js seems to hang and just never respond. Something to do with the
> fact that $taxol is pathologically 2D and not 3D. But
> >>
> >> $taxol
> >> $methanol
> >>
> >> works, until you ask for $morphine. Then it hangs.
> >>
> >> Go figure!
> >>
> >>
> >> Bob
> >>
> >>
> >>
> >>
> >
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department 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

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval


Re: [Jmol-users] new InChI option

2016-03-08 Thread Otis Rothenberger
Bob,

I was an avid reader of Rich Apodaca's Depth-First blog years ago, and I 
exchanged emails with him when I was considering ChemWriter for the model kit.

I thought about contacting him about the current inchi app problem, but his 
identity is kind of masked at his Metamolecular site, and Depth-First only 
exists as an archive from the past. Markus adopted ChemWriter for Resolver, and 
I think he knows Rich. I'll write to Markus about our interest in this 
application and about contacting Rich.

It's funny. I think taxol was the classic "hey it loads taxol" experiment when 
this stuff all started, and I swear that I remember that taxol loaded as a 3d 
model!

Otis

Sent from my iPad

> On Mar 8, 2016, at 6:39 PM, Robert Hanson  wrote:
> 
> OK, so there are some bugs there. And loading trashy 2D files is definitely a 
> bad idea. Otis, can you figure out the way to report this sort of thing?
> ​
> Bob
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-08 Thread Robert Hanson
OK, so there are some bugs there. And loading trashy 2D files is definitely
a bad idea. Otis, can you figure out the way to report this sort of thing?
​
Bob
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-08 Thread Otis Rothenberger
Bob,

I'm using the approach on github. The molfile and the calculated inchi are in 
globals per their suggestions. For testing, I set the globals to "" before each 
model load. This led to erroneous matches at the taxol break - i.e. "" == "". 

I'm seeing all kinds of irratic behavior all related to taxol. Here's what's 
pretty constant:

1) Things work pretty well if you don't load taxol!
2) Loading taxol results in:

a) Taxol works.
b) The next model load works (usually).
c) Any model (usually) breaks it on a third load. Why 3rd load after the taxol 
bomb?

3) The ChemWriter demo at github does not like Taxol either - loaded via paste 
Jmol taxol molfile.

4) When the Jmol page breaks with Taxol (3rd load, go figure), I'm not seeing 
any of the error messages listed in the .mem file. It just breaks.

5) If I wrap the following inchi code (I'm using github suggested code):

calc = InChI.fromMolfile(molfile).trim();

in a try/catch, I get an error when the taxol related 3rd load break happens:

type error: undefined is not an object (evaluating "a.stack")

I guess I can understand why that taxol molfile breaks the app. It's a mess. 
I'd just like to catch this situation before the 3rd load break starts.

Oh yeah, the first page load after a cache clear almost always throws an error. 
This does not break the page however. It just means that you don't get a page 
load inchi calculation.

Otis

Sent from my iPad

> On Mar 8, 2016, at 3:50 PM, Robert Hanson  wrote:
> 
> huh?
> 
>> On Mon, Mar 7, 2016 at 7:17 PM, Otis Rothenberger  
>> wrote:
>> Bob,
>> 
>> Rats! It’s reporting no difference, but there is a difference. This seems to 
>> be OK:
>> 
>> $("#log").html(nci==calc ? "no difference" : "check differences?”);
>> 
>> Calc seems to be OK. The problem is what’s printed on the screen for calc.
>> 
>> Otis
>> 
>> --
>> Otis Rothenberger
>> o...@chemagic.org
>> http://chemagic.org
>> 
>> > On Mar 7, 2016, at 6:33 PM, Otis Rothenberger  wrote:
>> >
>> > Bob,
>> >
>> > I think it may be a timing issue with the function below. When I comment 
>> > out the initial JQuery working… html replacements, the page no longer 
>> > “locks.” I don’t think it was really locking. I think those html 
>> > replacements somehow ran after the subsequent code. Which…
>> >
>> > makes absolutely no sense to me! Nevertheless, it seems to fix the problem.
>> >
>> > function getInChI(app,url) {
>> >   //$("#inchi2div").html("working...");
>> >   //$("#inchi1div").html("working...");
>> >   //$("#log").html("working...");
>> >   if (!url) { return; }
>> >   nci = Jmol.evaluateVar(jmolApplet0,"show('chemical 
>> > stdinchi')").trim();
>> >   $("#inchi2div").html(nci + "(from 
>> > NCI/CADD)");
>> >   calc = 
>> > InChI.fromMolfile(Jmol.evaluateVar(jmolApplet0,"write('MOL')")).trim();
>> >   $("#inchi1div").html(calc + "(calculated in 
>> > JavaScript)");
>> >   $("#log").html(nci==calc ? "no difference" : "check differences?");
>> > }
>> >
>> > Otis
>> >
>> > --
>> > Otis Rothenberger
>> > o...@chemagic.org
>> > http://chemagic.org
>> >
>> >> On Mar 7, 2016, at 4:37 PM, Robert Hanson  wrote:
>> >>
>> >> Otis, note that there is a bug there. If you ask for the models in this 
>> >> order:
>> >>
>> >> $taxol
>> >> $morphine
>> >>
>> >> inchi.js seems to hang and just never respond. Something to do with the 
>> >> fact that $taxol is pathologically 2D and not 3D. But
>> >>
>> >> $taxol
>> >> $methanol
>> >>
>> >> works, until you ask for $morphine. Then it hangs.
>> >>
>> >> Go figure!
>> >>
>> >>
>> >> Bob
>> >>
>> >>
>> >>
>> >>
>> >
>> 
>> 
>> --
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://makebettercode.com/inteldaal-eval
>> ___
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
> 
> 
> 
> -- 
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Department 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
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

Re: [Jmol-users] new InChI option

2016-03-08 Thread Robert Hanson
huh?

On Mon, Mar 7, 2016 at 7:17 PM, Otis Rothenberger 
wrote:

> Bob,
>
> Rats! It’s reporting no difference, but there is a difference. This seems
> to be OK:
>
> $("#log").html(nci==calc ? "no difference" : "check differences?”);
>
> Calc seems to be OK. The problem is what’s printed on the screen for calc.
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> > On Mar 7, 2016, at 6:33 PM, Otis Rothenberger 
> wrote:
> >
> > Bob,
> >
> > I think it may be a timing issue with the function below. When I comment
> out the initial JQuery working… html replacements, the page no longer
> “locks.” I don’t think it was really locking. I think those html
> replacements somehow ran after the subsequent code. Which…
> >
> > makes absolutely no sense to me! Nevertheless, it seems to fix the
> problem.
> >
> > function getInChI(app,url) {
> >   //$("#inchi2div").html("working...");
> >   //$("#inchi1div").html("working...");
> >   //$("#log").html("working...");
> >   if (!url) { return; }
> >   nci = Jmol.evaluateVar(jmolApplet0,"show('chemical
> stdinchi')").trim();
> >   $("#inchi2div").html(nci + "(from
> NCI/CADD)");
> >   calc =
> InChI.fromMolfile(Jmol.evaluateVar(jmolApplet0,"write('MOL')")).trim();
> >   $("#inchi1div").html(calc + "(calculated
> in JavaScript)");
> >   $("#log").html(nci==calc ? "no difference" : "check differences?");
> > }
> >
> > Otis
> >
> > --
> > Otis Rothenberger
> > o...@chemagic.org
> > http://chemagic.org
> >
> >> On Mar 7, 2016, at 4:37 PM, Robert Hanson  wrote:
> >>
> >> Otis, note that there is a bug there. If you ask for the models in this
> order:
> >>
> >> $taxol
> >> $morphine
> >>
> >> inchi.js seems to hang and just never respond. Something to do with the
> fact that $taxol is pathologically 2D and not 3D. But
> >>
> >> $taxol
> >> $methanol
> >>
> >> works, until you ask for $morphine. Then it hangs.
> >>
> >> Go figure!
> >>
> >>
> >> Bob
> >>
> >>
> >>
> >>
> >
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department 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
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-08 Thread Otis Rothenberger
Bob,

I think it may be a timing issue with the function below. When I comment out 
the initial JQuery working… html replacements, the page no longer “locks.” I 
don’t think it was really locking. I think those html replacements somehow ran 
after the subsequent code. Which…

makes absolutely no sense to me! Nevertheless, it seems to fix the problem.

function getInChI(app,url) {
//$("#inchi2div").html("working...");
//$("#inchi1div").html("working...");
//$("#log").html("working...");
if (!url) { return; }
nci = Jmol.evaluateVar(jmolApplet0,"show('chemical stdinchi')").trim();
$("#inchi2div").html(nci + "(from NCI/CADD)");
calc = 
InChI.fromMolfile(Jmol.evaluateVar(jmolApplet0,"write('MOL')")).trim();
$("#inchi1div").html(calc + "(calculated in 
JavaScript)");
$("#log").html(nci==calc ? "no difference" : "check differences?");
}

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 7, 2016, at 4:37 PM, Robert Hanson  wrote:
> 
> Otis, note that there is a bug there. If you ask for the models in this order:
> 
> $taxol
> $morphine
> 
> inchi.js seems to hang and just never respond. Something to do with the fact 
> that $taxol is pathologically 2D and not 3D. But 
> 
> $taxol
> $methanol
> 
> works, until you ask for $morphine. Then it hangs.
> 
> Go figure!
> 
> 
> Bob
> 
> 
> 
> 


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-08 Thread Otis Rothenberger
Bob,

Rats! It’s reporting no difference, but there is a difference. This seems to be 
OK:

$("#log").html(nci==calc ? "no difference" : "check differences?”);

Calc seems to be OK. The problem is what’s printed on the screen for calc.

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 7, 2016, at 6:33 PM, Otis Rothenberger  wrote:
> 
> Bob,
> 
> I think it may be a timing issue with the function below. When I comment out 
> the initial JQuery working… html replacements, the page no longer “locks.” I 
> don’t think it was really locking. I think those html replacements somehow 
> ran after the subsequent code. Which…
> 
> makes absolutely no sense to me! Nevertheless, it seems to fix the problem.
> 
> function getInChI(app,url) {
>   //$("#inchi2div").html("working...");
>   //$("#inchi1div").html("working...");
>   //$("#log").html("working...");
>   if (!url) { return; }
>   nci = Jmol.evaluateVar(jmolApplet0,"show('chemical stdinchi')").trim();
>   $("#inchi2div").html(nci + "(from NCI/CADD)");
>   calc = 
> InChI.fromMolfile(Jmol.evaluateVar(jmolApplet0,"write('MOL')")).trim();
>   $("#inchi1div").html(calc + "(calculated in 
> JavaScript)");
>   $("#log").html(nci==calc ? "no difference" : "check differences?");
> }
> 
> Otis
> 
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
> 
>> On Mar 7, 2016, at 4:37 PM, Robert Hanson  wrote:
>> 
>> Otis, note that there is a bug there. If you ask for the models in this 
>> order:
>> 
>> $taxol
>> $morphine
>> 
>> inchi.js seems to hang and just never respond. Something to do with the fact 
>> that $taxol is pathologically 2D and not 3D. But 
>> 
>> $taxol
>> $methanol
>> 
>> works, until you ask for $morphine. Then it hangs.
>> 
>> Go figure!
>> 
>> 
>> Bob
>> 
>> 
>> 
>> 
> 


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-07 Thread Robert Hanson
Otis, note that there is a bug there. If you ask for the models in this
order:

$taxol
$morphine

inchi.js seems to hang and just never respond. Something to do with the
fact that $taxol is pathologically 2D and not 3D. But

$taxol
$methanol

works, until you ask for $morphine. Then it hangs.

Go figure!


Bob




On Mon, Mar 7, 2016 at 3:24 PM, Otis Rothenberger 
wrote:

> Bob,
>
> I have it running now. The mime type registration on my server was the
> problem. I’m using (application/octet-stream .mem)
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> > On Mar 7, 2016, at 3:59 PM, Otis Rothenberger 
> wrote:
> >
> > Bob,
> >
> > OK, I think my problem is setting a mime type on my server of the format:
> >
> > text/plain .mem
> >
> > This file has binary data - correct? Do you have any idea what mime type
> I should set for this using the above format - i.e. what replaces
> text/plain?
> >
> > Otis
> >
> >
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department 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
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-07 Thread Otis Rothenberger
Bob,

I have it running now. The mime type registration on my server was the problem. 
I’m using (application/octet-stream .mem)

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 7, 2016, at 3:59 PM, Otis Rothenberger  wrote:
> 
> Bob,
> 
> OK, I think my problem is setting a mime type on my server of the format:
> 
> text/plain .mem
> 
> This file has binary data - correct? Do you have any idea what mime type I 
> should set for this using the above format - i.e. what replaces text/plain?
> 
> Otis
> 
> 


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-07 Thread Otis Rothenberger
Bob,

OK, I think my problem is setting a mime type on my server of the format:

text/plain .mem

This file has binary data - correct? Do you have any idea what mime type I 
should set for this using the above format - i.e. what replaces text/plain?

Otis


--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 7, 2016, at 3:31 PM, Otis Rothenberger  wrote:
> 
> Bob,
> 
> I’m having a hard time with this file on my server: inchi.js.mem
> 
> 404 errors.
> 
> I can only run the htm page on my server (windows) if I change the 
> appropriate page URL setting info to pick up the inchi.js on your server. I 
> have to disable cross origin to do this. At home I’m working with Mac, and my 
> Mac automatically slaps a .js on the inchi.js.mem file when I download it. I 
> change in back, but I have a feeling my Mac is messing with that file.
> 
> This inchi stuff requires jsmol.php. Am that correct?
> 
> Otis
> --
> Otis Rothenberger
> o...@chemagic.org 
> http://chemagic.org
> 

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-07 Thread Otis Rothenberger
Bob,

I’m having a hard time with this file on my server: inchi.js.mem

404 errors.

I can only run the htm page on my server (windows) if I change the appropriate 
page URL setting info to pick up the inchi.js on your server. I have to disable 
cross origin to do this. At home I’m working with Mac, and my Mac automatically 
slaps a .js on the inchi.js.mem file when I download it. I change in back, but 
I have a feeling my Mac is messing with that file.

This inchi stuff requires jsmol.php. Am that correct?

Otis
--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 7, 2016, at 3:08 PM, Robert Hanson  wrote:
> 
> yeah, I don't know that it is worth 900 KB to get locally what you can get 
> from NCI/CADD, but it is cool that they were able to get that going. 
> 
> I have found a bug, though, in that sometimes it can hang and then never 
> respond again. (Kind of like NCI...;)
> 
> 
> 
> On Mon, Mar 7, 2016 at 1:04 PM, Otis Rothenberger  > wrote:
> Bob,
> 
> I’m not completely clear on the details, but inchi has some open ended 
> capability that makes it a variable identifier, thus playing havoc with 
> look-up and keys. The stdinchi does not have this extended usage. Thus 
> stdinchi and stdinchikey are the way to go for most look-up.
> 
> Even though it’s weighty, I really like this new feature. With SMILES and 
> stdinchi, Jmol really has a new cheminformatics punch. I’m learning more and 
> more toward having users run the model kit locally, so I want to look into 
> this stdinchi capability.
> 
> Otis
> 
> --
> Otis Rothenberger
> o...@chemagic.org 
> http://chemagic.org 
> 
> > On Mar 7, 2016, at 1:44 PM, Robert Hanson  > > wrote:
> >
> > Thanks, Otis -- I forgot that there were two InChI calls for NCI -- "inchi" 
> > and "stdinchi". Changing that makes them identical.
> > ​
> > Bob
> > --
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> > http://makebettercode.com/inteldaal-eval___
> >  
> > 
> > Jmol-users mailing list
> > Jmol-users@lists.sourceforge.net 
> > https://lists.sourceforge.net/lists/listinfo/jmol-users 
> > 
> 
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval 
> 
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/jmol-users 
> 
> 
> 
> 
> -- 
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Department 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
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-07 Thread Robert Hanson
yeah, I don't know that it is worth 900 KB to get locally what you can get
from NCI/CADD, but it is cool that they were able to get that going.

I have found a bug, though, in that sometimes it can hang and then never
respond again. (Kind of like NCI...;)



On Mon, Mar 7, 2016 at 1:04 PM, Otis Rothenberger 
wrote:

> Bob,
>
> I’m not completely clear on the details, but inchi has some open ended
> capability that makes it a variable identifier, thus playing havoc with
> look-up and keys. The stdinchi does not have this extended usage. Thus
> stdinchi and stdinchikey are the way to go for most look-up.
>
> Even though it’s weighty, I really like this new feature. With SMILES and
> stdinchi, Jmol really has a new cheminformatics punch. I’m learning more
> and more toward having users run the model kit locally, so I want to look
> into this stdinchi capability.
>
> Otis
>
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
>
> > On Mar 7, 2016, at 1:44 PM, Robert Hanson  wrote:
> >
> > Thanks, Otis -- I forgot that there were two InChI calls for NCI --
> "inchi" and "stdinchi". Changing that makes them identical.
> > ​
> > Bob
> >
> --
> > Transform Data into Opportunity.
> > Accelerate data analysis in your applications with
> > Intel Data Analytics Acceleration Library.
> > Click to learn more.
> >
> http://makebettercode.com/inteldaal-eval___
> > Jmol-users mailing list
> > Jmol-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jmol-users
>
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>



-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department 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
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-07 Thread Otis Rothenberger
Bob,

I’m not completely clear on the details, but inchi has some open ended 
capability that makes it a variable identifier, thus playing havoc with look-up 
and keys. The stdinchi does not have this extended usage. Thus stdinchi and 
stdinchikey are the way to go for most look-up.

Even though it’s weighty, I really like this new feature. With SMILES and 
stdinchi, Jmol really has a new cheminformatics punch. I’m learning more and 
more toward having users run the model kit locally, so I want to look into this 
stdinchi capability.

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 7, 2016, at 1:44 PM, Robert Hanson  wrote:
> 
> Thanks, Otis -- I forgot that there were two InChI calls for NCI -- "inchi" 
> and "stdinchi". Changing that makes them identical.
> ​
> Bob
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval
___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-07 Thread Robert Hanson
Thanks, Otis -- I forgot that there were two InChI calls for NCI -- "inchi"
and "stdinchi". Changing that makes them identical.
​
Bob
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-06 Thread Otis Rothenberger
OK, I see what’s doing it:


Jmol.evaluateVar(jmolApplet0,"show('chemical inchi')”) VS 
Jmol.evaluateVar(jmolApplet0,"show('chemical stdinchi')”)


I did not know that Resolver would do inch and stdinchi

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

> On Mar 7, 2016, at 1:47 AM, osrot...@icloud.com wrote:
> 
> Bob,
> 
> Neat.
> 
> I'm a bit confused by the Resolver InChI report. It states 1/... "Calculate 
> here" shows 1S/...
> 
> I think Resolver only reports 1S/... - standard InChI.
> 
> Are the results possibly cross-reported? One is standard InChI and the other 
> is not.
> 
> Otis
> 
> --
> Otis Rothenberger
> o...@chemagic.org
> http://chemagic.org
> 
> On Mar 7, 2016, 1:09 AM -0500, Robert Hanson , wrote:
>> 
>> http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm 
>> 
>> 
>> demonstrates a new option - calculating an InChI in JavaScript from a JSmol 
>> model.
>> 
>> The InChI code is a bit heavy -- 800K.
>> 
>> Interesting to compare with what NCI/CADD returns.
>> 
>> Necessary files are in http://chemapps.stolaf.edu/jmol/jsmol/inchi 
>> 
>> 
>> The JavaScript code is from https://github.com/metamolecular/inchi-js 
>> 
>> 
>> Bob
>> 
>> --
>> Robert M. Hanson
>> Larson-Anderson Professor of Chemistry
>> Chair, Department 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
>> 
>> --
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn more.
>> http://makebettercode.com/inteldaal-eval
>> ___
>> Jmol-users mailing list
>> Jmol-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jmol-users
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


Re: [Jmol-users] new InChI option

2016-03-06 Thread osrothen
Bob,

Neat.

I'm a bit confused by the Resolver InChI report. It states 1/... "Calculate 
here" shows 1S/...

I think Resolver only reports 1S/... - standard InChI.

Are the results possibly cross-reported? One is standard InChI and the other is 
not.

Otis

--
Otis Rothenberger
o...@chemagic.org
http://chemagic.org

On Mar 7, 2016, 1:09 AM -0500, Robert Hanson, wrote:
> 
> http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm
> 
> demonstrates a new option - calculating an InChI in JavaScript from a JSmol 
> model.
> 
> The InChI code is a bit heavy -- 800K.
> 
> Interesting to compare with what NCI/CADD returns.
> 
> Necessary files are inhttp://chemapps.stolaf.edu/jmol/jsmol/inchi
> 
> The JavaScript code is fromhttps://github.com/metamolecular/inchi-js
> 
> Bob
> 
> --
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Department 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
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://makebettercode.com/inteldaal-eval
> ___
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users


[Jmol-users] new InChI option

2016-03-06 Thread Robert Hanson
http://chemapps.stolaf.edu/jmol/jsmol/inchi.htm

demonstrates a new option - calculating an InChI in JavaScript from a JSmol
model.

The InChI code is a bit heavy -- 800K.

Interesting to compare with what NCI/CADD returns.

Necessary files are in http://chemapps.stolaf.edu/jmol/jsmol/inchi

The JavaScript code is from https://github.com/metamolecular/inchi-js

Bob

-- 
Robert M. Hanson
Larson-Anderson Professor of Chemistry
Chair, Department 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
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval___
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users