You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(28) |
Nov
(13) |
Dec
(25) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(14) |
Feb
(30) |
Mar
(8) |
Apr
(24) |
May
(13) |
Jun
(8) |
Jul
(12) |
Aug
(46) |
Sep
(30) |
Oct
(40) |
Nov
(68) |
Dec
(15) |
2003 |
Jan
(20) |
Feb
(93) |
Mar
(56) |
Apr
(21) |
May
(28) |
Jun
(78) |
Jul
(58) |
Aug
(54) |
Sep
(213) |
Oct
(162) |
Nov
(81) |
Dec
(54) |
2004 |
Jan
(139) |
Feb
(227) |
Mar
(87) |
Apr
(150) |
May
(107) |
Jun
(70) |
Jul
(42) |
Aug
(87) |
Sep
(17) |
Oct
(34) |
Nov
(60) |
Dec
(93) |
2005 |
Jan
(45) |
Feb
(76) |
Mar
(67) |
Apr
(109) |
May
(90) |
Jun
(46) |
Jul
(39) |
Aug
(78) |
Sep
(67) |
Oct
(32) |
Nov
(81) |
Dec
(86) |
2006 |
Jan
(85) |
Feb
(76) |
Mar
(85) |
Apr
(84) |
May
(144) |
Jun
(78) |
Jul
(55) |
Aug
(55) |
Sep
(85) |
Oct
(71) |
Nov
(60) |
Dec
(30) |
2007 |
Jan
(27) |
Feb
(74) |
Mar
(48) |
Apr
(183) |
May
(33) |
Jun
(50) |
Jul
(83) |
Aug
(37) |
Sep
(110) |
Oct
(109) |
Nov
(78) |
Dec
(126) |
2008 |
Jan
(112) |
Feb
(81) |
Mar
(58) |
Apr
(38) |
May
(167) |
Jun
(115) |
Jul
(143) |
Aug
(164) |
Sep
(173) |
Oct
(143) |
Nov
(98) |
Dec
(134) |
2009 |
Jan
(185) |
Feb
(116) |
Mar
(125) |
Apr
(201) |
May
(59) |
Jun
(110) |
Jul
(56) |
Aug
(85) |
Sep
(109) |
Oct
(129) |
Nov
(315) |
Dec
(93) |
2010 |
Jan
(49) |
Feb
(93) |
Mar
(207) |
Apr
(123) |
May
(114) |
Jun
(63) |
Jul
(111) |
Aug
(160) |
Sep
(70) |
Oct
(254) |
Nov
(11) |
Dec
(91) |
2011 |
Jan
(34) |
Feb
(155) |
Mar
(92) |
Apr
(15) |
May
(82) |
Jun
(191) |
Jul
(102) |
Aug
(71) |
Sep
(113) |
Oct
(44) |
Nov
(66) |
Dec
(84) |
2012 |
Jan
(51) |
Feb
(95) |
Mar
(31) |
Apr
(100) |
May
(133) |
Jun
(73) |
Jul
(103) |
Aug
(90) |
Sep
(84) |
Oct
(217) |
Nov
(113) |
Dec
(30) |
2013 |
Jan
(9) |
Feb
(18) |
Mar
(10) |
Apr
(17) |
May
(26) |
Jun
(30) |
Jul
|
Aug
(10) |
Sep
(13) |
Oct
(65) |
Nov
(22) |
Dec
(30) |
2014 |
Jan
(55) |
Feb
(19) |
Mar
(31) |
Apr
(21) |
May
(15) |
Jun
(5) |
Jul
(16) |
Aug
(29) |
Sep
(37) |
Oct
(9) |
Nov
(7) |
Dec
(22) |
2015 |
Jan
(4) |
Feb
(22) |
Mar
(24) |
Apr
(18) |
May
(41) |
Jun
(13) |
Jul
(2) |
Aug
(7) |
Sep
(10) |
Oct
(43) |
Nov
(14) |
Dec
(18) |
2016 |
Jan
(7) |
Feb
(22) |
Mar
(12) |
Apr
(9) |
May
(10) |
Jun
(24) |
Jul
(10) |
Aug
(13) |
Sep
(1) |
Oct
(5) |
Nov
|
Dec
(3) |
2017 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(2) |
May
(8) |
Jun
(4) |
Jul
(9) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
(3) |
Feb
|
Mar
(10) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
(3) |
2019 |
Jan
(13) |
Feb
(3) |
Mar
|
Apr
(6) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(7) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
2022 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Christoph S. <ste...@ic...> - 2002-06-28 11:04:44
|
E.L. Willighagen wrote: > Hi all, > > I want to propose to make a new package called > > org.openscience.cdk.libio > > with conversion classes that convert cdk.ChemObjects > into classes used in other libraries, like JOELib and CMLDOM. > This package would have subpackages naming the library to > which it interfaces, ie: > > org.openscience.cdk.libio.joelib > org.openscience.cdk.libio.cmldom > > How does that sound? Of course that sounds reasonable. As always, we should instantiate this package as soon as we have the first class available that fits into this package. Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: E.L. W. <eg...@sc...> - 2002-06-28 09:41:30
|
Hi all, I want to propose to make a new package called org.openscience.cdk.libio with conversion classes that convert cdk.ChemObjects into classes used in other libraries, like JOELib and CMLDOM. This package would have subpackages naming the library to which it interfaces, ie: org.openscience.cdk.libio.joelib org.openscience.cdk.libio.cmldom How does that sound? Egon |
From: Christoph S. <ste...@ic...> - 2002-06-25 12:25:41
|
E.L. Willighagen wrote: > Hi all, > > some time ago someone (do not remember who) suggested to include classes to > calculate 3D predictors used in QSAR. At that time I already expressed > interest in those, and at this moment I am most interested in using them. > They have not been included yet, right? Could they be added? > I am interested in atomistic descriptors, the Randic index, the modifications > on it by Kier and Hall, and other often used 3D descriptors. Surely can they be added. Do you really mean 3D, i.e. based on 3D coordinates? I was thinking anyway that we could use a descriptor package for the most important indices. Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: E.L. W. <eg...@sc...> - 2002-06-25 11:29:56
|
Hi all, some time ago someone (do not remember who) suggested to include classes to calculate 3D predictors used in QSAR. At that time I already expressed interest in those, and at this moment I am most interested in using them. They have not been included yet, right? Could they be added? I am interested in atomistic descriptors, the Randic index, the modifications on it by Kier and Hall, and other often used 3D descriptors. thanx in advance, Egon |
From: Christoph S. <ste...@ic...> - 2002-06-24 12:12:31
|
Hi everybody, it has been annoying all of the active developers for quite a while and it has now finally been fixed: The src tree was moved to its own "src" subfolder. I recommend getting a fresh copy from CVS (backup and delete the old sources and do a fresh checkout) because at least in my case updating the old sandbox did not fully remove the old sources, while they did not appear when I do a fresh checkout. Also, the build.xml has been updated and cleaned up a little. I hope everything is still working on your side once you've got the new structure downloaded. Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <eg...@sc...> - 2002-06-17 19:13:27
|
On Monday 17 June 2002 18:51, Christoph Steinbeck wrote: > I would like to move the cdk sources to a src subdirectory. This is a > minor reorganization but there might be some problems with the CVS. I > have never before move a large portion of files around in a CVS > controlled environment. > > Does anyone have experiences, objections, etc.? Please do. The lack of a src/ dir has been annoying the hell out of me... I think the only with CVS is to remove the old files and add them in the right place... No easier way to do so, I'm afraid... Egon |
From: Christoph S. <ste...@ic...> - 2002-06-17 16:51:54
|
Hi everybody, I would like to move the cdk sources to a src subdirectory. This is a minor reorganization but there might be some problems with the CVS. I have never before move a large portion of files around in a CVS controlled environment. Does anyone have experiences, objections, etc.? Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Christoph S. <ste...@ic...> - 2002-06-11 14:54:54
|
Dear Co-Coders, I just became aware of a problem with the flags (and probably other fields) in ChemObjects. I frequently use these when for example keeping track of a path through the Molecule. If you are using serialization, no matter if JSX-based or with the native Java serialization, you will loose these fields when de-serializing the object, because they are declared transient and do thus not occur in the serialized file. And the thing is, they have just been declared transient not to appear in the XML serialization field (they really mess up the look of the config files :-)). Anyway, there might be a number of places in the code where I (and certainly others) have used the flags, just assuming they are there. In fact, if you use them, check if they are not "null" and if they are, initilize them correctly. Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Bradley A. S. <br...@ba...> - 2002-05-23 15:31:51
|
> > Class AtomImpl implements Atom. > > > > I hate nameing schemes like AtomImpl, but it might make things easier. > > I hate that too, and normally use a method just the other way around: > > interface AtomInterface > and > class Atom implements AtomInterface > Another naming scheme to consider would be interface Atom and class DefaultAtom implements Atom This sort of convention is used by the Swing classes in their model interfaces (for example ListSelectionModel, ComboBoxModel, etc.). Bradley |
From: Oliver H. <oli...@th...> - 2002-05-23 12:51:33
|
I have not yet implemented any of the changes that I have suggested. I thought that I would see what people thought first. Refactoring to add interfaces is simple with IntelliJ it creates the interface from the class and then analyses the project to replace references to the class with references to the interface where possible. For more info on how a factory methods are implemented check out the Factory Method design pattern. I would also opt for the naming convention FooInterface and Foo. It might be worth thinking about separating the interfaces from the implementations to reduce naming conflicts and to enable a interface only deploy. |
From: E.L. W. <eg...@sc...> - 2002-05-23 09:25:33
|
On Thursday 23 May 2002 09:23, Christoph Steinbeck wrote: > Firstly, let me thank you for this excellent initiative. > > Secondly, this is the first time I became aware of the AtomicNumbers > class. What was wrong with those that are inserted by the > ElementFactory? I think this AtomicNumbers class should go away. If it is duplicate, sure... I must have missed ElementFactory... could you add a key word "atomic numbers" to the appropriate procedure in ElementFactory? > The rest of the list seems to be ok. What if we implement Oliver's idea > about the interfaces. This would change quite a lot. Indeed, the list of core classes would have to be extended to include the interfaces... > Anyway, beside the AtomicNumbers class (which, if you think it further, > would logically bring AtomicWeight.class and classes for other atomic > constants with it) I think the list is ok. I've done a lot of > algorithmic work with the CDK now and the existing core classes were > always sufficient. How about the CDKConstants? I would say that would be not in the core classes.... I would like to devote the core classes just for data storage, not for actual information... But, that is arguable... Egon |
From: E.L. W. <eg...@sc...> - 2002-05-23 09:23:04
|
On Thursday 23 May 2002 09:01, Christoph Steinbeck wrote: > Egon Willighagen wrote: > > Christoph, is Seneca also based on CDK nowadays? > > Yes, it is. There is also work in progress, called "NMRShiftDB", which > is a database of organic structures together with their NMR spectra, > which is also based on the CDK. > > I thought that Olivers idea to have interfaces defined for the core > classes is a good one. I was not sure about how to make the nameing > scheme, but certainly it would be much easier to cast things to > interfaces. I also get in trouble sometimes with the > AtomContainer/Molecule pair. I'm trying to use the two classes in a > physical sense (if this exists). I use AtomContainer in any case where I > handle incomplete collections of Atom and Bonds, and the the Molecule > class only in cases where I have "real" molecules. However, this is all > rather spongy. > > I think, Egon's suggestion of a new branch is ok. However, we should get > over this as quick as possible, since it is even harder to properly > maintain to branches that it is with one. Yes, as soon as transition is done we move over. Moreover, I would say that the stable branch is only used to fix bugs... and other minor things only... Just in case the transition takes longer than expected... Also, changes in a branch can be automatically ported to HEAD... Thus, unstable would be HEAD and we would branch current CVS into CDK-1 as the first 'stable' release... > I also think that we should not just ask Oliver for a patch. This seems > a little more work than that. Essentially, switching to interfaces would > screw up pretty much everything in the first run and it will take > quite some time to fix it. Right. I was not sure wether he actually had done coding implementating the suggestions... If not, he should not do it just by himself, of course... > Of course, the interfaces have to be named like the the core classes are > named now. > > So we would have > > Interface Atom > > and we would have > > Class AtomImpl implements Atom. > > I hate nameing schemes like AtomImpl, but it might make things easier. I hate that too, and normally use a method just the other way around: interface AtomInterface and class Atom implements AtomInterface Egon |
From: Christoph S. <ste...@ic...> - 2002-05-23 07:23:30
|
Firstly, let me thank you for this excellent initiative. Secondly, this is the first time I became aware of the AtomicNumbers class. What was wrong with those that are inserted by the ElementFactory? I think this AtomicNumbers class should go away. The rest of the list seems to be ok. What if we implement Oliver's idea about the interfaces. This would change quite a lot. Anyway, beside the AtomicNumbers class (which, if you think it further, would logically bring AtomicWeight.class and classes for other atomic constants with it) I think the list is ok. I've done a lot of algorithmic work with the CDK now and the existing core classes were always sufficient. How about the CDKConstants? Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. Egon Willighagen wrote: > Request for Comments > ========================================================= > > PROPOSAL: > Proposed is a precise and definate list of classes that belong to the cdk-code > library. This class would contain the classes representing chemical entities > and required classes by those. All chemical information used in any of the > CDK classes must be able to be stored in one of these classes. Core classes > must not require non cdk-core classes other than provided by Java1.2. > > The list of classes in cdk-code is: > AtomContainer > AtomEnumeration > AtomicNumbers > Atom > AtomType > BioPolymer > Bond > ChemModel > ChemObject > ChemSequence > ElectronContainer > Element > Isotope > Molecule > Monomer > Polymer > Ring > RingSet > SetOfMolecules > > Data concerning visual representation does not need to be in one of these > classes. Also, factories and predefined values need not be in one of these > classes. > > Junit test classes testing and only needing these core classes would belong to > cdk-code-test and not to cdk-code itself. > > REASON: > A final list of core classes is needed to define a complete and accurate API > definition of the core CDK library. |
From: Christoph S. <ste...@ic...> - 2002-05-23 07:01:17
|
Egon Willighagen wrote: > Christoph, is Seneca also based on CDK nowadays? Yes, it is. There is also work in progress, called "NMRShiftDB", which is a database of organic structures together with their NMR spectra, which is also based on the CDK. I thought that Olivers idea to have interfaces defined for the core classes is a good one. I was not sure about how to make the nameing scheme, but certainly it would be much easier to cast things to interfaces. I also get in trouble sometimes with the AtomContainer/Molecule pair. I'm trying to use the two classes in a physical sense (if this exists). I use AtomContainer in any case where I handle incomplete collections of Atom and Bonds, and the the Molecule class only in cases where I have "real" molecules. However, this is all rather spongy. I think, Egon's suggestion of a new branch is ok. However, we should get over this as quick as possible, since it is even harder to properly maintain to branches that it is with one. I also think that we should not just ask Oliver for a patch. This seems a little more work than that. Essentially, switching to interfaces would screw up pretty much everything in the first run and it will take quite some time to fix it. Of course, the interfaces have to be named like the the core classes are named now. So we would have Interface Atom and we would have Class AtomImpl implements Atom. I hate nameing schemes like AtomImpl, but it might make things easier. Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <eg...@sc...> - 2002-05-22 20:58:04
|
Hi all, this email seems to be the first Request For Comments, which are used for setting up specification... A RFC gets comments/amendments/etc which will end in a proposal. People can vote on this proposal and a RFC can get approved. The number of people interesting and using CDK is growing which is a very good thing. But this also means that changing API's is more difficult, and we actually have two issues concerning the API which need to be resolved. These are: 1. now and then people run into the problem of unintialized fields 2. the current API for reading data from files is not flexible enough The current API was more or less developed in South Bend, USA about 1.5 years ago by Dan, Christoph and me. We never wrote a proper specification which lead to problem 1, and this never-written specification is likely to be changed for problem 2 (not in one step). Last two months I've put effort in improving the documentation, and a first step for this was creating statistics... a second was making documents describing the interface. Others have been working on generating UML diagrams, while I have focused on JavaDoc documentation... One of the problems then is the amount of classes we already have in the library... (Hence the use of the @keyword tag)... This also holds for the API. I would be good IMHO to divide the library in groups, which is partly done by the idea of packages. But this has never been formalized. Some time ago (see archives) I proposed a division. For each part we can have a separate API version system, jars, documentation etc... Anyway, in the next email I will propose a list of classes that will belong to the core CDK classes. API for these classes will freeze first afterwhich other classes can be made compatible, etc... This RFC will lead to an Request For Votes stating the final proposal. Both RFC and RFV are send to both cdk-devel and cdk-user as it affects both CDK developers but very much the users of the library too... Both will be able to vote too. Votes will be done within a certain time (two weeks?) span after the RFV by email were each person has one vote, and votes are preferably signed with a PGP/GnuPG key available from a free keyserver. Probably a new maillinglist should be set up. Only valid votes send by email are counted in determining the acceptance of a proposal. Ok, this proposal for an RFC/voting system. It is not supposed to delay development, but smooth the development and use of the library. Usage of branches in CVS can still be used to test new ideas/APIs in addition to the more formalized RFC/voting system. And new classes/algorithms etc are always welcomed (even encouraged) and not intended to be covered by this system. Egon |
From: Egon W. <eg...@sc...> - 2002-05-22 20:58:04
|
Request for Comments ========================================================= PROPOSAL: Proposed is a precise and definate list of classes that belong to the cdk-code library. This class would contain the classes representing chemical entities and required classes by those. All chemical information used in any of the CDK classes must be able to be stored in one of these classes. Core classes must not require non cdk-core classes other than provided by Java1.2. The list of classes in cdk-code is: AtomContainer AtomEnumeration AtomicNumbers Atom AtomType BioPolymer Bond ChemModel ChemObject ChemSequence ElectronContainer Element Isotope Molecule Monomer Polymer Ring RingSet SetOfMolecules Data concerning visual representation does not need to be in one of these classes. Also, factories and predefined values need not be in one of these classes. Junit test classes testing and only needing these core classes would belong to cdk-code-test and not to cdk-code itself. REASON: A final list of core classes is needed to define a complete and accurate API definition of the core CDK library. ========================================================= Egon |
From: Egon W. <eg...@sc...> - 2002-05-22 19:16:00
|
> I have given some more thought to your question about validating S and P > etc. So what I am doing now is I am looking at the number of electrons > that an atom shares in bonding with other atoms. I then compare this to > the absolute value of the oxidation states of the atom and if I find a > match the atom is valid. If the atom is invalid I check if I can make it > valid by adding H. It seems to work well, although I don't really know how > theoretically sound my method is. What it dose not do is check if the > molecule is sterically correct. For example SO4H2 is valid, so is SO6H6 > which is wrong. CDK may support different algorithms for certain tasks... As long as alternatives are clear, and limitations/assumptions/etc are documented... If at a later stage a better algorithm is available we could "deprecate" this method... > Also I have been thinking about the extensibility of the CDK and > unfortunately I am very restricted in what I can extend. I am not complete sure what is meant here... The Atom class is public and non-final and can thus be extended... > I can add > algorithms but I cannot extend the Atom class if I want to also use the > readers without changing them. Why is that? Because you want the reader to store information that is not in the Atom class but only in the SubclassedAtom class? Or because you want the info of an Atom class read from file to be of type SubclassedAtom? > And the same applies to Molecule, > AtomContainer or Bond. One way to make it possible to do that sort of > extensions is to define factory methods to create a new instance of Atom > and Bond in AtomContainer. That way I could override the factory methods > to create my Atom and Bond sub classes. Ok. Do I understand correctly if you mean that you want to be able to tell ChemFile what kind of atoms are produced when a ChemObjectReader parses a file? Something like: ChemFile.setAtomClassType(Atom dummy); > All the readers except for MDL > reader only support ChemFiles, so that would be a convenient place to put > the factory method for creating the AtomContainer sub class. > All this refactoring would allow you to change the signature of the > ChemObjectReader to public void read(ChemFile chemFile). The newly read > files would then be appended to the ChemFile, which would save a lot of > type casting of the returned ChemObject. > I know that changing the core classes is often painful but in this case > except for changing the method signature of the reader it should not impact > anyone to much if there are two more methods added to the AtomContainer and > ChemFile classes. And it would greatly improve the extensibility of the > cdk and also make it easyer to integrate the cdk into existing > programmes. Of course to help integration into existing systems it would > be great to have interfaces for all core classes so that existing > implementations of Atom etc. could just extend the interfaces. The CDK project is still far from reaching a state where the API of the core classes are properly defined... Heck, currently the "core classes" are not even defined properly... I find it a bit hard to get clear what your proposed patch looks like, but the ideas make reasonable sense to me... Concluding, I would like to see/welcome a patch... we could best make a branch in our CVS tree to incorporate your changing. Thus making an unstable test branch were we would apply the changes and see what all is breaking... We would then still have a stable branch if it turns out to be a disaster... About breaking stuff... I've tried to compile a list of projects that use CDK... At this moment this is limited to JCPCDK (does it actually recompile with CDK from cvs-HEAD?) and Jmol, which only uses the CML reading bit at this moment... Christoph, is Seneca also based on CDK nowadays? Egon |
From: Christoph S. <ste...@ic...> - 2002-05-21 15:04:17
|
Oliver had some interesting thoughs regarding the CDK. I would like to pass that over to the list for discussion. -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Christoph S. <ste...@ic...> - 2002-05-20 10:02:45
|
Egon Willighagen wrote: > On Sunday 05 May 2002 00:01, Egon Willighagen wrote: > >>I will add results to the website soon... > > > Results have been added to the website... I would like to point your > attention to this page: > > http://cdk.sourceforge.net/javadoc-stats.html > > In bold are given the percentages of the packages that have no > complete JavaDoc documentation. Note that it does not even check > correctness of the documentation. More on that later. > > Please have a look at the code you wrote and add JavaDoc documentation. > (This includes me! org.openscience.cdk.io.cml and > org.openscience.cdk.io.cml.cdopi only have 6.6% and 8.0% docs!) I win. None of my packages has less than 75% :-) But honestly, everything below 90% should be considered inexceptable in the long run. From my discussion with people on recent conferences I'm getting the feeling that the CDK might have a pretty bright future. Considering that fact that the article will be sent out for publication in one or two month, we should get everything in good shape until then. BTW, this brings up again issue of meeting in person for a week or so. This could be used to finish the article and to make all the missing corrections, bug fixes, etc. All of you who are interested in comming to Jena (or any other good place): Could you send me possible time slots during the next two or three month? For me, the second week in July would be great (08.07-15.07.) would be great. Any week in July after that, in fact. Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <eg...@sc...> - 2002-05-19 19:28:37
|
On Sunday 05 May 2002 00:01, Egon Willighagen wrote: > I will add results to the website soon... Results have been added to the website... I would like to point your attention to this page: http://cdk.sourceforge.net/javadoc-stats.html In bold are given the percentages of the packages that have no complete JavaDoc documentation. Note that it does not even check correctness of the documentation. More on that later. Please have a look at the code you wrote and add JavaDoc documentation. (This includes me! org.openscience.cdk.io.cml and org.openscience.cdk.io.cml.cdopi only have 6.6% and 8.0% docs!) Egon |
From: Egon W. <eg...@sc...> - 2002-05-04 22:00:13
|
Hi all, I found a nice tool that can generate statistics on the use of JavaDoc in our software (along with Non-Commenting Source Statements, and some complexity value)... I will add results to the website soon... The software is GPL and can be found here: http://www.kclee.com/clemens/java/javancss Egon |
From: Christoph S. <ste...@ic...> - 2002-04-29 19:56:04
|
Hi everybody, motivated by Oliver's contribution I finally found the time to port the old compchem smiles parser. It does the SSMILES specification and the % tag for more than 10 open rings at a time. There is some yet incomplete code for specifying atoms in [] brackets, but this has still to be completed. A test is available Have fun. Cheers, Chris -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Christoph S. <ste...@ic...> - 2002-04-26 08:28:06
|
Dear Shyamal, thanks for your kind email. And thanks for pointing me to these articles. I currently have a student working on the implementation of an algorithm which both does isomorphims and subgraph isomorphism checking. I hope that this part will be available soon. With respect to your wishes regarding the structure diagram layout, I can only say that the design of the StructureDiagramGenerator class is such that it should be able to handle a wide range of subgraph cleaning. Probably not all, but a lot of them. Some code would have to be written to handle specially marked sections of the molecule, do the layout and move and rotate the rest of the molecular fragments into the right position. And yes, the combinatorial section would be great, too. I once wrote a nice little program in Visual Basic, which does this kind of job [1], but having a such an engine (with a little more sophistication than in MASP) in the CDK would certainly open a whole new field of application for it. However, currently none of our coworkers seems to be working on this. What we would need to do is implement something like a macro atom concept. This would be very deserving also for the field of structure generators. Cheers, Chris 1. Steinbeck C, Berlin K, Richert C: Masp - a Program Predicting Mass Spectra of Combinatorial Libraries. Journal of Chemical Information & Computer Sciences 1997, 37:449-457. L. Shyamal wrote: > Greetings Dr. Steinbeck, > > I have been looking at your excellent work on the CDK, JChemPaint etc. > I notice that whereas isomorphism is implemented substructure search is not > (i may be mistaken though). I recently came across this algorithm, although > in C, whose performance, i am impressed with. > http://amalfi.dis.unina.it/graph/db/vflib-2.0/doc/vflib-30.html > > I have in fact used the same in chemical substructure matching. > Unfortunately we dont have an open source policy at our company. > > I hope this is of interest to you. > > I have recently spent some time on Helson's Structure Diagram Generator > paper and I hope some of his wishes can be added in that area. I am > especially interested in partial cleanup of molecules and retention of > stereochemistry during cleanup. > > Also i hope you might be interested in writing some kind of combinatorial > engine that mixes cores and substituents according to some kind of rules. I > especially think it would be great to work on a standard language for > defining cores, substitution rules etc, which could be read by a parser and > acted upon accordingly with external filters that could act in screening for > specific properties. > > Hope to see more features, > Best wishes > > - Shyamal > > L. Shyamal, Lead Analyst > Jubilant Biosys (P) Ltd > 4th Floor, S.J.M. Towers > #18 Seshadri Road > Gandhinagar > Bangalore 560009 > INDIA > phone 91-80-2207302 to 2207309 x 1046 > www.jubilantbiosys.com > > > -- Dr. Christoph Steinbeck (http://www.ice.mpg.de/departments/ChemInf) MPI of Chemical Ecology, Winzerlaer Str. 10, Beutenberg Campus, 07745 Jena, Germany Tel: +49(0)3641 571263 - Fax: +49(0)3641 571202 What is man but that lofty spirit - that sense of enterprise. ... Kirk, "I, Mudd," stardate 4513.3.. |
From: Egon W. <eg...@sc...> - 2002-04-24 04:36:19
|
On Tuesday 23 April 2002 15:21, Stefan Kuhn wrote: > Hi Egon, > according to my humble opinion this is not a feature, because > ChemObject.java says: > public transient boolean[] flags = new boolean[100]; > This is intended, I think, for initializing the variable. Ah. Then in this case it seems a feature... > If it's left to > the other classes, you would not need that line, would you? Anyway for me > it seems not a good concept to leave initializing to the code using the > classes. Stefan There is one reason to do so: If field are null, this information is not available... If the would have some initialized value, you would not know wether that value is actually set or that it is the initialized value. I think the latter is used in CDK too, at least it was in CDKs history... If this has not changed, then CDK is inconsistent in this respect (bad thing). Egon |
From: Stefan K. <sk...@ic...> - 2002-04-23 13:19:25
|
Hi Egon, according to my humble opinion this is not a feature, because ChemObject.java says: public transient boolean[] flags = new boolean[100]; This is intended, I think, for initializing the variable. If it's left to the other classes, you would not need that line, would you? Anyway for me it seems not a good concept to leave initializing to the code using the classes. Stefan |