From peter.schols at bio.kuleuven.ac.be Fri Oct 1 06:50:36 2004 From: peter.schols at bio.kuleuven.ac.be (Peter Schols) Date: Fri, 1 Oct 2004 12:50:36 +0200 Subject: [Biococoa-dev] Re: CVS commit notifications In-Reply-To: <85F6927B-127C-11D9-BA70-003065A5FDCC@earthlink.net> References: <85F6927B-127C-11D9-BA70-003065A5FDCC@earthlink.net> Message-ID: It seems like we should add these files to the repository's CVSROOT, which we don't have permissions for. Even if we could add/commit these files, I'd be careful because I think they might affect all cvs projects at bioinformatics.org (although I'm not entirely sure about that). Can anyone confim this (you can inspect the rep. here: http://bioinformatics.org/cgi-bin/cvsweb.cgi/BioCocoa/ Three months ago, I switched all my personal projects to Subversion, which is much much better than CVS in almost every respect. Setting up a svn server was quite easy. On the client side svn integrates nicely with Xcode (1.5) and you can execute most commands by using svnX, a great freeware Cocoa front-end. I'd be willing to create a BioCocoa repository but the only problem is that I'm afraid our university network can't be accessed from outside the university (SSH and other ports are closed). peter On 30 Sep 2004, at 03:03, Koen van der Drift wrote: > Hi, > > To generate automated notifications after a cvs commit, we need to add > some files (loginfo and syncmail) to CVSROOT at the rootlevel of the > repository on bioinformatics.org. As an example see these two files > from the fink project: > > http://cvs.sourceforge.net/viewcvs.py/fink/CVSROOT/loginfo > http://cvs.sourceforge.net/viewcvs.py/fink/CVSROOT/syncmail > > This probably has to be done by the list administrator (Peter). > > We could create a separate mailinglist for that (biococoa-cvs). > > > cheers, > > - Koen. > From mek at mekentosj.com Fri Oct 1 07:41:10 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Fri, 1 Oct 2004 13:41:10 +0200 Subject: [Biococoa-dev] Re: CVS commit notifications In-Reply-To: References: <85F6927B-127C-11D9-BA70-003065A5FDCC@earthlink.net> Message-ID: I hear everyone telling about the great benefits of subversion, perhaps the best thing to do is convince bioinformatics to switch ;-) Alex Op 1-okt-04 om 12:50 heeft Peter Schols het volgende geschreven: > It seems like we should add these files to the repository's CVSROOT, > which we don't have permissions for. Even if we could add/commit these > files, I'd be careful because I think they might affect all cvs > projects at bioinformatics.org (although I'm not entirely sure about > that). Can anyone confim this (you can inspect the rep. here: > http://bioinformatics.org/cgi-bin/cvsweb.cgi/BioCocoa/ > > Three months ago, I switched all my personal projects to Subversion, > which is much much better than CVS in almost every respect. Setting up > a svn server was quite easy. On the client side svn integrates nicely > with Xcode (1.5) and you can execute most commands by using svnX, a > great freeware Cocoa front-end. > I'd be willing to create a BioCocoa repository but the only problem is > that I'm afraid our university network can't be accessed from outside > the university (SSH and other ports are closed). > > peter > > > On 30 Sep 2004, at 03:03, Koen van der Drift wrote: > >> Hi, >> >> To generate automated notifications after a cvs commit, we need to >> add some files (loginfo and syncmail) to CVSROOT at the rootlevel of >> the repository on bioinformatics.org. As an example see these two >> files from the fink project: >> >> http://cvs.sourceforge.net/viewcvs.py/fink/CVSROOT/loginfo >> http://cvs.sourceforge.net/viewcvs.py/fink/CVSROOT/syncmail >> >> This probably has to be done by the list administrator (Peter). >> >> We could create a separate mailinglist for that (biococoa-cvs). >> >> >> cheers, >> >> - 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 The requirements said: Windows 2000 or better. So I got a Macintosh. ********************************************************* From kvddrift at earthlink.net Thu Oct 14 20:54:31 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 14 Oct 2004 20:54:31 -0400 Subject: [Biococoa-dev] it's quiet Message-ID: Hi, No posts in a few weeks. Is everyone on vacation, fed up with coding, or just too busy? (the latter for me) - Koen. From jtimmer at bellatlantic.net Thu Oct 14 22:42:17 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 14 Oct 2004 22:42:17 -0400 Subject: [Biococoa-dev] it's quiet In-Reply-To: Message-ID: > Hi, > > No posts in a few weeks. Is everyone on vacation, fed up with coding, > or just too busy? > > (the latter for me) Too busy about covers it. I inherited my mother's house a while back, and it's finally got a buyer, meaning I have to do an estate sale, get an old oil heat tank removed, etc. etc. all by Nov 1. Don't even get me started on the science hassles... Cheers, JT _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Mon Oct 18 04:30:53 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Mon, 18 Oct 2004 10:30:53 +0200 Subject: [Biococoa-dev] it's quiet In-Reply-To: References: Message-ID: <06771946-20E0-11D9-A156-000D93AE89A4@mekentosj.com> Sorry guys, Just returned from a congress in Stockholm, a paper that needs another revision and with the end of the month arriving soon, we want to post our cube story on the website... bummer Cheers, Alex Op 15-okt-04 om 4:42 heeft John Timmer het volgende geschreven: >> Hi, >> >> No posts in a few weeks. Is everyone on vacation, fed up with coding, >> or just too busy? >> >> (the latter for me) > > Too busy about covers it. I inherited my mother's house a while back, > and > it's finally got a buyer, meaning I have to do an estate sale, get an > old > oil heat tank removed, etc. etc. all by Nov 1. > > Don't even get me started on the science hassles... > > 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 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 Fri Oct 22 22:12:37 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 22 Oct 2004 22:12:37 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? Message-ID: <02C5A55C-2499-11D9-9944-003065A5FDCC@earthlink.net> Hi, (Trying to get some life back into the group :-D I have been thinking a lot recently (again) if it is really needed to subclass BCSequence. One of the things that keeps bugging me for instance is the duplicated code in BCNucleotideDNA and BCNucleotideRNA for getting the subsequences. Somehow it doesn't seem the most efficient approach, and also not applying the OOP paradigms. One of the things that is central in OOP is trying to avoid code duplication. I also have been thinking a lot too to see what would be a better (if any) approach for these kind of situations. We could for instance put the code to get a range in a wrapper class. If we just use a BCSequence, the same code to get a range can be used for RNA, DNA, and Protein. Similarly, for other sequence charcteristics, or for reversing and translating a sequence. But if we only use a BCSequence, how do we know if we are dealing with a Protein, DNA, etc? Well, we already are using the BCSequenceType variable, which the wrapper could check for. Or, as discussed before, we implement Alphabets (symbolsets) which are then used by the wrapper to identify the type of sequence. Both approaches will also reduce the need for testing each symbol if it is really part of a Protein, DNA, etc. As a snippet we could use code like this to create a new DNA: BCSymbolSet *dnaSet = [[BCSymbolSet alloc] initWithCharacterSet: DNA]; // global BCSequence *myDNA = [[BCSequence alloc] initWithString; @"aaatttccctttggg] usingSymbolSet: dnaSet]; An addiitonal advantage of this approach is that when we think of a new cool feature to add to BioCocoa, we only have to put it in a wrapper class, instead of a slightly modified version in each of the subclasses of BCSequence. This is much easier to maintain, and also less prone to errors. I know that I have brought this up before, but I think it is important that we discuss it a little bit more, before BioCocoa expands further. cheers, - Koen. From jtimmer at bellatlantic.net Sat Oct 23 11:37:07 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Sat, 23 Oct 2004 11:37:07 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: <02C5A55C-2499-11D9-9944-003065A5FDCC@earthlink.net> Message-ID: Okay, once again, I feel compelled to point out that I'm arguing strongly, but this is a case of trying to make a compelling case, rather than the annoyed sort of arguing. > One of the things that keeps bugging me for > instance is the duplicated code in BCNucleotideDNA and BCNucleotideRNA > for getting the subsequences. As I said the last time this came up, I put this together quickly, and I intend to merge the common methods into an intervening class that's the common ancestor of DNA and RNA, both for the nucleotides and the sequences. If what's bothering you so much are the two range methods, I can easily change the names and have them more explicitly parallel the superclass - have the normal method just be the super's, and change the one that handles ambiguity changed to _loose (right now, the range method overrides the super's to allow ambiguity, and the super's method is called by a _strict method. I'm sure that makes no sense, but I think I know what's bothering Koen there) . The key thing is that they're not as good as they can be, but that doesn't mean there's a need to throw the whole structure out. > Somehow it doesn't seem the most > efficient approach, and also not applying the OOP paradigms. Collapsing a hierarchy of classes down to a single one isn't following OOP paradigms, either. The whole point of inheritance is to provide superclasses that hold common methods and subclass them to provide specific functionality. I think we've achieved that to a large extent. There's two other reasons I favor this structure: What you tend to do with DNA sequences and what you tend to do with protein sequences are typically very different - I don't see why they all the differences should be forced to reside in the same class. The second is the thing that Alex always champions (and I sometimes argue against ;) - we should try to represent every biological concept with an object, be it a codon, a sequence fragment, whatever. To make things more useful, it's better to force the code to reflect the biology, rather than distort the biology in order to have it conform to how we want to code. > An addiitonal advantage of this approach is that when we think of a new > cool feature to add to BioCocoa, we only have to put it in a wrapper > class, instead of a slightly modified version in each of the subclasses > of BCSequence. This is much easier to maintain, and also less prone to > errors. Well, if it works for all sequences, it belongs in the superclass. If it doesn't it can go in the subclass. I'm not sure what the wrapper adds here or how it eliminates complexity. If all it's doing is managing an array of symbols, then it doesn't seem to be doing much more than NSArray is. While we're engaging in a bit of redesigning suggestions, I have problems with the BCSequence variables startPosition, endPosition, and range. They don't reflect anything about the underlying sequence itself. My understanding is that they are there for selection/display type usage. Given that, if we're trying to follow a MVC design, they belong in a sequence controller object rather than in the sequence itself. Okay, back to my scheduled paper editing.... Cheers, JT _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Sat Oct 23 18:17:06 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 24 Oct 2004 00:17:06 +0200 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: <6682DD82-2540-11D9-A66F-003065A5FDCC@earthlink.net> References: <6682DD82-2540-11D9-A66F-003065A5FDCC@earthlink.net> Message-ID: <462BAB38-2541-11D9-BBCE-000D93AE89A4@mekentosj.com> >> There's two other reasons I favor this structure: What you tend to >> do with >> DNA sequences and what you tend to do with protein sequences are >> typically >> very different - I don't see why they all the differences should be >> forced >> to reside in the same class. > > They shouldn't be, although I fail to understand why getting a > subsequence is different for a DNA or protein. But that might be > because of my limited knowledge of the biology. In this particular example I don't see a difference either. In the end I guess one can come up with many examples where things are similar for both and where things are different. The feeling I have is that there are more of the latter... > > The same approach is used in other bio frameworks, such as biopython, > bioperl, and biojava, so it's been proven useful (if that means > anything). Anyway the popular vote seems to be winning, so I will rest > my case. 2:1 isn't particular a strong vote. Reminds me to the American elections... ;-) 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 kvddrift at earthlink.net Sat Oct 23 18:10:51 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 23 Oct 2004 18:10:51 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: References: Message-ID: <6682DD82-2540-11D9-A66F-003065A5FDCC@earthlink.net> On Oct 23, 2004, at 11:37 AM, John Timmer wrote: > > If what's bothering you so much are the two range methods, I can easily > change the names and have them more explicitly parallel the superclass > - > have the normal method just be the super's, and change the one that > handles > ambiguity changed to _loose (right now, the range method overrides the > super's to allow ambiguity, and the super's method is called by a > _strict > method. I'm sure that makes no sense, but I think I know what's > bothering > Koen there) . The key thing is that they're not as good as they can > be, but > that doesn't mean there's a need to throw the whole structure out. As far as I know there aren't any other examples in BioCocoa right now, which is why I used the subrange code as an example. But there might be similar situations in the future while we expand BioCocoa. I now do remember it's on your todo list to merge this code for all sequences (including proteins I guess). In no means I was trying to throw the whole structure out, I was thinking aloud how we could improve the structure. We both agree that there is a need for improvement, only still differ on how. It might well be a good idea to implement both solutions, so there's more than one way to do it. I will look into that. > > There's two other reasons I favor this structure: What you tend to do > with > DNA sequences and what you tend to do with protein sequences are > typically > very different - I don't see why they all the differences should be > forced > to reside in the same class. They shouldn't be, although I fail to understand why getting a subsequence is different for a DNA or protein. But that might be because of my limited knowledge of the biology. > The second is the thing that Alex always > champions (and I sometimes argue against ;) - we should try to > represent > every biological concept with an object, be it a codon, a sequence > fragment, > whatever. To make things more useful, it's better to force the code to > reflect the biology, rather than distort the biology in order to have > it > conform to how we want to code. That's definitely a very good point. My argument is that we can have just a general sequence object, with additional information that identifies the type of sequence. I don't think that's distorting biology, and I am afraid that's where we don't agree on. The same approach is used in other bio frameworks, such as biopython, bioperl, and biojava, so it's been proven useful (if that means anything). Anyway the popular vote seems to be winning, so I will rest my case. > > >> An addiitonal advantage of this approach is that when we think of a >> new >> cool feature to add to BioCocoa, we only have to put it in a wrapper >> class, instead of a slightly modified version in each of the >> subclasses >> of BCSequence. This is much easier to maintain, and also less prone to >> errors. > Well, if it works for all sequences, it belongs in the superclass. If > it > doesn't it can go in the subclass. I'm not sure what the wrapper adds > here > or how it eliminates complexity. If all it's doing is managing an > array of > symbols, then it doesn't seem to be doing much more than NSArray is. The idea of using wrappers is to keep the superclass lightweight, and use small modules to add functionality. If we keep adding functionality to the superclass things become difficult to maintain quickly (and I speak from experience ;) Maybe it adds a level of complexity, but each task is well defined in one class. > > > While we're engaging in a bit of redesigning suggestions, I have > problems > with the BCSequence variables startPosition, endPosition, and range. > They > don't reflect anything about the underlying sequence itself. My > understanding is that they are there for selection/display type usage. > Given that, if we're trying to follow a MVC design, they belong in a > sequence controller object rather than in the sequence itself. All the sequence manipulation we do now is zero-based, which is how NSArray works. We need to make a decision if we want to keep it that way, and only move to a 1-based index when interacting with a GUI. In that case startPosition, endPosition, and range indeed could go into some controller class. Or we make all our sequences 1-based (maybe by adding a dummy symbol at index 0). - Koen. From mek at mekentosj.com Sat Oct 23 17:59:50 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 23 Oct 2004 23:59:50 +0200 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: References: Message-ID: Hi guys, Although I most certainly applaud further improvements and reorganisations where necessary/possible, I agree with John primarily for the reason he already coupled to my name ;-) I guess there's something to say for both solutions, what Koen is proposing is the "bioJava" way. We have had previous discussions but right now I'm still in favour of the way things are setup right now, John has described my opinion pretty nicely as well. > While we're engaging in a bit of redesigning suggestions, I have > problems > with the BCSequence variables startPosition, endPosition, and range. > They > don't reflect anything about the underlying sequence itself. My > understanding is that they are there for selection/display type usage. I think we should think a bit of how to setup annotations and features, that's what these things should be in. Once that is in place, one can add as many start and stop positions as he/she wants. We can than get rid of these here. > Given that, if we're trying to follow a MVC design, they belong in a > sequence controller object rather than in the sequence itself. Perhaps rather in a wrapper object (that if necessary a controller generates). This has been described in the discussions between Koen and me about restriction enzymes. Cheers, Alex Ps. Today finally another milestone towards more programming time for BioCocoa, we have completed the story on the design award cube. It's now online on our website: http://www.mekentosj.com/goodies/cubism Enjoy!! Op 23-okt-04 om 17:37 heeft John Timmer het volgende geschreven: > Okay, once again, I feel compelled to point out that I'm arguing > strongly, > but this is a case of trying to make a compelling case, rather than the > annoyed sort of arguing. > > >> One of the things that keeps bugging me for >> instance is the duplicated code in BCNucleotideDNA and BCNucleotideRNA >> for getting the subsequences. > As I said the last time this came up, I put this together quickly, and > I > intend to merge the common methods into an intervening class that's the > common ancestor of DNA and RNA, both for the nucleotides and the > sequences. > > If what's bothering you so much are the two range methods, I can easily > change the names and have them more explicitly parallel the superclass > - > have the normal method just be the super's, and change the one that > handles > ambiguity changed to _loose (right now, the range method overrides the > super's to allow ambiguity, and the super's method is called by a > _strict > method. I'm sure that makes no sense, but I think I know what's > bothering > Koen there) . The key thing is that they're not as good as they can > be, but > that doesn't mean there's a need to throw the whole structure out. > > >> Somehow it doesn't seem the most >> efficient approach, and also not applying the OOP paradigms. > Collapsing a hierarchy of classes down to a single one isn't following > OOP > paradigms, either. The whole point of inheritance is to provide > superclasses that hold common methods and subclass them to provide > specific > functionality. I think we've achieved that to a large extent. > > There's two other reasons I favor this structure: What you tend to do > with > DNA sequences and what you tend to do with protein sequences are > typically > very different - I don't see why they all the differences should be > forced > to reside in the same class. The second is the thing that Alex always > champions (and I sometimes argue against ;) - we should try to > represent > every biological concept with an object, be it a codon, a sequence > fragment, > whatever. To make things more useful, it's better to force the code to > reflect the biology, rather than distort the biology in order to have > it > conform to how we want to code. > > >> An addiitonal advantage of this approach is that when we think of a >> new >> cool feature to add to BioCocoa, we only have to put it in a wrapper >> class, instead of a slightly modified version in each of the >> subclasses >> of BCSequence. This is much easier to maintain, and also less prone to >> errors. > Well, if it works for all sequences, it belongs in the superclass. If > it > doesn't it can go in the subclass. I'm not sure what the wrapper adds > here > or how it eliminates complexity. If all it's doing is managing an > array of > symbols, then it doesn't seem to be doing much more than NSArray is. > > > While we're engaging in a bit of redesigning suggestions, I have > problems > with the BCSequence variables startPosition, endPosition, and range. > They > don't reflect anything about the underlying sequence itself. My > understanding is that they are there for selection/display type usage. > Given that, if we're trying to follow a MVC design, they belong in a > sequence controller object rather than in the sequence itself. > > Okay, back to my scheduled paper editing.... > > 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 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 Sat Oct 23 23:51:45 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Sat, 23 Oct 2004 23:51:45 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: <462BAB38-2541-11D9-BBCE-000D93AE89A4@mekentosj.com> Message-ID: >>> There's two other reasons I favor this structure: What you tend to >>> do with >>> DNA sequences and what you tend to do with protein sequences are >>> typically >>> very different - I don't see why they all the differences should be >>> forced >>> to reside in the same class. >> >> They shouldn't be, although I fail to understand why getting a >> subsequence is different for a DNA or protein. But that might be >> because of my limited knowledge of the biology. If you're asking for the range of a subsequence (which is what the methods I was referring to do), then there is a difference. With amino acids, there's no ambiguity - what you ask for is what you find. With nucleotides, what happens if you ask for GARNYTC? You could either be asking for an exact match, in which case the same method as with amino acids would work. Or you could be asking for any sequence that might match that, such as GAAACTC and GAGGCTC etc. Clearly, you need a second method for that. There's situations where you'd want one or the other (or at least I would), so it's definitely worth providing both. Cheers, JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Sun Oct 24 14:03:55 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 24 Oct 2004 14:03:55 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: References: Message-ID: <11D1A937-25E7-11D9-902A-003065A5FDCC@earthlink.net> On Oct 23, 2004, at 5:59 PM, Alexander Griekspoor wrote: >> While we're engaging in a bit of redesigning suggestions, I have >> problems >> with the BCSequence variables startPosition, endPosition, and range. >> They >> don't reflect anything about the underlying sequence itself. My >> understanding is that they are there for selection/display type usage. > I think we should think a bit of how to setup annotations and > features, that's what these things should be in. Once that is in > place, one can add as many start and stop positions as he/she wants. > We can than get rid of these here. I will remove them from BCSequence. - Koen. From kvddrift at earthlink.net Sun Oct 24 14:27:06 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 24 Oct 2004 14:27:06 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: References: Message-ID: <4F08AF2C-25EA-11D9-902A-003065A5FDCC@earthlink.net> On Oct 23, 2004, at 11:51 PM, John Timmer wrote: > If you're asking for the range of a subsequence (which is what the > methods I > was referring to do), then there is a difference. With amino acids, > there's no ambiguity - what you ask for is what you find. With > nucleotides, > what happens if you ask for GARNYTC? You could either be asking for an > exact match, in which case the same method as with amino acids would > work. > Or you could be asking for any sequence that might match that, such as > GAAACTC and GAGGCTC etc. Clearly, you need a second method for that. > There's situations where you'd want one or the other (or at least I > would), > so it's definitely worth providing both. > Aha, thanks! - Koen. From kvddrift at earthlink.net Sun Oct 24 17:26:18 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 24 Oct 2004 17:26:18 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: References: Message-ID: <579FA896-2603-11D9-A50B-003065A5FDCC@earthlink.net> On Oct 23, 2004, at 5:59 PM, Alexander Griekspoor wrote: > I think we should think a bit of how to setup annotations and > features, that's what these things should be in. Once that is in > place, one can add as many start and stop positions as he/she wants. > We can than get rid of these here. > Good idea, that will also allow us to start working on the BCSequenceIO classes. Already a few things come to mind: 1. Should we have just one BCSequenceReader class, which takes care of all various file formats, or should we subclass for each format? I'm not sure yet what the best solution is. 2. Some formats can contain multiple seqeuences (eg fasta). Should we return an NSArray of BCSequences only in those cases, or to be more consistent for all formats? I suggest the latter. 3. Do we need an additional class that holds the BCSequence plus all other info, or should everything go into the BCSequence class? shoot away :D - Koen. From kvddrift at earthlink.net Sun Oct 24 17:32:37 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 24 Oct 2004 17:32:37 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: References: Message-ID: <3980E03E-2604-11D9-A50B-003065A5FDCC@earthlink.net> On Oct 23, 2004, at 5:59 PM, Alexander Griekspoor wrote: > Ps. Today finally another milestone towards more programming time for > BioCocoa, we have completed the story on the design award cube. It's > now online on our website: http://www.mekentosj.com/goodies/cubism > Enjoy!! > How does it feel te be slashdotted? http://apple.slashdot.org/comments.pl? sid=126911&threshold=1&mode=flat&commentsort=0&op=Change ;-) - Koen. From mek at mekentosj.com Sun Oct 24 17:33:19 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 24 Oct 2004 23:33:19 +0200 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: <579FA896-2603-11D9-A50B-003065A5FDCC@earthlink.net> References: <579FA896-2603-11D9-A50B-003065A5FDCC@earthlink.net> Message-ID: <5285DAAE-2604-11D9-9BC4-000D93AE89A4@mekentosj.com> Just a few ideas in between the praying that are website will withstand being slashdotted ;-) > 1. Should we have just one BCSequenceReader class, which takes care of > all various file formats, or should we subclass for each format? I'm > not sure yet what the best solution is. Given the large number of different formats, I'm a bit afraid that we will end up with way to many subclasses It might also be a problem to have a general "find-out-what-format-it-is-and-handle-it" method, although this could be handled in a superclass. I'm not sure on this one either. > > 2. Some formats can contain multiple seqeuences (eg fasta). Should we > return an NSArray of BCSequences only in those cases, or to be more > consistent for all formats? I suggest the latter. I love consistency, but we can have some convenience methods to get only the first or a range of sequences. > > 3. Do we need an additional class that holds the BCSequence plus all > other info, or should everything go into the BCSequence class? Good question, I would tend to go with everything in BCSequence to avoid another wrapper, after all it is a property of the BCSequence... 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 kvddrift at earthlink.net Sun Oct 24 20:11:44 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 24 Oct 2004 20:11:44 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: <5285DAAE-2604-11D9-9BC4-000D93AE89A4@mekentosj.com> References: <579FA896-2603-11D9-A50B-003065A5FDCC@earthlink.net> <5285DAAE-2604-11D9-9BC4-000D93AE89A4@mekentosj.com> Message-ID: <741E5AEF-261A-11D9-A50B-003065A5FDCC@earthlink.net> On Oct 24, 2004, at 5:33 PM, Alexander Griekspoor wrote: > Just a few ideas in between the praying that are website will > withstand being slashdotted ;-) > >> 1. Should we have just one BCSequenceReader class, which takes care >> of all various file formats, or should we subclass for each format? >> I'm not sure yet what the best solution is. > Given the large number of different formats, I'm a bit afraid that we > will end up with way to many subclasses It might also be a problem to > have a general "find-out-what-format-it-is-and-handle-it" method, > although this could be handled in a superclass. I'm not sure on this > one either. My gut feeling says to use a general read-sequence class that can be passed a format identifier: BCSequenceReader* myReader = [[BCSequenceReader alloc] init]; BCSequence *mySequence = [myReader readSequenceFromFile: aFile usingFormat: @"fasta"]; (this is the bioperl approach) and additionally: BCSequence *mySequence = [myReader readSequenceFromFastaFile: aFile]; (this is the biojava approach) or even: BCSequence *mySequence = [myReader readSequenceFromFile: aFile]; The current BCReader class has some code to determine the file format which we could use. >> >> 2. Some formats can contain multiple seqeuences (eg fasta). Should we >> return an NSArray of BCSequences only in those cases, or to be more >> consistent for all formats? I suggest the latter. > I love consistency, but we can have some convenience methods to get > only the first or a range of sequences. Sounds good. >> >> 3. Do we need an additional class that holds the BCSequence plus all >> other info, or should everything go into the BCSequence class? > Good question, I would tend to go with everything in BCSequence to > avoid another wrapper, after all it is a property of the BCSequence... Hmm, the additional info is probably what we call annotations and features. But it is very variable dependeing on the file format. I would keep the BCSequence class small, it's only task is to maintain a sequence. We could use 'decorator' objects for these situations. - Koen. From kvddrift at earthlink.net Tue Oct 26 17:59:22 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 26 Oct 2004 17:59:22 -0400 Subject: [Biococoa-dev] CocoaDev entry Message-ID: <4AFCFB4E-279A-11D9-8658-003065A5FDCC@earthlink.net> Hi, While editing my own entry, I added an entry for BioCocoa to the CocoaDev wiki. Have a look and feel free to edit it. http://www.cocoadev.com/index.pl?BioCocoa - Koen. From kvddrift at earthlink.net Wed Oct 27 17:32:21 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 27 Oct 2004 17:32:21 -0400 Subject: [Biococoa-dev] accessorizer tool Message-ID: Hi all, Check out this: http://www.kevincallahan.org/software/accessorizer.html A handy tool for quickly writing accessor methods in Xcode. - Koen. From mek at mekentosj.com Wed Oct 27 17:38:29 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 27 Oct 2004 23:38:29 +0200 Subject: [Biococoa-dev] accessorizer tool In-Reply-To: References: Message-ID: <8B0555F1-2860-11D9-A821-000D93AE89A4@mekentosj.com> Very nice indeed, although I have been using Scotland Software's Objective-C service for a long time already, which saved me tons of typing. It is definitely less extensive, but does its job perfectly well. The nice thing of a service is that you simply highlight the stuff within XCode and doesn't require copy pasting.. http://www.scotlandsoftware.com/products/systemservices/ Alex Op 27-okt-04 om 23:32 heeft Koen van der Drift het volgende geschreven: > Hi all, > > Check out this: > > http://www.kevincallahan.org/software/accessorizer.html > > > A handy tool for quickly writing accessor methods in Xcode. > > > - 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 Thu Oct 28 22:00:54 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 28 Oct 2004 22:00:54 -0400 Subject: [Biococoa-dev] Subclassing BCSequence really needed? In-Reply-To: <6682DD82-2540-11D9-A66F-003065A5FDCC@earthlink.net> References: <6682DD82-2540-11D9-A66F-003065A5FDCC@earthlink.net> Message-ID: <5DE8ACC0-294E-11D9-9B65-003065A5FDCC@earthlink.net> On Oct 23, 2004, at 6:10 PM, Koen van der Drift wrote: > As far as I know there aren't any other examples in BioCocoa right > now, which is why I used the subrange code as an example. But there > might be similar situations in the future while we expand BioCocoa. I > now do remember it's on your todo list to merge this code for all > sequences (including proteins I guess). In no means I was trying to > throw the whole structure out, I was thinking aloud how we could > improve the structure. We both agree that there is a need for > improvement, only still differ on how. It might well be a good idea to > implement both solutions, so there's more than one way to do it. I > will look into that. > > To keep my promise, I just added a new class BCFindSequence, that can be used to find a subsequence (duh), similarly to John's rangeOfSubsequence methods. In fact, I copied most of that code :-) I have not done the multiple ranges yet, because I wanted to see how this works first. The class has a member strict, that can be set if needed, default is YES. It compiles fine, but I have not yet tried to test it, we don't have a test example right now. Let me know what you think. Also, the symbol counting code is now moved to a separate class, BCSymbolCounter. Both classes reside in a new folder, BCSequenceTools in BCTools. cheers, - Koen. From kvddrift at earthlink.net Sat Oct 30 09:13:02 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 30 Oct 2004 09:13:02 -0400 Subject: [Biococoa-dev] rangeOfSubsequence problem Message-ID: <6DE0E52A-2A75-11D9-9ECD-003065A5FDCC@earthlink.net> Hi, While working on the wrapper class for rangeOfSubsequence, I think I found some errors in the current code that's in the various BCSequence files. I had to change the following : if ( theLimit.location + theLimit.length >= [sequenceArray count] ) should be: if ( theLimit.location + theLimit.length > [sequenceArray count] ) and the two lines: entryBase = (BCNucleotideDNA *)CFArrayGetValueAtIndex( (CFArrayRef) entry, 0); should be: entryBase = (BCNucleotideDNA *)CFArrayGetValueAtIndex( (CFArrayRef) [entry sequenceArray], 0); It works now, except when the search string is at the end of the sequence, then I get an out of bounds error. Haven't tracked that one yet, though. To test the code, just add this to the translation demo: NSRange foundIt = [theSequence rangeOfSubsequence: [BCSequenceDNA DNASequenceWithString: @"AAT" skippingNonBases: YES]]; NSLog ( @"%i %i", foundIt.location, foundIt.length ); cheers, - Koen. From kvddrift at earthlink.net Sat Oct 30 23:21:09 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 30 Oct 2004 23:21:09 -0400 Subject: [Biococoa-dev] rangeOfSubsequence problem In-Reply-To: <6DE0E52A-2A75-11D9-9ECD-003065A5FDCC@earthlink.net> References: <6DE0E52A-2A75-11D9-9ECD-003065A5FDCC@earthlink.net> Message-ID: On Oct 30, 2004, at 9:13 AM, Koen van der Drift wrote: > It works now, except when the search string is at the end of the > sequence, then I get an out of bounds error. Haven't tracked that one > yet, though. Figured that one out, and made it work with multiple ranges. Please test BCFindSequence it to make sure I didn't screw up :) cheers, - Koen. From kvddrift at earthlink.net Sun Oct 31 11:40:23 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 31 Oct 2004 11:40:23 -0500 Subject: [Biococoa-dev] BCCodon init question Message-ID: <8FA1F618-2B5B-11D9-8785-003065A5FDCC@earthlink.net> Hi, I was trying to figure out why the current translation demo is not working (no protein is displayed in the right panel). So after some debugging I found that both BCCodonDNA and BCCodonRNA call self = [super init] in their init method. However, the super init method (BCCodon) always returns nil, so BCCodonDNA and BCCodonRNA always return nil. I commented out the init method of BCCodon, and now indeed I see a protein sequence in the right panel. Not sure if this is the intended way to make this work, though. John, is their a particular reason why BCCodon's init() always returns nil? thanks, - Koen.