Camelia, the Perl 6 bug

IRC log for #cdk, 2010-12-16

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

All times shown according to UTC.

Time Nick Message
04:44 azeem_ joined #cdk
04:46 sneumann_ joined #cdk
04:48 azeem left #cdk
07:37 sneumann_ left #cdk
08:00 Gpox joined #cdk
08:37 sneumann_ joined #cdk
09:09 jbrefort joined #cdk
09:55 egonw joined #cdk
12:16 jbrefort left #cdk
12:48 sneumann_ why on earth is   <atom id="Xx"> part of http://bodr.svn.sourceforge.net/vie​wvc/bodr/trunk/bodr/elements/elemen​ts.xml?revision=57&amp;view=markup
12:48 sneumann_ ?
12:49 zarah sneumann_'s link is also http://tinyurl.com/274ns5m
12:50 sneumann_ <label dictRef="bo:name" xml:lang="en" value="Dummy" />
13:03 egonw git blame?
13:04 egonw I guess because some file formats have those defined as element names...
13:04 sneumann_ So it's not there on purpose ?
13:04 egonw but I think we can do better now
13:04 sneumann_ Should I file a bugreport ?
13:04 egonw oh, i think it is there on purpose
13:04 sneumann_ is now known as sneumann
13:04 egonw best to send an email to the mailing list to discuss it
13:05 sneumann Hm, I am not subscribed ...
13:05 sneumann Can I send you, and you forward it ?
13:05 sneumann or is it moderated, and it will be moderated ?
13:06 sneumann or is it moderated, and it will be let through eventually ?
13:13 egonw I can approve
13:13 sneumann will do
13:20 sneumann bodr has no mailing list ?
13:21 sneumann will use tracker, then
13:21 egonw for bodr we just use the blue obelisk one
13:21 sneumann blueobelisk-discuss@lists.sourceforge.net.
13:21 sneumann thx
13:28 sneumann left #cdk
14:34 markr joined #cdk
14:37 egonw hej markr
14:37 markr ha
14:37 markr I can't see who's online
14:37 egonw ben zo terug
14:37 markr must be my crappy client
14:37 markr check
14:40 egonw back
14:41 markr waar zit de huidige afhankelijkheid tussen data en isomorphism precies? ik zit een beetje in de classes te grutten
14:42 markr ah
14:42 markr OrderQueryBond extends org.openscience.cdk.Bond
14:42 egonw precies
14:42 markr dat wil je dus niet?
14:42 egonw nee, dat moet weg
14:43 egonw that is possible too, because OrderQueryBond.getBuilder() is not used anyway
14:43 egonw and if, there would be a solution for that...
14:44 markr I'm missing some javadoc here
14:44 markr OrderQueryBond .. OrderQueryBondOrderOnly
14:44 markr what are they for anyway
14:44 egonw these are basically Java copies of particular queries
14:45 egonw the latter class is used to match thw query bond to the ibond based only on bond order
14:45 egonw but not on aromaticity (I guess...)
14:45 egonw I'm booting Eclipse
14:46 markr Hm.. so if you want to get rid of the 'data' dependency, you have to copy over both Atom and Bond into isomorphism..
14:47 markr and AtomContainer
14:48 markr sorry recap: why is it bad that isomorphism depends on data? As long as it's not the other way around
14:50 egonw because we want to be able to plug in alternative (faster, smaller-sized) implementations
14:50 egonw btw, for the MDL*Readers we do not have have to worry about isomorphism, I think
14:51 egonw IQueryBond is in the interfaces module already, and io does not depend on isomorphism, or does it now?
14:51 egonw checking
14:52 egonw yeah, it does right now...
14:52 egonw I think I remember why...
14:52 egonw someone made a patch that made it...
14:52 egonw wondering who that was :)
14:53 markr ha was that for the beatutiful R-groups?
14:53 egonw sorry, git is begin a bit slow today
14:53 egonw git show af8e566a
14:54 egonw yes, "RGroup queries"
14:54 egonw this might be a good time to 'fix' that...
14:55 markr so RGroup readers/writers would have to go into the isomorphism module?
14:56 egonw that was one option, I think, we considered at the time...
14:56 egonw but I'm fine if it depends on isomorphism
14:56 egonw if the latter does not depend on data
14:56 egonw I think I can do that...
14:58 egonw OK, there are basically two interfaces we need to implement: IQueryAtom and IQueryBond
14:58 egonw shall we split work?
14:58 egonw I do IQueryAtom, your IQueryBond?
14:58 s_wolf left #cdk
14:59 egonw adding an abstract class QueryAtom
14:59 markr are they basically just copies?
15:02 egonw yes, that's the plan
15:03 markr So IQueryBond a copy of IBond and QueryBond a copy of Bond
15:03 markr I'll start cut/pasting
15:03 egonw IQyerBond already exists
15:03 egonw but, yes on the secnod part
15:04 markr QueryBond implements IBond and IQueryBond then?
15:04 egonw just implements IQueryBond
15:04 egonw as IQueryBond extends IBond
15:05 markr .. it doesn't right now. Though IQueryAtom extends IAtom
15:07 egonw indeed!
15:07 egonw weird...
15:24 markr I sent you a patch just now
15:24 egonw received
15:25 egonw markr: can you set your git email config var?
15:25 markr ah
15:25 markr uh
15:25 egonw and add copyright/license statement to QueryBond
15:26 markr lemmesee
15:29 markr Sent again
15:30 markr I need to be off for a quick chat with someone
15:30 egonw ok
15:55 egonw markr: ah... query bond implementeerd nog niet all methoden...
15:55 egonw e.g. setID()
15:55 egonw try; public class OrderQueryBond extends QueryBond implements IQueryBond
16:03 markr daar was ik weer
16:03 markr hm
16:03 egonw ok, I misplaced QueryAtom...
16:03 egonw fixed that now...
16:03 egonw will merge those two patches...
16:03 markr IQueryBond extends IBond, IBond has     public IAtom[] getConnectedAtoms(IAtom atom);
16:04 markr But I thought we wanted public IAtom[] getConnectedAtoms(IQueryAtom atom);
16:04 markr But I thought we wanted public IQueryAtom[] getConnectedAtoms(IQueryAtom atom);
16:05 markr That why there are errors on public class OrderQueryBond extends QueryBond implements IQueryBond
16:06 markr I suppose I should let QueryBond use IAtom and not IQueryAtom
16:06 markr will fix that
16:07 egonw I guess that would be nice, but I think the APIs will then conflict
16:07 jbrefort joined #cdk
16:08 egonw markr: btw, my QueryAtom is also missing methods...
16:13 markr missing methods go up to ElectronContainer -> ChemObject
16:13 markr More copy/paste necessary
16:16 egonw indeed :)
16:17 egonw I guess we should have an AbstractQueryObject for the common stuff from ChemObject for QueryAtom and QueryBond
16:17 egonw if you have not copied that yet, I will set that up
16:17 egonw then QueryBond extends QueryChemObject
16:18 markr yes, makes sense, go ahead
16:26 egonw email sent
16:27 egonw markr: agreed on your reply
16:27 egonw SMARTS is at the IO level
16:27 egonw and still needs an impll
16:27 egonw and SMARTS is parsed into IQueryAtom things too
16:34 markr yup
16:34 markr got the patch for QueryChemObject, works, thanks
16:36 egonw I am now updating FooQueryAtom implemetnations to extend QueryAtom instead of Atom
16:38 markr okay, patch sent
16:38 markr this should do for the query bonds
16:38 markr but
16:38 markr I gotta go now, it's starting to snow here
16:38 egonw yes
16:38 egonw understood
16:38 markr to be cont!
16:39 egonw I'll continue refactoring the code for anohter hour
16:39 egonw and will then meet Nico in the pub :)
16:39 egonw (if he makes it in time :)
16:39 markr enjoy
16:39 markr it's a shame that the price for module independency is so much copy/paste
16:39 egonw yes, it is at this moment
16:40 markr luckily it's hidden away deep in a smarts package ;)
16:40 egonw we will be able to clean that up later too...
16:40 markr ooh
16:40 markr howsthat?
16:40 egonw the classes will become simpler in time... more bean like
16:40 egonw and in particular my half finished listener patch will do a lot
16:41 egonw making classes much smaller
16:41 egonw also
16:41 markr cool
16:41 egonw with the new builder, we can make data class subsets...
16:41 egonw e.g. a subset just around IAtomContainer
16:41 egonw (or IMolecule)
16:41 egonw but without all the rest
16:42 egonw if we then make IAtomContainer sub 10k size, we can have a core implementation perhaps
16:42 egonw which is really just bean like
16:42 egonw no listening
16:42 egonw no debugging, etc
16:42 egonw then that functionality can be add on
16:42 egonw while preserving a mean, lean, and clean core
16:43 markr good plan
16:43 markr but still - wouldn't prevent the copy/paste we did today or would it?
16:43 egonw not completely
16:43 markr unless something like Bond goes into the core
16:44 markr okay gotta go
16:44 egonw ok, cu
16:44 markr thanks for the coding!
16:44 markr left #cdk
17:32 slyrus left #cdk
17:37 jbrefort left #cdk
17:44 egonw cool, it compiles!
17:45 egonw isomorphism without dependencies on data!
17:51 egonw left #cdk
18:41 sneumann joined #cdk
19:12 jbrefort joined #cdk
20:54 CIA-121 cdk: Egon Willighagen cdk-1.4.x * r00b15a6 / (src/META-INF/core.datafiles src/META-INF/standard.datafiles): Moved packaging of the PeriodicTable data to the new model too - http://bit.ly/gJVQip
21:07 egonw joined #cdk
21:50 stain_ left #cdk
21:50 jbrefort left #cdk
21:50 azeem_ left #cdk
21:50 alchimiste left #cdk
21:50 egonw left #cdk
21:50 Conrad left #cdk
21:51 zarah left #cdk
21:51 sneumann_ joined #cdk
21:51 sneumann left #cdk
21:52 azeem joined #cdk
21:58 egonw joined #cdk
21:58 alchimiste joined #cdk
21:58 zarah joined #cdk
21:58 Conrad joined #cdk
21:58 stain_ joined #cdk
22:01 CIA-121 cdk: Egon Willighagen cdk-1.4.x * r3c057c4 / src/main/org/openscience/cdk/Atom.java : Restored the previous behavior of a zero default charge, fixing very many unit tests - http://bit.ly/hIPgmK
22:10 sneumann_ left #cdk
22:51 egonw left #cdk
22:51 Gpox left #cdk

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