Camelia, the Perl 6 bug

IRC log for #cdk, 2010-08-03

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

All times shown according to UTC.

Time Nick Message
03:11 azeem_ joined #cdk
05:09 egonw__ joined #cdk
05:43 sneumann_ joined #cdk
05:49 bag_ joined #cdk
05:49 egonw joined #cdk
05:51 jbrefort joined #cdk
07:02 sneumann_ joined #cdk
07:50 egonw joined #cdk
07:56 maclean joined #cdk
08:09 egonw joined #cdk
08:37 maclean joined #cdk
08:56 s9asad joined #cdk
09:02 maclean joined #cdk
09:22 egonw joined #cdk
09:23 egonw moin
09:24 egonw_ joined #cdk
09:32 s9asad Hi everyone
09:35 s9asad @maclean, could you please review the SMSD patch and sent your initial report to egon/rajarshi and me. This would be big help to all of us as I believe both the reviewers have alot to handle.
09:37 maclean s9asad: sure, will do
09:37 s9asad thankx
10:04 egonw_ joined #cdk
10:10 egonw__ joined #cdk
11:31 maclean joined #cdk
13:36 s9asad joined #cdk
13:40 egonw s9asad: is the smsd.jar depending on CDK code?
13:40 s9asad hi egonw
13:41 s9asad yes it does
13:41 egonw so, if someone starts changing an API that SMSD depends on, this person will never notive that it breaks the SMSD functionality...
13:42 egonw that does not sound like a smart idea...
13:42 egonw I thought we discussed this and concluded that the source code had to remain in the CDK, and that you were going to put a Java application wrapper as separate project?
13:42 egonw that's what I at least concluded from the discussion...
13:45 egonw I don't quite get why we spent so much energy on integrating the source code, to just remove it now
13:46 s9asad a) SMSD version should be depended on the CDK version. Refactoring the code classes will hamper the functionality but .depends will highlight this.
13:46 s9asad b) Regarding the code
13:47 s9asad I have no problem if you want the whole code inside the CDK, I was more worried about the comment that "Users are confused as they don't get to know where to start to use the SMSD"
13:47 maclean Well, my 2 cents would be that there are 3 possibilities
13:48 s9asad SMSD code is free and I have reservations in putting it into CDK, in-fact I am happy but
13:48 s9asad ......
13:48 maclean a) The original plan (embed SMSD in CDK)
13:49 maclean b) The large patch (remove all but a shim class)
13:49 maclean c) Refactor so that SMSD does not depend on the CDK, and have a CDK-specific implementation as classes in CDK.
13:50 maclean The last possibility is (in my opinion only) the best, but will require some work.
13:50 s9asad I am happy to go for any plan if a) it creates least confusion for the users b) I need some support for refactoring :-)
13:51 maclean It may not actually be possible, I suppose, but I would have thought that graph matching/MCS/etc could be done independently of the toolkit.
13:51 maclean The way it has been done with the signatures did create some fragile baseclass problems, but there may be other ways.
13:53 maclean I think that the work that was done to get the 'embeded' design to work was worthwhile, as it made necessary tests, docs, or fixes - but it could just be a stepping stone to a better way to do it.
13:53 s9asad I think SMSD uses some basic functions from the CDK....I am open to suggestions
13:54 s9asad ".. fixes - but it could just be a stepping stone to a better way to do it..." Agree
13:54 maclean Well, I'm going to try making a sketch of the architecture, to see where the connection points are with CDK classes (like IAtomContainer)
13:54 s9asad Thanks, would be great
13:55 maclean And think about what kind of refactoring would make the two projects more separable.
14:01 s9asad brb
14:31 s_wolf hello
14:32 maclean hello
14:32 s_wolf i have a question regarding the smsd substructure search
14:32 egonw s9asad: a lot of user confusion is removed, if you wrote a good tutorial on how to use it
14:32 s_wolf i just tried it and it is working perfectly
14:32 egonw how to perform the common SMSD use cases
14:33 s_wolf does Algorithm.SubStructure deliver every matching substructure?
14:34 s_wolf because in my case it returns only one matching structure but there is another substructure which is matching
14:35 s9asad @s_wolf : in the present algorithm Algorithm.SubStructure return first hit
14:35 s_wolf when I exchange Algorithm.SubStructure with Algorithm.Default two matches are returned as I expected
14:35 s_wolf ah ok
14:35 s9asad if you like more hits you can look for Algorithm.DEFAULT
14:37 s9asad @@member:s_wolf : the new patch which I have submitted reports all the matches
14:37 s_wolf thanks :)
14:37 s9asad you can clone it from git://github.com/asad/cdk.git
14:38 s9asad no worries :-)
14:41 egonw s9asad: so, what's the current status then? how do you want to proceed?
14:43 egonw personally, I would like to keep the source code in the CDK
14:43 egonw so that API changes will not break SMSD...
14:43 egonw I don't like the solution of a jar depending on the CDK on which the CDK depends again...
14:43 egonw that is asking for trouble
14:44 egonw and we have trouble enough already
14:44 maclean http://gilleain.tumblr.com/post/898227531
14:44 maclean http://gilleain.tumblr.com/post/898231159
14:45 maclean (package diagram, and a few class interactions).
14:45 maclean unfortunately, unreadable due to tumblr being rubbish.
14:46 egonw not that bad here
14:46 maclean maybe you have better eyesight than me :)
14:47 maclean Initial suggestions are that AbstractMCS and AbstractMCSAlgorithm are abstract classes with only abstract methods, so they could easily be interfaces instead.
14:49 maclean Also I will say that nearly every class imports a cdk class, so refactoring that away will not be trivial...
14:50 egonw so, I would say there are two options: 1) part as the CDK with source code 2) a 100% independent thing
14:50 egonw the first has the advantage of more people looking at the code, like CDK developers
14:50 egonw and basically what the CDK developers have been doing so far
14:51 egonw 2) would give Asad full control
14:56 maclean Control of code is important, but also the sheer size of the CDK concerns me sometimes.
14:56 maclean I remember the philosophical disagreements over adding the many CDK plugins to bioclipse :)
14:57 maclean But, also, at some point the project may become too large to maintain properly.
14:57 maclean Whereas a kind of 'ecosystem' of related cdk-like projects might work just as well, but be smaller.
14:59 s9asad Both ideas have pros and corn. If SMSD provides a good user base for the CDK then I think I can put the code inside the CDK but I should have rights to make changes and mark it
14:59 egonw you have those rights
15:00 egonw just like everyone else
15:00 egonw please elaborate on this, please
15:00 egonw I am not sure I understand your point
15:00 egonw that is, your argument with "but I should have rights to make changes and mark it"
15:01 s9asad I mean if I make changes in the code at my end, if takes more time to get into the CDK, and I land up have two versions. If I have right to commit the changes in the SMSD (with out braking the CDK) then it easier. I like and appreciate review process but not as a bootle neck
15:02 egonw ok, then inclusion into the CDK is currently not your thing
15:02 egonw we all have our code reviewed
15:02 egonw and we all have to wait until that is done
15:02 egonw the process is longer, but the library is much more stable and more accurate
15:03 egonw less breaking of things, less failing unit tests...
15:03 s9asad indeed review is very good and its very good process but there has go be a way for the core developers to commit the changes and then seek the approval of reviewers are busy.
15:03 egonw we are just short on code reviewers...
15:04 egonw it's mostly done by Rajarshi and me...
15:04 egonw and rarely by other developers
15:04 s9asad hmmm
15:04 egonw s9asad: when did you last review a patch?
15:04 egonw check that a patch is compiling, not introducing regressions, has JavaDoc, unit tests, etc
15:04 s9asad I don't remember ay assigned to me. The one I got for SMSD I already did it and committed it
15:05 egonw s9asad: anyone can review patches
15:05 egonw you do not wait for getting assigned
15:05 egonw there is a tracker, and you review those patches you find interesting
15:05 egonw or the oldest, or whatever
15:05 egonw you review, test them, and report your comments
15:06 egonw you do not have to restrict yourself to reviewing patches for your code
15:06 s9asad I am would be happy to do more
15:06 * maclean did start to review some patches on sunday, but got distracted designing a patch-reviewing GUI that page-scraped sourceforge...
15:06 egonw maclean++
15:06 egonw sounds pretty useful
15:07 maclean It would be great - it would make a git branch for each, run the appropriate module tests, and let you signoff :)
15:07 maclean But designing it it didn't get any patches reviewed :(
15:07 s9asad I did a git import of jcp
15:07 s9asad but I don't know who to keep it syc with the SVN branch
15:08 s9asad http://github.com/asad/jcp
15:09 s9asad any suggestion to keep it auto updated with the SF repos of the JCP
15:18 egonw for the jcp branch, you need to talk to Mark Rijnbeek
15:33 s9asad left #cdk
15:40 s9asad joined #cdk
18:44 bag_ joined #cdk
21:01 s9asad joined #cdk
21:30 egonw joined #cdk

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