From: Rajarshi G. <rg...@in...> - 2007-10-23 15:33:30
|
Hi, looking through the various packages in trunk, a number are either not used or duplicate other code in some way. I was wondering whether it would be a good idea to have an 'archive' pakcage where such code can be moved to and deleted at one point. Two examples come to mind: 1. The old R-CDK code - it used SJava but we don't bother with that anymore. It's been kept in for completeness, but it really, should be moved or deleted 2. The non-JJTree SMARTS parser. Given that the JJTree parser has fewer bugs, etc, it makes sense to remove the other parser. This would also make the SMARTS package cleaner - currently it's confusing to see two parsers in similar paths Comments? ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Regular naps prevent old age.... especially if you take them while driving |
From: Egon W. <ego...@gm...> - 2007-10-23 15:55:34
|
On 10/23/07, Rajarshi Guha <rg...@in...> wrote: > I was wondering whether it would be a good idea to have an 'archive' > pakcage where such code can be moved to and deleted at one point. I have used 'obsolete' for exactly this purpose... > Two examples come to mind: > > 1. The old R-CDK code - it used SJava but we don't bother with that > anymore. It's been kept in for completeness, but it really, should be > moved or deleted Ack. > 2. The non-JJTree SMARTS parser. Given that the JJTree parser has > fewer bugs, etc, it makes sense to remove the other parser. This > would also make the SMARTS package cleaner - currently it's confusing > to see two parsers in similar paths Ummm... this might actually deserve a full separate email... is there nothing in the other version left that is not dealt with the JJTree version? Sushil? Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2007-10-23 16:47:53
|
On Oct 23, 2007, at 11:55 AM, Egon Willighagen wrote: >> 2. The non-JJTree SMARTS parser. Given that the JJTree parser has >> fewer bugs, etc, it makes sense to remove the other parser. This >> would also make the SMARTS package cleaner - currently it's confusing >> to see two parsers in similar paths > > Ummm... this might actually deserve a full separate email... is there > nothing in the other version left that is not dealt with the JJTree > version? At least from the point of view of bugs smiles.smarts.SmartsParser.jj - 85 Junit failures (in ParserTest.java) smiles.smarts.parser.SmartsParser.jjt - 2 Junit failures (in RecursiveTest.java and the two failures are due to H addition/ aromaticity perception issues and 0 in ParserTest.java) I don't think the non-JJTree parser handles recursive SMARTS - I may be wrong ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Science kind of takes the fun out of the portent business. -Hobbes |
From: Egon W. <ego...@gm...> - 2007-10-23 17:33:50
|
On 10/23/07, Rajarshi Guha <rg...@in...> wrote: > On Oct 23, 2007, at 11:55 AM, Egon Willighagen wrote: > At least from the point of view of bugs > > smiles.smarts.SmartsParser.jj - 85 Junit failures (in ParserTest.java) > > smiles.smarts.parser.SmartsParser.jjt - 2 Junit failures (in > RecursiveTest.java and the two failures are due to H addition/ > aromaticity perception issues and 0 in ParserTest.java) Which classes contain the JUnit tests, for either approach? Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2007-10-23 17:41:51
|
On Oct 23, 2007, at 1:33 PM, Egon Willighagen wrote: > On 10/23/07, Rajarshi Guha <rg...@in...> wrote: >> On Oct 23, 2007, at 11:55 AM, Egon Willighagen wrote: >> At least from the point of view of bugs >> >> smiles.smarts.SmartsParser.jj - 85 Junit failures (in >> ParserTest.java) >> >> smiles.smarts.parser.SmartsParser.jjt - 2 Junit failures (in >> RecursiveTest.java and the two failures are due to H addition/ >> aromaticity perception issues and 0 in ParserTest.java) > > Which classes contain the JUnit tests, for either approach? org/openscience/cdk/test/smiles/smarts/ParserTest.java - non-JJTree org/openscience/cdk/test/smiles/smarts/parser/ParserTest.java - JJTree org/openscience/cdk/test/smiles/smarts/parser/RecursiveTest.java - JJTree, rec SMARTS ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it. |
From: Egon W. <ego...@gm...> - 2007-10-25 12:28:39
|
Rajarshi/David, On 10/23/07, Rajarshi Guha <rg...@in...> wrote: > On Oct 23, 2007, at 1:33 PM, Egon Willighagen wrote: > > On 10/23/07, Rajarshi Guha <rg...@in...> wrote: > >> On Oct 23, 2007, at 11:55 AM, Egon Willighagen wrote: > >> At least from the point of view of bugs > >> > >> smiles.smarts.SmartsParser.jj - 85 Junit failures (in > >> ParserTest.java) > >> > >> smiles.smarts.parser.SmartsParser.jjt - 2 Junit failures (in > >> RecursiveTest.java and the two failures are due to H addition/ > >> aromaticity perception issues and 0 in ParserTest.java) OK, I ported tests from the test suite for the JavaCC based SMARTS parser to the test suite of the JJTree based version, and with the results: smiles.smarts.parser.SmartsParser.jjt - 22 fails + 1 error (See commit 9207 in branches/cdk-1.0.x and 9208 in trunk/) Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2007-10-23 16:36:04
|
On Oct 23, 2007, at 11:55 AM, Egon Willighagen wrote: > On 10/23/07, Rajarshi Guha <rg...@in...> wrote: >> I was wondering whether it would be a good idea to have an 'archive' >> pakcage where such code can be moved to and deleted at one point. > > I have used 'obsolete' for exactly this purpose... Is there an actual package called obsolete in trunk? I don't see one ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- A committee is a life form with six or more legs and no brain. -- Lazarus Long, "Time Enough For Love" |
From: Egon W. <ego...@gm...> - 2007-10-23 17:28:45
|
On 10/23/07, Rajarshi Guha <rg...@in...> wrote: > On Oct 23, 2007, at 11:55 AM, Egon Willighagen wrote: > > On 10/23/07, Rajarshi Guha <rg...@in...> wrote: > >> I was wondering whether it would be a good idea to have an 'archive' > >> pakcage where such code can be moved to and deleted at one point. > > > > I have used 'obsolete' for exactly this purpose... > > Is there an actual package called obsolete in trunk? I don't see one I think I have deleted them already :) Seriously... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Jiao, D. <dj...@in...> - 2007-10-25 13:59:14
|
Hi, The stats Rajarshi used was before the new atom type was introduced. But the unit test for JavaCC is pretty out of date. When I updated the junit tests, I only update the unit test for JJTree. So the two becomes inconsistent. The one you ported has a few problems. And there are some real failures as well. Please see my explanation as below. I saw 27 fails and 4 errors in the test you ported. There are 12 failures and 4 errors in the SMARTSSearchTest. Most of the fails are because of the failure of detection of aromacity in the smiles. There should be 12, which also occurs in SMARTSSearchTest. I've mentioned it in previous emails and I thought I also documented it on a wiki page. But I can't find the wiki any more. Is the CDK wiki down? In the ported test, some of the other failures are because the number used in the assert is not correct. I've updated the SMARTSSearchTest for JJTree after Rajarshi implemented the USA (Unique Set of Atoms) in SMARTSQueryTool. So in SMARTSSearchTest, I am testing two types of matches: the regular match, and the USA match. All tests have been cross checked with the daylight depict tool. The Unit test for the JavaCC based parser hasn't adapted this change yet. So basically, the number is wrong. It can be proved by simply testing with the daylight depict tool. There is another case: testPropertyR2 I found the smiles is not correctly parsed. So I commented it in SMARTSSearchTest. I've reported this in an email and documented on the wiki. I should have submitted a bug report. The errors: testPattern240: This is not a correct smarts. I don't know how it gets there. So throwing an error is the right behavior. testLogicalOrHighAnd5: The error message says: Cannot percieve atom type of the 3th atom: Hg. testLogicalOrHighAnd7: Cannot percieve atom type of the 3th atom: I testLogicalOrLowAnd5: Cannot percieve atom type of the 3th atom: Hg. So they are really smiles parsing errors. I hope this covers everything. David Egon Willighagen wrote: > Rajarshi/David, > > On 10/23/07, Rajarshi Guha <rg...@in...> wrote: > >> On Oct 23, 2007, at 1:33 PM, Egon Willighagen wrote: >> >>> On 10/23/07, Rajarshi Guha <rg...@in...> wrote: >>> >>>> On Oct 23, 2007, at 11:55 AM, Egon Willighagen wrote: >>>> At least from the point of view of bugs >>>> >>>> smiles.smarts.SmartsParser.jj - 85 Junit failures (in >>>> ParserTest.java) >>>> >>>> smiles.smarts.parser.SmartsParser.jjt - 2 Junit failures (in >>>> RecursiveTest.java and the two failures are due to H addition/ >>>> aromaticity perception issues and 0 in ParserTest.java) >>>> > > OK, I ported tests from the test suite for the JavaCC based SMARTS > parser to the test suite of the JJTree based version, and with the > results: > > smiles.smarts.parser.SmartsParser.jjt - 22 fails + 1 error > > (See commit 9207 in branches/cdk-1.0.x and 9208 in trunk/) > > Egon > > -- Dazhi (David) Jiao System Analyst and Programmer Digital Library Program Indiana University at Bloomington 1320 E 10th Street, 501, Bloomington Indiana 47405 Tel: 812-856-0089 Email: dj...@in... |
From: Egon W. <ego...@gm...> - 2007-10-25 14:06:10
|
Hi David, On 10/25/07, Jiao, Dazhi <dj...@in...> wrote: > The stats Rajarshi used was before the new atom type was introduced. Please file bug reports against the atom typer, or the hydrogen adder and aromaticity detector based on it. You might feel more happy with the results of these tests in the cdk-1.0.x/ branch, which does not use the new atom typing. > But the unit test for JavaCC is pretty out of date. Please explain.... > When I updated the > junit tests, I only update the unit test for JJTree. So the two becomes > inconsistent. The one you ported has a few problems. And there are some > real failures as well. Please see my explanation as below. > > I saw 27 fails and 4 errors in the test you ported. There are 12 > failures and 4 errors in the SMARTSSearchTest. > > Most of the fails are because of the failure of detection of aromacity > in the smiles. That's why SMILES should not be used in JUnit tests :) > There should be 12, which also occurs in > SMARTSSearchTest. I've mentioned it in previous emails and I thought I > also documented it on a wiki page. But I can't find the wiki any more. > Is the CDK wiki down? Likely... big problem... > In the ported test, some of the other failures are because the number > used in the assert is not correct. OK, update them then. > I've updated the SMARTSSearchTest for > JJTree after Rajarshi implemented the USA (Unique Set of Atoms) in > SMARTSQueryTool. So in SMARTSSearchTest, I am testing two types of > matches: the regular match, and the USA match. All tests have been cross > checked with the daylight depict tool. The Unit test for the JavaCC > based parser hasn't adapted this change yet. So basically, the number is > wrong. It can be proved by simply testing with the daylight depict tool. > > There is another case: testPropertyR2 > > I found the smiles is not correctly parsed. So I commented it in > SMARTSSearchTest. I've reported this in an email and documented on the > wiki. I should have submitted a bug report. OK, add these SMILES as JUnit tests for the SmilesParser (in trunk/). Add assertions for those things that go wrong. > The errors: > > testPattern240: This is not a correct smarts. I don't know how it gets > there. So throwing an error is the right behavior. OK, remove that test then. > testLogicalOrHighAnd5: The error message says: Cannot percieve atom type > of the 3th atom: Hg. > testLogicalOrHighAnd7: Cannot percieve atom type of the 3th atom: I > testLogicalOrLowAnd5: Cannot percieve atom type of the 3th atom: Hg. OK, that's very likely a CDK atom typing limitation... please file as bug report, and assign to me. > So they are really smiles parsing errors. Please check the report for branches/cdk-1.0.x/ too, because tests are failing there too, and no new CDKAtomTyping is involved there... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Jiao, D. <dj...@in...> - 2007-10-25 14:12:57
|
Egon Willighagen wrote: > Hi David, > > On 10/25/07, Jiao, Dazhi <dj...@in...> wrote: > >> The stats Rajarshi used was before the new atom type was introduced. >> > > Please file bug reports against the atom typer, or the hydrogen adder > and aromaticity detector based on it. You might feel more happy with > the results of these tests in the cdk-1.0.x/ branch, which does not > use the new atom typing. > Will do. > >> But the unit test for JavaCC is pretty out of date. >> > > Please explain.... > I don't deem myself responsible for the JavaCC based parser. I don't think others think that way either based on our previous email exchanges. > >> When I updated the >> junit tests, I only update the unit test for JJTree. So the two becomes >> inconsistent. The one you ported has a few problems. And there are some >> real failures as well. Please see my explanation as below. >> >> I saw 27 fails and 4 errors in the test you ported. There are 12 >> failures and 4 errors in the SMARTSSearchTest. >> >> Most of the fails are because of the failure of detection of aromacity >> in the smiles. >> > > That's why SMILES should not be used in JUnit tests :) > Please advise what other options I have. > >> There should be 12, which also occurs in >> SMARTSSearchTest. I've mentioned it in previous emails and I thought I >> also documented it on a wiki page. But I can't find the wiki any more. >> Is the CDK wiki down? >> > > Likely... big problem... > > >> In the ported test, some of the other failures are because the number >> used in the assert is not correct. >> > > OK, update them then. > It'll be really a waste of time to update because it basically will end up with the same unit test as SMARTSSearchTest. > >> I've updated the SMARTSSearchTest for >> JJTree after Rajarshi implemented the USA (Unique Set of Atoms) in >> SMARTSQueryTool. So in SMARTSSearchTest, I am testing two types of >> matches: the regular match, and the USA match. All tests have been cross >> checked with the daylight depict tool. The Unit test for the JavaCC >> based parser hasn't adapted this change yet. So basically, the number is >> wrong. It can be proved by simply testing with the daylight depict tool. >> >> There is another case: testPropertyR2 >> >> I found the smiles is not correctly parsed. So I commented it in >> SMARTSSearchTest. I've reported this in an email and documented on the >> wiki. I should have submitted a bug report. >> > > OK, add these SMILES as JUnit tests for the SmilesParser (in trunk/). > Add assertions for those things that go wrong. > Will do. > >> The errors: >> >> testPattern240: This is not a correct smarts. I don't know how it gets >> there. So throwing an error is the right behavior. >> > > OK, remove that test then. > > >> testLogicalOrHighAnd5: The error message says: Cannot percieve atom type >> of the 3th atom: Hg. >> testLogicalOrHighAnd7: Cannot percieve atom type of the 3th atom: I >> testLogicalOrLowAnd5: Cannot percieve atom type of the 3th atom: Hg. >> > > OK, that's very likely a CDK atom typing limitation... please file as > bug report, and assign to me. > > Will do. >> So they are really smiles parsing errors. >> > > Please check the report for branches/cdk-1.0.x/ too, because tests are > failing there too, and no new CDKAtomTyping is involved there... > How do I check it? I haven't used the branches before. Thanks! David |
From: Egon W. <ego...@gm...> - 2007-10-25 14:30:27
|
Hi David, On 10/25/07, Jiao, Dazhi <dj...@in...> wrote: > >> But the unit test for JavaCC is pretty out of date. > >> > > > > Please explain.... > > > I don't deem myself responsible for the JavaCC based parser. I don't > think others think that way either based on our previous email exchanges. No, you are not. But you indicate that something is wrong with the code of the unit tests, which makes you responsible to indicate *what* is wrong with it... it does not make you responsible for fixing it... > > That's why SMILES should not be used in JUnit tests :) > > > Please advise what other options I have. Make a IMolecule object directly, with addAtom() and addBond() calls. > >> In the ported test, some of the other failures are because the number > >> used in the assert is not correct. > >> > > > > OK, update them then. > > > It'll be really a waste of time to update because it basically will end > up with the same unit test as SMARTSSearchTest. Was Rajarshi not complete in his overview in JUnit test suites? I have not seen this suite yet... please summarize which suites there are for the JJTree based SMARTS parser, and what each suite does. > > Please check the report for branches/cdk-1.0.x/ too, because tests are > > failing there too, and no new CDKAtomTyping is involved there... > > > How do I check it? I haven't used the branches before. svn co https://cdk.svn.sourceforge.net/svnroot/cdk/branches/cdk-1.0.x Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2007-10-25 14:39:19
|
On Oct 25, 2007, at 10:30 AM, Egon Willighagen wrote: > > >>>> In the ported test, some of the other failures are because the >>>> number >>>> used in the assert is not correct. >>>> >>> >>> OK, update them then. >>> >> It'll be really a waste of time to update because it basically >> will end >> up with the same unit test as SMARTSSearchTest. > > Was Rajarshi not complete in his overview in JUnit test suites? I have > not seen this suite yet... please summarize which suites there are for > the JJTree based SMARTS parser, and what each suite does. I just reported the Junit tests that specifically test parsing capabilities and not the stuff related to things like the SmartsQueryTool etc. ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- In matrimony, to hesitate is sometimes to be saved. -- Butler |
From: Egon W. <ego...@gm...> - 2007-10-25 14:42:53
|
On 10/25/07, Rajarshi Guha <rg...@in...> wrote: > On Oct 25, 2007, at 10:30 AM, Egon Willighagen wrote: > > Was Rajarshi not complete in his overview in JUnit test suites? I have > > not seen this suite yet... please summarize which suites there are for > > the JJTree based SMARTS parser, and what each suite does. > > I just reported the Junit tests that specifically test parsing > capabilities and not the stuff related to things like the > SmartsQueryTool etc. Ah, now I think I understand where the confusion comes from :) So, the tests I have been adding were already available in SmartsQueryToolTest? Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2007-10-25 14:48:26
|
On Oct 25, 2007, at 10:42 AM, Egon Willighagen wrote: > On 10/25/07, Rajarshi Guha <rg...@in...> wrote: >> On Oct 25, 2007, at 10:30 AM, Egon Willighagen wrote: >>> Was Rajarshi not complete in his overview in JUnit test suites? I >>> have >>> not seen this suite yet... please summarize which suites there >>> are for >>> the JJTree based SMARTS parser, and what each suite does. >> >> I just reported the Junit tests that specifically test parsing >> capabilities and not the stuff related to things like the >> SmartsQueryTool etc. > > Ah, now I think I understand where the confusion comes from :) > > So, the tests I have been adding were already available in > SmartsQueryToolTest? I would assume so ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- "355/113 -- Not the famous irrational number PI, but an incredible simulation!" |
From: Jiao, D. <dj...@in...> - 2007-10-25 15:39:08
|
Egon Willighagen wrote: > On 10/25/07, Rajarshi Guha <rg...@in...> wrote: > >> On Oct 25, 2007, at 10:30 AM, Egon Willighagen wrote: >> >>> Was Rajarshi not complete in his overview in JUnit test suites? I have >>> not seen this suite yet... please summarize which suites there are for >>> the JJTree based SMARTS parser, and what each suite does. >>> >> I just reported the Junit tests that specifically test parsing >> capabilities and not the stuff related to things like the >> SmartsQueryTool etc. >> > > Ah, now I think I understand where the confusion comes from :) > > So, the tests I have been adding were already available in SmartsQueryToolTest? > The unit tests for "Parsing smarts" are in org.openscience.cdk.test.smiles.smarts.parser.visitor.SmartsQueryVisitorTest David |
From: Rajarshi G. <rg...@in...> - 2007-10-26 18:53:10
|
On Oct 25, 2007, at 10:13 AM, Jiao, Dazhi wrote: >> >>> In the ported test, some of the other failures are because the >>> number >>> used in the assert is not correct. >>> >> >> OK, update them then. >> > It'll be really a waste of time to update because it basically will > end > up with the same unit test as SMARTSSearchTest. Egon, could you revert this class, since as Dazhi points out, fixing the counts will bring it back to the original version ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- A motion to adjourn is always in order. |
From: Egon W. <ego...@gm...> - 2007-10-26 19:16:46
|
On 10/26/07, Rajarshi Guha <rg...@in...> wrote: > On Oct 25, 2007, at 10:13 AM, Jiao, Dazhi wrote: > > It'll be really a waste of time to update because it basically will > > end up with the same unit test as SMARTSSearchTest. > > Egon, could you revert this class, since as Dazhi points out, fixing > the counts will bring it back to the original version Which class? I don't think I touched SMARTSSearchTest... Egon -- ---- http://chem-bla-ics.blogspot.com/ |
From: Rajarshi G. <rg...@in...> - 2007-10-26 19:33:10
|
On Oct 26, 2007, at 3:16 PM, Egon Willighagen wrote: > On 10/26/07, Rajarshi Guha <rg...@in...> wrote: >> On Oct 25, 2007, at 10:13 AM, Jiao, Dazhi wrote: >>> It'll be really a waste of time to update because it basically will >>> end up with the same unit test as SMARTSSearchTest. >> >> Egon, could you revert this class, since as Dazhi points out, fixing >> the counts will bring it back to the original version > > Which class? I don't think I touched SMARTSSearchTest... Oops, sorry about that. Should have looked at the SVN history first. But in ParserTest there are a number of errors. Dazhi pointed out that they are due to counts not being updated etc. However for public void testBondSingle5() throws Exception { int m = match("CC", "CC1(C)SC2C(NC(=O)Cc3ccccc3)C(=O)N2C1C(=O)O"); assertEquals(7, m); } the number of matches is supposed to be 14 (with 7 for the usa). m is currently coming out to 28 Similarly for some of the other tests. What's going on since SMARTSSearchTest seems to be running fine (with the exception of errors due to atom type and aromaticity detection) ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- CChheecckk yyoouurr dduupplleexx sswwiittcchh.. |
From: Rajarshi G. <rg...@in...> - 2007-10-26 19:35:26
|
On Oct 26, 2007, at 3:32 PM, Rajarshi Guha wrote: > > But in ParserTest there are a number of errors. Dazhi pointed out > that they are due to counts not being updated etc. > > However for > > public void testBondSingle5() throws Exception { > int m = match("CC", "CC1(C)SC2C(NC(=O)Cc3ccccc3)C(=O)N2C1C(=O) > O"); > assertEquals(7, m); > } > > the number of matches is supposed to be 14 (with 7 for the usa). m is > currently coming out to 28 Sorry! The error is due to the fact that the aromatic ring is being parsed as aromatic, so there are extra single bonds and so the count of 28 returned by the SMARTS engine is indeed correct ------------------------------------------------------------------- Rajarshi Guha <rg...@in...> GPG Fingerprint: 0CCA 8EE2 2EEB 25E2 AB04 06F7 1BB9 E634 9B87 56EE ------------------------------------------------------------------- All the passions make us commit faults; love makes us commit the most ridiculous ones. -- La Rochefoucauld |