From charles.parnot at stanford.edu Thu Feb 3 20:03:18 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 3 Feb 2005 17:03:18 -0800 Subject: [Biococoa-dev] BCSequence init methods Message-ID: Hi all! I commited last night (Pacific time...) the code with the new class 'BCAbstractSequence', the superclass, and changed the subclass header accordingly, and all the methods names etc.. in the framework (like I said before). In the process of writing the implementation for the BCSequence one-for-all placeholder class, I spent some time looking at the init and factory methods of the whole BCAbstractSequence class tree. I had a few questions, comments and/or suggestions: * I believe some of the factory methods in the subclasses are redundant; I am talking about the '+dnaSequenceWithString:' and equivalents; normally, defining a '+sequenceWithString' in the superclass is enough, because the type of the returned object is defined by the class used for the call, e.g. BCSequenceDNA *dna=[BCSequenceDna sequenceWithString:@"ATCGGGT"]; BCSequenceProtein *prot=[BCSequenceProtein sequenceWithString:@"AOCOCOIB"]; It would make the interface cleaner and more consistent, and reduce the amount of code by factoring it out to the superclass. * There is this concept of 'skippingNonBases' in the BCSequenceDNA, which could indeed be useful; but this could actually be useful for all the subclasses, proteins as well as DNA (the rationale is to handle pasting from output where there are numbers, spaces and other non-relevant characters); so I thought we could maybe put the code in the superclass and use something more generic like 'skippingUndefinedSymbols' (if you have a better shorter name, I'll take it); again, more consistent interface and more shared code in the superclass * I still don't know what to do with '-initWithSequence:' if the target and the argument are different sequence types; should we return an empty sequence unless they are the same type?; should we translate?; the latter might seem logical, but this innocent method name would then be hiding quite an important feature... I propose we drop that method (and +sequenceWithSequence), and let the user with 'copy', and then come up with a better name for a method that would do the tranformation of one sequence type into another. I put at the end of the email what I would propose as init and factory methods for the different subclasses. There are not many changes from the current status, in fact. I put some comments to indicate which methods will really need to be implemented in the subclass (well, the code is already done, anyway). This little 'cleaning' would be nice before we add the annotations stuff, what do you think? One more random thought: We probably don't need annotations in the init methods (or at least we can live without for a while). We would just need to set the ivar to nil at init and then alloc it at the first '-addAnnotation:'. Let me know what you think! Charles NB: I think Alex is still away, so I will wait also for his input... // ------------------ // BCAbstractSequence // ------------------ //designated initializer //override in subclasses - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; //another initializer //(that does not call the designated initializer) //(or should this one be the designated initializer?) //override in subclasses - (id)initWithSymbolArray:(NSArray *)anArray; //Call the designated initializer //do not override in the subclasses - (id)initWithString:(NSString *)aString; - (id)initWithString:(NSString *)aString range:(NSRange)aRange skippingUnknownSymbols:(BOOL)skipFlag; //Factory methods that call the init methods //do not override in the subclasses + (BCAbstractSequence *) sequenceWithString:(NSString *)aString; + (BCAbstractSequence *) sequenceWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; + (BCAbstractSequence *) sequenceWithString:(NSString *)aString range:(NSRange)aRange skippingUnknownSymbols:(BOOL)skipFlag; + (BCAbstractSequence *) sequenceWithSymbolArray: (NSArray *)entry; //Call the designated initializer //do not override in subclasses //(these methods are a bit dangerous when using 2 different subclasses // probably better to forget that for now // and come up with a better name that clearly implies translation // may have to occur for the method to make sense) - (id)initWithSequence:(BCAbstractSequence *)entry; + (BCAbstractSequence *)sequenceWithSequence:(BCAbstractSequence *)entry; // ---------- // BCSequence // ---------- // placeholder subclass //methods to override - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; - (id)initWithSymbolArray:(NSArray *)anArray; //new methods - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; usingType:(BCSequenceType) type; + (BCSequence *)sequenceWithString:(NSString *)string skippingUnknownSymbols:(BOOL)skipFlag; usingType:(BCSequenceType) type; - (BCSequenceType)sequenceTypeForUntypedString:(NSString *)string; //automatically inherited methods - (id)initWithString:(NSString *)aString; - (id)initWithString:(NSString *)aString range:(NSRange)aRange skippingUnknownSymbols:(BOOL)skipFlag; +(BCAbstractSequence *)sequenceWithString:(NSString *)string; +(BCAbstractSequence *)sequenceWithString:(NSString *)string skippingUnknownSymbols:(BOOL)skipFlag; +(BCAbstractSequence *)sequenceWithString:(NSString *)string range:(NSRange)aRange skippingUnknownSymbols:(BOOL)skipFlag; +(BCAbstractSequence *)sequenceWithSymbolArray: (NSArray *)entry; - (id)initWithSequence:(BCAbstractSequence *)entry; + (BCAbstractSequence *)sequenceWithSequence:(BCAbstractSequence *)entry; // ------------ // BCSequenceDNA / ------------ //methods to override - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; - (id)initWithSymbolArray:(NSArray *)anArray; //automatically inherited methods //...same as above... // ------------ // BCSequenceRNA // ------------ //methods to override - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; - (id)initWithSymbolArray:(NSArray *)anArray; //new methods - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag convertingThymidines:(BOOL)convertFlag; + (BCSequenceRNA *)rnaSequenceWithString:(NSString *)string skippingUnknownSymbols:(BOOL)skipFlag; convertingThymidines:(BOOL)convertFlag; //automatically inherited methods //...same as above... // --------------- // BCSequenceCodon // --------------- //methods to override - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; - (id)initWithSymbolArray:(NSArray *)anArray; //new methods - (id)initWithCodonArray:(NSArray *)anArray geneticCode:(BCGeneticCodeName)codeType frame:(NSString *)theFrame; - (BCSequenceCodon *)codonSequenceWithCodonArray:(NSArray *)anArray geneticCode:(BCGeneticCodeName)codeType frame:(NSString *)theFrame; //automatically inherited methods //...same as above... // ------------ // BCSequenceProtein // ------------ //methods to override - (id)initWithString:(NSString *)aString skippingUnknownSymbols:(BOOL)skipFlag; - (id)initWithSymbolArray:(NSArray *)anArray; //automatically inherited methods //...same as above... -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Thu Feb 3 20:53:06 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 3 Feb 2005 20:53:06 -0500 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: References: Message-ID: <014fc4ab2ba7d28b52b5d78f6065b9d8@earthlink.net> Hi Charles, Just noticed the new additions. However, BCAbstractSequence does not show up in my project. Make sure you also commit the project.pbxproj file in Xcode. To do this, click on the triangle next to 'SCM' in the left panel of the main window of Xcode. Then right click on project.pbxproj and select cmmit changes. Hopefully that will take care of it. > * I believe some of the factory methods in the subclasses are > redundant; I am talking about the '+dnaSequenceWithString:' and > equivalents; normally, defining a '+sequenceWithString' in the > superclass is enough, because the type of the returned object is > defined by the class used for the call, e.g. > > BCSequenceDNA *dna=[BCSequenceDna sequenceWithString:@"ATCGGGT"]; > BCSequenceProtein *prot=[BCSequenceProtein > sequenceWithString:@"AOCOCOIB"]; > > It would make the interface cleaner and more consistent, and reduce > the amount of code by factoring it out to the superclass. Sounds good to me. So as far as I am concerned, please go ahead and make the changes. > > * There is this concept of 'skippingNonBases' in the BCSequenceDNA, > which could indeed be useful; but this could actually be useful for > all the subclasses, proteins as well as DNA (the rationale is to > handle pasting from output where there are numbers, spaces and other > non-relevant characters); so I thought we could maybe put the code in > the superclass and use something more generic like > 'skippingUndefinedSymbols' (if you have a better shorter name, I'll > take it); again, more consistent interface and more shared code in the > superclass Again, I like the idea of shared code where possible, so this seems to me also a good idea. I don;t have an alternative for skippingUndefinedSymbols rijt now, but it says what it does, so why not leave it. This is also very related to my idea of finally implementing the BCSymbolSet, similar to alphabets in BioPerl and BioJava. I might have some time this weekend to finally implement this :-) > > * I still don't know what to do with '-initWithSequence:' if the > target and the argument are different sequence types; should we return > an empty sequence unless they are the same type?; should we > translate?; the latter might seem logical, but this innocent method > name would then be hiding quite an important feature... I propose we > drop that method (and +sequenceWithSequence), and let the user with > 'copy', and then come up with a better name for a method that would do > the tranformation of one sequence type into another. Not sure yet what to do in this situation. I would not do a translation or something else, because that would make the method unpredictable. I suggest to comment out both methods for the meantime. For transformation and translation we should use a class in the BCTools hierarchy. > > I put at the end of the email what I would propose as init and factory > methods for the different subclasses. There are not many changes from > the current status, in fact. I put some comments to indicate which > methods will really need to be implemented in the subclass (well, the > code is already done, anyway). This little 'cleaning' would be nice > before we add the annotations stuff, what do you think? I am not sure what you want to propose. > > One more random thought: We probably don't need annotations in the > init methods (or at least we can live without for a while). We would > just need to set the ivar to nil at init and then alloc it at the > first '-addAnnotation:'. Yep :) - Koen. From charles.parnot at stanford.edu Fri Feb 4 01:35:47 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 3 Feb 2005 22:35:47 -0800 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: <014fc4ab2ba7d28b52b5d78f6065b9d8@earthlink.net> References: <014fc4ab2ba7d28b52b5d78f6065b9d8@earthlink.net> Message-ID: >Hi Charles, > >Just noticed the new additions. However, BCAbstractSequence does not show up in my project. Make sure you also commit the project.pbxproj file in Xcode. To do this, click on the triangle next to 'SCM' in the left panel of the main window of Xcode. Then right click on project.pbxproj and select cmmit changes. Hopefully that will take care of it. I had done that already, and redid it just now after doing some fake modifs to the project. Let's see if that works for you. Let me know! >Again, I like the idea of shared code where possible, so this seems to me also a good idea. I don;t have an alternative for skippingUndefinedSymbols rijt now, but it says what it does, so why not leave it. This is also very related to my idea of finally implementing the BCSymbolSet, similar to alphabets in BioPerl and BioJava. I might have some time this weekend to finally implement this :-) I thought BCSymbolSet was already done. I can't wait to see what else it can be used for... >Not sure yet what to do in this situation. I would not do a translation or something else, because that would make the method unpredictable. I suggest to comment out both methods for the meantime. For transformation and translation we should use a class in the BCTools hierarchy. Yes, exactly. Actually, we also have to come up with a name for transforming a type of sequence into another (translation being a particular case), like 'transformation' or something better (?) >>I put at the end of the email what I would propose as init and factory methods for the different subclasses. There are not many changes from the current status, in fact. I put some comments to indicate which methods will really need to be implemented in the subclass (well, the code is already done, anyway). This little 'cleaning' would be nice before we add the annotations stuff, what do you think? > >I am not sure what you want to propose. I am not proposing anything more than the 3 points raised above. I am not even proposing anything about annotations. > >> >>One more random thought: We probably don't need annotations in the init methods (or at least we can live without for a while). We would just need to set the ivar to nil at init and then alloc it at the first '-addAnnotation:'. > >Yep :) Oups, just remembered the immutable/mutable issue :-) Thanks for your input, I will do all of that... soon... charles -- Charles Parnot charles.parnot at stanford.edu Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Fri Feb 4 02:10:45 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 4 Feb 2005 02:10:45 -0500 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: References: <014fc4ab2ba7d28b52b5d78f6065b9d8@earthlink.net> Message-ID: <502ed2e0a0257dea16ba0d31fac640df@earthlink.net> On Feb 4, 2005, at 1:35 AM, Charles PARNOT wrote: >> Hi Charles, >> >> Just noticed the new additions. However, BCAbstractSequence does not >> show up in my project. Make sure you also commit the project.pbxproj >> file in Xcode. To do this, click on the triangle next to 'SCM' in the >> left panel of the main window of Xcode. Then right click on >> project.pbxproj and select cmmit changes. Hopefully that will take >> care of it. > > I had done that already, and redid it just now after doing some fake > modifs to the project. Let's see if that works for you. Let me know! No, still don't see it. However, I do see it in the CVS window. I'll try a fresh checkout tomorrow. - Koen. From j.j.blow at dundee.ac.uk Fri Feb 4 09:02:15 2005 From: j.j.blow at dundee.ac.uk (Julian Blow) Date: Fri, 4 Feb 2005 14:02:15 +0000 Subject: [Biococoa-dev] hello! In-Reply-To: <9b532f78b55ac1836102277afd7eab2b@earthlink.net> References: <9b532f78b55ac1836102277afd7eab2b@earthlink.net> Message-ID: Dear Biococoa-dev Subscribers, just a quick word to let you know I've added myself to the mailing list as suggested by Koen. I'll keep an eye on what's going on, and will contribute if and when I think I can add something. Regards, Julian >Dear Julian, > >Thanks for your reply. Too bad you don't have enough time right now >to join the development of BioCocoa - I completely understand it >though, all current developers work on BioCocoa on the side. So >either solution you suggested works fine for me. An alternative >could be for you to for now only join the mailing list. This way you >get an idea of the current developments in the project, and you can >jump in in case there is a subject that is in your field. But it is >completely up to you. > >Regards, > >- Koen. > > > >On Jan 31, 2005, at 7:28 AM, Julian Blow wrote: > >>Dear Koen >> >>I've had a look at what you're up to, and I think it sounds very >>worthwhile. I'd be keen to support and help your project if I >>could. However, I don't think I'd be much help in doing coding at >>present. The main problem is that programming is only a sideline >>for me (it has to be squeezed into my 'spare time' either late at >>night or early in the morning) and most of my energy is directed to >>running my lab. I already have two major software projects I'm >>committed to at present; I guess these will take up most of my >>coding time for the next 6 months at least. >> >>So what should I do? I'm happy to join if it would help you, but I >>really would not be active, at least not until I've finished my >>other projects. Alternatively, I could leave you my goodwill, and >>you could contact me should you need anything you think I could >>specifically help with, or I could contact you when my current >>projects are done and I have coding time on my hands. >> >>Regards, >> >>Julian >> >>>Dear Julian, >>> >>>I found your name on the CocoaDev mailing list. I am one of the >>>core developers of the BioCocoa project, an open source Cocoa >>>framework for reading, writing, and manipulating various >>>biological sequences. Originally the framework only focused on >>>reading and writing sequences, and was also aimed at GNUStep, >>>which is still the official version that you can download from the >>>website at http://bioinformatics.org/biococoa/. A few months ago a >>>couple of mac loving bioscientists joined the project, and it was >>>transformed in a Cocoa-only framework, and extended to be able to >>>do other things with sequences than reading and writing. You could >>>say that it is trying to be the Cocoa/ObjC sibling of BioJava, >>>BioPerl, etc. >>> >>>So far we have created a set of new classes, that we believe >>>should be a solid base for extending the whole framework. However, >>>we still have many discussions what would be the best design. For >>>instance, currently we have a core class BCSequence, with various >>>subclasses for DNA, RNA, and proteins. We have had many >>>discussions whether we actually should subclass BCSequence >>>(compare eg BioJava which doesn't subclass it's main sequence >>>class). As an alternative, recently we have been discussing if >>>maybe we should use the class cluster design for the various >>>sequence classes, >>> >>>At the moment we are only a small group of developers, mainly with >>>a scientific background. Based on the description on the CocoaDev >>>webpage, it seems you could be a valuable addition to the BioCocoa >>>project. So we were wondering if you would be interested in >>>joining the development team, and the discussions on our mailing >>>list (see http://bioinformatics.org/project/?group_id=318 for more >>>info). To download the source code from CVS, please follow these >>>instructions: >>> >>>* First, log in by typing the following. When prompted for the >>>password, just press Enter. >>> >>>cvs -d:pserver:anonymous at bioinformatics.org:/cvsroot login >>> >>>* Then, type the following to download the project: >>> >>>cvs -d:pserver:anonymous at bioinformatics.org:/cvsroot checkout -P BioCocoa >>> >>> >>> >>>Feel free to have a look at the code and the current discussions, >>>and let me or one of the other developers know if you are >>>interested. We look forward to your reply, >>> >>> >>>On behalf of the BioCocoa Team, >>> >>>Best regards, >>> >>>Koen van der Drift >> -- Prof. J. Julian Blow, FRSE Cancer Research UK Chromosome Replication Research Group Wellcome Trust Biocentre, University of Dundee Dow Street, Dundee DD1 5EH, Scotland, UK Tel: (+44) (0)1382-345797 Fax: (+44) (0)1382-348072 E-mail: j.j.blow at dundee.ac.uk http://www.dundee.ac.uk/biocentre/ From charles.parnot at stanford.edu Fri Feb 4 16:19:57 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 4 Feb 2005 13:19:57 -0800 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: <502ed2e0a0257dea16ba0d31fac640df@earthlink.net> References: <014fc4ab2ba7d28b52b5d78f6065b9d8@earthlink.net> <502ed2e0a0257dea16ba0d31fac640df@earthlink.net> Message-ID: At 2:10 -0500 2/4/05, Koen van der Drift wrote: >On Feb 4, 2005, at 1:35 AM, Charles PARNOT wrote: > >>>Hi Charles, >>> >>>Just noticed the new additions. However, BCAbstractSequence does not show up in my project. Make sure you also commit the project.pbxproj file in Xcode. To do this, click on the triangle next to 'SCM' in the left panel of the main window of Xcode. Then right click on project.pbxproj and select cmmit changes. Hopefully that will take care of it. >> >>I had done that already, and redid it just now after doing some fake modifs to the project. Let's see if that works for you. Let me know! > > >No, still don't see it. However, I do see it in the CVS window. I'll try a fresh checkout tomorrow. > >- Koen. Maybe you have also a modified version of the project, and Xcode does not know how to merge, so keep your version and does not update to the current version on cvs. If the file is showing in the cvs window (you meant the scm window in Xcode, right), then it means it is either modified or to-be-updated, I would think. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Fri Feb 4 16:21:58 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 4 Feb 2005 13:21:58 -0800 Subject: [Biococoa-dev] hello! In-Reply-To: References: <9b532f78b55ac1836102277afd7eab2b@earthlink.net> Message-ID: >Dear Biococoa-dev Subscribers, > >just a quick word to let you know I've added myself to the mailing list as suggested by Koen. I'll keep an eye on what's going on, and will contribute if and when I think I can add something. > >Regards, > >Julian > Hi Julian, and welcome! I also joined recently, and so far, I like it here :-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Fri Feb 4 18:08:21 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 4 Feb 2005 18:08:21 -0500 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: References: <014fc4ab2ba7d28b52b5d78f6065b9d8@earthlink.net> <502ed2e0a0257dea16ba0d31fac640df@earthlink.net> Message-ID: On Feb 4, 2005, at 4:19 PM, Charles PARNOT wrote: > Maybe you have also a modified version of the project, and Xcode does > not know how to merge, so keep your version and does not update to the > current version on cvs. If the file is showing in the cvs window (you > meant the scm window in Xcode, right), then it means it is either > modified or to-be-updated, I would think. > Yes, I think that was the problem. I now have all your new code in my project. I'll have a closer look at it later tonight. BTW, are you 'didou' ? - Koen. From kvddrift at earthlink.net Sat Feb 5 08:07:27 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 5 Feb 2005 08:07:27 -0500 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: References: Message-ID: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Charles, A first comment/question about your new code. I compiled the Translation demo, and now get a few warnings such as these: Examples/Translation/theController.m:71: warning: passing arg 1 of `translateDNASequence:usingGeneticCode:' from incompatible pointer type I understand why I get these, because I am just using BCSequence, instead of one of its subclasses. If put in typecasts, the warnings go away. So for instance NSArray *translation = [BCToolTranslatorDNA translateDNASequence: theSequence usingGeneticCode: BCUniversalCodeDNA]; Will not give a warning when changed to: NSArray *translation = [BCToolTranslatorDNA translateDNASequence: (BCSequenceDNA*) theSequence usingGeneticCode: BCUniversalCodeDNA]; However, I thought that one of the benefits of the class cluster approach would be that we can just use BCSequence transparantly without having to worry about which subclass we are dealing with. Maybe I still don't understand your approach, could you comment on this? cheers, - Koen. From mek at mekentosj.com Sat Feb 5 09:54:49 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 5 Feb 2005 15:54:49 +0100 Subject: [Biococoa-dev] BioCocoa.framework path In-Reply-To: <35302DC6-6CC1-11D9-8B33-003065A5FDCC@earthlink.net> References: <35302DC6-6CC1-11D9-8B33-003065A5FDCC@earthlink.net> Message-ID: > And then there was silence... ;-) Yep, deep silence. Hi guys, I've been back from skiing for a week now but haven't been able to pick up my normal routines yet. What I didn't tell you thus-far is that since the beginning of this year I've got stuck in quite some heavy weather privately. To summarize everything in one Cocoa-like sentence, two days before new year's eve my girlfriend told me she wanted to release me as she had instantiated a new boyfriend. Given the fact that our relationship was in my eyes perfect for the past 8 years and this came as a complete surprise to me, you can imagine the blow. I still feel completely crap and this will probably last a bit longer I'm afraid. The skiing holiday was perfect, but unfortunately once home again it's "welcome to the real word" again. I'm trying hard to get my life back on the line a bit, so yes I'll try to get involved again in the project, still got a few emails to reply ;-) We'll just have to see how thing evolve... Cheers, Alex ************************************************************** ** Alexander Griekspoor ** ************************************************************** The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From mek at mekentosj.com Sat Feb 5 10:11:28 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 5 Feb 2005 16:11:28 +0100 Subject: [Biococoa-dev] BCSymbolList replacement In-Reply-To: <9b16c8d2b8afff9b8800873cfe65eca3@earthlink.net> References: <9b16c8d2b8afff9b8800873cfe65eca3@earthlink.net> Message-ID: <35C21A84-7788-11D9-AFC4-000D93AE89A4@mekentosj.com> >> Before commiting, I just wanted to check one last time, because I had >> to modify ~30 classes to replace the 'symbolList' namings with >> 'sequence', also in method names (several 'Find and Replace' were >> necessary). The compilation is fine and everything seems to work OK. >> I don't know if you want to add a tag before such major refactoring >> (this is probably ~ the same as when you added the BCSymbolList, >> Koen?). > > Actually, I didn't tag it (don't know how to do that with Xcode :). > Alex did another reorganization a while ago, so you might want to > check with him what would be the easiest procedure. However, since we > all agree on this change (I hope we still do after we see what you did > to the code ;-), I would say just commit it. It's in CVS, so we always > can revert certain changes. Yes, I did the last major cvs dance, as especially the directory hierarchy was changed I decided to clear the whole thing and upload it completely from scratch. This erases all comments though, which wasn't so much of a problem back then, but should be avoided wherever possible. If there are only files to update just use xcode or cvs by hand. What do you mean with major refactoring tag? Start a new branch or bump the major version number? Checkout the manual on how to do this, guess that can only be done from the command line... > >> I suppose such major refactoring is bound to happen at early stages >> of a project, and are a good thing? :-) Better save than sorry indeed that's my point of view as well... These are called startup troubles ;-) > > BioJava is currently in the progress of a complete rewrite. I am glad > I'm not in that project! Same here!! Cheers, Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com 4Peaks - For Peaks, Four Peaks. 2004 Winner of the Apple Design Awards Best Mac OS X Student Product http://www.mekentosj.com/4peaks ********************************************************* From mek at mekentosj.com Sat Feb 5 10:17:12 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 5 Feb 2005 16:17:12 +0100 Subject: [Biococoa-dev] hello! In-Reply-To: References: <9b532f78b55ac1836102277afd7eab2b@earthlink.net> Message-ID: <02E9EB97-7789-11D9-AFC4-000D93AE89A4@mekentosj.com> Hi Julian, You're very welcome! Great to have you listen along, don't hesitate to ask for any introduction or clarification if you need it. Cheers, Alex On 4-feb-05, at 15:02, Julian Blow wrote: > Dear Biococoa-dev Subscribers, > > just a quick word to let you know I've added myself to the mailing > list as suggested by Koen. I'll keep an eye on what's going on, and > will contribute if and when I think I can add something. > > Regards, > > Julian > > >> Dear Julian, >> >> Thanks for your reply. Too bad you don't have enough time right now >> to join the development of BioCocoa - I completely understand it >> though, all current developers work on BioCocoa on the side. So >> either solution you suggested works fine for me. An alternative could >> be for you to for now only join the mailing list. This way you get an >> idea of the current developments in the project, and you can jump in >> in case there is a subject that is in your field. But it is >> completely up to you. >> >> Regards, >> >> - Koen. >> >> >> >> On Jan 31, 2005, at 7:28 AM, Julian Blow wrote: >> >>> Dear Koen >>> >>> I've had a look at what you're up to, and I think it sounds very >>> worthwhile. I'd be keen to support and help your project if I could. >>> However, I don't think I'd be much help in doing coding at present. >>> The main problem is that programming is only a sideline for me (it >>> has to be squeezed into my 'spare time' either late at night or >>> early in the morning) and most of my energy is directed to running >>> my lab. I already have two major software projects I'm committed to >>> at present; I guess these will take up most of my coding time for >>> the next 6 months at least. >>> >>> So what should I do? I'm happy to join if it would help you, but I >>> really would not be active, at least not until I've finished my >>> other projects. Alternatively, I could leave you my goodwill, and >>> you could contact me should you need anything you think I could >>> specifically help with, or I could contact you when my current >>> projects are done and I have coding time on my hands. >>> >>> Regards, >>> >>> Julian >>> >>>> Dear Julian, >>>> >>>> I found your name on the CocoaDev mailing list. I am one of the >>>> core developers of the BioCocoa project, an open source Cocoa >>>> framework for reading, writing, and manipulating various biological >>>> sequences. Originally the framework only focused on reading and >>>> writing sequences, and was also aimed at GNUStep, which is still >>>> the official version that you can download from the website at >>>> http://bioinformatics.org/biococoa/. A few months ago a couple of >>>> mac loving bioscientists joined the project, and it was transformed >>>> in a Cocoa-only framework, and extended to be able to do other >>>> things with sequences than reading and writing. You could say that >>>> it is trying to be the Cocoa/ObjC sibling of BioJava, BioPerl, etc. >>>> >>>> So far we have created a set of new classes, that we believe should >>>> be a solid base for extending the whole framework. However, we >>>> still have many discussions what would be the best design. For >>>> instance, currently we have a core class BCSequence, with various >>>> subclasses for DNA, RNA, and proteins. We have had many discussions >>>> whether we actually should subclass BCSequence (compare eg BioJava >>>> which doesn't subclass it's main sequence class). As an >>>> alternative, recently we have been discussing if maybe we should >>>> use the class cluster design for the various sequence classes, >>>> >>>> At the moment we are only a small group of developers, mainly with >>>> a scientific background. Based on the description on the CocoaDev >>>> webpage, it seems you could be a valuable addition to the BioCocoa >>>> project. So we were wondering if you would be interested in joining >>>> the development team, and the discussions on our mailing list (see >>>> http://bioinformatics.org/project/?group_id=318 for more info). To >>>> download the source code from CVS, please follow these >>>> instructions: >>>> >>>> * First, log in by typing the following. When prompted for the >>>> password, just press Enter. >>>> >>>> cvs -d:pserver:anonymous at bioinformatics.org:/cvsroot login >>>> >>>> * Then, type the following to download the project: >>>> >>>> cvs -d:pserver:anonymous at bioinformatics.org:/cvsroot checkout -P >>>> BioCocoa >>>> >>>> >>>> >>>> Feel free to have a look at the code and the current discussions, >>>> and let me or one of the other developers know if you are >>>> interested. We look forward to your reply, >>>> >>>> >>>> On behalf of the BioCocoa Team, >>>> >>>> Best regards, >>>> >>>> Koen van der Drift >>> > > -- > Prof. J. Julian Blow, FRSE > Cancer Research UK Chromosome Replication Research Group > Wellcome Trust Biocentre, University of Dundee > Dow Street, Dundee DD1 5EH, Scotland, UK > Tel: (+44) (0)1382-345797 Fax: (+44) (0)1382-348072 > E-mail: j.j.blow at dundee.ac.uk > http://www.dundee.ac.uk/biocentre/ > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From kvddrift at earthlink.net Sat Feb 5 16:37:13 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 5 Feb 2005 16:37:13 -0500 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Message-ID: <59062b85be4e2690bcc473141f664b62@earthlink.net> On Feb 5, 2005, at 8:07 AM, Koen van der Drift wrote: > However, I thought that one of the benefits of the class cluster > approach would be that we can just use BCSequence transparantly > without having to worry about which subclass we are dealing with. > Maybe I still don't understand your approach, could you comment on > this? > OK, I think I know why this happens. In this case: BCSequence *theProtein = [[BCSequenceFactory sharedSequenceFactory] sequenceWithString: aString]; the BCSequenceFactory actually returns a BCAbstractSequence object, not a BCSequence, so that will cause the warning. In the other case: NSArray *translation = [BCToolTranslatorDNA translateDNASequence: theSequence usingGeneticCode: BCUniversalCodeDNA]; [BCToolTranslatorDNA translateDNASequence:] is expecting a BCSequenceDNA instead of a BCAbstractSequence. That one is easily fixed, and I will commit that. But I am not sure how to fix the first warning. If there is no objection, I will also make BCToolTranslatorDNA work like the other BCTool subclasses, using the initWithSequence, doSomethingWithSequence pattern. - Koen. From charles.parnot at stanford.edu Sun Feb 6 01:09:38 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 5 Feb 2005 22:09:38 -0800 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Message-ID: At 8:07 AM -0500 2/5/05, Koen van der Drift wrote: >Charles, > >A first comment/question about your new code. I compiled the Translation demo, and now get a few warnings such as these: > >Examples/Translation/theController.m:71: warning: passing arg 1 of `translateDNASequence:usingGeneticCode:' from incompatible pointer type Sorry about that, I forgot to check the compilation of the examples (actually, I suspected at some point there would be some issues, and probably this is why I subconciously (?) forgot to check at the end). >I understand why I get these, because I am just using BCSequence, instead of one of its subclasses. If put in typecasts, the warnings go away. So for instance > >NSArray *translation = [BCToolTranslatorDNA translateDNASequence: theSequence usingGeneticCode: BCUniversalCodeDNA]; > >Will not give a warning when changed to: > >NSArray *translation = [BCToolTranslatorDNA translateDNASequence: (BCSequenceDNA*) theSequence usingGeneticCode: BCUniversalCodeDNA]; > > >However, I thought that one of the benefits of the class cluster approach would be that we can just use BCSequence transparantly without having to worry about which subclass we are dealing with. Maybe I still don't understand your approach, could you comment on this? > >cheers, > >- Koen. At 4:37 PM -0500 2/5/05, Koen van der Drift wrote: ><...snip...>In the other case: > >NSArray *translation = [BCToolTranslatorDNA translateDNASequence: theSequence usingGeneticCode: BCUniversalCodeDNA]; > >[BCToolTranslatorDNA translateDNASequence:] is expecting a BCSequenceDNA instead of a BCAbstractSequence. That one is easily fixed, and I will commit that. This is an important point to understand about the tools, which I mentioned briefly during last month's discussion. For some of the tools, we will have to define 2 methods, depending on the type of sequence we pass. This is the only way you can have both strong and weak typing: - (NSArray *)translateSequence:(BCSequence *)theSequence usingGeneticCode: BCUniversalCodeDNA - (NSArray *)translateDNASequence:(BCSequenceDNA *)theSequence usingGeneticCode:code; Note that he implementation would be trivial for the BCSequence version. However, duplicate methods are really necessary only if the tool is public, if we let the framework user access it directly. On the conrary, if the tool is private and 'hidden' in the BCSequence interface, then there is no need to duplicate method names. The BCSequence can be used transparently only when dealing with methods in the sequence classes. Let me explain with the translation example.There could be a method 'translatedSequenceUsingGeneticCode:', only relevant for BCSequenceDNA, which would have the following implementation in the different sequence classes: * Interface of BCAbstractSequence and non-relevant subclasses: the method is not declared (you get compiler warnings) * BUT implementation in BCAbstractSequence: the method exists and returns an empty array; this will also be the default behavior for non-relevant subclasses; thus, even though the method is not declared, it is implemented and will not fail at runtime if called on a non-relevant subclass (this is crucial for BCSequence behavior, see below) * BCSequenceDNA: the method 'translatedSequenceUsingGeneticCode:' is declared in the header; in the implementation, it overrides the superclass, and this is really that subclass that uses the private tool; * BCSequence interface: the method is declared (hence no compiler warning) * BCSequence implementation: does not implement anything... but it is never instantiated! Real instances created thru BCSequence are one of the other subclasses; all the subclass will return something, either through the superclass implementation (empty array), or something relevant if the instance happens to really be a BCSequenceDNA; so BCSequence will behave properly at runtime too. This may be a bit complex to understand at first you just have to go through all the different cases to see what happens. But the implementation itself is simple. The bottom line is that it may be easier to make the simplest tools private, so we don't have to declare more methods. These tools would then be hidden in the BCSequence implementation, and only available through their interface. In the case of translation, this is clearly the way to go. Using a tool makes thing more convoluted. Note that BCSequence is not yet ready for prime-time yet. I need to add the code... charles NB: another email coming about the other compiler warning with the factory class. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Sun Feb 6 01:44:03 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 5 Feb 2005 22:44:03 -0800 Subject: [Biococoa-dev] Compilation warning with the factory class In-Reply-To: <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Message-ID: At 4:37 PM -0500 2/5/05, Koen van der Drift wrote: >...... > >OK, I think I know why this happens. In this case: > >BCSequence *theProtein = [[BCSequenceFactory sharedSequenceFactory] sequenceWithString: aString]; > >the BCSequenceFactory actually returns a BCAbstractSequence object, not a BCSequence, so that will cause the warning. > >.... But I am not sure how to fix the <...> warning. This is actually partly a flaw of the 'factory class' design when dealing with several subclasses. The only solution is to have the method in the factory declared as follows: +(id) sequenceWithString:aString; When you use factory methods in the sequence classes, the problem goes away. The code in the translation example could simply be: ... BCSequence *theProtein = [BCSequence sequenceWithString: aString]; ... And then you should have the following for the sequence classes: @interface BCAbstractSequence : NSObject { } + (BCAbstractSequence *) sequenceWithString: (NSString *)aString; @end @implementation BCAbstractSequence + (BCAbstractSequence *) sequenceWithString: (NSString *)aString; { return [[[[self class] alloc] initWithString:aString] autorelease]; } @end @interface BCSequence : BCAbstractSequence { } + (BCSequence *) sequenceWithString: (NSString *)aString; @end @implementation BCAbstractSequence + (BCSequence *)sequenceWithString:(NSString *)aString; { return (BCSequence *)[super sequenceWithString:aString]; } @end + similar stuff in the other subclasses. But this is not the only option. For a moment, consider NSArray and NSMutableArray. This is the same situation faced by the factory method 'array'. Both classes respond to '+array', and the method will return an NSArray or a NSMutableArray. Apple chose another route by declaring '-(id)array' only in the superclass NSArary, so that it does not need to be declared again in the subclass NSMutableArray. In our case, this would be even more efficient as this would reduce the code in not just one subclass, but 5. The only problem is you can then write things like this without compiler warnings: NSDictionary *dic=[NSArray array]; //try that, it is funny! BCSequenceDNA *seq=[BCSequenceProtein sequenceWithString:aString]; I would be actually probably more inclined to use the (id) return value, because there is then less code, and also because this is what NextStep and Apple decided to do... What would be your choice? A final note: this does not mean we should not use BCSequenceFactory, but that it could remain private. Another option, which I personaly think is better, is to have the BCSequenceFactory code in the BCSequence implementation, which will not have anything else anyway. Indeed, the only job of the BCSequence placeholder class is to determine which sequence type should be used and then return the right instance types. What do you think, Koen? can't wait to read you, guys! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Sun Feb 6 10:04:45 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 6 Feb 2005 10:04:45 -0500 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Message-ID: Charles, Thanks for the explanation. Right now I am nursing a slight hangover from last nights Mardi Gras / Carnaval party ("laissez les bonnes temps roulez"), so correct if me I am say something stupid :) >> NSArray *translation = [BCToolTranslatorDNA translateDNASequence: >> theSequence usingGeneticCode: BCUniversalCodeDNA]; >> >> [BCToolTranslatorDNA translateDNASequence:] is expecting a >> BCSequenceDNA instead of a BCAbstractSequence. That one is easily >> fixed, and I will commit that. > > This is an important point to understand about the tools, which I > mentioned briefly during last month's discussion. For some of the > tools, we will have to define 2 methods, depending on the type of > sequence we pass. This is the only way you can have both strong and > weak typing: > - (NSArray *)translateSequence:(BCSequence *)theSequence > usingGeneticCode: BCUniversalCodeDNA > - (NSArray *)translateDNASequence:(BCSequenceDNA *)theSequence > usingGeneticCode:code; I don't understand why there have to be two methods, instead of one general like this: -(NSArray *) translateSequence: (BCSequence *)sequence usingGeneticCode: code > > > Note that he implementation would be trivial for the BCSequence > version. > > However, duplicate methods are really necessary only if the tool is > public, if we let the framework user access it directly. On the > conrary, if the tool is private and 'hidden' in the BCSequence > interface, then there is no need to duplicate method names. The > BCSequence can be used transparently only when dealing with methods in > the sequence classes. > > Let me explain with the translation example.There could be a method > 'translatedSequenceUsingGeneticCode:', only relevant for > BCSequenceDNA, which would have the following implementation in the > different sequence classes: > * Interface of BCAbstractSequence and non-relevant subclasses: the > method is not declared (you get compiler warnings) > * BUT implementation in BCAbstractSequence: the method exists and > returns an empty array; this will also be the default behavior for > non-relevant subclasses; thus, even though the method is not declared, > it is implemented and will not fail at runtime if called on a > non-relevant subclass (this is crucial for BCSequence behavior, see > below) > * BCSequenceDNA: the method 'translatedSequenceUsingGeneticCode:' > is declared in the header; in the implementation, it overrides the > superclass, and this is really that subclass that uses the private > tool; > * BCSequence interface: the method is declared (hence no compiler > warning) > * BCSequence implementation: does not implement anything... but it is > never instantiated! Real instances created thru BCSequence are one of > the other subclasses; all the subclass will return something, either > through the superclass implementation (empty array), or something > relevant if the instance happens to really be a BCSequenceDNA; so > BCSequence will behave properly at runtime too. > > This may be a bit complex to understand at first you just have to go > through all the different cases to see what happens. But the > implementation itself is simple. > > The bottom line is that it may be easier to make the simplest tools > private, so we don't have to declare more methods. These tools would > then be hidden in the BCSequence implementation, and only available > through their interface. In the case of translation, this is clearly > the way to go. Using a tool makes thing more convoluted. > I still believe that we should keep the BCSequence class et al as clean as possible, and put all the manipulations in a separate class. The way I see it to use the tools classes is as follows: myTool = [BCSequenceToolFoo toolFooWithSequence: BCSequence]; [myTool setParameter1: param1]; [myTool setParameter:2 param2]; result = [myTool doSomethingWithSequence]; This way we keep the framework modular, and don't clog BCSequence with code that works for some classes in one case, and other classes in another case. It will also be more confusing for the user when some methods are in BCSequence, other ones are in a separate BCSequenceTool subclass. However, we can alsways have convenience methods in the BCSequence classes to the BCSequenceTool classes that takes care of some very general situations. If the user needs some more special manipulations (s)he can always use the approach as I sketched above. Also making some tools private and others not is confusing, so we should stick with one approach, I think. cheers, - Koen. From kvddrift at earthlink.net Sun Feb 6 10:07:45 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 6 Feb 2005 10:07:45 -0500 Subject: [Biococoa-dev] Compilation warning with the factory class In-Reply-To: References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Message-ID: On Feb 6, 2005, at 1:44 AM, Charles PARNOT wrote: > I would be actually probably more inclined to use the (id) return > value, because there is then less code, and also because this is what > NextStep and Apple decided to do... What would be your choice? > > A final note: this does not mean we should not use BCSequenceFactory, > but that it could remain private. Another option, which I personaly > think is better, is to have the BCSequenceFactory code in the > BCSequence implementation, which will not have anything else anyway. > Indeed, the only job of the BCSequence placeholder class is to > determine which sequence type should be used and then return the right > instance types. What do you think, Koen? > I think it is a good idea to have BCSequence now take care of the code that is currently in BCSequenceFactory. Now we have the class cluster, there is probably no need anymore for a BCSequenceFactory class. - Koen. From charles.parnot at stanford.edu Mon Feb 7 20:05:44 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 7 Feb 2005 17:05:44 -0800 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Message-ID: >I don't understand why there have to be two methods, instead of one general like this: > >-(NSArray *) translateSequence: (BCSequence *)sequence usingGeneticCode: code This works fine if you only use BCSequence and never relies on the other sequence classes. But if you use a BCSequenceDNA on the above method, you get a compiler warning. Just to let the possibility for strong typing. e.g. if John wants to enforce the use of a BCSequenceDNA for that method, then we need a separate method with the BCSequenceDNA typing. An alternative is to use the BCAbstractSequence type and have only one method. But then it would also accept BCSequenceProtein, etc... An alternative is to define a 'BCSequenceDNA' protocol, that both BCSequence and BCSequenceDNA would follow. I am not a big fan of protocols, but that may be a nice use of them. Importantly, the user would not have to worry about the protocol. Bottom line: it might be best to have both methods. The 'generic' one would test for the sequence type, and return an empty array if non-relevant type, or call the method for BCSequenceDNA if the sequence is indeed of that type. >I still believe that we should keep the BCSequence class et al as clean as possible, and put all the manipulations in a separate class. The way I see it to use the tools classes is as follows: > >myTool = [BCSequenceToolFoo toolFooWithSequence: BCSequence]; > >[myTool setParameter1: param1]; >[myTool setParameter:2 param2]; > >result = [myTool doSomethingWithSequence]; > >This way we keep the framework modular, and don't clog BCSequence with code that works for some classes in one case, and other classes in another case. It will also be more confusing for the user when some methods are in BCSequence, other ones are in a separate BCSequenceTool subclass. However, we can alsways have convenience methods in the BCSequence classes to the BCSequenceTool classes that takes care of some very general situations. If the user needs some more special manipulations (s)he can always use the approach as I sketched above. Also making some tools private and others not is confusing, so we should stick with one approach, I think. > I completely agree that there should only be one approach, so no tool should be private. I was foolish to imagine the other possibility... Now, what do you think of this other 'rule': to NOT have a convenience method both in the tool (+translateSequence:usingGeneticCode:) AND in the BCSequence (-translatedSequenceUsingGeneticCode:), but only in the BCSequence? I am not completely sure about all this and we may have to see how it works out in the long term... charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Mon Feb 7 22:52:06 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 7 Feb 2005 22:52:06 -0500 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> Message-ID: <776f77beaac1f031ef687b9b9b296b4b@earthlink.net> On Feb 7, 2005, at 8:05 PM, Charles PARNOT wrote: >> I don't understand why there have to be two methods, instead of one >> general like this: >> >> -(NSArray *) translateSequence: (BCSequence *)sequence >> usingGeneticCode: code > > This works fine if you only use BCSequence and never relies on the > other sequence classes. But if you use a BCSequenceDNA on the above > method, you get a compiler warning. > > Just to let the possibility for strong typing. e.g. if John wants to > enforce the use of a BCSequenceDNA for that method, then we need a > separate method with the BCSequenceDNA typing. An alternative is to > use the BCAbstractSequence type and have only one method. But then it > would also accept BCSequenceProtein, etc... > > An alternative is to define a 'BCSequenceDNA' protocol, that both > BCSequence and BCSequenceDNA would follow. I am not a big fan of > protocols, but that may be a nice use of them. Importantly, the user > would not have to worry about the protocol. > > Bottom line: it might be best to have both methods. The 'generic' one > would test for the sequence type, and return an empty array if > non-relevant type, or call the method for BCSequenceDNA if the > sequence is indeed of that type. Or have one weak typed method as I suggested in a previous post, and test for the type in that method. Then either return an empty or useful array. > > >> I still believe that we should keep the BCSequence class et al as >> clean as possible, and put all the manipulations in a separate class. >> The way I see it to use the tools classes is as follows: >> >> myTool = [BCSequenceToolFoo toolFooWithSequence: BCSequence]; >> >> [myTool setParameter1: param1]; >> [myTool setParameter:2 param2]; >> >> result = [myTool doSomethingWithSequence]; >> >> This way we keep the framework modular, and don't clog BCSequence >> with code that works for some classes in one case, and other classes >> in another case. It will also be more confusing for the user when >> some methods are in BCSequence, other ones are in a separate >> BCSequenceTool subclass. However, we can alsways have convenience >> methods in the BCSequence classes to the BCSequenceTool classes that >> takes care of some very general situations. If the user needs some >> more special manipulations (s)he can always use the approach as I >> sketched above. Also making some tools private and others not is >> confusing, so we should stick with one approach, I think. >> > > I completely agree that there should only be one approach, so no tool > should be private. I was foolish to imagine the other possibility... > Now, what do you think of this other 'rule': to NOT have a convenience > method both in the tool (+translateSequence:usingGeneticCode:) AND in > the BCSequence (-translatedSequenceUsingGeneticCode:), but only in the > BCSequence? I am not completely sure about all this and we may have to > see how it works out in the long term... > That seems like a reasonable 'rule'. I don't see any problems when the convenience method is only in BCSequence. - Koen. From charles.parnot at stanford.edu Tue Feb 8 02:16:43 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 7 Feb 2005 23:16:43 -0800 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: <776f77beaac1f031ef687b9b9b296b4b@earthlink.net> References: <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <59062b85be4e2690bcc473141f664b62@earthlink.net> <3f3b883fbadab5a09efe92be75b5c5ea@earthlink.net> <776f77beaac1f031ef687b9b9b296b4b@earthlink.net> Message-ID: At 10:52 PM -0500 2/7/05, Koen van der Drift wrote: >On Feb 7, 2005, at 8:05 PM, Charles PARNOT wrote: >>...... An alternative is to use the BCAbstractSequence type and have only one method.... > >Or have one weak typed method as I suggested in a previous post, and test for the type in that method. Then either return an empty or useful array. So, you mean 'BCAbstractSequence', right? I am completely OK with that! (I just wanted to make sure that whatever we choose will please everybody). >>I completely agree that there should only be one approach, so no tool should be private. I was foolish to imagine the other possibility... Now, what do you think of this other 'rule': to NOT have a convenience method both in the tool (+translateSequence:usingGeneticCode:) AND in the BCSequence (-translatedSequenceUsingGeneticCode:), but only in the BCSequence? I am not completely sure about all this and we may have to see how it works out in the long term... >That seems like a reasonable 'rule'. I don't see any problems when the convenience method is only in BCSequence. I forgot to mention the reason I mentioned such 'rule' is to avoid having 2 convenience methods in the tool, one with BCSequence and one with BCSequenceDNA. But if we just go with BCAbstractSequence, then it does not matter so much. Anyway, let's just use BCAbstractSequence for now, like you say, and we could always come back to it in the future if we think it is a limitation. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 8 02:20:03 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 7 Feb 2005 23:20:03 -0800 Subject: [Biococoa-dev] Compilation warnings with tools Message-ID: (sorry, Koen, for the duplicate email) At 10:52 PM -0500 2/7/05, Koen van der Drift wrote: >On Feb 7, 2005, at 8:05 PM, Charles PARNOT wrote: >>...... An alternative is to use the BCAbstractSequence type and have only one method.... > >Or have one weak typed method as I suggested in a previous post, and test for the type in that method. Then either return an empty or useful array. So, you mean 'BCAbstractSequence', right? I am completely OK with that! (I just wanted to make sure that whatever we choose will please everybody). >>I completely agree that there should only be one approach, so no tool should be private. I was foolish to imagine the other possibility... Now, what do you think of this other 'rule': to NOT have a convenience method both in the tool (+translateSequence:usingGeneticCode:) AND in the BCSequence (-translatedSequenceUsingGeneticCode:), but only in the BCSequence? I am not completely sure about all this and we may have to see how it works out in the long term... >That seems like a reasonable 'rule'. I don't see any problems when the convenience method is only in BCSequence. I forgot to mention the reason I mentioned such 'rule' is to avoid having 2 convenience methods in the tool, one for argument BCSequence and one for argument BCSequenceDNA. But if we just go with BCAbstractSequence, then it does not matter so much. Anyway, let's just use BCAbstractSequence for now, like you say, and we could always come back to it in the future if we think it is a limitation. Sorry, I have been making too much of a big deal out of that non-issue;-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From jtimmer at bellatlantic.net Tue Feb 8 08:06:42 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 08 Feb 2005 08:06:42 -0500 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: Message-ID: >>> ...... An alternative is to use the BCAbstractSequence type and have >>> only one method.... >> >> Or have one weak typed method as I suggested in a previous post, and test for >> the type in that method. Then either return an empty or useful array. > > So, you mean 'BCAbstractSequence', right? > I am completely OK with that! (I just wanted to make sure that whatever we > choose will please everybody). Sorry, have to chime in here - I'm not! I thought the idea here was that the convenience methods, which would be present only in classes that actually should use that method, would be strictly typed. That way, anybody as uptight as I am can be using strict classes and have access to methods with strict signatures in them. JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Tue Feb 8 10:55:13 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 08 Feb 2005 10:55:13 -0500 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: Message-ID: > >>>> ...... An alternative is to use the BCAbstractSequence type and have >>>> only one method.... >>> >>> Or have one weak typed method as I suggested in a previous post, and test >>> for >>> the type in that method. Then either return an empty or useful array. >> >> So, you mean 'BCAbstractSequence', right? >> I am completely OK with that! (I just wanted to make sure that whatever we >> choose will please everybody). > > Sorry, have to chime in here - I'm not! I thought the idea here was that > the convenience methods, which would be present only in classes that > actually should use that method, would be strictly typed. That way, anybody > as uptight as I am can be using strict classes and have access to methods > with strict signatures in them. Just an aside here - I'm assuming that since we aren't getting rid of the subclasses, then it's probably worth my putting in a BCSequenceNucleotide to hold a bunch of the convenience methods that will be common to the DNA and RNA classes? I should also explicitly state that, as I want the convenience methods, I'll put them in. One thing that would help here is if the tools headers were well commented - last I looked, some of them were and some weren't. This may have changed, but I need to run Tiger for a while to get a project moving, and I don't want to risk incompatibilities by accessing CVS from that environment. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Tue Feb 8 19:51:17 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 8 Feb 2005 19:51:17 -0500 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: References: Message-ID: <48b7ce2e036582fb72bd517426c6e783@earthlink.net> On Feb 8, 2005, at 10:55 AM, John Timmer wrote: >> >>>>> ...... An alternative is to use the BCAbstractSequence type >>>>> and have >>>>> only one method.... >>>> >>>> Or have one weak typed method as I suggested in a previous post, >>>> and test >>>> for >>>> the type in that method. Then either return an empty or useful >>>> array. >>> >>> So, you mean 'BCAbstractSequence', right? >>> I am completely OK with that! (I just wanted to make sure that >>> whatever we >>> choose will please everybody). >> >> Sorry, have to chime in here - I'm not! I thought the idea here was >> that >> the convenience methods, which would be present only in classes that >> actually should use that method, would be strictly typed. That way, >> anybody >> as uptight as I am can be using strict classes and have access to >> methods >> with strict signatures in them. As long as the use of strong typing remains in the convenience method, that that sounds fine to me too. What I mean is, that the use of strong tying should remain hidden from the user - he should only have to deal with BCSequence. > > Just an aside here - I'm assuming that since we aren't getting rid of > the > subclasses, then it's probably worth my putting in a > BCSequenceNucleotide to > hold a bunch of the convenience methods that will be common to the DNA > and > RNA classes? > > I should also explicitly state that, as I want the convenience > methods, I'll > put them in. One thing that would help here is if the tools headers > were > well commented - last I looked, some of them were and some weren't. > This > may have changed, but I need to run Tiger for a while to get a project > moving, and I don't want to risk incompatibilities by accessing CVS > from > that environment. I guess that would be my bad. Which classes in particular are you referring to? - Koen. From charles.parnot at stanford.edu Tue Feb 8 20:09:20 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 8 Feb 2005 17:09:20 -0800 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: <48b7ce2e036582fb72bd517426c6e783@earthlink.net> References: <48b7ce2e036582fb72bd517426c6e783@earthlink.net> Message-ID: Charles: >So, you mean 'BCAbstractSequence', right? >I am completely OK with that! (I just wanted to make sure that whatever we >choose will please everybody). John: >Sorry, have to chime in here - I'm not! I thought the idea here was that >the convenience methods, which would be present only in classes that >actually should use that method, would be strictly typed. That way, anybody >as uptight as I am can be using strict classes and have access to methods >with strict signatures in them. Koen: >As long as the use of strong typing remains in the convenience method, that that sounds fine to me too. What I mean is, that the use of strong tying should remain hidden from the user - he should only have to deal with BCSequence. The reason why I was insisting on having the two methods in the public header, is that we all agreed that we should keep BOTH weakly and strongly typed sequence classes public, as John is reminding us... In terms of implementation, the code required to achieve that for the sequence classes is minimal (through the placeholder class; BTW, technically not a cluster class). However, for the tools, me will have a little more code to put. I was actually surprised that John did not step in earlier ;-) So my proposition was to have two methods, eg: - (BCSequence *)translateSequence:(BCSequence *)aSequence; - (BCSequenceDNA *)translateDNASequence:(BCSequenceDNA *)aSequence; (the implementation for the one with BCSequence will be trivial. Note also that even with only the BCSequence method, the amount of code will remain the same: the sequence type checking). The other options is to have a protocol that is followed by bothe BCSequence and BCSequenceDNA, and only one method: - (id )translateDNASequence:(id )aSequence; but I am not a big fan of it. To answer your question, yes, John, a BCNucleotideSequence class will be useful :-) I am almost done with the 'cleaning' of the init methods of the sequence class. Can you wait before changing code in the existing classes, but you can already have the BCSequeceNucleotide added. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Tue Feb 8 20:40:03 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 8 Feb 2005 20:40:03 -0500 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: References: <48b7ce2e036582fb72bd517426c6e783@earthlink.net> Message-ID: <8cd430cd6ab6fcdb263176bd8894bfaa@earthlink.net> On Feb 8, 2005, at 8:09 PM, Charles PARNOT wrote: > I was actually surprised that John did not step in earlier ;-) > > So my proposition was to have two methods, eg: > - (BCSequence *)translateSequence:(BCSequence *)aSequence; > - (BCSequenceDNA *)translateDNASequence:(BCSequenceDNA *)aSequence; > Oh, now I see what you mean. So the first method will check the type, and then call the second one or return nil (or whatever). In that case my 'fix' in BCToolTranslatorDNA can be reverted. I'll leave that up to you Charles, so seem to be better knowing what you are doing ;-) - Koen. From charles.parnot at stanford.edu Wed Feb 9 03:06:27 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 9 Feb 2005 00:06:27 -0800 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: References: Message-ID: Another framework-wide commit tonight, with what is described in my previous email (see below). I am very happy with the result. you get exactly the same functionality as before, but with much less code. I also corrected some weird mistakes in the BCSequenceCodon init methods. Next task is to finally get BCSequence up and running. At that point, I will check the code of the examples to fully comply. And then, later, I want to discuss the BCSeqenceCodon design. Get ready for some long emails ;-) charles At 5:03 PM -0800 2/3/05, Charles PARNOT wrote: >Hi all! > >I commited last night (Pacific time...) the code with the new class 'BCAbstractSequence', the superclass, and changed the subclass header accordingly, and all the methods names etc.. in the framework (like I said before). > >In the process of writing the implementation for the BCSequence one-for-all placeholder class, I spent some time looking at the init and factory methods of the whole BCAbstractSequence class tree. I had a few questions, comments and/or suggestions: > >* I believe some of the factory methods in the subclasses are redundant; I am talking about the '+dnaSequenceWithString:' and equivalents; normally, defining a '+sequenceWithString' in the superclass is enough, because the type of the returned object is defined by the class used for the call, e.g. > > BCSequenceDNA *dna=[BCSequenceDna sequenceWithString:@"ATCGGGT"]; > BCSequenceProtein *prot=[BCSequenceProtein sequenceWithString:@"AOCOCOIB"]; > > It would make the interface cleaner and more consistent, and reduce the amount of code by factoring it out to the superclass. > >* There is this concept of 'skippingNonBases' in the BCSequenceDNA, which could indeed be useful; but this could actually be useful for all the subclasses, proteins as well as DNA (the rationale is to handle pasting from output where there are numbers, spaces and other non-relevant characters); so I thought we could maybe put the code in the superclass and use something more generic like 'skippingUndefinedSymbols' (if you have a better shorter name, I'll take it); again, more consistent interface and more shared code in the superclass > >* I still don't know what to do with '-initWithSequence:' if the target and the argument are different sequence types; should we return an empty sequence unless they are the same type?; should we translate?; the latter might seem logical, but this innocent method name would then be hiding quite an important feature... I propose we drop that method (and +sequenceWithSequence), and let the user with 'copy', and then come up with a better name for a method that would do the tranformation of one sequence type into another. > > >I put at the end of the email what I would propose as init and factory methods for the different subclasses. There are not many changes from the current status, in fact. I put some comments to indicate which methods will really need to be implemented in the subclass (well, the code is already done, anyway). This little 'cleaning' would be nice before we add the annotations stuff, what do you think? > > >One more random thought: We probably don't need annotations in the init methods (or at least we can live without for a while). We would just need to set the ivar to nil at init and then alloc it at the first '-addAnnotation:'. > >Let me know what you think! > >Charles > >NB: I think Alex is still away, so I will wait also for his input... > > > >// ------------------ >// BCAbstractSequence >// ------------------ > > //designated initializer > //override in subclasses > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > > //another initializer > //(that does not call the designated initializer) > //(or should this one be the designated initializer?) > //override in subclasses > - (id)initWithSymbolArray:(NSArray *)anArray; > > //Call the designated initializer > //do not override in the subclasses > - (id)initWithString:(NSString *)aString; > - (id)initWithString:(NSString *)aString > range:(NSRange)aRange > skippingUnknownSymbols:(BOOL)skipFlag; > > //Factory methods that call the init methods > //do not override in the subclasses > + (BCAbstractSequence *) sequenceWithString:(NSString *)aString; > + (BCAbstractSequence *) sequenceWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > + (BCAbstractSequence *) sequenceWithString:(NSString *)aString > range:(NSRange)aRange > skippingUnknownSymbols:(BOOL)skipFlag; > + (BCAbstractSequence *) sequenceWithSymbolArray: (NSArray *)entry; > > //Call the designated initializer > //do not override in subclasses > //(these methods are a bit dangerous when using 2 different subclasses > // probably better to forget that for now > // and come up with a better name that clearly implies translation > // may have to occur for the method to make sense) > - (id)initWithSequence:(BCAbstractSequence *)entry; > + (BCAbstractSequence *)sequenceWithSequence:(BCAbstractSequence *)entry; > > > >// ---------- >// BCSequence >// ---------- >// placeholder subclass > > > //methods to override > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > - (id)initWithSymbolArray:(NSArray *)anArray; > > //new methods > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > usingType:(BCSequenceType) type; > + (BCSequence *)sequenceWithString:(NSString *)string > skippingUnknownSymbols:(BOOL)skipFlag; > >usingType:(BCSequenceType) type; > - (BCSequenceType)sequenceTypeForUntypedString:(NSString *)string; > > //automatically inherited methods > - (id)initWithString:(NSString *)aString; > - (id)initWithString:(NSString *)aString > range:(NSRange)aRange > skippingUnknownSymbols:(BOOL)skipFlag; > +(BCAbstractSequence *)sequenceWithString:(NSString *)string; > +(BCAbstractSequence *)sequenceWithString:(NSString *)string > skippingUnknownSymbols:(BOOL)skipFlag; > +(BCAbstractSequence *)sequenceWithString:(NSString *)string > range:(NSRange)aRange > skippingUnknownSymbols:(BOOL)skipFlag; > +(BCAbstractSequence *)sequenceWithSymbolArray: (NSArray *)entry; > - (id)initWithSequence:(BCAbstractSequence *)entry; > + (BCAbstractSequence *)sequenceWithSequence:(BCAbstractSequence *)entry; > > > >// ------------ >// BCSequenceDNA >/ ------------ > > //methods to override > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > - (id)initWithSymbolArray:(NSArray *)anArray; > > > //automatically inherited methods > //...same as above... > > >// ------------ >// BCSequenceRNA >// ------------ > > //methods to override > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > - (id)initWithSymbolArray:(NSArray *)anArray; > > //new methods > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag > convertingThymidines:(BOOL)convertFlag; > + (BCSequenceRNA *)rnaSequenceWithString:(NSString *)string > skippingUnknownSymbols:(BOOL)skipFlag; > convertingThymidines:(BOOL)convertFlag; > > //automatically inherited methods > //...same as above... > > > >// --------------- >// BCSequenceCodon >// --------------- > > //methods to override > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > - (id)initWithSymbolArray:(NSArray *)anArray; > > //new methods > - (id)initWithCodonArray:(NSArray *)anArray > geneticCode:(BCGeneticCodeName)codeType > frame:(NSString *)theFrame; > - (BCSequenceCodon *)codonSequenceWithCodonArray:(NSArray *)anArray > >geneticCode:(BCGeneticCodeName)codeType > frame:(NSString *)theFrame; > > //automatically inherited methods > //...same as above... > > > >// ------------ >// BCSequenceProtein >// ------------ > > //methods to override > - (id)initWithString:(NSString *)aString > skippingUnknownSymbols:(BOOL)skipFlag; > - (id)initWithSymbolArray:(NSArray *)anArray; > > > //automatically inherited methods > //...same as above... > >-- >Help science go fast forward: >http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > >Charles Parnot >charles.parnot at stanford.edu > >Room B157 in Beckman Center >279, Campus Drive >Stanford University >Stanford, CA 94305 (USA) > >Tel +1 650 725 7754 >Fax +1 650 725 8021 >_______________________________________________ >Biococoa-dev mailing list >Biococoa-dev at bioinformatics.org >https://bioinformatics.org/mailman/listinfo/biococoa-dev -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From jtimmer at bellatlantic.net Wed Feb 9 08:02:53 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 09 Feb 2005 08:02:53 -0500 Subject: [Biococoa-dev] BCSequence init methods In-Reply-To: Message-ID: > > And then, later, I want to discuss the BCSeqenceCodon design. Get ready for > some long emails ;-) > Save your fingers! The class was thrown together on a flight between Cyprus and London, just in order to get translation working. It is more ad-hoc than designed, so don't point out where all its flaws are. You can just point out how you'd like to set it up. Cheers, John _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Fri Feb 11 23:15:59 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 11 Feb 2005 20:15:59 -0800 Subject: [Biococoa-dev] BCSequence commit Message-ID: At 0:06 -0800 2/9/05, Charles PARNOT wrote: >Next task is to finally get BCSequence up and running. At that point, I will check the code of the examples to fully comply. I commited the full implementation of BCSequence. This code won't need any change for a while, except if we add more sequence classes. Actually, there is a little piece of code still missing: when scanning a NSString or an NSArray of BCSymbol, it does not yet recognize sequence of type Codon automatically. The BCSequence header is still empty. It will contain all the methods of all the classes. I will then need to prevent compilation warnings as the class won't implement those methods. What is the pragma used for that, BTW? Next tasks: * remove BCSequenceFactory * make the examples compliant charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Fri Feb 11 23:37:36 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 11 Feb 2005 20:37:36 -0800 Subject: [Biococoa-dev] BCSequenceFactory removed In-Reply-To: References: Message-ID: >Next tasks: >* remove BCSequenceFactory done. The files are not in the target anymore. I have not removed the files from the CVS. I created a 'DEPRECATED' group and moved the files in there (with BCSymbolList). I thought we could keep these files around for a while, as a reference until the new structure is fully tested. >* make the examples compliant to do. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Sat Feb 12 03:22:42 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 12 Feb 2005 03:22:42 -0500 Subject: [Biococoa-dev] BCSequenceFactory removed In-Reply-To: References: Message-ID: <846734991d83d8e5d8e150a0741263ba@earthlink.net> On Feb 11, 2005, at 11:37 PM, Charles PARNOT wrote: > done. > The files are not in the target anymore. I have not removed the files > from the CVS. I created a 'DEPRECATED' group and moved the files in > there (with BCSymbolList). I thought we could keep these files around > for a while, as a reference until the new structure is fully tested. > >> * make the examples compliant > > to do. > Great job Charles. Not sure if you are aware of it, but he translation example now crashes at startup (I bet during the creation of the 1st sequence). I may have some time this weekend, and can look into what's going on. cheers, - Koen. From kvddrift at earthlink.net Sat Feb 12 10:18:33 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 12 Feb 2005 10:18:33 -0500 Subject: [Biococoa-dev] BCSequenceFactory removed In-Reply-To: <846734991d83d8e5d8e150a0741263ba@earthlink.net> References: <846734991d83d8e5d8e150a0741263ba@earthlink.net> Message-ID: On Feb 12, 2005, at 3:22 AM, Koen van der Drift wrote: > Great job Charles. Not sure if you are aware of it, but he translation > example now crashes at startup (I bet during the creation of the 1st > sequence). I may have some time this weekend, and can look into what's > going on. > Ha - I see Charles already fixed it :). Looks like the timer in the Translation demo displays a lower number now thatn before. Maybe just my imagination, or maybe wishful thinking. But if it is true, that's a great improvement! - Koen. From charles.parnot at stanford.edu Sat Feb 12 10:44:47 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 12 Feb 2005 07:44:47 -0800 Subject: [Biococoa-dev] BCSequenceFactory removed In-Reply-To: <846734991d83d8e5d8e150a0741263ba@earthlink.net> References: <846734991d83d8e5d8e150a0741263ba@earthlink.net> Message-ID: >Great job Charles. Not sure if you are aware of it, but he translation example now crashes at startup (I bet during the creation of the 1st sequence). I may have some time this weekend, and can look into what's going on. > >cheers, > >- Koen. Yeah, I fixed it ;-) In several subclasses, the designated initalizer 'initWithString:skippingUnknownSymbols:' was not calling the designated initializer of the superclass (the same method), but instead the 'init' method of the superclass. Because the latter does call the designated initializer (of course), an infinite loop was generated. All my fault. Nasty bug. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Sat Feb 12 17:00:21 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 12 Feb 2005 17:00:21 -0500 Subject: [Biococoa-dev] BCSequenceFactory removed In-Reply-To: References: <846734991d83d8e5d8e150a0741263ba@earthlink.net> Message-ID: <6a307240c9ea3b6daffc4ce6012ffe13@earthlink.net> On Feb 12, 2005, at 10:44 AM, Charles PARNOT wrote: > In several subclasses, the designated initalizer > 'initWithString:skippingUnknownSymbols:' was not calling the > designated initializer of the superclass (the same method), but > instead the 'init' method of the superclass. Because the latter does > call the designated initializer (of course), an infinite loop was > generated. All my fault. Nasty bug. > Excellent job. So, is the whole transformation to the class cluster done, or are there still things that do not work? Maybe we can start to add convenience methods for the BCTools classes? Should they go into the appropriate subclasses, or only in BCAbstractSequence? Next I guess is the annotation class, and then adding more code to the reader/writer classes. - Koen. From charles.parnot at stanford.edu Sun Feb 13 02:25:48 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 12 Feb 2005 23:25:48 -0800 Subject: [Biococoa-dev] BCSequenceFactory removed In-Reply-To: <6a307240c9ea3b6daffc4ce6012ffe13@earthlink.net> References: <846734991d83d8e5d8e150a0741263ba@earthlink.net> <6a307240c9ea3b6daffc4ce6012ffe13@earthlink.net> Message-ID: >Excellent job. So, is the whole transformation to the class cluster done, or are there still things that do not work? Maybe we can start to add convenience methods for the BCTools classes? Should they go into the appropriate subclasses, or only in BCAbstractSequence? > >Next I guess is the annotation class, and then adding more code to the reader/writer classes. > >- Koen. The placeholder class should work OK at runtime. It may still give compilation warnings if using methods not in the header. When adding public methods to the the subclasses, here are the 'rules': * the superclass should implement the method no matter what: - if it is relevant for all subclasses, then the returned value will be something real - even if relevant only for one subclass, the superclass should return something, like an empty sequence or empty array, * the superclass does not have to have the method in the header, if it is not relevant for some of the subclasses * the subclasses can override the superclass if necessary * the subclasses can have the method in the hearder, if relevant * BCSequence does not need to implement anything, because such code would never be called, but SHOULD have it in the header About convenience methods. For instance, in the case of translation, you would probably implement it in the superclass with something like: - (BCSequence *)translate { BCToolTranslator *tool=[BCToolTranslator translatorToolWithSequence:self]; return [tool result]; } and have the method only declared in BCSequence header (and BCSequenceDNA maybe?). and have the following in BCSequenceDNA header and implementation: - (BCProtein *)translateToProtein { BCToolTranslator *tool=[BCToolTranslator translatorToolWithDNASequence:self]; return [tool result]; } and then the tool have to have the appropriate methods too. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 15 01:39:42 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 14 Feb 2005 22:39:42 -0800 Subject: [Biococoa-dev] developer docs Message-ID: I added some file to have developer documentation in the project (eg for BioCocoa newcomers). So if you update your project in Xcode, you will see a new group with some files. These files will show in red because they are in a new folder inside the project folder, and Xcode does not handle new folders in cvs, so it won't find the files. I found that you need to update in the terminal with the -d flag, like so: (for bash) export CVS_RSH='ssh' export CVSROOT=':ext:cparnot at bioinformatics.org:/cvsroot' cd (path to the project)/BioCocoa cvs update -d (for csh) setenv CVS_RSH 'ssh' setenv CVSROOT ':ext:loginname at bioinformatics.org:/cvsroot' cd (path to the project)/BioCocoa cvs update -d charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Tue Feb 15 19:11:07 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 15 Feb 2005 19:11:07 -0500 Subject: [Biococoa-dev] developer docs In-Reply-To: References: Message-ID: <11ea9ae632f0bf16b29460247ac3690b@earthlink.net> On Feb 15, 2005, at 1:39 AM, Charles PARNOT wrote: > cvs update -d > You also need the -P flag, otherwise you will download all the deprecated directories as well: cvs update -d -P - Koen. From kvddrift at earthlink.net Tue Feb 15 19:39:23 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 15 Feb 2005 19:39:23 -0500 Subject: [Biococoa-dev] developer docs In-Reply-To: References: Message-ID: On Feb 15, 2005, at 1:39 AM, Charles PARNOT wrote: > I added some file to have developer documentation in the project (eg > for BioCocoa newcomers). Good initiative Charles! I also added some info on how to create the html docs from the headerdoc entries. - Koen. From charles.parnot at stanford.edu Wed Feb 16 03:02:44 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 16 Feb 2005 00:02:44 -0800 Subject: [Biococoa-dev] relative paths in headers Message-ID: I was trying to use the framework in another project when I found this caused some compiling failures. The reason is the compiler parses the header files in the framework and was seeing things like: #import "../BCSequenceTool.h" but when compiler in another project, the compiler only sees the list of header files in the Header directory of the framework bundle, so it is all flat and does not find the header file. The fix is to remove the directory '..' and just have #import "BCSequenceTool.h" or this seems OK too: #import Now, the other project does compile fine with this set of header files in the BioCocoa framework. Importantly, despite the absence of the '..', the compiler can also still find the header file when compiling BioCocoa itself. I commited the modifs to get things to work (~a dozen classes). I am not entirely sure of the fix I did, so let me know if you know better. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Wed Feb 16 05:19:01 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 16 Feb 2005 11:19:01 +0100 Subject: [Biococoa-dev] WWDC2005 Message-ID: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Hi guys, Yesterday the date of WWDC2005 was announced (6-10 june) and Tom and I will definitely go again (very addictive). Although I haven't contributed much in the past month because of you know why, I have been walking around with this idea that I would like to get your opinion on. Wouldn't it be great if we could organize a get together at the WWDC, meet each other in real, learn all about the new stuff in tiger (i.e. what opportunities will Core Data give us in combination with BioCocoa), and discuss/work together on the framework. I think it would be a perfect opportunity to both boost the development progress and set out the future directions/trajectory we have in mind. Now my gut feeling says that: - Me and Tom will go for sure (that wasn't to difficult to feel) and will apply for a scholarship for admission and travel sponsorship from the institute - Peter can go for the scholarship as well, but perhaps joins the Belgian Apple group again ? - Charles are you going because of the xgrid stuff again? Do you have an invitation? - Jim was there last time, are you going again? - And then there are Koen and John, did you guys have any plans in going already? So the question is, does any of you already know for sure they're going and who would be interested in going and join in a BioCocoa meeting? Who would be interested but has (financial) considerations that will make it unlikely to come? The reason for asking is that if we all like the idea, I'm want to try to convince the people at Apple I met last year to perhaps sponsor/co-organize this event. Therefore I would like to know who would like to come but needs to pay the 1600$ admission fee if he does so. I would like to see if its possible that Apple would sponsor those a free ticket to the WWDC. The second thing would be to ask if they're interested in having one of the lunch meetings being centered around BioCocoa. Last year there were quite some bio people there (including a guy from BioPerl), it would be nice to give a little presentation on the framework and discuss the plans and as such both attract new developers perhaps and warm up apple to support our initiative if they like it. Also, Apple is an official sponsor of the Open Bioinformatics Foundation (the mother organisation of BioJava, BioPerl etc), so I guess they are interested in a BioCocoa sibling. For those planning to visit WWDC already, I'm looking forward to meet you all! For those that didn't until now, let me know if you're interested and can free the week from the 6-10th of june. It would be great to have our first official BioCocoa meeting! Let me know what you think, Cheers, Alex Links: http://developer.apple.com/wwdc/ http://www.mekentosj.com/events/wwdc04/ ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From peter.schols at bio.kuleuven.ac.be Wed Feb 16 06:50:38 2005 From: peter.schols at bio.kuleuven.ac.be (Peter Schols) Date: Wed, 16 Feb 2005 12:50:38 +0100 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> References: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: <23f532a0297c1a0e419d9379945b5358@bio.kuleuven.ac.be> Hi Alex, Great idea! I'll definitely attend WWDC 2005 and of course I would be very interested in joining/co-organising a BioCocoa session. At WWDC 2002 and at last year's WWDC, there were Birds of a Feather sessions. I think that these BOFs might be the appropriate forum to talk about BC. In case Apple is planning to organise BOFs this year (I don't think they already know this for sure), it should be relatively easy to arrange something with Robert Kehrer or Bud Tribble. This BC talk could also be a great opportunity to get some BC developers to WWDC. Best wishes, Peter On 16 Feb 2005, at 11:19, Alexander Griekspoor wrote: > Hi guys, > > Yesterday the date of WWDC2005 was announced (6-10 june) and Tom and I > will definitely go again (very addictive). Although I haven't > contributed much in the past month because of you know why, I have > been walking around with this idea that I would like to get your > opinion on. Wouldn't it be great if we could organize a get together > at the WWDC, meet each other in real, learn all about the new stuff in > tiger (i.e. what opportunities will Core Data give us in combination > with BioCocoa), and discuss/work together on the framework. I think it > would be a perfect opportunity to both boost the development progress > and set out the future directions/trajectory we have in mind. > > Now my gut feeling says that: > - Me and Tom will go for sure (that wasn't to difficult to feel) and > will apply for a scholarship for admission and travel sponsorship from > the institute > - Peter can go for the scholarship as well, but perhaps joins the > Belgian Apple group again ? > - Charles are you going because of the xgrid stuff again? Do you have > an invitation? > - Jim was there last time, are you going again? > - And then there are Koen and John, did you guys have any plans in > going already? > > So the question is, does any of you already know for sure they're > going and who would be interested in going and join in a BioCocoa > meeting? Who would be interested but has (financial) considerations > that will make it unlikely to come? > > The reason for asking is that if we all like the idea, I'm want to try > to convince the people at Apple I met last year to perhaps > sponsor/co-organize this event. Therefore I would like to know who > would like to come but needs to pay the 1600$ admission fee if he does > so. I would like to see if its possible that Apple would sponsor those > a free ticket to the WWDC. > The second thing would be to ask if they're interested in having one > of the lunch meetings being centered around BioCocoa. Last year there > were quite some bio people there (including a guy from BioPerl), it > would be nice to give a little presentation on the framework and > discuss the plans and as such both attract new developers perhaps and > warm up apple to support our initiative if they like it. Also, Apple > is an official sponsor of the Open Bioinformatics Foundation (the > mother organisation of BioJava, BioPerl etc), so I guess they are > interested in a BioCocoa sibling. > > For those planning to visit WWDC already, I'm looking forward to meet > you all! For those that didn't until now, let me know if you're > interested and can free the week from the 6-10th of june. It would be > great to have our first official BioCocoa meeting! > Let me know what you think, > Cheers, > Alex > > Links: > http://developer.apple.com/wwdc/ > http://www.mekentosj.com/events/wwdc04/ > > > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Windows vs Mac > 65 million years ago, there were more > dinosaurs than humans. > Where are the dinosaurs now? > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > From jtimmer at bellatlantic.net Wed Feb 16 08:31:52 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 16 Feb 2005 08:31:52 -0500 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: I hadn't planned on going - it's rather expensive, and I'd be shocked if I could convince anyone at either my current or former institutions that it's worth their money to send me. As it is, my seed key just expired and I have to go and beg for a new one later today. That said, I'd love the chance to go, and I have a lot of friends in the area left over from grad school, so the housing at least would be cheap. Incidentally, I've been building a CoreData application - I'm probably about a quarter of the way done with the basics, so I think I've got a decent grasp of it. If we're interested in transitioning to that, it's going to take a bunch of fundamental changes to the basic classes. If people are interested, I can look over the non-NDA'd material and try to describe some of the issues. JT > Hi guys, > > Yesterday the date of WWDC2005 was announced (6-10 june) and Tom and I > will definitely go again (very addictive). Although I haven't > contributed much in the past month because of you know why, I have been > walking around with this idea that I would like to get your opinion on. > Wouldn't it be great if we could organize a get together at the WWDC, > meet each other in real, learn all about the new stuff in tiger (i.e. > what opportunities will Core Data give us in combination with > BioCocoa), and discuss/work together on the framework. I think it would > be a perfect opportunity to both boost the development progress and set > out the future directions/trajectory we have in mind. > > Now my gut feeling says that: > - Me and Tom will go for sure (that wasn't to difficult to feel) and > will apply for a scholarship for admission and travel sponsorship from > the institute > - Peter can go for the scholarship as well, but perhaps joins the > Belgian Apple group again ? > - Charles are you going because of the xgrid stuff again? Do you have > an invitation? > - Jim was there last time, are you going again? > - And then there are Koen and John, did you guys have any plans in > going already? > > So the question is, does any of you already know for sure they're going > and who would be interested in going and join in a BioCocoa meeting? > Who would be interested but has (financial) considerations that will > make it unlikely to come? > > The reason for asking is that if we all like the idea, I'm want to try > to convince the people at Apple I met last year to perhaps > sponsor/co-organize this event. Therefore I would like to know who > would like to come but needs to pay the 1600$ admission fee if he does > so. I would like to see if its possible that Apple would sponsor those > a free ticket to the WWDC. > The second thing would be to ask if they're interested in having one of > the lunch meetings being centered around BioCocoa. Last year there were > quite some bio people there (including a guy from BioPerl), it would be > nice to give a little presentation on the framework and discuss the > plans and as such both attract new developers perhaps and warm up apple > to support our initiative if they like it. Also, Apple is an official > sponsor of the Open Bioinformatics Foundation (the mother organisation > of BioJava, BioPerl etc), so I guess they are interested in a BioCocoa > sibling. > > For those planning to visit WWDC already, I'm looking forward to meet > you all! For those that didn't until now, let me know if you're > interested and can free the week from the 6-10th of june. It would be > great to have our first official BioCocoa meeting! > Let me know what you think, > Cheers, > Alex > > Links: > http://developer.apple.com/wwdc/ > http://www.mekentosj.com/events/wwdc04/ > > > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Windows vs Mac > 65 million years ago, there were more > dinosaurs than humans. > Where are the dinosaurs now? > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev _______________________________________________ This mind intentionally left blank From james.balhoff at duke.edu Wed Feb 16 09:54:22 2005 From: james.balhoff at duke.edu (Jim Balhoff) Date: Wed, 16 Feb 2005 09:54:22 -0500 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> References: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: I think a BioCocoa meeting at WWDC would be a great idea. I'll be applying for a scholarship, but without that I'd have a hard time going. Or maybe I could whip up an entry for the Apple Design Awards like you guys :-). I'm hoping to get back into BioCocoa soon - my dissertation defense is coming up quickly. Jim On Feb 16, 2005, at 5:19 AM, Alexander Griekspoor wrote: > Hi guys, > > Yesterday the date of WWDC2005 was announced (6-10 june) and Tom and I > will definitely go again (very addictive). Although I haven't > contributed much in the past month because of you know why, I have > been walking around with this idea that I would like to get your > opinion on. Wouldn't it be great if we could organize a get together > at the WWDC, meet each other in real, learn all about the new stuff in > tiger (i.e. what opportunities will Core Data give us in combination > with BioCocoa), and discuss/work together on the framework. I think it > would be a perfect opportunity to both boost the development progress > and set out the future directions/trajectory we have in mind. > ____________________________________________ James P. Balhoff Dept. of Biology Duke University Durham, NC 27708-0338 USA From kvddrift at earthlink.net Wed Feb 16 17:17:11 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 16 Feb 2005 17:17:11 -0500 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> References: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: <7d62ffe0499b5fc29de52d29d3393266@earthlink.net> On Feb 16, 2005, at 5:19 AM, Alexander Griekspoor wrote: > For those planning to visit WWDC already, I'm looking forward to meet > you all! For those that didn't until now, let me know if you're > interested and can free the week from the 6-10th of june. It would be > great to have our first official BioCocoa meeting! > Let me know what you think, > I'd love to go, but I am afraid it ain't gonna happen. My work is completely unrelated to the BioCocoa project (except that I work with proteins :), so I don't think I can convince my supervisor to pay for my trip and admission. Besides that, working for a US company doens't allow much vacation time, so taking time off to go to the WWDC is difficult too :( Sorry guys. - Koen. From charles.parnot at stanford.edu Wed Feb 16 20:08:40 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 16 Feb 2005 17:08:40 -0800 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: Message-ID: >Incidentally, I've been building a CoreData application - I'm probably about >a quarter of the way done with the basics, so I think I've got a decent >grasp of it. If we're interested in transitioning to that, it's going to >take a bunch of fundamental changes to the basic classes. If people are >interested, I can look over the non-NDA'd material and try to describe some >of the issues. > >JT That sounds really exciting, and the little I have read about CoreData is still quite blurry and I can't quite grasp the fundamentals yet. That would be a nice way for everybody to also learn more about CoreData. What would CoreData bring, and what changes would be needed? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Wed Feb 16 20:09:48 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 16 Feb 2005 17:09:48 -0800 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> References: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: I am not (yet) invited and I don't think this will happen two years in a row (or even more than 1 time in my entire life). I like the idea of Apple paying for it, of course (or me not paying for it), because I would have to pay for myself otherwise and can't get sponsored. I think it is a good idea to start lobbying to get Apple to sponsor at least a lunch session in the Science lounge... and at best invite everybody to the WWDC and pay for a suite per person at the Hilton. In any case, I would love to meet those of you that will attend, and that can happen outside of the WWDC Actually, one of you could even drop a badge from the roof ;-) I live close by, so it is easy for me to simply drive to San Francisco. Following your message, Alex, something else came to my mind. It may be time to get a nice demo app together before then, that would demonstrate the power (or potential power!) of the framework. An app with just a dozen lines of code and some IB connections that works magically thanks to the framework (using a class ? la WebView). charles >Hi guys, > >Yesterday the date of WWDC2005 was announced (6-10 june) and Tom and I will definitely go again (very addictive). Although I haven't contributed much in the past month because of you know why, I have been walking around with this idea that I would like to get your opinion on. Wouldn't it be great if we could organize a get together at the WWDC, meet each other in real, learn all about the new stuff in tiger (i.e. what opportunities will Core Data give us in combination with BioCocoa), and discuss/work together on the framework. I think it would be a perfect opportunity to both boost the development progress and set out the future directions/trajectory we have in mind. > >Now my gut feeling says that: >- Me and Tom will go for sure (that wasn't to difficult to feel) and will apply for a scholarship for admission and travel sponsorship from the institute >- Peter can go for the scholarship as well, but perhaps joins the Belgian Apple group again ? >- Charles are you going because of the xgrid stuff again? Do you have an invitation? >- Jim was there last time, are you going again? >- And then there are Koen and John, did you guys have any plans in going already? > >So the question is, does any of you already know for sure they're going and who would be interested in going and join in a BioCocoa meeting? Who would be interested but has (financial) considerations that will make it unlikely to come? > >The reason for asking is that if we all like the idea, I'm want to try to convince the people at Apple I met last year to perhaps sponsor/co-organize this event. Therefore I would like to know who would like to come but needs to pay the 1600$ admission fee if he does so. I would like to see if its possible that Apple would sponsor those a free ticket to the WWDC. >The second thing would be to ask if they're interested in having one of the lunch meetings being centered around BioCocoa. Last year there were quite some bio people there (including a guy from BioPerl), it would be nice to give a little presentation on the framework and discuss the plans and as such both attract new developers perhaps and warm up apple to support our initiative if they like it. Also, Apple is an official sponsor of the Open Bioinformatics Foundation (the mother organisation of BioJava, BioPerl etc), so I guess they are interested in a BioCocoa sibling. > >For those planning to visit WWDC already, I'm looking forward to meet you all! For those that didn't until now, let me know if you're interested and can free the week from the 6-10th of june. It would be great to have our first official BioCocoa meeting! >Let me know what you think, >Cheers, >Alex -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Wed Feb 16 21:32:17 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 16 Feb 2005 21:32:17 -0500 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: Message-ID: <52192e115dad2cd7d7c459768e405c70@earthlink.net> On Feb 16, 2005, at 8:08 PM, Charles PARNOT wrote: > > That sounds really exciting, and the little I have read about CoreData > is still quite blurry and I can't quite grasp the fundamentals yet. > That would be a nice way for everybody to also learn more about > CoreData. What would CoreData bring, and what changes would be needed? > > One thing that we have to be aware of is that If we introduce CoreData, the framework will be 10.4 only. But of course I am interested to learn more about CoreData as well ;-) - Koen. From kvddrift at earthlink.net Wed Feb 16 21:34:56 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 16 Feb 2005 21:34:56 -0500 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: References: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: On Feb 16, 2005, at 8:09 PM, Charles PARNOT wrote: > Following your message, Alex, something else came to my mind. It may > be time to get a nice demo app together before then, that would > demonstrate the power (or potential power!) of the framework. An app > with just a dozen lines of code and some IB connections that works > magically thanks to the framework (using a class ? la WebView). > I think it would be nice if we can add the demo from the current release (1.6) to the framework, and replace the current 'SequenceConverter' with that. I have never been able to get that one to work. I also have some code that will grab a file from a database (NCBI, SwissProt), and display it in a window. But it will use more than a dozen lines ;-) - Koen. From charles.parnot at stanford.edu Thu Feb 17 02:26:33 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 16 Feb 2005 23:26:33 -0800 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: References: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: >On Feb 16, 2005, at 8:09 PM, Charles PARNOT wrote: > >>Following your message, Alex, something else came to my mind. It may be time to get a nice demo app together before then, that would demonstrate the power (or potential power!) of the framework. An app with just a dozen lines of code and some IB connections that works magically thanks to the framework (using a class ? la WebView). >> > >I think it would be nice if we can add the demo from the current release (1.6) to the framework, and replace the current 'SequenceConverter' with that. I have never been able to get that one to work. I also have some code that will grab a file from a database (NCBI, SwissProt), and display it in a window. But it will use more than a dozen lines ;-) > >- Koen. The dozen lines would be in the app. So if your code is in the framework, done! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Thu Feb 17 04:38:16 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 17 Feb 2005 10:38:16 +0100 Subject: [Biococoa-dev] WWDC2005 Message-ID: <54e1309b015a78b3b7106078fdf48987@mekentosj.com> Cool, it seems that except Koen (he's the only one really working it seems ;-) everyone is planning to go or willing to go, great! I will together with Peter write an email to Robert Kehrer, and see what we can organize. I'll keep you all informed on the results. > > Following your message, Alex, something else came to my mind. It may > be time to get a nice demo app together before then, that would > demonstrate the power (or potential power!) of the framework. An app > with just a dozen lines of code and some IB connections that works > magically thanks to the framework (using a class ? la WebView). Definitely, let me think about it this weekend, I had those plans for a long time and of course have quite some code from the different apps I've created. I need to get back into the framework anyway, so I would like to give it a try and come up with something as a basis to start with... It would include the custom view as well. Cheers, Alex > charles > >> Hi guys, >> >> Yesterday the date of WWDC2005 was announced (6-10 june) and Tom and >> I will definitely go again (very addictive). Although I haven't >> contributed much in the past month because of you know why, I have >> been walking around with this idea that I would like to get your >> opinion on. Wouldn't it be great if we could organize a get together >> at the WWDC, meet each other in real, learn all about the new stuff >> in tiger (i.e. what opportunities will Core Data give us in >> combination with BioCocoa), and discuss/work together on the >> framework. I think it would be a perfect opportunity to both boost >> the development progress and set out the future directions/trajectory >> we have in mind. >> >> Now my gut feeling says that: >> - Me and Tom will go for sure (that wasn't to difficult to feel) and >> will apply for a scholarship for admission and travel sponsorship >> from the institute >> - Peter can go for the scholarship as well, but perhaps joins the >> Belgian Apple group again ? >> - Charles are you going because of the xgrid stuff again? Do you have >> an invitation? >> - Jim was there last time, are you going again? >> - And then there are Koen and John, did you guys have any plans in >> going already? >> >> So the question is, does any of you already know for sure they're >> going and who would be interested in going and join in a BioCocoa >> meeting? Who would be interested but has (financial) considerations >> that will make it unlikely to come? >> >> The reason for asking is that if we all like the idea, I'm want to >> try to convince the people at Apple I met last year to perhaps >> sponsor/co-organize this event. Therefore I would like to know who >> would like to come but needs to pay the 1600$ admission fee if he >> does so. I would like to see if its possible that Apple would sponsor >> those a free ticket to the WWDC. >> The second thing would be to ask if they're interested in having one >> of the lunch meetings being centered around BioCocoa. Last year there >> were quite some bio people there (including a guy from BioPerl), it >> would be nice to give a little presentation on the framework and >> discuss the plans and as such both attract new developers perhaps and >> warm up apple to support our initiative if they like it. Also, Apple >> is an official sponsor of the Open Bioinformatics Foundation (the >> mother organisation of BioJava, BioPerl etc), so I guess they are >> interested in a BioCocoa sibling. >> >> For those planning to visit WWDC already, I'm looking forward to meet >> you all! For those that didn't until now, let me know if you're >> interested and can free the week from the 6-10th of june. It would be >> great to have our first official BioCocoa meeting! >> Let me know what you think, >> Cheers, >> Alex >> >> Links: >> http://developer.apple.com/wwdc/ >> http://www.mekentosj.com/events/wwdc04/ >> >> >> ********************************************************* >> ** Alexander Griekspoor ** >> ********************************************************* >> The Netherlands Cancer Institute >> Department of Tumorbiology (H4) >> Plesmanlaan 121, 1066 CX, Amsterdam >> Tel: + 31 20 - 512 2023 >> Fax: + 31 20 - 512 2029 >> AIM: mekentosj at mac.com >> E-mail: a.griekspoor at nki.nl >> Web: http://www.mekentosj.com >> >> Windows vs Mac >> 65 million years ago, there were more >> dinosaurs than humans. >> Where are the dinosaurs now? >> >> ********************************************************* >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev > > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From mek at mekentosj.com Thu Feb 17 04:38:29 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 17 Feb 2005 10:38:29 +0100 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) Message-ID: <181da07d4a0868389ab30ed0533661f7@mekentosj.com> Great! The problem really is that core data is pretty much NDA-ed all over still (another advantage if we all join the WWDC, but by then Tiger will probably be unleashed anyway). But yes, think of a "webview-like" biococoa-view and core data, mix that with binding and you don't have to write any code for a basic app... That's how powerful it can be. Alex On 17-feb-05, at 2:08, Charles PARNOT wrote: >> Incidentally, I've been building a CoreData application - I'm >> probably about >> a quarter of the way done with the basics, so I think I've got a >> decent >> grasp of it. If we're interested in transitioning to that, it's >> going to >> take a bunch of fundamental changes to the basic classes. If people >> are >> interested, I can look over the non-NDA'd material and try to >> describe some >> of the issues. >> >> JT > > That sounds really exciting, and the little I have read about CoreData > is still quite blurry and I can't quite grasp the fundamentals yet. > That would be a nice way for everybody to also learn more about > CoreData. What would CoreData bring, and what changes would be needed? > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From mek at mekentosj.com Thu Feb 17 04:38:41 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 17 Feb 2005 10:38:41 +0100 Subject: Fwd: CoreDate (was: [Biococoa-dev] WWDC2005) Message-ID: > One thing that we have to be aware of is that If we introduce > CoreData, the framework will be 10.4 only. But of course I am > interested to learn more about CoreData as well ;-) Yep, I didn't want to bring it all up at once, but the discussion would come anyway like the one on GNUstep support: what do we want? I think we all agree we don't want the framework to be 10.4 only. I am strongly in favour to have a 10.4 version though that adds the nice new things from tiger, most prominently core data support (though not a prime target right now). It should be possible to have a kind of extension that will build in a 10.4 only framework on top of the basic one, or not? Then the discussion I was talking about, 10.2 support. First the view on our personal programs. We basically intend to support down to [current release] minus one. So currently all our programs run on 10.2 or higher. But with Tiger coming that will shift to 10.3 or higher. The reason is simple, first I want to simply use those nifty features in panther, second I want to get rid of those annoying 10.2 bugs and the fact our programs run slower, finally (most important factor) my development machine runs the latest OS and I don't have an Apple Compatibility Lab to test it all. Also, I think (might be wrong here) that by now 90% of the people run 10.3. So with the coming of 10.4 I have decided to no longer go for 10.2 unless my older programs don't need 10.3 per se, than it comes for free. Now I strongly argue in favor of lifting the BioCocoa framework minimum requirements to 10.3 or higher for the following reasons: - first, the same reasons as above - second, 10.3 is considered to be the first really "mature" MacOSX version (think in terms of speed and bugs) - third, we can support bindings, this will be the basis for all future cocoa apps and 10.3 supports the minimum you need, missing this is huge in my opinion, even if we all haven't really used it because of 10.2 support of our current programs. - fourth, we get a number of additional stuff which is not critical but very nice: NSXML, Webkit installed by default, etc - finally, it allows to do the 10.3 / 10.4 version of the framework, 10.2 and 10.4 will differ so dramatically that it won't make sense, but with 10.3/10.4 it should be possible (think again to the lack of bindings in 10.2) Now remember, no one has made any app yet with the new framework, and that's perhaps the most strongest argument. I think everyone who will start coding a completely new app today will make it 10.3 or higher, so why make it 10.2 compatible. A practical example: I plan to upgrade EnzymeX and 4Peaks to use the biococoa framework for all its sequence handling the moment we come to a stable version. Do I need 10.2 support, no because I won't support it anyway anymore, the current versions are stable and will run on 10.2 forever, but if you want a new update for 4Peaks or EnzymeX you need Panther, that's fair by now in my opinion. Let me know what you think and chime in if I overlooked a big reason to support 10.3. Cheers, Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From kvddrift at earthlink.net Thu Feb 17 06:41:37 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 17 Feb 2005 06:41:37 -0500 Subject: [Biococoa-dev] WWDC2005 In-Reply-To: References: <669f21e4b52ed779c59e83ce228fdecd@mekentosj.com> Message-ID: <940b52f1cac144e3332ddeb9bd07d690@earthlink.net> On Feb 17, 2005, at 2:26 AM, Charles PARNOT wrote: > > The dozen lines would be in the app. So if your code is in the > framework, done! > I will see what I can do do ;-) Let's not forget though, that there are some more basic things that really need to be added to the framework, such as finishing BCSequenceReader, BCSequenceWriter and the implementation of features and annotations. Now we have a (hopefully) final structure in place for the BCSequence classes, there is no more excuse for us to delay this ;-) cheers, - Koen. From james.balhoff at duke.edu Thu Feb 17 07:36:41 2005 From: james.balhoff at duke.edu (Jim Balhoff) Date: Thu, 17 Feb 2005 07:36:41 -0500 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: Message-ID: <6d0fe15f186e61ac22d95eebea3c1c1a@duke.edu> On Feb 17, 2005, at 4:38 AM, Alexander Griekspoor wrote: > Also, I think (might be wrong here) that by now 90% of the people run > 10.3. Here are some interesting statistics: Jim ____________________________________________ James P. Balhoff Dept. of Biology Duke University Durham, NC 27708-0338 USA From mek at mekentosj.com Thu Feb 17 08:33:33 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 17 Feb 2005 14:33:33 +0100 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: <6d0fe15f186e61ac22d95eebea3c1c1a@duke.edu> References: <6d0fe15f186e61ac22d95eebea3c1c1a@duke.edu> Message-ID: <9b64fbd7e3b26f31010b268b17245567@mekentosj.com> ok 95.2%, I was wrong but on the right side ;-) On 17-feb-05, at 13:36, Jim Balhoff wrote: > On Feb 17, 2005, at 4:38 AM, Alexander Griekspoor wrote: > >> Also, I think (might be wrong here) that by now 90% of the people run >> 10.3. > > Here are some interesting statistics: > > > > > Jim > > ____________________________________________ > James P. Balhoff > Dept. of Biology > Duke University > Durham, NC 27708-0338 > USA > > > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com 4Peaks - For Peaks, Four Peaks. 2004 Winner of the Apple Design Awards Best Mac OS X Student Product http://www.mekentosj.com/4peaks ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1383 bytes Desc: not available URL: From jtimmer at bellatlantic.net Thu Feb 17 11:11:09 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 17 Feb 2005 11:11:09 -0500 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: <6d0fe15f186e61ac22d95eebea3c1c1a@duke.edu> Message-ID: My guess is that those stats are an over-estimation of the rate for the people we'd be writing software for. People who buy Omni products are those who care about their software, which means they're more likely to update their OS. Their target market doesn't include the "set it up and leave it alone if it isn't broken" population, and based on my rough survey around where I've been working, that group is over-represented in biology. That said, it should be possible to create a "modern" branch of our classes. Given the number of changes I think we'd have to make, I'd say we'd need to keep that a separate project, or we'd ifdef things beyond readability. The other thing I'd say is that we should just target it at 10.4 using CoreData. The big difference in 10.3 was the addition of bindings via key/value coding and observing. By targeting CoreData, we get both of those, plus object storage and undo management for free. And I was disappointed to see that CoreData's still NDA'd beyond what's here: http://developer.apple.com/macosx/tiger/ They'd started giving details on a bunch of things like Spotlight and 64-bitness, and I'd assumed they'd done one for CoreData as well. There's enough there to say a couple of things, though. The key phrases in that description are: "Cocoa can manage your data objects themselves through the power of Core Data, providing automatic undo/redo support, additional user interface synchronization, and data consistency, correctness, and speed enhancements when it's time to write to disk." And: " A high-performance, SQLite-based database file format" As these indicate, CoreData should allow you to treat a database as an object store, meaning if you can write a database query that will produce a specific object or list of objects, you can just send that query into the CoreData store to get all the objects out. This should mean that you no longer have to pass specific references to objects all over your application, and can bind to them painlessly. The trick is that, to make the queries and bindings work, you have to make everything you store key/value coding compliant. We'd need to do a lot of work to get there. There's other issues as well, but there's not enough in that short description to allow me to bring them up here. John >> Also, I think (might be wrong here) that by now 90% of the people run >> 10.3. > > Here are some interesting statistics: > > > > > Jim _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Thu Feb 17 11:22:44 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 17 Feb 2005 17:22:44 +0100 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: Message-ID: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> > My guess is that those stats are an over-estimation of the rate for the > people we'd be writing software for. No doubt this is not a representative sample, you're absolutely right, but I do stick to my 80-90% conversion to 10.3. Yes, there are those machines which are never upgraded, but these are often shared, or say hooked to a scanner or machine. Macs that people work enthusiastically on are often happily updated by the user. Anyway, you nicely dodge the question ;-) Yes, a 10.4 version would be nice as a separate branch, but in my opinion the base version should be lifted to 10.3 instead of 10.2. You mention the reason yourself: > The trick is that, to make the queries and bindings work, you have to > make everything you store > key/value coding compliant. We'd need to do a lot of work to get > there. And the KVC, KVO protocols are first of all easy to implement, second it gives you bindings for (almost) free and IMHO all classes we produce should be compatible (even if you make the 10.2 compatible), key value coding (using accessors) is something we do already anyway. It's not difficult and not that much of work actually. Switching to 10.3 has two main advantages, first the binding possibilities, second that it forms a much stronger basis for a 10.4 version with WAY less differences (read: less work). I still think there might be possibilities to actually implement the 10.4 part as an extension (through categories?) on top of a base 10.3 version, but if the differences are too big we might end up with two different ones. With 10.2 as a base, the latter is truly the only solution. Remember, right now 10% is on 10.2, once Tiger will be out that will drop to even less (I know people who will skip 10.3 but will go for 10.4), and our framework isn't even out yet (add a few months) and the first app will come even later right (add even a few more months), who will still use 10.2 by then? Cheers, Alex > > There's other issues as well, but there's not enough in that short > description to allow me to bring them up here. > > John > > >>> Also, I think (might be wrong here) that by now 90% of the people run >>> 10.3. >> >> Here are some interesting statistics: >> >> >> >> >> Jim > > _______________________________________________ > This mind intentionally left blank > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From charles.parnot at stanford.edu Thu Feb 17 14:19:14 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 17 Feb 2005 11:19:14 -0800 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> Message-ID: >And the KVC, KVO protocols are first of all easy to implement, second it gives you bindings for (almost) free and IMHO all classes we produce should be compatible (even if you make the 10.2 compatible), key value coding (using accessors) is something we do already anyway. It's not difficult and not that much of work actually. I do agree with Alex that KVC should be fairly easy to add. I also do like John's idea of sticking to 10.2 as much as possible, which should be possible with KVC. I also know that there are some differences which could get quite annoying, and that the 10.2 KVC is not as consistent and usable as the KVC in 10.3... but that may be fixable with some NSObject category. Anyway, after all these however/but, the bottom line is: my opinion is we should try to implement KVC asap and at the same time, stick to the 10.2 APIs as long as possible. Regarding other 10.3-sepcific APIs, here are the questions we should answer (in particular Alex): * Alex, what APIs other than binding are you refering to? Can we narrow down to just bindings the question of '10.2 vs 10.3'? Are there any other critical super-useful 1.3-specifc APIs that we are going to use? (e.g. NSIndexSet --> possible work-arounds) * Then, about bindings: are there really any use of bindings at the framework level? The bindings would be in the app, right? We would just have to be KVC-compliant in the framework. Do the bindings use 10.2 deprecated methods when forced to? >Remember, right now 10% is on 10.2, once Tiger will be out that will drop to even less (I know people who will skip 10.3 but will go for 10.4), and our framework isn't even out yet (add a few months) and the first app will come even later right (add even a few more months), who will still use 10.2 by then? Probably true, future will tell. My prediction: there will be 5% people stuck at 10.2 for a long long time! charles NB: and yes, Koen, we should just be coding instead of chatting, for God's sake! -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 17 14:21:40 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 17 Feb 2005 11:21:40 -0800 Subject: [Biococoa-dev] Re: CoreData In-Reply-To: References: Message-ID: >... >And: " A high-performance, SQLite-based database file format" > >As these indicate, CoreData should allow you to treat a database as an >object store, meaning if you can write a database query that will produce a >specific object or list of objects, you can just send that query into the >CoreData store to get all the objects out. This should mean that you no >longer have to pass specific references to objects all over your >application, and can bind to them painlessly. The trick is that, to make >the queries and bindings work, you have to make everything you store >key/value coding compliant. We'd need to do a lot of work to get there. Thanks for the explanation. I have a much much better sense of what it is. Going KVC looks like a reasonable first step. Let's do that! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Thu Feb 17 15:23:00 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 17 Feb 2005 21:23:00 +0100 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> Message-ID: <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> > I do agree with Alex that KVC should be fairly easy to add. I also do > like John's idea of sticking to 10.2 as much as possible, which should > be possible with KVC. I also know that there are some differences > which could get quite annoying, and that the 10.2 KVC is not as > consistent and usable as the KVC in 10.3... but that may be fixable > with some NSObject category. Anyway, after all these however/but, the > bottom line is: my opinion is we should try to implement KVC asap and > at the same time, stick to the 10.2 APIs as long as possible. > > Regarding other 10.3-sepcific APIs, here are the questions we should > answer (in particular Alex): > * Alex, what APIs other than binding are you refering to? Can we > narrow down to just bindings the question of '10.2 vs 10.3'? Are there > any other critical super-useful 1.3-specifc APIs that we are going to > use? (e.g. NSIndexSet --> possible work-arounds) > * Then, about bindings: are there really any use of bindings at the > framework level? The bindings would be in the app, right? We would > just have to be KVC-compliant in the framework. Do the bindings use > 10.2 deprecated methods when forced to? Ok, sorry but I was indeed specifically referring to a (future) appkit side of the framework, not the foundation part (what we're working on right now). This originated from the discussion about a demo app with "webview" like view, that would really shine if it has binding support. You're perfectly right that for the foundation (model) part we can happily stick with 10.2 support, for bindings you indeed only need KVC basically (which we implement already). The rest is in the controller and view. I don't think that besides bindings there are many things we can't do without in 10.3, that I can think of (like NSXMLParser, there are plenty core foundation routines in 10.2 already). The point was not to specifically start using all possible 10.3 options, but just to make the point that 10.2 support is not that important anymore IMHO. Even if 5% sticks with it, that would not justify refraining to advance/optimize our framework. But again, as long as we can stick (if necessary with a bit of effort) to 10.2 compliancy in the foundation, that's a big plus of course. If we go for an Appkit part (views etc) I would go for 10.3 from the beginning though, primarily for the bindings part. > NB: and yes, Koen, we should just be coding instead of chatting, for > God's sake! Sorry, yes boss, I'll see what I can do ;-) Alex > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* From charles.parnot at stanford.edu Thu Feb 17 16:13:13 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 17 Feb 2005 13:13:13 -0800 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> Message-ID: >If we go for an Appkit part (views etc) I would go for 10.3 from the beginning though, primarily for the bindings part. OK. I am not familiar with OS-specific developement: does that mean we need two separate targets, one for the Foundation and one for the AppKit? >>NB: and yes, Koen, we should just be coding instead of chatting, for God's sake! >Sorry, yes boss, I'll see what I can do ;-) >Alex BTW, I have been looking the day before yesterday at how/if we could have unit tests implemented in parallel to the framework. I was following John's steps (I think) and what he implemented in the translation example. I alredy wrote some code using OCUnit, and it looks like something we could really use and is very easy to implement. Particularly with future development and the intense refactoring and feature addition that are going to happen ;-) I will make it available to you the code so far so you can look and tell me what you think charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Thu Feb 17 16:42:40 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 17 Feb 2005 22:42:40 +0100 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> Message-ID: >> If we go for an Appkit part (views etc) I would go for 10.3 from the >> beginning though, primarily for the bindings part. > > OK. I am not familiar with OS-specific developement: does that mean we > need two separate targets, one for the Foundation and one for the > AppKit? Yep, it basically means you get two frameworks (like appkit and foundation or two separate frameworks, together forming cocoa). We can simply have two targets, BCFoundation and BCAppkit both having their own sdk to build against (10.2 and 10.3, respectively). Last time I did the main cleanup the first thing I did was to put all current development in a BCFoundation folder leaving space for a BCAppkit folder at the root level. >>> NB: and yes, Koen, we should just be coding instead of chatting, for >>> God's sake! >> Sorry, yes boss, I'll see what I can do ;-) >> Alex > > BTW, I have been looking the day before yesterday at how/if we could > have unit tests implemented in parallel to the framework. I was > following John's steps (I think) and what he implemented in the > translation example. I alredy wrote some code using OCUnit, and it > looks like something we could really use and is very easy to > implement. Particularly with future development and the intense > refactoring and feature addition that are going to happen ;-) I will > make it available to you the code so far so you can look and tell me > what you think Sounds interesting, a few days ago I spoke Serge Cohen who was using OCUnit (or one of the variants, I'll ask him which) as well in his project and was pretty enthusiastic about it. I haven't used it myself, but if it is trivial to add I can certainly see the advantage. Cheers, Alex > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* From kvddrift at earthlink.net Thu Feb 17 21:17:17 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 17 Feb 2005 21:17:17 -0500 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> Message-ID: <7aa11e84e2d4c196e6f67293812c7f91@earthlink.net> On Feb 17, 2005, at 3:23 PM, Alexander Griekspoor wrote: > If we go for an Appkit part (views etc) I would go for 10.3 from the > beginning though, primarily for the bindings part. I don't see the advantage of adding all sorts of views to the framework. I guess when users want to implement the sequence handling part they will create their own sequence viewers, etc. For instance, we supply the code to search for a subsequence, but how this is implemented in a window is up to the user. Every app is different, so will have different demands on the views it uses. That said, if we decide to add specialized views for users, maybe we can supply them as IB palettes? BTW, so far nobody noticed the typo in the subject ;-p - Koen. From charles.parnot at stanford.edu Thu Feb 17 21:29:35 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 17 Feb 2005 18:29:35 -0800 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: <7aa11e84e2d4c196e6f67293812c7f91@earthlink.net> References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> <7aa11e84e2d4c196e6f67293812c7f91@earthlink.net> Message-ID: >On Feb 17, 2005, at 3:23 PM, Alexander Griekspoor wrote: > >>If we go for an Appkit part (views etc) I would go for 10.3 from the beginning though, primarily for the bindings part. > > >I don't see the advantage of adding all sorts of views to the framework. I guess when users want to implement the sequence handling part they will create their own sequence viewers, etc. For instance, we supply the code to search for a subsequence, but how this is implemented in a window is up to the user. Every app is different, so will have different demands on the views it uses. That said, if we decide to add specialized views for users, maybe we can supply them as IB palettes? I think a simple BCSequenceView would be nice. Besides, we are not forcing anybody to use it. But it can be useful for applications not necessarily sequence-centric, like a pdb viewer that wants to display sequences without too much code to add. I am still unsure how bindings could be useful, but I trust Alex on that and we will see what he comes up with (and I don't think there is much we can do to slow him down now...). > >BTW, so far nobody noticed the typo in the subject ;-p I actually corrected the spelling in my message j1HJLgWY017185 , Thu, 17 Feb 2005 11:21:40 -0800, [Biococoa-dev] Re: CoreData. My mistake :-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Fri Feb 18 04:15:52 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Fri, 18 Feb 2005 10:15:52 +0100 Subject: CoreData (was: [Biococoa-dev] CoreDate ;-) In-Reply-To: References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> <7aa11e84e2d4c196e6f67293812c7f91@earthlink.net> Message-ID: >> I don't see the advantage of adding all sorts of views to the >> framework. I guess when users want to implement the sequence handling >> part they will create their own sequence viewers, etc. For instance, >> we supply the code to search for a subsequence, but how this is >> implemented in a window is up to the user. Every app is different, so >> will have different demands on the views it uses. That said, if we >> decide to add specialized views for users, maybe we can supply them >> as IB palettes? > > I think a simple BCSequenceView would be nice. Besides, we are not > forcing anybody to use it. But it can be useful for applications not > necessarily sequence-centric, like a pdb viewer that wants to display > sequences without too much code to add. Exactly, I totally agree with Charles. We don't need a complete editing/vector dnastrider like view, but a simple sequenceview (with line numbers) is very nice. And I was also thinking more in the direction of for instance a standard entrez search window, like I will use in the upcoming enzymex update. Think on things like the Addressbook lookuppanel. And yes, that should become IB palettes... > > I am still unsure how bindings could be useful, but I trust Alex on > that and we will see what he comes up with (and I don't think there is > much we can do to slow him down now...). Oh there are plenty of things that can (and will) slow me down ;-) Alex ************************************************************** ** Alexander Griekspoor ** ************************************************************** The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From kvddrift at earthlink.net Fri Feb 18 05:37:17 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 18 Feb 2005 05:37:17 -0500 Subject: CoreData (was: [Biococoa-dev] CoreDate ;-) In-Reply-To: References: <16e68499e0997fc99098f5ed30dd1454@mekentosj.com> <09b9c5c9911238f3599ea5cd69edfa33@mekentosj.com> <7aa11e84e2d4c196e6f67293812c7f91@earthlink.net> Message-ID: <0930bce4f82569c8b25b6181c47e2070@earthlink.net> On Feb 18, 2005, at 4:15 AM, Alexander Griekspoor wrote: > Exactly, I totally agree with Charles. We don't need a complete > editing/vector dnastrider like view, but a simple sequenceview (with > line numbers) is very nice. And I was also thinking more in the > direction of for instance a standard entrez search window, like I will > use in the upcoming enzymex update. Think on things like the > Addressbook lookuppanel. And yes, that should become IB palettes... > Yes, that sounds like a good idea. I might have some code also for linenumbers ;-) - Koen. From jtimmer at bellatlantic.net Fri Feb 18 11:45:51 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Fri, 18 Feb 2005 11:45:51 -0500 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: Message-ID: > > BTW, I have been looking the day before yesterday at how/if we could have unit > tests implemented in parallel to the framework. I was following John's steps > (I think) and what he implemented in the translation example. I alredy wrote > some code using OCUnit, and it looks like something we could really use and is > very easy to implement. Particularly with future development and the intense > refactoring and feature addition that are going to happen ;-) I will make it > available to you the code so far so you can look and tell me what you think Any resemblance between what I did and reasonable unit testing was purely coincidental. I just get nervous about writing too much code without checking whether it works. That said, I'm quite interested in learning good practices like this. Is there a good resource online to read up on the principles and practices of unit testing? One that's appropriate for someone with about 5 minutes of free time on my average day? Cheers, JT _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Fri Feb 18 12:12:11 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Fri, 18 Feb 2005 18:12:11 +0100 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: Message-ID: <7ac11b3a726dc5da6c2f074d25b45403@mekentosj.com> Same here! On 18-feb-05, at 17:45, John Timmer wrote: > >> >> BTW, I have been looking the day before yesterday at how/if we could >> have unit >> tests implemented in parallel to the framework. I was following >> John's steps >> (I think) and what he implemented in the translation example. I >> alredy wrote >> some code using OCUnit, and it looks like something we could really >> use and is >> very easy to implement. Particularly with future development and the >> intense >> refactoring and feature addition that are going to happen ;-) I >> will make it >> available to you the code so far so you can look and tell me what you >> think > > Any resemblance between what I did and reasonable unit testing was > purely > coincidental. I just get nervous about writing too much code without > checking whether it works. That said, I'm quite interested in > learning good > practices like this. Is there a good resource online to read up on the > principles and practices of unit testing? One that's appropriate for > someone with about 5 minutes of free time on my average day? > > Cheers, > > JT > > _______________________________________________ > This mind intentionally left blank > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* From kvddrift at earthlink.net Fri Feb 18 17:53:33 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 18 Feb 2005 17:53:33 -0500 Subject: CoreDate (was: [Biococoa-dev] WWDC2005) In-Reply-To: References: Message-ID: <2327360fde8ecab16df25c2241ae0235@earthlink.net> On Feb 18, 2005, at 11:45 AM, John Timmer wrote: > Is there a good resource online to read up on the > principles and practices of unit testing? One that's appropriate for > someone with about 5 minutes of free time on my average day? Maybe: http://www.cocoadev.com/index.pl?UnitTesting - Koen. (who also has no clue about what unit testing is ;-) From kvddrift at earthlink.net Fri Feb 18 20:37:01 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 18 Feb 2005 20:37:01 -0500 Subject: [Biococoa-dev] Annotation Message-ID: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> Hi, This weekend I might be trying to implement the code for annotations. Unless someone else feels the urge to do so ;-) I noticed that Charles has added the following instance variable to BCAbstractSequence.h: NSMutableArray *annotationArray; //coming soon!! Not sure what you had in mind here, Charles. Would this be an array of BCAnnotation objects? In that case each BCAnnotation object would be take care of just one annotation. However, I suggest we use a NSDictionary instead. The next decision would be if we add a NSMutableDictionary variable to the sequence, or create a separate BCAnnotations class that manages the annotations (basically a wrapper). In the latter case, to add a annotation, we could use the following code [mySequence addAnnotation: @"value" forKey: @"key"]; This will then call in BCAbstractSequence - (id) addAnnotation:(NSString *)aValue forKey:(NSString *) aKey { [[self annotations] addAnnotation: aValue forKey: aKey]; } And then in BCAnnotations: - (id) addAnnotation:(NSString *)aValue forKey:(NSString *) aKey { [[self annotationDictionary] setObject: aValue forKey: aKey]; } etc. It seems redundant to add almost two similar calls, my thought here is is that if we keep the interaction with the dictionary in a wrapper, it becomes easier to change things, and add more possibilities (searching, eg). What do you think of this approach? cheers, - Koen. From charles.parnot at stanford.edu Fri Feb 18 23:50:26 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 18 Feb 2005 20:50:26 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> Message-ID: It seems logical and simple to start with the ivar being a dictionary, and I afree this is better than an array for the reasons you say. I would not add a BCAnnotations class. But some constant for some important keys would be useful. The real question is what can be an annotation? It seems that for most databases and sequence file formats, a key-value design is very appropriate, right? have a nice week-end! charles At 8:37 PM -0500 2/18/05, Koen van der Drift wrote: >Hi, > >This weekend I might be trying to implement the code for annotations. Unless someone else feels the urge to do so ;-) I noticed that Charles has added the following instance variable to BCAbstractSequence.h: > >NSMutableArray *annotationArray; //coming soon!! > > >Not sure what you had in mind here, Charles. Would this be an array of BCAnnotation objects? In that case each BCAnnotation object would be take care of just one annotation. However, I suggest we use a NSDictionary instead. The next decision would be if we add a NSMutableDictionary variable to the sequence, or create a separate BCAnnotations class that manages the annotations (basically a wrapper). In the latter case, to add a annotation, we could use the following code > > >[mySequence addAnnotation: @"value" forKey: @"key"]; > > >This will then call in BCAbstractSequence > >- (id) addAnnotation:(NSString *)aValue forKey:(NSString *) aKey >{ > [[self annotations] addAnnotation: aValue forKey: aKey]; >} > > >And then in BCAnnotations: > >- (id) addAnnotation:(NSString *)aValue forKey:(NSString *) aKey >{ > [[self annotationDictionary] setObject: aValue forKey: aKey]; >} > >etc. > >It seems redundant to add almost two similar calls, my thought here is is that if we keep the interaction with the dictionary in a wrapper, it becomes easier to change things, and add more possibilities (searching, eg). > > > >What do you think of this approach? > > >cheers, > >- Koen. > > >_______________________________________________ >Biococoa-dev mailing list >Biococoa-dev at bioinformatics.org >https://bioinformatics.org/mailman/listinfo/biococoa-dev -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Sat Feb 19 02:54:35 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 18 Feb 2005 23:54:35 -0800 Subject: [Biococoa-dev] Unit testing Message-ID: >Is there a good resource online to read up on the >principles and practices of unit testing? One that's appropriate for >someone with about 5 minutes of free time on my average day? I liked that page too: http://testkit.sourceforge.net/user/index.html (a Fixture = how you prepare your TestCase instance before running a test method) I am myself very new to it, and found the concept easy to grasp, and the implementation quite straightforward. Experience is probably needed to have a good sense of what deserves a test and what does not for a particular class in a particular project. Doing too much is a waste. Doing too little is a waste too if you end up not using the tests or not getting much from it. All the different unit test frameworks available are very similar. There are 4 important components: * A bundle provided by you. This bundle is a collection of classes, most if not all are 'TestCase' (see below). This 'test bundle' that you create is usually separate from the code you want to test. In our case, we would thus have two bundles: BioCocoa.framework and BioCocoa-test.bundle. The second bundle is the one you provide to the 'Tester' tool (see next entry) and that is being scanned for tests that need to be run. * A tool provided by the testing kit (an executable ready for use) or 'Tester' tool. You run that tool by providing it a bundle: it loads that bundle in memory, then scans all the classes and all the methods, looking for the code that needs to be run for the tests (see below the criteria that are used). So it is smart enough so you don't have to list all the tests anywhere, they are 'automatically' detected. The toool then runs the tests that were detected and logs the result as they are run, with some details about the failed tests. It counts how many tests ran, how many failed, and how long they took. * TestCase class. You are supposed to subclass this class to write tests. A test case is... well, a test case. You load some data (=initialize the test case), you run some method on it, you check the result. You load data, you run another method on it, you check the result... For each test, you reload the data. This is done automatically by the 'Tester' tool mentioned above. If the tool determines that your class is a subclass of TestCase, it will look for all the methods that start with 'test' and for each of these methods, it will create an instance, run the first test method, dealloc the instance. Then again, create an instance, run the second test method, dealloc the instance.... All this for all the subclasses of TestCase found in the bundle. This means that you have to write some methods with names starting with 'test' and that will run some code. And the tool takes care of running the test for you. * Assertion macros. Inside your 'test' methods, you will test things, right? Well, to tell the 'Tester' program how things are going, you call macros for your tests, e.g. Assert_Equality(object1,object2). These macros notifies the 'Tester' tool of the failures, and useful log messages are being displayed. Now, some code! Here is my first test class and test bundle ever: http://cmgm.stanford.edu/~cparnot/temp/BioCocoa-test.zip (you have to install OCUnit first and maybe adjust the paths) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Sat Feb 19 07:04:26 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 19 Feb 2005 07:04:26 -0500 Subject: [Biococoa-dev] Unit testing In-Reply-To: References: Message-ID: On Feb 19, 2005, at 2:54 AM, Charles PARNOT wrote: > Now, some code! > Here is my first test class and test bundle ever: > http://cmgm.stanford.edu/~cparnot/temp/BioCocoa-test.zip > (you have to install OCUnit first and maybe adjust the paths) > Thanks Charles, good initiative. Unfortunately, I cannot build it, I get a lot of errors that it cannot find the BioCocoa headers. Maybe it has to do with the removal of '../' you did a few days ago? (And yes, I checked the paths to the BioCocoa and OCUnit frameworks on my HD ;-) - Koen. From kvddrift at earthlink.net Sat Feb 19 07:07:59 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 19 Feb 2005 07:07:59 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> Message-ID: <31dd32986d69459081f0341038086de3@earthlink.net> On Feb 18, 2005, at 11:50 PM, Charles PARNOT wrote: > The real question is what can be an annotation? It seems that for most > databases and sequence file formats, a key-value design is very > appropriate, right? > > Correct. However, almost every file format uses a different string for the 'key'. For instance for SwissProt, the key for the sequence is 'SQ' while for PDB it is 'SEQRES'. So should we just use what each file format uses, or should we try to make them all the same. Especially when writing a format, we need a good way to convert from one key to another. Anyone has an idea how to do this? cheers, - Koen. From kvddrift at earthlink.net Sat Feb 19 07:34:57 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 19 Feb 2005 07:34:57 -0500 Subject: [Biococoa-dev] Unit testing In-Reply-To: References: Message-ID: On Feb 19, 2005, at 2:54 AM, Charles PARNOT wrote: > Here is my first test class and test bundle ever: > http://cmgm.stanford.edu/~cparnot/temp/BioCocoa-test.zip > (you have to install OCUnit first and maybe adjust the paths) > Oh, one more thing. Right now the BioCocoa-test target is a framework. Shouldn't it be a application? - Koen. From charles.parnot at stanford.edu Sat Feb 19 12:58:02 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 19 Feb 2005 09:58:02 -0800 Subject: [Biococoa-dev] Unit testing In-Reply-To: References: Message-ID: At 7:04 AM -0500 2/19/05, Koen van der Drift wrote: >On Feb 19, 2005, at 2:54 AM, Charles PARNOT wrote: > >>Now, some code! >>Here is my first test class and test bundle ever: >>http://cmgm.stanford.edu/~cparnot/temp/BioCocoa-test.zip >>(you have to install OCUnit first and maybe adjust the paths) >> > >Thanks Charles, good initiative. Unfortunately, I cannot build it, I get a lot of errors that it cannot find the BioCocoa headers. Maybe it has to do with the removal of '../' you did a few days ago? (And yes, I checked the paths to the BioCocoa and OCUnit frameworks on my HD ;-) > >- Koen. If you get the 'cannot find file ../BC....h', then yes, you need to update your BioCocoa project and rebuild it. These updates were made after trying to build my test bundle and would show up from any project linking the BioCocoa framework, because the compiler can't resolve the paths and can't find the header files. Let me know if that still does not work! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Sat Feb 19 13:01:31 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 19 Feb 2005 10:01:31 -0800 Subject: [Biococoa-dev] Unit testing In-Reply-To: References: Message-ID: At 7:34 AM -0500 2/19/05, Koen van der Drift wrote: >On Feb 19, 2005, at 2:54 AM, Charles PARNOT wrote: > >>Here is my first test class and test bundle ever: >>http://cmgm.stanford.edu/~cparnot/temp/BioCocoa-test.zip >>(you have to install OCUnit first and maybe adjust the paths) >> > >Oh, one more thing. Right now the BioCocoa-test target is a framework. Shouldn't it be a application? > > >- Koen. The executable is the OCUnit tool, which takes the bundle as an argument. In fact, you can even bypass the tool by having the test run during the build, using a shell script (you can reactivate it, it is already in the target but I set it to run only during deployment builds). Of course, the line between an executable and a shell script is blurry. It is basically the same thing... charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Sat Feb 19 14:54:14 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 19 Feb 2005 14:54:14 -0500 Subject: [Biococoa-dev] Unit testing In-Reply-To: References: Message-ID: On Feb 19, 2005, at 12:58 PM, Charles PARNOT wrote: > If you get the 'cannot find file ../BC....h', then yes, you need to > update your BioCocoa project and rebuild it. These updates were made > after trying to build my test bundle and would show up from any > project linking the BioCocoa framework, because the compiler can't > resolve the paths and can't find the header files. > > Let me know if that still does not work! > Just in case, I did a fresh checkout of BioCocoa. However, I still get the errors: not found :( - Koen. From kvddrift at earthlink.net Sat Feb 19 15:26:30 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 19 Feb 2005 15:26:30 -0500 Subject: [Biococoa-dev] Unit testing In-Reply-To: References: Message-ID: On Feb 19, 2005, at 12:58 PM, Charles PARNOT wrote: > If you get the 'cannot find file ../BC....h', then yes, you need to > update your BioCocoa project and rebuild it. These updates were made > after trying to build my test bundle and would show up from any > project linking the BioCocoa framework, because the compiler can't > resolve the paths and can't find the header files. > > Let me know if that still does not work! > > charles > Aha, solved. Instead of changing the path of the framework, I removed it and re-added it using the 'Add Existing Framework' command. Now it builds fine. Nect, I need to figure out how to test the test. sorry for the noise ;-) - Koen. From kvddrift at earthlink.net Sun Feb 20 11:43:32 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 20 Feb 2005 11:43:32 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> Message-ID: <1fa9e0310afca70fed442cba40e730dc@earthlink.net> Hi, I added some initial code for annotations to BioCocoa. BCAbstractSequence has 2 methods to set and get annotations. To test the code, I added some lines to readSwissProt in BCSequenceReader. When I compile the code, I get a warning that BCSequenceProtein might not respond to the addAnnotation (which I added to BCAbstractSequence). Also, when I step through the code, no annotations are added. Should I add the code as well to seach subclass of BCAbstractSequence to make this work? That seems rather redundant to me. I guess I still not completely understand how the class cluster code works. Charles, maybe you can add some documentation about this in the developer docs folder? cheers, - Koen. From charles.parnot at stanford.edu Sun Feb 20 14:05:04 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sun, 20 Feb 2005 11:05:04 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <1fa9e0310afca70fed442cba40e730dc@earthlink.net> References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> Message-ID: It is because you have not #import-ed the BCSequenceProtein header, so the compiler does not know it is a subclass of BCAbstractSequence. It knows that it is a class, though, because you have the @class statement in the header of BCSequenceReade (otherwise you would get a compiler error). It is my plan to put more info about BCSequence. BTW, it is NOT a class cluster (it would be if there was only one public class with private subclass), it is simply a placeholder class. When you use the other subclasses of BCAbtractSequence, everything just works like a normal class-subclass design, and BCSequence won't interfere. When you use BCSequence, things get more subtle at runtime, but you can ignore them for the most part... In other words, the magic is at runtime, but the compiler behavior is quite strightforward: if it has not heard of a class, you get an error; if it has not heard of a mehod, you get a warning. BCSequenceReader should probably be able to return a BCAbstractSequence instance now, with methods like: -(BCSequence *)sequence; -(BCSequenceProtein *)proteinSequence; ...etc... that the user could call depending on what she wants (strong typing or weak typing). charles At 11:43 AM -0500 2/20/05, Koen van der Drift wrote: >Hi, > >I added some initial code for annotations to BioCocoa. BCAbstractSequence has 2 methods to set and get annotations. To test the code, I added some lines to readSwissProt in BCSequenceReader. When I compile the code, I get a warning that BCSequenceProtein might not respond to the addAnnotation (which I added to BCAbstractSequence). Also, when I step through the code, no annotations are added. Should I add the code as well to seach subclass of BCAbstractSequence to make this work? That seems rather redundant to me. I guess I still not completely understand how the class cluster code works. Charles, maybe you can add some documentation about this in the developer docs folder? > > >cheers, > >- Koen. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Sun Feb 20 21:46:06 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 20 Feb 2005 21:46:06 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> Message-ID: <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> On Feb 20, 2005, at 2:05 PM, Charles PARNOT wrote: > It is because you have not #import-ed the BCSequenceProtein header, so > the compiler does not know it is a subclass of BCAbstractSequence. Thanks - I added some more code and fixes. If everyone agress this is the right approach for the annotations, I will start adding more code. cheers, - Koen. From charles.parnot at stanford.edu Mon Feb 21 01:42:32 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sun, 20 Feb 2005 22:42:32 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: At 9:46 PM -0500 2/20/05, Koen van der Drift wrote: >On Feb 20, 2005, at 2:05 PM, Charles PARNOT wrote: > >>It is because you have not #import-ed the BCSequenceProtein header, so the compiler does not know it is a subclass of BCAbstractSequence. > > >Thanks - I added some more code and fixes. If everyone agress this is the right approach for the annotations, I will start adding more code. > > >cheers, > >- Koen. I do think the NSMutableDictionary is very appropriate for annotations. Regarding the current implementation, it looks good to me. My only comment is I don't think we need a 'setAnnotations:' method. This is a bit dangerous, particularly with a mutable dictionary as argument. Instead, methods 'removeAnnotationWithKey:', 'removeAllAnnotations' and 'addAnnotationsFromDictionary:' will do the job. BTW, I corrected some of the code because I needed the compiled framework for the testing unit thing and there was a compiler error. Let me know, guys, if and when you want me to incorporate the tests in the cvs? Also, Koen, I have one question about the symbolSet: it seems that all instances of one sequence type use the same symbol set. Is that right? Do you think it is going to stay like this, or are there special cases where we will want to change that? If this is true, we could leverage that knowledge to simplify the init methods of the sequence classes. Let me know, I can explain better what I mean. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Mon Feb 21 06:24:24 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 06:24:24 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: On Feb 21, 2005, at 1:42 AM, Charles PARNOT wrote: > I do think the NSMutableDictionary is very appropriate for > annotations. Regarding the current implementation, it looks good to > me. My only comment is I don't think we need a 'setAnnotations:' > method. This is a bit dangerous, particularly with a mutable > dictionary as argument. Instead, methods 'removeAnnotationWithKey:', > 'removeAllAnnotations' and 'addAnnotationsFromDictionary:' will do the > job. > Good point, I will comment out the method. > BTW, I corrected some of the code because I needed the compiled > framework for the testing unit thing and there was a compiler error. > Charles, somehow the changes you make are not picked up by my project. I see that files are updated in the SCM window, but the changes don't show up the source code. So far this only happens when the code changes are form Charles, I haven't seen it before. I checkedout a complete new project, but the problem remains. Anyone else has the same problem, and maybe knows how to fix it? > Also, Koen, I have one question about the symbolSet: it seems that all > instances of one sequence type use the same symbol set. Is that right? No, each sequence should have it's own symbolset, just like each sequence has its own symbolArray. - Koen. From mek at mekentosj.com Mon Feb 21 09:57:36 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Mon, 21 Feb 2005 15:57:36 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: <81f616f1a4c65dfa05bc0c5b62aaaaee@mekentosj.com> > Charles, somehow the changes you make are not picked up by my project. > I see that files are updated in the SCM window, but the changes don't > show up the source code. So far this only happens when the code > changes are form Charles, I haven't seen it before. I checkedout a > complete new project, but the problem remains. Anyone else has the > same problem, and maybe knows how to fix it? Sorry, I haven't followed the exact changes so can't judge if they're present in my checkout... More coming up... Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* From mek at mekentosj.com Mon Feb 21 10:26:31 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Mon, 21 Feb 2005 16:26:31 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: <6b98457dfc2932af889c74b4728763e9@mekentosj.com> Nice work on the annotations guys, looks nice and indeed a dictionary is the obvious way to go. Just a few things that came to mind and like to share with you. Two issues with the annotations to think about. First, it would be nice to have a standard set defined for common annotations, like author, organism etc. The question of course is what list should be adhere to? The EMBL format, the NCBI format? Second, while searching the web a bit, I came along the BSML XML format which seems to become a kind of standard for new sequence formats. It would perhaps be nice (and wise) to have a look at the documents they made because they (obviously) studied the annotation/feature issue very well. You can find more info at: http://www.bsml.org/ Now, just to make sure, bsml is a file format and one we could implement of course, internally the dictionary approach is for us the way to go, but it might be an idea to adhere to there nomenclature and/or tree/hierarchy. I came already across some nice ideas to keep in mind: > As research proceeds on a given biological molecule, certain segments > of the sequence become interesting for a variety of reasons. Sequence > annotation is used to capture this extra information about the > sequence data. Positional annotation refers to annotations that are > specific to a portion of a sequence. In BSML, positional annotation is > captured through Feature tags. Feature tags are child tags of a > sequence tag, and therefore a Feature is related to a single sequence. > For example, the following tag indicates that the region between 1513 > and 1962 encodes a particular gene: > > > > complement="0"/> > So a feature is defined as a "positional annotation" which is a nice definition that I had in mind as well. Of course features give the extra problem that they have to be kept in sync during editing. Therefore it's perhaps better to internally have a dictionary of annotations and a dictionary of features. > A given DNA sequence could have many features associated with it. > Rather than simply encoding all of these flatly, in BSML related > feature tags can be aggregated into Feature-Tables. Feature-Tables are > intended to provide a logical grouping to features, such as grouping > all gene expression features together. This is nice as well, it allows to have nested annotations and features, which is perfectly possible with a dictionary of course. What do you guys think of this, to complicated or a desired feature? Basically, the dictionary approach we have right now allows us to put everything (including resources, data etc) as an annotations, we're not limited by strings and such. The question rises if we should go for an annotation/feature object (which I kind of like because it allows much more standardisation and easier addition of i.e. sorting/updating logic), or not and let the user be free to add anything he/she likes (which is still a possible with annotation objects as well of course). > An annotation can also take the form of a comparison between two > sequences. Perhaps two segments are equivalent to one another. In > order to achieve this in BSML, a tag can be used to > enclose a set of segments represented by tags. For example, > the tag shown in Listing 2 expresses that a region from sequence > AB1432 and sequence NZ5723 are equivalent. This is also a very nice thing to keep in mind. For instance it allows to backtrace how a construct was build... > One of the core strengths of BSML, however, is the availability of > public converters to translate from other formats into BSML. This > allows consumers of bioinformatics data to pull together information > from disparate sources into a single common language for their > research. Surprisingly enough, many of these converters were not > developed by LabBook, the company driving BSML as a standard, but > rather from third-party adopters and supporters of BSML. For example, > Bristol-Myers Squibb has release an open-source adapter into the > BioPerl project that translates between the SeqIO format and BSML. > Similarly, Cold Spring Harbor Laboratory has released a translator > between the ASN.1 format used by GenBank and BSML. The European > Bioinformatics Institute provides a translation between EMBL documents > and BSML. Every day more and more translators become available, making > it possible for researchers and application developers to build tools > around BSML while accessing a variety of data sources. This is nice as well of course, by mirroring to some extend the setup of BSML internally we can use these adopters to more easily implement the reader/writer classes instead of reinventing the wheel... Finally, just a thinking out loud here, if we go for a number of often used pre-defined tags for annotations and features, how do we then "define" them? Perhaps it's nice to have a category added to the BCAbstractSequence class, i.e. annotation-extensions that predefines methods to add these predefined methods like: -(NSString *)authorname; -setAuthorname: (NSString *)author; -(NSCalendarDate *)creationdate; -setCreationdate: (NSCalendarDate *)date; (note the possibility to return a calendardate instead of string, this way we ensure that all dates will be created equally instead of someone entering: 20-2-2003 and the other 2/20/2003). etc, including things like predefined position specific annotations (aka features). Although I'm not a fan of categories in frameworks, here it might be a nice way to separate the code instead of adding all these things in the abstract sequence class. Just an idea though... Cheers, Alex On 21-feb-05, at 7:42, Charles PARNOT wrote: > At 9:46 PM -0500 2/20/05, Koen van der Drift wrote: >> On Feb 20, 2005, at 2:05 PM, Charles PARNOT wrote: >> >>> It is because you have not #import-ed the BCSequenceProtein header, >>> so the compiler does not know it is a subclass of >>> BCAbstractSequence. >> >> >> Thanks - I added some more code and fixes. If everyone agress this is >> the right approach for the annotations, I will start adding more >> code. >> >> >> cheers, >> >> - Koen. > > I do think the NSMutableDictionary is very appropriate for > annotations. Regarding the current implementation, it looks good to > me. My only comment is I don't think we need a 'setAnnotations:' > method. This is a bit dangerous, particularly with a mutable > dictionary as argument. Instead, methods 'removeAnnotationWithKey:', > 'removeAllAnnotations' and 'addAnnotationsFromDictionary:' will do the > job. > > BTW, I corrected some of the code because I needed the compiled > framework for the testing unit thing and there was a compiler error. > > Let me know, guys, if and when you want me to incorporate the tests in > the cvs? > > Also, Koen, I have one question about the symbolSet: it seems that all > instances of one sequence type use the same symbol set. Is that right? > Do you think it is going to stay like this, or are there special cases > where we will want to change that? If this is true, we could leverage > that knowledge to simplify the init methods of the sequence classes. > Let me know, I can explain better what I mean. > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 8956 bytes Desc: not available URL: From jtimmer at bellatlantic.net Mon Feb 21 11:01:45 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 21 Feb 2005 11:01:45 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: <6b98457dfc2932af889c74b4728763e9@mekentosj.com> Message-ID: > > Second, while searching the web a bit, I came along the BSML XML format which > seems to become a kind of standard for new sequence formats. It would perhaps > be nice (and wise) to have a look at the documents they made because they > (obviously) studied the annotation/feature issue very well. > You can find more info at: http://www.bsml.org/ > Now, just to make sure, bsml is a file format and one we could implement of > course, internally the dictionary approach is for us the way to go, but it > might be an idea to adhere to there nomenclature and/or tree/hierarchy. I came > already across some nice ideas to keep in mind: > >> As research proceeds on a given biological molecule, certain segments of the >> sequence become interesting for a variety of reasons. Sequence annotation is >> used to capture this extra information about the sequence data. Positional >> annotation refers to annotations that are specific to a portion of a >> sequence. In BSML, positional annotation is captured through Feature tags. >> Feature tags are child tags of a sequence tag, and therefore a Feature is >> related to a single sequence. For example, the following tag indicates that >> the region between 1513 and 1962 encodes a particular gene: >> >> >> >> > complement="0"/> >> > > So a feature is defined as a "positional annotation" which is a nice > definition that I had in mind as well. Of course features give the extra > problem that they have to be kept in sync during editing. Therefore it's > perhaps better to internally have a dictionary of annotations and a dictionary > of features. This is nice, and we should try for compatibility, but a bit difficult to work as a dictionary. The nice part is that it has a uniqueID, name, and class. The bad part is that they?re all part of the same compound field, so they don?t work nicely as the dictionary key. A related issue is that it would be really nice to be able to get annotations for every exon or every ORF without having to enumerate through the keys of the whole dictionary and check a field in each. There?s two ways I can think of doing this ? within the annotation wrapper, keep arrays for each feature type and put things into the appropriate one as they?re added. The alternative would be to make sure we write the appropriate code to do the enumeration. Personally, for performance reasons, I?d favor the first. JT _______________________________________________ This mind intentionally left blank -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.parnot at stanford.edu Mon Feb 21 12:52:32 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 09:52:32 -0800 Subject: SCM update (was: [Biococoa-dev] Annotation) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: >Charles, somehow the changes you make are not picked up by my project. I see that files are updated in the SCM window, but the changes don't show up the source code. So far this only happens when the code changes are form Charles, I haven't seen it before. I checkedout a complete new project, but the problem remains. Anyone else has the same problem, and maybe knows how to fix it? Sorry you already know the following... just in case: if the file show up in the SCM window, then you need to update them. If there is a 'U' in the SCM column, you just need to choose 'Update...from Latest' in the SCM menu or in the contextual menu. If there is a little 'C' it means you have made modifications to the version you had, but a new version has been commited since, in which case you may need to discard your changes and update (I am not sure how to merge). That said, some of my latest commits were very small, so maybe you did not notice them? Did you try to 'Compare with...Revision...' in the SCM menu to see the changes? The very last possibility is you have checked the box 'Ignore changes from Charles' in your Xcode prefs...;-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Mon Feb 21 13:10:40 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 10:10:40 -0800 Subject: symbol class and sequence class (was: [Biococoa-dev] Annotation) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: >>Also, Koen, I have one question about the symbolSet: it seems that all instances of one sequence type use the same symbol set. Is that right? >No, each sequence should have it's own symbolset, just like each sequence has its own symbolArray. Oups, I got confused. I actually meant: do you foresee that each sequence class will most of the time use a constant BCSymbol subclass? I am not sure what the BCSymbolSet will be used for. I am asking this because I am still annoyed by the fact that the BCAbstractSequence class does not have a designated initializer. This is an issue that showed up no later than yesterday, when Koen added the annotations code. You set the annotations to nil in 'initWithString...' but not in 'initWithSymbolArray'... and you should not have had to if the latter was calling the first, in other words if it was calling the 'designated initializer'. The problem is those two initializations are encoded separately and in parallel, and are also encoded in all the subclasses, where the code is repeated exactly the same except for the BCSymbol subclass used. I suggest we do the following: * each subclass implements "+ (Class)defaultSymbolClass" to return the BCSymbol subclass to use; * the initializer 'initWithString:skippingUnknownSymbols' and 'initWithSymbolArray' are fully implemented in the superclass and use 'defaultSymbolClass' to do the job; no more code needed in the subclass (except codon and BCSequence) * the designated initializer is 'initWithSymbolArray', which is called by 'initWithString:skippingUnknownSymbols' after creating a symbol array The BCSequence has to be treated separately (actually the code remains the same as now). The BCSequenceCodon will also have to be treated separately at this point because it does not use an array of symbols, but of codons. Ultimately, maybe a codon could be made a symbol subclass? Koen, let me know if that interferes with the symbolSet, because I suspect this issue may be related. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Mon Feb 21 13:23:21 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 10:23:21 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <6b98457dfc2932af889c74b4728763e9@mekentosj.com> References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> <6b98457dfc2932af889c74b4728763e9@mekentosj.com> Message-ID: At 4:26 PM +0100 2/21/05, Alexander Griekspoor wrote: >Nice work on the annotations guys, looks nice and indeed a dictionary is the obvious way to go. >Just a few things that came to mind and like to share with you. Two issues with the annotations to think about. >First, it would be nice to have a standard set defined for common annotations, like author, organism etc. The question of course is what list should be adhere to? The EMBL format, the NCBI format? > >Second, while searching the web a bit, I came along the BSML XML format which seems to become a kind of standard for new sequence formats. It would perhaps be nice (and wise) to have a look at the documents they made because they (obviously) studied the annotation/feature issue very well. >You can find more info at: http://www.bsml.org/ >Now, just to make sure, bsml is a file format and one we could implement of course, internally the dictionary approach is for us the way to go, but it might be an idea to adhere to there nomenclature and/or tree/hierarchy. I came already across some nice ideas to keep in mind: Yes, we need a standard set internal to BioCocoa. Translations to and from other formats could be easily implemented using plists. Queries for a particular key could be smart: * first look the annotation dictionary * if nil, use a dictionary look-up table to see if the query key passed as argument could be translated into another key (e.g. query key is 'species' but we could also try 'organism') * return the value ...e.g. if a query is made with the NCBI species key, but is not found in the annotation dictionary, try all the other equivalent keys of different formats, starting with the standard BioCocoa format. In addition, the query key could be added to the annotation dictionary so future queries with the same query key will be faster. Anyway, the bsml format looks like a good starting point. I am not really in the field so it is difficult to tell how widely accepted and used the format is. Whatever we choose, we will have to translate keys anyway. So we might as well choose something as general as possible and the bsml looks appropriate. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Mon Feb 21 14:16:10 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 11:16:10 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: References: Message-ID: >This is nice, and we should try for compatibility, but a bit difficult to work as a dictionary. The nice part is that it has a uniqueID, name, and class. The bad part is that they're all part of the same compound field, so they don't work nicely as the dictionary key. > >A related issue is that it would be really nice to be able to get annotations for every exon or every ORF without having to enumerate through the keys of the whole dictionary and check a field in each. There's two ways I can think of doing this - within the annotation wrapper, keep arrays for each feature type and put things into the appropriate one as they're added. The alternative would be to make sure we write the appropriate code to do the enumeration. Personally, for performance reasons, I'd favor the first. > >JT I think if we go for the bsml format, we should stick to its structure as much as possible, and not try to outsmart it for performance or readability issues. A smart structure like you suggest could be better than a simple dictionary, I agree. But we want to make sure we don't give up the flexibility, by restricting the queries to some keywords, or even to the fact that all features will have a feature type or that new tags will never be added. I suppose you have this flexibility issue in mind, but I just want to be sure! With my limited experience in data structures for xml, I know I would design a BCFeatureSet class that mimick as closely as possible the bsml/xml format. I don't know if this is really feasible or how to do it... Well, I guess I would use a dictionary, like proposed by Alex. But again, there might be nice data structures already designed for xml, out there, and maybe this is what you had in mind, John. In any case, I don't think we should worry too much about performance at this point. Enumerating through dictionaries of dictionaries or arrays of dictionaries will only create performance issues when going through tens of thousands of sequences. And even if you do go through tens of thousands of sequences, there might be many other places that will be a performance bottleneck, like simply loading the sequences from disk. Last point. It seems that Features will be complicated enough that they deserve a special class, even if it is just to wrap a dictionary. We want then to encapsulate the inner workings as much as possible and expose the minimum amount of public methods. If and when performance become an issue, we can redesign the inside and leave the outside unchanged. And with the unit testing, it will be a breeze to check the consistency of a new design;-) So here are my 'bottom line' questions and comments: * I think the annotations could be treated separately as they are now; this way we will get something that works well for annotations, which is a first step to get a useful framework; features are a completely different world with many implications; in other words, I am talking of BioCocoa 1.0 vs 1.5 ;-); if the public methods are carefully designed, it should be easy to connect the new Feature design to the current implementation of annotations when and if needed * do we need a BCFeature class? do we need a BCFeatureSet class? Probably only the latter. It seems the bsml format would require a BCFeatureSet class which could not be broken down into BCFeature elements, because it has a nested structure. If any of you has experience with data structures for xml, speak up! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Mon Feb 21 14:45:55 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Mon, 21 Feb 2005 20:45:55 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: Message-ID: <17bd8f21422204542205b787c80aee3f@mekentosj.com> > * do we need a BCFeature class? do we need a BCFeatureSet class? > Probably only the latter. It seems the bsml format would require a > BCFeatureSet class which could not be broken down into BCFeature > elements, because it has a nested structure. If any of you has > experience with data structures for xml, speak up! Yes sir, well in fact I would strongly suggest that we make BOTH a BCAnnotation AND a BCFeature class. In thought of the way BSML nicely described a feature as a special, position related, annotation, I would make BCFeature a subclass of a more general BCAnnotation class. It would only have to implement in addition the position specific methods. Now why do I want that? Because I've just seen how much better it is to have an cocoa object instead of fetching it from a plist. It offers so many advantages that I could throw away half of my code in EnzymeX a week ago ;-) An example, in EnzymeX I have 600 enzymes of which the data is in a plist. I was fetching all of it again and again from the ordinary dictionary instantiated from the plist. Say I wanted to have a button colored based on the average efficiency of Enzyme X in Buffer A from Manufacturer B. Do you know how many times I had to call "objectForKey:"? Well many many times. Now what I do is parse the plist once into custom enzyme objects and just call colorForBuffer: buf ofManufacturer: man... the logic is in the enzyme class and it knows how to calculate the efficiency and return an NSColor object: just to give you an idea what this means for your controller class: BEFORE: lEff = ([[[amershamDict objectForKey: @"L"] objectAtIndex: 0] floatValue]+ [[[amershamDict objectForKey: @"L"] objectAtIndex: 1] floatValue]) / 2; // L lColor = [NSColor colorWithCalibratedRed: [[minColorArray objectAtIndex: 0] floatValue] - ([[colorRangeArray objectAtIndex: 0] floatValue] * (lEff/100)) green: [[minColorArray objectAtIndex: 1] floatValue] - ([[colorRangeArray objectAtIndex: 1] floatValue] * (lEff/100)) blue: [[minColorArray objectAtIndex: 2] floatValue] - ([[colorRangeArray objectAtIndex: 2] floatValue] * (lEff/100)) alpha: 1.0]; [amershamBufferL setBackgroundColor: lColor]; if ([[[amershamDict objectForKey: @"L"] objectAtIndex: 0] intValue] == 100){ [amershamBufferL setStringValue: @"100%"]; }else if ([[[amershamDict objectForKey: @"L"] objectAtIndex: 0] intValue] == [[[amershamDict objectForKey: @"L"] objectAtIndex: 1] intValue]){ [amershamBufferL setStringValue: [NSString stringWithFormat: @"%d\%%", [[[amershamDict objectForKey: @"L"] objectAtIndex: 0] intValue]]]; } else { [amershamBufferL setStringValue: [NSString stringWithFormat: @"%d-%d\%%", [[[amershamDict objectForKey: @"L"] objectAtIndex: 0] intValue], [[[amershamDict objectForKey: @"L"] objectAtIndex: 1] intValue]]]; } BECAME: [amershamBufferL setBackgroundColor: [maincontroller colorForPercentage: [enz efficiencyForBuffer: @"L" ofCompany: @"Amersham"]]]; [amershamBufferL setStringValue: [enz efficiencyStringForBuffer: @"L" ofCompany: @"Amersham"]]; And this about 40 times.... It also centralizes the code to for instance calculate the color at one place (the enzyme class). But that's not all, for instance, just to call [enzymeX forwardSequence] instead of [[[dict objectForKey: enzyme] objectForKey: @"sequence"] objectForKey: @"forwardsequence"]; is a dream come true... Finally, think of sorting for a moment, how do you for instance sort all features ranked on position? With the plain dictionary approach you need to do all this in a controller object, enumerating, comparing etc In the object approach: simply call [myarrayofenzymes sortUsingSelector: @selector(sortOnPositionAscending:)]; The actual sortOnPositionAscending method in the class would be three lines of code. Simple, clean, brilliant... If we want flexibility, we should go for an annotation and feature (sub)class IMHO, Cheers, Alex Ps. Remember these can still be kept in the dictionary with a key! i.e. in EnzymeX I store all enzyme object in a dictionary with the enzyme name as its key. that way I still can get all enzyme names with a simple [enzymeDict allKeys]; instead of enumerating the whole thing again and again... > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 7454 bytes Desc: not available URL: From biococoa at bioworxx.com Mon Feb 21 16:43:20 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Mon, 21 Feb 2005 22:43:20 +0100 Subject: [Biococoa-dev] Joining the team Message-ID: <845bf012f128211b3ce338c32826ba3a@bioworxx.com> Hi, I'm a computer science & bioinformatics student from germany and very interested in the biococoa framework. I nearly finished my exams and after that i'm going to make my PhD in Bioinformatics. The programs i want to develop could partly be commercial so i'd like to know if it's possible to make biococoa lgpl or something i could use. Of course i want to contribute most of my work to the project, but my finished product won't be opensource. Please don't misunderstand me, i don't want to "rip" opensource code for commercial programs, but i think my base framework will be nearly the same what biococoa is aimed to be. So please let me know if there is a chance for me to take part in your project. cheers Phil From mek at mekentosj.com Mon Feb 21 16:55:55 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Mon, 21 Feb 2005 22:55:55 +0100 Subject: [Biococoa-dev] Joining the team In-Reply-To: <845bf012f128211b3ce338c32826ba3a@bioworxx.com> References: <845bf012f128211b3ce338c32826ba3a@bioworxx.com> Message-ID: Just to inform everyone, a few days ago Phil contacted me with a question about the WWDC. Of course, I couldn't resist asking him to join the biococoa team ;-) He asked me if the framework could be released as LGPL instead of GPL, which allows incorporation into commercial products as long as the framework is unmodified. I told him that I was not the one who could solely decide that of course and told him to raise the question on his behalf on the list. I did say that I would like to copy his request and that I basically see no problems with changing the license as we have started from scratch and have no legacy code with GPL license included anyway. But, fair enough this is something we should decide upon together, and perhaps especially Peter who started the project. What's everybody's opinion on this? Alex On 21-feb-05, at 22:43, Philipp Seibel wrote: > Hi, > > I'm a computer science & bioinformatics student from germany and very > interested in the biococoa framework. I nearly finished my exams and > after that i'm going to make my PhD in Bioinformatics. > The programs i want to develop could partly be commercial so i'd like > to know if it's possible to make biococoa lgpl or something i could > use. > Of course i want to contribute most of my work to the project, but my > finished product won't be opensource. Please don't misunderstand me, i > don't want to "rip" opensource code for commercial programs, but i > think my base framework will be nearly the same what biococoa is aimed > to be. > So please let me know if there is a chance for me to take part in your > project. > > cheers > > Phil > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From jtimmer at bellatlantic.net Mon Feb 21 17:12:46 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 21 Feb 2005 17:12:46 -0500 Subject: [Biococoa-dev] Joining the team In-Reply-To: Message-ID: I have no problems with this. If there are more options for decent software available to me, I feel it's a good thing. If BioCocoa can shorten the development time and make for cheaper software than some of the outrageously overpriced suites currently available, that's also a good thing. If someone wants to take BioCocoa and make an outrageously overpriced bit of software, then at least I know I have the same foundation to write something that will undercut their price ;). Incidentally, I thought this came up ages ago, and it was Alex who asked Peter about it then. Maybe I'm hallucinating after too much time in a darkened microscope room? JT Incidentally, what's the story for re-use of code? A hypothetical: If I were to write code for a commercial project, then donate some of that code to BioCocoa, would I then have to go back and release the code for the entire commercial product? Would I have to explicitly retain copyright to the shared code to avoid this? Hasn't been an issue yet, but if we do go CoreData, I could see it becoming one. > Just to inform everyone, a few days ago Phil contacted me with a > question about the WWDC. Of course, I couldn't resist asking him to > join the biococoa team ;-) He asked me if the framework could be > released as LGPL instead of GPL, which allows incorporation into > commercial products as long as the framework is unmodified. I told him > that I was not the one who could solely decide that of course and told > him to raise the question on his behalf on the list. I did say that I > would like to copy his request and that I basically see no problems > with changing the license as we have started from scratch and have no > legacy code with GPL license included anyway. But, fair enough this is > something we should decide upon together, and perhaps especially Peter > who started the project. > What's everybody's opinion on this? > Alex _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Mon Feb 21 17:31:58 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 17:31:58 -0500 Subject: SCM update (was: [Biococoa-dev] Annotation) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: On Feb 21, 2005, at 12:52 PM, Charles PARNOT wrote: > Sorry you already know the following... just in case: if the file show > up in the SCM window, then you need to update them. If there is a 'U' > in the SCM column, you just need to choose 'Update...from Latest' in > the SCM menu or in the contextual menu. If there is a little 'C' it > means you have made modifications to the version you had, but a new > version has been commited since, in which case you may need to discard > your changes and update (I am not sure how to merge). > > That said, some of my latest commits were very small, so maybe you did > not notice them? Did you try to 'Compare with...Revision...' in the > SCM menu to see the changes? > > The very last possibility is you have checked the box 'Ignore changes > from Charles' in your Xcode prefs...;-) > Alright, I think I figured out what is going on here. If you go the BioCocoa cvs website where the project files are located: http://bioinformatics.org/cgi-bin/cvsweb.cgi/BioCocoa/BioCocoa.pbproj/ You will see files for all users. However, if you then check which files are in MAIN or HEAD, you will notice that the file koen.pbxuser is missing. So I suspect that because of the wrong tag, the changes commited by others are not propagated to my project, only to my HD. So now the million dollar question. Anyone knows how to fix this so the file koen.pbxuser will have the correct tag? thanks, - Koen. From mek at mekentosj.com Mon Feb 21 17:33:15 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Mon, 21 Feb 2005 23:33:15 +0100 Subject: [Biococoa-dev] Joining the team In-Reply-To: References: Message-ID: <3397e7015a838aea76864c25da5ab924@mekentosj.com> > Incidentally, I thought this came up ages ago, and it was Alex who > asked > Peter about it then. Maybe I'm hallucinating after too much time in a > darkened microscope room? Nope, absolutely not, you're right, in fact I have an email from Peter that he changed the license of the current biococoa to LGPL already, not sure if that's reflected in the current license file already, but at the time Peter was fine with it. Just wanted to inform and ask everyone though... > Incidentally, what's the story for re-use of code? A hypothetical: > If I > were to write code for a commercial project, then donate some of that > code > to BioCocoa, would I then have to go back and release the code for the > entire commercial product? Would I have to explicitly retain > copyright to > the shared code to avoid this? Hasn't been an issue yet, but if we do > go > CoreData, I could see it becoming one. Hmm, I don't get it, but that's probably me hallucinating after coding to long... ;-) Cheers, Alex > > >> Just to inform everyone, a few days ago Phil contacted me with a >> question about the WWDC. Of course, I couldn't resist asking him to >> join the biococoa team ;-) He asked me if the framework could be >> released as LGPL instead of GPL, which allows incorporation into >> commercial products as long as the framework is unmodified. I told him >> that I was not the one who could solely decide that of course and told >> him to raise the question on his behalf on the list. I did say that I >> would like to copy his request and that I basically see no problems >> with changing the license as we have started from scratch and have no >> legacy code with GPL license included anyway. But, fair enough this is >> something we should decide upon together, and perhaps especially Peter >> who started the project. >> What's everybody's opinion on this? >> Alex > > _______________________________________________ > This mind intentionally left blank > > > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* From charles.parnot at stanford.edu Mon Feb 21 18:32:48 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 15:32:48 -0800 Subject: [Biococoa-dev] Joining the team In-Reply-To: References: Message-ID: >Incidentally, I thought this came up ages ago, and it was Alex who asked >Peter about it then. Maybe I'm hallucinating after too much time in a >darkened microscope room? > >JT Yeah, that's what I thought too! I am OK with LPGL anyway... -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Mon Feb 21 18:37:41 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 15:37:41 -0800 Subject: [Biococoa-dev] Joining the team In-Reply-To: References: Message-ID: >Incidentally, what's the story for re-use of code? A hypothetical: If I >were to write code for a commercial project, then donate some of that code >to BioCocoa, would I then have to go back and release the code for the >entire commercial product? Would I have to explicitly retain copyright to >the shared code to avoid this? Hasn't been an issue yet, but if we do go >CoreData, I could see it becoming one. If it is going to be a whole class or a bunch of class, that would be a problem. But if it is just pasting some chunks of code here and there with some modifications to avoid typing and to get an outline of something otherwise quite starightforward, then it is not much of an issue, particularly if it is very standard code that you could find in an Apple example or a tutorial (then it is not original code, so no copyright issue). I would guess what makes code original is not just how you wrote it, but the intent and the context. I am not a lawyer, of course, but this seems to be the rule of thumb. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Mon Feb 21 18:38:19 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 18:38:19 -0500 Subject: [Biococoa-dev] Joining the team In-Reply-To: References: Message-ID: <3d9aff99b90e4bd18ef3fcd48d006355@earthlink.net> On Feb 21, 2005, at 6:32 PM, Charles PARNOT wrote: >> Incidentally, I thought this came up ages ago, and it was Alex who >> asked >> Peter about it then. Maybe I'm hallucinating after too much time in a >> darkened microscope room? >> >> JT > > Yeah, that's what I thought too! I am OK with LPGL anyway... > Same here (2x) - Koen. From mek at mekentosj.com Mon Feb 21 18:41:06 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 00:41:06 +0100 Subject: [Biococoa-dev] Joining the team In-Reply-To: <3d9aff99b90e4bd18ef3fcd48d006355@earthlink.net> References: <3d9aff99b90e4bd18ef3fcd48d006355@earthlink.net> Message-ID: <4ef5512f3c8427aa32ce4ef5bcfb7a9d@mekentosj.com> Ok Ok, am I the only one really hallucinating? Man where was the d?j? vu moment when I really needed it, LOL... Anyway, that's settled then.... LGPL it (still) is... ;-) On 22-feb-05, at 0:38, Koen van der Drift wrote: > > On Feb 21, 2005, at 6:32 PM, Charles PARNOT wrote: > >>> Incidentally, I thought this came up ages ago, and it was Alex who >>> asked >>> Peter about it then. Maybe I'm hallucinating after too much time in >>> a >>> darkened microscope room? >>> >>> JT >> >> Yeah, that's what I thought too! I am OK with LPGL anyway... >> > > Same here (2x) > > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ************************************************************** ** Alexander Griekspoor ** ************************************************************** The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From charles.parnot at stanford.edu Mon Feb 21 18:54:05 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 15:54:05 -0800 Subject: SCM update (was: [Biococoa-dev] Annotation) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: It looks like you fixed it, right? charles At 17:31 -0500 2/21/05, Koen van der Drift wrote: >On Feb 21, 2005, at 12:52 PM, Charles PARNOT wrote: > >>Sorry you already know the following... just in case: if the file show up in the SCM window, then you need to update them. If there is a 'U' in the SCM column, you just need to choose 'Update...from Latest' in the SCM menu or in the contextual menu. If there is a little 'C' it means you have made modifications to the version you had, but a new version has been commited since, in which case you may need to discard your changes and update (I am not sure how to merge). >> >>That said, some of my latest commits were very small, so maybe you did not notice them? Did you try to 'Compare with...Revision...' in the SCM menu to see the changes? >> >>The very last possibility is you have checked the box 'Ignore changes from Charles' in your Xcode prefs...;-) >> > >Alright, I think I figured out what is going on here. If you go the BioCocoa cvs website where the project files are located: > >http://bioinformatics.org/cgi-bin/cvsweb.cgi/BioCocoa/BioCocoa.pbproj/ > >You will see files for all users. However, if you then check which files are in MAIN or HEAD, you will notice that the file koen.pbxuser is missing. So I suspect that because of the wrong tag, the changes commited by others are not propagated to my project, only to my HD. > >So now the million dollar question. Anyone knows how to fix this so the file koen.pbxuser will have the correct tag? > > >thanks, > >- Koen. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Mon Feb 21 19:12:28 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 19:12:28 -0500 Subject: HELP!!! (was: Re: SCM update (was: [Biococoa-dev] Annotation)) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: On Feb 21, 2005, at 6:54 PM, Charles PARNOT wrote: > It looks like you fixed it, right? > No, just trying out various cvs commands :( What happened is that the branched version 1.1.1.2 has the tag 'MAIN', but the most recent version 1.16 has now a tag 'FOO', which I added by accident. The tag was 'REL_2' before that, so also not good. What needs to happen is that version 1.16 needs to be tagged 'MAIN', but everytime I try that I get an error: [koen at RubyTuesday:~/Documents/Development/Active Projects/BioCocoa/BioCocoa.pbproj] $ cvs tag -f MAIN koen.pbxuser W koen.pbxuser : MAIN already exists on branch 1.1.1.2 : NOT MOVING tag to version 1.16 I can merge the two, but version 1.16 will keep the wrong tag. [koen at RubyTuesday:~/Documents/Development/Active Projects/BioCocoa/BioCocoa.pbproj] $ cvs -q update -j 1.16 -j 1.1.1.2 koen.pbxuser RCS file: /cvsroot/BioCocoa/BioCocoa.pbproj/koen.pbxuser,v retrieving revision 1.16 retrieving revision 1.1.1.2 Merging differences between 1.16 and 1.1.1.2 into koen.pbxuser [koen at RubyTuesday:~/Documents/Development/Active Projects/BioCocoa/BioCocoa.pbproj] $ cvs status koen.pbxuser =================================================================== File: koen.pbxuser Status: Locally Modified Working revision: 1.16 Repository revision: 1.16 /cvsroot/BioCocoa/BioCocoa.pbproj/koen.pbxuser,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Any ideas? - Koen. From kvddrift at earthlink.net Mon Feb 21 19:49:51 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 19:49:51 -0500 Subject: symbol class and sequence class (was: [Biococoa-dev] Annotation) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: On Feb 21, 2005, at 1:10 PM, Charles PARNOT wrote: >>> Also, Koen, I have one question about the symbolSet: it seems that >>> all instances of one sequence type use the same symbol set. Is that >>> right? >> No, each sequence should have it's own symbolset, just like each >> sequence has its own symbolArray. > > Oups, I got confused. I actually meant: do you foresee that each > sequence class will most of the time use a constant BCSymbol subclass? > I am not sure what the BCSymbolSet will be used for. The BCSymbolSet was introduced to have a similar function as the alphabets in BioPerl and BioJava. It can be used instead of or next to BCSequenceType. So basically, a sequence has a symbolset which defines which BCSymbols are allowed for that particular type of sequence. In most cases just the standard symbolsets will be used, but they can be extended if needed, eg to incorporate user-defined symbols. An advantage can be that we don't need to check everytime if the BCSymbol in a sequence is of the right type of BCSymbol. If we use eg the BCSymbolSet for DNA, then we know that an 'A' in that sequence must be adenosine and not alanine. So far, ony the code for BCSymbolSet has been written, but not yet the implementation in the rest of the framework. I hope it is more clearer now? > > I am asking this because I am still annoyed by the fact that the > BCAbstractSequence class does not have a designated initializer. This > is an issue that showed up no later than yesterday, when Koen added > the annotations code. You set the annotations to nil in > 'initWithString...' but not in 'initWithSymbolArray'... and you should > not have had to if the latter was calling the first, in other words if > it was calling the 'designated initializer'. The problem is those two > initializations are encoded separately and in parallel, and are also > encoded in all the subclasses, where the code is repeated exactly the > same except for the BCSymbol subclass used. > > I suggest we do the following: > * each subclass implements "+ (Class)defaultSymbolClass" to return the > BCSymbol subclass to use; For this purpose exactly we have introduced the BCSymbolSet, so I don't think the defaultSymbolClass is needed. What is needed is that I add the code for BCSymbolSet ;-) - Koen. From kvddrift at earthlink.net Mon Feb 21 19:52:11 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 19:52:11 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: <17bd8f21422204542205b787c80aee3f@mekentosj.com> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> Message-ID: <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> On Feb 21, 2005, at 2:45 PM, Alexander Griekspoor wrote: >> * do we need a BCFeature class? do we need a BCFeatureSet class? >> Probably only the latter. It seems the bsml format would require a >> BCFeatureSet class which could not be broken down into BCFeature >> elements, because it has a nested structure. If any of you has >> experience with data structures for xml, speak up! > > Yes sir, well in fact I would strongly suggest that we make BOTH a > BCAnnotation AND a BCFeature class. I agree with Alex here. See his excellent explanation for his enzymeX dictionary why. > Simple, clean, brilliant... I couldn't have said it better :) - Koen. From charles.parnot at stanford.edu Mon Feb 21 20:06:54 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 17:06:54 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> Message-ID: At 19:52 -0500 2/21/05, Koen van der Drift wrote: >On Feb 21, 2005, at 2:45 PM, Alexander Griekspoor wrote: > >>>* do we need a BCFeature class? do we need a BCFeatureSet class? Probably only the latter. It seems the bsml format would require a BCFeatureSet class which could not be broken down into BCFeature elements, because it has a nested structure. If any of you has experience with data structures for xml, speak up! >> >>Yes sir, well in fact I would strongly suggest that we make BOTH a BCAnnotation AND a BCFeature class. > >I agree with Alex here. See his excellent explanation for his enzymeX dictionary why. > >>Simple, clean, brilliant... > > >I couldn't have said it better :) > I like the idea of wrapping a dictionary in a new class, if it means smart methods to store, sort and retrieve info. One thing is actually still unclear to me. Do we need a BCFeatureSet (or BCFeatures)? Alex, could you lay out in more details what you are thinking about, what goes in the different class and what goes in BCSequence? Either here on the mailing list or commit some code on the cvs... charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Mon Feb 21 20:09:10 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 17:09:10 -0800 Subject: symbol class and sequence class (was: [Biococoa-dev] Annotation) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: OK, I see... I suspected something like this! So, does that mean we will need a 'initWithSymbolArray:symbolSet:'? thanks! charles At 19:49 -0500 2/21/05, Koen van der Drift wrote: >On Feb 21, 2005, at 1:10 PM, Charles PARNOT wrote: > >>>>Also, Koen, I have one question about the symbolSet: it seems that all instances of one sequence type use the same symbol set. Is that right? >>>No, each sequence should have it's own symbolset, just like each sequence has its own symbolArray. >> >>Oups, I got confused. I actually meant: do you foresee that each sequence class will most of the time use a constant BCSymbol subclass? I am not sure what the BCSymbolSet will be used for. > >The BCSymbolSet was introduced to have a similar function as the alphabets in BioPerl and BioJava. It can be used instead of or next to BCSequenceType. So basically, a sequence has a symbolset which defines which BCSymbols are allowed for that particular type of sequence. In most cases just the standard symbolsets will be used, but they can be extended if needed, eg to incorporate user-defined symbols. An advantage can be that we don't need to check everytime if the BCSymbol in a sequence is of the right type of BCSymbol. If we use eg the BCSymbolSet for DNA, then we know that an 'A' in that sequence must be adenosine and not alanine. So far, ony the code for BCSymbolSet has been written, but not yet the implementation in the rest of the framework. I hope it is more clearer now? > >> >>I am asking this because I am still annoyed by the fact that the BCAbstractSequence class does not have a designated initializer. This is an issue that showed up no later than yesterday, when Koen added the annotations code. You set the annotations to nil in 'initWithString...' but not in 'initWithSymbolArray'... and you should not have had to if the latter was calling the first, in other words if it was calling the 'designated initializer'. The problem is those two initializations are encoded separately and in parallel, and are also encoded in all the subclasses, where the code is repeated exactly the same except for the BCSymbol subclass used. >> >>I suggest we do the following: >>* each subclass implements "+ (Class)defaultSymbolClass" to return the BCSymbol subclass to use; > >For this purpose exactly we have introduced the BCSymbolSet, so I don't think the defaultSymbolClass is needed. What is needed is that I add the code for BCSymbolSet ;-) > > >- Koen. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Mon Feb 21 20:17:33 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 21 Feb 2005 17:17:33 -0800 Subject: HELP!!! (was: Re: SCM update (was: [Biococoa-dev] Annotation)) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: On the CVS web interface, your user file koen.pbproj looks like it has the MAIN and the HEAD tags, just like mine, and FOO is gone... Did you try to checkout again now?? I also don't know if Xcode might be caching some stuff in your back and screwing things up? charles At 19:12 -0500 2/21/05, Koen van der Drift wrote: >On Feb 21, 2005, at 6:54 PM, Charles PARNOT wrote: > >>It looks like you fixed it, right? >> > > >No, just trying out various cvs commands :( What happened is that the branched version 1.1.1.2 has the tag 'MAIN', but the most recent version 1.16 has now a tag 'FOO', which I added by accident. The tag was 'REL_2' before that, so also not good. What needs to happen is that version 1.16 needs to be tagged 'MAIN', but everytime I try that I get an error: > > >[koen at RubyTuesday:~/Documents/Development/Active Projects/BioCocoa/BioCocoa.pbproj] $ cvs tag -f MAIN koen.pbxuser >W koen.pbxuser : MAIN already exists on branch 1.1.1.2 : NOT MOVING tag to version 1.16 > > >I can merge the two, but version 1.16 will keep the wrong tag. > >[koen at RubyTuesday:~/Documents/Development/Active Projects/BioCocoa/BioCocoa.pbproj] $ cvs -q update -j 1.16 -j 1.1.1.2 koen.pbxuser >RCS file: /cvsroot/BioCocoa/BioCocoa.pbproj/koen.pbxuser,v >retrieving revision 1.16 >retrieving revision 1.1.1.2 >Merging differences between 1.16 and 1.1.1.2 into koen.pbxuser >[koen at RubyTuesday:~/Documents/Development/Active Projects/BioCocoa/BioCocoa.pbproj] $ cvs status koen.pbxuser >=================================================================== >File: koen.pbxuser Status: Locally Modified > > Working revision: 1.16 > Repository revision: 1.16 >/cvsroot/BioCocoa/BioCocoa.pbproj/koen.pbxuser,v > Sticky Tag: (none) > Sticky Date: (none) > Sticky Options: (none) > > > >Any ideas? > > >- Koen. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Mon Feb 21 20:23:05 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 20:23:05 -0500 Subject: symbol class and sequence class (was: [Biococoa-dev] Annotation) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: On Feb 21, 2005, at 8:09 PM, Charles PARNOT wrote: > OK, I see... I suspected something like this! > > So, does that mean we will need a 'initWithSymbolArray:symbolSet:'? > Probably, but not essential, I think. It would be nice, though if the user already knows what type of sequence she is creating. In other case we should use sequenceTypeForString to determine the symbolset. As you can see in BCSymbolSet, there are many interesting variations possible, eg dnaSymbolSet vs. dnaStrictSymbolSet. The latter only allows ACGT, the former all possible nucleotides. So it maybe can also be used instead of the skippingUnknownSymbols variable. - Koen. From kvddrift at earthlink.net Mon Feb 21 20:35:23 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 21 Feb 2005 20:35:23 -0500 Subject: HELP!!! (was: Re: SCM update (was: [Biococoa-dev] Annotation)) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> Message-ID: <7b50ea6c2ff0b67033183ce091332356@earthlink.net> On Feb 21, 2005, at 8:17 PM, Charles PARNOT wrote: > On the CVS web interface, your user file koen.pbproj looks like it has > the MAIN and the HEAD tags, just like mine, and FOO is gone... > If I look here: http://bioinformatics.org/cgi-bin/cvsweb.cgi/BioCocoa/BioCocoa.pbproj/? only_with_tag=MAIN I don't see my file, and FOO is still listed in the popup. > Did you try to checkout again now?? I also don't know if Xcode might > be caching some stuff in your back and screwing things up? > > I did a fresh checkout, and made a commit in BCAbstractSequence (I commented out the setAnnotations). Could you add some code or text, commit the changes, and let me know? That way I can check if it worked. merci, - Koen. From peter.schols at bio.kuleuven.ac.be Tue Feb 22 03:44:31 2005 From: peter.schols at bio.kuleuven.ac.be (Peter Schols) Date: Tue, 22 Feb 2005 09:44:31 +0100 Subject: [Biococoa-dev] Joining the team In-Reply-To: References: Message-ID: <9544c218eb48553ab306291be4bbee48@bio.kuleuven.ac.be> > Incidentally, I thought this came up ages ago, and it was Alex who > asked > Peter about it then. Maybe I'm hallucinating after too much time in a > darkened microscope room? No you aren't, John. We indeed changed the license from GPL to L-GPL to get Alex on board ;-) This means that the BioCocoa framework can be used in any (commercial) application, as long as the changes to the framework itself (in case changes are made) are donated back to the community. The application built upon BC can remain proprietary so there is no need to release its source. Best wishes, Peter From mek at mekentosj.com Tue Feb 22 04:01:37 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 10:01:37 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> Message-ID: > One thing is actually still unclear to me. Do we need a BCFeatureSet > (or BCFeatures)? Alex, could you lay out in more details what you are > thinking about, what goes in the different class and what goes in > BCSequence? Either here on the mailing list or commit some code on the > cvs... Damn, your right, I should keep my mouth shut and implement the stuff instead of talking all the time... I'm ashamed... ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From mek at mekentosj.com Tue Feb 22 04:04:14 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 10:04:14 +0100 Subject: [Biococoa-dev] Joining the team In-Reply-To: <9544c218eb48553ab306291be4bbee48@bio.kuleuven.ac.be> References: <9544c218eb48553ab306291be4bbee48@bio.kuleuven.ac.be> Message-ID: > No you aren't, John. We indeed changed the license from GPL to L-GPL > to get Alex on board ;-) Ironically I didn't release anything commercial yet, and still have no plans to do so ;-) ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From a.griekspoor at nki.nl Tue Feb 22 06:00:29 2005 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Tue, 22 Feb 2005 12:00:29 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> Message-ID: <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> Having said that, I'll add a basic BCAnnotation class tonight (based on my Enzyme example), and modify the sequence class to represent the addition. The BCFeature class will be its subclass and contain an NSRange property and some position related methods (similar to the once in the sequence class). Many questions on the implementation will come along I guess. I'll have a look at the methods Charles (or John?) was proposing with the plists and predefined keys... I have two questions already though: - if we request subsequences, do we add a boolean argument to include the annotations? It would mean that we have to include ALL position independent annotations, and all the ones that are within the range requested? - do we use 1 or 0 based ranges? For the first 10 bases, do I create a range {0,10} or {1,10}. I think it would be nicest to use NSRanges, we can compensate in the accessors if necessary I guess... Cheers, Alex On 22-feb-05, at 10:01, Alexander Griekspoor wrote: >> One thing is actually still unclear to me. Do we need a BCFeatureSet >> (or BCFeatures)? Alex, could you lay out in more details what you are >> thinking about, what goes in the different class and what goes in >> BCSequence? Either here on the mailing list or commit some code on >> the cvs... > Damn, your right, I should keep my mouth shut and implement the stuff > instead of talking all the time... I'm ashamed... > > > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Windows is a 32-bit patch to a 16-bit shell for an 8-bit > operating system, written for a 4-bit processor by a 2- > bit company without 1 bit of sense. > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From kvddrift at earthlink.net Tue Feb 22 06:04:09 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 06:04:09 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> Message-ID: <637a0c5504cd5a46a18cfda65dc6958e@earthlink.net> On Feb 22, 2005, at 6:00 AM, Alexander Griekspoor wrote: > Having said that, I'll add a basic BCAnnotation class tonight (based > on my Enzyme example), and modify the sequence class to represent the > addition. Please remove my annotations code as well. I don't think I can do much until my cvs problems are fixed :( - Koen. From a.griekspoor at nki.nl Tue Feb 22 06:05:45 2005 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Tue, 22 Feb 2005 12:05:45 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: <637a0c5504cd5a46a18cfda65dc6958e@earthlink.net> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <637a0c5504cd5a46a18cfda65dc6958e@earthlink.net> Message-ID: <3a15566da96226810de25a0450fbf822@nki.nl> Which ones? The code in the abstractsequence class or do I miss a class already? alex On 22-feb-05, at 12:04, Koen van der Drift wrote: > > On Feb 22, 2005, at 6:00 AM, Alexander Griekspoor wrote: > >> Having said that, I'll add a basic BCAnnotation class tonight (based >> on my Enzyme example), and modify the sequence class to represent the >> addition. > > > Please remove my annotations code as well. I don't think I can do much > until my cvs problems are fixed :( > > > - Koen. > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* From mek at mekentosj.com Tue Feb 22 06:08:00 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 12:08:00 +0100 Subject: [Biococoa-dev] SequenceReader In-Reply-To: <3a15566da96226810de25a0450fbf822@nki.nl> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <637a0c5504cd5a46a18cfda65dc6958e@earthlink.net> <3a15566da96226810de25a0450fbf822@nki.nl> Message-ID: <839b22604910cf3a965d33d8ca084921@mekentosj.com> Something else, just wondering, in the sequenceIO, is the BCReader a legacy class that will be replaced by BCSequenceReader? Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From kvddrift at earthlink.net Tue Feb 22 06:08:15 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 06:08:15 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: <3a15566da96226810de25a0450fbf822@nki.nl> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <637a0c5504cd5a46a18cfda65dc6958e@earthlink.net> <3a15566da96226810de25a0450fbf822@nki.nl> Message-ID: On Feb 22, 2005, at 6:05 AM, Alexander Griekspoor wrote: > Which ones? The code in the abstractsequence class or do I miss a > class already? > In BCAbstractSequence and BCSequenceReader. - Koen. From kvddrift at earthlink.net Tue Feb 22 06:11:17 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 06:11:17 -0500 Subject: [Biococoa-dev] SequenceReader In-Reply-To: <839b22604910cf3a965d33d8ca084921@mekentosj.com> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <637a0c5504cd5a46a18cfda65dc6958e@earthlink.net> <3a15566da96226810de25a0450fbf822@nki.nl> <839b22604910cf3a965d33d8ca084921@mekentosj.com> Message-ID: On Feb 22, 2005, at 6:08 AM, Alexander Griekspoor wrote: > is the BCReader a legacy class that will be replaced by > BCSequenceReader? Yes (and also BCSequenceWriter will replace BCWriter). - Koen. From charles.parnot at stanford.edu Tue Feb 22 12:56:32 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 09:56:32 -0800 Subject: HELP!!! (was: Re: SCM update (was: [Biococoa-dev] Annotation)) In-Reply-To: <7b50ea6c2ff0b67033183ce091332356@earthlink.net> References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> <7b50ea6c2ff0b67033183ce091332356@earthlink.net> Message-ID: Koen, I thought we could do it the hard way, so I did the following on the cvs repository, in the BioCocoa.pbproj folder: mv koen.pbxuser,v koen.pbxuser,v.old which simply hides the file from the cvs repository, and it now has no memory of it. The '.old' file could be destroyed in the future if the next steps work. Now, you could checkout a new BioCocoa folder. The, before opening the project, you may want to copy the old koen.pbxuser from a recent version into the new checkout project, then 'cvs add' the file and then 'cvs commit' it. (This is only to keep some of the settings you may have but I am not sure you would miss them anyway) And hopefully you will be back to normal! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 22 13:08:48 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 10:08:48 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> Message-ID: At 12:00 +0100 2/22/05, Alexander Griekspoor wrote: >Having said that, I'll add a basic BCAnnotation class tonight (based on my Enzyme example), and modify the sequence class to represent the addition. The BCFeature class will be its subclass and contain an NSRange property and some position related methods (similar to the once in the sequence class). Many questions on the implementation will come along I guess. I'll have a look at the methods Charles (or John?) was proposing with the plists and predefined keys... That was John >I have two questions already though: >- if we request subsequences, do we add a boolean argument to include the annotations? It would mean that we have to include ALL position independent annotations, and all the ones that are within the range requested? I think we can include that later, but yes, we would have to do that to be consistent. We may even need to add a new annotation to the subsequence to keep track of the history of that sequence, using one of these 'segment' tag you cited in your initial Annotation email. >- do we use 1 or 0 based ranges? For the first 10 bases, do I create a range {0,10} or {1,10}. I think it would be nicest to use NSRanges, we can compensate in the accessors if necessary I guess... > >Cheers, >Alex The issue of 0 vs 1 is a problem with cDNAs and the transcription or translation starting point, or is it a more widely used convention? One problem with the +1 convention is the absence of 0, IIRC. The positions goes -2, -1, +1, +2, right? Anyway, that's a tough question. IMO, we should use a 0 based range to stick to the Cocoa conventions. In the Cocoa NSRange convention, the first character of a string is anyway not at position 0 or 1, but in between the two! Of course, the BCSequenceView would have to display the correct numbers, Alex ;-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 22 13:22:26 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 10:22:26 -0800 Subject: HELP!!! (was: Re: SCM update (was: [Biococoa-dev] Annotation)) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> <7b50ea6c2ff0b67033183ce091332356@earthlink.net> Message-ID: OK, I did it for you! And you are back on that page: http://bioinformatics.org/cgi-bin/cvsweb.cgi/BioCocoa/BioCocoa.pbproj/?only_with_tag=MAIN I did not try to checkout and test because I would need to create koen user on my computer ;-) charles At 9:56 -0800 2/22/05, Charles PARNOT wrote: >Koen, I thought we could do it the hard way, so I did the following on the cvs repository, in the BioCocoa.pbproj folder: > >mv koen.pbxuser,v koen.pbxuser,v.old > >which simply hides the file from the cvs repository, and it now has no memory of it. The '.old' file could be destroyed in the future if the next steps work. > >Now, you could checkout a new BioCocoa folder. The, before opening the project, you may want to copy the old koen.pbxuser from a recent version into the new checkout project, then 'cvs add' the file and then 'cvs commit' it. (This is only to keep some of the settings you may have but I am not sure you would miss them anyway) > >And hopefully you will be back to normal! > >charles > >-- >Help science go fast forward: >http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > >Charles Parnot >charles.parnot at stanford.edu > >Room B157 in Beckman Center >279, Campus Drive >Stanford University >Stanford, CA 94305 (USA) > >Tel +1 650 725 7754 >Fax +1 650 725 8021 >_______________________________________________ >Biococoa-dev mailing list >Biococoa-dev at bioinformatics.org >https://bioinformatics.org/mailman/listinfo/biococoa-dev -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Tue Feb 22 13:32:32 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 19:32:32 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> Message-ID: <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> >> I'll have a look at the methods Charles (or John?) was proposing with >> the plists and predefined keys... > > That was John Yep, found the email... > >> I have two questions already though: >> - if we request subsequences, do we add a boolean argument to include >> the annotations? It would mean that we have to include ALL position >> independent annotations, and all the ones that are within the range >> requested? > > I think we can include that later, but yes, we would have to do that > to be consistent. We may even need to add a new annotation to the > subsequence to keep track of the history of that sequence, using one > of these 'segment' tag you cited in your initial Annotation email. Yep, I was thinking that perhaps we should add some method in the sequence class to have it return a unique id or serial number (the famous UUID) so that we can uniquely point to a certain sequence. The segment would be of class BCFeature I guess as it should have the positional properties to which it applies... I'm about half way with the basic BCAnnotation class, it will have two properties (or three perhaps depending on how you see it) along the lines of the BSML attribute tag: NSString *name, the name of the attribute, also the key with which it is stored in the mutable dictionary NSObject *content. the content of the attribute (can be any kind of object) NSString *datatype, the classname of the content object (this is not a property but a method) So for instance an example from the BSML pdf would be the following example: which would be come: NSString *name -> @"Subcellular Location" NSObject *content -> @"Cytoplasmic" NSString *datatype -> @"NSString" The BCFeature would add a range property plus logic for modifying it and helper methods like startposition, endposition etc) A segment feature example would then become: NSString *name -> @"Segment" NSObject *content -> @"1921292" <- UUID in this case, or another reference (object) to another sequence, in principle this could even be the segment's BCSequence object ;-) NSString *datatype -> @"NSString" NSRange range -> NSRange {1212, 12} The question perhaps rises if we want each annotation to have a set of properties that identify the creator/date etc of the annotation, say the metadata of the annotation. >> - do we use 1 or 0 based ranges? For the first 10 bases, do I create >> a range {0,10} or {1,10}. I think it would be nicest to use NSRanges, >> we can compensate in the accessors if necessary I guess... > > The issue of 0 vs 1 is a problem with cDNAs and the transcription or > translation starting point, or is it a more widely used convention? > One problem with the +1 convention is the absence of 0, IIRC. The > positions goes -2, -1, +1, +2, right? Yes, guess so, but those are relative positions, so 0 in that case is the base itself. > Anyway, that's a tough question. IMO, we should use a 0 based range to > stick to the Cocoa conventions. In the Cocoa NSRange convention, the > first character of a string is anyway not at position 0 or 1, but in > between the two! Yep, I would like to have it 0 based as well.... The ranges the findSubsequence methods use are also 0-based right? Guess, that's settled then... Correct me if I'm wrong but I believe BioJava's sequences are 1-based, but Koen might know better. > Of course, the BCSequenceView would have to display the correct > numbers, Alex ;-) Yeah yeah, LOL I got the message ;-) I'll let you know when the BCAnnotation class is in the CVS, ready to burn it down, haha Cheers, Alex > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From biococoa at bioworxx.com Tue Feb 22 13:39:25 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Tue, 22 Feb 2005 19:39:25 +0100 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa Message-ID: <13826ad951def09bbfffdb916756db41@bioworxx.com> Hi everybody, I'm currently working on a project focused on Hidden markov models & sequence alignments. I would like to contribute my work to the framework. So i'd like to add aligment & HMM structures to the framework. What do you think about it Bye, Phil From mek at mekentosj.com Tue Feb 22 13:45:22 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 19:45:22 +0100 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: <13826ad951def09bbfffdb916756db41@bioworxx.com> References: <13826ad951def09bbfffdb916756db41@bioworxx.com> Message-ID: <6180ed6b6117ccddbdd5a64bf5be3870@mekentosj.com> Hi Phil, Absolutely fabulous, I've been begging for alignments in a decent framework for more than a year already, so it would be more than great from both a personal and a biococoa point of view I think. Of course this would require some work to make your project work natively (ideally speaking) with our BCSequence classes, but it would be awesome. If you haven't done so, please create an account at Bioinformatics.com and Peter can add you to the project member list, which allows you to access the CVS. If you want I would like to invite you to describe your project in more detail on the list and we can discuss a bit more on how to implement your work in the framework... Looking forward to your contribution! Cheers, Alex On 22-feb-05, at 19:39, Philipp Seibel wrote: > Hi everybody, > > I'm currently working on a project focused on Hidden markov models & > sequence alignments. > I would like to contribute my work to the framework. So i'd like to > add aligment & HMM structures to the framework. > > What do you think about it > > Bye, > > Phil > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* From peter.schols at bio.kuleuven.ac.be Tue Feb 22 13:54:38 2005 From: peter.schols at bio.kuleuven.ac.be (Peter Schols) Date: Tue, 22 Feb 2005 19:54:38 +0100 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: <6180ed6b6117ccddbdd5a64bf5be3870@mekentosj.com> References: <13826ad951def09bbfffdb916756db41@bioworxx.com> <6180ed6b6117ccddbdd5a64bf5be3870@mekentosj.com> Message-ID: Hi Alex and Phil, First of all, I'd like to welcome Phil officially to the BC team! I've just added him as a group member. Secondly, I want to say that I would love to see a BioCocoa implementation of alignment and HMM APIs! I was planning to use both multiple alignment and HMM in an app I'm working on (for phylogenetic footprinting) so I'd be very interested! Feel free to discuss any implementation ideas you might have on the list. Best wishes, Peter On 22 Feb 2005, at 19:45, Alexander Griekspoor wrote: > Hi Phil, > > Absolutely fabulous, I've been begging for alignments in a decent > framework for more than a year already, so it would be more than great > from both a personal and a biococoa point of view I think. Of course > this would require some work to make your project work natively > (ideally speaking) with our BCSequence classes, but it would be > awesome. If you haven't done so, please create an account at > Bioinformatics.com and Peter can add you to the project member list, > which allows you to access the CVS. > If you want I would like to invite you to describe your project in > more detail on the list and we can discuss a bit more on how to > implement your work in the framework... Looking forward to your > contribution! > Cheers, > Alex > > On 22-feb-05, at 19:39, Philipp Seibel wrote: > >> Hi everybody, >> >> I'm currently working on a project focused on Hidden markov models & >> sequence alignments. >> I would like to contribute my work to the framework. So i'd like to >> add aligment & HMM structures to the framework. >> >> What do you think about it >> >> Bye, >> >> Phil >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> >> > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > E-mail: a.griekspoor at nki.nl > AIM: mekentosj at mac.com > Web: http://www.mekentosj.com > > EnzymeX - To cut or not to cut > http://www.mekentosj.com/enzymex > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > From mek at mekentosj.com Tue Feb 22 13:58:33 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 19:58:33 +0100 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: References: <13826ad951def09bbfffdb916756db41@bioworxx.com> <6180ed6b6117ccddbdd5a64bf5be3870@mekentosj.com> Message-ID: <1c24e42271057ca9f3b34e2411790c08@mekentosj.com> Hooray, and as Phil will likely join the WWDC'05 as well, our BioCocoa meeting has just grown dramatically ;-) That reminds me that I have to come up with a draft email to Robert Kehrer, I'll see if I can send you one soon Peter... Cheers, Alex On 22-feb-05, at 19:54, Peter Schols wrote: > Hi Alex and Phil, > > First of all, I'd like to welcome Phil officially to the BC team! I've > just added him as a group member. > > Secondly, I want to say that I would love to see a BioCocoa > implementation of alignment and HMM APIs! I was planning to use both > multiple alignment and HMM in an app I'm working on (for phylogenetic > footprinting) so I'd be very interested! Feel free to discuss any > implementation ideas you might have on the list. > > Best wishes, > > Peter > > > On 22 Feb 2005, at 19:45, Alexander Griekspoor wrote: > >> Hi Phil, >> >> Absolutely fabulous, I've been begging for alignments in a decent >> framework for more than a year already, so it would be more than >> great from both a personal and a biococoa point of view I think. Of >> course this would require some work to make your project work >> natively (ideally speaking) with our BCSequence classes, but it would >> be awesome. If you haven't done so, please create an account at >> Bioinformatics.com and Peter can add you to the project member list, >> which allows you to access the CVS. >> If you want I would like to invite you to describe your project in >> more detail on the list and we can discuss a bit more on how to >> implement your work in the framework... Looking forward to your >> contribution! >> Cheers, >> Alex >> >> On 22-feb-05, at 19:39, Philipp Seibel wrote: >> >>> Hi everybody, >>> >>> I'm currently working on a project focused on Hidden markov models & >>> sequence alignments. >>> I would like to contribute my work to the framework. So i'd like to >>> add aligment & HMM structures to the framework. >>> >>> What do you think about it >>> >>> Bye, >>> >>> Phil >>> >>> _______________________________________________ >>> Biococoa-dev mailing list >>> Biococoa-dev at bioinformatics.org >>> https://bioinformatics.org/mailman/listinfo/biococoa-dev >>> >>> >> ********************************************************* >> ** Alexander Griekspoor ** >> ********************************************************* >> The Netherlands Cancer Institute >> Department of Tumorbiology (H4) >> Plesmanlaan 121, 1066 CX, Amsterdam >> Tel: + 31 20 - 512 2023 >> Fax: + 31 20 - 512 2029 >> E-mail: a.griekspoor at nki.nl >> AIM: mekentosj at mac.com >> Web: http://www.mekentosj.com >> >> EnzymeX - To cut or not to cut >> http://www.mekentosj.com/enzymex >> >> ********************************************************* >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> > > > ************************************************************** ** Alexander Griekspoor ** ************************************************************** The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From jtimmer at bellatlantic.net Tue Feb 22 14:23:25 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 22 Feb 2005 14:23:25 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> Message-ID: >>> I'll have a look at the methods Charles (or John?) was proposing with >>> the plists and predefined keys... >> >> That was John > Yep, found the email... Oh, two additions of why a set of pre-defined keys would be neat for describing sequence type: Consistent display: an app using this could let the user set a preference something like "show all introns in green". This would make it easy to propagate the preference across all documents. Spotlight: we'd have a better sense of what to export and how to export it. Something like: if ( theFeature == @"S/T Kinase domain") export "kinase". >>> I have two questions already though: >>> - if we request subsequences, do we add a boolean argument to include >>> the annotations? It would mean that we have to include ALL position >>> independent annotations, and all the ones that are within the range >>> requested? >> >> I think we can include that later, but yes, we would have to do that >> to be consistent. We may even need to add a new annotation to the >> subsequence to keep track of the history of that sequence, using one >> of these 'segment' tag you cited in your initial Annotation email. > Yep, I was thinking that perhaps we should add some method in the > sequence class to have it return a unique id or serial number (the > famous UUID) so that we can uniquely point to a certain sequence. The > segment would be of class BCFeature I guess as it should have the > positional properties to which it applies... ... > The question perhaps rises if we want each annotation to have a set of > properties that identify the creator/date etc of the annotation, say > the metadata of the annotation. The question this raises for me: should we effectively provide access to the underlying dictionary so that people could add any feature/annotation they wanted? Using my example above, would you allow the user to dive into the feature and add a "display color" key with [NSColor greenColor] to the feature dictionary? If so, the best we can hope to code for is handling the reading/saving/manipulating of a set of pre-defined keys, and framework users would have to override these methods if they're going to do extensive customization. Either way, we're going to have to define a set of keys that we will support, but this seems like a major design decision that should be thought about for a bit. Cheers, JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Tue Feb 22 14:32:37 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 22 Feb 2005 14:32:37 -0500 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: <13826ad951def09bbfffdb916756db41@bioworxx.com> Message-ID: I think it sounds excellent. Maybe I could finally understand what a Hidden Markov Model is... Incidentally, I recently wound up building OS-X versions of Muscle and ClustalW. Now that our sequence object is stabilizing a bit, I was wondering if people thought it might be worth some effort trying to write a generic wrapper that could feed our sequences to command line apps and get a result back? This would potentially help us provide a layer of abstraction to a large number of Unix tools. The reason this comes to mind is that I'm finding that a lot of these things only take input in a limited number of formats, and we've already got format conversion code in place.... JT > Hi everybody, > > I'm currently working on a project focused on Hidden markov models & > sequence alignments. > I would like to contribute my work to the framework. So i'd like to add > aligment & HMM structures to the framework. > > What do you think about it > > Bye, > > Phil > _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Feb 22 14:51:00 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 20:51:00 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: Message-ID: > Oh, two additions of why a set of pre-defined keys would be neat for > describing sequence type: > Consistent display: an app using this could let the user set a > preference > something like "show all introns in green". This would make it easy to > propagate the preference across all documents. Yep! > Spotlight: we'd have a better sense of what to export and how to > export it. > Something like: if ( theFeature == @"S/T Kinase domain") export > "kinase". Again, yep! Metadata extraction can also be unified... > The question this raises for me: should we effectively provide access > to > the underlying dictionary so that people could add any > feature/annotation > they wanted? Ok, I've added the base BCAnnotation class to the CVS, not connected to anything, not build once ;-) But, it does give you an idea of the methods, and also I've headerdoc-ed the header with some ideas. Take a look and let me know what you think, any addition, comments and critiques are welcome of course. The question below is now answered. Absolutely! One of the things I liked to see from the start was the flexibility to add custom annotations of any form. The just added annotation class takes ANY object as content, thus including your own program specific ones (though we have to define some coding protocols in order to be able to write those out to a file). This way developers can store their own preferences, metadata etc in the sequence file as annotations. Of course, by defining predefined sets following your excellent plist proposal, we can standardize things where ever possible, without giving up flexibility. An example, say my EnzymeX program wants to store enzyme cut positions in the sequence file. Now I can simply add a BCFeature with my previously mentioned custom enzyme object as content, and the cut position as its range. Two more ideas: For the key (a.k.a name), it might be a good idea to use the same approach as the preferences model, so a predefined tag would be according to BSML wherever suitable. Developer custom names should be composed according to the rules Apple proposed for preferences (the inverted url approach): I could store my enzyme objects using the following name: com.mekentosj.enzymex.enzyme(.ecori) similar, one we define but is not present in BSML would become: org.bioinformatic.biococoa.ournewpredefinedname Another idea: how do we write out these things? simple, only accept custom objects that adhere to the protocol. All objects that aren't natively supported by plist encoding, can be archived into NSData and written as such in the xml. The nice thing is that the datatype (= className) is written in the xml as well, so that makes it easy to unarchive the thing. It needs some logic to control/check but its powerful I think. I can even add a simple - (NSData *)encodedContent; method to the BCAnnotation class which does the work, and can be used by the BSML writer. It can even check whether coding is supported by the custom class and return nil if it does not (in case the object is lost during a write. This actually leads me to another question right at the spot, is it a good idea to add a boolean "archive" or something to an annotation? This way you can actively decide whether the annotation should be written out to disk or not (think of temporary attributes, like the one in NSAttributedStrings). For instance, during the life of my program it might be nice to add custom (non-writable) objects to your sequence, but you might not want those be saved with the file (or you're not able to). This way you can specify which are to be saved and which not.... > > Either way, we're going to have to define a set of keys that we will > support, but this seems like a major design decision that should be > thought > about for a bit. Absolutely! I'll think a bit more about the plist approach... Cheers, Alex > _______________________________________________ > This mind intentionally left blank > > > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* From mek at mekentosj.com Tue Feb 22 15:23:08 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 21:23:08 +0100 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: References: Message-ID: <7cbbff93b8444f1192bfcc1218affa6c@mekentosj.com> > Incidentally, I recently wound up building OS-X versions of Muscle and > ClustalW. Now that our sequence object is stabilizing a bit, I was > wondering if people thought it might be worth some effort trying to > write a > generic wrapper that could feed our sequences to command line apps and > get a > result back? This would potentially help us provide a layer of > abstraction > to a large number of Unix tools. Do I understand you correctly that you want to generate a general NSTaskController that does the following: BCSequence -> NSString -> Run Task with arguments -> parse output -> BCSequence or other objects? > The reason this comes to mind is that I'm finding that a lot of these > things > only take input in a limited number of formats, and we've already got > format > conversion code in place.... The real question is how you can make the thing multipurpose instead of having tens of different controllers for very specific tasks... But you must have something in mind right? Alex > > JT > > >> Hi everybody, >> >> I'm currently working on a project focused on Hidden markov models & >> sequence alignments. >> I would like to contribute my work to the framework. So i'd like to >> add >> aligment & HMM structures to the framework. >> >> What do you think about it >> >> Bye, >> >> Phil >> > > _______________________________________________ > This mind intentionally left blank > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* From jtimmer at bellatlantic.net Tue Feb 22 15:46:55 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 22 Feb 2005 15:46:55 -0500 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: <7cbbff93b8444f1192bfcc1218affa6c@mekentosj.com> Message-ID: >> Incidentally, I recently wound up building OS-X versions of Muscle and >> ClustalW. Now that our sequence object is stabilizing a bit, I was >> wondering if people thought it might be worth some effort trying to >> write a >> generic wrapper that could feed our sequences to command line apps and >> get a >> result back? This would potentially help us provide a layer of >> abstraction >> to a large number of Unix tools. > Do I understand you correctly that you want to generate a general > NSTaskController that does the following: > BCSequence -> NSString -> Run Task with arguments -> parse output -> > BCSequence or other objects? More or less. Give the user the option of whether to have our existing file reading classes try to interpret the output, or to have it returned as a string and let them sort it out. >> The reason this comes to mind is that I'm finding that a lot of these >> things >> only take input in a limited number of formats, and we've already got >> format >> conversion code in place.... > The real question is how you can make the thing multipurpose instead of > having tens of different controllers for very specific tasks... But you > must have something in mind right? Flags - lots and lots of flags. The idea is that most of these tools have a limited number of file formats they take as input. Some of them can take input from stdin, others need files. Some output a single file, others multiple files. We need to give the user enough opportunity to work with as many as possible. The point of the wrapper would be to do what your initial comment suggested, but also automate handling things like creating tmp files as needed, reading from the STDOUT and STDERR pipes, handling conversions back to BCSequences, cleaning up, sending callback messages, etc. Clearly, there are going to be a bunch of user-supplied flags that will differ between tasks, but I think a lot of the grunt work could be wrapped, so that most tools could be run as something like the following: BCTask *myTask; [myTask setSequence: mySequnce]; [myTask setUsesSTDIN: NO]; /// know to use a tmp file [myTask setInputFormat: BCFastaFormat]; [myTask setAdditionalFlags: myFlagArray]; [myTask setUsesSTDOUT: NO]; // use a tmp output file [myTask setCallBack: @selector(taskDone:contextInfo:) target: self contextInfo: nil]; [myTask setCreatesSequencesFromOutput: YES]; [myTask setRetainsSTDERRasString: YES]; [myTask launch]; _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Feb 22 15:52:49 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 21:52:49 +0100 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: References: Message-ID: Instead of having to set 100 flags before being able to run the thing, it might be a good idea to see if you can discriminate different types of task (like ones that have a return value vs ones that only input stuff, or vice versa) and see if you can have them in a kind of hierarchy. That would allow to create a base BCTaskController with a number of more specialized subclasses. Often I like that approach more than a one-for-all-with-way-too-many-options approach... Think about it.. Cheers, Alex On 22-feb-05, at 21:46, John Timmer wrote: >>> Incidentally, I recently wound up building OS-X versions of Muscle >>> and >>> ClustalW. Now that our sequence object is stabilizing a bit, I was >>> wondering if people thought it might be worth some effort trying to >>> write a >>> generic wrapper that could feed our sequences to command line apps >>> and >>> get a >>> result back? This would potentially help us provide a layer of >>> abstraction >>> to a large number of Unix tools. >> Do I understand you correctly that you want to generate a general >> NSTaskController that does the following: >> BCSequence -> NSString -> Run Task with arguments -> parse output -> >> BCSequence or other objects? > More or less. Give the user the option of whether to have our > existing file > reading classes try to interpret the output, or to have it returned as > a > string and let them sort it out. > > >>> The reason this comes to mind is that I'm finding that a lot of these >>> things >>> only take input in a limited number of formats, and we've already got >>> format >>> conversion code in place.... >> The real question is how you can make the thing multipurpose instead >> of >> having tens of different controllers for very specific tasks... But >> you >> must have something in mind right? > Flags - lots and lots of flags. > > The idea is that most of these tools have a limited number of file > formats > they take as input. Some of them can take input from stdin, others > need > files. Some output a single file, others multiple files. We need to > give > the user enough opportunity to work with as many as possible. > > The point of the wrapper would be to do what your initial comment > suggested, > but also automate handling things like creating tmp files as needed, > reading > from the STDOUT and STDERR pipes, handling conversions back to > BCSequences, > cleaning up, sending callback messages, etc. > > Clearly, there are going to be a bunch of user-supplied flags that will > differ between tasks, but I think a lot of the grunt work could be > wrapped, > so that most tools could be run as something like the following: > > BCTask *myTask; > [myTask setSequence: mySequnce]; > [myTask setUsesSTDIN: NO]; /// know to use a tmp file > [myTask setInputFormat: BCFastaFormat]; > [myTask setAdditionalFlags: myFlagArray]; > [myTask setUsesSTDOUT: NO]; // use a tmp output file > [myTask setCallBack: @selector(taskDone:contextInfo:) target: self > contextInfo: nil]; > [myTask setCreatesSequencesFromOutput: YES]; > [myTask setRetainsSTDERRasString: YES]; > [myTask launch]; > > > > > > _______________________________________________ > This mind intentionally left blank > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* From charles.parnot at stanford.edu Tue Feb 22 16:11:29 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 13:11:29 -0800 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: References: Message-ID: At 14:32 -0500 2/22/05, John Timmer wrote: >I think it sounds excellent. Maybe I could finally understand what a Hidden >Markov Model is... > >Incidentally, I recently wound up building OS-X versions of Muscle and >ClustalW. Now that our sequence object is stabilizing a bit, I was >wondering if people thought it might be worth some effort trying to write a >generic wrapper that could feed our sequences to command line apps and get a >result back? This would potentially help us provide a layer of abstraction >to a large number of Unix tools. > >The reason this comes to mind is that I'm finding that a lot of these things >only take input in a limited number of formats, and we've already got format >conversion code in place.... > >JT > If you can deliver such a nice wrapper, it would indeed be wonderful! I think it is feasible. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 22 16:11:52 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 13:11:52 -0800 Subject: [Biococoa-dev] Alignment & HMM Support in Biococoa In-Reply-To: <13826ad951def09bbfffdb916756db41@bioworxx.com> References: <13826ad951def09bbfffdb916756db41@bioworxx.com> Message-ID: At 19:39 +0100 2/22/05, Philipp Seibel wrote: >Hi everybody, > >I'm currently working on a project focused on Hidden markov models & sequence alignments. >I would like to contribute my work to the framework. So i'd like to add aligment & HMM structures to the framework. > >What do you think about it > >Bye, > >Phil That would be great, yes! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Tue Feb 22 16:57:21 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 22:57:21 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> Message-ID: <0f45f8c7c22c6add17a77d3e133621f7@mekentosj.com> Ok guys, I've completed the BCAnnotation class, next up, implementation in BCAbstractSequence and sequencereader. (these classes also have to take care of the predefined names. I've temporarily added some code to test the new class in the awakeFromNib method of the translation demo. It prints out the tests to the console and demos some of the methods... Cheers, Alex On 22-feb-05, at 19:32, Alexander Griekspoor wrote: >>> I'll have a look at the methods Charles (or John?) was proposing >>> with the plists and predefined keys... >> >> That was John > Yep, found the email... >> >>> I have two questions already though: >>> - if we request subsequences, do we add a boolean argument to >>> include the annotations? It would mean that we have to include ALL >>> position independent annotations, and all the ones that are within >>> the range requested? >> >> I think we can include that later, but yes, we would have to do that >> to be consistent. We may even need to add a new annotation to the >> subsequence to keep track of the history of that sequence, using one >> of these 'segment' tag you cited in your initial Annotation email. > Yep, I was thinking that perhaps we should add some method in the > sequence class to have it return a unique id or serial number (the > famous UUID) so that we can uniquely point to a certain sequence. The > segment would be of class BCFeature I guess as it should have the > positional properties to which it applies... > I'm about half way with the basic BCAnnotation class, it will have two > properties (or three perhaps depending on how you see it) along the > lines of the BSML attribute tag: > NSString *name, the name of the attribute, also the key with which it > is stored in the mutable dictionary > NSObject *content. the content of the attribute (can be any kind of > object) > NSString *datatype, the classname of the content object (this is not a > property but a method) > > So for instance an example from the BSML pdf would be the following > example: > > which would be come: > NSString *name -> @"Subcellular Location" > NSObject *content -> @"Cytoplasmic" > NSString *datatype -> @"NSString" > > The BCFeature would add a range property plus logic for modifying it > and helper methods like startposition, endposition etc) > A segment feature example would then become: > NSString *name -> @"Segment" > NSObject *content -> @"1921292" <- UUID in this case, or another > reference (object) to another sequence, in principle this could even > be the segment's BCSequence object ;-) > NSString *datatype -> @"NSString" > NSRange range -> NSRange {1212, 12} > > The question perhaps rises if we want each annotation to have a set of > properties that identify the creator/date etc of the annotation, say > the metadata of the annotation. > >>> - do we use 1 or 0 based ranges? For the first 10 bases, do I create >>> a range {0,10} or {1,10}. I think it would be nicest to use >>> NSRanges, we can compensate in the accessors if necessary I guess... >> >> The issue of 0 vs 1 is a problem with cDNAs and the transcription or >> translation starting point, or is it a more widely used convention? >> One problem with the +1 convention is the absence of 0, IIRC. The >> positions goes -2, -1, +1, +2, right? > Yes, guess so, but those are relative positions, so 0 in that case is > the base itself. >> Anyway, that's a tough question. IMO, we should use a 0 based range >> to stick to the Cocoa conventions. In the Cocoa NSRange convention, >> the first character of a string is anyway not at position 0 or 1, but >> in between the two! > > Yep, I would like to have it 0 based as well.... The ranges the > findSubsequence methods use are also 0-based right? Guess, that's > settled then... Correct me if I'm wrong but I believe BioJava's > sequences are 1-based, but Koen might know better. > >> Of course, the BCSequenceView would have to display the correct >> numbers, Alex ;-) > Yeah yeah, LOL I got the message ;-) > I'll let you know when the BCAnnotation class is in the CVS, ready to > burn it down, haha > Cheers, > Alex > > >> >> charles >> >> -- >> Help science go fast forward: >> http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ >> >> Charles Parnot >> charles.parnot at stanford.edu >> >> Room B157 in Beckman Center >> 279, Campus Drive >> Stanford University >> Stanford, CA 94305 (USA) >> >> Tel +1 650 725 7754 >> Fax +1 650 725 8021 >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> >> > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Claiming that the Macintosh is inferior to Windows > because most people use Windows, is like saying > that all other restaurants serve food that is > inferior to McDonalds > > ********************************************************* > > > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Windows is a 32-bit patch to a 16-bit shell for an 8-bit > operating system, written for a 4-bit processor by a 2- > bit company without 1 bit of sense. > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* From biococoa at bioworxx.com Tue Feb 22 17:11:12 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Tue, 22 Feb 2005 23:11:12 +0100 Subject: [Biococoa-dev] HMMs & mailinglist problem Message-ID: Hey, since peter added me to the developers list, i didn't get any mails from the mailinglist. Someone a idea ? I will commit some header ideas for the alignment & hmm structures for discussion tomorrow i think cheers Phil From mek at mekentosj.com Tue Feb 22 17:12:34 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 23:12:34 +0100 Subject: [Biococoa-dev] Compilation warnings with tools In-Reply-To: References: Message-ID: On 8-feb-05, at 16:55, John Timmer wrote: > I should also explicitly state that, as I want the convenience > methods, I'll > put them in. Hey, I want them as well! ;-) But I'll have to dive in the sequences first to see how everything works now... Also, once the basis is set for the sequences, annotations, and seqIO, we definitely have to write documentation ;-) Cheers, Alex > ************************************************************** ** Alexander Griekspoor ** ************************************************************** The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From mek at mekentosj.com Tue Feb 22 17:41:45 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 22 Feb 2005 23:41:45 +0100 Subject: [Biococoa-dev] HMMs & mailinglist problem In-Reply-To: <6ce9ef452dadb352cb736a47a2610a9b@bioworxx.com> References: <0238bb002b2e0377e8f1007b94e9fc56@mekentosj.com> <6ce9ef452dadb352cb736a47a2610a9b@bioworxx.com> Message-ID: <05ca188ee644bcaf5ba08902807e1a9e@mekentosj.com> >>> I will commit some header ideas for the alignment & hmm structures >>> for discussion tomorrow i think Phil, perhaps it's best if you create a BCAlignment folder inside the BCFoundation folder of the framework. CVS is pretty crap when it comes down to moving folders further down the road (in fact you can't delete folders once created), so be careful before creating too many of them... Looking forward to your work, Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* From kvddrift at earthlink.net Tue Feb 22 18:01:16 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 18:01:16 -0500 Subject: HELP!!! (was: Re: SCM update (was: [Biococoa-dev] Annotation)) In-Reply-To: References: <01a3845719fb698b6bcb08b69a703adf@earthlink.net> <1fa9e0310afca70fed442cba40e730dc@earthlink.net> <5c5dfcd3b91a2da56bf79088b178ef4b@earthlink.net> <7b50ea6c2ff0b67033183ce091332356@earthlink.net> Message-ID: <06e9339d34256140ee6216e1705e5987@earthlink.net> On Feb 22, 2005, at 1:22 PM, Charles PARNOT wrote: > OK, I did it for you! > > And you are back on that page: > http://bioinformatics.org/cgi-bin/cvsweb.cgi/BioCocoa/ > BioCocoa.pbproj/?only_with_tag=MAIN > > I did not try to checkout and test because I would need to create koen > user on my computer ;-) > woohoohoo!!!! It works. Checkout also goes fine so far. Need to catch up with all the emails later tonight ;-) many thanks! - Koen. From charles.parnot at stanford.edu Tue Feb 22 18:16:23 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 15:16:23 -0800 Subject: [Biococoa-dev] HMMs & mailinglist problem In-Reply-To: <05ca188ee644bcaf5ba08902807e1a9e@mekentosj.com> References: <0238bb002b2e0377e8f1007b94e9fc56@mekentosj.com> <6ce9ef452dadb352cb736a47a2610a9b@bioworxx.com> <05ca188ee644bcaf5ba08902807e1a9e@mekentosj.com> Message-ID: At 23:41 +0100 2/22/05, Alexander Griekspoor wrote: >>>>I will commit some header ideas for the alignment & hmm structures for discussion tomorrow i think >Phil, perhaps it's best if you create a BCAlignment folder inside the BCFoundation folder of the framework. CVS is pretty crap when it comes down to moving folders further down the road (in fact you can't delete folders once created), so be careful before creating too many of them... >Looking forward to your work, >Alex Yes, but remember to not use relative paths in the #import-s, as they might fail when compiling a separate project that uses the framework, because then the headers will be found in a flat directory inside the framework, and the '../../' et al. won't make sense. And ultimately, we want people to link against the BioCocoa framework in their project, right ;-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 22 18:19:21 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 15:19:21 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <0f45f8c7c22c6add17a77d3e133621f7@mekentosj.com> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> <0f45f8c7c22c6add17a77d3e133621f7@mekentosj.com> Message-ID: At 22:57 +0100 2/22/05, Alexander Griekspoor wrote: >Ok guys, I've completed the BCAnnotation class, next up, implementation in BCAbstractSequence and sequencereader. (these classes also have to take care of the predefined names. I've temporarily added some code to test the new class in the awakeFromNib method of the translation demo. It prints out the tests to the console and demos some of the methods... >Cheers, >Alex I don't know what the plan is, but should not we have a BCFeatureSet or BCAnnotationSet class to manage sets of annotations and perform smart queries. I am usually not a big fan of too many classes, but the way things are going, a separate class could make sense; this whole thing could have a life of its own, no? For example, to resolve conflicts and inconsistencies, (e.g. multiple features with the same name,...). charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Tue Feb 22 18:20:54 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 00:20:54 +0100 Subject: [Biococoa-dev] HMMs & mailinglist problem In-Reply-To: References: <0238bb002b2e0377e8f1007b94e9fc56@mekentosj.com> <6ce9ef452dadb352cb736a47a2610a9b@bioworxx.com> <05ca188ee644bcaf5ba08902807e1a9e@mekentosj.com> Message-ID: Got it! On 23-feb-05, at 0:16, Charles PARNOT wrote: > At 23:41 +0100 2/22/05, Alexander Griekspoor wrote: >>>>> I will commit some header ideas for the alignment & hmm structures >>>>> for discussion tomorrow i think >> Phil, perhaps it's best if you create a BCAlignment folder inside the >> BCFoundation folder of the framework. CVS is pretty crap when it >> comes down to moving folders further down the road (in fact you can't >> delete folders once created), so be careful before creating too many >> of them... >> Looking forward to your work, >> Alex > > Yes, but remember to not use relative paths in the #import-s, as they > might fail when compiling a separate project that uses the framework, > because then the headers will be found in a flat directory inside the > framework, and the '../../' et al. won't make sense. And ultimately, > we want people to link against the BioCocoa framework in their > project, right ;-) > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From mek at mekentosj.com Tue Feb 22 18:41:28 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 00:41:28 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> <0f45f8c7c22c6add17a77d3e133621f7@mekentosj.com> Message-ID: <52dc349075d3e35e2f34639d7af3c8cb@mekentosj.com> Hmm, perhaps in a (not too distant future) yes, we might need the set objects. Right now, I first like to setup the system without. For instance, would you like EVERY annotation and feature to be at least part of set? Or do you like to see sets and individual annotations be mixed? The way I see it, an annotation-/featureset could be a subclass of BCAnnotation/BCFeature that is identical except that it has as content an array of annotations/features plus some logic to do things like testing, sorting and managing the set. A relatively simple extension. The reason why is that a set of annotations/features is basically an annotation/feature itself (including range specificity). An examples on the benefit from this implementation: Suppose a featureset has 10 features with there own ranges, than we can override the range method of the featureset subclass to calculate and return a union range of the ranges of all its members. Note that in contrast to the general BCFeature class, the content of the BCFeatureSet subclass can only be a mutable dictionary which is limited to contain BCFeature objects only, but that's easy to control of course. > I don't know what the plan is, but should not we have a BCFeatureSet > or BCAnnotationSet class to manage sets of annotations and perform > smart queries. Do you have an example in mind? > For example, to resolve conflicts and inconsistencies, (e.g. multiple > features with the same name,...). I don't think that this is a problem, in fact why not allow multiple features with the same name? For instance the example with the enzymes I mentioned, what I would do is just add 20 features of type com.mekentosj.enzymex.EcoRI with only the ranges different between the objects. We simply have to let the sequence class return an array of all occurences of this name. Of course you could have to methods, annotationWithName: and annotationArrayWithName:, the first returning the first instance found, the other returning all of them (which is undoubtfully slower). And yes, it would be wise for me as a developer to nest all these in a BCFeatureSet called com.mekentosj.enzymex for instance. What do you think, let's add these set subclasses immediately, or build it as an intermediate layer later? If you prefer the first option, I'll see what I can do... and think a bit in the mean time how we would write these away in a file ;-) Cheers, Alex > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From kvddrift at earthlink.net Tue Feb 22 18:53:38 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 18:53:38 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> Message-ID: On Feb 22, 2005, at 6:00 AM, Alexander Griekspoor wrote: > - do we use 1 or 0 based ranges? For the first 10 bases, do I create a > range {0,10} or {1,10}. I think it would be nicest to use NSRanges, we > can compensate in the accessors if necessary I guess... > Whatever we do within the framework, I strongly suggest that we make all sequence-accessors 1-based. This will be handy in many situations: searching, aligning, digesting, etc. - Koen. From biococoa at bioworxx.com Tue Feb 22 18:58:18 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Wed, 23 Feb 2005 00:58:18 +0100 Subject: [Biococoa-dev] BCAlignment header added Message-ID: <62b0783435bcba3a77e58878aa57eb7d@bioworxx.com> Hi everybody, i added a simple start for our alignment objects. I think we should discuss what everybody thinks a Alignment should be. Another thing about the BCAnnotations .. I would suggest a BCAnnotable protocol with - (void)setAnnotation:(id)aAnnotation forKey:(id)key; - (id)annotationForKey:(id)key; - (class)classForKey:(id)key; this would lead us to a much sleeker structure. I think we will run into performance problems, if we have to handle that complex structure in every BCSequence object. and with the protocol everything could be annotable even the Alignment or other things as well. cheers Phil From a.griekspoor at nki.nl Tue Feb 22 18:58:38 2005 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Wed, 23 Feb 2005 00:58:38 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> Message-ID: Fine by me, but In that we have to check whether the current methods satisfy this condition (pointing at the subsequence methods for instance)... Alex On 23-feb-05, at 0:53, Koen van der Drift wrote: > > On Feb 22, 2005, at 6:00 AM, Alexander Griekspoor wrote: > >> - do we use 1 or 0 based ranges? For the first 10 bases, do I create >> a range {0,10} or {1,10}. I think it would be nicest to use NSRanges, >> we can compensate in the accessors if necessary I guess... >> > > Whatever we do within the framework, I strongly suggest that we make > all sequence-accessors 1-based. This will be handy in many situations: > searching, aligning, digesting, etc. > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com 4Peaks - For Peaks, Four Peaks. 2004 Winner of the Apple Design Awards Best Mac OS X Student Product http://www.mekentosj.com/4peaks ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* From mek at mekentosj.com Tue Feb 22 19:12:45 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 01:12:45 +0100 Subject: [Biococoa-dev] BCAlignment header added In-Reply-To: <62b0783435bcba3a77e58878aa57eb7d@bioworxx.com> References: <62b0783435bcba3a77e58878aa57eb7d@bioworxx.com> Message-ID: <34e59e31f73e1efa60835c09081b888c@mekentosj.com> > Another thing about the BCAnnotations .. > > I would suggest a BCAnnotable protocol with > > - (void)setAnnotation:(id)aAnnotation forKey:(id)key; > - (id)annotationForKey:(id)key; > - (class)classForKey:(id)key; > > this would lead us to a much sleeker structure. I think we will run > into performance problems, if we have to handle that complex structure > in every BCSequence object. > > and with the protocol everything could be annotable even the Alignment > or other things as well. Great suggestion phil, it would mean that for instance the alignment object/factory/whatever is also able to generate BCAnnotation objects right? An official protocol would indeed be nice. I'll add it to the BCAnnotation class. The protocol would then become the following methods - (void)setAnnotation:(BCAnnotation *)aAnnotation forWithName:(NSString *) aName; - (BCAnnotation *)annotationForName:(NSString *)aName; - (id)contentForName: (NSString *) aName; - (NSString *)dataTypeForName: (NSString *) aName; and the identical methods for features. No clue yet how sets would fit in here, but I'll think about it. perhaps the object supporting this protocol could also have the method: - (NSArray *)availableAnnotations; or something which would return an array of all available annotations it can provide (from a plist if necessary), like a way to vend them to the user. Note that adding a protocol to the object, still means that all logic to handle, set, store, and manipulate the annotation in an object like BCAbstractSequence still has to be implemented by the class. The protocol will only ensure that all these objects have a uniform interface with respect to setting and getting annotations.... Any thoughts on this are welcome of course... Now, I will quickly peek at your alignment code as I'm really curious, and then I really have to get some sleep... Cheers, Alex > > cheers > > Phil > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* From mek at mekentosj.com Tue Feb 22 19:18:36 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 01:18:36 +0100 Subject: [Biococoa-dev] BCAlignment header added In-Reply-To: <62b0783435bcba3a77e58878aa57eb7d@bioworxx.com> References: <62b0783435bcba3a77e58878aa57eb7d@bioworxx.com> Message-ID: <758ef0ebbc88ca2f60bd36a57601c57e@mekentosj.com> Oh shoot, forgot to tell, we try to mirror the hierarchy in xcode also in the filesystem, i.a.w. we should also create a physical BCAlignment folder in the BCFoundation one. I've updated from CVS and although it's fine in the XCode project, the Alignment.h/m files show up in the root of the BioCocoa folder on disk. Well, guess this can be changed later, no worries... Something for next time... Cheers, Alex On 23-feb-05, at 0:58, Philipp Seibel wrote: > Hi everybody, > > i added a simple start for our alignment objects. I think we should > discuss what everybody thinks a Alignment should be. > > Another thing about the BCAnnotations .. > > I would suggest a BCAnnotable protocol with > > - (void)setAnnotation:(id)aAnnotation forKey:(id)key; > - (id)annotationForKey:(id)key; > - (class)classForKey:(id)key; > > this would lead us to a much sleeker structure. I think we will run > into performance problems, if we have to handle that complex structure > in every BCSequence object. > > and with the protocol everything could be annotable even the Alignment > or other things as well. > > cheers > > Phil > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From biococoa at bioworxx.com Tue Feb 22 19:21:24 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Wed, 23 Feb 2005 01:21:24 +0100 Subject: [Biococoa-dev] Annotation Message-ID: <60a9b2d35c3a27907d0cdfcd14a992d7@bioworxx.com> Hey Alex, why do you use NSString * instead of using class for the returntype of dataTypeForName: ? i think its better to have a classForAnnotationWithName: which returns the class not a String representation you mensioned sleep .... very good idea ;-) Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 340 bytes Desc: not available URL: From kvddrift at earthlink.net Tue Feb 22 19:47:43 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 19:47:43 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> Message-ID: <15927b1f95fc411616af31b742b5517e@earthlink.net> On Feb 22, 2005, at 6:58 PM, Alexander Griekspoor wrote: > Fine by me, but In that we have to check whether the current methods > satisfy this condition (pointing at the subsequence methods for > instance)... > I'm pretty sure they don't :) A 'hack' solution could be to add a dummy empty BCSymbol at the beginning of a symbolarray. Not sure if that would give problems in other classes, though. - Koen. From kvddrift at earthlink.net Tue Feb 22 19:58:25 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 19:58:25 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> Message-ID: <62fea2117c4ca7b39a860a6d77cad964@earthlink.net> On Feb 22, 2005, at 1:32 PM, Alexander Griekspoor wrote: > >>> - do we use 1 or 0 based ranges? For the first 10 bases, do I create >>> a range {0,10} or {1,10}. I think it would be nicest to use >>> NSRanges, we can compensate in the accessors if necessary I guess... >> >> The issue of 0 vs 1 is a problem with cDNAs and the transcription or >> translation starting point, or is it a more widely used convention? >> One problem with the +1 convention is the absence of 0, IIRC. The >> positions goes -2, -1, +1, +2, right? > Yes, guess so, but those are relative positions, so 0 in that case is > the base itself. >> Anyway, that's a tough question. IMO, we should use a 0 based range >> to stick to the Cocoa conventions. In the Cocoa NSRange convention, >> the first character of a string is anyway not at position 0 or 1, but >> in between the two! > > Yep, I would like to have it 0 based as well.... The ranges the > findSubsequence methods use are also 0-based right? Guess, that's > settled then... Correct me if I'm wrong but I believe BioJava's > sequences are 1-based, but Koen might know better. > Ha, I missed this in all the messages from today, and already replied on Alex's original question in a separate email. Yes, I think BioJava uses a 1-based sequence. But I don't think Java have nice build-in array's, so they had to write them theirselves. As I said, internally we can use the 0-based code. However, imagine a find sequence dialog window. That should accept and return values that are 1-based. Should that be the responsibility of the developer, or should it be BioCocoa's? I would say the latter, but if we decide on going 0-based all the way, then we have to document that very well. >> Of course, the BCSequenceView would have to display the correct >> numbers, Alex ;-) > Yeah yeah, LOL I got the message ;-) > I'll let you know when the BCAnnotation class is in the CVS, ready to > burn it down, haha > I can add something too, including symbols numbers. I probably have to add a view + nib and maybe a controller. Any ideas how we are going to organize the code within BCAppKit? - Koen. ps - great work everyone - it's good to see all the new code being added!!! From biococoa at bioworxx.com Tue Feb 22 20:08:57 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Wed, 23 Feb 2005 02:08:57 +0100 Subject: [Biococoa-dev] removed my mistakes Message-ID: <5a0b867899a6bb2d2cd702b493e78bca@bioworxx.com> Hi, i removed my mistakes from the repository, hopefully i did it correct. Tomorrow i will start a new try bye Phil From kvddrift at earthlink.net Tue Feb 22 21:02:52 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 21:02:52 -0500 Subject: [Biococoa-dev] BCSequenceView Message-ID: <483c68d8c7cf1850817f9d781366333b@earthlink.net> Hi, I added an initial version of a BCSequenceView. It's a subclass of NSTextView, so it should be fed an NSString to display. It will draw symbol or line numbers in the margin, and can draw gaps every 10th symbol. This can be changed in the updateLayout method. - Koen. From kvddrift at earthlink.net Tue Feb 22 21:38:27 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 21:38:27 -0500 Subject: [Biococoa-dev] BCSequenceView In-Reply-To: <483c68d8c7cf1850817f9d781366333b@earthlink.net> References: <483c68d8c7cf1850817f9d781366333b@earthlink.net> Message-ID: <8671fedd2cc9d9e8c35ee3468e5d7809@earthlink.net> On Feb 22, 2005, at 9:02 PM, Koen van der Drift wrote: > Hi, > > I added an initial version of a BCSequenceView. It's a subclass of > NSTextView, so it should be fed an NSString to display. It will draw > symbol or line numbers in the margin, and can draw gaps every 10th > symbol. This can be changed in the updateLayout method. > > Excellent, it works in the Translation example as well :) Just make the NSTextView in InterfaceBuilder a BCSequenceView, and tadaa! No more coding needed. How do I update a nib file in CVS? - Koen. From jtimmer at bellatlantic.net Tue Feb 22 21:45:18 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 22 Feb 2005 21:45:18 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: <483c68d8c7cf1850817f9d781366333b@earthlink.net> Message-ID: Quick question: in order to set things up to provide method calls appropriate for sequence types, I was going to put in a BCSequenceNucleotide. I've since realized that to make any sense out of the method signatures, I'm going to need to make a BCSymbolNucleotide. Any objections to this? In the end, it looks like it's going to be an abstract class with most of the possible methods there. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Tue Feb 22 21:57:45 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 22 Feb 2005 21:57:45 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: <8d523ee4f2ef49e4332934e56b45bcd8@earthlink.net> On Feb 22, 2005, at 9:45 PM, John Timmer wrote: > Quick question: in order to set things up to provide method calls > appropriate for sequence types, I was going to put in a > BCSequenceNucleotide. I've since realized that to make any sense out > of the > method signatures, I'm going to need to make a BCSymbolNucleotide. Any > objections to this? In the end, it looks like it's going to be an > abstract > class with most of the possible methods there. > John, I am not sure if I understand why we need a BCSequenceNucleotide (and BCSymbolNucleotide) class. There are only a few methods in both subclasses, so right now I don't see the need for an additional layer that takes care of those methods. Maybe you can refresh my memory? thanks, - Koen. PS, what probably needs some more thoughts is to create a similar structure for the BCSymbol classes that we have just introduced for the BCSequence classes. From harris at cshl.edu Tue Feb 22 22:09:02 2005 From: harris at cshl.edu (Todd Harris) Date: Tue, 22 Feb 2005 20:09:02 -0700 Subject: [Biococoa-dev] new to the list Message-ID: Hi all - I've been lurking on the list for a few weeks but have never introduced myself properly. I'm a scientific programmer -- formerly a postdoc -- in Lincoln Stein's lab at Cold Spring Harbor Laboratory. I'm a biologist by training although I write code full time now. By way of background, I primarily work in Perl as the central developer of WormBase, and on projects like BioPerl and the Generic Model Organism Database project. I just today released what I hope will become a unified API for biological databases, insulating end users from model changes and data mining minutae. I also do basic research in comparative genomics. I'm currently working on algorithms for multiple whole genome alignment and visualization. Anyway, I just wanted to delurk and say hello. I'm reading messages now as I get up to speed with the status of the project. It's clearly a dynamic and dedicated group. I hope to be able to contribute wherever needed. Todd From jtimmer at bellatlantic.net Tue Feb 22 22:44:17 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 22 Feb 2005 22:44:17 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: <8d523ee4f2ef49e4332934e56b45bcd8@earthlink.net> Message-ID: The reasoning is that, over time, we're going to add a lot of methods that will operate on some subset of sequences. Some of these will operate on a specific type of sequence (ie - restriction enzymes, splice site recognition), some will more generically work on nucleotide sequences (ie - translation or complement). As the framework expands, things will probably be easier if we can put the more generic ones in a single class, even if they're only convenience methods. Looking things over, I'm not sure I see the need for further parallelism, but I could be mising something. The exception might be if we wanted to do symbol-specific attributes (phosphorylation, or something similar), instead of having attributes with a length of 1. I'd expect that this would be necessary, but I'd be happy to hear otherwise. JT >> Quick question: in order to set things up to provide method calls >> appropriate for sequence types, I was going to put in a >> BCSequenceNucleotide. I've since realized that to make any sense out >> of the >> method signatures, I'm going to need to make a BCSymbolNucleotide. Any >> objections to this? In the end, it looks like it's going to be an >> abstract >> class with most of the possible methods there. >> > > John, > > I am not sure if I understand why we need a BCSequenceNucleotide (and > BCSymbolNucleotide) class. There are only a few methods in both > subclasses, so right now I don't see the need for an additional layer > that takes care of those methods. Maybe you can refresh my memory? > > > thanks, > > - Koen. > > > PS, what probably needs some more thoughts is to create a similar > structure for the BCSymbol classes that we have just introduced for the > BCSequence classes. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Tue Feb 22 22:48:34 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 19:48:34 -0800 Subject: Archiving annotations (was: [Biococoa-dev] Annotation) In-Reply-To: References: Message-ID: >Another idea: >how do we write out these things? simple, only accept custom objects that adhere to the protocol. All objects that aren't natively supported by plist encoding, can be archived into NSData and written as such in the xml. The nice thing is that the datatype (= className) is written in the xml as well, so that makes it easy to unarchive the thing. It needs some logic to control/check but its powerful I think. I can even add a simple - (NSData *)encodedContent; method to the BCAnnotation class which does the work, and can be used by the BSML writer. It can even check whether coding is supported by the custom class and return nil if it does not (in case the object is lost during a write. >This actually leads me to another question right at the spot, is it a good idea to add a boolean "archive" or something to an annotation? This way you can actively decide whether the annotation should be written out to disk or not (think of temporary attributes, like the one in NSAttributedStrings). For instance, during the life of my program it might be nice to add custom (non-writable) objects to your sequence, but you might not want those be saved with the file (or you're not able to). This way you can specify which are to be saved and which not.... >....and think a bit in the mean time how we would write these away in a file ;-) This scheme to save objects to disk is perfect. I like the additional BOOL 'shouldArchive'. I actually also liked the additional fiels 'creator' and 'creationDate' (or something like this?) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 22 22:55:42 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 19:55:42 -0800 Subject: Annotation sets (was: [Biococoa-dev] Annotation) In-Reply-To: <52dc349075d3e35e2f34639d7af3c8cb@mekentosj.com> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> <0f45f8c7c22c6add17a77d3e133621f7@mekentosj.com> <52dc349075d3e35e2f34639d7af3c8cb@mekentosj.com> Message-ID: At 12:41 AM +0100 2/23/05, Alexander Griekspoor wrote: >Hmm, perhaps in a (not too distant future) yes, we might need the set objects. Right now, I first like to setup the system without. For instance, would you like EVERY annotation and feature to be at least part of set? Or do you like to see sets and individual annotations be mixed? >The way I see it, an annotation-/featureset could be a subclass of BCAnnotation/BCFeature that is identical except that it has as content an array of annotations/features plus some logic to do things like testing, sorting and managing the set. A relatively simple extension. The reason why is that a set of annotations/features is basically an annotation/feature itself (including range specificity). An examples on the benefit from this implementation: >Suppose a featureset has 10 features with there own ranges, than we can override the range method of the featureset subclass to calculate and return a union range of the ranges of all its members. Note that in contrast to the general BCFeature class, the content of the BCFeatureSet subclass can only be a mutable dictionary which is limited to contain BCFeature objects only, but that's easy to control of course. > >>I don't know what the plan is, but should not we have a BCFeatureSet or BCAnnotationSet class to manage sets of annotations and perform smart queries. >Do you have an example in mind? > >> For example, to resolve conflicts and inconsistencies, (e.g. multiple features with the same name,...). >I don't think that this is a problem, in fact why not allow multiple features with the same name? For instance the example with the enzymes I mentioned, what I would do is just add 20 features of type com.mekentosj.enzymex.EcoRI with only the ranges different between the objects. We simply have to let the sequence class return an array of all occurences of this name.... I should not have used the word 'inconsistent' ;-) I am thinking more complicated queries like featureWithName:inRange:,... Everything could fit in the current BCAbstractSequence, but a class of its own might make sense, with all these combinations to handle. Also, the BCFeatureSet could be used in other classes of the framework at some point, maybe? (hint: alignments!) But you are right. Let's just see first where that gets us with the sequences, and then we can add another layer. It seems funny to have a set a subclass of the items, but I understand the logic, and I kind of like it the way you present it! >What do you think, let's add these set subclasses immediately, or build it as an intermediate layer later? If you prefer the first option, I'll see what I can do... and think a bit in the mean time how we would write these away in a file ;-) >Cheers, >Alex OK, I answered that... now, have a good day! Time to get up, it is ~4 in the morning in Europe... charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Tue Feb 22 22:58:22 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 19:58:22 -0800 Subject: [Biococoa-dev] Annotation In-Reply-To: <60a9b2d35c3a27907d0cdfcd14a992d7@bioworxx.com> References: <60a9b2d35c3a27907d0cdfcd14a992d7@bioworxx.com> Message-ID: At 1:21 AM +0100 2/23/05, Philipp Seibel wrote: >Hey Alex, > >why do you use NSString * instead of using class for the returntype >of dataTypeForName: ? >i think its better to have a classForAnnotationWithName: which >returns the class not a String representation > >you mensioned sleep .... very good idea ;-) > >Phil I jump in! The accessor could return the class, but internally it should be a NSString to: * allow archiving * handle unknown classes, which could happen if you go from one app to another using the framework and using the same file This is probably what you meant: just the accessor, right? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtimmer at bellatlantic.net Tue Feb 22 23:05:15 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 22 Feb 2005 23:05:15 -0500 Subject: [Biococoa-dev] new to the list In-Reply-To: Message-ID: Welcome! It looks like we've got a few professionals on board now - it'll be good to have your perspective, and hope I don't come across as too clueless when you go through the archive. Do you have some links to point us to so that we can check into the database adapter? I'd be interested in looking it over. Cheers, John > Hi all - > > I've been lurking on the list for a few weeks but have never introduced > myself properly. > > I'm a scientific programmer -- formerly a postdoc -- in Lincoln Stein's lab > at Cold Spring Harbor Laboratory. I'm a biologist by training although I > write code full time now. > > By way of background, I primarily work in Perl as the central developer of > WormBase, and on projects like BioPerl and the Generic Model Organism > Database project. I just today released what I hope will become a unified > API for biological databases, insulating end users from model changes and > data mining minutae. I also do basic research in comparative genomics. I'm > currently working on algorithms for multiple whole genome alignment and > visualization. > > Anyway, I just wanted to delurk and say hello. I'm reading messages now as > I get up to speed with the status of the project. It's clearly a dynamic > and dedicated group. I hope to be able to contribute wherever needed. > > Todd _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Tue Feb 22 23:05:24 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 20:05:24 -0800 Subject: 0 or 1 based ranges ? (was: [Biococoa-dev] Annotation) In-Reply-To: <62fea2117c4ca7b39a860a6d77cad964@earthlink.net> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> <62fea2117c4ca7b39a860a6d77cad964@earthlink.net> Message-ID: At 7:58 PM -0500 2/22/05, Koen van der Drift wrote: >On Feb 22, 2005, at 1:32 PM, Alexander Griekspoor wrote: > >> >>>>- do we use 1 or 0 based ranges? For the first 10 bases, do I create a range {0,10} or {1,10}. I think it would be nicest to use NSRanges, we can compensate in the accessors if necessary I guess... >>> >>>The issue of 0 vs 1 is a problem with cDNAs and the transcription or translation starting point, or is it a more widely used convention? One problem with the +1 convention is the absence of 0, IIRC. The positions goes -2, -1, +1, +2, right? >>Yes, guess so, but those are relative positions, so 0 in that case is the base itself. >>>Anyway, that's a tough question. IMO, we should use a 0 based range to stick to the Cocoa conventions. In the Cocoa NSRange convention, the first character of a string is anyway not at position 0 or 1, but in between the two! >> >>Yep, I would like to have it 0 based as well.... The ranges the findSubsequence methods use are also 0-based right? Guess, that's settled then... Correct me if I'm wrong but I believe BioJava's sequences are 1-based, but Koen might know better. >> > >Ha, I missed this in all the messages from today, and already replied on Alex's original question in a separate email. Yes, I think BioJava uses a 1-based sequence. But I don't think Java have nice build-in array's, so they had to write them theirselves. As I said, internally we can use the 0-based code. However, imagine a find sequence dialog window. That should accept and return values that are 1-based. Should that be the responsibility of the developer, or should it be BioCocoa's? I would say the latter, but if we decide on going 0-based all the way, then we have to document that very well. Maybe we should have some methods that explicitely give the choice to the user of the framework? The convention for ranges is so well established that it is going to be confusing for us and for some users. So we could have methods like 'subsequenceWithRange:' and 'subsequenceWithSequenceRange:'.... the naming is not very good, uh? Actually, maybe we could create a new struct to handle 1-based ranges, something like BCSequenceRange?? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Wed Feb 23 00:44:05 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 21:44:05 -0800 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: At 10:44 PM -0500 2/22/05, John Timmer wrote: >The reasoning is that, over time, we're going to add a lot of methods that >will operate on some subset of sequences. Some of these will operate on a >specific type of sequence (ie - restriction enzymes, splice site >recognition), some will more generically work on nucleotide sequences (ie - >translation or complement). As the framework expands, things will probably >be easier if we can put the more generic ones in a single class, even if >they're only convenience methods. > >Looking things over, I'm not sure I see the need for further parallelism, >but I could be mising something. The exception might be if we wanted to do >symbol-specific attributes (phosphorylation, or something similar), instead >of having attributes with a length of 1. I'd expect that this would be >necessary, but I'd be happy to hear otherwise. > >JT I agree that we probably don't want to parallel the sequence class structure in the symbol subclasses. But where do we need a BCSymbolNucleotide? The phosphorylation et al. idea is a good point and something to keep in mind, yes! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Wed Feb 23 00:50:14 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 21:50:14 -0800 Subject: [Biococoa-dev] new to the list In-Reply-To: References: Message-ID: At 8:09 PM -0700 2/22/05, Todd Harris wrote: >Hi all - > >I've been lurking on the list for a few weeks but have never introduced >myself properly. > >I'm a scientific programmer -- formerly a postdoc -- in Lincoln Stein's lab >at Cold Spring Harbor Laboratory. I'm a biologist by training although I >write code full time now. > >By way of background, I primarily work in Perl as the central developer of >WormBase, and on projects like BioPerl and the Generic Model Organism >Database project. I just today released what I hope will become a unified >API for biological databases, insulating end users from model changes and >data mining minutae. I also do basic research in comparative genomics. I'm >currently working on algorithms for multiple whole genome alignment and >visualization. > >Anyway, I just wanted to delurk and say hello. I'm reading messages now as >I get up to speed with the status of the project. It's clearly a dynamic >and dedicated group. I hope to be able to contribute wherever needed. > >Todd > Welcome! It is nice to have somebody with such a background. Hopefully, that will prevent us from reinventing the wheel!! Today's mailing list activity was quite crazy, too... For Todd and Philipp: I am a biologist (mostly at the bench), with a strong background in maths and physics (mostly in the classroom), and with ~ 1 year of work-related experience in Cocoa; but not much experience in bioinformatics per se. Follow the link in my signature to learn more about my main current project. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Wed Feb 23 01:19:39 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Tue, 22 Feb 2005 22:19:39 -0800 Subject: [Biococoa-dev] Unit testing: poll Message-ID: I gave unit testing a try, like I explained before, and added more test classes for the sequence classes. I can only say again that I liked it a lot. It is very easy to quickly set a new test, it is a great way to think about what we really want to make with the class being tested. And the nice thing about it is that it should be quite insensitive to refactoring of the framework (if used properly), which means very little maintenance. Ideally, these tests keep accumulating over time and you rarely destroy any. And you don't need any headerdoc, just some regular comments. The code itself will usually be short and self-explanatory. Then, there is Koen's question: how do you test the tests? At first, I thought it was a nice joke. Then I realized the tests themselves are in fact tests for themselves. When they fail, it is either the framework or the test. So there is an answer for Koen's question: if the test has a bug, it will fail! There you go... Anyway, the bottom line is: * should we add unit testing? By reading about it, it seems to require some very strict habits of writing tests all the time, but somehow, I got the feeling that was mostly for commercial program with deadlines and doing this scary 'extreme programing' thing. I believe that we can add tests as we go without being too obsessed with them. As I say, they will grow over time and with several programers involved, they will eventually be in sync with the project. One good habit for sure is: when you find a bug, add a test to prevent it from happening again in the future. * should we use OCUnit? All these frameworks look about the same and I had the feeling this one had been around for a while and was updated frequently, this is why I picked it. I found it really easy to use. Also, it is released with a BSD license, which means it is quite compatible with LPGL (anyway, we would not use any portion of the code anywhere, so the problem is probably moot). * one drawback is that new BioCocoa developers will have to install the OCUnit framework in addition to the checkout of the project, as we can not simply include it in the current project; however, it is only really needed when running the tests; the test bundle could however be part of the project and be easily run at any time >From last week, it seemed most people liked the idea, but I thought I'd ask again now that we have more people before adding yet another folder and a new target and 10 more files... charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Wed Feb 23 02:50:28 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 08:50:28 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: <60a9b2d35c3a27907d0cdfcd14a992d7@bioworxx.com> References: <60a9b2d35c3a27907d0cdfcd14a992d7@bioworxx.com> Message-ID: Yeah, I'll change that.... On 23-feb-05, at 1:21, Philipp Seibel wrote: > Hey Alex, > > why do you use NSString * instead of using class for the returntype of > dataTypeForName: ? > i think its better to have a classForAnnotationWithName: which returns > the class not a String representation > > you mensioned sleep .... very good idea ;-) > > Phil_______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1358 bytes Desc: not available URL: From a.griekspoor at nki.nl Wed Feb 23 02:51:43 2005 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Wed, 23 Feb 2005 08:51:43 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: <15927b1f95fc411616af31b742b5517e@earthlink.net> References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <15927b1f95fc411616af31b742b5517e@earthlink.net> Message-ID: <56441d24250699919d41434c7267feff@nki.nl> Oh no, no hacks please... Either, the interface should simply always correct for the difference or we stick at a 0 based system... Alex On 23-feb-05, at 1:47, Koen van der Drift wrote: > > On Feb 22, 2005, at 6:58 PM, Alexander Griekspoor wrote: > >> Fine by me, but In that we have to check whether the current methods >> satisfy this condition (pointing at the subsequence methods for >> instance)... >> > > I'm pretty sure they don't :) > > A 'hack' solution could be to add a dummy empty BCSymbol at the > beginning of a symbolarray. Not sure if that would give problems in > other classes, though. > > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From mek at mekentosj.com Wed Feb 23 03:03:52 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 09:03:52 +0100 Subject: [Biococoa-dev] Annotation In-Reply-To: References: <60a9b2d35c3a27907d0cdfcd14a992d7@bioworxx.com> Message-ID: Ok, yes, I'm awake, and yes, I'm still sleepy. Indeed one of the benefits of the NSString as charles mentioned was that along the lines of the BSML format it's handy to have it as a string for archiving and stuff. That's the reason... Also, it's a method, not an accessor it generates the NSString upon request. BUT, what I can do of course is add a - classForName: method in addition, perhaps a better alternative. Cheers, and good morning, Alex Ps. I realize this doesn't help reducing today's list traffic ;-) On 23-feb-05, at 8:50, Alexander Griekspoor wrote: > Yeah, I'll change that.... > > On 23-feb-05, at 1:21, Philipp Seibel wrote: > >> Hey Alex, >> >> why do you use NSString * instead of using class for the returntype >> of dataTypeForName: ? >> i think its better to have a classForAnnotationWithName: which >> returns the class not a String representation >> >> you mensioned sleep .... very good idea ;-) >> >> Phil_______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Windows is a 32-bit patch to a 16-bit shell for an 8-bit > operating system, written for a 4-bit processor by a 2- > bit company without 1 bit of sense. > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2878 bytes Desc: not available URL: From biococoa at bioworxx.com Wed Feb 23 04:08:28 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Wed, 23 Feb 2005 10:08:28 +0100 Subject: [Biococoa-dev] BCSequence implementation Message-ID: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> Morning everyone, i think we should be careful by adding more and more features to the BCSequence. We have to keep in mind that for many sequence related algorithms it is better to have a sleek Object. We shouldn't design a full featured object as base class. I think categories is the best solution to add features like Annotations and Features to the Sequence object. cheers Phil From mek at mekentosj.com Wed Feb 23 05:41:02 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 11:41:02 +0100 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> References: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> Message-ID: <39a870ed3d726079f428a987ad19a2b7@mekentosj.com> Hi phil, We previously had this discussion as well so I guess it's a relevant one. In principle I don't have a problem with categories (anymore ;-) to add these features and keep the base class lean and small. I would strongly argue to keep them in the same .h/.m file though (like apple seems to do). The real question then of course is, how do I get a slimmed down sequence objects without the added categories? Is that possible at all? And perhaps the real real question is, does that really matter? Does your code becomes slower when you add methods and arguments but don't use them? I can hardly imagine that a pointer to a dictionary (even kept nil if you don't add annotations) make a lot of difference in the end. With symbols I can imagine, but with sequences? Perhaps we can discuss this in analogy to NSString. That seems a class very alike to our sequence class and it does contain many methods. Can you describe how you see the design of NSString and the similarities with our class? How would you implement the categories? If I take a quick look at the NSString header file, I see @interface NSString : NSObject [..] //base @end @interface NSString (NSStringExtensionMethods) [..] //most methods @end @interface NSMutableString : NSString [..] //mutable base @end @interface NSMutableString (NSMutableStringExtensionMethods) [..] //most mutable methods @end @interface NSString (NSExtendedStringPropertyListParsing) [..] //some plist stuff @end So yes, they use categories as well, with a very simple NSString base, and the rest implemented as extensions. BUT, unless you ask for a NSMutableString, you get ALL methods if you ask for an NSString right?! So how would you get the base string only? That can only be if this would be the public header, while internally they have kept things separated (multiple headers), so that they internally can use the base classes, and we not). OR we decide to keep all extensions separated with separate headers that you have to import to add the functionality to the sequence class. I'm not sure though whether it would than be wiser to make subclasses instead of spreading the code of the sequence class throughout different files.... hmmm... Again the question is if there's a real advantage of having a very minimalistic basic sequence class... Anyone wants to jump in? Alex On 23-feb-05, at 10:08, Philipp Seibel wrote: > Morning everyone, > > i think we should be careful by adding more and more features to the > BCSequence. We have to keep in mind that for many sequence related > algorithms it is better to have a sleek Object. We shouldn't design a > full featured object as base class. I think categories is the best > solution to add features like Annotations and Features to the Sequence > object. > > cheers > > Phil > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4159 bytes Desc: not available URL: From mek at mekentosj.com Wed Feb 23 05:42:01 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 11:42:01 +0100 Subject: [Biococoa-dev] BCSequenceView In-Reply-To: <483c68d8c7cf1850817f9d781366333b@earthlink.net> References: <483c68d8c7cf1850817f9d781366333b@earthlink.net> Message-ID: <9e98b05a4aeacee4ca02851dd83519b8@mekentosj.com> Great!! On 23-feb-05, at 3:02, Koen van der Drift wrote: > Hi, > > I added an initial version of a BCSequenceView. It's a subclass of > NSTextView, so it should be fed an NSString to display. It will draw > symbol or line numbers in the margin, and can draw gaps every 10th > symbol. This can be changed in the updateLayout method. > > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From mek at mekentosj.com Wed Feb 23 05:46:47 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 11:46:47 +0100 Subject: [Biococoa-dev] BCSequenceView In-Reply-To: <8671fedd2cc9d9e8c35ee3468e5d7809@earthlink.net> References: <483c68d8c7cf1850817f9d781366333b@earthlink.net> <8671fedd2cc9d9e8c35ee3468e5d7809@earthlink.net> Message-ID: Hmm, I had to do a fresh checkout because the BCAppkit folder was previously empty and thus pruned by the cvs checkout.... Alex On 23-feb-05, at 3:38, Koen van der Drift wrote: > > On Feb 22, 2005, at 9:02 PM, Koen van der Drift wrote: > >> Hi, >> >> I added an initial version of a BCSequenceView. It's a subclass of >> NSTextView, so it should be fed an NSString to display. It will draw >> symbol or line numbers in the margin, and can draw gaps every 10th >> symbol. This can be changed in the updateLayout method. >> >> > > > Excellent, it works in the Translation example as well :) Just make > the NSTextView in InterfaceBuilder a BCSequenceView, and tadaa! No > more coding needed. > > How do I update a nib file in CVS? > > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 E-mail: a.griekspoor at nki.nl AIM: mekentosj at mac.com Web: http://www.mekentosj.com EnzymeX - To cut or not to cut http://www.mekentosj.com/enzymex ********************************************************* From kvddrift at earthlink.net Wed Feb 23 06:29:35 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 23 Feb 2005 06:29:35 -0500 Subject: [Biococoa-dev] Unit testing: poll In-Reply-To: References: Message-ID: On Feb 23, 2005, at 1:19 AM, Charles PARNOT wrote: > Then, there is Koen's question: how do you test the tests? At first, I > thought it was a nice joke. No joke :) What I meant was, OK, it builds fine, now what I do I do to run it and see the tests results? - Koen. From kvddrift at earthlink.net Wed Feb 23 06:30:36 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 23 Feb 2005 06:30:36 -0500 Subject: [Biococoa-dev] BCSequenceView In-Reply-To: References: <483c68d8c7cf1850817f9d781366333b@earthlink.net> <8671fedd2cc9d9e8c35ee3468e5d7809@earthlink.net> Message-ID: On Feb 23, 2005, at 5:46 AM, Alexander Griekspoor wrote: > Hmm, I had to do a fresh checkout because the BCAppkit folder was > previously empty and thus pruned by the cvs checkout.... > Yes, it was a pain to add the code too for the same reason. And then It took me for ever to realize that the folder in CVS is called BCAppkit, not BCAppKit ;-) - Koen. From jtimmer at bellatlantic.net Wed Feb 23 08:39:16 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 23 Feb 2005 08:39:16 -0500 Subject: [Biococoa-dev] Annotation In-Reply-To: Message-ID: I had a thought on handling the attributes last night. One of the dangers of allowing everything into an attribute is that cruft can build up and the file size balloon, especially if a single sequence is shuffled between applications. It would be nice to have a formalized way of ensuring that a minimal, informative sequence object can be created. So, I suggest that we code for three levels of information: Base level: minimum necessary to hold an attribute: name, type, range, notes. Everything else is removed. Guaranteed to work in any BC-based app. App level: All objects are tested to determine whether the current application has the class to work with is kept; everything else is removed. Verbose level: everything?s there, whether it can be used or not. This way, information that?s been copied, dragged and dropped, etc. can easily be streamlined in a way that?s more appropriate for the receiving app. JT > > > > Ok, yes, I'm awake, and yes, I'm still sleepy. Indeed one of the benefits of > the NSString as charles mentioned was that along the lines of the BSML format > it's handy to have it as a string for archiving and stuff. That's the > reason... Also, it's a method, not an accessor it generates the NSString upon > request. BUT, what I can do of course is add a - classForName: method in > addition, perhaps a better alternative. > Cheers, and good morning, > Alex > > Ps. I realize this doesn't help reducing today's list traffic ;-) > _______________________________________________ This mind intentionally left blank -------------- next part -------------- An HTML attachment was scrubbed... URL: From mek at mekentosj.com Wed Feb 23 08:39:57 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 14:39:57 +0100 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: <6c42bc8f6ff44093036f6855aa94d182@bioworxx.com> References: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> <39a870ed3d726079f428a987ad19a2b7@mekentosj.com> <6c42bc8f6ff44093036f6855aa94d182@bioworxx.com> Message-ID: <4337f2d7595b54a80ad35e6df2eb0be0@mekentosj.com> > you are completely right. It was my fault. I think its nice to have > some categories in one header file, but not due to performance > issues.. (you are right). No problem, indeed it's a good idea to organize the code in categories inside a single header file, it nicely groups all the related code. > I took a look into the BCAbstract Sequence and recognized that the > Object stores the Sequence in a NSArray of BCSymbols. Thats not really > good i think. Imagine handling complete genome sequences or other > stuff. I think we need to store it in a NSString or even simmpe char > array. There could be of course accessor methods for BCSymbols .... > but we really need to care about memory and performance issues. > Especially in the Foundation framework. Again this discussion also predates your arrival at the framework, perhaps you can take a look in the archives... The basic thought here is that we have made the decision very carefully to go for our own BCSequence and BCSymbol class (although the design has recently changed quite dramatically with the arrival of Charles ;-). The reason is pretty simple, although many similarities an NSString is not the same as a sequence. The characters are different, many features are different. Of course we could go for char arrays but that will basically get rid of all the benefits Cocoa (and object oriented design) has to offer us from the start (and thus basically kill the reason to build the framework in the first place). By having our own BCSymbol and BCSequence we think we have an oriented design mimicking NSString (but better) which is way more powerful than basic c arrays can ever be. Well, I hear you think, "that's nice, but my computer will never work with a genome of objects (memory and speedwise)!" That correct, but therefore we are using a simple trick. All symbols are so-called shared instances, meaning that only a single instance is allocated and in memory, and all a sequence array consists of are pointers to this one instance. Yes, this will take up more memory than a char (around 4 times?) but that's more than worth the benefits Cocoa will give us. And to relieve you further, yes there are char and NSString accessors that will give you the desired variable if you need them. But just to make sure, it's a deliberate choice that ALL internal representations of sequences should be in the form of our own BCSequence objects wherever possible. Ideally this includes alignments. I don't think it's a good thing if a method would consist of converting a BCSequence to a string, do the manipulation, and reconvert the string to a BCSequence. All this should be done natively in the BCSequence format, and if that gives one trouble, we should rethink/extend the BCSequence class. Now, I do realize that with the arrival of more people, it's obvious that they are gonna ask themselves and the list (no offense, please do!) the questions that we asked ourselves as well during the initial design of the setup we now implement. Therefore, I think that once the basic BCSequence system is up and running (BCSequence et al, annotations & features, and SeqIO) documentation will become the number one priority. As I want to do spend a bit more (PR) words on BioCocoa on our website anyway, to generate more knowledge and traffic. I'll see if I can combine that with some more explanation of the basic architecture of the BCSequence setup. Until the 1.0 release of BioCocoa and if anyone agrees with the idea, it can become the temporarily (developer) homepage of the new BioCocoa framework, leaving the current one intact as long as we're still in beta (or alpha ;-) phase. Peter, any thoughts on this one? > Another Question: > > What about a BCMutableSequence ... id like to implement one for the > Alignment classes At the moment we've decided to go for a class that's mutable from the beginning, mainly for both performance and technical reasons. Perhaps Charles and John can talk a bit more about this, and I remember a discussion about this issue, so there must be a thread in the archives... It would be nice to have an optimized immutable version in the future, but again Charles might explain you better why that's not so easy with the current implementation, he designed the class cluster approach. So all in all, please don't feel offended by the answers, all your comments are more than welcome and the lack of documentation doesn't really help starters. Feel free to ask us to explain the rational behind different design choices, it will help writing the documentation and FAQs for one! Cheers, Alex Ps. finally I don't want to sound too motherly but as a general "rule" please first let the list know the plans we all have on what we will do before submitting anything in the CVS (for instance the BCAnnotableSequence.h/m files I noticed). This especially when you would like to see folders added and/or files (simply outline your proposed work in a post), then at least we know not to remove them ;-) Right now my current focus is the BCAnnotation/Feature part, the implementation of them in BCSequence and BCSequenceReader/Writer. ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From jtimmer at bellatlantic.net Wed Feb 23 08:41:08 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 23 Feb 2005 08:41:08 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: Message-ID: Well, the BCSequenceNucleotide may have methods that receive or return symbols. I haven't come across one yet, but if I do, I'd like to just go ahead and add it, rather than stopping and having this debate then ;). JT > > I agree that we probably don't want to parallel the sequence class structure > in the symbol subclasses. But where do we need a BCSymbolNucleotide? > > The phosphorylation et al. idea is a good point and something to keep in mind, > yes! > > charles > _______________________________________________ This mind intentionally left blank From biococoa at bioworxx.com Wed Feb 23 08:57:10 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Wed, 23 Feb 2005 14:57:10 +0100 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: <4337f2d7595b54a80ad35e6df2eb0be0@mekentosj.com> References: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> <39a870ed3d726079f428a987ad19a2b7@mekentosj.com> <6c42bc8f6ff44093036f6855aa94d182@bioworxx.com> <4337f2d7595b54a80ad35e6df2eb0be0@mekentosj.com> Message-ID: <4f30b252e7070ecb0b602346492b7329@bioworxx.com> Ok i see ... I'm a newbee and i don't know everything jet ..... ;-) Let me try to make another suggestion ..... ok ok possibly it was also there before ... but it's worth to risk i think ;-) What about to make several Frameworks from the beginnig like it's organized in the Cocoa Framework. There is the plan for a BCFoundation / BCAppKit framework i noticed. For my HMM plans i think a BCHMM.framework would be nice .... Only because there are so many elementary classes for HMMs, it will be confusing putting them all in the BCFoundation framework what do you think ? Phil Am 23.02.2005 um 14:39 schrieb Alexander Griekspoor: >> you are completely right. It was my fault. I think its nice to have >> some categories in one header file, but not due to performance >> issues.. (you are right). > No problem, indeed it's a good idea to organize the code in categories > inside a single header file, it nicely groups all the related code. > >> I took a look into the BCAbstract Sequence and recognized that the >> Object stores the Sequence in a NSArray of BCSymbols. Thats not >> really good i think. Imagine handling complete genome sequences or >> other stuff. I think we need to store it in a NSString or even simmpe >> char array. There could be of course accessor methods for BCSymbols >> .... but we really need to care about memory and performance issues. >> Especially in the Foundation framework. > Again this discussion also predates your arrival at the framework, > perhaps you can take a look in the archives... > The basic thought here is that we have made the decision very > carefully to go for our own BCSequence and BCSymbol class (although > the design has recently changed quite dramatically with the arrival of > Charles ;-). The reason is pretty simple, although many similarities > an NSString is not the same as a sequence. The characters are > different, many features are different. > Of course we could go for char arrays but that will basically get rid > of all the benefits Cocoa (and object oriented design) has to offer us > from the start (and thus basically kill the reason to build the > framework in the first place). > > By having our own BCSymbol and BCSequence we think we have an oriented > design mimicking NSString (but better) which is way more powerful than > basic c arrays can ever be. Well, I hear you think, "that's nice, but > my computer will never work with a genome of objects (memory and > speedwise)!" That correct, but therefore we are using a simple trick. > All symbols are so-called shared instances, meaning that only a single > instance is allocated and in memory, and all a sequence array consists > of are pointers to this one instance. Yes, this will take up more > memory than a char (around 4 times?) but that's more than worth the > benefits Cocoa will give us. And to relieve you further, yes there are > char and NSString accessors that will give you the desired variable if > you need them. But just to make sure, it's a deliberate choice that > ALL internal representations of sequences should be in the form of our > own BCSequence objects wherever possible. Ideally this includes > alignments. I don't think it's a good thing if a method would consist > of converting a BCSequence to a string, do the manipulation, and > reconvert the string to a BCSequence. All this should be done natively > in the BCSequence format, and if that gives one trouble, we should > rethink/extend the BCSequence class. > > Now, I do realize that with the arrival of more people, it's obvious > that they are gonna ask themselves and the list (no offense, please > do!) the questions that we asked ourselves as well during the initial > design of the setup we now implement. Therefore, I think that once the > basic BCSequence system is up and running (BCSequence et al, > annotations & features, and SeqIO) documentation will become the > number one priority. As I want to do spend a bit more (PR) words on > BioCocoa on our website anyway, to generate more knowledge and > traffic. I'll see if I can combine that with some more explanation of > the basic architecture of the BCSequence setup. Until the 1.0 release > of BioCocoa and if anyone agrees with the idea, it can become the > temporarily (developer) homepage of the new BioCocoa framework, > leaving the current one intact as long as we're still in beta (or > alpha ;-) phase. Peter, any thoughts on this one? > >> Another Question: >> >> What about a BCMutableSequence ... id like to implement one for the >> Alignment classes > At the moment we've decided to go for a class that's mutable from the > beginning, mainly for both performance and technical reasons. Perhaps > Charles and John can talk a bit more about this, and I remember a > discussion about this issue, so there must be a thread in the > archives... It would be nice to have an optimized immutable version in > the future, but again Charles might explain you better why that's not > so easy with the current implementation, he designed the class cluster > approach. > > So all in all, please don't feel offended by the answers, all your > comments are more than welcome and the lack of documentation doesn't > really help starters. Feel free to ask us to explain the rational > behind different design choices, it will help writing the > documentation and FAQs for one! > Cheers, > Alex > > Ps. finally I don't want to sound too motherly but as a general "rule" > please first let the list know the plans we all have on what we will > do before submitting anything in the CVS (for instance the > BCAnnotableSequence.h/m files I noticed). This especially when you > would like to see folders added and/or files (simply outline your > proposed work in a post), then at least we know not to remove them ;-) > Right now my current focus is the BCAnnotation/Feature part, the > implementation of them in BCSequence and BCSequenceReader/Writer. > > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > LabAssistant - Get your life organized! > http://www.mekentosj.com/labassistant > > ********************************************************* > > From mek at mekentosj.com Wed Feb 23 09:49:13 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 15:49:13 +0100 Subject: [BioCocoa-dev] AppKit Message-ID: No clue how, but I clearly made a stupid mistake a while ago, do want the BCAppkit folder renamed to BCAppKit? I guess yes, but does CVS allow that? Anyone? Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From mek at mekentosj.com Wed Feb 23 09:52:13 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 15:52:13 +0100 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: <4f30b252e7070ecb0b602346492b7329@bioworxx.com> References: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> <39a870ed3d726079f428a987ad19a2b7@mekentosj.com> <6c42bc8f6ff44093036f6855aa94d182@bioworxx.com> <4337f2d7595b54a80ad35e6df2eb0be0@mekentosj.com> <4f30b252e7070ecb0b602346492b7329@bioworxx.com> Message-ID: Well, as long as we both in the XCode project and in the file hierarchy add a BCHMM folder, I don't have any objection against many elementary classes in the current framework. I would like to see as little frameworks as possible... Maybe others don't share this opinion though... Look at the BCSequence folder, that starts to expand nicely as well ;-) Cocoa is made up of only two frameworks, NSFoundation and NSAppKit, that's more or less why we kept the separation similar... Cheers, Alex On 23-feb-05, at 14:57, Philipp Seibel wrote: > Ok i see ... > I'm a newbee and i don't know everything jet ..... ;-) > Let me try to make another suggestion ..... ok ok possibly it was also > there before ... but it's worth to risk i think ;-) > > What about to make several Frameworks from the beginnig like it's > organized in the Cocoa Framework. > > There is the plan for a BCFoundation / BCAppKit framework i noticed. > > For my HMM plans i think a BCHMM.framework would be nice .... > Only because there are so many elementary classes for HMMs, it will be > confusing putting them all in the BCFoundation framework > > what do you think ? > > Phil > > Am 23.02.2005 um 14:39 schrieb Alexander Griekspoor: > >>> you are completely right. It was my fault. I think its nice to have >>> some categories in one header file, but not due to performance >>> issues.. (you are right). >> No problem, indeed it's a good idea to organize the code in >> categories inside a single header file, it nicely groups all the >> related code. >> >>> I took a look into the BCAbstract Sequence and recognized that the >>> Object stores the Sequence in a NSArray of BCSymbols. Thats not >>> really good i think. Imagine handling complete genome sequences or >>> other stuff. I think we need to store it in a NSString or even >>> simmpe char array. There could be of course accessor methods for >>> BCSymbols .... but we really need to care about memory and >>> performance issues. Especially in the Foundation framework. >> Again this discussion also predates your arrival at the framework, >> perhaps you can take a look in the archives... >> The basic thought here is that we have made the decision very >> carefully to go for our own BCSequence and BCSymbol class (although >> the design has recently changed quite dramatically with the arrival >> of Charles ;-). The reason is pretty simple, although many >> similarities an NSString is not the same as a sequence. The >> characters are different, many features are different. >> Of course we could go for char arrays but that will basically get rid >> of all the benefits Cocoa (and object oriented design) has to offer >> us from the start (and thus basically kill the reason to build the >> framework in the first place). >> >> By having our own BCSymbol and BCSequence we think we have an >> oriented design mimicking NSString (but better) which is way more >> powerful than basic c arrays can ever be. Well, I hear you think, >> "that's nice, but my computer will never work with a genome of >> objects (memory and speedwise)!" That correct, but therefore we are >> using a simple trick. All symbols are so-called shared instances, >> meaning that only a single instance is allocated and in memory, and >> all a sequence array consists of are pointers to this one instance. >> Yes, this will take up more memory than a char (around 4 times?) but >> that's more than worth the benefits Cocoa will give us. And to >> relieve you further, yes there are char and NSString accessors that >> will give you the desired variable if you need them. But just to make >> sure, it's a deliberate choice that ALL internal representations of >> sequences should be in the form of our own BCSequence objects >> wherever possible. Ideally this includes alignments. I don't think >> it's a good thing if a method would consist of converting a >> BCSequence to a string, do the manipulation, and reconvert the string >> to a BCSequence. All this should be done natively in the BCSequence >> format, and if that gives one trouble, we should rethink/extend the >> BCSequence class. >> >> Now, I do realize that with the arrival of more people, it's obvious >> that they are gonna ask themselves and the list (no offense, please >> do!) the questions that we asked ourselves as well during the initial >> design of the setup we now implement. Therefore, I think that once >> the basic BCSequence system is up and running (BCSequence et al, >> annotations & features, and SeqIO) documentation will become the >> number one priority. As I want to do spend a bit more (PR) words on >> BioCocoa on our website anyway, to generate more knowledge and >> traffic. I'll see if I can combine that with some more explanation of >> the basic architecture of the BCSequence setup. Until the 1.0 release >> of BioCocoa and if anyone agrees with the idea, it can become the >> temporarily (developer) homepage of the new BioCocoa framework, >> leaving the current one intact as long as we're still in beta (or >> alpha ;-) phase. Peter, any thoughts on this one? >> >>> Another Question: >>> >>> What about a BCMutableSequence ... id like to implement one for the >>> Alignment classes >> At the moment we've decided to go for a class that's mutable from the >> beginning, mainly for both performance and technical reasons. Perhaps >> Charles and John can talk a bit more about this, and I remember a >> discussion about this issue, so there must be a thread in the >> archives... It would be nice to have an optimized immutable version >> in the future, but again Charles might explain you better why that's >> not so easy with the current implementation, he designed the class >> cluster approach. >> >> So all in all, please don't feel offended by the answers, all your >> comments are more than welcome and the lack of documentation doesn't >> really help starters. Feel free to ask us to explain the rational >> behind different design choices, it will help writing the >> documentation and FAQs for one! >> Cheers, >> Alex >> >> Ps. finally I don't want to sound too motherly but as a general >> "rule" please first let the list know the plans we all have on what >> we will do before submitting anything in the CVS (for instance the >> BCAnnotableSequence.h/m files I noticed). This especially when you >> would like to see folders added and/or files (simply outline your >> proposed work in a post), then at least we know not to remove them >> ;-) Right now my current focus is the BCAnnotation/Feature part, the >> implementation of them in BCSequence and BCSequenceReader/Writer. >> >> ********************************************************* >> ** Alexander Griekspoor ** >> ********************************************************* >> The Netherlands Cancer Institute >> Department of Tumorbiology (H4) >> Plesmanlaan 121, 1066 CX, Amsterdam >> Tel: + 31 20 - 512 2023 >> Fax: + 31 20 - 512 2029 >> AIM: mekentosj at mac.com >> E-mail: a.griekspoor at nki.nl >> Web: http://www.mekentosj.com >> >> LabAssistant - Get your life organized! >> http://www.mekentosj.com/labassistant >> >> ********************************************************* >> >> > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com 4Peaks - For Peaks, Four Peaks. 2004 Winner of the Apple Design Awards Best Mac OS X Student Product http://www.mekentosj.com/4peaks ********************************************************* From harris at cshl.edu Wed Feb 23 11:32:34 2005 From: harris at cshl.edu (Todd Harris) Date: Wed, 23 Feb 2005 09:32:34 -0700 Subject: [Biococoa-dev] new to the list In-Reply-To: Message-ID: Hi John - Good to be on board! You can check out the GMOD adaptor from CPAN. Bio::GMOD It hasn't propagated to all the mirrors yet. I'm still laying in infrastructure and working on data schema acstraction layer right now. That will go in for release 0.02 :) Todd > On 2/22/05 9:05 PM, John Timmer wrote: > Welcome! > > It looks like we've got a few professionals on board now - it'll be good to > have your perspective, and hope I don't come across as too clueless when you > go through the archive. > > Do you have some links to point us to so that we can check into the database > adapter? I'd be interested in looking it over. > > Cheers, > > John > > >> Hi all - >> >> I've been lurking on the list for a few weeks but have never introduced >> myself properly. >> >> I'm a scientific programmer -- formerly a postdoc -- in Lincoln Stein's lab >> at Cold Spring Harbor Laboratory. I'm a biologist by training although I >> write code full time now. >> >> By way of background, I primarily work in Perl as the central developer of >> WormBase, and on projects like BioPerl and the Generic Model Organism >> Database project. I just today released what I hope will become a unified >> API for biological databases, insulating end users from model changes and >> data mining minutae. I also do basic research in comparative genomics. I'm >> currently working on algorithms for multiple whole genome alignment and >> visualization. >> >> Anyway, I just wanted to delurk and say hello. I'm reading messages now as >> I get up to speed with the status of the project. It's clearly a dynamic >> and dedicated group. I hope to be able to contribute wherever needed. >> >> Todd > > _______________________________________________ > This mind intentionally left blank > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > From mek at mekentosj.com Wed Feb 23 11:35:21 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 17:35:21 +0100 Subject: [Biococoa-dev] new to the list In-Reply-To: References: Message-ID: <8bc436baa74571a91ddd31829a6a2868@mekentosj.com> Hi Todd, welcome to the list! It's great to have someone on board from one of the BioX frameworks. Just a small question related to recent discussions, are you by any chance planning to visit the WWDC? Or would you be interested in going if we hold a BioCocoa gathering there? Looking forward to your contributions, and perhaps you are THE person to join the discussion regarding future CoreData integration... Cheers, Alex On 23-feb-05, at 4:09, Todd Harris wrote: > Hi all - > > I've been lurking on the list for a few weeks but have never introduced > myself properly. > > I'm a scientific programmer -- formerly a postdoc -- in Lincoln > Stein's lab > at Cold Spring Harbor Laboratory. I'm a biologist by training > although I > write code full time now. > > By way of background, I primarily work in Perl as the central > developer of > WormBase, and on projects like BioPerl and the Generic Model Organism > Database project. I just today released what I hope will become a > unified > API for biological databases, insulating end users from model changes > and > data mining minutae. I also do basic research in comparative > genomics. I'm > currently working on algorithms for multiple whole genome alignment and > visualization. > > Anyway, I just wanted to delurk and say hello. I'm reading messages > now as > I get up to speed with the status of the project. It's clearly a > dynamic > and dedicated group. I hope to be able to contribute wherever needed. > > Todd > > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* From mek at mekentosj.com Wed Feb 23 11:43:02 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 23 Feb 2005 17:43:02 +0100 Subject: Archiving annotations (was: [Biococoa-dev] Annotation) In-Reply-To: References: Message-ID: > This scheme to save objects to disk is perfect. I like the additional > BOOL 'shouldArchive'. This should perhaps be integrated with John's proposal on the three archiving options, more on this later... > I actually also liked the additional fiels 'creator' and > 'creationDate' (or something like this?) Yes, I think it would be nice to automatically set the creation / modified date on all annotations, plus the author (which is something the end-developer is responsible for). Also, the same holds true for the sequence object itself, which can be done in two ways. Or upon creation of the sequence object, automatically annotation objects are added (created, modified, author, version (?)). Or we have these general fields as normal properties in the sequence file (using accessors). Whichever you prefer. This can all be added in the annotation category part of the abstractsequence of course. Cheers, Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* From harris at cshl.edu Wed Feb 23 12:33:31 2005 From: harris at cshl.edu (Todd Harris) Date: Wed, 23 Feb 2005 10:33:31 -0700 Subject: [Biococoa-dev] new to the list In-Reply-To: <8bc436baa74571a91ddd31829a6a2868@mekentosj.com> Message-ID: Hi Alex - I'm not planning to attend WWDC yet. I haven't followed the attendence threads - is their a quorum planning to attend? If so, I might be able to extend a trip to Cali the week before to include WWDC. Last year there was some talk about apple supporting an open bio / bioperl meeting but it never materialized, largely due to conflicts with other meetings. It would be good to sit down and hack some things out. Perhaps we should hold a BioCocoa meeting in A'dam? Do you know my friend Ronald Plasterk? He used to be at the NKI, but moved to the Hubrecht in Utrecht. Todd > On 2/23/05 9:35 AM, Alexander Griekspoor wrote: > Hi Todd, welcome to the list! > It's great to have someone on board from one of the BioX frameworks. > Just a small question related to recent discussions, are you by any > chance planning to visit the WWDC? Or would you be interested in going > if we hold a BioCocoa gathering there? > Looking forward to your contributions, and perhaps you are THE person > to join the discussion regarding future CoreData integration... > Cheers, > Alex > > On 23-feb-05, at 4:09, Todd Harris wrote: > >> Hi all - >> >> I've been lurking on the list for a few weeks but have never introduced >> myself properly. >> >> I'm a scientific programmer -- formerly a postdoc -- in Lincoln >> Stein's lab >> at Cold Spring Harbor Laboratory. I'm a biologist by training >> although I >> write code full time now. >> >> By way of background, I primarily work in Perl as the central >> developer of >> WormBase, and on projects like BioPerl and the Generic Model Organism >> Database project. I just today released what I hope will become a >> unified >> API for biological databases, insulating end users from model changes >> and >> data mining minutae. I also do basic research in comparative >> genomics. I'm >> currently working on algorithms for multiple whole genome alignment and >> visualization. >> >> Anyway, I just wanted to delurk and say hello. I'm reading messages >> now as >> I get up to speed with the status of the project. It's clearly a >> dynamic >> and dedicated group. I hope to be able to contribute wherever needed. >> >> Todd >> >> >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> >> > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Microsoft is not the answer, > Microsoft is the question, > NO is the answer > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > From harris at cshl.edu Wed Feb 23 12:41:17 2005 From: harris at cshl.edu (Todd Harris) Date: Wed, 23 Feb 2005 10:41:17 -0700 Subject: [BioCocoa-dev] AppKit In-Reply-To: Message-ID: I do not believe that you can rename or move folders easily in CVS. You can always rename the folder in the repository, and then make sure everyone with checked out sources does the same (including in their CVS Entries file). I cannot guarantee that this will work and it isn't a very clean solution :) If there isn't a huge amount of development history, you might just want to add the renamed directory and delete the old. t. > On 2/23/05 7:49 AM, Alexander Griekspoor wrote: > No clue how, but I clearly made a stupid mistake a while ago, do want > the BCAppkit folder renamed to BCAppKit? I guess yes, but does CVS > allow that? Anyone? > Alex > > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > LabAssistant - Get your life organized! > http://www.mekentosj.com/labassistant > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > From charles.parnot at stanford.edu Wed Feb 23 13:25:24 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 23 Feb 2005 10:25:24 -0800 Subject: [BioCocoa-dev] AppKit In-Reply-To: References: Message-ID: At 10:41 -0700 2/23/05, Todd Harris wrote: >I do not believe that you can rename or move folders easily in CVS. > >You can always rename the folder in the repository, and then make sure >everyone with checked out sources does the same (including in their CVS >Entries file). I cannot guarantee that this will work and it isn't a very >clean solution :) > >If there isn't a huge amount of development history, you might just want to >add the renamed directory and delete the old. > >t. I was about to say the exact same thing :-) With the AppKit folder, the latter is the way to go because it is almost empty. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From biococoa at bioworxx.com Wed Feb 23 14:06:33 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Wed, 23 Feb 2005 20:06:33 +0100 Subject: [Biococoa-dev] Project Structure Message-ID: <593e4c31c4a315fb67ead5e0a012ed59@bioworxx.com> i'm a bit unhappy with the current project structure. I think bioinformatics is a very widespread resarch field and so it's not very good to handle all this within two Framewoks (AppKit and Foundation). Look at Apple: They have more than two Objective-C frameworks: Foundation for the basics ( and only the basics !!!) AppKit for basic ui stuff ( also basic !!! ) and now the special ones AddressBook, PDFKit, WebKit and so on .... but i think everybody knows what i'm talking about ..... so i stop here. What i want to suggest is the following... BCFoundation.framework ( for the base classes) BCStatistics.framework ( HMMs, PCA, CA, and many many more ) ..... as many as you can think ( e.g. ProteinStructure.framework ) BCAppKit.framework ( Basic UI ) and a BioCocoa.framework, which contains the headers of all other frameworks. with this organisation we wouldn't need the folders in the filesystem, just groups and targets. Just think about it .... perhaps i'm looking too far to the future Phil From jtimmer at bellatlantic.net Wed Feb 23 14:50:45 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 23 Feb 2005 14:50:45 -0500 Subject: [Biococoa-dev] Project Structure In-Reply-To: <593e4c31c4a315fb67ead5e0a012ed59@bioworxx.com> Message-ID: I think in general it's a reasonable idea - separating out some of the computation-heavy stuff would make the framework a bit more lightweight for apps that don't need the full suite of tools (say, a plasmid mapping app). The folder structure, however, I think is useful on a practical basis, in that Xcode's CVS support isn't good enough, so we often have to do things by hand. Given that, a more modular directory structure makes the hand-tweaking a bit more manageable. Maybe Xcode 2 will be better in this regard..... JT > i'm a bit unhappy with the current project structure. I think > bioinformatics is a very widespread resarch field and so it's not very > good to handle all this within two Framewoks (AppKit and Foundation). > Look at Apple: > > They have more than two Objective-C frameworks: > > Foundation for the basics ( and only the basics !!!) > AppKit for basic ui stuff ( also basic !!! ) > and now the special ones > AddressBook, PDFKit, WebKit and so on .... > > but i think everybody knows what i'm talking about ..... so i stop here. > > What i want to suggest is the following... > > BCFoundation.framework ( for the base classes) > BCStatistics.framework ( HMMs, PCA, CA, and many many more ) > ..... as many as you can think ( e.g. ProteinStructure.framework ) > BCAppKit.framework ( Basic UI ) > > and a BioCocoa.framework, which contains the headers of all other > frameworks. > > with this organisation we wouldn't need the folders in the filesystem, > just groups and targets. > > Just think about it .... perhaps i'm looking too far to the future > > Phil > > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Wed Feb 23 16:30:59 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 23 Feb 2005 16:30:59 -0500 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: <4337f2d7595b54a80ad35e6df2eb0be0@mekentosj.com> Message-ID: > I took a look into the BCAbstract Sequence and recognized that the > Object stores the Sequence in a NSArray of BCSymbols. Thats not really > good i think. Imagine handling complete genome sequences or other > stuff. I think we need to store it in a NSString or even simmpe char > array. There could be of course accessor methods for BCSymbols .... > but we really need to care about memory and performance issues. > Especially in the Foundation framework. As one of the people that Alex converted to this idea, let me provide a bit more of an explanation here. There's no question that a raw C array of unichar would be faster for some things than our implementation, and more in line with what other frameworks are doing. In order to do anything with that sort of sequence, however, you have to interpret it, which means handing it off to other objects, finding the appropriate information, using lookup tables, etc. A lot of the basic efficiency of the storage will be lost when you actually try to learn something about the sequence. The symbol objects we have provide for a richer experience. Want to complement a nucleotide? Ask it what its complement is. Want to know what nucleotides are represented by "Y"? Just ask it. How much does Threonine wieght? Etc. Basically, they cut down on the intervening objects/methods you need in order to interpret the information in a sequence. They also make methods like reverse-complementation a three line bit of code. Anyway, if you dig through the sequences a bit, you'll also see that we can still get speed boosts by targeting bottlenecks. In some cases, it's much faster to use the underlying CoreFoundation array structures, which are closer in speed to basic C-structs, but provide a lot of the flexibility of Cocoa. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Wed Feb 23 17:19:42 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 23 Feb 2005 17:19:42 -0500 Subject: [Biococoa-dev] Using annotations Message-ID: <039b14f5251110cc607fb2d9d543a2b4@earthlink.net> Alex, I finally had some time to look more closer at your BCAnnotations class. I am not sure how you intend it to be used. Suppose I want to add a BCAnnotation for an organism to the annotations dictionary of BCSequence. My instinct would say to use the key @"organism" and the value @"Homo Sapiens". However, if I look at your code, both strings are supposed to go into a BCAnnotation object: newAnnotation = [[BCAnnotation alloc] initWithName: @"organism" content: @"Homo sapiens"]; Now how do I add it to the dictionary of the sequence? I already used the key (organism) inside BCAnnotation, so should I use it again? If yes, why is the key/name repeated inside the annotation object? This is not a critisicm, because I really like the way it is set up now. I am just trying to understand how it works :-) - Koen. From kvddrift at earthlink.net Wed Feb 23 17:21:34 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 23 Feb 2005 17:21:34 -0500 Subject: [Biococoa-dev] Project Structure In-Reply-To: References: Message-ID: On Feb 23, 2005, at 2:50 PM, John Timmer wrote: > I think in general it's a reasonable idea - separating out some of the > computation-heavy stuff would make the framework a bit more > lightweight for > apps that don't need the full suite of tools (say, a plasmid mapping > app). > I also think it is a good suggestion from Philipp to make smaller and more than one frameworks, even in different projects. Not only makes it the framework less bloated, it also makes code management easier. This is also the way the Omni frameworks are arranged. Initially we used BioJava and BioPerl as an example, and they have indeed (almost) everything inside the same project. cheers, - Koen. From kvddrift at earthlink.net Wed Feb 23 19:16:35 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 23 Feb 2005 19:16:35 -0500 Subject: [BioCocoa-dev] AppKit In-Reply-To: References: Message-ID: <9115b604387992ec0e562fde8d9252fb@earthlink.net> On Feb 23, 2005, at 1:25 PM, Charles PARNOT wrote: > I was about to say the exact same thing :-) > With the AppKit folder, the latter is the way to go because it is > almost empty. > > Just ssh'ed into cvsroot, and made the change. Now everone needs to do a fresh checkout ;-) Maybe this is also the way to clean up the old BioCocoa folder structure? - Koen. From charles.parnot at stanford.edu Thu Feb 24 00:26:31 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 23 Feb 2005 21:26:31 -0800 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: At 8:41 AM -0500 2/23/05, John Timmer wrote: >Well, the BCSequenceNucleotide may have methods that receive or return >symbols. I haven't come across one yet, but if I do, I'd like to just go >ahead and add it, rather than stopping and having this debate then ;). > >JT I think I know where you are going... OK! :-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 00:33:07 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 23 Feb 2005 21:33:07 -0800 Subject: [BioCocoa-dev] AppKit In-Reply-To: <9115b604387992ec0e562fde8d9252fb@earthlink.net> References: <9115b604387992ec0e562fde8d9252fb@earthlink.net> Message-ID: At 7:16 PM -0500 2/23/05, Koen van der Drift wrote: >On Feb 23, 2005, at 1:25 PM, Charles PARNOT wrote: > >>I was about to say the exact same thing :-) >>With the AppKit folder, the latter is the way to go because it is almost empty. >> > >Just ssh'ed into cvsroot, and made the change. Now everone needs to do a fresh checkout ;-) > >Maybe this is also the way to clean up the old BioCocoa folder structure? > >- Koen. When I said 'the latter', that was removing the old folder and adding the new one, and not the hack directly in the repository! But that's OK... In general, it seems it is not a good idea to play with the repository itself, in particular because it forces everyone to do a checkout, and because it might corrupt the repository if an error is made... We should do it only for emergencies, like what happened to you the other day ;-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 00:35:39 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 23 Feb 2005 21:35:39 -0800 Subject: Archiving annotations (was: [Biococoa-dev] Annotation) Message-ID: At 8:39 AM -0500 2/23/05, John Timmer wrote: >I had a thought on handling the attributes last night. One of the >dangers of allowing everything into an attribute is that cruft can >build up and the file size balloon, especially if a single sequence >is shuffled between applications. It would be nice to have a >formalized way of ensuring that a minimal, informative sequence >object can be created. So, I suggest that we code for three levels >of information: > >Base level: minimum necessary to hold an attribute: name, type, >range, notes. Everything else is removed. Guaranteed to work in >any BC-based app. >App level: All objects are tested to determine whether the current >application has the class to work with is kept; everything else is >removed. >Verbose level: everything's there, whether it can be used or not. > >This way, information that's been copied, dragged and dropped, etc. >can easily be streamlined in a way that's more appropriate for the >receiving app. > >JT >At 5:43 PM +0100 2/23/05, Alexander Griekspoor wrote: >>This scheme to save objects to disk is perfect. I like the >>additional BOOL 'shouldArchive'. >This should perhaps be integrated with John's proposal on the three >archiving options, more on this later... John's idea is indeed excellent! One thing to keep in mind is if a file is used in 2 different apps, back and forth, then the user would probably not want to lose everything every time she switches from one app to the other and save. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.parnot at stanford.edu Thu Feb 24 00:56:19 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 23 Feb 2005 21:56:19 -0800 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> References: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> Message-ID: Being in California, I am the last one to write and it's not fair, everybody else already said what I wanted to say!! But that's OK, the weather is good... I still want to add my 2 cents: * Categories: creating more categories won't reduce the 'size' of the BCSequence class at runtime, and this 'size' is not really relevant in terms of memory or performance, so I think we should not be afraid of a big big class with lots lots of methods... The analogy with NSString is perfect: does anybody complain about NSString being bloated? * Categories files: yes there should be only one header, because potentially the user of the framework will want to import the header for the class, and it is just easier to have everything in one file then; however, having several implementation files is OK, and is even better IMO; easier to navigate * NSArray of BCSymbols vs arrays of chars: I am on John and Alex's side; the object might be bigger, but not much much bigger; performance may be an issue at some point but it is difficult to really predict what is going to happen until you face the issue; in which case translating back and forth to a different structure might make sense if the performance is an issue (in that I don't completely agree with Alex) * Performance again: I don't know how many of you have used Shark, but with such a tool, we should be able to improve performance dramatically when the framework is more mature and is facing the real world; Shark is a great great application that get right to the performance bottlenecks... and they might be anywhere, and not necessarily where you would predict: http://www.cocoadev.com/index.pl?OptimizeLater * frameworks: it is indeed a good idea; with multiple targets, it also makes recompiling less frequent, e.g. if a file modified by somebody else is in another framework; charles At 10:08 AM +0100 2/23/05, Philipp Seibel wrote: >Morning everyone, > >i think we should be careful by adding more and more features to the BCSequence. We have to keep in mind that for many sequence related algorithms it is better to have a sleek Object. We shouldn't design a full featured object as base class. I think categories is the best solution to add features like Annotations and Features to the Sequence object. > >cheers > >Phil At 11:41 AM +0100 2/23/05, Alexander Griekspoor wrote: >We previously had this discussion as well so I guess it's a relevant one. In principle I don't have a problem with categories (anymore ;-) to add these features and keep the base class lean and small. I would strongly argue to keep them in the same .h/.m file though (like apple seems to do). The real question then of course is, how do I get a slimmed down sequence objects without the added categories? Is that possible at all? And perhaps the real real question is, does that really matter? Does your code becomes slower when you add methods and arguments but don't use them? I can hardly imagine that a pointer to a dictionary (even kept nil if you don't add annotations) make a lot of difference in the end. With symbols I can imagine, but with sequences? At 2:39 PM +0100 2/23/05, Alexander Griekspoor wrote: >Now, I do realize that with the arrival of more people, it's obvious that they are gonna ask themselves and the list (no offense, please do!) the questions that we asked ourselves as well during the initial design of the setup we now implement. Therefore, I think that once the basic BCSequence system is up and running (BCSequence et al, annotations & features, and SeqIO) documentation will become the number one priority. As I want to do spend a bit more (PR) words on BioCocoa on our website anyway, to generate more knowledge and traffic. I'll see if I can combine that with some more explanation of the basic architecture of the BCSequence setup. Until the 1.0 release of BioCocoa and if anyone agrees with the idea, it can become the temporarily (developer) homepage of the new BioCocoa framework, leaving the current one intact as long as we're still in beta (or alpha ;-) phase. Peter, any thoughts on this one? -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 01:05:07 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 23 Feb 2005 22:05:07 -0800 Subject: [Biococoa-dev] Developer documentation Message-ID: At 2:39 PM +0100 2/23/05, Alexander Griekspoor wrote: >Now, I do realize that with the arrival of more people, it's obvious that they are gonna ask themselves and the list (no offense, please do!) the questions that we asked ourselves as well during the initial design of the setup we now implement. Therefore, I think that once the basic BCSequence system is up and running (BCSequence et al, annotations & features, and SeqIO) documentation will become the number one priority. As I want to do spend a bit more (PR) words on BioCocoa on our website anyway, to generate more knowledge and traffic. I'll see if I can combine that with some more explanation of the basic architecture of the BCSequence setup. Until the 1.0 release of BioCocoa and if anyone agrees with the idea, it can become the temporarily (developer) homepage of the new BioCocoa framework, leaving the current one intact as long as we're still in beta (or alpha ;-) phase. Peter, any thoughts on this one? Yes, this is why I started the dev-docs folder on the project. Having it in the project makes it easier for everybody to edit, like a wiki in a way, so everybody can contribute and help too. To duplicate this in a web site is nice, but it might be hard for you to keep it in sync? Maybe if you suggested a simple layout that would make the conversion easier? e.g. I sticked to some

and

tags in what I started (I did not like the default format for

, too big!). I know by experience from working with you that the web page will look fantastic no matter what, so I do think it is a good idea... i just want to make sure you don't spend too much time on it and that everyone can help. And also let's remember: most of the 'developer doc' should be in the implementation files themselves, in the good old /*comments*/ which are sooo important to edit and debug somebody else's code. Again, just my 2 cents :-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 01:17:06 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Wed, 23 Feb 2005 22:17:06 -0800 Subject: [Biococoa-dev] Comments on BCAnnotation Message-ID: After going through your code, Alex, here are my comments: * we should make BCAnnotation and BCFeature immutable and thus not have any setter; for instance, the annotations would otherwise have to be physically copied every time a piece of sequence is copied and pasted or used for alignement, etc... * I don't like the comparison methods names; why not stick to the Cocoa way, which is simply 'compare:' using 'compareName:' and 'compareContents:'. And I am not sure why you would need a ascending and descending method when one can use reverseEnumerator? * In the comparison: more generally, if the Contents are of the same class and both respond to 'compare:', then this is what is used * the data type should be an ivar, if you want to preserve annotations coming from another app; in which case the contents is NSData; more precisely, when unarchiving, if the class is known, the contents is unarchived; otherwise, the ivar 'contentsClass' stores the class name and the ivar 'contents' stores the unarchived data; otherwise, it looks very clean and a good start! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From biococoa at bioworxx.com Thu Feb 24 02:47:01 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Thu, 24 Feb 2005 08:47:01 +0100 Subject: [Biococoa-dev] Comments on BCAnnotation In-Reply-To: References: Message-ID: <0d23e9fa4bb6205791d3d8eeed544eea@bioworxx.com> Hi, Am 24.02.2005 um 07:17 schrieb Charles PARNOT: > After going through your code, Alex, here are my comments: > > * we should make BCAnnotation and BCFeature immutable and thus not > have any setter; for instance, the annotations would otherwise have to > be physically copied every time a piece of sequence is copied and > pasted or used for alignement, etc... you are definitly right. There is perhaps one problem, but perhaps it isn't a real problem ;-)... what happens with the BCFeature positions if i insert gaps into the sequence. If the positions have no set method everybody has to know that this positions are the ones without gaps. I'm also not sure wether we need a special BCSequence class for alignment or not. Perhaps we need only a BCMutableSequence with the corresponding BCSymbolSet including a gap-symbol. This is open for discussion .... > * I don't like the comparison methods names; why not stick to the > Cocoa way, which is simply 'compare:' using 'compareName:' and > 'compareContents:'. And I am not sure why you would need a ascending > and descending method when one can use reverseEnumerator? This is what i think, too. > * In the comparison: more generally, if the Contents are of the same > class and both respond to 'compare:', then this is what is used > > * the data type should be an ivar, if you want to preserve annotations > coming from another app; in which case the contents is NSData; more > precisely, when unarchiving, if the class is known, the contents is > unarchived; otherwise, the ivar 'contentsClass' stores the class name > and the ivar 'contents' stores the unarchived data; > I committed a very very simple start for the BCAlignment class, please take a look and tell me what you think we need. Next point are scoring matrices. I would suggest a handling similar to your handling with the genetic code stuff. We store the PAM etc in plists, but i think we need to be carfeul with storing the matrix in the object. perhaps a int** is the best. Anyone a good idea ? ok thats for now Phil From mek at mekentosj.com Thu Feb 24 04:22:35 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 10:22:35 +0100 Subject: [BioCocoa-dev] AppKit In-Reply-To: References: <9115b604387992ec0e562fde8d9252fb@earthlink.net> Message-ID: <28ad7187e0142b8b28ddb3b2bd619805@mekentosj.com> True, Charles is right here, but I would propose to grant Koen one more time access to "the matrix" and remove those pesky (BCUtil ?) folders in the root folder that require us to do the pruning during checkout, those are remnants from a time long gone ;-) Cheers, Alex On 24-feb-05, at 6:33, Charles PARNOT wrote: > At 7:16 PM -0500 2/23/05, Koen van der Drift wrote: >> On Feb 23, 2005, at 1:25 PM, Charles PARNOT wrote: >> >>> I was about to say the exact same thing :-) >>> With the AppKit folder, the latter is the way to go because it is >>> almost empty. >>> >> >> Just ssh'ed into cvsroot, and made the change. Now everone needs to >> do a fresh checkout ;-) >> >> Maybe this is also the way to clean up the old BioCocoa folder >> structure? >> >> - Koen. > > When I said 'the latter', that was removing the old folder and adding > the new one, and not the hack directly in the repository! But that's > OK... In general, it seems it is not a good idea to play with the > repository itself, in particular because it forces everyone to do a > checkout, and because it might corrupt the repository if an error is > made... We should do it only for emergencies, like what happened to > you the other day ;-) > > charles > > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From mek at mekentosj.com Thu Feb 24 04:32:34 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 10:32:34 +0100 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: References: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> Message-ID: On 24-feb-05, at 6:56, Charles PARNOT wrote: > * NSArray of BCSymbols vs arrays of chars: I am on John and Alex's > side; the object might be bigger, but not much much bigger; > performance may be an issue at some point but it is difficult to > really predict what is going to happen until you face the issue; in > which case translating back and forth to a different structure might > make sense if the performance is an issue (in that I don't completely > agree with Alex) I was talking here specifically about the conversion to NSString and back. I guess, most of us have previously used NSString for their sequence related methods like reverse complement for example. So the easiest way to implement your old work would be BCSequence -> NSString -> your old code -> NSString -> BCSequence. The whole argument I wanted to make is that in my opinion NSString does/should not have an advantage over our BCSequence, in contrast it should perform worse because of the benefits we described previously (if that isn't the case then we should make it that way, a primary condition). Both are cocoa objects. So the point I wanted to make is that if we implement old-code based on NSString, we should convert it to work natively with BCSequence objects (otherwise you'll get the same situation John just described about the overhead if you work natively with char arrays). BUT having said that, if a critical bottleneck can be resolved by using more primitive C type structures like char arrays or the Core Foundation classes, yes then it might make sense to do a conversion. Absolutely. Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From mek at mekentosj.com Thu Feb 24 04:37:18 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 10:37:18 +0100 Subject: [Biococoa-dev] Developer documentation In-Reply-To: References: Message-ID: <60be4d35dde205444660baf7aa4c3604@mekentosj.com> > Yes, this is why I started the dev-docs folder on the project. Having > it in the project makes it easier for everybody to edit, like a wiki > in a way, so everybody can contribute and help too. To duplicate this > in a web site is nice, but it might be hard for you to keep it in > sync? Maybe if you suggested a simple layout that would make the > conversion easier? e.g. I sticked to some

and

tags in what I > started (I did not like the default format for

, too big!). Heard of CSS ? ;-) If we stick to some tags perhaps similar to the headerdoc tags, we don't have to go spread all these

etc throughout the code. I'll give a look at it and come up with a proposal. Editing the docs in the project is brilliant, indeed wiki like.... What I was pointing add, was a more tutorial based outline of the architecture. Just a simple two page overview or something, but perhaps that too screams for an example.. > > I know by experience from working with you that the web page will look > fantastic no matter what, so I do think it is a good idea... i just > want to make sure you don't spend too much time on it and that > everyone can help. And also let's remember: most of the 'developer > doc' should be in the implementation files themselves, in the good old > /*comments*/ which are sooo important to edit and debug somebody > else's code. Yep, you're fully right. The prime concern is documented code, properly headerdoc-ed... Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* From mek at mekentosj.com Thu Feb 24 04:51:24 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 10:51:24 +0100 Subject: [Biococoa-dev] Re: Using annotations In-Reply-To: <039b14f5251110cc607fb2d9d543a2b4@earthlink.net> References: <039b14f5251110cc607fb2d9d543a2b4@earthlink.net> Message-ID: > Suppose I want to add a BCAnnotation for an organism to the > annotations dictionary of BCSequence. My instinct would say to use the > key @"organism" and the value @"Homo Sapiens". However, if I look at > your code, both strings are supposed to go into a BCAnnotation object: > > newAnnotation = [[BCAnnotation alloc] initWithName: @"organism" > content: @"Homo sapiens"]; The idea was to store the annotation object in a mutable dictionary with the name as key. Yes, this duplicates the name string, but it has several big advantages to store the name in the object itself. For instance sorting. An object can't ask it's enclosing dictionary for the key under which it is stored. Also if you pass annotation objects around, you always know its name. Well, why don't we just store it in a mutable array then? That's a possibility, but say I want the object with name "organism" then in an array we would have to enumerate it, while in a dictionary you can simply ask it. NSDictionary is highly optimized for this, so at the cost of the duplicated string I take the far higher optimization in return. I took the same approach for the enzyme example, and I simply love it. Now of course that doesn't say much if it is the best way to do things... ;-) > > Now how do I add it to the dictionary of the sequence? I already used > the key (organism) inside BCAnnotation, so should I use it again? If > yes, why is the key/name repeated inside the annotation object? This > is not a critisicm, because I really like the way it is set up now. I > am just trying to understand how it works :-) No problem, and I can see why it sounds strange at first so criticism is at place here, hope it has become more clear now why I choose for this approach. About how to add an annotation? I still have to add that code to the sequence class ;-) Something else, as I proposed to make BCFeature a subclass of BCAnnotation, do we want a single mutable dictionary annotations in the sequence class containing both, or one annotations and one features dict? I think the first or not? Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From mek at mekentosj.com Thu Feb 24 05:02:12 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 11:02:12 +0100 Subject: [Biococoa-dev] Comments on BCAnnotation In-Reply-To: References: Message-ID: <54a29a2827612bcb0179e59846d495ce@mekentosj.com> On 24-feb-05, at 7:17, Charles PARNOT wrote: > After going through your code, Alex, here are my comments: > > * we should make BCAnnotation and BCFeature immutable and thus not > have any setter; for instance, the annotations would otherwise have to > be physically copied every time a piece of sequence is copied and > pasted or used for alignement, etc... Yep, I'll change that and make the setters private. > > * I don't like the comparison methods names; why not stick to the > Cocoa way, which is simply 'compare:' using 'compareName:' and > 'compareContents:'. And I am not sure why you would need a ascending > and descending method when one can use reverseEnumerator? Somehow this is the way I always used to implement rapid sorting for tableviews. Say you have a mutablearray of BCAnnotations displayed in a tableview, you can quickly sort them in ascending or descending order with this method. Haven't used bindings enough to see if that has become obsolete now. Yes, I can change the methods to compareName: and compareContents: no problem. > * In the comparison: more generally, if the Contents are of the same > class and both respond to 'compare:', then this is what is used What do you try to say? I don't get the point.. > * the data type should be an ivar, if you want to preserve annotations > coming from another app; in which case the contents is NSData; more > precisely, when unarchiving, if the class is known, the contents is > unarchived; otherwise, the ivar 'contentsClass' stores the class name > and the ivar 'contents' stores the unarchived data; Again, I'm not really what you would like to see. My proposal was to keep the datatype as it is, an NSString. And add a dataclass getter which does what phil wants to see (return a class instead of a string). Is this what you mean? > otherwise, it looks very clean and a good start! Thanks! Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com 4Peaks - For Peaks, Four Peaks. 2004 Winner of the Apple Design Awards Best Mac OS X Student Product http://www.mekentosj.com/4peaks ********************************************************* From mek at mekentosj.com Thu Feb 24 05:17:11 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 11:17:11 +0100 Subject: [Biococoa-dev] Comments on BCAnnotation In-Reply-To: <0d23e9fa4bb6205791d3d8eeed544eea@bioworxx.com> References: <0d23e9fa4bb6205791d3d8eeed544eea@bioworxx.com> Message-ID: <5e11d5508de5c8738339706794b0a62f@mekentosj.com> >> After going through your code, Alex, here are my comments: >> >> * we should make BCAnnotation and BCFeature immutable and thus not >> have any setter; for instance, the annotations would otherwise have >> to be physically copied every time a piece of sequence is copied and >> pasted or used for alignement, etc... > you are definitly right. There is perhaps one problem, but perhaps it > isn't a real problem ;-)... what happens with the BCFeature positions > if i insert gaps into the sequence. If the positions have no set > method everybody has to know that this positions are the ones without > gaps. > I'm also not sure wether we need a special BCSequence class for > alignment or not. Perhaps we need only a BCMutableSequence with the > corresponding BCSymbolSet including a gap-symbol. This is open for > discussion .... Annotations can be immutable as they are position independent indeed, but per definition the range of a BCFeature of a mutable sequence (which ours is at the moment) should be mutable as well. Good thought Phil... > I committed a very very simple start for the BCAlignment class, please > take a look and tell me what you think we need. > Next point are scoring matrices. I would suggest a handling similar to > your handling with the genetic code stuff. We store the PAM etc in > plists, but i think we need to be carfeul with storing the matrix in > the object. perhaps a int** is the best. Anyone a good idea ? Again, that comes down to performance vs elegance I guess. A matrix object is very nice as it offers a so much richer experience. It depends how often the matrix is accessed. Instantiating a matrix from a plist is a really nice idea, which brings me to a few options that might be something you like: - We could implement a matrix object that can instantiate itself from a plist (class method) and has all the nice cocoa things you can think of (for instance asking it the cocoa way for a substitution score, a name accessor for use in popupbuttons etc). Now for alignments you can have an accessor which simply returns a classic C matrix representation that you can use in your alignment methods. Best of both worlds. - Alternatively, we can a sort of matrix factory which does the plist conversion into a c type matrix. You can guess which one I like most ;-) Cheers, Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From mek at mekentosj.com Thu Feb 24 05:19:54 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 11:19:54 +0100 Subject: Annotation sets (was: [Biococoa-dev] Annotation) In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> <0f45f8c7c22c6add17a77d3e133621f7@mekentosj.com> <52dc349075d3e35e2f34639d7af3c8cb@mekentosj.com> Message-ID: <76ddf581283db00ba469206d662e4a6e@mekentosj.com> > But you are right. Let's just see first where that gets us with the > sequences, and then we can add another layer. It seems funny to have a > set a subclass of the items, but I understand the logic, and I kind of > like it the way you present it! Yeah, found that funny as well, a collection class that is the subclass of its content...... ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* From a.griekspoor at nki.nl Thu Feb 24 05:21:41 2005 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Thu, 24 Feb 2005 11:21:41 +0100 Subject: [Biococoa-dev] BCSequence implementation In-Reply-To: References: <0163abbf5f5b3a4cb0ec43fc77e290a1@bioworxx.com> Message-ID: <1ecb8279b4d9a327b0b571a20f17c6b7@nki.nl> > Being in California, I am the last one to write and it's not fair, > everybody else already said what I wanted to say!! But that's OK, the > weather is good... You should turn the tides in your favor and start the discussion, then you're always the first ;-) It's great to see the work continue round the clock, or should I say round the world... ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* From mek at mekentosj.com Thu Feb 24 05:44:53 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 11:44:53 +0100 Subject: 0 or 1 based ranges ? (was: [Biococoa-dev] Annotation) In-Reply-To: References: <17bd8f21422204542205b787c80aee3f@mekentosj.com> <0c71dbdec4f3a2d507b69852a2d6a092@earthlink.net> <5e3df3b78053dfd966f81ad9d51d8202@nki.nl> <5c91cf97d9deceec167709a3e16a2db5@mekentosj.com> <62fea2117c4ca7b39a860a6d77cad964@earthlink.net> Message-ID: <6faabe37db7139074df424a827c30481@mekentosj.com> > Maybe we should have some methods that explicitely give the choice to > the user of the framework? The convention for ranges is so well > established that it is going to be confusing for us and for some > users. So we could have methods like 'subsequenceWithRange:' and > 'subsequenceWithSequenceRange:'.... the naming is not very good, uh? > > Actually, maybe we could create a new struct to handle 1-based ranges, > something like BCSequenceRange?? I like that idea, just a BCRange (1-based).... Can simply be added to BCFoundationDefines.h We might have to implement a few of the NSRange utitilities as well though.... Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* From mek at mekentosj.com Thu Feb 24 05:56:32 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 11:56:32 +0100 Subject: [Biococoa-dev] Project Structure In-Reply-To: <593e4c31c4a315fb67ead5e0a012ed59@bioworxx.com> References: <593e4c31c4a315fb67ead5e0a012ed59@bioworxx.com> Message-ID: Phil, Never looked at it in such a way, but you're right and most people like the idea as well. > What i want to suggest is the following... > > BCFoundation.framework ( for the base classes) > BCStatistics.framework ( HMMs, PCA, CA, and many many more ) > ..... as many as you can think ( e.g. ProteinStructure.framework ) > BCAppKit.framework ( Basic UI ) > > and a BioCocoa.framework, which contains the headers of all other > frameworks. Excellent, this way people can choose how much they integrate. It doesn't change much to the situation thus far, the foundation is still the thing to concentrate on for most of us, but I understand that you'll probably start with the BCStatistics framework then in the near future (I don't know what PCA and CA are standing for anyway ;-). The question is will we stick with one XCode project with a separate target for each (sub)framework? I'm in favor of that as long as it doesn't grow too much (which probably will not be the case for some time..). > > with this organisation we wouldn't need the folders in the filesystem, > just groups and targets. Please, like John said, let's mirror the group, target hierarchy also in the filesystem as much as possible!!! If we add a BCStatistics framework, then we should also add a BCStatistics folder in the root of the project directory just like we did with BCAppKit and BCFoundation. Let's try to stick to the same model as for these two... Finally, this answers Charles remark as well: > From last week, it seemed most people liked the idea, but I thought > I'd ask again now that we have more people before adding yet another > folder and a new target and 10 more files... Guess, it's no problem to add another target and folder;-) > Just think about it .... perhaps i'm looking too far to the future You're looking quite far indeed, but there's nothing against that! I call it dedication ;-) Cheers, Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* From mek at mekentosj.com Thu Feb 24 05:57:26 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 11:57:26 +0100 Subject: [Biococoa-dev] Project Structure In-Reply-To: References: Message-ID: <625960dcc8b1d9daa765a6b227cff286@mekentosj.com> > I also think it is a good suggestion from Philipp to make smaller and > more than one frameworks, even in different projects. Not only makes > it the framework less bloated, it also makes code management easier. > This is also the way the Omni frameworks are arranged. Initially we > used BioJava and BioPerl as an example, and they have indeed (almost) > everything inside the same project. And I have to admit that indeed these seem really bloated.... Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From mek at mekentosj.com Thu Feb 24 06:09:38 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 12:09:38 +0100 Subject: Archiving annotations (was: [Biococoa-dev] Annotation) In-Reply-To: References: Message-ID: <32d498b46a9eb20bf3fbb700c3688270@mekentosj.com> I see where you're head at, but I don't see exactly HOW you would like to see this implement. Do you mean that each annotation instead of a simple shouldArchive boolean should have a variable which you can set to one of the three levels you describe? Could you describe a bit more in detail how to implement this all? If I understand you right, you want this system be functional in the read/write classes or not? So one can define what he wants to save/load to/from a file? Or/And do you want to have these options in the sequence creation methods? How do we check what the app supports? Delegates? It's rather vague to me although I agree that we need to have a system to discriminate between different levels of annotation datatype support. Alex On 24-feb-05, at 6:35, Charles PARNOT wrote: > At 8:39 AM -0500 2/23/05, John Timmer wrote: > I had a thought on handling the attributes last night. ?One of the > dangers of allowing everything into an attribute is that cruft can > build up and the file size balloon, especially if a single sequence is > shuffled between applications. ?It would be nice to have a formalized > way of ensuring that a minimal, informative sequence object can be > created. ?So, I suggest that we code for three levels of information: > > Base level: ?minimum necessary to hold an attribute: ?name, type, > range, notes. ?Everything else is removed. ?Guaranteed to work in any > BC-based app. > App level: All objects are tested to determine whether the current > application has the class to work with is kept; everything else is > removed. > Verbose level: ?everything's there, whether it can be used or not. > > This way, information that's been copied, dragged and dropped, etc. > can easily be streamlined in a way that's more appropriate for the > receiving app. > > JT > > > At 5:43 PM +0100 2/23/05, Alexander Griekspoor wrote: > This scheme to save objects to disk is perfect. I like the additional > BOOL 'shouldArchive'. > This should perhaps be integrated with John's proposal on the three > archiving options, more on this later... > > John's idea is indeed excellent! > One thing to keep in mind is if a file is used in 2 different apps, > back and forth, then the user would probably not want to lose > everything every time she switches from one app to the other and save. > > charles > > -- > > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room? B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3752 bytes Desc: not available URL: From mek at mekentosj.com Thu Feb 24 06:17:14 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 12:17:14 +0100 Subject: [Biococoa-dev] new to the list In-Reply-To: References: Message-ID: <9470b2334b597109dee45cdab42ed808@mekentosj.com> Hi Todd, > I'm not planning to attend WWDC yet. I haven't followed the attendence > threads - is their a quorum planning to attend? If so, I might be > able to > extend a trip to Cali the week before to include WWDC. Here's a copy of the mail I send about the WWDC. Most of us are willing to go (if for some a ticket can be arranged). Peter and I have agreed to contact Apple and see what can be arranged... > Hi guys, > > Yesterday the date of WWDC2005 was announced (6-10 june) and Tom and I > will definitely go again (very addictive). Although I haven't > contributed much in the past month because of you know why, I have > been walking around with this idea that I would like to get your > opinion on. Wouldn't it be great if we could organize a get together > at the WWDC, meet each other in real, learn all about the new stuff in > tiger (i.e. what opportunities will Core Data give us in combination > with BioCocoa), and discuss/work together on the framework. I think it > would be a perfect opportunity to both boost the development progress > and set out the future directions/trajectory we have in mind. > > Now my gut feeling says that: > - Me and Tom will go for sure (that wasn't to difficult to feel) and > will apply for a scholarship for admission and travel sponsorship from > the institute > - Peter can go for the scholarship as well, but perhaps joins the > Belgian Apple group again ? > - Charles are you going because of the xgrid stuff again? Do you have > an invitation? > - Jim was there last time, are you going again? > - And then there are Koen and John, did you guys have any plans in > going already? > > So the question is, does any of you already know for sure they're > going and who would be interested in going and join in a BioCocoa > meeting? Who would be interested but has (financial) considerations > that will make it unlikely to come? > > The reason for asking is that if we all like the idea, I'm want to try > to convince the people at Apple I met last year to perhaps > sponsor/co-organize this event. Therefore I would like to know who > would like to come but needs to pay the 1600$ admission fee if he does > so. I would like to see if its possible that Apple would sponsor those > a free ticket to the WWDC. > The second thing would be to ask if they're interested in having one > of the lunch meetings being centered around BioCocoa. Last year there > were quite some bio people there (including a guy from BioPerl), it > would be nice to give a little presentation on the framework and > discuss the plans and as such both attract new developers perhaps and > warm up apple to support our initiative if they like it. Also, Apple > is an official sponsor of the Open Bioinformatics Foundation (the > mother organisation of BioJava, BioPerl etc), so I guess they are > interested in a BioCocoa sibling. > > For those planning to visit WWDC already, I'm looking forward to meet > you all! For those that didn't until now, let me know if you're > interested and can free the week from the 6-10th of june. It would be > great to have our first official BioCocoa meeting! > Let me know what you think, > Cheers, > Alex > > Links: > http://developer.apple.com/wwdc/ > http://www.mekentosj.com/events/wwdc04/ > Last year there was some talk about apple supporting an open bio / > bioperl > meeting but it never materialized, largely due to conflicts with other > meetings. Last year there indeed was a science lunch session with a guy from bioperl, forgot his name though, and the subject wasn't centered around bioperl indeed... > > It would be good to sit down and hack some things out. Exactly the plan! > > Perhaps we should hold a BioCocoa meeting in A'dam? The european party can do that indeed ;-) I can certainly arrange something if we want. Peter, Phil, I and you (?) are situated quite nearby, would be fun! > Do you know my friend Ronald Plasterk? He used to be at the NKI, but > moved to the Hubrecht in Utrecht. Yes, i know him, he's quite "famous" here in The Netherlands, both to scientists (he's indeed the director of the Hubrecht) and to the general public (he's deeply involved in politics and writing for a national newspaper)... Cheers, Alex >> On 2/23/05 9:35 AM, Alexander Griekspoor wrote: > >> Hi Todd, welcome to the list! >> It's great to have someone on board from one of the BioX frameworks. >> Just a small question related to recent discussions, are you by any >> chance planning to visit the WWDC? Or would you be interested in going >> if we hold a BioCocoa gathering there? >> Looking forward to your contributions, and perhaps you are THE person >> to join the discussion regarding future CoreData integration... >> Cheers, >> Alex >> >> On 23-feb-05, at 4:09, Todd Harris wrote: >> >>> Hi all - >>> >>> I've been lurking on the list for a few weeks but have never >>> introduced >>> myself properly. >>> >>> I'm a scientific programmer -- formerly a postdoc -- in Lincoln >>> Stein's lab >>> at Cold Spring Harbor Laboratory. I'm a biologist by training >>> although I >>> write code full time now. >>> >>> By way of background, I primarily work in Perl as the central >>> developer of >>> WormBase, and on projects like BioPerl and the Generic Model Organism >>> Database project. I just today released what I hope will become a >>> unified >>> API for biological databases, insulating end users from model changes >>> and >>> data mining minutae. I also do basic research in comparative >>> genomics. I'm >>> currently working on algorithms for multiple whole genome alignment >>> and >>> visualization. >>> >>> Anyway, I just wanted to delurk and say hello. I'm reading messages >>> now as >>> I get up to speed with the status of the project. It's clearly a >>> dynamic >>> and dedicated group. I hope to be able to contribute wherever >>> needed. >>> >>> Todd >>> >>> >>> >>> _______________________________________________ >>> Biococoa-dev mailing list >>> Biococoa-dev at bioinformatics.org >>> https://bioinformatics.org/mailman/listinfo/biococoa-dev >>> >>> >> ********************************************************* >> ** Alexander Griekspoor ** >> ********************************************************* >> The Netherlands Cancer Institute >> Department of Tumorbiology (H4) >> Plesmanlaan 121, 1066 CX, Amsterdam >> Tel: + 31 20 - 512 2023 >> Fax: + 31 20 - 512 2029 >> AIM: mekentosj at mac.com >> E-mail: a.griekspoor at nki.nl >> Web: http://www.mekentosj.com >> >> Microsoft is not the answer, >> Microsoft is the question, >> NO is the answer >> >> ********************************************************* >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> > > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From kvddrift at earthlink.net Thu Feb 24 06:52:32 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 06:52:32 -0500 Subject: [Biococoa-dev] Re: Using annotations In-Reply-To: References: <039b14f5251110cc607fb2d9d543a2b4@earthlink.net> Message-ID: <8f2035bca1f374a1e0cb59d92b9bc8a1@earthlink.net> On Feb 24, 2005, at 4:51 AM, Alexander Griekspoor wrote: >> Now how do I add it to the dictionary of the sequence? I already used >> the key (organism) inside BCAnnotation, so should I use it again? If >> yes, why is the key/name repeated inside the annotation object? This >> is not a critisicm, because I really like the way it is set up now. I >> am just trying to understand how it works :-) > No problem, and I can see why it sounds strange at first so criticism > is at place here, hope it has become more clear now why I choose for > this approach. About how to add an annotation? I still have to add > that code to the sequence class ;-) Thanks for the explanation. I understnad now your plan, and it looks good to me. And most of the code in the sequence class is already in place (in BCAbstractSequence), so you just have to change it to make it work with BCAnnotaion. > Something else, as I proposed to make BCFeature a subclass of > BCAnnotation, do we want a single mutable dictionary annotations in > the sequence class containing both, or one annotations and one > features dict? I think the first or not? > I would make two separate dictionaries. Maybe sometimes people are only interested in features, and maybe sometimes only in annotations. With 2 dictionaries that would make it easier to find. Or if you want to sort the features from symbol 1234 to 2345, it's easier I think if you dont't have to differentiate between features and annotations. Now, one question, in another mail the word 'attributes' was used. Is this yet something else than annotations and features? - Koen. From kvddrift at earthlink.net Thu Feb 24 06:56:25 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 06:56:25 -0500 Subject: [BioCocoa-dev] AppKit In-Reply-To: <28ad7187e0142b8b28ddb3b2bd619805@mekentosj.com> References: <9115b604387992ec0e562fde8d9252fb@earthlink.net> <28ad7187e0142b8b28ddb3b2bd619805@mekentosj.com> Message-ID: <52c9796a7cd2d4c23e87dd911e569d10@earthlink.net> On Feb 24, 2005, at 4:22 AM, Alexander Griekspoor wrote: > True, Charles is right here, but I would propose to grant Koen one > more time access to "the matrix" and remove those pesky (BCUtil ?) > folders in the root folder that require us to do the pruning during > checkout, those are remnants from a time long gone ;-) > I will do that tonight (EST). Just post a list here of things that can be thrown out. - Koen. From mek at mekentosj.com Thu Feb 24 07:45:53 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 13:45:53 +0100 Subject: [Biococoa-dev] Re: Using annotations Message-ID: <8ffaaf024aa6088022b414317f592c53@mekentosj.com> > Now, one question, in another mail the word 'attributes' was used. Is > this yet something else than annotations and features? No, attribute is the term used in the BSML format for one type of annotation (the one we use here).... Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com 4Peaks - For Peaks, Four Peaks. 2004 Winner of the Apple Design Awards Best Mac OS X Student Product http://www.mekentosj.com/4peaks ********************************************************* From mek at mekentosj.com Thu Feb 24 07:46:15 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 24 Feb 2005 13:46:15 +0100 Subject: [BioCocoa-dev] AppKit Message-ID: > I will do that tonight (EST). Just post a list here of things that can > be thrown out. The following files, all in the root directory: root/BCSequence (including the BCSymbol folder inside). root/BCUtils root/demo_app root/English.lproj root/Translation ************************************************************** ** Alexander Griekspoor ** ************************************************************** The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From jtimmer at bellatlantic.net Thu Feb 24 08:45:28 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 24 Feb 2005 08:45:28 -0500 Subject: Archiving annotations (was: [Biococoa-dev] Annotation) In-Reply-To: <32d498b46a9eb20bf3fbb700c3688270@mekentosj.com> Message-ID: > I see where you're head at, but I don't see exactly HOW you would like to see > this implement. > Do you mean that each annotation instead of a simple shouldArchive boolean > should have a variable which you can set to one of the three levels you > describe? Could you describe a bit more in detail how to implement this all? > If I understand you right, you want this system be functional in the > read/write classes or not? So one can define what he wants to save/load > to/from a file? Or/And do you want to have these options in the sequence > creation methods? How do we check what the app supports? Delegates? > It's rather vague to me although I agree that we need to have a system to > discriminate between different levels of annotation datatype support. I was thinking of keeping this under the control of the user (user == developer using the framework). Basically, when importing data or preparing it for export, they could call a method and get the attributes stripped according to their needs. The method could just walk through the values and do the pruning as appropriate. It would probably be too processor hungry to do at d-and-d initiation, but could easily be done by the receiving app. In regards to Charles?s point about the ?lossy? formats being somewhat problematic from the perspective of shifting data back and forth between apps and losing something each time, that?s definitely true. But if we shift the burden of when to call these methods onto the users, then it?s up to them to determine when stripping information is appropriate, perhaps making it a user preference. JT _______________________________________________ This mind intentionally left blank -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtimmer at bellatlantic.net Thu Feb 24 11:28:04 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 24 Feb 2005 11:28:04 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: Message-ID: I see that Koen (probably long ago) put the ambiguous amino acids in place. That means that all subclasses of BCSymbol now have ambiguity. That, in turn, means that the method "isSingleBase" can be moved to the BCSymbol class, and renamed to reflect its more broad applicability. I could either do "isSimpleSymbol" or "isCompoundSymbol" accordingly. Any preferences or alternate suggestions? Incidentally, this will allow me to get rid of the last warning in the BCSequenceNucleotide class I'm putting together ;). The flipside is that I'm sure it'll break code somewhere else... A technical question: I'd like a BCSequenceNucleotide method, when called, to return an instance of the appropriate subclass. Is the following syntax appropriate: [[self class] sequenceWithSymbolArray: theArray]; Since the method's actually going to be called on a subclass, I figure this should generate the appropriate one. Is that accurate? Cheers, JT _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Thu Feb 24 12:21:32 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 09:21:32 -0800 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: >I see that Koen (probably long ago) put the ambiguous amino acids in place. >That means that all subclasses of BCSymbol now have ambiguity. That, in >turn, means that the method "isSingleBase" can be moved to the BCSymbol >class, and renamed to reflect its more broad applicability. I could either >do "isSimpleSymbol" or "isCompoundSymbol" accordingly. Any preferences or >alternate suggestions? isCompoundSymbol: maybe more technical but also more precise than 'simple', so I like it better. >Incidentally, this will allow me to get rid of the last warning in the >BCSequenceNucleotide class I'm putting together ;). The flipside is that >I'm sure it'll break code somewhere else... Ah, ah! Time for me to commit the test bundle and then no more such worries. Nobody answered my poll about the unit testing (snif), so I will take the absence of answers as a yes. This is democracy! >[[self class] sequenceWithSymbolArray: theArray]; > >Since the method's actually going to be called on a subclass, I figure this >should generate the appropriate one. Is that accurate? > >Cheers, > >JT Since I 'cleaned' the sequence classes initialization methods, it is actually already in the superclass BCAbstractSequence, so you get it for free for your class!! + (BCAbstractSequence *)sequenceWithSymbolArray:(NSArray *)entry { return [[[[self class] alloc] initWithSymbolArray:entry] autorelease]; } Subclasses only need to overwrite the two designated initializers. I put some comments about that somewhere I believe (note that with the symbolSet -Koen!-, even this should disappear soon; having 2 designated initializers is not a good design anyway!). But the subclasses of BCSequenceNucleotide already implement them, so you probably don't need to do anything at this level. Not doing anything is probably also the best way to not break anything ;-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From jtimmer at bellatlantic.net Thu Feb 24 14:54:58 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 24 Feb 2005 14:54:58 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: Message-ID: >> I see that Koen (probably long ago) put the ambiguous amino acids in place. >> That means that all subclasses of BCSymbol now have ambiguity. That, in >> turn, means that the method "isSingleBase" can be moved to the BCSymbol >> class, and renamed to reflect its more broad applicability. I could either >> do "isSimpleSymbol" or "isCompoundSymbol" accordingly. Any preferences or >> alternate suggestions? > > isCompoundSymbol: maybe more technical but also more precise than 'simple', so > I like it better. In a related issue, I see that BCSymbol now has the representedSymbol methods, which is good, but contains the complement method, which seems bad, since it returns nil. Is there any advantage to having it there, instead of moving it down to a Nucleotide class? Again, I'm very nervous about providing a method that returns nil (and thus increases the chances of terminal bugs) to the amino acids, which have no reason to ever support this. JT _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Thu Feb 24 15:23:22 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 12:23:22 -0800 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: At 14:54 -0500 2/24/05, John Timmer wrote: > >> I see that Koen (probably long ago) put the ambiguous amino acids in place. >>> That means that all subclasses of BCSymbol now have ambiguity. That, in >>> turn, means that the method "isSingleBase" can be moved to the BCSymbol >>> class, and renamed to reflect its more broad applicability. I could either >>> do "isSimpleSymbol" or "isCompoundSymbol" accordingly. Any preferences or >>> alternate suggestions? >> >> isCompoundSymbol: maybe more technical but also more precise than 'simple', so >> I like it better. > >In a related issue, I see that BCSymbol now has the representedSymbol >methods, which is good, but contains the complement method, which seems bad, >since it returns nil. Is there any advantage to having it there, instead of >moving it down to a Nucleotide class? > >Again, I'm very nervous about providing a method that returns nil (and thus >increases the chances of terminal bugs) to the amino acids, which have no >reason to ever support this. > >JT > I have not had time to go down to that level of details, yet, but it could be better that the BCSymbol superclass responds to the message (even if not in the header). It could return 'self' instead, though. I agree that would be safer. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From biococoa at bioworxx.com Thu Feb 24 15:59:47 2005 From: biococoa at bioworxx.com (Philipp Seibel) Date: Thu, 24 Feb 2005 21:59:47 +0100 Subject: [Biococoa-dev] BCStatistics framework Message-ID: Hi all, i set up the BCStatistics.framework in my local XCode projects. Now i want to put it into the CVS. Can anybody tell me how to set it up as a new target, basically i know my self, but i don't want to crash the cvs and i want of course conform to your current project structure. So a little "tutorial for the newbee" woud be fine. thx Phil From kvddrift at earthlink.net Thu Feb 24 19:49:22 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 19:49:22 -0500 Subject: [BioCocoa-dev] AppKit In-Reply-To: References: Message-ID: On Feb 24, 2005, at 7:46 AM, Alexander Griekspoor wrote: >> I will do that tonight (EST). Just post a list here of things that >> can be thrown out. > The following files, all in the root directory: > root/BCSequence (including the BCSymbol folder inside). > root/BCUtils > root/demo_app > root/English.lproj > root/Translation > Done. - Koen. From kvddrift at earthlink.net Thu Feb 24 19:51:27 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 19:51:27 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: <90595157479d94d2f3e2e940d825a95b@earthlink.net> On Feb 24, 2005, at 3:23 PM, Charles PARNOT wrote: >> >> Again, I'm very nervous about providing a method that returns nil >> (and thus >> increases the chances of terminal bugs) to the amino acids, which >> have no >> reason to ever support this. >> >> JT >> > > I have not had time to go down to that level of details, yet, but it > could be better that the BCSymbol superclass responds to the message > (even if not in the header). It could return 'self' instead, though. I > agree that would be safer. > > By lack of a BCNucleotideSymbol class, I put the complements method in BCSymbol for the time being. You can move them to the BCNucleotideSymbol class, but I also like Charles' suggestion to let the method return self in such cases. The same can be said for other methods that only work on certain symbols or sequences, eg translation. - Koen. From kvddrift at earthlink.net Thu Feb 24 20:53:57 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 20:53:57 -0500 Subject: [Biococoa-dev] Updating Nib files Message-ID: Hi, To use the BCSequenceView with the translation demo, a few things need to be changed in the nib file of that target. To add those changes to cvs, Xcode cannot be used, so it has to be done from the command line. I think I figured out how to do it (I already did it, no need to repeat) on the command line cd into MainMenu.nib (it's a folder) first I updated the three files: cvs update classes.nib info.nib cvs update -kb keyedobjects.nib (===>>>> it's a binaryfile, and needs the -kb flags) Then I commited the three files: cvs ci -m "info message" classes.nib cvs ci -m "info message" info.nib cvs ci -m "info message" keyedobjects.nib I did a fresh checkout from cvs, and it seems to be working. Please try a cvs update to see if the translation demo now uses the BCSequenceView with the line numbers. thanks, - Koen. (psssst I did some more cleanup in cvs: I removed the .DS_Store files, and also added a cvsignore file that tells cvs to skip the .DS*, build, and *~.nib files) From jtimmer at bellatlantic.net Thu Feb 24 21:22:49 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 24 Feb 2005 21:22:49 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: <90595157479d94d2f3e2e940d825a95b@earthlink.net> Message-ID: > > By lack of a BCNucleotideSymbol class, I put the complements method in > BCSymbol for the time being. You can move them to the > BCNucleotideSymbol class, but I also like Charles' suggestion to let > the method return self in such cases. The same can be said for other > methods that only work on certain symbols or sequences, eg translation. > Yeah - asking for a translation of a protein and getting the protein doesn't seem unreasonable, and is certainly safer than getting nil. I'll put in the BCSymbolNucleotide tomorrow, along with the BCSequenceNucleotide. JT _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Thu Feb 24 21:34:04 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 18:34:04 -0800 Subject: [Biococoa-dev] Updating Nib files, etc. In-Reply-To: References: Message-ID: Wow, you are the cvs jedi!! Ok, I take back what I said about being careful with the repository. This does not apply to you anymore ;-) charles At 19:49 -0500 2/24/05, Koen van der Drift wrote: >On Feb 24, 2005, at 7:46 AM, Alexander Griekspoor wrote: > >>>I will do that tonight (EST). Just post a list here of things that can be thrown out. >>The following files, all in the root directory: >>root/BCSequence (including the BCSymbol folder inside). >>root/BCUtils >>root/demo_app >>root/English.lproj >>root/Translation > >Done. > >- Koen. > >_______________________________________________ >Biococoa-dev mailing list >Biococoa-dev at bioinformatics.org >https://bioinformatics.org/mailman/listinfo/biococoa-dev At 20:53 -0500 2/24/05, Koen van der Drift wrote: >Hi, > >To use the BCSequenceView with the translation demo, a few things need to be changed in the nib file of that target. To add those changes to cvs, Xcode cannot be used, so it has to be done from the command line. I think I figured out how to do it (I already did it, no need to repeat) > >on the command line cd into MainMenu.nib (it's a folder) > >first I updated the three files: > >cvs update classes.nib info.nib >cvs update -kb keyedobjects.nib (===>>>> it's a binaryfile, and needs the -kb flags) > >Then I commited the three files: > >cvs ci -m "info message" classes.nib >cvs ci -m "info message" info.nib >cvs ci -m "info message" keyedobjects.nib > >I did a fresh checkout from cvs, and it seems to be working. Please try a cvs update to see if the translation demo now uses the BCSequenceView with the line numbers. > >thanks, > >- Koen. > > >(psssst I did some more cleanup in cvs: I removed the .DS_Store files, and also added a cvsignore file that tells cvs to skip the .DS*, build, and *~.nib files) > >_______________________________________________ >Biococoa-dev mailing list >Biococoa-dev at bioinformatics.org >https://bioinformatics.org/mailman/listinfo/biococoa-dev -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Thu Feb 24 21:50:57 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 21:50:57 -0500 Subject: [Biococoa-dev] BCStatistics framework In-Reply-To: References: Message-ID: <2410e25fba26efc4cfb99904ed1c36f6@earthlink.net> On Feb 24, 2005, at 3:59 PM, Philipp Seibel wrote: > i set up the BCStatistics.framework in my local XCode projects. Now i > want to put it into the CVS. Can anybody tell me how to set it up as a > new target, basically i know my self, but i don't want to crash the > cvs and i want of course conform to your current project structure. > So a little "tutorial for the newbee" woud be fine. > Phil, I am not sure if we have decided yet how we are going to add additional frameworks. Are we making separate targets in the same project, or separate projects for each framework? Alex already started that discussion in another thread, so maybe I shouldn't reply here. I think right now we can have one BioCocoa project with various targets for each framework: BCFoundation, BCAppKit, BCStatistics, ... Actually, BCFoundation and BCAppKit are in the same framework right now, with the same target, so that may need a change as well if we go this path. To answer your question, I don't know if just adding a target will actually be accepted by cvs, guess we just have to try. Just make sure (as already mentioned by Alex) that you add the BCStatistics folder in the same location in the Xcode project and in the BioCocoa folder on your HD. The most logical place seems to be at the same level as BFoundation and BCAppKit. - Koen. From kvddrift at earthlink.net Thu Feb 24 21:52:55 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 21:52:55 -0500 Subject: [Biococoa-dev] Updating Nib files, etc. In-Reply-To: References: Message-ID: On Feb 24, 2005, at 9:34 PM, Charles PARNOT wrote: > Wow, you are the cvs jedi!! > Ok, I take back what I said about being careful with the repository. > This does not apply to you anymore ;-) > Hahahaha. Did you know that from cvsroot you can also cd into the other projects, and into the html files from Bioinformatics.org? BTW, did the new translation demo work with the BCSequenceView? - Koen. From charles.parnot at stanford.edu Thu Feb 24 21:57:01 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 18:57:01 -0800 Subject: mutable or immutable features? (was: [Biococoa-dev] Comments on BCAnnotation) In-Reply-To: <5e11d5508de5c8738339706794b0a62f@mekentosj.com> References: <0d23e9fa4bb6205791d3d8eeed544eea@bioworxx.com> <5e11d5508de5c8738339706794b0a62f@mekentosj.com> Message-ID: At 11:17 +0100 2/24/05, Alexander Griekspoor wrote: >>>After going through your code, Alex, here are my comments: >>> >>>* we should make BCAnnotation and BCFeature immutable and thus not have any setter; for instance, the annotations would otherwise have to be physically copied every time a piece of sequence is copied and pasted or used for alignement, etc... >>you are definitly right. There is perhaps one problem, but perhaps it isn't a real problem ;-)... what happens with the BCFeature positions if i insert gaps into the sequence. If the positions have no set method everybody has to know that this positions are the ones without gaps. >>I'm also not sure wether we need a special BCSequence class for alignment or not. Perhaps we need only a BCMutableSequence with the corresponding BCSymbolSet including a gap-symbol. This is open for discussion .... > >Annotations can be immutable as they are position independent indeed, but per definition the range of a BCFeature of a mutable sequence (which ours is at the moment) should be mutable as well. Good thought Phil... Well, I would still stick to an immutable version. Here is why. When you modify a sequence, you have to change the positional information in the features. If a feature is mutable, you will want to make a copy first and then modify it, though, because you don't know if the feature instance is not shared with another sequence, and the range you are modifying would not apply to that other sequence. Or to avoid that, when you copy a sequence, you would also make a physical copy of the feature so you know a feature object is not shared between sequences. In both approach, you still don't know what the user of the framework might do with the feature if it is being returned through the accessor in the sequence object. So the accessor should return a copy too, just in case. You end up physically copying the features all the time one way or the other, and the user of the framework may be doing the same too, even when maybe it would be OK to share the instance because nobody is going to modify it. But you never know, so you just copy. The bottom line is: if we agree that features might be shared by different objects (which you may say is not the case), then every time you modify a feature, you have to copy it first just in case. On the contrary, with an immutable feature, you don't have to physically copy it all the time, you know it will never change. Even the -(id)copy method can simply return self (and retain it). Of course, the issue raised by Phil is still valid. But because the only modif would be on the range, you could have a method like this: - (BCFeature *)featureWithNewRange:(BCRange)newRange; returning a new autoreleased object, copy of the target and with a new range. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Thu Feb 24 21:58:49 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 21:58:49 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: <82a8a49ad768fe62168019a5f0ebfa42@earthlink.net> On Feb 24, 2005, at 9:22 PM, John Timmer wrote: > Yeah - asking for a translation of a protein and getting the protein > doesn't > seem unreasonable, and is certainly safer than getting nil. > I looked at changing that in BCSymbol. I think the most logical place would be in initializeSymbolRelationships, for instance: symbolReference = [[self symbolInfo] objectForKey: @"Complement"]; if ( symbolReference != nil || [symbolReference length] > 0 ) { complement = [(BCSymbol*)[self class] performSelector: NSSelectorFromString( symbolReference )]; // add this: if (complement == nil) complement = self; } Or I can put it in the complement method - (BCSymbol *)complement { if ( complement == nil ) [self initializeSymbolRelationships]; // add this: if (complement == nil) complement = self; return (BCSymbol *)complement; } What do others think? > I'll put in the BCSymbolNucleotide tomorrow, along with the > BCSequenceNucleotide. Great! - Koen. From kvddrift at earthlink.net Thu Feb 24 22:04:10 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 22:04:10 -0500 Subject: mutable or immutable features? (was: [Biococoa-dev] Comments on BCAnnotation) In-Reply-To: References: <0d23e9fa4bb6205791d3d8eeed544eea@bioworxx.com> <5e11d5508de5c8738339706794b0a62f@mekentosj.com> Message-ID: <6f42f1f14629a04c73d9598facf61ec1@earthlink.net> On Feb 24, 2005, at 9:57 PM, Charles PARNOT wrote: > When you modify a sequence, you have to change the positional > information in the features. If a feature is mutable, you will want to > make a copy first and then modify it, though, because you don't know > if the feature instance is not shared with another sequence, I don't understand this last part. Can you explain why a feature can be shared between more than one sequence? The way I see it, if two sequences have the same feature they both should have a separate BCFeature object to contain that information. - Koen. From charles.parnot at stanford.edu Thu Feb 24 22:04:41 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 19:04:41 -0800 Subject: sorting features (was: [Biococoa-dev] Comments on BCAnnotation) In-Reply-To: <54a29a2827612bcb0179e59846d495ce@mekentosj.com> References: <54a29a2827612bcb0179e59846d495ce@mekentosj.com> Message-ID: >>* I don't like the comparison methods names; why not stick to the Cocoa way, which is simply 'compare:' using 'compareName:' and 'compareContents:'. And I am not sure why you would need a ascending and descending method when one can use reverseEnumerator? >Somehow this is the way I always used to implement rapid sorting for tableviews. Say you have a mutablearray of BCAnnotations displayed in a tableview, you can quickly sort them in ascending or descending order with this method. Haven't used bindings enough to see if that has become obsolete now. Yes, I can change the methods to compareName: and compareContents: no problem. I went through the documentation and could not find a 'reverseSort' method for arrays, which I find weird. I was sure something like this existed. I am not sure if bindings stick with that. Anyway, then maybe you could keep the reverse sorting and name it 'reverseCompareName:' and 'reverseCompareContents:', inspired by NSString's 'caseInsensitiveCompare:' method. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 22:13:42 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 19:13:42 -0800 Subject: [Biococoa-dev] Subclass organization In-Reply-To: <82a8a49ad768fe62168019a5f0ebfa42@earthlink.net> References: <82a8a49ad768fe62168019a5f0ebfa42@earthlink.net> Message-ID: I vote for putting it in 'initializeSymbolRelationships'. Oups, actually, don't we have a reference count, then? We don't release complement in the dealloc, do we? Yes, we do! Well, we should not, because we are not retaining complement. And we should not retain. This is a case where we want a weak link. So we should not release it (did I already say that?). I know it does not really matter because dealloc is probably never called and these objects never die, but well... charles >I looked at changing that in BCSymbol. I think the most logical place would be in initializeSymbolRelationships, for instance: > > symbolReference = [[self symbolInfo] objectForKey: @"Complement"]; > > if ( symbolReference != nil || [symbolReference length] > 0 ) > { > complement = [(BCSymbol*)[self class] performSelector: NSSelectorFromString( symbolReference )]; > > // add this: > > if (complement == nil) > complement = self; > } > >Or I can put it in the complement method > > - (BCSymbol *)complement > { > if ( complement == nil ) > [self initializeSymbolRelationships]; > > // add this: > > if (complement == nil) > complement = self; > > return (BCSymbol *)complement; > } > > >What do others think? > >>I'll put in the BCSymbolNucleotide tomorrow, along with the >>BCSequenceNucleotide. > >Great! > > >- Koen. > >_______________________________________________ >Biococoa-dev mailing list >Biococoa-dev at bioinformatics.org >https://bioinformatics.org/mailman/listinfo/biococoa-dev -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Thu Feb 24 22:13:55 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 22:13:55 -0500 Subject: sorting features (was: [Biococoa-dev] Comments on BCAnnotation) In-Reply-To: References: <54a29a2827612bcb0179e59846d495ce@mekentosj.com> Message-ID: <2a7ce6992ae7bacfd25e068622760e3d@earthlink.net> On Feb 24, 2005, at 10:04 PM, Charles PARNOT wrote: > I went through the documentation and could not find a 'reverseSort' > method for arrays, which I find weird. I was sure something like this > existed. Maybe you meant sortedArrayUsingSelector ? > I am not sure if bindings stick with that. Anyway, then maybe you > could keep the reverse sorting and name it 'reverseCompareName:' and > 'reverseCompareContents:', inspired by NSString's > 'caseInsensitiveCompare:' method. I would suggest compareByName and reverseCompareByName, etc - Koen. From jtimmer at bellatlantic.net Thu Feb 24 22:15:28 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 24 Feb 2005 22:15:28 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: <82a8a49ad768fe62168019a5f0ebfa42@earthlink.net> Message-ID: Well, I don't really see the point in having complement there when I'm going to create BCSymbolNucleotide, so I'll just do an experiment when I get into work tomorrow (where I've got the initial files): can I move the complement method to BCSymbolNucleotide and not have anything break, build wise? > I looked at changing that in BCSymbol. I think the most logical place > would be in initializeSymbolRelationships, for instance: > > symbolReference = [[self symbolInfo] objectForKey: @"Complement"]; > > if ( symbolReference != nil || [symbolReference length] > 0 ) > { > complement = [(BCSymbol*)[self class] performSelector: > NSSelectorFromString( symbolReference )]; > > // add this: > > if (complement == nil) > complement = self; > } > > Or I can put it in the complement method > > - (BCSymbol *)complement > { > if ( complement == nil ) > [self initializeSymbolRelationships]; > > // add this: > > if (complement == nil) > complement = self; > > return (BCSymbol *)complement; > } > > > What do others think? > _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Thu Feb 24 22:21:35 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 24 Feb 2005 22:21:35 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: <6f9b132612be315eb846b50e37449fad@earthlink.net> On Feb 24, 2005, at 10:15 PM, John Timmer wrote: > Well, I don't really see the point in having complement there when I'm > going > to create BCSymbolNucleotide, so I'll just do an experiment when I get > into > work tomorrow (where I've got the initial files): can I move the > complement > method to BCSymbolNucleotide and not have anything break, build wise? > John, I thought you agreed that returning self instead of nil was a good alternative, sorry if I misunderstood. Feel free to go ahead and move the complement code to BCSymbolNucleotide. cheers, - Koen. From charles.parnot at stanford.edu Thu Feb 24 22:30:01 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 19:30:01 -0800 Subject: [Biococoa-dev] Subclass organization In-Reply-To: <6f9b132612be315eb846b50e37449fad@earthlink.net> References: <6f9b132612be315eb846b50e37449fad@earthlink.net> Message-ID: >>Well, I don't really see the point in having complement there when I'm going >>to create BCSymbolNucleotide, so I'll just do an experiment when I get into >>work tomorrow (where I've got the initial files): can I move the complement >>method to BCSymbolNucleotide and not have anything break, build wise? >> > >John, > >I thought you agreed that returning self instead of nil was a good alternative, sorry if I misunderstood. Feel free to go ahead and move the complement code to BCSymbolNucleotide. >- Koen. I think what John means is that in BCSymbol, -complement can return self: - (id)complement { return self; } and BCSymbolNucleotide would override this and have an ivar 'complement' to cache the result. It makes more sense, actually, because then it really takes advantage of the superclass-subclass design, where more specialized subclasses override superclass methods. is that it, John? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 22:44:06 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 19:44:06 -0800 Subject: mutable or immutable features? (was: [Biococoa-dev] Comments on BCAnnotation) In-Reply-To: <6f42f1f14629a04c73d9598facf61ec1@earthlink.net> References: <0d23e9fa4bb6205791d3d8eeed544eea@bioworxx.com> <5e11d5508de5c8738339706794b0a62f@mekentosj.com> <6f42f1f14629a04c73d9598facf61ec1@earthlink.net> Message-ID: >On Feb 24, 2005, at 9:57 PM, Charles PARNOT wrote: > >>When you modify a sequence, you have to change the positional information in the features. If a feature is mutable, you will want to make a copy first and then modify it, though, because you don't know if the feature instance is not shared with another sequence, > >I don't understand this last part. Can you explain why a feature can be shared between more than one sequence? The way I see it, if two sequences have the same feature they both should have a separate BCFeature object to contain that information. > >- Koen. It could be shared if you copy a sequence. Or you paste a piece of sequence somewhere else and the position is the same. Or you copy a sequence to do an alignment. Because the sequence objects are mutable, you have to physically copy them before using them in another context, which means physically copying any mutable ivar. It is still debatable how often this will happen, of course. I think there is a part of psychology here, as immutable objects are less likely to cause trouble in the future and will let you code in peace. For instance, in my current application for my project in the lab, I am using a parameter class which I made mutable at the beginning because I thought it would be easier. I end up worrying all the time: should I copy the object before doing this or that? Because when the code grows bigger, you tend to lose track of where and why objects could be shared with other objects. Now I really wish I had created immutable objects instead. Don't you find yourself mostly using immutable objects (NSString, NSArray,..) when they might be used out of the scope of a method or out of a scope of a class (e.g. public ivars), and mutable objects WITHIN the scope of a method or when you know these ivars are going to be private. Maybe I am paranoid, though!! My final argument would be: it does not really cost much to use immutable features instead of mutable features because they are light objects, containing immutable ivars. So a copy is really just allocating a few bytes to copy the addresses of the ivars. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 22:57:06 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 19:57:06 -0800 Subject: [Biococoa-dev] Comments on BCAnnotation In-Reply-To: <54a29a2827612bcb0179e59846d495ce@mekentosj.com> References: <54a29a2827612bcb0179e59846d495ce@mekentosj.com> Message-ID: >>* In the comparison: more generally, if the Contents are of the same class and both respond to 'compare:', then this is what is used >What do you try to say? I don't get the point.. Sorry it was very very brief... Here is what I mean. In the headerdoc of 'compareContents:' you say it does use compare: when the class of the contents is NSString or NSNumber. More generally, it could use 'compare:' if the instance in Contents responds to it. That would be more general. The user could put objects of her own that responds to 'compare:' and would be sorted gracefully even if not NSString or NSNumber. In other words, the headerdoc could explain that and the implementation could use 'respondsToSelector:@selector(compare:)' to check the behavior of the contents object. >>* the data type should be an ivar, if you want to preserve annotations coming from another app; in which case the contents is NSData; more precisely, when unarchiving, if the class is known, the contents is unarchived; otherwise, the ivar 'contentsClass' stores the class name and the ivar 'contents' stores the unarchived data; >Again, I'm not really what you would like to see. I was just trying to anticipate what is going to happen when you unarchive the feature: * first you unarchive 'contentsClass' = NSString *theClass * then you check that NSClassFromString(theClass) != nil * if it is not nil, then fine you can unarchive the contents object and you call 'decodeObjectForKey:' * if it is nil, then what do you do?? The object is lost and you can't reencode it later I could not find a solution to that issue. OK, then, the archiving should archive this: * the class type as NSString * the 'contents' object wrapped in NSData using 'archivedDataWithRootObject:' * the 'name' as NSString Now, when unarchiving: * you unarchive the name * you unarchive 'contentsClass' = NSString *theClass * then you check that NSClassFromString(theClass) != nil * if it is not nil, then fine you can unarchive the NSData object calling '-decodeObjectForKey:' and then unwrap the contents using '+unarchiveObjectWithData:' (this could be simplify if the class is part of the Cocoa framework, which we could test for; also it assumes that if the root object class exists, then the children object classes also exist) * if it is nil, then you simply store the NSData object for future archiving * but for future archiving, you also need to store the contentsClass, otherwise you have know way to remember what it is when archiving --> hence the need for an ivar 'contentsClass' I hope this was clearer, and maybe I am missing a more elegant solution. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 23:05:35 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 20:05:35 -0800 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: Message-ID: At 22:38 -0500 2/24/05, John Timmer wrote: >No, actually, I just don't see the point in putting a method into the >superclass that's should never be called by it or some of its subclasses. >There could be a reason for doing that, but I just don't see any. Is there >something I missed? > >Please be assured that I'm not trying to rehash some of the older arguemnts >- I'm getting the impression I'm missing something here, and I'd really like >to understand what it is. > >JT > I was just thinking that the 'complement' method of sequence could then be in the superclass and not have to worry about BCSymbol responding or not to complement. But now, I realize this is a bit ridiculous, BCAbstractSequence will simply return an empty sequence, and I don't see any other place where BCSymbol responding to complement makes sense. Having complement only in the nucleotide subclass also makes the code more readable. Do it like you say, sorry for the noise:-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 23:13:40 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 20:13:40 -0800 Subject: [Biococoa-dev] Project Structure In-Reply-To: References: <593e4c31c4a315fb67ead5e0a012ed59@bioworxx.com> Message-ID: >The question is will we stick with one XCode project with a separate target for each (sub)framework? I'm in favor of that as long as it doesn't grow too much (which probably will not be the case for some time..). >> >>with this organisation we wouldn't need the folders in the filesystem, just groups and targets. >Please, like John said, let's mirror the group, target hierarchy also in the filesystem as much as possible!!! If we add a BCStatistics framework, then we should also add a BCStatistics folder in the root of the project directory just like we did with BCAppKit and BCFoundation. Let's try to stick to the same model as for these two... > >Finally, this answers Charles remark as well: >>From last week, it seemed most people liked the idea, but I thought I'd ask again now that we have more people before adding yet another folder and a new target and 10 more files... >Guess, it's no problem to add another target and folder;-) I don't really see any problems with a large project. Checkout and updates via cvs would only suffer performance issues if we have thousands of files. Clearly having physical folders in the project will help, lke John explained. I also wondered at the beginning why you were doing that, and I realized after a while the benefit for cvs stuff. Having many targets and groups in the project is dependent on Xcode resistance to that. We will test its limits... A wild guess: beyond 20 targets, some issues may appear? We will never get there, right?? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 23:16:08 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 20:16:08 -0800 Subject: Archiving annotations (was: [Biococoa-dev] Annotation) In-Reply-To: References: Message-ID: At 8:45 -0500 2/24/05, John Timmer wrote: >I see where you're head at, but I don't see exactly HOW you would like to see this implement. >Do you mean that each annotation instead of a simple shouldArchive boolean should have a variable which you can set to one of the three levels you describe? Could you describe a bit more in detail how to implement this all? If I understand you right, you want this system be functional in the read/write classes or not? So one can define what he wants to save/load to/from a file? Or/And do you want to have these options in the sequence creation methods? How do we check what the app supports? Delegates? >It's rather vague to me although I agree that we need to have a system to discriminate between different levels of annotation datatype support. > > >I was thinking of keeping this under the control of the user (user == developer using the framework). Basically, when importing data or preparing it for export, they could call a method and get the attributes stripped according to their needs. The method could just walk through the values and do the pruning as appropriate. It would probably be too processor hungry to do at d-and-d initiation, but could easily be done by the receiving app. > >In regards to Charles's point about the "lossy" formats being somewhat problematic from the perspective of shifting data back and forth between apps and losing something each time, that's definitely true. But if we shift the burden of when to call these methods onto the users, then it's up to them to determine when stripping information is appropriate, perhaps making it a user preference. > >JT I think you address the point quite well. We let the decision to the user of the framework, who lets the decision to the user of the application. Simple and flexible. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 23:25:50 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 20:25:50 -0800 Subject: [Biococoa-dev] BCStatistics framework In-Reply-To: References: Message-ID: At 21:59 +0100 2/24/05, Philipp Seibel wrote: >Hi all, > >i set up the BCStatistics.framework in my local XCode projects. Now i want to put it into the CVS. Can anybody tell me how to set it up as a new target, basically i know my self, but i don't want to crash the cvs and i want of course conform to your current project structure. >So a little "tutorial for the newbee" woud be fine. > >thx Phil when adding a target, the file project.pbxproj inside the BioCocoa.pbproj package file get modified and appears in the SCM smart group in the Xcode window of the project (in the Groups&Files panel). So if you add a target, you should see that file with the letter M appear in the SCM smart group (M=modified). You select that line (maybe with the other files you added) and commit it. Now everybody will see that file with an 'U' in the SCM smart group, and will be able to update it. For the added folders, you need to add the folder and its contents using the command line cvs (cvs add foldername) then the files inside can be added within Xcode (they will show with a ? in the SCM smart group, then you add them, they show with an 'A', then you commit them). If somebody added folder, you need to update the project through the command-line using: cvs update -d (after cd-ing to the project folder) (the -P flag could also be used to prune empty folders, but thanks to Koen, no more of these) Otherwise, Xcode will be aware of the files (thanks to project.pbxproj) and show them in red because it can't find them. In other words, Xcode is unable to handle folders in the projects (both for addition and for updating) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 23:28:01 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 20:28:01 -0800 Subject: [Biococoa-dev] Updating Nib files, etc. In-Reply-To: References: Message-ID: At 21:52 -0500 2/24/05, Koen van der Drift wrote: >On Feb 24, 2005, at 9:34 PM, Charles PARNOT wrote: > >>Wow, you are the cvs jedi!! >>Ok, I take back what I said about being careful with the repository. This does not apply to you anymore ;-) >> > >Hahahaha. Did you know that from cvsroot you can also cd into the other projects, and into the html files from Bioinformatics.org? > >BTW, did the new translation demo work with the BCSequenceView? > > >- Koen. with read/write permissions?? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 23:33:13 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 20:33:13 -0800 Subject: [Biococoa-dev] Developer documentation In-Reply-To: <60be4d35dde205444660baf7aa4c3604@mekentosj.com> References: <60be4d35dde205444660baf7aa4c3604@mekentosj.com> Message-ID: At 10:37 +0100 2/24/05, Alexander Griekspoor wrote: >>Yes, this is why I started the dev-docs folder on the project. Having it in the project makes it easier for everybody to edit, like a wiki in a way, so everybody can contribute and help too. To duplicate this in a web site is nice, but it might be hard for you to keep it in sync? Maybe if you suggested a simple layout that would make the conversion easier? e.g. I sticked to some

and

tags in what I started (I did not like the default format for

, too big!). >Heard of CSS ? ;-) >If we stick to some tags perhaps similar to the headerdoc tags, we don't have to go spread all these

etc throughout the code. I'll give a look at it and come up with a proposal. Editing the docs in the project is brilliant, indeed wiki like.... The idea of using html was to have something immediately readable by whoever checkouts the project for the first time. If we use tags similar to headerdoc, then this is not true anymore. If we stick to simple html tags like h1-h2... and p, the parsing should be easy, and maybe even just a css is enough without further processing or parsing to paste on your web site? Anyway, I will let you think about it! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Thu Feb 24 23:41:48 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 20:41:48 -0800 Subject: [Biococoa-dev] BCStatistics framework In-Reply-To: References: Message-ID: >For the added folders, you need to add the folder and its contents using the command line cvs (cvs add foldername) then the files inside can be added within Xcode (they will show with a ? in the SCM smart group, then you add them, they show with an 'A', then you commit them). I forgot. After adding the folder you need to commit: cd to/the/project cvs add somefoldername cvs commit -m 'added somefoldername' somefoldername charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Fri Feb 25 02:21:16 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Thu, 24 Feb 2005 23:21:16 -0800 Subject: [Biococoa-dev] Upgrading to native targets Message-ID: From Apple's docs: "Cross-development in Xcode requires native targets. For more information on how to upgrade existing Jam-based targets to use the native build system, see "Converting a Project Builder Target"." I ran into this problem when trying to add the test framework, which requires to use OS X.3 deployement target. Upgrading to native target is then needed because old targets do not support different Mac OS X version deployment, which also require to set the SDK at the level of the project. I am not sure I understand all the details yet, but upgrading to a native target seems inevitable. Note that it does not prevent the development of X.2.8-compatible targets. However, native targets require Xcode. Is everybody using Xcode and can we switch the framework to a native target? Anyway, it seems that we have decided to define a new target BCFoundation.framework to replace BioCocoa.framework. And with all these new targets coming, and potentially different Mac OS X version deployment, the time has come to force everybody to use Xcode, what do you think? Now that I think about it, I can't see why somebody would not be using Xcode yet and would still be on Project Builder, so it is probably no big deal. Just want to check. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Fri Feb 25 04:13:16 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 25 Feb 2005 04:13:16 -0500 Subject: [Biococoa-dev] Updating Nib files, etc. In-Reply-To: References: Message-ID: <74e26c032761dc33b258bbbf554abf37@earthlink.net> On Feb 24, 2005, at 11:28 PM, Charles PARNOT wrote: >> BTW, did the new translation demo work with the BCSequenceView? >> >> >> - Koen. > > with read/write permissions?? > Eh? I am not sure what you mean. Are the permissions wrong in cvs? My question was, I updated the nib file using cvs on the command line, do you now see the changes in the demo that should now use the BCSequenceView? - Koen. From kvddrift at earthlink.net Fri Feb 25 04:16:45 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 25 Feb 2005 04:16:45 -0500 Subject: [Biococoa-dev] Subclass organization In-Reply-To: References: <6f9b132612be315eb846b50e37449fad@earthlink.net> Message-ID: <6ef80fcffb5f5f9ac01185e4d4d857bf@earthlink.net> On Feb 24, 2005, at 10:30 PM, Charles PARNOT wrote: > I think what John means is that in BCSymbol, -complement can return > self: > - (id)complement > { > return self; > } > > > and BCSymbolNucleotide would override this and have an ivar > 'complement' to cache the result. > > It makes more sense, actually, because then it really takes advantage > of the superclass-subclass design, where more specialized subclasses > override superclass methods. > > Ah, yes, that would indeed be the best approach. - Koen. From charles.parnot at stanford.edu Fri Feb 25 13:06:43 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 25 Feb 2005 10:06:43 -0800 Subject: [Biococoa-dev] Updating Nib files, etc. In-Reply-To: <74e26c032761dc33b258bbbf554abf37@earthlink.net> References: <74e26c032761dc33b258bbbf554abf37@earthlink.net> Message-ID: >Eh? I am not sure what you mean. Are the permissions wrong in cvs? My question was, I updated the nib file using cvs on the command line, do you now see the changes in the demo that should now use the BCSequenceView? > >- Koen. Oups... Sorry I quoted the wrong part of the message. I meant: At 21:52 -0500 2/24/05, Koen van der Drift wrote: >Hahahaha. Did you know that from cvsroot you can also cd into the other projects, and into the html files from Bioinformatics.org? with read/write permissions?? charles NB: and I did not test the Translation demo. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From jtimmer at bellatlantic.net Fri Feb 25 19:23:03 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Fri, 25 Feb 2005 19:23:03 -0500 Subject: [Biococoa-dev] Update In-Reply-To: Message-ID: Okay, I'm ready to do a major update. I've created BCNucleotides as symbols and BCSequenceNucleotides. I've modified the corresponding BCSequence and Symbol subclasses for DNA and RNA. I've modified BCSymbol to move complementation down to the subclass, while adding "isCompoundSymbol" to it. I added "containsCompoundSymbols" to BCAbstractSequence accordingly. I had to modify the Complement tool - if its sequence is a protein, it returns a copy of that protein (in keeping with Koen's idea of returning "self" when it can't return anything else). If it's not, it uses BCNucleotides to create the complement. I can't guarantee everything's working properly, but the translation demo doesn't crash (though it produces a very short peptide, so it may not be working perfectly). Any objections before I commit this? I may not be done with rationalizing things up from the subclasses, but I think the worst of it is now done. I won't commit until I hear from Charles and Koen, who seem to be working the most on things right now. Cheers, John _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Fri Feb 25 19:32:40 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 25 Feb 2005 16:32:40 -0800 Subject: [Biococoa-dev] Update In-Reply-To: References: Message-ID: At 19:23 -0500 2/25/05, John Timmer wrote: >Okay, I'm ready to do a major update. I've created BCNucleotides as symbols >and BCSequenceNucleotides. I've modified the corresponding BCSequence and >Symbol subclasses for DNA and RNA. I've modified BCSymbol to move >complementation down to the subclass, while adding "isCompoundSymbol" to it. >I added "containsCompoundSymbols" to BCAbstractSequence accordingly. > >I had to modify the Complement tool - if its sequence is a protein, it >returns a copy of that protein (in keeping with Koen's idea of returning >"self" when it can't return anything else). If it's not, it uses >BCNucleotides to create the complement. > >I can't guarantee everything's working properly, but the translation demo >doesn't crash (though it produces a very short peptide, so it may not be >working perfectly). > >Any objections before I commit this? I may not be done with rationalizing >things up from the subclasses, but I think the worst of it is now done. I >won't commit until I hear from Charles and Koen, who seem to be working the >most on things right now. > >Cheers, > >John > Go ahead! It is a useful addition, and we will just work out te bugs. While you and Koen are on, about me going ahead with the test framework? The main point is I will need to upgrade the cross-development level to 10.3 in the project settings, which means target that we want to be compiled for 10.2.8 deployment will have to be upgraded to 'native target', which means the project won't work with Project Builder, and everyone needs to use Xcode. This is probably already the case? Koen, John, I know you are here?? The others?? Who is STILL using Project Builder? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From jtimmer at bellatlantic.net Fri Feb 25 19:34:34 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Fri, 25 Feb 2005 19:34:34 -0500 Subject: [Biococoa-dev] Update In-Reply-To: Message-ID: I'm on Xcode, so no problems here. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Fri Feb 25 19:38:24 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 25 Feb 2005 19:38:24 -0500 Subject: [Biococoa-dev] Update In-Reply-To: References: Message-ID: On Feb 25, 2005, at 7:23 PM, John Timmer wrote: > Okay, I'm ready to do a major update. I've created BCNucleotides as > symbols > and BCSequenceNucleotides. I've modified the corresponding BCSequence > and > Symbol subclasses for DNA and RNA. I've modified BCSymbol to move > complementation down to the subclass, while adding "isCompoundSymbol" > to it. > I added "containsCompoundSymbols" to BCAbstractSequence accordingly. > > I had to modify the Complement tool - if its sequence is a protein, it > returns a copy of that protein (in keeping with Koen's idea of > returning > "self" when it can't return anything else). If it's not, it uses > BCNucleotides to create the complement. That was actually Charles' idea ;-) > > I can't guarantee everything's working properly, but the translation > demo > doesn't crash (though it produces a very short peptide, so it may not > be > working perfectly). It already does that, maybe we should a different DNA sequence? > > Any objections before I commit this? I may not be done with > rationalizing > things up from the subclasses, but I think the worst of it is now > done. I > won't commit until I hear from Charles and Koen, who seem to be > working the > most on things right now. No objections from me. - Koen. From kvddrift at earthlink.net Fri Feb 25 21:05:02 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 25 Feb 2005 21:05:02 -0500 Subject: [Biococoa-dev] BCSequenceView Message-ID: <0ffa67f4b9db7861cf78ee89826d10ad@earthlink.net> Hi, I copied most of the code in BCSequenceView from an app that I develop (and which already uses part of BioCocoa). In my app the sequence is displayed with a whitespace every 10 characters. Without thinking I copied that code also to BCSequenceView (in the updateLayout method), and found that it is not working. It took some time to realize why, and that is that in my app, the view is coupled to a controller. The controller is notified by a textDidChange notification, and in turn sends it a message to the view to update the layout. Of course I can add that code to the controller in the demo app, but that would make BCSequenceView dependent on another object that is outside the framework. So I added the textDidChange method directly to BCSequenceView, although this catually is a method for the delegate. Indeed the whitespaces are now added and updated when editing the text. The only problem now is that I cannot put the cursor in the middle of the text. New characters are only added to the end of the text. Any ideas what might be going on and how to fix it without using a delegate object? thanks, - Koen. From charles.parnot at stanford.edu Sat Feb 26 01:45:32 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Fri, 25 Feb 2005 22:45:32 -0800 Subject: [Biococoa-dev] BCFoundation-Tests Message-ID: OK, I did it. I added a new target called 'BCFoundation-Tests'. All the files for it are nicely grouped in the Xcode project, inside BCFoundation/Tests, and same thing for the filesystem ;-) To try the tests: * install OCUnit at the root level: http://www.sente.ch/software/ocunit/#Download (choose OCUnitRoot-v39.dmg and install) * cvs update -d (because of the new folders in the filesystem...) * choose the new target in the target popup menu * compile button: after compiling and linking, a script runs the tests; if no test fail, you get no message * run button: this will also run the tests, with some logs; in other words, there are 2 ways to run the tests; this second way runs the executable 'otest' with the test framework as argument. I had to change the 'Cross-Develop using Target SDK' to Mac OS X.3. After a quick survey of three individuals (Koen, John and me), I found that 100% of the developers use Xcode, so we can upgrade the other targets. It seems Alex has some experience with that, so I will wait for his input, because there is no easy way back to the old target format (contrary to what I did so far, which is easily reversible). As a result, it seems you should clean the other targets before recompiling if you modify the code. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From kvddrift at earthlink.net Sat Feb 26 07:27:19 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 07:27:19 -0500 Subject: [Biococoa-dev] Update In-Reply-To: References: Message-ID: <8dbe9500045eb3a860442cb40a696861@earthlink.net> On Feb 25, 2005, at 7:23 PM, John Timmer wrote: > I can't guarantee everything's working properly, but the translation > demo > doesn't crash (though it produces a very short peptide, so it may not > be > working perfectly). > Thanks for committing the code, John. A few initial comments: - BCNucleotide should call it's super method in initializeComplementRelationships, otherwise the 'represents' etc never gets set up. - should BCNucleotide have a copyWithZone method? - in the Complement tool, maybe you should check if the sequence is DNA or RNA, instead of protein? Later on we might have other sequence types (carbohydrates, for instance). - Koen. From kvddrift at earthlink.net Sat Feb 26 08:07:09 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 08:07:09 -0500 Subject: [Biococoa-dev] BCFoundation-Tests In-Reply-To: References: Message-ID: <27965339f38d3f269a0eeaeee9450c46@earthlink.net> On Feb 26, 2005, at 1:45 AM, Charles PARNOT wrote: > * choose the new target in the target popup menu Not sure if this is important, but why does the test framework have a different Target icon (toolbox instead of red circles)? > I had to change the 'Cross-Develop using Target SDK' to Mac OS X.3. > After a quick survey of three individuals (Koen, John and me), I found > that 100% of the developers use Xcode, so we can upgrade the other > targets. It seems Alex has some experience with that, so I will wait > for his input, because there is no easy way back to the old target > format (contrary to what I did so far, which is easily reversible). So are we now dropping 10.2.8 support? Maybe only the test framework can be 10.3 and the rest 10.2.8? - Koen. From kvddrift at earthlink.net Sat Feb 26 08:09:41 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 08:09:41 -0500 Subject: [Biococoa-dev] Update In-Reply-To: <8dbe9500045eb3a860442cb40a696861@earthlink.net> References: <8dbe9500045eb3a860442cb40a696861@earthlink.net> Message-ID: <1546252759f757b4dcad2c09ec99fc67@earthlink.net> On Feb 26, 2005, at 7:27 AM, Koen van der Drift wrote: > Thanks for committing the code, John. A few initial comments: > > - BCNucleotide should call it's super method in > initializeComplementRelationships, otherwise the 'represents' etc > never gets set up. > - should BCNucleotide have a copyWithZone method? > - in the Complement tool, maybe you should check if the sequence is > DNA or RNA, instead of protein? Later on we might have other sequence > types (carbohydrates, for instance). > > Oh, one more thing, I guess the complement lines in the headers of BCSequenceRNA and BCSequenceDNA can be removed, because it is already in their super? cheers, - Koen. From kvddrift at earthlink.net Sat Feb 26 09:59:24 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 09:59:24 -0500 Subject: [Biococoa-dev] Update In-Reply-To: References: Message-ID: <0e97c0932e51f38770b3d1342d0dbbe6@earthlink.net> On Feb 26, 2005, at 8:52 AM, John Timmer wrote: > Incidentally, I never liked that implementation (even though I put it > there) > because I don't entirely understand memory zones. Neither do I :-) I noticed it in the other class, so I assumed it should be in the new class as well. - Koen. From jtimmer at bellatlantic.net Sat Feb 26 10:10:54 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sat, 26 Feb 2005 10:10:54 -0500 Subject: [Biococoa-dev] Update In-Reply-To: <8dbe9500045eb3a860442cb40a696861@earthlink.net> Message-ID: Koen - You're right on all counts except possibly this one: > - should BCNucleotide have a copyWithZone method? Since the BCSymbol copyWithZone method returns self in order to keep these things singletons, the super's method should work nicely. Incidentally, I never liked that implementation (even though I put it there) because I don't entirely understand memory zones. Is the self likely to be a problem? Nobody knew the last time I brought this up, but we've got some fresh blood around... I've got to go into work later today, and I'll implement your suggested changes when I get there. JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Sat Feb 26 10:20:53 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sat, 26 Feb 2005 10:20:53 -0500 Subject: [Biococoa-dev] Update In-Reply-To: <8dbe9500045eb3a860442cb40a696861@earthlink.net> Message-ID: Okay, Koen's suggested fixes are now in place, along with a few others. One key difference is that I've now separated base representations and complementation. This is relevant to the following: > - BCNucleotide should call it's super method in > initializeComplementRelationships, otherwise the 'represents' etc never > gets set up. Now, BCSymbol has the methods that handle representing multiple symbols, and these relationships are initialized in that class as needed. BCNucleotide has the complements, and they're initialized there as needed. So, in the end, there's not a need to call super - you can do a complement without knowing the representations and vice versa. Next up, I'd like to start cleaning up the mess I put in place in the translation code. I know Koen's done some tweaking there, but some of it still looks almost as bad as when I wrote it, and I'd imagine it's not been updated to handle BCAbstractSequences. Has anyone who's looked it over recently got any suggestions as to priorities or necessities? JT _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Sat Feb 26 10:55:12 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 26 Feb 2005 07:55:12 -0800 Subject: [Biococoa-dev] Update In-Reply-To: References: Message-ID: At 10:10 AM -0500 2/26/05, John Timmer wrote: >Koen - > >You're right on all counts except possibly this one: > >> - should BCNucleotide have a copyWithZone method? > >Since the BCSymbol copyWithZone method returns self in order to keep these >things singletons, the super's method should work nicely. > >Incidentally, I never liked that implementation (even though I put it there) >because I don't entirely understand memory zones. Is the self likely to be >a problem? Nobody knew the last time I brought this up, but we've got some >fresh blood around... > >I've got to go into work later today, and I'll implement your suggested >changes when I get there. > >JT the copy should do: { return [self retain]; } because copy returns by convention a retained object and the caller is in charge of releasing it. If you don't retain it and the caller releases the copy, the object is gone! The zone is not an issue here, because you return self. It is supposed to be useful if you create a object and want to keep the ivar objects in the same zone, supposedly for efficient memory management. I will try to think about the translation too this week-end! charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From charles.parnot at stanford.edu Sat Feb 26 10:59:51 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 26 Feb 2005 07:59:51 -0800 Subject: [Biococoa-dev] BCFoundation-Tests In-Reply-To: <27965339f38d3f269a0eeaeee9450c46@earthlink.net> References: <27965339f38d3f269a0eeaeee9450c46@earthlink.net> Message-ID: >On Feb 26, 2005, at 1:45 AM, Charles PARNOT wrote: > >>* choose the new target in the target popup menu > >Not sure if this is important, but why does the test framework have a different Target icon (toolbox instead of red circles)? It is because it is a 'native target' = new format introduced with Xcode The other targets are 'legacy targets' = format compatible with Project Builder. > >>I had to change the 'Cross-Develop using Target SDK' to Mac OS X.3. After a quick survey of three individuals (Koen, John and me), I found that 100% of the developers use Xcode, so we can upgrade the other targets. It seems Alex has some experience with that, so I will wait for his input, because there is no easy way back to the old target format (contrary to what I did so far, which is easily reversible). > > >So are we now dropping 10.2.8 support? Maybe only the test framework can be 10.3 and the rest 10.2.8? I knew this was going to be confusing! The way I understand it is that only 'native targets' can be set to a different deployement OS X target. Hence my question about upgrading the legacy targets to native targets. I want to wait for Alex's input before upgrading because this is a no-return process, and I want to make sure this is the way he was thinking of doing it for Foundation (10.2) and AppKit (10.3). charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Sat Feb 26 12:27:11 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 26 Feb 2005 18:27:11 +0100 Subject: [Biococoa-dev] BCFoundation-Tests In-Reply-To: References: <27965339f38d3f269a0eeaeee9450c46@earthlink.net> Message-ID: >> So are we now dropping 10.2.8 support? Maybe only the test framework >> can be 10.3 and the rest 10.2.8? > > I knew this was going to be confusing! > The way I understand it is that only 'native targets' can be set to a > different deployement OS X target. Hence my question about upgrading > the legacy targets to native targets. I want to wait for Alex's input > before upgrading because this is a no-return process, and I want to > make sure this is the way he was thinking of doing it for Foundation > (10.2) and AppKit (10.3). Sorry guys, little time today. My experience is that converting the target to a native XCode format does prevent you from opening the file in Project Builder (no problem for me). The nice thing is that it STILL allows you to build against the 10.2.8 SDK, so no we won't move to 10.3 only for the foundation..... Go ahead Charles, it should be no problem. (yes, indeed the target icon will change in an application/framework instead of the red-circle. I'll comment on the other emails later tonight... Great work on the sequence classes guys! Cheers, Alex Ps. unfortunately it seems that the target SDK can only be set for the complete XCode file (using get info on the project icon), we can leave it at 10.2.8 for the moment, we'll see what the future brings. Converting to a native target has nothing to do with this though, so forms no problem. > > charles > > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From kvddrift at earthlink.net Sat Feb 26 13:15:34 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 13:15:34 -0500 Subject: [Biococoa-dev] Update In-Reply-To: References: Message-ID: <99bd89ff41cec9ca504e8ac0fe34d55c@earthlink.net> On Feb 26, 2005, at 10:20 AM, John Timmer wrote: > Now, BCSymbol has the methods that handle representing multiple > symbols, and > these relationships are initialized in that class as needed. > BCNucleotide > has the complements, and they're initialized there as needed. So, in > the > end, there's not a need to call super - you can do a complement without > knowing the representations and vice versa. > But what if I want to know both the complement and the representations? I don't see any reason not to call the super method, as is the purpose of inheritance. - Koen. From jtimmer at bellatlantic.net Sat Feb 26 13:56:58 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sat, 26 Feb 2005 13:56:58 -0500 Subject: [Biococoa-dev] Update In-Reply-To: <99bd89ff41cec9ca504e8ac0fe34d55c@earthlink.net> Message-ID: > But what if I want to know both the complement and the representations? > I don't see any reason not to call the super method, as is the purpose > of inheritance. It really doesn't matter that much - they'd both be created as soon as they are needed. You're welcome to change it to call super, if you'd prefer it that way. There will be a very slight performance decrease if you only want one or the other, but I'm quite certain it would be negligible. As for inheritance, it could be argued either way. If you view representations and complements as essentially the same thing (ie - relationships between symbols), then yes, the method should call super. If you view them as separate features (ie - complement reflects actual biology, representations reflect human designated abbreviations), then the design as it now stands is appropriately modular. As you can tell, I don't really care that much ;). Please change it and commit the change if you do care. Cheers, JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Sat Feb 26 14:32:32 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sat, 26 Feb 2005 14:32:32 -0500 Subject: [Biococoa-dev] Translation Message-ID: Okay, for translation, I think we're going to need three instance variables and their setter/getter methods; - (int) readingFrame; - (void) setReadingFrame: (int)theFrame; - (BCGeneticCodeName) codeName; - (void)setCodeName: (BCGeneticCodeName)aName; - (BCAbstractSequence *) sequence; - (void) setSequence: (BCAbstractSequence *)theSequence; Again, I'll check the sequence type prior to translating and return [sequence copy] if it's not DNA or RNA. One thing I'm thinking of doing: changing the genetic code so that it doesn't specify sequence type. Since we're going to be testing the sequence type, there really isn't a reason to specify whether to use DNA or RNA for the translation. In fact, not specifying them should allow us to avoid the possibility of a code/sequence mismatch error. So, instead of looking up "BCUniversalGeneticCodeDNA", we would have a method like: geneticCode: BCUniversalGeneticCode forSequenceType: BCDNASequenceType Does this sound reasonable? Have I missed something? JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Sat Feb 26 14:52:55 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 14:52:55 -0500 Subject: [Biococoa-dev] Update In-Reply-To: References: Message-ID: On Feb 26, 2005, at 1:56 PM, John Timmer wrote: > t really doesn't matter that much - they'd both be created as soon as > they > are needed. You're welcome to change it to call super, if you'd > prefer it > that way. There will be a very slight performance decrease if you > only want > one or the other, but I'm quite certain it would be negligible. > > As for inheritance, it could be argued either way. If you view > representations and complements as essentially the same thing (ie - > relationships between symbols), then yes, the method should call > super. If > you view them as separate features (ie - complement reflects actual > biology, > representations reflect human designated abbreviations), then the > design as > it now stands is appropriately modular. > Aah, but you renamed the method in BCNucleotide from initializeSymbolRelationships to initializeComplementRelationships :-) In that case there is no need to call the super method. I assumed the method in BCNucleotide would still be initializeSymbolRelationships, in which case the super has to be called. - Koen. From charles.parnot at stanford.edu Sat Feb 26 15:12:18 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 26 Feb 2005 12:12:18 -0800 Subject: [Biococoa-dev] BCFoundation-Tests In-Reply-To: References: <27965339f38d3f269a0eeaeee9450c46@earthlink.net> Message-ID: At 6:27 PM +0100 2/26/05, Alexander Griekspoor wrote: >>>So are we now dropping 10.2.8 support? Maybe only the test >>>framework can be 10.3 and the rest 10.2.8? >> >>I knew this was going to be confusing! >>The way I understand it is that only 'native targets' can be set to >>a different deployement OS X target. Hence my question about >>upgrading the legacy targets to native targets. I want to wait for >>Alex's input before upgrading because this is a no-return process, >>and I want to make sure this is the way he was thinking of doing it >>for Foundation (10.2) and AppKit (10.3). > >Sorry guys, little time today. My experience is that converting the >target to a native XCode format does prevent you from opening the >file in Project Builder (no problem for me). The nice thing is that >it STILL allows you to build against the 10.2.8 SDK, so no we won't >move to 10.3 only for the foundation..... Go ahead Charles, it >should be no problem. (yes, indeed the target icon will change in an >application/framework instead of the red-circle. I'll comment on the >other emails later tonight... Great work on the sequence classes >guys! >Cheers, >Alex > >Ps. unfortunately it seems that the target SDK can only be set for >the complete XCode file (using get info on the project icon), we can >leave it at 10.2.8 for the moment, we'll see what the future brings. >Converting to a native target has nothing to do with this though, so >forms no problem. The problem is the OCUnit needs the Mac OS X deployment target in the build settings to be set to X.3, otherwise I get the compiler message: `-fobjc-exceptions' ignored because MACOSX_DEPLOYMENT_TARGET is "10.2" It works fine for now, but may not behave properly if a method throws an exception. Now, there is one thing I don't understand very well the differences between the two following settings: * Cross-Develop using Target SDK in the project General settings * Mac OS X deployment target in the build settings of individual targets Maybe the first is only for the headers used by the compiler and the headers, and the second is for the linking. In fact, the way it is setup now, the SDK may not even be taken into account, according to Apple's documentation, because we are using a non-native target. This is the warning that you should be able to see on this file on your computer (Apple's doc): file:///Developer/Applications/Xcode.app/Contents/Resources/English.lproj/Xcode_Help/Building/chapter_6_section_10.html So, we think we are using the 10.2.8 SDK but we are probably not if our machines are on 10.3!! So updating to a native target seems in fact necessary if we want to use the 10.2.8 SDK. Anyway, if we want to have different targets compatible with different OS X versions, we have to find a way to do it. It seems the prefix header is where the action is. I will try to read more about this. charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvddrift at earthlink.net Sat Feb 26 20:20:45 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 20:20:45 -0500 Subject: [Biococoa-dev] Translation In-Reply-To: References: Message-ID: On Feb 26, 2005, at 2:32 PM, John Timmer wrote: > - (BCAbstractSequence *) sequence; > - (void) setSequence: (BCAbstractSequence *)theSequence; > FYI, because BCToolTranslatorDNA now is a subclass of BCSequenceTool, the accessor methods for the sequence are already in place. - Koen. From kvddrift at earthlink.net Sat Feb 26 23:17:08 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 26 Feb 2005 23:17:08 -0500 Subject: [Biococoa-dev] Digest tool Message-ID: <2ad2f9bc2f6b471d065d634e9655249d@earthlink.net> Hi, I am going to work on the BCToolDigest class and need some feedback from the DNA/RNA folks. I already have code to digest a protein, and can add that without much problems. However, I would like to try to make the class as universal as possible, so it should also work for DNA and RNA. The code that I already have will digest a protein, based on information of an enzyme that is stored in a plist file. An example is: Trypsin CleaveAt KR DontCleaveAdjacentTo P CleaveDirection C So it defines the name of the enzyme in the key, and then identifies where to cleave the protein, in this case at a lysine or arginine residue. The string can contain more than one residues. It also adds the possibility to define a residue that inhibits the cleavage if it is adjacent to the given residue(s). Finally it defines on which side of the residue to cleave. So my question is, when digesting an DNA/RNA, can I use a similar approach? I have absolutely no clue about the digestion of DNA/RNA, so the mechanism could well be completely different. In that case additional class needs to be written, and maybe a super class to hold code that is in common. The result of the code I already have is an array of subsequences. Will the result of a DNA/RNA digest be similar? thanks, - Koen. From charles.parnot at stanford.edu Sun Feb 27 02:17:13 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sat, 26 Feb 2005 23:17:13 -0800 Subject: [Biococoa-dev] Xcode settings for cross-development In-Reply-To: References: <27965339f38d3f269a0eeaeee9450c46@earthlink.net> Message-ID: OK, I just read the docs and I understand much better now. * The SDK is chosen in the project settings. It applies to all the targets in the project. The SDK is used to compilation and linking; for instance, if you use NSIndexSet with SDK = 10.2.8, you get a compiler error, because it is not found in . In fact, the header being used is in /Developer/SDKs/MacOSX.2.8.sdk and not the one on your system, that's why. This is set with the environment variable SDKROOT. * The Mac OS X Deployment target, however. can be set for each individual target. This is a different setting, which sets on which version the code will run. If you choose 10.2, your code will load in 10.2 and higher. However, it does not mean it will run without crashes. For instance, if you were using the 10.3 SDK, and used NSIndexSet somewhere in your code, you don't get compiler warning, the program loads and runs fine until it hits that piece of code and then the program may crash when run on 10.2 (basically NSIndexSet is replaced with nil). Maybe you still want to use NSIndexSet, but only when running on X.3, and simply skip the code when running 10.2 (the app then misses some features). To allow that, you can dynamically check the version at runtime and only run the code using NSIndexSet if the system is 10.3+. * I repeat: you can have the SDK set to 10.3 and still have code that loads fine in 10.2 if the Deployement target is set to 10.2. AS long as you don't use APIs specific for 10.3, the code will run fine. * However, you cannot have the SDK set to 10.2 and the Deployement target to 10.3. The compilation will fail early. * The way the project is set now, the SDK chosen in the project settings is 10.2.8 but it is actually NOT used for the BioCocoa.framework build!! The BioCocoa framework still uses the 10.3 APIs despite that setting because it is an old format target and does not recognize the SDKROOT environment variable. For instance, I tried to define an NSIndexSet * variable in the BioCocoa code with the SDK set to 10.2.8, and I had no compilation error!! This is because the targets are old-format. If you do the same with the new target I added, which is in the new format, you DO get a compilation error, telling you that NSIndexSet is undefined. Bottom line: we should update all the targets to native format to take into account the SDKs and get the compilation warnings as appropriate. * New format target = 'native target' won't open in Project Builder. This won't be a problem as everybody seems to be using Xcode (at least Alex, John, Koen and me). * OCUnit works best with X.3-only frameworks because it uses the latest exception handling system. This does not mean the framework being tested need to be 10.3 only. Only the test framework needs to be X.3 only. In other words, the target 'BioCocoa' can be 10.2+, and the target 'BCFoundation-Tests' should be 10.3+. So the SDK has to be set to 10.3 to be able to compile the test framework... But then the SDKs will also be 10.3 for the BioCocoa framework... The bottom line is: * We may have to set the SDK to 10.3 because of the test framework * I may find a way around it * We will probably have to set the SDK to 10.3 at some point (e.g. for the BCAppKit --> bindings) * Setting the SDK to 10.3 will not prevent the BioCocoa framework to load and run in 10.2.8, but we will not get compiler warnings if using APIs 10.3-only. For instance, if somebody uses NSIndexSet, there won't be any compiler warning. * Future versions of Xcode might address that limitation. Last update: I just found a very simple solution to have one SDK per target: add an SDKROOT entry to the build settings. For instance, I set the SDK to 10.2.8 in the project and set SDKROOT to '/Developer/SDKs/MacOSX.3.0.sdk' in the target 'BCFoundation-Tests' and it ignored the project settings and compiled fine!!! An alternative is to even set SDKROOT to '/', in other words use the APIs of the current computer, which is 10.3 in my case (so I get the 10.3.8 APIS, and not just 10.3.0 if that makes any difference). Yeehouu!! I will be able to sleep tonight!!! If anybody read all the way to here, let me know if something is still unclear ;-) charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Sun Feb 27 07:46:15 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 27 Feb 2005 13:46:15 +0100 Subject: [Biococoa-dev] Xcode settings for cross-development In-Reply-To: References: <27965339f38d3f269a0eeaeee9450c46@earthlink.net> Message-ID: <61afd01c967b77e35dde5368a1a2b5a9@mekentosj.com> Very well explained Charles, great news! Go ahead and change the project SDK to 10.3 and add the 10.2.8 SDKRoot environment variable for the foundation... Cheers, Alex On 27-feb-05, at 8:17, Charles PARNOT wrote: > OK, I just read the docs and I understand much better now. > > * The SDK is chosen in the project settings. It applies to all the > targets in the project. The SDK is used to compilation and linking; > for instance, if you use NSIndexSet with SDK = 10.2.8, you get a > compiler error, because it is not found in . In fact, > the header being used is in /Developer/SDKs/MacOSX.2.8.sdk and not the > one on your system, that's why. This is set with the environment > variable SDKROOT. > > * The Mac OS X Deployment target, however. can be set for each > individual target. This is a different setting, which sets on which > version the code will run. If you choose 10.2, your code will load in > 10.2 and higher. However, it does not mean it will run without > crashes. For instance, if you were using the 10.3 SDK, and used > NSIndexSet somewhere in your code, you don't get compiler warning, the > program loads and runs fine until it hits that piece of code and then > the program may crash when run on 10.2 (basically NSIndexSet is > replaced with nil). Maybe you still want to use NSIndexSet, but only > when running on X.3, and simply skip the code when running 10.2 (the > app then misses some features). To allow that, you can dynamically > check the version at runtime and only run the code using NSIndexSet if > the system is 10.3+. > > * I repeat: you can have the SDK set to 10.3 and still have code that > loads fine in 10.2 if the Deployement target is set to 10.2. AS long > as you don't use APIs specific for 10.3, the code will run fine. > > * However, you cannot have the SDK set to 10.2 and the Deployement > target to 10.3. The compilation will fail early. > > * The way the project is set now, the SDK chosen in the project > settings is 10.2.8 but it is actually NOT used for the > BioCocoa.framework build!! The BioCocoa framework still uses the 10.3 > APIs despite that setting because it is an old format target and does > not recognize the SDKROOT environment variable. > For instance, I tried to define an NSIndexSet * variable in the > BioCocoa code with the SDK set to 10.2.8, and I had no compilation > error!! This is because the targets are old-format. If you do the same > with the new target I added, which is in the new format, you DO get a > compilation error, telling you that NSIndexSet is undefined. > Bottom line: we should update all the targets to native format to take > into account the SDKs and get the compilation warnings as appropriate. > > * New format target = 'native target' won't open in Project Builder. > This won't be a problem as everybody seems to be using Xcode (at least > Alex, John, Koen and me). > > * OCUnit works best with X.3-only frameworks because it uses the > latest exception handling system. This does not mean the framework > being tested need to be 10.3 only. Only the test framework needs to be > X.3 only. In other words, the target 'BioCocoa' can be 10.2+, and the > target 'BCFoundation-Tests' should be 10.3+. So the SDK has to be set > to 10.3 to be able to compile the test framework... But then the SDKs > will also be 10.3 for the BioCocoa framework... > > > The bottom line is: > > * We may have to set the SDK to 10.3 because of the test framework > > * I may find a way around it > > * We will probably have to set the SDK to 10.3 at some point (e.g. for > the BCAppKit --> bindings) > > * Setting the SDK to 10.3 will not prevent the BioCocoa framework to > load and run in 10.2.8, but we will not get compiler warnings if using > APIs 10.3-only. For instance, if somebody uses NSIndexSet, there won't > be any compiler warning. > > * Future versions of Xcode might address that limitation. > > > Last update: > I just found a very simple solution to have one SDK per target: add an > SDKROOT entry to the build settings. For instance, I set the SDK to > 10.2.8 in the project and set SDKROOT to > '/Developer/SDKs/MacOSX.3.0.sdk' in the target 'BCFoundation-Tests' > and it ignored the project settings and compiled fine!!! An > alternative is to even set SDKROOT to '/', in other words use the APIs > of the current computer, which is 10.3 in my case (so I get the 10.3.8 > APIS, and not just 10.3.0 if that makes any difference). > Yeehouu!! I will be able to sleep tonight!!! > > If anybody read all the way to here, let me know if something is still > unclear ;-) > > charles > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From mek at mekentosj.com Sun Feb 27 07:55:00 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 27 Feb 2005 13:55:00 +0100 Subject: [Biococoa-dev] Digest tool In-Reply-To: <2ad2f9bc2f6b471d065d634e9655249d@earthlink.net> References: <2ad2f9bc2f6b471d065d634e9655249d@earthlink.net> Message-ID: <89dc18375112d444add00fa3b2d72889@mekentosj.com> Hmm, in principle there are many similarities so yes, we should try to make it work with DNA as well (don't know much about RNA cutting enzymes and their specificity... Don't want to sound to commercial (well, it's freeware anyway), but perhaps you can download our program EnzymeX (http://www.mekentosj.com/enzymex ) and play a bit with it. Also, Tom added in the help files quite some info on how these enzymes work. Finally, we have added a piece on our website about it: http://www.mekentosj.com/enzymex/science.html Some potential pitfalls we have to foresee in the method: - DNA has two strands and enzymes can both generate blunt ends and overhangs (cut different position in the forward and reverse strand, see the picture of the enzyme sequence in enzymeX). - Far more than is the case in peptide cleavage, ambiguity place a major role in DNA restriction enzymes: i.e. enzymes like EaeI that recognises: y^GGCCr - DNA can be circular, meaning that one has to account for potential cuts in the connecting segment if circularity is the case - Later on we can add the problem of methylation sensitivity, but that's way more advanced. I know John has created a DNA digestion plugin for 4Peaks, so he can tell you more probably. I'll send you the source off-list... Cheers, Alex On 27-feb-05, at 5:17, Koen van der Drift wrote: > Hi, > > I am going to work on the BCToolDigest class and need some feedback > from the DNA/RNA folks. I already have code to digest a protein, and > can add that without much problems. However, I would like to try to > make the class as universal as possible, so it should also work for > DNA and RNA. The code that I already have will digest a protein, based > on information of an enzyme that is stored in a plist file. An example > is: > > Trypsin > > CleaveAt > KR > DontCleaveAdjacentTo > P > CleaveDirection > C > > > So it defines the name of the enzyme in the key, and then identifies > where to cleave the protein, in this case at a lysine or arginine > residue. The string can contain more than one residues. It also adds > the possibility to define a residue that inhibits the cleavage if it > is adjacent to the given residue(s). Finally it defines on which side > of the residue to cleave. > > So my question is, when digesting an DNA/RNA, can I use a similar > approach? I have absolutely no clue about the digestion of DNA/RNA, so > the mechanism could well be completely different. In that case > additional class needs to be written, and maybe a super class to hold > code that is in common. > > The result of the code I already have is an array of subsequences. > Will the result of a DNA/RNA digest be similar? > > thanks, > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* From mek at mekentosj.com Sun Feb 27 07:58:03 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 27 Feb 2005 13:58:03 +0100 Subject: Fwd: [Biococoa-dev] Digest tool Message-ID: Correction, I only have the binary of the restrictionmapper plugin John wrote, not the source. Perhaps he can send you the source (and me, because I would like to have the source as well ;-). John? Cheers, Alex Begin forwarded message: > From: Alexander Griekspoor > Date: 27 februari 2005 13:55:00 GMT+01:00 > To: Koen van der Drift > Cc: BioCocoa Mailinglist > Subject: Re: [Biococoa-dev] Digest tool > > Hmm, in principle there are many similarities so yes, we should try to > make it work with DNA as well (don't know much about RNA cutting > enzymes and their specificity... > Don't want to sound to commercial (well, it's freeware anyway), but > perhaps you can download our program EnzymeX > (http://www.mekentosj.com/enzymex ) and play a bit with it. Also, Tom > added in the help files quite some info on how these enzymes work. > Finally, we have added a piece on our website about it: > http://www.mekentosj.com/enzymex/science.html > Some potential pitfalls we have to foresee in the method: > - DNA has two strands and enzymes can both generate blunt ends and > overhangs (cut different position in the forward and reverse strand, > see the picture of the enzyme sequence in enzymeX). > - Far more than is the case in peptide cleavage, ambiguity place a > major role in DNA restriction enzymes: i.e. enzymes like EaeI that > recognises: y^GGCCr > - DNA can be circular, meaning that one has to account for potential > cuts in the connecting segment if circularity is the case > - Later on we can add the problem of methylation sensitivity, but > that's way more advanced. > I know John has created a DNA digestion plugin for 4Peaks, so he can > tell you more probably. I'll send you the source off-list... > Cheers, > Alex > > On 27-feb-05, at 5:17, Koen van der Drift wrote: > >> Hi, >> >> I am going to work on the BCToolDigest class and need some feedback >> from the DNA/RNA folks. I already have code to digest a protein, and >> can add that without much problems. However, I would like to try to >> make the class as universal as possible, so it should also work for >> DNA and RNA. The code that I already have will digest a protein, >> based on information of an enzyme that is stored in a plist file. An >> example is: >> >> Trypsin >> >> CleaveAt >> KR >> DontCleaveAdjacentTo >> P >> CleaveDirection >> C >> >> >> So it defines the name of the enzyme in the key, and then identifies >> where to cleave the protein, in this case at a lysine or arginine >> residue. The string can contain more than one residues. It also adds >> the possibility to define a residue that inhibits the cleavage if it >> is adjacent to the given residue(s). Finally it defines on which side >> of the residue to cleave. >> >> So my question is, when digesting an DNA/RNA, can I use a similar >> approach? I have absolutely no clue about the digestion of DNA/RNA, >> so the mechanism could well be completely different. In that case >> additional class needs to be written, and maybe a super class to hold >> code that is in common. >> >> The result of the code I already have is an array of subsequences. >> Will the result of a DNA/RNA digest be similar? >> >> thanks, >> >> - Koen. >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev >> >> > ********************************************************* > ** Alexander Griekspoor ** > ********************************************************* > The Netherlands Cancer Institute > Department of Tumorbiology (H4) > Plesmanlaan 121, 1066 CX, Amsterdam > Tel: + 31 20 - 512 2023 > Fax: + 31 20 - 512 2029 > AIM: mekentosj at mac.com > E-mail: a.griekspoor at nki.nl > Web: http://www.mekentosj.com > > Claiming that the Macintosh is inferior to Windows > because most people use Windows, is like saying > that all other restaurants serve food that is > inferior to McDonalds > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5375 bytes Desc: not available URL: From kvddrift at earthlink.net Sun Feb 27 08:29:42 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 08:29:42 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: <89dc18375112d444add00fa3b2d72889@mekentosj.com> References: <2ad2f9bc2f6b471d065d634e9655249d@earthlink.net> <89dc18375112d444add00fa3b2d72889@mekentosj.com> Message-ID: On Feb 27, 2005, at 7:55 AM, Alexander Griekspoor wrote: > Hmm, in principle there are many similarities so yes, we should try to > make it work with DNA as well (don't know much about RNA cutting > enzymes and their specificity... > Don't want to sound to commercial (well, it's freeware anyway), but > perhaps you can download our program EnzymeX > (http://www.mekentosj.com/enzymex ) and play a bit with it. Also, Tom > added in the help files quite some info on how these enzymes work. > Finally, we have added a piece on our website about it: > http://www.mekentosj.com/enzymex/science.html Thank for the pointers - I'll check it out. > Some potential pitfalls we have to foresee in the method: > - DNA has two strands and enzymes can both generate blunt ends and > overhangs (cut different position in the forward and reverse strand, > see the picture of the enzyme sequence in enzymeX). We should then first think about creating a double stranded BCSequence object in BioCocoa. Once that is in place, we can think about digesting those. > - Far more than is the case in peptide cleavage, ambiguity place a > major role in DNA restriction enzymes: i.e. enzymes like EaeI that > recognises: y^GGCCr Right now I am using an NSScanner to identify the cleavage sites in a sequence string. Then I use those sites to create subsequences. I assume that NSScanner can be used for such ambiguous cases. What approach are you guys using in EnzymeX to find the cleavage sites? BTW is that supposed to be a regular expression? > - DNA can be circular, meaning that one has to account for potential > cuts in the connecting segment if circularity is the case That's a tricky one, but as with the double stranded sequence, until we have circular sequences in BioCocoa probably not so urgent. > - Later on we can add the problem of methylation sensitivity, but > that's way more advanced. > I know John has created a DNA digestion plugin for 4Peaks, so he can > tell you more probably. I'll send you the source off-list... That would be great. - Koen. From mek at mekentosj.com Sun Feb 27 08:40:13 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 27 Feb 2005 14:40:13 +0100 Subject: [Biococoa-dev] Digest tool In-Reply-To: References: <2ad2f9bc2f6b471d065d634e9655249d@earthlink.net> <89dc18375112d444add00fa3b2d72889@mekentosj.com> Message-ID: <5a7be563977acada870858dd3d08b768@mekentosj.com> >> Some potential pitfalls we have to foresee in the method: >> - DNA has two strands and enzymes can both generate blunt ends and >> overhangs (cut different position in the forward and reverse strand, >> see the picture of the enzyme sequence in enzymeX). > > We should then first think about creating a double stranded BCSequence > object in BioCocoa. Once that is in place, we can think about > digesting those. Perhaps yes... But at first we can just ignore the overhang and just return the segments based on the forward sequence only. >> - Far more than is the case in peptide cleavage, ambiguity place a >> major role in DNA restriction enzymes: i.e. enzymes like EaeI that >> recognises: y^GGCCr > > Right now I am using an NSScanner to identify the cleavage sites in a > sequence string. Then I use those sites to create subsequences. I > assume that NSScanner can be used for such ambiguous cases. What > approach are you guys using in EnzymeX to find the cleavage sites? BTW > is that supposed to be a regular expression? I think there still is a necessity to at one point come up with an enumerator and/or scanner for our native sequence objects as well... That aside, yes in the upcoming enzymex (with primitive cutting capabilities, I first use the by now famous enzyme objects, and indeed the opensource AGRegex framework. I have an NSString extension that returns a conventional regex string generated from it's ambiguous recognition string: -(NSString *)convertSequenceToPattern{ int i; NSMutableString* pattern = [NSMutableString stringWithCapacity: [self length]*2]; NSString *ustring = [self uppercaseString]; for(i= 0; i < [ustring length]; i++){ if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"A"]) [pattern appendString: @"A"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"C"]) [pattern appendString: @"C"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"G"]) [pattern appendString: @"G"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"T"]) [pattern appendString: @"T"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @" "]) [pattern appendString: @""]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"W"]) [pattern appendString: @"[AT]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"S"]) [pattern appendString: @"[CG]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"M"]) [pattern appendString: @"[AC]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"K"]) [pattern appendString: @"[GT]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"R"]) [pattern appendString: @"[AG]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"Y"]) [pattern appendString: @"[CT]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"N"]) [pattern appendString: @"."]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"H"]) [pattern appendString: @"[ACT]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"V"]) [pattern appendString: @"[ACG]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"D"]) [pattern appendString: @"[AGT]"]; if([[ustring substringWithRange: NSMakeRange(i,1)] isEqualToString: @"B"]) [pattern appendString: @"[CGT]"]; } return pattern; } But, I know the implementation of John did not use regex, so perhaps you better start with that one... By the way, the problems listed above are from my own list of things to solve before release of the new enzymex ;-) > >> - DNA can be circular, meaning that one has to account for potential >> cuts in the connecting segment if circularity is the case > > That's a tricky one, but as with the double stranded sequence, until > we have circular sequences in BioCocoa probably not so urgent. I'm not sure if we need to have a circular sequence object for this though, you only have to fuse the last and first segment, and also make sure you don't miss any recognition patterns in the begin/end boundary. Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows vs Mac 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 8490 bytes Desc: not available URL: From kvddrift at earthlink.net Sun Feb 27 09:49:00 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 09:49:00 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: <5a7be563977acada870858dd3d08b768@mekentosj.com> References: <2ad2f9bc2f6b471d065d634e9655249d@earthlink.net> <89dc18375112d444add00fa3b2d72889@mekentosj.com> <5a7be563977acada870858dd3d08b768@mekentosj.com> Message-ID: On Feb 27, 2005, at 8:40 AM, Alexander Griekspoor wrote: > By the way, the problems listed above are from my own list of things > to solve before release of the new enzymex ;-) > Are you volunteering? This is how I use the NSScanner to find the cleavage sites: NSScanner *scanner = [NSScanner scannerWithString: sequenceString]; cleaveSet = [NSCharacterSet characterSetWithCharactersInString:[enzyme objectForKey:@"CleaveAt"]]; if ( nil == cleaveSet ) return nil; s = [enzyme objectForKey:@"DontCleaveAdjacentTo"]; if ([s length]) dontCleaveAdjacentTo = [NSCharacterSet characterSetWithCharactersInString:[enzyme objectForKey:@"DontCleaveAdjacentTo"]]; else dontCleaveAdjacentTo = nil; cleaveDirection = [NSCharacterSet characterSetWithCharactersInString:[enzyme objectForKey:@"CleaveDirection"]]; len = [sequenceString length]; current = 0; cleavageSites = [[NSMutableArray alloc] init]; while (![scanner isAtEnd]) { [scanner scanUpToCharactersFromSet: cleaveSet intoString:nil]; current = [scanner scanLocation]; if ( current + 1 <= len ) { if ( !dontCleaveAdjacentTo || ( dontCleaveAdjacentTo && ![scanner scanCharactersFromSet: dontCleaveAdjacentTo intoString:nil] )) { current = [scanner scanLocation]; cut = [NSNumber numberWithInt:current + 1]; [cleavageSites addObject:cut]; [scanner setScanLocation: current + 1]; } } } I have to run now, but will have a more closer look at your snippet later today. - Koen. From kvddrift at earthlink.net Sun Feb 27 15:49:02 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 15:49:02 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: References: Message-ID: <568c24951598aa445f90ec973bbcc90e@earthlink.net> On Feb 27, 2005, at 10:51 AM, John Timmer wrote: > On the plus side, the SequenceFinder class seems pretty well designed > for finding sites accounting for ambiguity, though I haven?t tested it > with ambiguous sequences since the code was stripped out of the > sequence class. It's still in the BCAbstractSequence class (at the bottom). So it should work on all sequence classes. - Koen. From kvddrift at earthlink.net Sun Feb 27 16:01:30 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 16:01:30 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: References: Message-ID: On Feb 27, 2005, at 10:51 AM, John Timmer wrote: > Okay, as for digests, an NSScanner won?t work because of all the > ambiguity issues. That might indeed be a problem. Maybe we should ressurrect BCScanner that could help us here? > ?Since Alex found that you can?t load frameworks out of a plugin > bundle, I had to roll my own solution rather than using a REGEX > library, which means this code could be fairly informative. ?The > digest method itself is a bit complex, as it formats the output as an > attributed string, and labels sites, positions, etc. ?I?ve cut out the > actual site finding code here. I would suggest for the output we create subsequences, and copy all its intrinsic properties, not only the symbolArray. This way you should get all annotations and features, which I assume is what you are referring to. > > First, a rough overview: ?I decided for performance reasons to split > things up so that the simplest cases could be handled quickly (and > then I went and used array enumerators because I didn?t know they had > awful performance ? oh well). ?The first case handles no ambiguity, > the second handles ambiguous bases, the third is when the site > includes a stretch of N?s, and the final case has ambiguity and N?s. > ?In each case, several enzymes may recognize the same sequence, so > there?s an test and a call to mark everything from the ?same sites? > array. That sounds like a good approach. The first two can also be used for proteins. > The trick I use for recognizing sites with ambiguous bases here comes > from the use of strings ? I simply call a method that builds up an > array of all possible sequences, then search for each of them. ?For > N?s, I count how many there are and just skip forward that many bases. In my current code, I also use strings to scan for the characters representing the cleavage sites. When we decide on using the BCScanner class, we should be able to scan a symbolArray directly. So no need for a sequence -> string -> sequence conversion which will speed things up. - Koen. From mek at mekentosj.com Sun Feb 27 16:03:18 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 27 Feb 2005 22:03:18 +0100 Subject: [Biococoa-dev] Digest tool In-Reply-To: References: Message-ID: <95a7257f9324a12496396458ebffdfa1@mekentosj.com> >> The trick I use for recognizing sites with ambiguous bases here comes >> from the use of strings ? I simply call a method that builds up an >> array of all possible sequences, then search for each of them. ?For >> N?s, I count how many there are and just skip forward that many >> bases. > > In my current code, I also use strings to scan for the characters > representing the cleavage sites. When we decide on using the BCScanner > class, we should be able to scan a symbolArray directly. So no need > for a sequence -> string -> sequence conversion which will speed > things up. Hooray, yes I would love to see a BCScanner (obviously ;-) Alex ************************************************************** ** Alexander Griekspoor ** ************************************************************** The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From kvddrift at earthlink.net Sun Feb 27 16:12:15 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 16:12:15 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: <95a7257f9324a12496396458ebffdfa1@mekentosj.com> References: <95a7257f9324a12496396458ebffdfa1@mekentosj.com> Message-ID: <7b08b6848bd48aa5f7c304514618c63a@earthlink.net> On Feb 27, 2005, at 4:03 PM, Alexander Griekspoor wrote: > Hooray, yes I would love to see a BCScanner (obviously ;-) > From your initial code it looks like it is mimicking an NSScanner class. As John pointed out an NSScanner doesn't work well with ambiguous sequences, so we have to be aware of that when we write the implementation of the BCScanner. I have not much experience with regex (always tried to avoid them :) so maybe someone with more knowledge about that (eg from perl) can give more insight in the use of regex for our purpose. - Koen. From mek at mekentosj.com Sun Feb 27 16:15:57 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 27 Feb 2005 22:15:57 +0100 Subject: [Biococoa-dev] Digest tool In-Reply-To: <7b08b6848bd48aa5f7c304514618c63a@earthlink.net> References: <95a7257f9324a12496396458ebffdfa1@mekentosj.com> <7b08b6848bd48aa5f7c304514618c63a@earthlink.net> Message-ID: <428c75b42a8489090cf55279869fedb7@mekentosj.com> >> Hooray, yes I would love to see a BCScanner (obviously ;-) > > As John pointed out an NSScanner doesn't work well with ambiguous > sequences, so we have to be aware of that when we write the > implementation of the BCScanner. NSScanner doesn't obviously, but with all the tests at place in the BCSymbol class it much me possible to iterate over a BCSequence as a scanner and work with ambiguous symbols right? Or is too easy thought? Cheers, Alex ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Windows is a 32-bit patch to a 16-bit shell for an 8-bit operating system, written for a 4-bit processor by a 2- bit company without 1 bit of sense. ********************************************************* From jtimmer at bellatlantic.net Sun Feb 27 10:51:32 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 27 Feb 2005 10:51:32 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: Message-ID: Okay, as for digests, an NSScanner won?t work because of all the ambiguity issues. Since Alex found that you can?t load frameworks out of a plugin bundle, I had to roll my own solution rather than using a REGEX library, which means this code could be fairly informative. The digest method itself is a bit complex, as it formats the output as an attributed string, and labels sites, positions, etc. I?ve cut out the actual site finding code here. First, a rough overview: I decided for performance reasons to split things up so that the simplest cases could be handled quickly (and then I went and used array enumerators because I didn?t know they had awful performance ? oh well). The first case handles no ambiguity, the second handles ambiguous bases, the third is when the site includes a stretch of N?s, and the final case has ambiguity and N?s. In each case, several enzymes may recognize the same sequence, so there?s an test and a call to mark everything from the ?same sites? array. The trick I use for recognizing sites with ambiguous bases here comes from the use of strings ? I simply call a method that builds up an array of all possible sequences, then search for each of them. For N?s, I count how many there are and just skip forward that many bases. Overall, I?m not sure how well this is going to work as an example, given our non-string based model. I think rolling the digests into a single object is a good idea, but I?m pretty sure you?re going to have to make separate code for proteins and DNA. On the plus side, the SequenceFinder class seems pretty well designed for finding sites accounting for ambiguity, though I haven?t tested it with ambiguous sequences since the code was stripped out of the sequence class. We could start using that for now, and use Shark to tell us where we could make some improvements. Off the top of my head, I?d imagine inlining the symbol comparison method would help, and a few of the conditional statements could be taken out in the case where the sequence being searched had no ambiguous bases. ///////////////////////////////////////////////////// // this is the easiest case - all bases are defined ///////////////////////////////////////////////////// if ( [validCodonCharacters isSupersetOfSet: theSitesBases] ) { siteRange = [theDNASequence rangeOfString: siteString]; while ( siteRange.location != NSNotFound ) { anySitesFound = YES; numberOfCuts++; [self _markSequenceWithName: [anEnzyme objectForKey: @"enzyme name"] atRange: siteRange]; [cutterPositions addObject: [NSNumber numberWithInt: (siteRange.location + 1)]]; if ( markAllSequences && [[anEnzyme objectForKey: @"same sites"] count] > 0 ) { tempEnumerator = [[anEnzyme objectForKey: @"same sites"] objectEnumerator]; while ( anEnzymeName = [tempEnumerator nextObject] ) { [self _markSequenceWithName: anEnzymeName atRange: siteRange]; } } siteRange = [theDNASequence rangeOfString: siteString options: NSLiteralSearch range: NSMakeRange( siteRange.location + 1, [theDNASequence length] - siteRange.location - 2 )]; } } else if ( [siteString rangeOfString: @"N"].location == NSNotFound ) { ///////////////////////////////////////////////////// // ambiguous bases - we get an array of possible sites and search for each ///////////////////////////////////////////////////// siteArray = [self _getAllSitesFromSequence: siteString]; siteEnumerator = [siteArray objectEnumerator]; while ( aPossibleSiteString = [siteEnumerator nextObject] ) { siteRange = [theDNASequence rangeOfString: aPossibleSiteString]; while ( siteRange.location != NSNotFound ) { anySitesFound = YES; numberOfCuts++; [self _markSequenceWithName: [anEnzyme objectForKey: @"enzyme name"] atRange: siteRange]; [cutterPositions addObject: [NSNumber numberWithInt: (siteRange.location + 1)]]; if ( markAllSequences && [[anEnzyme objectForKey: @"same sites"] count] > 0 ) { tempEnumerator = [[anEnzyme objectForKey: @"same sites"] objectEnumerator]; while ( anEnzymeName = [tempEnumerator nextObject] ) { [self _markSequenceWithName: anEnzymeName atRange: siteRange]; } } siteRange = [theDNASequence rangeOfString: aPossibleSiteString options: NSLiteralSearch range: NSMakeRange( siteRange.location + 1, [theDNASequence length] - siteRange.location - 2 )]; } } } else { ///////////////////////////////////////////////////// // we have N bases, how annoying // first case, it's regular bases with some N's ///////////////////////////////////////////////////// if ( [normalBasesAndNCharacters isSupersetOfSet: theSitesBases] ) { // thankfully, it's only N's nonNComponentsArray = [siteString componentsSeparatedByString: @"N"]; numberOfNs = [nonNComponentsArray count] - 1; // see if this is worth doing if ( [siteString length] - numberOfNs < minimumSiteSize ) siteTooSmall = YES; else { leftHalf = [nonNComponentsArray objectAtIndex: 0]; rightHalf = [nonNComponentsArray objectAtIndex: ([nonNComponentsArray count] - 1)]; locationOfNStart = [leftHalf length]; siteRange = [theDNASequence rangeOfString: leftHalf]; while ( siteRange.location != NSNotFound ) { fullSiteRange = NSMakeRange( siteRange.location, [siteString length] ); if ( fullSiteRange.location + fullSiteRange.length < [theDNASequence length] - 1 ) { tempString = [theDNASequence substringWithRange: fullSiteRange]; if ( [tempString hasSuffix: rightHalf] ) { anySitesFound = YES; numberOfCuts++; [self _markSequenceWithName: [anEnzyme objectForKey: @"enzyme name"] atRange: siteRange]; [cutterPositions addObject: [NSNumber numberWithInt: (siteRange.location + 1)]]; if ( markAllSequences && [[anEnzyme objectForKey: @"same sites"] count] > 0 ) { tempEnumerator = [[anEnzyme objectForKey: @"same sites"] objectEnumerator]; while ( anEnzymeName = [tempEnumerator nextObject] ) { [self _markSequenceWithName: anEnzymeName atRange: siteRange]; } } } } siteRange = [theDNASequence rangeOfString: leftHalf options: NSLiteralSearch range: NSMakeRange( siteRange.location + 1, [theDNASequence length] - siteRange.location - 2 )]; } } } // worst case - we've got N's and Y's and W's and such. else { nonNComponentsArray = [siteString componentsSeparatedByString: @"N"]; numberOfNs = [nonNComponentsArray count] - 1; if ( [siteString length] - numberOfNs < minimumSiteSize ) siteTooSmall = YES; else { rightHalf = [nonNComponentsArray objectAtIndex: ([nonNComponentsArray count] - 1)]; leftHalf = [nonNComponentsArray objectAtIndex: 0]; siteArray = [self _getAllSitesFromSequence: leftHalf]; nonNComponentsArray = [self _getAllSitesFromSequence: rightHalf]; locationOfNStart = [leftHalf length]; siteEnumerator = [siteArray objectEnumerator]; while ( aPossibleSiteString = [siteEnumerator nextObject] ) { siteRange = [theDNASequence rangeOfString: aPossibleSiteString]; while ( siteRange.location != NSNotFound ) { fullSiteRange = NSMakeRange( siteRange.location, [siteString length] ); if ( fullSiteRange.location + fullSiteRange.length < [theDNASequence length] - 1 ) { tempString = [theDNASequence substringWithRange: fullSiteRange]; tempString = [tempString substringWithRange: NSMakeRange(locationOfNStart + numberOfNs, [rightHalf length])]; if ( [nonNComponentsArray containsObject: tempString] ) { anySitesFound = YES; numberOfCuts++; [self _markSequenceWithName: [anEnzyme objectForKey: @"enzyme name"] atRange: siteRange]; [cutterPositions addObject: [NSNumber numberWithInt: (siteRange.location + 1)]]; if ( markAllSequences && [[anEnzyme objectForKey: @"same sites"] count] > 0 ) { tempEnumerator = [[anEnzyme objectForKey: @"same sites"] objectEnumerator]; while ( anEnzymeName = [tempEnumerator nextObject] ) { [self _markSequenceWithName: anEnzymeName atRange: siteRange]; } } } } siteRange = [theDNASequence rangeOfString: aPossibleSiteString options: NSLiteralSearch range: NSMakeRange( siteRange.location + 1, [theDNASequence length] - siteRange.location - 2 )]; } } } } } } _______________________________________________ This mind intentionally left blank -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvddrift at earthlink.net Sun Feb 27 16:31:35 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 16:31:35 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: References: Message-ID: <548dabca42c98ff3c16fcf78ff2e52d4@earthlink.net> On Feb 27, 2005, at 10:51 AM, John Timmer wrote: > he first case handles no ambiguity, the second handles ambiguous > bases, the third is when the site includes a stretch of N?s, and the > final case has ambiguity and N?s. ?In each case, several enzymes may > recognize the same sequence, so there?s an test and a call to mark > everything from the ?same sites? array. Just thinking aloud here. Maybe if we design the appropriate BCSymbolSet for each case, we can just have one method (or while-loop in John's snippet). I haven't studied his code that closely, though, so I might be way of. However in any case, the combination BCScanner/BCSymbolSet to replace NSScanner/NCCharacterSet is definitely something to keep in mind. - Koen. From jtimmer at bellatlantic.net Sun Feb 27 17:07:15 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 27 Feb 2005 17:07:15 -0500 Subject: [Biococoa-dev] Digest tool In-Reply-To: <548dabca42c98ff3c16fcf78ff2e52d4@earthlink.net> Message-ID: > > On Feb 27, 2005, at 10:51 AM, John Timmer wrote: > >> he first case handles no ambiguity, the second handles ambiguous >> bases, the third is when the site includes a stretch of N?s, and the >> final case has ambiguity and N?s. ?In each case, several enzymes may >> recognize the same sequence, so there?s an test and a call to mark >> everything from the ?same sites? array. > > Just thinking aloud here. Maybe if we design the appropriate > BCSymbolSet for each case, we can just have one method (or while-loop > in John's snippet). I haven't studied his code that closely, though, so > I might be way of. However in any case, the combination > BCScanner/BCSymbolSet to replace NSScanner/NCCharacterSet is definitely > something to keep in mind. Well, the big dividing line between "easy" and "annoying" is handled by BCAbstractSequence's "containsAmbiguousSymbols", which is fairly optimized. The line between "just annoying" and "truly a PITA" is whether the sequence contains Ns, which should be an easy test to write and optimize. Since you may be performing a restriction map with hundreds of enzymes, it's probably worth making these tests very low overhead if we find they're needed. If symbolSets do that, then great. Again, I'd say that we try the find methods that we already have in place and then profile the results before deciding what to do. Not that I'm saying BCScanner shouldn't be implemented, just that we may not need it for this case. One thing I'm seeing with the "findSequence" method in the SequenceFinder tool is that it handles ambiguity in both directions (in the target and query sequences). I'd think with a restriction site map, we wouldn't want to mark a possible site that may or may not match because of an ambiguous base in the target sequence. This would cut down the matching we have to do and potentially speed things ups considerably, but would require a custom method. JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Sun Feb 27 19:58:26 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 27 Feb 2005 19:58:26 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: Message-ID: I've committed BCToolTranslator, and accompanying changes in BCGeneticCode. I'm pretty sure a single method now translates both DNA and RNA codons. This broke a bunch of stuff in BCSequenceCodon, which I'm now going to try to fix. You also may have to delete the I may have to make changes to BCSequenceCodon for it to fit in better with the new class cluster design. It's a bit of an oddball class, so these changes may require I pull it out of the class cluster. I'll summarize the problems before I do so to see if I'm missing something stupid. In addition, I put a lot of the code for getting the amino acid sequences out of the codon sequence in the codon sequence class itself. Is everyone comfortable with it there, or should I think about making a separate tool class? JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Sun Feb 27 20:05:42 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 20:05:42 -0500 Subject: [Biococoa-dev] More on BCSymbolSets Message-ID: <441c925a826b8a3524135c16803848b3@earthlink.net> Hi, Again I was looking at the BCSymbolSet code to implement it more in the BCSequence code. However with the new BCSequence class structure in place I am not so sure yet how to do this. For instance, we have the following method in each subclass: - (id) initWithString:(NSString *)entry skippingUnknownSymbols:(BOOL)skipFlag; I guess these are intended to be the designated initializer, although they have not been labeled as such in all classes. Now in BCSymbolSet we have the following (eg for DNA): dnaStrictSymbolSet (for C G T A) and dnaSymbolSet (for all possible nucleotides, including the ambiguous ones). Similar symbolsets are available for the other sequence types. Both symbolsets are possible in the method above, the skipFlag is not related to either symbolset. So what I can do is, is to test immediately for ambiguous symbols when creating the sequence (using containsAmbiguousSymbols), and based on that set the appropriate symbolset. Or even, to avoid a double iteration, test immediately for isCompoundSymbol when each symbol is added. I think this code should only go in the designated initializer, because that should be called by all other initializers. Would this be a reasonable approach? Then of course we have the 'unknown symbols' flag. I still am not sure what the purpose of this is. Is it to prevent illegal characters to be converted to a symbol. This could happen if the string contains numbers, or other characters not defined to be symbols. I noticed that the implementation for the skip flag is slightly different in the code for proteins versus that for DNA/RNA. For proteins it looks like: if ( (skipFlag==NO) || (aminoAcid!=[BCAminoAcid undefined]) ) [tempSequence addObject: aminoAcid]; For DNA/RNA it looks like: if ( aBase != [BCNucleotideDNA undefined] ) [tempSequence addObject: aBase]; else { if ( !skipFlag ) [tempSequence addObject: [BCNucleotideDNA undefined]]; The protein adds the aminoAcid if skipFlag is NO, the DNA/RNA adds an undefined symbol. I guess we should settle on one, anyone has a preference? thanks, - Koen. From kvddrift at earthlink.net Sun Feb 27 20:12:00 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 20:12:00 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: References: Message-ID: <266786a6bb973e77917e220741fde58c@earthlink.net> John, did you also commit the changes in your project.pbxproj file? I get the new BCToolTranslator classes on my HD, but they don't show up in my Xcode project. > I've committed BCToolTranslator, and accompanying changes in > BCGeneticCode. > I'm pretty sure a single method now translates both DNA and RNA codons. > This broke a bunch of stuff in BCSequenceCodon, which I'm now going to > try > to fix. You also may have to delete the > > delete what ? :-) - Koen. From jtimmer at bellatlantic.net Sun Feb 27 21:15:21 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 27 Feb 2005 21:15:21 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: <266786a6bb973e77917e220741fde58c@earthlink.net> Message-ID: > John, did you also commit the changes in your project.pbxproj file? I > get the new BCToolTranslator classes on my HD, but they don't show up > in my Xcode project. > >> I've committed BCToolTranslator, and accompanying changes in >> BCGeneticCode. >> I'm pretty sure a single method now translates both DNA and RNA codons. >> This broke a bunch of stuff in BCSequenceCodon, which I'm now going to >> try >> to fix. You also may have to delete the >> >> > > delete what ? :-) Ooops, sorry - delete the previous tool files. And I can't seem to commit a change to the project file. It's probably because I'm using Tiger. If you add themto the project yourself, please add them to the project and commit that. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Sun Feb 27 22:09:12 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 22:09:12 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: References: Message-ID: <63cc7d7df9e815c8a3f621c8ffc191af@earthlink.net> On Feb 27, 2005, at 9:15 PM, John Timmer wrote: > Ooops, sorry - delete the previous tool files. And I can't seem to > commit a > change to the project file. It's probably because I'm using Tiger. > If you > add themto the project yourself, please add them to the project and > commit > that. > Done. The translation demo has the code: // Translate the DNA sequence - the result is an NSArray of BCCodons (three nucleotides each) NSArray *translation = [BCToolTranslatorDNA translateDNASequence: (BCSequenceDNA *)theSequence usingGeneticCode: BCUniversalCodeDNA]; Could you update that to reflect the changes in the new BCTranslationTool? thanks, - Koen. From jtimmer at bellatlantic.net Sun Feb 27 22:26:17 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 27 Feb 2005 22:26:17 -0500 Subject: [Biococoa-dev] More on BCSymbolSets In-Reply-To: <441c925a826b8a3524135c16803848b3@earthlink.net> Message-ID: Okay, looking at things, we definitely have to try to make things a bit more consistent in terms of the init methods. I think they're mostly holdovers from before amino acids had ambiguous members. I think the idea of using a symbol set to limit the possible options for initializing a sequence is a good one, provided we make the process very streamlined. The class itself looks to be good in that regard. I've got a couple of ideas on the implementation. One idea that suggests itself is to have a BCSequencType variable for the symbol set - that way the sequence being initialized could pick up its sequence type from the set it gets passed during initialization. The other thing I'd do is take the methods like "baseForSymbol" and "aaForSymbol" and formalize them to be a single selector, like "symbolForCharacter". That way, you could call the same selector on any class. This would allow you to make code that looked something like this (given passedString and passedSet as the arguments): TheClass = [passedSet anyObject]; TheChar = [passedString characterAtIndex: loopCounter]; TheSymbol = [theClass symbolForCharacter: theChar]; If ( [passedSet containsObject: theSymbol] ) // add it to our sequence If we're making symbol sets this central to sequence creation, though, I'd make a lot of combinations, rather than the two we have for each type. We don't want any of the commonly used sets more than a single call away. Basically, I'd do strict, ambiguous, those with gap, those with undefined, those with both, etc. We may also want to make the standard ones singletons. This sound like the sort of thing you were looking to do? JT > Again I was looking at the BCSymbolSet code to implement it more in the > BCSequence code. However with the new BCSequence class structure in > place I am not so sure yet how to do this. For instance, we have the > following method in each subclass: > > - (id) initWithString:(NSString *)entry > skippingUnknownSymbols:(BOOL)skipFlag; > > I guess these are intended to be the designated initializer, although > they have not been labeled as such in all classes. Now in BCSymbolSet > we have the following (eg for DNA): > > dnaStrictSymbolSet (for C G T A) and dnaSymbolSet (for all possible > nucleotides, including the ambiguous ones). > > Similar symbolsets are available for the other sequence types. Both > symbolsets are possible in the method above, the skipFlag is not > related to either symbolset. So what I can do is, is to test > immediately for ambiguous symbols when creating the sequence (using > containsAmbiguousSymbols), and based on that set the appropriate > symbolset. Or even, to avoid a double iteration, test immediately for > isCompoundSymbol when each symbol is added. > > I think this code should only go in the designated initializer, because > that should be called by all other initializers. Would this be a > reasonable approach? > > Then of course we have the 'unknown symbols' flag. I still am not sure > what the purpose of this is. Is it to prevent illegal characters to be > converted to a symbol. This could happen if the string contains > numbers, or other characters not defined to be symbols. I noticed that > the implementation for the skip flag is slightly different in the code > for proteins versus that for DNA/RNA. > > For proteins it looks like: > > if ( (skipFlag==NO) || (aminoAcid!=[BCAminoAcid undefined]) ) > [tempSequence addObject: aminoAcid]; > > For DNA/RNA it looks like: > > if ( aBase != [BCNucleotideDNA undefined] ) > [tempSequence addObject: aBase]; > else { > if ( !skipFlag ) > [tempSequence addObject: [BCNucleotideDNA undefined]]; > > > The protein adds the aminoAcid if skipFlag is NO, the DNA/RNA adds an > undefined symbol. I guess we should settle on one, anyone has a > preference? > > > thanks, > > - Koen. > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Sun Feb 27 22:41:22 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 27 Feb 2005 22:41:22 -0500 Subject: [Biococoa-dev] More on BCSymbolSets In-Reply-To: References: Message-ID: On Feb 27, 2005, at 10:26 PM, John Timmer wrote: > I think the idea of using a symbol set to limit the possible options > for > initializing a sequence is a good one, provided we make the process > very > streamlined. The class itself looks to be good in that regard. Not only in the init methods. They can be used all throughout the framework. > > I've got a couple of ideas on the implementation. One idea that > suggests > itself is to have a BCSequencType variable for the symbol set - that > way the > sequence being initialized could pick up its sequence type from the > set it > gets passed during initialization. Then we might have to extend the different BCSequenceTypes to include strict, ambiguous, etc. > > The other thing I'd do is take the methods like "baseForSymbol" and > "aaForSymbol" and formalize them to be a single selector, like > "symbolForCharacter". That way, you could call the same selector on > any > class. This would allow you to make code that looked something like > this > (given passedString and passedSet as the arguments): > TheClass = [passedSet anyObject]; > TheChar = [passedString characterAtIndex: loopCounter]; > TheSymbol = [theClass symbolForCharacter: theChar]; > If ( [passedSet containsObject: theSymbol] ) > // add it to our sequence This is indeed similar to what I have in mind, yes. > If we're making symbol sets this central to sequence creation, though, > I'd > make a lot of combinations, rather than the two we have for each type. > We > don't want any of the commonly used sets more than a single call away. Sets can always be combined, using formUnionWithSymbolSet and formIntersectionWithSymbolSet. > Basically, I'd do strict, ambiguous, those with gap, those with > undefined, > those with both, etc. We may also want to make the standard ones > singletons. Sounds good. - Koen. From charles.parnot at stanford.edu Mon Feb 28 01:03:06 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Sun, 27 Feb 2005 22:03:06 -0800 Subject: [Biococoa-dev] More on BCSymbolSets In-Reply-To: <441c925a826b8a3524135c16803848b3@earthlink.net> References: <441c925a826b8a3524135c16803848b3@earthlink.net> Message-ID: At 8:05 PM -0500 2/27/05, Koen van der Drift wrote: >Hi, > >Again I was looking at the BCSymbolSet code to implement it more in the BCSequence code. However with the new BCSequence class structure in place I am not so sure yet how to do this. For instance, we have the following method in each subclass: > >- (id) initWithString:(NSString *)entry skippingUnknownSymbols:(BOOL)skipFlag; > >I guess these are intended to be the designated initializer, although they have not been labeled as such in all classes. Now in BCSymbolSet we have the following (eg for DNA): >dnaStrictSymbolSet (for C G T A) and dnaSymbolSet (for all possible nucleotides, including the ambiguous ones). When I updated the sequence initialization methods, I did some cleanup mostly to remove redundant methods, in particular factory methods. However, I kept the init methods exactly the same. There is clearly one issue: there are 2 designated initializers independent of each other 'initWithString:skipUnknownSymbols' and 'initWithSymbolArray:'. In theory, initWithSymbolArray' would be the best candidate for a designated initializer as it is closer to the actual data structure. See code at the end of the email... >Similar symbolsets are available for the other sequence types. Both symbolsets are possible in the method above, the skipFlag is not related to either symbolset. So what I can do is, is to test immediately for ambiguous symbols when creating the sequence (using containsAmbiguousSymbols), and based on that set the appropriate symbolset. Or even, to avoid a double iteration, test immediately for isCompoundSymbol when each symbol is added. > >I think this code should only go in the designated initializer, because that should be called by all other initializers. Would this be a reasonable approach? It seems to me that we should use a default symbol set when the user don't want to bother. However, if we use symbol sets, it would make sense to use it to provide their benefits to the user. For instance, the user could decide how she wants to filter an input sequence, and let her choose a symbolSet in the init method. See code at the end of the email... >Then of course we have the 'unknown symbols' flag. I still am not sure what the purpose of this is. Is it to prevent illegal characters to be converted to a symbol. This could happen if the string contains numbers, or other characters not defined to be symbols. Like I said, I strictly used what was there. I still wonder when the user would NOT want to skip unknown symbol and replace numbers or weird characters with question marks (undefined symbol). Maybe this could be implemented in a particular symbolSet, by having a symbolSet e.g. 'dnaSymbolSetWhereUnknownSymbolsAreAllUndefined' (we should find a shorter name!). Symbol sets could return 'symbolWithCharacter:'. Symbol sets would normally return nil if unknown, but this particular symbol set would return the undefined symbol for all unknown characters. See more code at the end of the email... >I noticed that the implementation for the skip flag is slightly different in the code for proteins versus that for DNA/RNA. > >For proteins it looks like: > > if ( (skipFlag==NO) || (aminoAcid!=[BCAminoAcid undefined]) ) > [tempSequence addObject: aminoAcid]; > >For DNA/RNA it looks like: > > if ( aBase != [BCNucleotideDNA undefined] ) > [tempSequence addObject: aBase]; > else { > if ( !skipFlag ) > [tempSequence addObject: [BCNucleotideDNA undefined]]; > > >The protein adds the aminoAcid if skipFlag is NO, the DNA/RNA adds an undefined symbol. I guess we should settle on one, anyone has a preference? I am responsible for the protein version. If you think more about the code, I believe the result is actually the same! In both cases, if skipFlag=NO, you get the undefined symbol added. The protein code reads : "if I don't care about undefined symbols, or if I care but the symbol is defined, then add the symbol..) Maybe the code is clearer with: if (skipFlag==NO) { [tempSequence addObject: aBase]; } else { if (aBase != [BCNucleotideDNA undefined]) [tempSequence addObject: aBase]; } But we could drop the skipFlag and still provide the functionality. At 10:26 PM -0500 2/27/05, John Timmer wrote: >Okay, looking at things, we definitely have to try to make things a bit more >consistent in terms of the init methods. I think they're mostly holdovers >from before amino acids had ambiguous members. > >I think the idea of using a symbol set to limit the possible options for >initializing a sequence is a good one, provided we make the process very >streamlined. The class itself looks to be good in that regard. > >I've got a couple of ideas on the implementation. One idea that suggests >itself is to have a BCSequencType variable for the symbol set - that way the >sequence being initialized could pick up its sequence type from the set it >gets passed during initialization. One thing we have to be aware of is that the sequence class is a bit repetitive for the sequence type. We have the class which tells what the type of sequence is (e.g. [BCSequenceDNA class]), the sequenceType ivar (e.g. BCDNASequence), and then possibly the symbolSet now. So we have to be very clear on which of these 3 items is the 'leader'. I seems natural that the sequence class should be the leader and decide what the sequence type is and what the symbol set type should be. I thus agree that symbolSet could have a sequenceType, for that purpose: the sequence class could check that the symbolSet is the right type before using it. Otherwise, it would default to a default symbolSet. >The other thing I'd do is take the methods like "baseForSymbol" and >"aaForSymbol" and formalize them to be a single selector, like >"symbolForCharacter". That way, you could call the same selector on any >class. This would allow you to make code that looked something like this >(given passedString and passedSet as the arguments): >TheClass = [passedSet anyObject]; >TheChar = [passedString characterAtIndex: loopCounter]; >TheSymbol = [theClass symbolForCharacter: theChar]; >If ( [passedSet containsObject: theSymbol] ) > // add it to our sequence Even better, 'symbolForCharacter:' could actually be a method for the symbolSet. That would be a very good idea to allow for that code: TheChar = [passedString characterAtIndex: loopCounter]; TheSymbol = [passedSet symbolForCharacter: theChar]; If ( theSymbol!=nil ) // add it to our sequence See more code at the end of the email... >If we're making symbol sets this central to sequence creation, though, I'd >make a lot of combinations, rather than the two we have for each type. We >don't want any of the commonly used sets more than a single call away. >Basically, I'd do strict, ambiguous, those with gap, those with undefined, >those with both, etc. We may also want to make the standard ones >singletons. Very good point! It thens makes really sense to let the user access them. At 10:41 PM -0500 2/27/05, Koen van der Drift wrote: > >>I've got a couple of ideas on the implementation. One idea that suggests >>itself is to have a BCSequencType variable for the symbol set - that way the >>sequence being initialized could pick up its sequence type from the set it >>gets passed during initialization. > >Then we might have to extend the different BCSequenceTypes to include strict, ambiguous, etc. Actually, the current sequence type is redundant with the sequence class. But it is convenient to make sure we deal with DNA or protein without having to use the inelegant and dangerous 'isKindOfClass:' (which relies on the class name never changing). The sequence type you propose would be redundant with the symbolSet. It is alreadyeasy to check for a symbolSet with equality to the class singleton, without the need for a sequenceType enum. We could also provide a isEqualToSymbolSet: method. In addition, the user might create other symbol sest that would not be covered by the nomenclature we would put in place. This is probably even more problematic for a fixed enum that could never take that into account. OK, now, here is what I have in mind. Some real code! This is all that is needed to provide the initializers for ALL the classes (except BCSequenceCodon and BCSequence; for the latter, a slight modification will do). Most of the code is in the subclass. @interface BCAbstractSequence:NSObject { BCSymbolSet *symbolSet; BCSequenceType *sequenceType; NSMutableArray *symbolArray; } //designated initializer - (id)initWithSymbolArray:(NSArray *)anArray symbolSet:(BCSymbolSet *)aSet; - (id)initWithString:(NSString *)aString; - (id)initWithString:(NSString *)aString symbolSet:(BCSymbolSet *)aSet; //methods to override in the subclasses + (BCSequenceType)sequenceType; + (BCSymbolSet *)defaultSymbolSet; @end @implementation BCAbstractSequence - (id)initWithSymbolArray:(NSArray *)anArray symbolSet:(BCSymbolSet *)aSet { self=[super init]; if (self!=nil) { sequenceType=[[self class] sequenceType]; //check that the symbol set is the right type, otherwise use default if ([aSet sequenceType]!=sequenceType) aSet=[[self class] defaultSymbolSet]; //let the set check the symbols NSArray *finalArray=[aSet arrayByRemovingUnknownSymbolsFromArray:anArray]; symbolArray=[[NSMutableArray alloc] initWithArray:finalArray]; } return self; } - (id)initWithString:(NSString *)aString; { return [self initWithString:aString symbolSet:[[self class] defaultSymbolSet]]; } - (id)initWithString:(NSString *)aString symbolSet:(BCSymbolSet *)aSet; { int i,n; NSMutableArray *anArray; BCSymbol *aSymbol; //check that the symbol set is the right type, otherwise use default if ([aSet sequenceType]!=[[self class] sequenceType]) aSet=[[self class] defaultSymbolSet]; //creates a symbol array n=[aString length]; anArray=[NSMutableArray arrayWithCapacity:[aString length]]; for (i=0;i++;i The BioCocoa target has been upgraded to a native target, and its SDKROOT set to 10.2.8 in the build settings. Now that the SDK is really used, one problem showed up in BCUtilCGI: somewhere, the use of method 'stringByReplacingPercentEscapesUsingEncoding:' which is available on 10.3 only... I have no idea what this is used for!! charles NB: I kept the old target for now, but I will delete it when things have been tested a little more. -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From mek at mekentosj.com Mon Feb 28 04:08:14 2005 From: mek at mekentosj.com (Alexander Griekspoor) Date: Mon, 28 Feb 2005 10:08:14 +0100 Subject: [Biococoa-dev] Target upgraded In-Reply-To: References: Message-ID: <1fb2ca7dd590359eded486a6004f811e@mekentosj.com> BCUtilCGI is a class from John which allows you to perform CGI commands on a server if I remember correctly. Anyway, the stringByReplacingPercentEscapesUsingEncoding method replaces all non-URL characters to escaped counterparts (i.e. spaces to %20). It's a corefoundation method which received a Cocoa wrapper method in 10.3. Because all my apps are still 10.2 compatible, I still use the CF function. If you add the following to the NSString-Extensions in BCUtilStrings and change the method in BCUtilCGI accordingly, we should get rid of the warning... Alex - (NSString*) stringByAddingURLEscapesUsingEncoding: (CFStringEncodings) enc { NSString* str2 = (id) CFURLCreateStringByAddingPercentEscapes(NULL, (CFStringRef)self, NULL, NULL, enc); if( str2 == self ) [self release]; // CF just bumped its refcount else [str2 autorelease]; return str2; } On 28-feb-05, at 7:26, Charles PARNOT wrote: > The BioCocoa target has been upgraded to a native target, and its > SDKROOT set to 10.2.8 in the build settings. > > Now that the SDK is really used, one problem showed up in BCUtilCGI: > somewhere, the use of method > 'stringByReplacingPercentEscapesUsingEncoding:' which is available on > 10.3 only... I have no idea what this is used for!! > > charles > > NB: I kept the old target for now, but I will delete it when things > have been tested a little more. > > -- > Help science go fast forward: > http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ > > Charles Parnot > charles.parnot at stanford.edu > > Room B157 in Beckman Center > 279, Campus Drive > Stanford University > Stanford, CA 94305 (USA) > > Tel +1 650 725 7754 > Fax +1 650 725 8021 > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev > > ********************************************************* ** Alexander Griekspoor ** ********************************************************* The Netherlands Cancer Institute Department of Tumorbiology (H4) Plesmanlaan 121, 1066 CX, Amsterdam Tel: + 31 20 - 512 2023 Fax: + 31 20 - 512 2029 AIM: mekentosj at mac.com E-mail: a.griekspoor at nki.nl Web: http://www.mekentosj.com Claiming that the Macintosh is inferior to Windows because most people use Windows, is like saying that all other restaurants serve food that is inferior to McDonalds ********************************************************* -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3193 bytes Desc: not available URL: From jtimmer at bellatlantic.net Mon Feb 28 12:04:36 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 28 Feb 2005 12:04:36 -0500 Subject: [Biococoa-dev] More on BCSymbolSets In-Reply-To: Message-ID: I'm replying to Koen's mail, but I'm going to cut and paste in some of Charles's email as well, since it's all on related stuff. >> I think the idea of using a symbol set to limit the possible options >> for >> initializing a sequence is a good one, provided we make the process >> very >> streamlined. The class itself looks to be good in that regard. > > Not only in the init methods. They can be used all throughout the > framework. I wasn't implying they couldn't, just that this was an obvious case for their use. I could also see how implementing this would turn the "containsAmbiguousSymbols" method into about a 4 liner instead of a big loop. >> I've got a couple of ideas on the implementation. One idea that >> suggests >> itself is to have a BCSequencType variable for the symbol set - that >> way the >> sequence being initialized could pick up its sequence type from the >> set it >> gets passed during initialization. > > Then we might have to extend the different BCSequenceTypes to include > strict, ambiguous, etc. Well, there are clearly going to be cases where all we care about is the type of sequence we're looking at, such as deciding whether we can complement it - quite likely these are the majority of cases. So if we're trying to treat everything as a BCAbstractSeqeuence where possible, then asking the sequence type makes sense, as does keeping that type fairly broad. I'd view the SymbolSet as providing a more detailed description than that provided by sequence type: you check for it when you need more details, but can ignore it when you don't. >> If we're making symbol sets this central to sequence creation, though, >> I'd >> make a lot of combinations, rather than the two we have for each type. >> We >> don't want any of the commonly used sets more than a single call away. > > Sets can always be combined, using formUnionWithSymbolSet and > formIntersectionWithSymbolSet. That's true. Which could actually be a problem. If we have a singleton instance for all non-ambiguous amino acids, what happens if somebody deletes the alanine? You've just screwed the entire runtime. So, let me refine my suggestion. We have a group of immutable sets that represent all the commonly used symbol sets. We initialize these out of a plist file and make them singletons, as we do with the other base classes. We have a subclass that allows mutability, and that can obtain copies of the base sets for manipulation, but cannot go back and mutate the singleton sets. > Even better, 'symbolForCharacter:' could actually be a method for the > symbolSet. That would be a very good idea to allow for that code: I agree that it should be an option, but I'm not certain it should be the default use. One of the problems I had with BioJava is that you called through so many classes and methods to get something simple done, it made it very difficult to debug problems (I kept thinking "wait, what class am I in now?"). My guess is that it also slowed the code down. This would also cause problems when it runs into characters not in the set: would it return nil? If so, you'd have to test for nil, etc. By getting a symbol and then testing whether the symbol is in the set, you are always working with actual objects, which is safer and easier to read. I'm not fond of the following code: + (BCSequenceType)sequenceType { return BCDNASequence; } You're typically going to be calling this method on a BCAbstractSequence to find out what kind of sequence it actually is. Making it a class method defeats this purpose. If you meant this to provide what the default is for the class as a whole, then the method should be named to reflect that. Finally, I just want to sound a couple of notes of caution: By having a specific symbol set associated with a sequence, it means we have to do error testing whenever new symbols are added to the sequence, two sequences are combined, etc. We will ALWAYS have to make sure the symbol set and sequenceArrays are rationalized. I actually like this, but got scolded for being excessively cautious when I implemented something like this a while back ;). Another potential complication: what happens if the complement of a base isn't in the same symbol set? Say someone makes an "all pyrimadine" symbol set, then asks for its complement - we'd have to have some code to figure out what symbol set is appropriate when creating the complement, so that we could assign it to the resulting sequence... I still think this is a good idea, but I think implementing it in a safe manner is going to be very challenging, and we should think through all the consequences and where we'd have to modify code before we even start to try it. Think that's everything for now... JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Mon Feb 28 12:08:13 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 28 Feb 2005 12:08:13 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: <63cc7d7df9e815c8a3f621c8ffc191af@earthlink.net> Message-ID: > The translation demo has the code: > > // Translate the DNA sequence - the result is an NSArray of BCCodons > (three nucleotides each) > NSArray *translation = [BCToolTranslatorDNA translateDNASequence: > (BCSequenceDNA *)theSequence usingGeneticCode: > BCUniversalCodeDNA]; > > > Could you update that to reflect the changes in the new > BCTranslationTool? I've made the change, but the code isn't working properly, so the change I added has some debugging code nearby. For some reason, the category I added on NSMutableArrays isn't allowing them to sort based on Ranges stuffed into NSValues. I'll try to figure out what's gone wrong there later today. JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Mon Feb 28 12:21:26 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 28 Feb 2005 12:21:26 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: <63cc7d7df9e815c8a3f621c8ffc191af@earthlink.net> Message-ID: Incidentally, to aid with debugging I just changed code so that the description of a codon sequence now produces something like the following: P(CCN)W(TGG)Y(TAY)A(GCN)R(CGN)R(MGR)Y(TAY)R(MGR)S(TCN)G(GGN)I(ATH)P(CCN)G(GG N)S(TCN)T(ACN)H(CAY)A(GCN)S(TCN)A(GCN)D(GAY)A(GCN)W(TGG)G(GGN)D(GAY)P(CCN)G( GGN)R(MGR)F(TTY)E(GAR)C(TGY)F(TTY)V(GTN)W(TGG)*(TAR)S(TCN)K(AAR)S(TCN)G(GGN) F(TTY)S(TCN)G(GGN)W(TGG)I(ATH)S(TCN)N(AAY)S(TCN)R(MGR)L(YTR)C(TGY)R(CGN)G(GG N)T(ACN)N(AAY)V(GTN)A(GCN)C(TGY)C(TGY)F(TTY)I(ATH)C(TGY)Q(CAR)*(TGA)C(TGY)S( TCN)L(CTN)I(ATH)R(MGR)H(CAY)T(ACN)E(GAR)T(ACN)T(ACN)R(MGR)Y(TAY)S(TCN)V(GTN) Q(CAR)A(GCN)S(AGY)*(TAR)Q(CAR)W(TGG)F(TTY)R(MGR)*(TGA)F(TTY)*(TGA)*(TGA)R(MG R)R(MGR)S(TCN)*(TGA)W(TGG)R(MGR)D(GAY)C(TGY)N(AAY)N(AAY)S(AGY)E(GAR)*(TGA)*( TGA)S(TCN)Y(TAY)R(MGR)C(TGY)*(TAR)A(GCN)C(TGY)*(TAR)E(GAR)D(GAY)A(GCN)F(TTY) K(AAR)P(CCN)R(MGR)I(ATH)R(CGN)*(TAR)A(GCN)L(CTN)*(TAR)K(AAR)K(AAR)K(AAR)A(GC N)R(MGR)A(GCN)N(AAY)E(GAR)*(TGA)I(ATH)*(TGA)F(TTY)T(ACN)G(GGN)W(TGG)P(CCN)I( ATH)T(ACN)W(TGG)*(TGA)A(GCN)F(TTY)N(AAY)Y(TAY)A(GCN)*(TAR)A(GCN)S(TCN)*(TAR) *(TGA)G(GGN)H(CAY)S(TCN)E(GAR)V(GTN)*(TAR)H(CAY)R(CGN)C(TGY)C(TGY)R(MGR)*(TA R)Q(CAR)N(AAY)L(CTN)K(AAR)S(AGY)*(TGA)Y(TAY)R(MGR)N(AAY)I(ATH)E(GAR)N(AAY)K( AAR)G(GGN)E(GAR)D(GAY)G(GGN)R(MGR)G(GGN)H(CAY)C(TGY)E(GAR)K(AAR)S(AGY)D(GAY) R(MGR)D(GAY)E(GAR)P(CCN)*(TAR)A(GCN)F(TTY)G(GGN)K(AAR)T(ACN)I(ATH)Q(CAR)H(CA Y)T(ACN)I(ATH)R(MGR)*(TAR)D(GAY)T(ACN)D(GAY)G(GGN)F(TTY)F(TTY)T(ACN)A(GCN)K( AAR)L(CTN)E(GAR)S(TCN)N(AAY)R(MGR)H(CAY)D(GAY)S(TCN)K(AAR)S(TCN)N(AAY)I(ATH) R(MGR)G(GGN)Q(CAR)Q(CAR)F(TTY)C(TGY)K(AAR)Q(CAR)L(CTN)G(GGN)C(TGY)Y(TAY)F(TT Y)G(GGN)I(ATH)R(MGR)L(YTR)Q(CAR)C(TGY)F(TTY)*(TGA)S(AGY)?(---) Which is the amino acid followed by the codon triplet. Does anyone have suggestions for better readability before I check in the code? JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Mon Feb 28 12:35:58 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 28 Feb 2005 12:35:58 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: Message-ID: > I've made the change, but the code isn't working properly, so the change I > added has some debugging code nearby. For some reason, the category I added > on NSMutableArrays isn't allowing them to sort based on Ranges stuffed into > NSValues. I'll try to figure out what's gone wrong there later today. Okay, I can confirm that the translator tool is just fine. The bugs appear to be in BCSequenceCodon, and I'll be trying to sort those out later today. JT _______________________________________________ This mind intentionally left blank From charles.parnot at stanford.edu Mon Feb 28 18:34:17 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 28 Feb 2005 15:34:17 -0800 Subject: Fwd: Re: [Biococoa-dev] More on BCSymbolSets Message-ID: > >> I've got a couple of ideas on the implementation. One idea that >>> suggests >>> itself is to have a BCSequencType variable for the symbol set - that >>> way the >>> sequence being initialized could pick up its sequence type from the >>> set it >>> gets passed during initialization. >> >> Then we might have to extend the different BCSequenceTypes to include >> strict, ambiguous, etc. >Well, there are clearly going to be cases where all we care about is the >type of sequence we're looking at, such as deciding whether we can >complement it - quite likely these are the majority of cases. So if we're >trying to treat everything as a BCAbstractSeqeuence where possible, then >asking the sequence type makes sense, as does keeping that type fairly >broad. I'd view the SymbolSet as providing a more detailed description than >that provided by sequence type: you check for it when you need more >details, but can ignore it when you don't. I agree a symbolSet could just be a way of getting more details about the type of sequence you are dealing with. The sequence type would be to give a broader scope: DNA, RNA, protein. Using symbolSet to also better control the sequence behavior at creation and when adding symbols could make sense, though. You outline below a number of problems. Like you say, we coul still try to address them as they are not unsurmountable. Anyway, the question at this point is: what do we want to do with symbolSet? If they are just a way to provide a refinement on the sequenceType, they we may not need a full class, but just an enum. And if we don't enforce the sequence contents to be consistent with the symbolSet, then it is useless. Maybe also as a first step, we don't have to make symbolSet a public class, then. It would just allow us more flexibility. Using a symbolSet instead of a bunch of BOOL like 'skipUnknownSymbols', 'allowAmbiguousSymbols', 'allowGaps',... will be much more readable and will allow for more extensions and more flexibility. In other words, it could be a tool available to us, developers, but not to the users of the framework. So, what do you think symbolSet should be used for? The way I see it now is as a filter to restrict the symbols used in a given sequence. In fact, the more I think about it, the more 'filtering' seems like what it should do. And if we don't want any restriction, then one can always create very broad symbol sets. >So, let me refine my suggestion. We have a group of immutable sets that >represent all the commonly used symbol sets. We initialize these out of a >plist file and make them singletons, as we do with the other base classes. >We have a subclass that allows mutability, and that can obtain copies of the >base sets for manipulation, but cannot go back and mutate the singleton >sets. This is perfect. I love immutable classes! In fact, you may not even need a mutable class or even want it: what happens if such a mutable object is used in a sequence, and is changed. what do we do with the existsing symbols?. By providing a 'symbolSetWithSymbols:(id)aSymbol,...' and some basic intersect/union, that should be enough to create any set in 2-3 lines of code max. > > Even better, 'symbolForCharacter:' could actually be a method for the >> symbolSet. That would be a very good idea to allow for that code: >I agree that it should be an option, but I'm not certain it should be the >default use. One of the problems I had with BioJava is that you called >through so many classes and methods to get something simple done, it made it >very difficult to debug problems (I kept thinking "wait, what class am I in >now?"). My guess is that it also slowed the code down. This would also >cause problems when it runs into characters not in the set: would it return >nil? If so, you'd have to test for nil, etc. By getting a symbol and then >testing whether the symbol is in the set, you are always working with actual >objects, which is safer and easier to read. Yes, it would return nil. This is the behavior of NSDictionary, NSArray and NSSet. Getting the symbol and then testing if it exits in the symbol set, like you suggest, works fine too but is not necessarily easier to read. Safer, yes,maybe ;-) but there are a few occasions where nil is useful, like I said with NSDictionary,... Anyway, this is not a critical design problem. Your concern about a bloated framework is much more important, and I share it. I actually was scared by BioPerl because of that (and it does indeed result in somewhat slow code). This is one of the reason I did not like the factory design in BioCocoa, when it can simply be in the class with a few lines of code. However, I do think that the symbolSet class is quite self-explanatory, and the code I submitted is very short and thus very readable I believe (??), and whichever way we do it, it should be quite readable because the concept is sumple. Anyway, we all talk about using the symbolSet, so we end up having three classes: sequence, symbol and symbol set. > >I'm not fond of the following code: >+ (BCSequenceType)sequenceType > { return BCDNASequence; } > >You're typically going to be calling this method on a BCAbstractSequence to >find out what kind of sequence it actually is. Making it a class method >defeats this purpose. If you meant this to provide what the default is for >the class as a whole, then the method should be named to reflect that. I am not sure I understand what you are saying. I declared this class method, because it seems that all instances of a given class will have the same sequence type. Is that right? In fact, is there really a need for an ivar? An instance method could be used instead that always return the same value in a given class. Do you mean we should use an instance method instead, or do you mean we should name this method 'defaultSequenceType'? The reason for this method and the 'defaultSymbolset' method is so that the init method can be factored out to the superclass. When you look at the code for the sequence subclass, it is always the same except for the symbol class being checked. This would be the same problem if we used symbol sets instead of symbol class to check the validity of symbols or strings. To be able to put the common code in the initializer, where no ivar has been set yet, it makes sense to then use methods that will provide that information at runtime. There are a number of Cocoa classes that use this design, like NSDocument with the nib name or the window controller. The initialization of the document calls methods in the subclass to get the names of these elements. I agree they are instance methods, so maybe we could use instance methods instead. >Finally, I just want to sound a couple of notes of caution: > >By having a specific symbol set associated with a sequence, it means we have >to do error testing whenever new symbols are added to the sequence, two >sequences are combined, etc. We will ALWAYS have to make sure the symbol >set and sequenceArrays are rationalized. I actually like this, but got >scolded for being excessively cautious when I implemented something like >this a while back ;). Let's see what would be logical: * adding a string or an array of symbols: filter using the symbol set * appending a sequence with 'appendSequence': filter the appended sequence passed as argument * concatenating sequences with a class method like 'sequenceByConcatenatingSequences:' should first create the union of the symbolsets of the sequences passed as argument > >Another potential complication: what happens if the complement of a base >isn't in the same symbol set? Say someone makes an "all pyrimadine" symbol >set, then asks for its complement - we'd have to have some code to figure >out what symbol set is appropriate when creating the complement, so that we >could assign it to the resulting sequence... > I don't know what Koen had in mind when creating the symbol set class, because I see a 'complementSet' method there. Or we could impose that a set always is its own complement (this reminds me of some of my math classes, about groups and operations). But yes, the complement sequence would have to be defined using the complement symbol set. >I still think this is a good idea, but I think implementing it in a safe >manner is going to be very challenging, and we should think through all the >consequences and where we'd have to modify code before we even start to try >it. > You know, I did not realize all these implications until now, and there might indeed may be other issues we don't foresee yet. The user should not expect too much from the framework when she starts doing crazy things... Anyway, the bottom line is: should we use symbols sets or not? what for? charles -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021 From jtimmer at bellatlantic.net Mon Feb 28 19:41:56 2005 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 28 Feb 2005 19:41:56 -0500 Subject: [Biococoa-dev] More on BCSymbolSets In-Reply-To: Message-ID: >> You're typically going to be calling this method on a BCAbstractSequence to >> find out what kind of sequence it actually is. Making it a class method >> defeats this purpose. If you meant this to provide what the default is for >> the class as a whole, then the method should be named to reflect that. > > I am not sure I understand what you are saying. > I declared this class method, because it seems that all instances of > a given class will have the same sequence type. Is that right? In > fact, is there really a need for an ivar? An instance method could be > used instead that always return the same value in a given class. Do > you mean we should use an instance method instead, or do you mean we > should name this method 'defaultSequenceType'? Well, my point is regarding the following situation: you have an abstract sequence reference, which points to an actual sequence. You need to know what type of sequence that is, so you need to ask that instance "what sequence type are you?". You can't ask an instance for a class method. I guess you could get the instance's class and ask the class its sequence type, but that seems a bit awkward in comparison. Incidentally, how does ObjC work: you have a pointer typed to one thing, and it actually holds a subclass - when you request its class, what do you get? From kvddrift at earthlink.net Mon Feb 28 19:47:10 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 28 Feb 2005 19:47:10 -0500 Subject: [Biococoa-dev] More on BCSymbolSets In-Reply-To: References: Message-ID: <49dddfc55a41885485415cf3dbc0bab1@earthlink.net> On Feb 28, 2005, at 12:04 PM, John Timmer wrote: > So, let me refine my suggestion. We have a group of immutable sets > that > represent all the commonly used symbol sets. We initialize these out > of a > plist file I like the idea of using plists. This makes it much more flexible and allows users to create their own symbolsets. > Finally, I just want to sound a couple of notes of caution: > > By having a specific symbol set associated with a sequence, it means > we have > to do error testing whenever new symbols are added to the sequence, two > sequences are combined, etc. I think this one of the main reasons to use symbolsets. It allows the user to filter input and prevent illegal characters to be added. > We will ALWAYS have to make sure the symbol > set and sequenceArrays are rationalized. I actually like this, but got > scolded for being excessively cautious when I implemented something > like > this a while back ;). The advantage of symbolsets is that you ony have to test once. As soon as a symbol is added to an array we know it belongs to taht symbolset, and there is no more need for testing. IIRC, you were testing each symbol everytime in many methods, which was thought of as being too careful. - Koen. From kvddrift at earthlink.net Mon Feb 28 20:03:40 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 28 Feb 2005 20:03:40 -0500 Subject: [Biococoa-dev] More on BCSymbolSets In-Reply-To: References: Message-ID: <1fd716c728644fa55ff651f015037831@earthlink.net> On Feb 28, 2005, at 6:34 PM, Charles PARNOT wrote: > Anyway, the question at this point is: what do we want to do with > symbolSet? If they are just a way to provide a refinement on the > sequenceType, they we may not need a full class, but just an enum. And > if we don't enforce the sequence contents to be consistent with the > symbolSet, then it is useless. The idea of the symbolSet originates from a similar approach in BioPerl and BioJava, where they are called 'Alphabets'. Basically they can be used in cases when a users add a 'T' to a sequence, and wants to be sure they are a thymidine in DNA or a treonine in a protein. See also http://www.biojava.org/tutorials/chap1.html for more background. Although we all agree that the BioJava approach is cumbersome, I still like the idea of using a symbolset to define which symbols are allowed in a sequence. So it is not neccesarily a sequence identifier, but more a filter which defines which symbols are allowed in a specific type of sequence. Another possible reason at that time was that the symbolset could act as a sequece identifier, and thereby removing the need to subclass BCSequence. But that idea was not much appreciated here ;-) > So, what do you think symbolSet should be used for? The way I see it > now is as a filter to restrict the symbols used in a given sequence. > In fact, the more I think about it, the more 'filtering' seems like > what it should do. And if we don't want any restriction, then one can > always create very broad symbol sets. Exactly, see my point above. > > I don't know what Koen had in mind when creating the symbol set class, > because I see a 'complementSet' method there. This was actualy introduced by Alex. He wrote the interface, I filled in some of the implementation. And indeed I had no idea what to do with complementSet and a few other methods, so I have left those empty :-) - Koen. ps you guys are going *way* too fast with all those emails. I only have a limited time each day to read them, understand them and possibly reply to them. Sorry if I don't address all issues :( From kvddrift at earthlink.net Mon Feb 28 20:33:53 2005 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 28 Feb 2005 20:33:53 -0500 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: References: Message-ID: On Feb 28, 2005, at 12:08 PM, John Timmer wrote: > I've made the change, but the code isn't working properly, so the > change I > added has some debugging code nearby. For some reason, the category I > added > on NSMutableArrays isn't allowing them to sort based on Ranges stuffed > into > NSValues. I'll try to figure out what's gone wrong there later today. > Unfortunately, the translation demo won't compile, I get lots of errors saying that BCOtherSequence et al are already declared: /Users/koen/Documents/Development/Active Projects/FrameWorks/BioCocoa/build/BioCocoa.framework/Headers/ BCFoundationDefines.h:30: error: redeclaration of `enum BCSequenceType' /Users/koen/Documents/Development/Active Projects/FrameWorks/BioCocoa/build/BioCocoa.framework/Headers/ BCFoundationDefines.h:31: error: conflicting types for `BCOtherSequence' Also cc1obj (the actual compiler) crashes. John, you mentioned that you use Tiger, maybe you introduced some settings in the project that causes these errors? - Koen. From charles.parnot at stanford.edu Mon Feb 28 23:18:47 2005 From: charles.parnot at stanford.edu (Charles PARNOT) Date: Mon, 28 Feb 2005 20:18:47 -0800 Subject: [Biococoa-dev] BCToolTranslator In-Reply-To: References: Message-ID: did you try to clean? I don't get those errors. At 8:33 PM -0500 2/28/05, Koen van der Drift wrote: >On Feb 28, 2005, at 12:08 PM, John Timmer wrote: > >>I've made the change, but the code isn't working properly, so the change I >>added has some debugging code nearby. For some reason, the category I added >>on NSMutableArrays isn't allowing them to sort based on Ranges stuffed into >>NSValues. I'll try to figure out what's gone wrong there later today. >> > >Unfortunately, the translation demo won't compile, I get lots of errors saying that BCOtherSequence et al are already declared: > >/Users/koen/Documents/Development/Active Projects/FrameWorks/BioCocoa/build/BioCocoa.framework/Headers/BCFoundationDefines.h:30: error: redeclaration of `enum BCSequenceType' >/Users/koen/Documents/Development/Active Projects/FrameWorks/BioCocoa/build/BioCocoa.framework/Headers/BCFoundationDefines.h:31: error: conflicting types for `BCOtherSequence' > > >Also cc1obj (the actual compiler) crashes. John, you mentioned that you use Tiger, maybe you introduced some settings in the project that causes these errors? > >- Koen. > >_______________________________________________ >Biococoa-dev mailing list >Biococoa-dev at bioinformatics.org >https://bioinformatics.org/mailman/listinfo/biococoa-dev -- Help science go fast forward: http://cmgm.stanford.edu/~cparnot/xgrid-stanford/ Charles Parnot charles.parnot at stanford.edu Room B157 in Beckman Center 279, Campus Drive Stanford University Stanford, CA 94305 (USA) Tel +1 650 725 7754 Fax +1 650 725 8021