Menu
▾
▴
joelib-devel — JOELib-Development
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
(10) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(1) |
Jul
(1) |
Aug
(13) |
Sep
(1) |
Oct
|
Nov
(4) |
Dec
|
| 2004 |
Jan
(5) |
Feb
(9) |
Mar
(13) |
Apr
(25) |
May
(10) |
Jun
(21) |
Jul
(13) |
Aug
(8) |
Sep
(6) |
Oct
(1) |
Nov
(5) |
Dec
(16) |
| 2005 |
Jan
(9) |
Feb
(15) |
Mar
(8) |
Apr
(8) |
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joerg K. W. <we...@in...> - 2004-11-12 15:09:09
|
Hi Ambrish, 1. LOG4J requires its property file in the classpath. If you use the source code distribution (strongly recommended) this will be copied automatically to joelib/build/log4j.properties 2. Seems that there are the required libraries missing which are located under joelib/lib/log4j.jar Please check carefully if the properties and the libraries are part of your classpath. You can resolve such things dynamically via ANT or the included shell scripts. For Windows and your own potential application you must check such things 'by hand'. Kind regards, Joerg > hi > thanx for the prompt reply..... > i am having problem s like > 1.package org.apache.log4j does not exist import org.apache.log4j.Category; > 2. private static Category logger = Category.getInstance( > > I tried to configure log4j but still the problem persists. i also searched for the solution but got some hits like This class has been deprecated and replaced by the Logger subclass > should i replace that in my program. > > > > > > "Joerg K. Wegner" <we...@in...> wrote: > Hi Ambrish, > > >>i am a new user to JOELib but am not able to make out how to get started with the package.... >>Can somebody write to me in detail how to start and if i want to write a program using this package where will i have to store the program i.e whether in same directory? > > I recommend to start with all examples in joelib/src/joelib/test > Have a look at them and try to understand them, then you will know the > basic functionalities. > > >>Also i am getting problem with setting with JOELib enviornment. > > That's to sloppy fomulated. > What are your problems: Java, ANT, eclipse, properties files, > protonation model, atom typer, ... > > Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-11-12 06:03:37
|
Hi Ambrish, > i am a new user to JOELib but am not able to make out how to get started with the package.... > Can somebody write to me in detail how to start and if i want to write a program using this package where will i have to store the program i.e whether in same directory? I recommend to start with all examples in joelib/src/joelib/test Have a look at them and try to understand them, then you will know the basic functionalities. > Also i am getting problem with setting with JOELib enviornment. That's to sloppy fomulated. What are your problems: Java, ANT, eclipse, properties files, protonation model, atom typer, ... Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Ambrish R. <che...@ya...> - 2004-11-11 18:46:41
|
hi i am a new user to JOELib but am not able to make out how to get started with the package.... Can somebody write to me in detail how to start and if i want to write a program using this package where will i have to store the program i.e whether in same directory? Also i am getting problem with setting with JOELib enviornment. Ambrish --------------------------------- Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com |
|
From: Joerg K. W. <we...@in...> - 2004-10-29 15:12:50
|
Hi all, i've started a 'joelib2-redesign'-branch in CVS. This has the following consequences: 1. The standard JOELib-version will only be bugfixed, there will be no new releases on this version. 2. All new features, changes and releases will be in the future named JOELib2. This will switch this project back to an alpha-version, because the class structure will be changed fullfilling several design criterias. ALL interface wishes and conventions are welcome and will be discussed on the developer mailing list. All suggestions must take the actual structure into account, because this will be an refactoring driven redesign and not a 'we-invent-the-wheel-twice' approach. If there are no further suggestions, i will follow the points: - Better interface and implementation separation - All developers must follow the PMD-rules - Redesign for easier and faster descriptor access The first changes were checked in to CVS. Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-09-23 05:19:16
|
Hi, i've added a short 'How-To' to the SF documentation system: http://sourceforge.net/docman/display_doc.php?docid=24799&group_id=39708 Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-09-06 05:53:17
|
Dear NAJI, 1. radicals R are not supported directly. 2. You can not simply add a new element entry in the element table joelib/data/plain/element.txt, because this type must be anywhere assigned and this is not the case at all. Typically this is done by the SMARTS atom types (PATTY algorithm) in joelib/data/plain/atomtype.txt So, radicals are much more difficult, because electron counts are at the moment not supported by SMARTS matching and therefore also not for the PATTY algorithm. See also: joelib/smarts/JOESmartsPattern.java joelib/smarts/ParseSmart.java joelib/smarts/Patty.java 3. Smiles does not recognize 'R'. So there exists still a request for this feature, but there they requested the R-groups analogue to the entries in SDF files. So, what is the standard here ? http://sourceforge.net/tracker/index.php?func=detail&aid=970983&group_id=39708&atid=425970 I've increased the priority to 6. Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-09-03 06:28:48
|
Hi all, Be courageous and help improving, if you have half-an-hour per week. New release: http://sourceforge.net/project/showfiles.php?group_id=39708&package_id=108845&release_id=265282 The bug in PMD for assigning 'unusedcode' warnings for arrays and matrices was fixed: https://sourceforge.net/tracker/?func=detail&atid=479921&aid=1020199&group_id=56262 I've also introduced the metrics for a CVS version. http://www-ra.informatik.uni-tuebingen.de/software/joelib/statistics.html As you can see we have a lot to do, so please be courageous and help improving. Here are my comments to the single metrics. The technical descriptions are directly linked in the first row in the table. basic good to handle braces nothing to do, we use jalopy source code formatter codesize serious for users and new developers also hard to fix, because you need to be an JOELib expert controversial good to handle, some rule are controversial in my opinion coupling good to handle finalizers good to handle imports good to handle naming good to handle with a good refactoring toolkit most IDEs support, and a crazy amount of work strictexception good to handle strings serious for users and new developers also hard to fix, strongly connected with code complexity unused complex tasks and feature requests shows also some open construction and porting tasks, e.g. residue PDB import, rotamer generation, ... Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-09-01 20:50:33
|
Dear John Beaver, > I've gotten JoeLib to convert an SDF file to a Smiles file using the > Convert program, but what is the best way to modify the default Smiles > output? Specifically, there are extra data elements in the SDF file of > the form... > > > <element1Name> > element1Value > > ...beyond that needed to generate the Smiles, that I'd like to output > unmodified as additional columns in the Smiles file: > > smileString | element1Value | element2Value | ... > > Does JoeLib store these somewhere? Would I need to edit the source, or > is there a standard way of changing output columns, such as editing the > joelib.properies file? Yes ! If you got the instance for the Smiles writer this will initialize the output format. The property, which is loaded by default is joelib.io.types.Smiles.lineStructure=SMILES|TITLE in the joelib.properties file So one possibility is to change your required output there directly. I've also implemented a command line option for convertSkip.sh (joelib.test.ConvertSkip class) which is [+s<lineStructure>] - Can be used for an alternate SMILES entry line structure Here you have to quote your definition correcctly. Finally, you can write your own class using one of the examples given in joelib/test to modify things to your requirements. E.g. using a descriptor file or whatever ... Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: John B. <jb...@uc...> - 2004-09-01 20:42:25
|
Hi,
I've gotten JoeLib to convert an SDF file to a Smiles file using the
Convert program, but what is the best way to modify the default Smiles
output? Specifically, there are extra data elements in the SDF file of
the form...
> <element1Name>
element1Value
...beyond that needed to generate the Smiles, that I'd like to output
unmodified as additional columns in the Smiles file:
smileString | element1Value | element2Value | ...
Does JoeLib store these somewhere? Would I need to edit the source, or
is there a standard way of changing output columns, such as editing the
joelib.properies file?
|
|
From: NAJI H. <naj...@ul...> - 2004-09-01 12:20:07
|
Hi, I used in Joelib your program joelib/src/desc/types/LogP in order to calculate a chemical property from groups contributions that uses Smiles and Smarts. But I have a trouble when there is a Smiles string with an alkyl radical : R , this pattern R is unknown. In first, I have add this element R in the joelib/data/plain/element.txt but there are some errors. Could you tell me how I could do? Thanks Naji |
|
From: Joerg K. W. <we...@in...> - 2004-08-30 13:29:56
|
Dear users,
default users of the main functionality should not be affected by these
changes.
------------
Dear developers,
I've started with refactoring the sources following the PMD rules.
First, this is important to hide the internal JOELib development
process, e.g. using a more efficient implementation.
Second, these changes are at the moment only available in the CVS and if
you are a developer this may affect your implementation. So, the next
JOELib release will switch back into beta-release mode with focus on a
more stable release for the future.
Beta-release mode for the next release means that i've decided to change
method calls and signatures if necessary. So developers ... be warned.
Example: Load descriptors of unkown size. Load them into a data
structure, e.g. Vector, which causes a lot of memory swapping processes.
So, a LinkedList would be more efficient here.
So, the PMD coupling rule recommend to use always a List interface for
the user, so the user have not to know which implementation is used
internally.
This was not the case, because i've often used a Vector in method headers.
Until now i've corrected the 'basic','coupling' and 'import' rules. Two
of them causes no problems.
But the 'coupling' rule has forced me to change 'Vector-->List',
'HashMap-->Map'. So, this affects method calls and forces you to
change these things also, if you are using the JOELib library for
your own implementations.
This causes three main changes for you:
0. joelibMethod(myVector);
Nothing to do here, because List is an interface for the Vector
class
1. Vector myVector=joelibMethod();
Must be changed to:
List myList=joelibMethod();
or you should use casting from Vector to List and vice versa.
Depends on your implementation.
2. Vector myVector=joelibMethod();
Enumeration enum=myVector.enumeration();
enum.hasNextElement();
enum.nextElement();
Must be changed to:
Iteration iter=myVector.iterator();
iter.hasNext();
iter.next();
3. All users which have used the 'addElement', 'getElementAt'
should use the access method, which are recommended from the
interface:
'add' and 'get'
And 'setElementAt(object, index)' should be replaced by
'setElementAt(index, object)' interchanging the order of the
arguments.
Kind regards, Joerg
--
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW: http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
(E. Hemingway)
Never mistake action for meaningful action.
(Hugo Kubinyi,2004)
|
|
From: Joerg K. W. <we...@in...> - 2004-08-27 11:39:03
|
Hi all, the new release is available. See ChengeLog.txt for details: https://sourceforge.net/project/shownotes.php?group_id=39708&release_id=263745 Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
Hi all, thanks guys. That's not a big effort. This will be checked in and part of the monthly new release. Kind regards, Joerg > xpost to joelib-devel mailing list > > E.L. Willighagen wrote: > >>On Thursday 19 August 2004 09:06, E.L. Willighagen wrote: >> >>>On Wednesday 18 August 2004 19:39, Daniel Leidert wrote: >>> >>>>* The follwing methods must be changed: >>>> * * >>>> * * getX2D() --> getX2d() >>>> * * getY2D() --> getY2d() >>>> * * >>>> * * That's all. >>> >>>That's a bug... we still need to set up som build deamons, that build with >>>certain JVM's and configurations (with/-out Java3d, JOELib)... >> >>Huh? I thought I understood what was happening here... but... >> >>Daniel, where do those changes need to be made? > > > In <joelib-source-20040729>/src/joelib/util/cdk/CDKTools.java (line > 83+84). This seems to be a bug in JOElib, not in the CDK-source (IMHO). > Yesterday, there was no time, to post the problem to the > JOElib-developers mailing list. > > The compiler stops with an error, when you try to compile joelib.jar > with the cdk-*.jars (target: compile.cdk.parts, see joebuild.xml - the > second joelib-build-run in Makefile). He complains about the methods > getX2D() and getY2D(). So I think, the above changes have to be made, to > build joelib.jar with compiled-in cdk-parts (it is working then, but it > seems not to be necessary to compile joelib.jar with cdk-*.jar for > building cdk-libio.jar -> maybe, this can be an own package: > libcdk-java-joelib, which will contain joelib.jar with compiled-in > cdk-parts). > > BTW: I wanted to ask you, if we can remove several directories from > cvs/cdk/packages/debian/? In the next days/weeks, I will try to make a > cdk-package for the Shell-wrappers (and maybe one doc-package if > possible). So it should be possible, to delete libcdk/ and libcdkextra/ > and maybe cdk/ and cdk-doc/. > > Regards, Daniel -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 19 August 2004 13:21, E.L. Willighagen wrote:
> On Thursday 19 August 2004 11:47, Daniel Leidert wrote:
> > E.L. Willighagen wrote:
> > > On Thursday 19 August 2004 09:06, E.L. Willighagen wrote:
> > > > On Wednesday 18 August 2004 19:39, Daniel Leidert wrote:
> > > > > * The follwing methods must be changed:
> > > > > * *
> > > > > * * getX2D() --> getX2d()
> > > > > * * getY2D() --> getY2d()
> > > > > * *
> > > > > * * That's all.
> > > >
> > > > That's a bug... we still need to set up som build deamons, that bui=
ld
> > > > with certain JVM's and configurations (with/-out Java3d, JOELib)...
> > >
> > > Daniel, where do those changes need to be made?
> >
> > In <joelib-source-20040729>/src/joelib/util/cdk/CDKTools.java (line
> > 83+84). This seems to be a bug in JOElib,=20
CDK changed the D to d recently... not really a bug, more of a version=20
incompatibility :)
> > not in the CDK-source (IMHO).=20
> > Yesterday, there was no time, to post the problem to the
> > JOElib-developers mailing list.
>
> Ah, ic...
Joerg, the patch is:
=2D --- src/joelib/util/cdk/CDKTools.java 2004-08-19 13:22:57.623944000 +=
0200
+++ src/joelib/util/cdk/CDKTools.java.fixed 2004-08-19 13:26:18.5988090=
00=20
+0200
@@ -80,8 +80,8 @@
for (int i =3D 0; i < cdkAtoms.length; i++)
{
=2D - mol.getAtom(i + 1).setVector(cdkAtoms[i].getX2D(),
=2D - cdkAtoms[i].getY2D(), 0.0);
+ mol.getAtom(i + 1).setVector(cdkAtoms[i].getX2d(),
+ cdkAtoms[i].getY2d(), 0.0);
}
// remove all 3D coordinates in all atoms
Egon
=2D --=20
eg...@us...
=2D ---------------------------------------
CDK: http://cdk.sf.net/
JChemPaint: http://jchempaint.sf.net/
Jmol: http://www.jmol.org/
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (SunOS)
iD8DBQFBJI8Xd9R8I9Yza6YRAj9zAJ975tCjFbnt8zArYxrKi4XHReMyigCdFFFC
qehKS9BPOcMUSml9pkbM/yI=3D
=3D7Jd+
=2D----END PGP SIGNATURE-----
|
|
From: E.L. W. <eg...@us...> - 2004-08-19 11:21:26
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 19 August 2004 11:47, Daniel Leidert wrote: > E.L. Willighagen wrote: > > On Thursday 19 August 2004 09:06, E.L. Willighagen wrote: > > > On Wednesday 18 August 2004 19:39, Daniel Leidert wrote: > > > > * The follwing methods must be changed: > > > > * * > > > > * * getX2D() --> getX2d() > > > > * * getY2D() --> getY2d() > > > > * * > > > > * * That's all. > > > > > > That's a bug... we still need to set up som build deamons, that build > > > with certain JVM's and configurations (with/-out Java3d, JOELib)... > > > > Huh? I thought I understood what was happening here... but... > > > > Daniel, where do those changes need to be made? > > In <joelib-source-20040729>/src/joelib/util/cdk/CDKTools.java (line > 83+84). This seems to be a bug in JOElib, not in the CDK-source (IMHO). > Yesterday, there was no time, to post the problem to the > JOElib-developers mailing list. Ah, ic...=20 > The compiler stops with an error, when you try to compile joelib.jar > with the cdk-*.jars (target: compile.cdk.parts, see joebuild.xml - the > second joelib-build-run in Makefile). He complains about the methods > getX2D() and getY2D(). So I think, the above changes have to be made, to > build joelib.jar with compiled-in cdk-parts (it is working then, but it > seems not to be necessary to compile joelib.jar with cdk-*.jar for > building cdk-libio.jar -> maybe, this can be an own package: > libcdk-java-joelib which will contain joelib.jar with compiled-in=20 > cdk-parts). Or a libjoelib-java package for joelib, and a libcdklibio-java for the=20 cdk-libio.jar? JOELib compiles also with Ant, so it should be fairly easy to start with th= e=20 debian files for CDK or JChemPaint... > BTW: I wanted to ask you, if we can remove several directories from > cvs/cdk/packages/debian/? In the next days/weeks, I will try to make a > cdk-package for the Shell-wrappers (and maybe one doc-package if > possible).=20 Cool. Then I can learn how to do that... As said, I've tried that for CDK, = but=20 did not have enough deb building experience... > So it should be possible, to delete libcdk/ and libcdkextra/=20 > and maybe cdk/ and cdk-doc/. Yes, go ahead. Was thinking about that too, but busy with non-CDK stuff dur= ing=20 the day (well, except for email :) Egon =2D --=20 eg...@us... =2D --------------------------------------- CDK: http://cdk.sf.net/ JChemPaint: http://jchempaint.sf.net/ Jmol: http://www.jmol.org/ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (SunOS) iD8DBQFBJI0kd9R8I9Yza6YRAozyAKCQnMawLYeHPZ56b2uWdNJsjRh35wCgsY/a lqn8cpSaGukt0VBb2azhpr8=3D =3DYbgh =2D----END PGP SIGNATURE----- |
|
From: Daniel L. <dan...@gm...> - 2004-08-19 09:46:19
|
xpost to joelib-devel mailing list E.L. Willighagen wrote: > On Thursday 19 August 2004 09:06, E.L. Willighagen wrote: > > On Wednesday 18 August 2004 19:39, Daniel Leidert wrote: > > > * The follwing methods must be changed: > > > * * > > > * * getX2D() --> getX2d() > > > * * getY2D() --> getY2d() > > > * * > > > * * That's all. > > > > That's a bug... we still need to set up som build deamons, that build with > > certain JVM's and configurations (with/-out Java3d, JOELib)... > > Huh? I thought I understood what was happening here... but... > > Daniel, where do those changes need to be made? In <joelib-source-20040729>/src/joelib/util/cdk/CDKTools.java (line 83+84). This seems to be a bug in JOElib, not in the CDK-source (IMHO). Yesterday, there was no time, to post the problem to the JOElib-developers mailing list. The compiler stops with an error, when you try to compile joelib.jar with the cdk-*.jars (target: compile.cdk.parts, see joebuild.xml - the second joelib-build-run in Makefile). He complains about the methods getX2D() and getY2D(). So I think, the above changes have to be made, to build joelib.jar with compiled-in cdk-parts (it is working then, but it seems not to be necessary to compile joelib.jar with cdk-*.jar for building cdk-libio.jar -> maybe, this can be an own package: libcdk-java-joelib, which will contain joelib.jar with compiled-in cdk-parts). BTW: I wanted to ask you, if we can remove several directories from cvs/cdk/packages/debian/? In the next days/weeks, I will try to make a cdk-package for the Shell-wrappers (and maybe one doc-package if possible). So it should be possible, to delete libcdk/ and libcdkextra/ and maybe cdk/ and cdk-doc/. Regards, Daniel -- |
|
From: Joerg K. W. <we...@in...> - 2004-08-17 17:34:40
|
Hi all, as proposed by Rich here are again the Signature references with DOI for=20 interested readers and developers. The DOI can be directly looked up at: http://dx.doi.org/ J.-L. Faulon, D. P. Visco und R. S. Pophale. `The Signature Molecular=20 Descriptor. 1. Using Extended Valence Sequences in QSAR and QSPR=20 Studies'. J. Chem. Inf. Comput. Sci. 2003. 43, 707-720.=20 doi:10.1021/ci020345w. J.-L. Faulon, C. J. Churchwell und D. P. Visco. `The Signature Molecular=20 Descriptor. 2. Enumerating Molecules from Their Extended Valence=20 Sequences'. J. Chem. Inf. Comput. Sci. 2003. 43, 721-734.=20 doi:10.1021/ci020346o. C. J. Churchwell, M. D. Rintoul, S. Martin, D. P. Visco, A. Kotu, R. S.=20 Larson, L. O. Sillerud, D. C. Brown und J.-L. Faulon. `The signature=20 molecular descriptor 3. Inverse-quantitative structure-activity=20 relationship of ICAM-1 inhibitory peptides'. Journal of Molecular=20 Graphics and Modelling 2004. 22, 263-=96273. doi:10.1016/j.jmgm.2003.10.0= 02. J.-L. Faulon, M. J. Collins und R. D. Carr. `The Signature Molecular=20 Descriptor. 4. Canonizing Molecules Using Extended Valence Sequences'.=20 J. Chem. Inf. Comput. Sci. 2004. 44, 427-436. doi:10.1021/ci0341823. Kind regards, Joerg --=20 Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-08-17 07:50:59
|
Hi all, the program for the eCheminfo conference is now Online: http://conferences.metalayer.net/echeminfo/ JOELib is part of the 'Open Source'-session: http://conferences.metalayer.net/echeminfo/design/conference/html/speakerinfoechem.htm Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-07-29 10:49:24
|
Hi Dave, first ... i'm going today into holiday until the end of next week. Yes, this was a bug in the detection and: UP is '/' DOWN is '\\' CIS is C/C=C\C TRANS is C/C=C/C I've created a (non-planned) bug fix release. The previous changes caused also SMILES export and i hope this is now correct. Please let me know if not not and send a bug report via the bug tracking list. I've additionally added unspecific up/down bond matching using '\\?' and '/?'. Please note that you need C/?C=C/?C if you plan to match plain butene, also. Download: https://sourceforge.net/projects/joelib/ Kind regards, Joerg > First, thanks for the new release. > > I've been experimenting with TestSmarts.java, using trans_butene.mol and > cis_butene.mol in .../build/resources/smartsEvaluation/. It seems to be > doing the exact opposite of what I'd expect: > > trans_butene.mol(C\C=C\C) > debugging output says "C\C=C/C trans-butene" > TestSmarts trans_butene.mol C\\C=C/C matches > trans_butene.mol C/C=C\\C matches > trans_butene.mol C\\C=C\\C doesn't match > trans_butene.mol C/C=C/C doesn't match > cis_butene.mol(C\C=C/C) > debugging output says "C\C=C\C cis-butene" > TestSmarts cis_butene.mol C\\C=C/C doesn't match > cis_butene.mol C/C=C\\C doesn't match > cis_butene.mol C\\C=C\\C matches > cis_butene.mol C/C=C/C doesn't match * > > * There's a note about this in evaluation.txt > > Notice the debugging output from the println on line 146 of TestSmarts.java. > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-07-27 15:51:30
|
Hi Rich,
I've changed the subject to being more precisely.
I agree that things are getting complex, but primitive native
numeric/nominal descriptors are only a really small subset of all
possible codings for molecular structures (descriptor results).
descriptor (parameters, molecule): algorithm to get values
descriptor result: storing object for the abstract molecule
numeric,nominal value, binary nominal value,
atom-pair, mcs, ...
query (parameters): a search method getting a list of valid matchings
e.g. SMARTS, AP, shape, whatever, ...
metric (parameters, descRes1, descRes2): Getting similarity for two
possibly codings
> But one thing that is not clear to me is how a generic Metric (or Comparator) does its job (without violating encapsulation) of comparing two Descriptor calculations given that the way in which each Descriptor represents itself is unique. For example, a Tanamoto comparison of two fingerprints will be done one way, but a Tanamoto comparison of two TPSA's will be done very differently. A Euclidian distance comparison of Topological Torsion is straightforward, but the same comparison of clogP - that's done very differently, I imagine.
Generic would not be the correct term.
The basic problem we always have is that 'similarity' can and definitely
should not be separated from the metric, because a metric can only
interpret the features given.
I've tried to find a structure for my private literature and i've now
the opinion that coding and similarity are two sides of a coin.
So, we can have different images on one of the two sides, but we can not
split the coin.
So, eventually every descriptorResult should have something like:
List=descriptorResult.getPossibleMetrics();
And i've also the opinion that we should be really general here, because
most model building algorithms (classification, regression, clustering)
need most often only a kind of similarity and a meanValue for a set of
molecules.
And the primitive euclidian distance of descriptor (sub)sets is only the
plain data mining approach with loosing all topologial information
(inverse QSAR problem).
> And then there's the problem that a generic Metric will need a much wider Descriptor interface to do a comparison than a generic DescriptorResult or Descriptor will have.
Hmm, i think the result holds the: coding
and the metric addresses: similarity on coding
> How does JOELib handle these issues?
Not good and really diverse.
For general descriptor results i've recently introduced:
joelib.math.similarity.DistanceMetric
For basic values (numeric or nominal or binary nominal), furthermore
there are some hot topics working directly on molecular structures. I
will not discuss these things on the public mailing list, but i'm
definitely willingly to cooperate here, if the plan is to write a paper
using one of the new methods. For all methods we have the atom labelling
(set) problem !
EUCLIDIAN, TANIMOTO:
joelib.util.ComparisonHelper
the euclidian or tanimoto metric is chosen from the kind of descriptor
given to
setComparisonDescriptor(String)
setComparisonDescriptor(String[])
ATOM-PAIR (also unpublished work of Nikolas Fechner available, still in
development)
joelib.desc.types.atompair.BasicAPDistanceMetric
MCS(not public, still in development, paper submitted, eventually i will
publish after the paper was accepted, but i'm not sure if i'm willingly
to share the implementation advantages so early)
Really weird, but i will prefer the abstractest object oriented way you
can provide.
In fact two results (coding) and metric based on these results.
But there are tons of ways you can code (parameters for MCS generation)
the MCS and you can apply the metric (parameters for metric)
> It almost seems like the "Descriptor" category itself is overly general and needs to be broken down further. Otherwise any Descriptor framework will have to know too much about particular Descriptor implementations with the result being a decidedly non-object-oriented framework that is difficult to extend and maintain. How can we address this?
In JOElib every descriptor knows it's result, so if you call
result=descriptor.calculate(molecule)
you will get the correct result. Because this is done by using
Java-Reflection this is not the most efficient way, but if we use
result=descriptor.calculate(molecule, result) this will be efficient.
Hence, standard users will have to pay a runtime-penalty, because object
generation in Java is expensive (see also joelib.desc.ResultFactory).
I suggest that every result should know possible metrics.
I've also introduced a joelib.desc.DescriptorInfo object
Additionally there exists the DescDescription object which holds
informations for each descriptor. If you will try:
joelib/ant> ant JOELibTestGUI
And you will switch to Info-->Descriptors Panel all informations are
generated and loaded on the fly by using:
111. DescriptorFactory (get all descriptors JOELib can calculate, so we
know the details for them, BTW unavailable documentation will cause
annoying warnings, so developers are forced to provide from the
beginning documentation files)
222. Get descriptor infos for each descriptor
333. Load single HTML documentation (generated also from DocBook-XML)
for each descriptor
444. show informations.
Kind regards, Joerg
>
> rich
>
> "Joerg K. Wegner" <we...@in...> wrote:
> Hi again,
>
> we should for performace issues not use (as in JOElib):
> molecule.calculate("XYZ")
>
> we should use:
> keyXYZ=KeyFactory.getKey("XYZ");
>
> // and use internal caching for this descriptor
> molecule.calculate(keyXYZ);
>
> Kind regards, Joerg
>
>
>>Hi Rich,
>>
>>
>>>* Molecule implements AtomGraph. In the near future, BondingSystem
>>>should also implement AtomGraph to enable traversal/query with the
>>>same tools used for Molecules (any objections to this?)
>>
>>Good.
>>
>>
>>>* Traversers traverse the graph structure of any AtomGraph. Traversers
>>>are low-level components that are helpful for building higher-level
>>>functionality. Currently two types of Traverser are available:
>>>DepthFirstTraverser and CycleTraverser. Both use a system of Handlers
>>>and Controllers - Handlers for handling events generated at various
>>>stages of a traversal algorithm and Controllers for exercising limited
>>>control over the algorithm itself. This system borrows from SAX's
>>>ContentHandler idea. HanserCycleTraverser is an implementation of
>>>CycleTraverser that uses Hanser's algorithm for finding the set of all
>>>cycles of an AtomGraph using collapsing Path-Graphs.
>>
>>CycleTraverser should use an interface, so that we can switch the
>>traverser.
>>If nothing is said a default traverser should be used.
>>The traverser should also have an ID and version number analogue to
>>descriptors.
>>
>>
>>
>>>* MoleculeComparator compares two AtomGraphs for isomorphism, but
>>>without comparing atom/bonding properties. UllmanComparator implements
>>>MoleculeComparator by using Ullman's subgraph isomorphism algorithm.
>>>Like Traverser, MoleculeComparator uses a system of Handlers and
>>>Controllers for fine-grained control. It should be possible to use
>>>this sytem to create additional isomorphism algorithms implementing
>>>MoleculeComparator.
>>
>>Isn't this only a formulation problem ?
>>Can't we use a boolean method compareNode(LabelSet) which uses a set of
>>labels to check isomorphism ?
>>
>>
>>>* QueryBuilder enables clients to build a molecular query using the
>>>same process that is used for building a Molecule with
>>>MoleculeBuilder. In fact, QueryBuilder extends MoleculeBuilder and can
>>>be used in many contexts calling for a MoleculeBuilder. QueryBuilder
>>>is designed for building queries that are based on a template molecule
>>>with constraints placed on individual Atoms with AtomQuery.
>>
>>Can 'pharmacophores' treated also with this approach. So are combined
>>features, e.g. carbon acid group combined to a single feature and a
>>distance to all other features allowed ?
>>
>>
>>
>>>* SmartsQueryFactory is in the early stages, but is intended to
>>>simplify the process of using QueryBuilder by enabling clients to use
>>>SMARTS Atomic Primitive strings as keys to obtain a fully functional
>>>AtomQuery. Although this isn't exactly a SMARTS parser, it isn't that
>>>far from being one given Octet's SmilesReader. Currenly only the
>>>wildcard Atomic Primitive ("*") is supported, but other should be
>>>appearing soon. The approach here has some elements in common with
>>>that of CDK's growing SMARTS support, but there are also some
>>>interesting differences.
>>
>>Same as above, so atom based (not feature based) compareNode(LabelSet)
>>method, where the LabelSet is what i would call the chemical kernel atom
>>labelling set.
>>
>>
>>>Looking a little further down the road for QSAR, what are people's
>>>thoughts on a framework for molecular descriptors? Of course, there
>>>hundreds of descriptors, and of course we all have our ideas on what a
>>>particular descriptor means or doesn't mean. What I'm actually
>>>wondering about is what a descriptor facility in QSAR would look and
>>>feel like. I've been looking at JOELib's descriptor framework, which
>>>has some reasonable concepts. From what I can tell, there are two
>>>basic kinds of descriptor: a "holistic" descriptor that is a single
>>>value (i.e. TPSA) and which is primitive-like, and everything else,
>>>which tends to be higher-resolution in nature (i.e. Topological
>>>Torsion) and more object-like. Are there any other ideas?
>>
>>With respect to query i would prefer the object approach, so we can use:
>>result=molecule.calculate("XYZ")
>>or as in JOELib
>>result1=calculator.calculate(mol1,"XYZ", Properties)
>>result2=calculator.calculate(mol2,"XYZ", Properties)
>>
>>for matching or similarity we can then use
>>// inherited from Comparator in Java API
>>// applicable for euclidian, tanimoto, atom-pairs
>>similarity=metricThatILike(result1,result2, Properties);
>>
>>For simple single value descriptors it would be also interesting to have:
>>similarity=metricThatILike(ResultSet1,ResultSet2, Properties);
>>Also with pharmacophore outlook or multiple graph isomorphism and not
>>only pair-wise matching.
>>
>>So a query is from my standpoint a kind of similarity-metric which can
>>only return 0 and 1. Sometimes, as in SMARTS matching we are only
>>interested in subgraph isomorphism.
>>result1=calculator.calculate(mol1,"XYZ", LabelSet)
>>result2=calculator.calculate(mol2,"XYZ", LabelSet)
>>// only applicable for this specific calculator
>>// can be used for maximum common substructure search (MCS)
>>matchings=matchingsThatILike(result1,result2, Properties);
>>
>>So, for SMARTS matching we need also:
>>matchings=matchingsThatILike(query1,result2, Properties);
>>
>>For pharmacophores 2D/3D/Shape we can also use this appraoch, because
>>the representation for the similarity/matching is the relevant point.
>>matchings=matchingsThatILike(query1,result2, Properties);
>>or
>>similarity=metricThatILike(result1,result2, Properties);
>>
>>Kind regards, Joerg
>>
>>
>
>
>
--
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW: http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
(E. Hemingway)
Never mistake action for meaningful action.
(Hugo Kubinyi,2004)
|
|
From: Joerg K. W. <we...@in...> - 2004-07-26 07:45:22
|
Hi Egon, sorry for cross-posting, but this is interesting for all java-project-admins. good old ANT, i've attached the build file, no it's not in the CVS. I've simply used all old sf-source-code-releases to get an objective PMD measure. Unfortunately setting properties seems only to work sometimes ? I don't get it. So, i've started the script for each PMD metric. You can download the required libraries at: http://sourceforge.net/project/showfiles.php?group_id=39708&package_id=108845 Kind regards, Joerg > On Monday 26 July 2004 00:05, Joerg K. Wegner wrote: > >>- Extensive PMD, JavaNCSS offline statistics, so on long term runs there >>are some non-functioanlity things to do ... just for improving the >>design and becoming more user friendly :-) >>http://www-ra.informatik.uni-tuebingen.de/software/joelib/statistics.html > > > That's a nice page... how did you create those in-time statistics? > Are the scripts in JOELib CVS? > > Egon > -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Egon W. <eg...@us...> - 2004-07-26 06:49:46
|
On Monday 26 July 2004 00:05, Joerg K. Wegner wrote: > - Extensive PMD, JavaNCSS offline statistics, so on long term runs there > are some non-functioanlity things to do ... just for improving the > design and becoming more user friendly :-) > http://www-ra.informatik.uni-tuebingen.de/software/joelib/statistics.html That's a nice page... how did you create those in-time statistics? Are the scripts in JOELib CVS? Egon -- eg...@sc... GPG: 1024D/D6336BA6 |
|
From: Joerg K. W. <we...@in...> - 2004-07-25 22:02:52
|
Hi Egon, Hi all, i've released a new JOELib version http://sourceforge.net/projects/joelib/ with the following changes: - Extended tutorial introducing formally molecular graphs. This is especially interesting for the Octet interface and the QSAR project. http://www-ra.informatik.uni-tuebingen.de/software/joelib/tutorial/JOELibPrimer.html - E/Z SMARTS matching and adding improved autodetection for 2D/3D structures if not using SMILES as input. - Extensive PMD, JavaNCSS offline statistics, so on long term runs there are some non-functioanlity things to do ... just for improving the design and becoming more user friendly :-) http://www-ra.informatik.uni-tuebingen.de/software/joelib/statistics.html Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
|
From: Joerg K. W. <we...@in...> - 2004-07-07 15:41:07
|
Hi all,
I've added dummy atom support for MDL-SDF import to CVS.
The hashed kernel ID has changed from
'715333816'
to
'-2141483117'
So please: 'Don't panic'
This will not change your descriptor calculation results, because the
changes affects only the 'dummy' atoms.
- joelib/src/joelib/io/MDLSD.java
Added dummy atom support for 'Du' entries.
- joelib/src/joelib/data/plain/types.txt
Internal representation of dummy atoms changed from 'X' to 'Xx'.
Now we are conform with joelib/src/joelib/data/plain/element.txt
See also:
joelib/kernel.txt for details and detailed ID changes.
FINALLY, you can treat all desriptor calculations with the kernel ID's
'715333816' and '-2141483117'
as equivalent, because nothing relevant has changed in the chemical
representation.
Kind regards, Joerg
--
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW: http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
(E. Hemingway)
Never mistake action for meaningful action.
(Hugo Kubinyi,2004)
|
|
From: Joerg K. W. <we...@in...> - 2004-07-07 15:29:02
|
Hi NAJI, > Thank very much for your advice : sh convert.sh yourOriginalFile.smi > phCorrectedFile.smi. Now, I can transform my original file to > pHcorrectedfile but in the transformations I don't manage to convert C > (=NH)(-NH2)(-NH-) to C(=NH2+)(-NH2)(-NH-) ( a guanidium group found > for example in the arginine ) As you can see at the bottom of this page http://www-ra.informatik.uni-tuebingen.de/software/joelib/tutorial/functionalities/mol-smarts.html 1. you should only apply one change at time. 2. I can't see any vector binding in your pattern, it should be something like this, but please remember that not all imaginable rules are implementetd in the basic transformer class, so try and check, e.g.: [N:1](-NH2)(-NH) >> [N+:1](-NH2)(-NH) > I have another question : Have you got some ideas how I could make in > order to count the total number of hydrogen of a molecule from a smiles > string. Explicit or implicite hydrogens ? Try: numHAtoms=atom.getImplicitValence() + atom.getValence() Kind regards, Joerg -- Dipl. Chem. Joerg K. Wegner Center of Bioinformatics Tuebingen (ZBIT) Department of Computer Architecture Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany Phone: (+49/0) 7071 29 78970 Fax: (+49/0) 7071 29 5091 E-Mail: mailto:we...@in... WWW: http://www-ra.informatik.uni-tuebingen.de -- Never mistake motion for action. (E. Hemingway) Never mistake action for meaningful action. (Hugo Kubinyi,2004) |
4 messages has been excluded from this view by a project administrator.
