Menu
▾
▴
joelib-cvs — Describe shortly your changes in the CVS
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(9) |
Sep
|
Oct
(3) |
Nov
(1) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joerg K. W. <we...@in...> - 2004-08-30 16:55:54
|
joelib/src/joelib/io/types/MDLSD.java PMD 'codesize': Reduced cyclomatic complexity (from 42 to <10) |
|
From: Joerg K. W. <we...@in...> - 2004-08-30 13:29:55
|
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:02
|
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) |
|
From: Joerg K. W. <we...@in...> - 2003-11-04 08:05:56
|
Hi, the aromaticity typer bug is fixed. see joelib.data.JOEAromaticTyper We use a prescreening of all available root atoms. Then, when picking new root atoms for bridging root atoms we check if the new root atom is a ring without root atom !!! 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 |
|
From: Joerg K. W. <we...@in...> - 2003-10-28 11:41:07
|
joelib/test/Convert.java Added 'split' option to generate splitted files 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 |
|
From: Joerg K. W. <we...@in...> - 2003-10-16 16:33:11
|
Hi, joelib.io.types.PDF The improved PDF-writer stores now also descriptor entries. More complex=20 descriptor entries like arrays, matrices and so on are truncated.=20 Otherwise the layout would be too bad. Regards, J=F6rg --=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 |
|
From: Joerg K. W. <we...@in...> - 2003-10-15 07:06:32
|
Hi, - joelib.gui.render AWT 2D molecule rendering and image creation - joelib.io.SimpleImageWriter joelib.io.types.BMP joelib.io.types.GIF joelib.io.types.JPEG joelib.io.types.PDF joelib.io.types.PPM Image writing classes for default usage with JOELib. - joelib.util.types.Int New class to replace, from time to time, the int[0] workaround to store plain intergers as objects. - Fixed bug in joelib.mol.JOEMol for virtual bonds. Now virtual bonds (added bonds, where an atom is until now now added) can now store stereochemistry informations correctly - jtt.docbook.*Molecule* Preprocessing parer for DocBook files to create 2D rendered images of molecules - docs/docbookO2C2 docs/tutorialO2C2 Open Organic Chemistry Content (O2C2) document to show some examples for the good combination of the image writing facilities for DocBook (jtt.docbook) 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 |
|
From: Joerg K. W. <we...@in...> - 2003-08-22 16:18:29
|
Hi Gert, > Probably this test should be added at other places too. perfect, i've moved the testing functionality to the java3d.util.Java3DHelper class, or users without java3d will have problems compiling the core package, when there occure other java3d dependencies which are not in molviewer.java3d sub-packages. I've also changed the configOk method to static, there is no need for a new class instance for this testing method. 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 |
|
From: Gert S. <Ger...@re...> - 2003-08-22 09:17:00
|
When no non-null GraphicsConfiguration3D-object could be created, because of a wrongly configured graphics driver, an outdated graphics board or a buggy java3d package, the ViewerFrame was still shown when calling the Viewer main method. For this reason a test has been added in the beginning of the Viewer main method to check the ability to create a non-null GraphicsConfiguration3D-object. An additional class, joelib/test/TestJava3D, has been created to perform the testing. Probably this test should be added at other places too. Greetings, Gert |
|
From: Gert S. <Ger...@re...> - 2003-08-19 10:19:13
|
> So if you want to use your own formatter, please use analogue options. I have been using emacs for quite some time now and would appreciate if I could continue doing so. Is anyone aware of ports of the eclipse JAVA source formatting to emacs? And how should I change this formatting manually? Thanks, Gert |
|
From: Joerg K. W. <we...@in...> - 2003-08-19 10:00:19
|
Hi,
for avoiding CVS diff complications i recommend to use the same source
code formatter for all source code files.
1. I use eclipse, eventually we can also use another tool as ant task,
but i would still prefer eclipse, e.g. for formatting also impoerts and
the good wraning and error styles when editing.
2. for all comments i recommend
// TODO: my question or todo tag
because eclipse shows nice blue targets in the editor for these tags.
and not:
// QUESTION
// ???
// XXX
Link: http://www.eclipse.org/
Eclipse-formatter preferences to use:
New Lines: (x) insert before opening brace
(x) insert in control statements
( ) clear blank lines
( ) insert new line between else-if
(x) insert inside empty block
Line Splitting: 80
Style: ( ) Compact assignment
(x) Insert space after cast
(x) Insert tabs, not spaces
space identation level: 4
So if you want to use your own formatter, please use analogue options.
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
|
|
From: Joerg K. W. <we...@in...> - 2003-08-19 09:50:24
|
Find new root ring atoms, if more than 2 other neighbour ring atoms -->ignore non-heavy weight atoms for breaking this loop http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/joelib/joelib/src/joelib/data/JOEAromaticTyper.java.diff?r1=1.18&r2=1.19 Return null for emtpy descriptor names. http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/joelib/joelib/src/joelib/molecule/GenericDataHolder.java.diff?r1=1.18&r2=1.19 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 |
|
From: Gert S. <Ger...@re...> - 2003-08-19 08:59:13
|
When reading in the comment line of a file in CTX-format, the actual comment line wasn't added to the constructed JOECommentData. When converting CTX-files to other files, this could result in corrupt files. This occurred for instance when converting to a MDL SD-file. Perform cvs diff -c -r 1.22 -r 1.21 src/joelib/io/types/ClearTextFormat.java to view the changes. Greetings, Gert |
|
From: Joerg K. W. <we...@in...> - 2003-08-14 21:46:54
|
Hi Gert, >>2DCOORD: >>first line: default length used for the coordinate > What would be meant with 'default length'? Default z-coordinate maybe? > Or the default value if a coordinate is missing? It is always '1' in my > .CTX-files. I think they mean the multiplication factor for atom coordinates ... for more informations we should contact Dr. Ihlenfeldt or one out of the Group of Prof Gasteiger, e.g. Achim or Thomas. >>second line: xmin, xmax, ymin, ymax are the rectangle coordinates >>including all atom coordi > I should have figured this out myself. >>which means a CTX-writer could be also useful > Sorry, I don't completely understand this deduction. Do you mean that it > would in any case be useful to implement a CTX-writer, or do you more > specifically mean that it would be useful to implement the CTX-writer > because of these rectangle coordinate (seems absurd, but maybe I'm > missing something)? 1. I think it could be usefull to implement the coordinate ouput more correctly to store not only 3D coordinates but also 2D, 3D or both of them analogue to CML --> With low priority, in my opinion, because i do not really need a CTX writer and the format is not documented really well!!! I own only the old 1994 manual in paper form. 2. This requires also taking 2D AND 3D coordinates into account when loading molecules, so i recommend the analogue mechanism like the one in joelib.io.types.cml.MoleculeFileCDO:endObject(String objectType) which stores 2D informations in coordinates2Dx coordinates2Dy and 3D informations in coordinates3Dx coordinates3Dy coordinates3Dy Both are simple double 'atom property' descriptors, which allows us also to store such kind of informations in all formats which support descriptors, e.g. MDL SD 3. Finally the JOELib writer for 2DCOORDS entry can also store the ? ? ? ? ? options !;-) So, i think, the writer is really far behind other topics which should be implemented ... was just an idea ... i would say forget my last mail !;-) > Greetings and thanks for the lookup. > > Gert 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 |
|
From: Joerg K. W. <we...@in...> - 2003-08-14 14:14:05
|
|
From: Gert S. <Ger...@re...> - 2003-08-12 10:16:10
|
When trying to convert a structure file in ctx-format, a NullPointerException was thrown. The main origin of the error was found in the parsing of the /2DCOORD section. The original code expected a formatting like: /2DCOORD n n 1 xcoord_atom_1 ycoord_atom_1 .. n xcoord_atom_n ycoord_atom_n Whilst the .ctx-files produced by CACTVS (both v2.56 and v2.95) have a formatting like: /2DCOORD n+2 n+2 ? ? ? ? ? 1 xcoord_atom_1 ycoord_atom_1 .. n xcoord_atom_n ycoord_atom_n Does anyone know the meaning of these 2 extra lines before the actual 2d-coordinates? At the moment the parser just ignores them. To be complete, here follows the diff of the changed ClearTextFormat.java and the old ClearTextFormat.java (or at least the important parts of the diff output). If this is not necessary in the future, please let me know: diff joelib/io/types/ClearTextFormat_New.java joelib/io/types/ClearTextFormat.java 349,351c347,349 < boolean is2D = (line.charAt(2) == '2') ? true: false; < < // read atoms coordinates --- > boolean is2D = (line.charAt(2) == 2) ? true : false; > > // read atoms coordinates 356,357c354 < counter = Integer.parseInt((String) tv.get(1)) - 2; < --- > counter = Integer.parseInt((String) tv.get(1)); 369,372d365 < //QUESTION: Do the following two lines contain necessary information? < line = lnr.readLine(); < line = lnr.readLine(); < Greetings, Gert Sclep |
