From: Egon W. <ego...@gm...> - 2010-07-30 06:41:01
|
Hi all, The master branch does not all the stuff I was hoping to see in CDK 1.4, but there is always 1.6, I guess... Seriously, I merged in the changes from cdk-1.2.x and it went pretty smooth, but the number of manual changes I need to make are slowly increasing... So, what I would like to do is create a new branch, cdk-1.4.x, and start fixing the failing unit tests, to bring the number of fails and errors in the same range as cdk-1.2.x, or preferably below. But, this means that we would seriously move towards a CDK 1.4.0 release, replacing the current CDK 1.2.x series... Does anyone see any problems with that right now? There is at least a week or two to get the unit test fail down, so there is still some time to move in new functionality, but that may happen after the branching too anyway... Your thoughts please... Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Rajarshi G. <raj...@gm...> - 2010-07-30 12:06:55
|
How long has 1.2.x been out? I Know that people have issues with breaking the API and 1.4 would do that in a number of places (for the better, IMO) On Jul 30, 2010, at 2:40 AM, Egon Willighagen wrote: > Hi all, > > The master branch does not all the stuff I was hoping to see in CDK > 1.4, but there is always 1.6, I guess... > > Seriously, I merged in the changes from cdk-1.2.x and it went pretty > smooth, but the number of manual changes I need to make are slowly > increasing... > > So, what I would like to do is create a new branch, cdk-1.4.x, and > start fixing the failing unit tests, to bring the number of fails and > errors in the same range as cdk-1.2.x, or preferably below. > > But, this means that we would seriously move towards a CDK 1.4.0 > release, replacing the current CDK 1.2.x series... Does anyone see any > problems with that right now? > > There is at least a week or two to get the unit test fail down, so > there is still some time to move in new functionality, but that may > happen after the branching too anyway... > > Your thoughts please... > > Egon > > -- > Post-doc @ Uppsala University > Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg > Homepage: http://egonw.github.com/ > Blog: http://chem-bla-ics.blogspot.com/ > PubList: http://www.citeulike.org/user/egonw/tag/papers > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel ---------------------------------------------------- Rajarshi Guha | NIH Chemical Genomics Center http://www.rguha.net | http://ncgc.nih.gov ---------------------------------------------------- A memorandum is written not to inform the reader, but to protect the writer. -- Dean Acheson |
From: Egon W. <ego...@gm...> - 2010-07-30 19:24:34
|
On Fri, Jul 30, 2010 at 2:06 PM, Rajarshi Guha <raj...@gm...> wrote: > How long has 1.2.x been out? I Know that people have issues with > breaking the API and 1.4 would do that in a number of places (for the > better, IMO) CDK 1.2.0 was released at 2009-03-12. Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Jules K. <jul...@go...> - 2010-08-02 11:10:10
|
So 1.2.0. came out about a year-and-a-half ago, especially in the early stages of a project, that is not a long time (especially considering many major linux distro's have a full release every half-year, we're two behind ;-) ) If everybody feels a lot of significant functionality was added in 1.3 since that time, and that new stuff is ready for production, then I don't see a reason why not to go to 1.4 API-breaking is inevitable when adding major functionality, and it is not like 1.2.6 suddenly will vanish from the download servers, so people can keep using that if they don't care for the new stuff. If they do care about the new stuff, they'll need the new(/improved) api anyway to interface the new code, so there's no 'additional loss' there. And if we're on the topic of api-breaking anyway: One of the things I would like to see updated is the IChemobject.getProperty() suite. It now returns a base Object, relying on the user to figure out what type it should be cast to. This is trouble waiting to happen when somebody accidentally (purposefully?) puts in/retrieves the wrong type. I really, really like the strong typing for parameters used in the renderer classes (with a subclass for each parameter). This gives you 100% rigid control over the return types. I do guess it's to short a notice to get this in 1.4, but could this be something to start working on in 1.5 for eventual inclusion into 1.6? This at the very core of the CDK api, so it may even have to wait until 2.0. Kind regards, Jules On 30 July 2010 21:24, Egon Willighagen <ego...@gm...> wrote: > On Fri, Jul 30, 2010 at 2:06 PM, Rajarshi Guha <raj...@gm...> wrote: >> How long has 1.2.x been out? I Know that people have issues with >> breaking the API and 1.4 would do that in a number of places (for the >> better, IMO) > > CDK 1.2.0 was released at 2009-03-12. > > Egon > > -- > Post-doc @ Uppsala University > Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg > Homepage: http://egonw.github.com/ > Blog: http://chem-bla-ics.blogspot.com/ > PubList: http://www.citeulike.org/user/egonw/tag/papers > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > |
From: Egon W. <ego...@gm...> - 2010-08-02 13:29:10
|
On Mon, Aug 2, 2010 at 12:09 PM, Jules Kerssemakers <jul...@go...> wrote: > API-breaking is inevitable when adding major functionality, and it is > not like 1.2.6 suddenly will vanish from the download servers, so > people can keep using that if they don't care for the new stuff. We can have a couple of 1.2-to-1.4 online workshops where 'we' can sit down on problems users encounter, where the patch commiters like me can help out... Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Rajarshi G. <raj...@gm...> - 2010-08-02 13:33:19
|
Well one major reason for a 1.4 branch is to bring back rendering into the main library! On Mon, Aug 2, 2010 at 9:28 AM, Egon Willighagen <ego...@gm...> wrote: > On Mon, Aug 2, 2010 at 12:09 PM, Jules Kerssemakers > <jul...@go...> wrote: >> API-breaking is inevitable when adding major functionality, and it is >> not like 1.2.6 suddenly will vanish from the download servers, so >> people can keep using that if they don't care for the new stuff. > > We can have a couple of 1.2-to-1.4 online workshops where 'we' can sit > down on problems users encounter, where the patch commiters like me > can help out... > > Egon > > -- > Post-doc @ Uppsala University > Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg > Homepage: http://egonw.github.com/ > Blog: http://chem-bla-ics.blogspot.com/ > PubList: http://www.citeulike.org/user/egonw/tag/papers > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > -- Rajarshi Guha NIH Chemical Genomics Center |
From: Syed A. R. <s9...@go...> - 2010-08-02 13:47:01
|
I am wondering if its better to move to CDK 2.0 with such changes (1.2 + 1.3 etc) or remain in this 1.* orbit? Asad On 2 Aug 2010, at 14:33, Rajarshi Guha wrote: > Well one major reason for a 1.4 branch is to bring back rendering into > the main library! > > On Mon, Aug 2, 2010 at 9:28 AM, Egon Willighagen > <ego...@gm...> wrote: >> On Mon, Aug 2, 2010 at 12:09 PM, Jules Kerssemakers >> <jul...@go...> wrote: >>> API-breaking is inevitable when adding major functionality, and it is >>> not like 1.2.6 suddenly will vanish from the download servers, so >>> people can keep using that if they don't care for the new stuff. >> >> We can have a couple of 1.2-to-1.4 online workshops where 'we' can sit >> down on problems users encounter, where the patch commiters like me >> can help out... >> >> Egon >> >> -- >> Post-doc @ Uppsala University >> Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg >> Homepage: http://egonw.github.com/ >> Blog: http://chem-bla-ics.blogspot.com/ >> PubList: http://www.citeulike.org/user/egonw/tag/papers >> >> ------------------------------------------------------------------------------ >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> of $1 Million in cash or HP Products. Visit us here for more details: >> http://p.sf.net/sfu/dev2dev-palm >> _______________________________________________ >> Cdk-devel mailing list >> Cdk...@li... >> https://lists.sourceforge.net/lists/listinfo/cdk-devel >> > > > > -- > Rajarshi Guha > NIH Chemical Genomics Center > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel |
From: Egon W. <ego...@gm...> - 2010-08-02 13:49:34
|
On Mon, Aug 2, 2010 at 2:45 PM, Syed Asad Rahman <s9...@go...> wrote: > I am wondering if its better to move to CDK 2.0 with such changes (1.2 + 1.3 etc) or remain in this 1.* orbit? We need to first decide how and when we want to move to a next stable version. What version that will have is not important right now. Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Egon W. <ego...@gm...> - 2010-08-05 16:32:42
|
On Mon, Aug 2, 2010 at 2:33 PM, Rajarshi Guha <raj...@gm...> wrote: > Well one major reason for a 1.4 branch is to bring back rendering into > the main library! True. And that code is available as patch on top of the main library. But not yet as core part, though. Anyway... I like some consensus... Yes or no? Because of increasing number of API patches, I am no longer trusting git to do what is right. So, independent of what we say above, I think we should stop 'merging' in changes from cdk-1.2.x, but start using 'git cherry-pick' instead... Rajarshi, what are your thoughts on that? Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Rajarshi G. <raj...@gm...> - 2010-08-06 01:05:17
|
On Aug 5, 2010, at 12:32 PM, Egon Willighagen wrote: > On Mon, Aug 2, 2010 at 2:33 PM, Rajarshi Guha > <raj...@gm...> wrote: >> Well one major reason for a 1.4 branch is to bring back rendering >> into >> the main library! > > True. And that code is available as patch on top of the main library. > But not yet as core part, though. > > Anyway... I like some consensus... > > Yes or no? Yes, to a new 1.4 branch and EOL of 1.2 branch > Because of increasing number of API patches, I am no longer trusting > git to do what is right. So, independent of what we say above, I think > we should stop 'merging' in changes from cdk-1.2.x, but start using > 'git cherry-pick' instead... > > Rajarshi, what are your thoughts on that? git cherry-pick is good, but if we decide on EOL for 1.2, then we don't need to bother ---------------------------------------------------- Rajarshi Guha | NIH Chemical Genomics Center http://www.rguha.net | http://ncgc.nih.gov ---------------------------------------------------- A red sign on the door of a physics professor: 'If this sign is blue, you're going too fast.' |
From: Egon W. <ego...@gm...> - 2010-08-09 10:04:41
|
On Fri, Aug 6, 2010 at 2:05 AM, Rajarshi Guha <raj...@gm...> wrote: > Yes, to a new 1.4 branch and EOL of 1.2 branch Agreed. > git cherry-pick is good, but if we decide on EOL for 1.2, then we don't need > to bother If we freeze 1.4 now, then we'll still have some overlap... the number of regressions in the current master branch is still too high to release 1.4.0... it's needs to go down a further 20 unit tests... (preferably more of course ... ) OK, one last question then... IBond.Order.SINGLE_OR_DOUBLE... part of 1.4, or move to 1.6? This is the famous bond order in the SMILES c1ccccc1... but I expect bugs... plenty of bugs... as this will need updates all over the code... a lot of code is assuming SINGLE, DOUBLE, or TRIPLE... (yes, there are actually bugs due to QUADRUPLE, though I have not filed them yet) Egon -- Post-doc @ Uppsala University Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Rajarshi G. <raj...@gm...> - 2010-08-11 14:13:43
|
On Aug 9, 2010, at 6:04 AM, Egon Willighagen wrote: > OK, one last question then... > > IBond.Order.SINGLE_OR_DOUBLE... part of 1.4, or move to 1.6? > > This is the famous bond order in the SMILES c1ccccc1... but I expect > bugs... plenty of bugs... as this will need updates all over the > code... a lot of code is assuming SINGLE, DOUBLE, or TRIPLE... (yes, > there are actually bugs due to QUADRUPLE, though I have not filed them > yet) I'd say, 1.4 - we have to take the hit at one point! ---------------------------------------------------- Rajarshi Guha | NIH Chemical Genomics Center http://www.rguha.net | http://ncgc.nih.gov ---------------------------------------------------- In matrimony, to hesitate is sometimes to be saved. -- Butler |
From: Egon W. <ego...@gm...> - 2010-08-11 14:17:16
|
On Wed, Aug 11, 2010 at 4:13 PM, Rajarshi Guha <raj...@gm...> wrote: > On Aug 9, 2010, at 6:04 AM, Egon Willighagen wrote: >> This is the famous bond order in the SMILES c1ccccc1... but I expect >> bugs... plenty of bugs... as this will need updates all over the >> code... a lot of code is assuming SINGLE, DOUBLE, or TRIPLE... (yes, >> there are actually bugs due to QUADRUPLE, though I have not filed them >> yet) > > I'd say, 1.4 - we have to take the hit at one point! I tried it earlier this week... [0]... but it's not gonna make it... there is incompatible code, at least: IAtomContainer.getBondOrderSum(IAtom) IAtomContainer.getMaximumBondOrder(IAtom) Doing anything in this area will require a proper rethinking of the bond types in the CDK data model... So, I withdraw my suggestion... let's postpone this until after 1.4... Egon -- Dr E.L. Willighagen Post-doc @ Uppsala University (only until 2010-09-30) Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Rajarshi G. <raj...@gm...> - 2010-08-11 14:24:35
|
On Aug 11, 2010, at 10:16 AM, Egon Willighagen wrote: > On Wed, Aug 11, 2010 at 4:13 PM, Rajarshi Guha <raj...@gm... > > wrote: >> On Aug 9, 2010, at 6:04 AM, Egon Willighagen wrote: >>> This is the famous bond order in the SMILES c1ccccc1... but I expect >>> bugs... plenty of bugs... as this will need updates all over the >>> code... a lot of code is assuming SINGLE, DOUBLE, or TRIPLE... (yes, >>> there are actually bugs due to QUADRUPLE, though I have not filed >>> them >>> yet) >> >> I'd say, 1.4 - we have to take the hit at one point! > > I tried it earlier this week... [0]... but it's not gonna make it... > there is incompatible code, at least: Aah, OK > > IAtomContainer.getBondOrderSum(IAtom) > IAtomContainer.getMaximumBondOrder(IAtom) > > Doing anything in this area will require a proper rethinking of the > bond types in the CDK data model... Didn't we use 1.5 as the bond order for aromatic bonds at one point? ---------------------------------------------------- Rajarshi Guha | NIH Chemical Genomics Center http://www.rguha.net | http://ncgc.nih.gov ---------------------------------------------------- Science kind of takes the fun out of the portent business. -Hobbes |
From: Egon W. <ego...@gm...> - 2010-08-11 14:40:30
|
On Wed, Aug 11, 2010 at 4:24 PM, Rajarshi Guha <raj...@gm...> wrote: >> Doing anything in this area will require a proper rethinking of the >> bond types in the CDK data model... > > Didn't we use 1.5 as the bond order for aromatic bonds at one point? Yes, and I was really happy we got rid of that :) I was questioned earlier this week about the sense behind SINGLE_OR_DOUBLE... perhaps it is indeed not the way to go... (bloody SMILES) Egon -- Dr E.L. Willighagen Post-doc @ Uppsala University (only until 2010-09-30) Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Nina J. <jel...@gm...> - 2010-08-11 14:29:19
|
Rajarshi, Egon, I recall there was emailing in April about introducing SINGE_OR_DOUBLE and me being silent then it is somewhat awkward to propose to reconsider the decision now, but given the current DeduceBondSystemTool behaviour, and apparently not easy change - could you still tell if introducing SINGE_OR_DOUBLE will really be a gain ? Consider an user entering aromatic SMILES, readers will parse it into the new singe or double type of bond; even if all processing code works fine, it will still be impossible to write the structure back in a e.g. MOL file, unless bonds are assigned either single or double type. Getting back the aromatic bond type might be an easier workaround. Best regards, Nina On Wed, Aug 11, 2010 at 5:16 PM, Egon Willighagen <ego...@gm...> wrote: > On Wed, Aug 11, 2010 at 4:13 PM, Rajarshi Guha <raj...@gm...> wrote: >> On Aug 9, 2010, at 6:04 AM, Egon Willighagen wrote: >>> This is the famous bond order in the SMILES c1ccccc1... but I expect >>> bugs... plenty of bugs... as this will need updates all over the >>> code... a lot of code is assuming SINGLE, DOUBLE, or TRIPLE... (yes, >>> there are actually bugs due to QUADRUPLE, though I have not filed them >>> yet) >> >> I'd say, 1.4 - we have to take the hit at one point! > > I tried it earlier this week... [0]... but it's not gonna make it... > there is incompatible code, at least: > > IAtomContainer.getBondOrderSum(IAtom) > IAtomContainer.getMaximumBondOrder(IAtom) > > Doing anything in this area will require a proper rethinking of the > bond types in the CDK data model... > > So, I withdraw my suggestion... let's postpone this until after 1.4... > > Egon > > > -- > Dr E.L. Willighagen > Post-doc @ Uppsala University (only until 2010-09-30) > Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg > Homepage: http://egonw.github.com/ > Blog: http://chem-bla-ics.blogspot.com/ > PubList: http://www.citeulike.org/user/egonw/tag/papers > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > |
From: Egon W. <ego...@gm...> - 2010-08-11 15:19:44
|
Nina, I think you might be right... On Wed, Aug 11, 2010 at 4:29 PM, Nina Jeliazkova <jel...@gm...> wrote: > Consider an user entering aromatic SMILES, readers will parse it into > the new singe or double type of bond; even if all processing code > works fine, it will still be impossible to write the structure back in > a e.g. MOL file, unless bonds are assigned either single or double > type. I was thinking of perhaps just using UNKNOWN instead... which we currently have as 'null'... > Getting back the aromatic bond type might be an easier workaround. I remember I was quite happy to see the aromatic bond type gone... we have flags for this, allowing us to actually have SINGLE *and* ISAROMATIC... with an IBond.Order.AROMATIC that would not be possible. Egon -- Dr E.L. Willighagen Post-doc @ Uppsala University (only until 2010-09-30) Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg Homepage: http://egonw.github.com/ Blog: http://chem-bla-ics.blogspot.com/ PubList: http://www.citeulike.org/user/egonw/tag/papers |
From: Jules K. <jul...@go...> - 2010-08-23 10:27:02
|
I'd say that the best data-model is as close to reality as possible (at least as far as quantum mechanics currently understands 'reality'). Quantum-mechanically speaking, the closest approach would be to have the ring with all bonds Ibond.Order.SINGLE (the sigma-bonds), and then add a single 'meta-bond' for the pi system with all the ringatoms and aromatic electrons in it. This meta-bond then gets the ISAROMATIC flag. So for benzene: 6 atoms, 7 bonds: 6 conventional single bonds + 1 'pi system meta-bond' containing all 6 ringatoms and 6 electrons. This is the closest I can think of actually representing electron de-localization in the current CDK model. An advantage is that this is by far the most flexible and generic solution, disadvantage is that it means reworking every single piece of CDK aromaticity code. Ouch.. Reality-wise, the next best compromise I think would be the Ibond.Order.SINGLE_OR_DOUBLE solution, which is a bondorder of 1.5, and could equally well be termed Ibond.Order.AROMATIC or Ibond.Order.ONE_PLUS_HALF. We may need an extra Ibond.Order.TWO_PLUS_HALF if we allow for triple-bonds in an aromatic system. I'm not sure this is practically possible unless you have rings of ridiculous size to overcome the angle strain. Of course this scheme breaks down when (d-orbital-using) metals become involved, such as Ferrocene <http://en.wikipedia.org/wiki/Ferrocene>, or when representing inorganic compounds/crystals (e.g. metal alloys). I believe this would potentially require a long list of THREE_PLUS_HALF, FOUR_PLUS_HALF etc. bondorders, but I'm not sure of that.. (The multi-atom-multi-electron 'pi-system-bond' scheme would easily accommodate this problem.) As for some IO-formats not supporting aromaticity but only Kekulé notation<http://en.wikipedia.org/wiki/Kekul%C3%A9_structure>: I think some crippled legacy disk-format (I.E. .MOL), even if it is still often used, shouldn't limit the CDK functionality nor its internal datamodel. In the worst case the affected writers will need an extra call to a 'convertAromaticToKekule()' method, paired with a 'convertKekuleToAromatic()' in the readers. This doesn't sound like a problem to me as the conversion is pretty straightforward. The 'problem' in the current flag-using data model is that it allows for corrupt data. You could build a seven-ring with only single-bonds, set the ISAROMATIC flag for all of them, and no-one would notice. Of course the current handling of infamous c1ccccc1 by JChemPaint is another nice example: it's aromatic, but you don't see it unless you manually count implicit hydrogens. summarising: I think a return of the 1.5 bond order would be the best practical solution for CDK v1.4, but would like to suggest a move to the pi-system metabonds for CDK v2.0. Kind regards, Jules On 11 August 2010 17:19, Egon Willighagen <ego...@gm...> wrote: > Nina, > > I think you might be right... > > On Wed, Aug 11, 2010 at 4:29 PM, Nina Jeliazkova > <jel...@gm...> wrote: >> Consider an user entering aromatic SMILES, readers will parse it into >> the new singe or double type of bond; even if all processing code >> works fine, it will still be impossible to write the structure back in >> a e.g. MOL file, unless bonds are assigned either single or double >> type. > > I was thinking of perhaps just using UNKNOWN instead... which we > currently have as 'null'... > >> Getting back the aromatic bond type might be an easier workaround. > > I remember I was quite happy to see the aromatic bond type gone... we > have flags for this, allowing us to actually have SINGLE *and* > ISAROMATIC... with an IBond.Order.AROMATIC that would not be possible. > > Egon > > > -- > Dr E.L. Willighagen > Post-doc @ Uppsala University (only until 2010-09-30) > Proteochemometrics / Bioclipse Group of Prof. Jarl Wikberg > Homepage: http://egonw.github.com/ > Blog: http://chem-bla-ics.blogspot.com/ > PubList: http://www.citeulike.org/user/egonw/tag/papers > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > |