Camelia, the Perl 6 bug

IRC log for #cdk, 2011-02-24

| Channels | #cdk index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
05:09 egonw joined #cdk
05:48 egonw left #cdk
06:11 egonw joined #cdk
06:20 egonw_ joined #cdk
06:24 egonw__ joined #cdk
06:24 egonw left #cdk
06:27 egonw_ left #cdk
06:29 egonw joined #cdk
06:32 egonw__ left #cdk
06:33 egonw_ joined #cdk
06:34 egonw left #cdk
06:43 egonw__ joined #cdk
06:47 egonw_ left #cdk
06:48 egonw joined #cdk
06:52 egonw__ left #cdk
06:53 egonw_ joined #cdk
06:57 egonw left #cdk
07:05 egonw__ joined #cdk
07:08 egonw_ left #cdk
07:22 Gpox joined #cdk
07:23 egonw__ left #cdk
07:28 sneumann_ joined #cdk
07:31 egonw__ joined #cdk
09:16 bag__ left #cdk
09:25 bag__ joined #cdk
09:35 egonw__ is now known as egonw
09:42 jbrefort joined #cdk
10:15 maclean joined #cdk
10:19 maclean left #cdk
12:03 maclean joined #cdk
12:04 maclean hi
12:04 zarah ni hao maclean
12:42 maclean egonw : I updated the SMSD patch set, but only remembered to read your previous reviews after uploading (sorry :( )
12:42 egonw no worries...
12:43 egonw are they on GitHub too?
12:43 maclean I will fix those things that have not already been done (eg: javadocs in ChemFilter methods are todo, copywrite is done)
12:43 egonw then I can give inline comments
12:43 maclean Er, no.
12:43 maclean Hmmm. It's in a branch on my cdk, so I could probably just push that.
12:43 maclean Running low on batteries...
12:45 maclean "pack-objects died with strange error" - darn.
12:47 egonw OK, I'll check your branch
12:47 egonw soonish
12:48 egonw next week fully programmed with EU FP7 project meetings
12:48 maclean well - I'll have to push it first :) - just letting you know, is all.
12:48 maclean ok. g2g.
12:48 maclean (1% battery!)
12:48 maclean left #cdk
13:53 s_wolf left #cdk
13:57 jbrefort left #cdk
15:03 Gpox left #cdk
15:09 maclean joined #cdk
15:25 egonw left #cdk
15:45 egonw joined #cdk
15:47 egonw maclean: I don't think factoring out the inchi parsing is needed for this patch to be accepted..
15:48 maclean Oh, right.
15:48 egonw maclean: I was also wondering if Sam's code doesn't already do InChI 2 IAtomContainer
15:48 egonw we have errors in unit tests too..
15:48 maclean Well perhaps, but Mark's code is asking for some specific things from the inchi
15:49 egonw so, I think readability matters there too
15:49 egonw yes, it does...
15:49 maclean Yes, but it's always a balance
15:50 egonw well, from my only-80-chars-fit-on-my-screen, 120 is already quite balanced :)
15:50 maclean It's "Stefan's equivalency principle" - shorter width means longer height.
15:50 egonw I think source code is not supposed to be a novel :)
15:50 egonw indeed... which is why also complains about long methods
15:50 maclean But you're probably not reading those InChIs, are you?
15:51 egonw the trick is to write clean code
15:51 egonw and clean code, as any IT prof can tell you, has more or less one function on one screen
15:52 egonw what Stefan's principle overlooks here, is that source code writing is not smashing on one side of the code so that it becomes wider or shorter, depending on your prefs
15:53 egonw you can write spaghetti code in any shape you like
15:54 egonw it's also easy to obscure code to make it hide bugs
15:54 egonw that's why one should try to write simple, readable code
15:54 maclean And you can write good code in different shapes, too. Shape is a crude code quality descriptor.
15:54 egonw indeed...
15:55 egonw but something that does not fit on a screen is unreadable whatever the shape is
15:55 egonw you don't complaint with a referee either that your English is fine, because the experiment matters
15:56 egonw you want the message to be understood
15:56 egonw shape matters, because you want *others* to read your code
15:56 egonw and then the *others* set normals on what the shape should be like
15:56 egonw so does the CDK community
15:57 egonw the alternative is that no one likes to referee your patches
15:57 maclean I don't disagree with any of those things ... in general.
15:58 maclean It's just that all rules have exceptions.
15:58 egonw yes, they do
15:58 egonw and that's fine
15:58 egonw it's not the rules that decide if a patch is acceptable
15:58 egonw it's the reviewers
15:59 egonw (marking that a reviewer can't reject a patch if all rules have been complied too)
15:59 egonw anyway...
15:59 egonw some just don't like to be reviewed at all
16:00 maclean Well, most people I would say. With papers it's different, because publishing them matters more.
16:00 egonw_ joined #cdk
16:02 egonw_ yes, and I guess that's why we had so many bugs in the CDK
16:04 maclean Absolutely, and code can always be better. It's just that the unfortunate fact is contributing code to the CDK is still optional :)
16:04 egonw left #cdk
16:04 egonw_ well, that's freedom I guess...
16:05 egonw_ btw... another point I like to stress, is that it does not have to be the original author to reply on reviewer requests!
16:05 egonw_ and I think the tautomer patch is working out fine...
16:05 egonw_ you reviewed the code *and* write fixes
16:06 egonw_ I love to see that happen more
16:06 egonw_ this is what open source is about
16:06 egonw_ I have written also a few patches for SMSD when the first patch arrived
16:07 egonw_ one advantage of factoring out the InChI parsing, would be that it could get unit testing...
16:07 egonw_ it's not tested itself right now...
16:07 egonw_ yet, the functionality is really interesting...
16:08 maclean No? Hmmm.
16:08 egonw_ I have a long standing wish to use information from the InChI auxilary layer
16:08 maclean Yes. Would be nice to have the InChI canonical labelling available.
16:08 egonw_ don't think so...
16:08 egonw_ might have overlooked it though...
16:08 egonw_ but the threading issue is important to fix
16:08 maclean Auxillary layer? Wait. Will look it up.
16:09 maclean Yeah, I didn't understand that - how do you know it isn't thread-safe?
16:09 egonw_ the pattern here is the use of global variables
16:10 egonw_ yet, the class is not written to be instantiated for one molecule
16:10 egonw_ so, you can use one generator class, and call getTautomer() in parallel
16:10 egonw_ which would cause the global variable to be overwritten, causing general havoc
16:11 maclean Ohhh. Right right. I see.
16:11 egonw_ so, either there should be a new InChITautomerGenerator(IMolecule)
16:11 egonw_ or not use global vars
16:11 egonw_ it's not too difficult to fix, I think
16:12 maclean Probably not. Could also use the singleton pattern that's so popular in the CDK.
16:14 egonw_ yeah, that's often used when a IChemObjectBuilder is needed...
16:14 egonw_ when the input is not an IChemObject
16:14 egonw_ that's actually an interesting patch I look forward to:
16:15 egonw_ an ChemObjectBuilderFactory which will use class loading to instantiate a builder instance
16:15 egonw_ I think that's possible now...
16:15 maclean *Aquires immediate headache*
16:15 maclean :)
16:16 egonw_ yeah, it does sounds like a patch for me to write, doesn't it...
16:16 maclean "ChemObjectBuilderFactory". I _think_ I understand that.
16:16 egonw_ the use case is very simple:
16:16 egonw_ parser = new SmilesParser()
16:16 maclean Not necessarily :) I was toying with making an AnimatingChemObjectBuilder the other day.
16:17 egonw_ then this constructor would internally load a suitable loader that is available on the classpath
16:17 egonw_ yeah, and I was talking today with Daniel Lowe (OPSIN) about a CMLChemObjectBuilder
16:17 egonw_ which uses CML elements internally only :)
16:18 egonw_ though I'd also love a RDFChemObjectBuilder, that acts on a remote triple store
16:19 maclean Hmmm. Those could be good.
16:19 egonw_ actually... Mark might even be interested in a OracleChemObjectBuilder :)
16:20 maclean Heh.
16:21 egonw__ joined #cdk
16:21 egonw__ as well as being able to only implement a subset of interfaces...
16:21 egonw__ another serious application, is just speeding up the CDK...
16:21 egonw__ being able to just copy/paste the data module, start hacking and see where it speeds up things is just convenient
16:21 egonw__ is now known as egonw
16:22 maclean True. Adjacency-lists vs Adjacency-matrices for bonds, for example.
16:22 egonw yes, good thinking
16:23 egonw but at the same time, abstractions lead to more complexity
16:23 egonw not appreciated by everyone
16:24 egonw__ joined #cdk
16:24 maclean Yeah, I got the comment "Why does the CDK have so many of these interface things?" from someone the other day :)
16:24 egonw__ grmph
16:24 egonw__ stupid unstable wireless
16:24 egonw__ :)
16:25 egonw_ left #cdk
16:27 egonw_ joined #cdk
16:27 egonw left #cdk
16:28 egonw joined #cdk
16:28 egonw yeah, well, most computer scientists say it is a good thing...
16:28 egonw what chemist would I be to complain
16:29 egonw__ left #cdk
16:29 egonw anyway... for the CDK... it did illustrate many bugs otherwise hidden in the code
16:29 maclean That's good.
16:29 egonw so, as a chemist, I can't really complain about the interface pattern either
16:31 sneumann_ left #cdk
16:31 egonw_ left #cdk
16:34 maclean g2g
16:34 maclean left #cdk
16:35 egonw same here
16:39 egonw left #cdk
17:54 egonw joined #cdk
19:13 jbrefort joined #cdk
21:13 CIA-48 cdk: Rajarshi Guha cdk-1.4.x * rcb4335e / (4 files in 4 dirs):
21:13 CIA-48 cdk: Updated OrderQueryBond in SMARTS & isomorphism matching so that we correctly match when faced with aromatic bonds (rather than just looking at the bond order)
21:13 CIA-48 cdk: Signed-off-by: Egon Willighagen <egonw@users.sourceforge.net> - http://bit.ly/eMhmtX
21:30 egonw left #cdk
21:42 jbrefort left #cdk

| Channels | #cdk index | Today | | Search | Google Search | Plain-Text | summary