From jtimmer at bellatlantic.net Wed Sep 1 14:34:58 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 01 Sep 2004 14:34:58 -0400 Subject: [Biococoa-dev] Translation In-Reply-To: Message-ID: Ugh - the code works and is a lot cleaner and easier to follow, but takes twice as long. Looks like I'm going to have to learn to use the performance tools to figure out where the hangups are. I'm at home, so I can't commit it to CVS, but I'll send everything necessary for anyone who wants to look it over. JT > > On Aug 31, 2004, at 6:53 PM, John Timmer wrote: > >> Okay, I'll commit my current controller.m. > > > I have added Alex's code to John's commit plus some additional goodies. > > > - Koen. > _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Wed Sep 1 18:08:25 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 1 Sep 2004 18:08:25 -0400 Subject: [Biococoa-dev] Re: Translation In-Reply-To: References: Message-ID: <7206ACB4-FC63-11D8-A4C0-003065A5FDCC@earthlink.net> On Sep 1, 2004, at 2:34 PM, John Timmer wrote: > Ugh - the code works and is a lot cleaner and easier to follow, but > takes > twice as long. which part of the code? - Koen. From jtimmer at bellatlantic.net Wed Sep 1 20:04:11 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 01 Sep 2004 20:04:11 -0400 Subject: [Biococoa-dev] Translation In-Reply-To: Message-ID: > Ugh - the code works and is a lot cleaner and easier to follow, but takes > twice as long. Looks like I'm going to have to learn to use the performance > tools to figure out where the hangups are. > > I'm at home, so I can't commit it to CVS, but I'll send everything necessary > for anyone who wants to look it over. > I had a brief window where bioinformatics.org appeared, and I added a bunch of stuff then, so the code may be visible. It requires a different .plist format which I didn't manage to upload, though, so it is currently non-functional. Shark turned out to be incredibly easy to use. I just looped through the translation 100 times while sampling, and out popped a list of what's being done sorted by percent of CPU use. About 28% of the time is being used by ObjC_msgSend, another 17% or so with array index related stuff. This isn't really surprising, given that we've injected another object layer (the codons) into the process. I'm thinking I might be able to remove the BCSequenceDNA from the codon and just store all three bases as variables, and pull the array out of the sequence being translated and deal with the base array directly - both of these should cut down on the messaging substantially. Hopefully, a positive report later this evening - John _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Wed Sep 1 20:33:34 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 1 Sep 2004 20:33:34 -0400 Subject: [Biococoa-dev] rangeOfSubsequence fix Message-ID: Hi, I posted this a few days ago, but got no answer yet - maybe everyone's busy ;) Anyway, if you get the time to look into this, I'd appreciate it. ---------- >> What I am trying to get at is to see if it is possible to have a >> separate method to test the entrySymbol and selfSymbol that goes in >> BCNucleotideDNA and BCAminoAcid (or BCSequenceDNA and >> BCSequenceProtein). Then we can keep all the rangeOfSubsequence in >> BCSequence. > Perhaps it's indeed a good plan to let BCSymbol have the > isRepresentedBySymbol method that BCNucleotideDNA overrides to check > for ambiguous bases as well, that way BCSequence could have the > general methods. > Here is my suggestion, but I don't know if this will work. Make the following method in BCSymbol: -(BOOL) isRepresentedBySymbol : (BCSymbol *)aSymbol { return (self == aSymbol); } Then override this for BCNucleotideDNA to do all the ambiguity testing. Now the method - (NSRange) rangeOfSubsequence: (BCSequence *)entry withinRange: (NSRange)theLimit can be much simplified and only needs to be in BCSequence: - (NSRange) rangeOfSubsequence: (BCSequence *)entry withinRange: (NSRange)theLimit { // do bounds checking if ( theLimit.location + theLimit.length >= [sequenceArray count] ) return NSMakeRange( NSNotFound, 0); // get the region to check NSArray *subSequence = [sequenceArray subarrayWithRange: theLimit]; int loopCounter; BCSymbol *entrySymbol, *selfSymbol; BOOL haveMatch = NO; for ( loopCounter = 0 ; loopCounter < [subSequence count] - [entry length] ; loopCounter++ ) { selfSymbol = [subSequence objectAtIndex: loopCounter]; entrySymbol = [entry symbolAtIndex: 0]; haveMatch = [selfSymbol isRepresentedBySymbol: entrySymbol]; if ( haveMatch ) return NSMakeRange( loopCounter, [entry length] ); } } // went through the whole sequence without finding anything return NSMakeRange( NSNotFound, 0); } The same can be done for - (NSArray *) rangesOfSubsequence: (BCSequence *)entry There is no need for having the same code in a super and derived class, so it should all be removed from BCSequenceDNA. However, just copy-paste the following to BCNucleotideDNA won't work, because 'entry' and 'subSequence' are part of the rangesOfSubsequence method. if ( [selfBase isRepresentedByBase: entryBase] || [entryBase isRepresentedByBase: selfBase] ) { haveMatch = YES; innerCounter = 1; // go through and compare each base while ( innerCounter < [entry length] ) { selfBase = [subSequence objectAtIndex: loopCounter + innerCounter]; entryBase = [entry symbolAtIndex: innerCounter]; if ( ![selfBase isRepresentedByBase: entryBase] && ![entryBase isRepresentedByBase: selfBase] ) { // exit without a match if we fail that comparison innerCounter = [entry length]; haveMatch = NO; } innerCounter ++; } I don't want to break the algorithm, so if anyone has a suggestion how to approach this, could you commit it or post it here? thanks, - Koen. From mek at mekentosj.com Thu Sep 2 01:59:07 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 2 Sep 2004 07:59:07 +0200 Subject: [Biococoa-dev] rangeOfSubsequence fix In-Reply-To: References: Message-ID: <33D923B8-FCA5-11D8-80BF-000393CFDE0C@mekentosj.com> Hi Koen, Indeed very busy ;-) But I think in this it's really between John and you what to decide. Things are to specific for me, being not really into the code, to say much. It sounds all very logical and it would be nice if we could dramatically simply the code... I would say go ahead, but John will have his words as well I guess... Cheers, Alex > Here is my suggestion, but I don't know if this will work. Make the > following method in BCSymbol: > > > -(BOOL) isRepresentedBySymbol : (BCSymbol *)aSymbol > { > return (self == aSymbol); > } > > > Then override this for BCNucleotideDNA to do all the ambiguity > testing. Now the method - (NSRange) rangeOfSubsequence: (BCSequence > *)entry withinRange: (NSRange)theLimit can be much simplified and only > needs to be in BCSequence: > > - (NSRange) rangeOfSubsequence: (BCSequence *)entry withinRange: > (NSRange)theLimit { > // do bounds checking > if ( theLimit.location + theLimit.length >= [sequenceArray count] ) > return NSMakeRange( NSNotFound, 0); > > // get the region to check > NSArray *subSequence = [sequenceArray subarrayWithRange: theLimit]; > > int loopCounter; > BCSymbol *entrySymbol, *selfSymbol; > BOOL haveMatch = NO; > > for ( loopCounter = 0 ; loopCounter < [subSequence count] - [entry > length] ; loopCounter++ ) { > selfSymbol = [subSequence objectAtIndex: loopCounter]; > entrySymbol = [entry symbolAtIndex: 0]; > > haveMatch = [selfSymbol isRepresentedBySymbol: entrySymbol]; > > if ( haveMatch ) > return NSMakeRange( loopCounter, [entry length] ); > > } > > } > // went through the whole sequence without finding anything > return NSMakeRange( NSNotFound, 0); > } > > The same can be done for - (NSArray *) rangesOfSubsequence: > (BCSequence *)entry > > There is no need for having the same code in a super and derived > class, so it should all be removed from BCSequenceDNA. > > However, just copy-paste the following to BCNucleotideDNA won't work, > because 'entry' and 'subSequence' are part of the > rangesOfSubsequence method. > > > if ( [selfBase isRepresentedByBase: entryBase] || [entryBase > isRepresentedByBase: selfBase] ) { > haveMatch = YES; > innerCounter = 1; > // go through and compare each base > while ( innerCounter < [entry length] ) { > selfBase = [subSequence objectAtIndex: loopCounter + > innerCounter]; > entryBase = [entry symbolAtIndex: innerCounter]; > > if ( ![selfBase isRepresentedByBase: entryBase] && > ![entryBase isRepresentedByBase: selfBase] ) { > // exit without a match if we fail that comparison > innerCounter = [entry length]; > haveMatch = NO; > } > innerCounter ++; > } > > > I don't want to break the algorithm, so if anyone has a suggestion how > to approach this, could you commit it or post it here? > > > 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 Mac vs Windows 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 MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From kvddrift at earthlink.net Thu Sep 2 17:47:01 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 2 Sep 2004 17:47:01 -0400 Subject: [Biococoa-dev] [BioCocoa] My first (tiny) contribution In-Reply-To: <3870ED56-FB7E-11D8-80BF-000393CFDE0C@nki.nl> References: <3870ED56-FB7E-11D8-80BF-000393CFDE0C@nki.nl> Message-ID: <9F769620-FD29-11D8-B1EB-003065A5FDCC@earthlink.net> On Aug 31, 2004, at 2:47 PM, Alexander Griekspoor wrote: > To make things a bit more quantitative I've added a few lines of code > to John's demo_app, which displays the time it took to process your > code. It also adds a custom field that you can use to log one kind of > extra info. In the demo_app it shows the number of input > nucleotides... Perhaps you can commit it for me Koen, I know how to > commit, but do not have the experience to make sure it ends up in the > demo_app folder... > Alex, I think this is already in CVS, at least the code in theController.m doesn't look different. I also made some addtions last night (MW for the protein). - Koen. From kvddrift at earthlink.net Thu Sep 2 17:47:01 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 2 Sep 2004 17:47:01 -0400 Subject: [Biococoa-dev] [BioCocoa] My first (tiny) contribution In-Reply-To: <3870ED56-FB7E-11D8-80BF-000393CFDE0C@nki.nl> References: <3870ED56-FB7E-11D8-80BF-000393CFDE0C@nki.nl> Message-ID: <9F769620-FD29-11D8-B1EB-003065A5FDCC@earthlink.net> On Aug 31, 2004, at 2:47 PM, Alexander Griekspoor wrote: > To make things a bit more quantitative I've added a few lines of code > to John's demo_app, which displays the time it took to process your > code. It also adds a custom field that you can use to log one kind of > extra info. In the demo_app it shows the number of input > nucleotides... Perhaps you can commit it for me Koen, I know how to > commit, but do not have the experience to make sure it ends up in the > demo_app folder... > Alex, I think this is already in CVS, at least the code in theController.m doesn't look different. I also made some addtions last night (MW for the protein). - Koen. From a.griekspoor at nki.nl Thu Sep 2 17:51:33 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Thu, 2 Sep 2004 23:51:33 +0200 Subject: [Biococoa-dev] [BioCocoa] My first (tiny) contribution In-Reply-To: <9F769620-FD29-11D8-B1EB-003065A5FDCC@earthlink.net> References: <3870ED56-FB7E-11D8-80BF-000393CFDE0C@nki.nl> <9F769620-FD29-11D8-B1EB-003065A5FDCC@earthlink.net> Message-ID: <419D2486-FD2A-11D8-B507-000393CFDE0C@nki.nl> You're right Koen, this was the mail held for moderator approval. Apparently Peter has allowed it to be send (a few days late therefore)... Alex Op 2-sep-04 om 23:47 heeft Koen van der Drift het volgende geschreven: > > On Aug 31, 2004, at 2:47 PM, Alexander Griekspoor wrote: > >> To make things a bit more quantitative I've added a few lines of code >> to John's demo_app, which displays the time it took to process your >> code. It also adds a custom field that you can use to log one kind of >> extra info. In the demo_app it shows the number of input >> nucleotides... Perhaps you can commit it for me Koen, I know how to >> commit, but do not have the experience to make sure it ends up in the >> demo_app folder... >> > > Alex, > > I think this is already in CVS, at least the code in theController.m > doesn't look different. I also made some addtions last night (MW for > the protein). > > > > - 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 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 jtimmer at bellatlantic.net Fri Sep 3 13:59:12 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Fri, 03 Sep 2004 13:59:12 -0400 Subject: [Biococoa-dev] Translation In-Reply-To: Message-ID: I've checked in some updated code, still using codons but having moved a bunch of things into arrays, rather than using BCSequenceDNA objects. The time is down by a bit, but not a whole lot (maybe about 10-15% - it's just under .4 seconds now). ObjC_msgSend is down to about 23%, and testing whether a base in the codon represents one in the sequence is up to about 17.5%. Since that's the most important step, I view this as a bit of progress. I'm not sure if there's any other obvious ways for me to squeeze performance out of this - please look over the code and offer suggestions. JT > > I had a brief window where bioinformatics.org appeared, and I added a bunch > of stuff then, so the code may be visible. It requires a different .plist > format which I didn't manage to upload, though, so it is currently > non-functional. > > Shark turned out to be incredibly easy to use. I just looped through the > translation 100 times while sampling, and out popped a list of what's being > done sorted by percent of CPU use. About 28% of the time is being used by > ObjC_msgSend, another 17% or so with array index related stuff. > > This isn't really surprising, given that we've injected another object layer > (the codons) into the process. I'm thinking I might be able to remove the > BCSequenceDNA from the codon and just store all three bases as variables, > and pull the array out of the sequence being translated and deal with the > base array directly - both of these should cut down on the messaging > substantially. > > Hopefully, a positive report later this evening - > > John > > _______________________________________________ > This mind intentionally left blank > > _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Fri Sep 3 18:55:11 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 3 Sep 2004 18:55:11 -0400 Subject: [Biococoa-dev] Translation In-Reply-To: References: Message-ID: <4F843712-FDFC-11D8-B1EB-003065A5FDCC@earthlink.net> On Sep 3, 2004, at 1:59 PM, John Timmer wrote: > I've checked in some updated code, still using codons but having moved > a > bunch of things into arrays, rather than using BCSequenceDNA objects. > John, I seem to be missing BCGeneticCodeName, I get a bunch of errors related to that. Did you forget to commit that file? > The time is down by a bit, but not a whole lot (maybe about 10-15% - > it's > just under .4 seconds now). ObjC_msgSend is down to about 23%, and > testing > whether a base in the codon represents one in the sequence is up to > about > 17.5%. Since that's the most important step, I view this as a bit of > progress. maybe you can speed up by changing this: [theOutput setString: [aString addSpacesToStringWithInterval:5]]; to this: [theOutput setString: aString]; - Koen. From jtimmer at bellatlantic.net Sat Sep 4 10:22:27 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Sat, 04 Sep 2004 10:22:27 -0400 Subject: [Biococoa-dev] Translation In-Reply-To: <4F843712-FDFC-11D8-B1EB-003065A5FDCC@earthlink.net> Message-ID: > I seem to be missing BCGeneticCodeName, I get a bunch of errors related > to that. Did you forget to commit that file? I told Xcode to add it, but I had created a "Translation" folder, so it failed to add this properly. I've gone in and fixed things manually now. Sorry about that > > > >> The time is down by a bit, but not a whole lot (maybe about 10-15% - >> it's >> just under .4 seconds now). ObjC_msgSend is down to about 23%, and >> testing >> whether a base in the codon represents one in the sequence is up to >> about >> 17.5%. Since that's the most important step, I view this as a bit of >> progress. > > maybe you can speed up by changing this: > > [theOutput setString: [aString addSpacesToStringWithInterval:5]]; > > to this: > > [theOutput setString: aString]; No, I was checking timings separate from generating the output to specifically avoid this sort of thing. Anyway, I checked in code that cuts the time spent translating more than in half. I did some thinking and I'm pretty sure that the way the code's written, if one potential codon matches, there's not a chance that a codon for a different a.a. would also match. There's a chance my thinking's wrong, so if anybody has sequences filled with ambiguous bases, I recommend giving it a try and let me know if there are any inaccuracies. Given that I'm happy with the speed now, I'll spend some time cleaning up the codons/genetic codes and then work on creating a BCSequenceCodon. Cheers, John _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Sat Sep 4 13:41:25 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 4 Sep 2004 13:41:25 -0400 Subject: [Biococoa-dev] peptides and proteins Message-ID: Hi, I am working on a class that digests a protein sequence, and returns an array of peptides. I am not sure if I want to use BCProteinSequence for the peptides, or that I should create a separate class BCSequencePeptide, and/or BCSequenceAminoAcid. In that case, BCProteinSequence is then a subclass of either one. My first thought would be to use this scheme: BCSequence | | | ------ BCSequencePeptide (or BCSequenceAminoAcid) | | | ------------BCSequenceProtein What do you guys think? cheers, - Koen. From kvddrift at earthlink.net Sat Sep 4 13:53:02 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 4 Sep 2004 13:53:02 -0400 Subject: [Biococoa-dev] Translation In-Reply-To: References: Message-ID: <43F9D2EE-FE9B-11D8-B1EB-003065A5FDCC@earthlink.net> On Sep 4, 2004, at 10:22 AM, John Timmer wrote: > I told Xcode to add it, but I had created a "Translation" folder, so it > failed to add this properly. I've gone in and fixed things manually > now. > Thanks, I got the files now. One remark, on my drive the files are in the folder Translation, but in my Xcode project they are in BCSequence. I suggest we synchronize this. The same for the demo app code (demo_app on HD, demo_app files in project). cheers, - Koen. From kvddrift at earthlink.net Sun Sep 5 07:43:18 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 5 Sep 2004 07:43:18 -0400 Subject: [Biococoa-dev] BCCodon bug (?) Message-ID: John, The method AminoAcidSymbolString in BCCodon returns the symbol '*' when theAminoAcid is nil. However, if you pass that in an NSString to BCSequenceProtein the code crashes, because '*' is not an entry in the amino acids plist. For gaps the entry in the plist is a hyphen. Maybe there is a specific reason to use the asterisk, in that case I will add a line to BCSequenceProtein to skip that symbol. Otherwise, can you change AminoAcidSymbolString to return an hyphen? Also, change the name of the method to aminoAcidSymbolString (first letter should be lowercase). thanks, - Koen. From jtimmer at bellatlantic.net Sun Sep 5 08:30:51 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 05 Sep 2004 08:30:51 -0400 Subject: [Biococoa-dev] BCCodon bug (?) In-Reply-To: Message-ID: > John, > > The method AminoAcidSymbolString in BCCodon returns the symbol '*' > when theAminoAcid is nil. However, if you pass that in an NSString to > BCSequenceProtein the code crashes, because '*' is not an entry in the > amino acids plist. For gaps the entry in the plist is a hyphen. Maybe > there is a specific reason to use the asterisk, in that case I will add > a line to BCSequenceProtein to skip that symbol. Otherwise, can you > change AminoAcidSymbolString to return an hyphen? > > Also, change the name of the method to aminoAcidSymbolString (first > letter should be lowercase). > Sorry about that - that's a stop codon. It was decided that we wouldn't create a "stop" amino acid (I still think it would be convenient to do so), so I used a nil amino acid reference as stop within a BCCodon. Part of what I need to do is to put the headerdoc in place, so this doesn't surprise anyone, and to create a BCSequenceCodon in order to provide an interface for generating BCSequenceProteins safely (ie - ending the sequence when it hits a stop codon). And go ahead and change the method name. Sorry again - John _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Sun Sep 5 10:35:51 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 5 Sep 2004 10:35:51 -0400 Subject: [Biococoa-dev] BCCodon bug (?) In-Reply-To: References: Message-ID: On Sep 5, 2004, at 8:30 AM, John Timmer wrote: > Sorry about that - that's a stop codon. It was decided that we > wouldn't > create a "stop" amino acid (I still think it would be convenient to do > so), > so I used a nil amino acid reference as stop within a BCCodon. Part > of what > I need to do is to put the headerdoc in place, so this doesn't surprise > anyone, and to create a BCSequenceCodon in order to provide an > interface for > generating BCSequenceProteins safely (ie - ending the sequence when it > hits > a stop codon). > > And go ahead and change the method name. > So it's ok if I change the * to a -? BTW, I have no problems with adding another entry in aminoacids.plist for a 'stop amino acid', I just had not heard of it and was confused by that terminology. If you think it's beneficial for the translation code, let's just add it. - Koen. From kvddrift at earthlink.net Mon Sep 6 13:58:53 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 6 Sep 2004 13:58:53 -0400 Subject: [Biococoa-dev] more on BCCodon Message-ID: <6A5FB88F-002E-11D9-B1EB-003065A5FDCC@earthlink.net> Hi, While editing the BCCodon file (as discussed yesterday), I realized that BCCodon is actually a sequence of three bases. Would it be an idea to make BCCodon a subclass of BCSequence (or BCSequenceDNA)? The method tripletString can than just return [self sequenceString]; - Koen. From jtimmer at bellatlantic.net Mon Sep 6 14:27:14 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 06 Sep 2004 14:27:14 -0400 Subject: [Biococoa-dev] more on BCCodon In-Reply-To: <6A5FB88F-002E-11D9-B1EB-003065A5FDCC@earthlink.net> Message-ID: > Hi, > > While editing the BCCodon file (as discussed yesterday), I realized > that BCCodon is actually a sequence of three bases. Would it be an idea > to make BCCodon a subclass of BCSequence (or BCSequenceDNA)? The method > tripletString can than just return [self sequenceString]; The problem with codons is that they don't really fit neatly into the defined classes. There's always a few methods in the Symbol and Sequence classes that don't make any sense when applied to a codon. Given that, it seemed more useful to have a BCSequenceCodon, so I specifically avoided using it as a superclass. While I'm on my flights later this week, I'm going to try to figure out a way to squeeze them in as a subclass of BCSymbol, but I'm not optimistic. I'd originally had a codon contain a BCSequence for holding the bases it encompassed, but that turned out to be terminally slow, as it took two ObjC_msgSend calls in order to look up each base or 6 to do anything useful with the actual codon, so that was removed as part of my optimization. Cheers, John _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Mon Sep 6 14:29:36 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 06 Sep 2004 14:29:36 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: <6A5FB88F-002E-11D9-B1EB-003065A5FDCC@earthlink.net> Message-ID: Don't know if everyone caught this on the Cocoa mailing list, so I thought I'd point it out: http://www.mulle-kybernetik.com/artikel/Optimization/opti-3-imp-deluxe.html And other links at the site give some really good hints at how to optimize for speed in ObjC. I'm going to be giving CFArrays a lookover as a way to speed up some of my methods a bit further. I wouldn't recommend making any of these techniques part of the public interface, but using them internally within a method seems perfectly reasonable. Cheers, John _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Mon Sep 6 16:30:50 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 06 Sep 2004 16:30:50 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: Message-ID: Replying to myself here - Simply taking one of the methods (isRepresentedBy:) from BCNucleotideDNA that's used heavily in BCCodon, and changing this return [representedBy containsObject: entry]; To this return CFArrayContainsValue ( representedBy, CFRangeMake( 0, CFArrayGetCount ( representedBy )), entry) ; Drops ObjC_msgSend from the top processor user, replacing it with CFEqual. Times drop accordingly. Given that, it's probably worth going back and looking for places we can replace an NSArray method with its CFArray counterpart. If someone actually intends to do so on a specific file, let me know; otherwise, I'll work on this on the airplane. Cheers, John _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Mon Sep 6 17:39:20 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 6 Sep 2004 17:39:20 -0400 Subject: [Biococoa-dev] more on BCCodon In-Reply-To: References: Message-ID: <3655A916-004D-11D9-A4F0-003065A5FDCC@earthlink.net> On Sep 6, 2004, at 2:27 PM, John Timmer wrote: > The problem with codons is that they don't really fit neatly into the > defined classes. There's always a few methods in the Symbol and > Sequence > classes that don't make any sense when applied to a codon. You don't have to use all methods that are provided by the superclass, so I don't think it is a problem. If I know that an object is a sequence, I will just call [mySequence sequenceString] to get an NSString, and I don't have to worry that the method doesn't exit, or is named differently. BCCodon now uses 'tripletString' to return an NSString, just as it uses 'triplet' instead of sequenceArray. That's the beauty of inheritance. I don't see any reason why to treat BCCodon differently, to me it's a sequence of three nucleotides. Moreover if all classes that deal with sequences use the same method naming, it becomes much easier for users (and us) to use BioCocoa. If every class uses a different approach, things get more unclear, and more difficult to maintain. > Given that, it > seemed more useful to have a BCSequenceCodon, so I specifically avoided > using it as a superclass. While I'm on my flights later this week, I'm > going to try to figure out a way to squeeze them in as a subclass of > BCSymbol, but I'm not optimistic. What's the advantage of subclassing BCSymbol compared to BCSequence? Again, it's a sequence, so subclassing BCSequence seems more logical to me. - Koen. From mek at mekentosj.com Mon Sep 6 18:10:06 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 00:10:06 +0200 Subject: [Biococoa-dev] more on BCCodon In-Reply-To: <3655A916-004D-11D9-A4F0-003065A5FDCC@earthlink.net> References: <3655A916-004D-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: <825F67FC-0051-11D9-B507-000393CFDE0C@mekentosj.com> Back online after a food-poisoning on friday (which struck Tom as well, join in for a dinner at our institute's restaurant ;-) and a weekend away, I'd like to chime in here... I will also go through the code and previous emails of this weekend in later replies if I have some time later on, but this seems more a definition issue. >> The problem with codons is that they don't really fit neatly into the >> defined classes. There's always a few methods in the Symbol and >> Sequence >> classes that don't make any sense when applied to a codon. > What's the advantage of subclassing BCSymbol compared to BCSequence? > Again, it's a sequence, so subclassing BCSequence seems more logical > to me. The way I see it, you have a list of Codons that together make up a Sequence of Codons. Thus, BCCodon in that respect would be the symbol (so a subclass of BCSymbol) and BCSequenceCodon would be the sequence, a subclass of BCSequence. All confusion seems to come from the fact that BCCodon has a (very important) variable that is a BCSequenceDNA, but than again it also has a amino acid variable. If we make BCCodon a BCSequenceDNA subclass I think the balance is completely shifted to its DNA half, and the aminoacid half makes quite a strange appearance in there. In my opinion we should compare a codon to a amino acid or nucleotide, thus as a entity that makes up a sequence. The codon per se is not a sequence, a list of codons is. Perhaps the best comparison to real life is that with the tRNA. On the one side a tRNA has it's RNA complement of three bases, on the other side it carries the amino acid. Whether I'm missing things here is something I'll probably find out soon after reading through all other emails ;-) > You don't have to use all methods that are provided by the superclass, > so I don't think it is a problem. Well yes and no, you don't have to use them, but they must return something that makes sense. If you feed a codon in a method that accepts BCSequences in general, it could terribly crash if BCCodon doesn't know how to interpret things. > If I know that an object is a sequence, I will just call [mySequence > sequenceString] to get an NSString, and I don't have to worry that the > method doesn't exit, or is named differently. BCCodon now uses > 'tripletString' to return an NSString, just as it uses 'triplet' > instead of sequenceArray. That's the beauty of inheritance. I don't > see any reason why to treat BCCodon differently, to me it's a sequence > of three nucleotides. The one thing doesn't prevent the other. We can still, for clarity, keep a lot of method names the same, even if they are not subclasses. In fact, this is something you see all-over the appkit as well, and I would strongly recommend to keep our basic set of method names as small as possible. For instance, this afternoon I noticed that both NSBox (a NSView subclass) and NSWindow (a NSResponder subclass) have a -(id)contentView; method which does exactly the same thing in both cases. > Moreover if all classes that deal with sequences use the same method > naming, it becomes much easier for users (and us) to use BioCocoa. If > every class uses a different approach, things get more unclear, and > more difficult to maintain. Exactly my point, but again that doesn't require subclassing per se. Also I was thinking from a user perspective (remember it's a developer here, so code organization is key here) that we can organize things a bit better still, like moving BCCodon to the symbols group, moving the symbols folder to the root instead of inside BCSequence etc. But I'll make a wishlist one of the next days ;-) Great work guys! 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 jtimmer at bellatlantic.net Mon Sep 6 18:13:04 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Mon, 06 Sep 2004 18:13:04 -0400 Subject: [Biococoa-dev] more on BCCodon In-Reply-To: <3655A916-004D-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: >> Given that, it >> seemed more useful to have a BCSequenceCodon, so I specifically avoided >> using it as a superclass. While I'm on my flights later this week, I'm >> going to try to figure out a way to squeeze them in as a subclass of >> BCSymbol, but I'm not optimistic. > > > What's the advantage of subclassing BCSymbol compared to BCSequence? > Again, it's a sequence, so subclassing BCSequence seems more logical to > me. Well, in addition to class inheritance, we have to think about what these things are supposed to represent biologically. A sequence is an ordered list of objects. A symbol is a single instance of one of these objects. Given those definitions, a codon isn't actually a sequence. A codon is a single instance of something that typically occurs as an ordered list, meaning an mRNA transcript can be thought of as an ordered list of codons. By most standards, a codon should be a symbol. The only reason to view it as a sequence is that it contains a short sequence as one of its properties. Putting it another way, all the properties of a BCSequence subclass are (or at least should be) derived from the sequence itself. The properties of a codon aren't - they depend on external information, namely what (if any) amino acid it codes for in a given genetic code. Given all that, Symbol seems a better fit, but it's also awkward - there's both nucleotide and amino acid information, and unlike all the other symbols, its meaning can vary (again, based on the genetic code). The only reason I see to try to wrench it into being a symbol is that I can see advantages to allowing our BCSequence class to assume its contents are always symbols. I haven't looked over the class in detail in order to determine if it does anything that requires that yet. I hope that's clear - it is to me, but it's also obvious that codons are something I worry about on a much more regular basis in my real life as a scientist as opposed to when I'm pretending to be a programmer. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Mon Sep 6 20:52:12 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Mon, 6 Sep 2004 20:52:12 -0400 Subject: [Biococoa-dev] more on BCCodon In-Reply-To: <825F67FC-0051-11D9-B507-000393CFDE0C@mekentosj.com> References: <3655A916-004D-11D9-A4F0-003065A5FDCC@earthlink.net> <825F67FC-0051-11D9-B507-000393CFDE0C@mekentosj.com> Message-ID: <27A04473-0068-11D9-A4F0-003065A5FDCC@earthlink.net> On Sep 6, 2004, at 6:10 PM, Alexander Griekspoor wrote: > Back online after a food-poisoning on friday (which struck Tom as > well, join in for a dinner at our institute's restaurant ;-) Mosselen? > The way I see it, you have a list of Codons that together make up a > Sequence of Codons. Thus, BCCodon in that respect would be the symbol > (so a subclass of BCSymbol) and BCSequenceCodon would be the > sequence, a subclass of BCSequence. > All confusion seems to come from the fact that BCCodon has a (very > important) variable that is a BCSequenceDNA, but than again it also > has a amino acid variable. If we make BCCodon a BCSequenceDNA subclass > I think the balance is completely shifted to its DNA half, and the > aminoacid half makes quite a strange appearance in there. In my > opinion we should compare a codon to a amino acid or nucleotide, thus > as a entity that makes up a sequence. The codon per se is not a > sequence, a list of codons is. Perhaps the best comparison to real > life is that with the tRNA. On the one side a tRNA has it's RNA > complement of three bases, on the other side it carries the amino > acid. Whether I'm missing things here is something I'll probably find > out soon after reading through all other emails ;-) That's a very good explanation for me, and makes things much more clearer. So I think this suggestion from Alex would be a good solution: BCSymbol -> BCCodon (with BCCodon having a BCSequenceDNA as member) BCSequence -> BCSequenceCodon >> You don't have to use all methods that are provided by the >> superclass, so I don't think it is a problem. > Well yes and no, you don't have to use them, but they must return > something that makes sense. If you feed a codon in a method that > accepts BCSequences in general, it could terribly crash if BCCodon > doesn't know how to interpret things. Why? The abstract method takes care of for instance returning 'nil' in such a case. If it isn't implemented in BCCodon, than BCSymbol should take care of it with a default response. If you want BCCodon to do something else, then just override it. > >> If I know that an object is a sequence, I will just call [mySequence >> sequenceString] to get an NSString, and I don't have to worry that >> the method doesn't exit, or is named differently. BCCodon now uses >> 'tripletString' to return an NSString, just as it uses 'triplet' >> instead of sequenceArray. That's the beauty of inheritance. I don't >> see any reason why to treat BCCodon differently, to me it's a >> sequence of three nucleotides. > The one thing doesn't prevent the other. We can still, for clarity, > keep a lot of method names the same, even if they are not subclasses. > In fact, this is something you see all-over the appkit as well, and I > would strongly recommend to keep our basic set of method names as > small as possible. Good point. > >> Moreover if all classes that deal with sequences use the same method >> naming, it becomes much easier for users (and us) to use BioCocoa. If >> every class uses a different approach, things get more unclear, and >> more difficult to maintain. > Exactly my point, but again that doesn't require subclassing per se. > Also I was thinking from a user perspective (remember it's a developer > here, so code organization is key here) that we can organize things a > bit better still, like moving BCCodon to the symbols group, moving the > symbols folder to the root instead of inside BCSequence etc. But I'll > make a wishlist one of the next days ;-) Please submit. BioCocoa is still small enough to move stuff around (altough it would be less straightforward in CVS ;-) - Koen. From mek at mekentosj.com Tue Sep 7 01:35:43 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 07:35:43 +0200 Subject: [Biococoa-dev] more on BCCodon In-Reply-To: <27A04473-0068-11D9-A4F0-003065A5FDCC@earthlink.net> References: <3655A916-004D-11D9-A4F0-003065A5FDCC@earthlink.net> <825F67FC-0051-11D9-B507-000393CFDE0C@mekentosj.com> <27A04473-0068-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: >> Back online after a food-poisoning on friday (which struck Tom as >> well, join in for a dinner at our institute's restaurant ;-) > > Mosselen? Luckily not, still not sure what caused it but definitely had to be removed ;-) > > That's a very good explanation for me, and makes things much more > clearer. So I think this suggestion from Alex would be a good > solution: > > BCSymbol -> BCCodon (with BCCodon having a BCSequenceDNA as member) > BCSequence -> BCSequenceCodon Seems I could have waited 5 minutes to let John do the talking ;-) >>> You don't have to use all methods that are provided by the >>> superclass, so I don't think it is a problem. >> Well yes and no, you don't have to use them, but they must return >> something that makes sense. If you feed a codon in a method that >> accepts BCSequences in general, it could terribly crash if BCCodon >> doesn't know how to interpret things. > > Why? The abstract method takes care of for instance returning 'nil' in > such a case. If it isn't implemented in BCCodon, than BCSymbol should > take care of it with a default response. If you want BCCodon to do > something else, then just override it. Sure, but the only point I tried to make that one should be careful that 1) all superclass methods should be checked to either return something useful or nil and 2) all classes that work with these methods should then also expect to receive a nil when they call them. Although, the latter seems good programming practice, I'm sure there plenty of examples in my code where things would go terribly wrong if one of my methods returned nil simply because I know they should never. >>> Moreover if all classes that deal with sequences use the same method >>> naming, it becomes much easier for users (and us) to use BioCocoa. >>> If every class uses a different approach, things get more unclear, >>> and more difficult to maintain. >> Exactly my point, but again that doesn't require subclassing per se. >> Also I was thinking from a user perspective (remember it's a >> developer here, so code organization is key here) that we can >> organize things a bit better still, like moving BCCodon to the >> symbols group, moving the symbols folder to the root instead of >> inside BCSequence etc. But I'll make a wishlist one of the next days >> ;-) > > Please submit. BioCocoa is still small enough to move stuff around > (altough it would be less straightforward in CVS ;-) Ok, well let me first play with CVS a bit then, to at least understand what I'm doing ;-) I'll let you guys know when I start moving things around (in a day or two), so everything can be checked back in prior to that. 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. ********************************************************* ********************************************************* ** 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 Sep 7 01:44:16 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 07:44:16 +0200 Subject: [Biococoa-dev] [BioCocoa] Alignments Message-ID: This is more a newsflash, but perhaps nice to let you guys know is that I've spoken to Serge Cohen, a French programmer here in the institute and have asked him if he could help us look at implementing alignments. He's a mac enthusiast as well, and works on a program for automatic modeling of Xray structures. He also wrote some stuff for organizing and parsing pubmed entries, so perhaps he has some more things he can help us with. Lucky for us, he absolutely wants to contribute with the alignment algorithms, something I don't really have a lot of experience with at least. Very nice is that he has quite some experience with altivec enhancements as well, would be nice to have altivec enabled alignments ;-) I'll introduce him to the framework once the core is more or less stable... 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 Tue Sep 7 02:24:35 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 08:24:35 +0200 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: References: Message-ID: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> Koen, Both Tom and I discussed this and we have our doubt if this is the way to go. We don't really see why we should add the intermediate BCSequence class. I think this is the example of a manipulation you do with a BCSequence (a digestion) which returns some sort of result that by incidence is a collection of BCSequences as well. Similar examples are perhaps PCR reactions, and especially DNA enzyme digests. To take the latter as example, and how I would like to implement this is by modelling things to real life. I propose the following new classes: BCEnzyme | ---------------BCRestrictionEnzyme | ---------------BCProtease | ---------------etc These can hold variables like optimal temperature, buffer conditions etc. Not completely sure, but it might again be very handy to have a predefined set as singletons (instead of instantiating 600 restriction enzymes for each digest, let the BCRestrictionEnzyme create a singleton dictionary the first time and access them from there the next time). Then a BCUtilDigester(DNA/Protein) or something that can do the digest ala your masscalculator (which I would like to call BCUtilMassCalculator if that's ok by the way). The result of a digest in the theoretical form of: [BCUtilDigesterDNA performDigestWithSequence: aBCSequence andEnzymes: anArrayOfBCEnzymes]; would be a BCDigest, a class that holds variables for the conditions choosen, the enzymes used, and an array of BCSequences that represent the fragments. Another possible setup would be to instantiate a BCDigest first, fill it with the parameters like enzymes, sequence, conditions etc, and then let the class self or a BCUtilDigester perform the digest which fills the array of fragments. Again, this is all theoretical stuff but I hope it inspires a discussion. Having thought quite a bit about it given the EnzymeX background, I thought this would be a nice system. I have a few questions still, like if we need a BCFragment intermediate that not only holds the sequence of the fragment, but also which restriction enzyme cuts at the left site and which on the right. Thus: BCDigest | --> dictionary of conditions sequence of type BCSequence (complete sequence) array of BCEnzymes array of BCFragments | --> 5' BCEnzyme 3' BCEnzyme NSRange within the BCSequence above The fragment part is more or less what I have working in an upcoming version of EnzymeX, and it works beautifully. Sorting fragments on size, position etc is so easy! The approach for peptide digestions could be very similar I guess. Again, I don't think that we should put additional layers in the BCSequence classes just to let them act as containers of multiple other BCSequences for specific purposes like digestions or other manipulations. I'm sure there's enough to comment on ;-) Alex Op 4-sep-04 om 19:41 heeft Koen van der Drift het volgende geschreven: > Hi, > > I am working on a class that digests a protein sequence, and returns > an array of peptides. I am not sure if I want to use BCProteinSequence > for the peptides, or that I should create a separate class > BCSequencePeptide, and/or BCSequenceAminoAcid. In that case, > BCProteinSequence is then a subclass of either one. > > > My first thought would be to use this scheme: > > > BCSequence > | > | > | > ------ BCSequencePeptide (or BCSequenceAminoAcid) > | > | > | > ------------BCSequenceProtein > > > > What do you guys think? > > > 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 LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From mek at mekentosj.com Tue Sep 7 02:38:47 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 08:38:47 +0200 Subject: [Biococoa-dev] BCCodon bug (?) In-Reply-To: References: Message-ID: <92910C11-0098-11D9-B507-000393CFDE0C@mekentosj.com> >> Sorry about that - that's a stop codon. It was decided that we >> wouldn't >> create a "stop" amino acid (I still think it would be convenient to >> do so), >> so I used a nil amino acid reference as stop within a BCCodon. Part >> of what >> I need to do is to put the headerdoc in place, so this doesn't >> surprise >> anyone, and to create a BCSequenceCodon in order to provide an >> interface for >> generating BCSequenceProteins safely (ie - ending the sequence when >> it hits >> a stop codon). >> >> And go ahead and change the method name. >> > > So it's ok if I change the * to a -? > > BTW, I have no problems with adding another entry in aminoacids.plist > for a 'stop amino acid', I just had not heard of it and was confused > by that terminology. If you think it's beneficial for the translation > code, let's just add it. I'm not absolutely against a stop amino acid, but the choice was a rational one, they simply don't exist. Again, we're in code here so nobody will stop us from doing so, and indeed perhaps we should, although I like the idea of returning nil (in fact that happens in real life as well, the stop tRNA returns no amino acid to the ribosome, which crashes and falls of the mRNA ;-) The thing is that a mRNA of codon list can contain stops, a protein not. So there's no problem of defining a stop codon, but that opens up the possibility to create proteins that contain stops, for which we than have to account for in calculation/transformation methods etc.... The idea we have now if simple: BCSequenceDNA/RNA -> BCSequenceCodon -> BCSequenceProtein All manipulations you perform on things with stops still there (like displaying the "translation" of my sequence file in 4Peaks for instance, which often contains many stops due to reading errors (CTG*AG*WC etc)) should be done with BCSequenceCodon. The only thing we still have to think about is that it would be nice to have to possibility to either treat BCSequenceCodon as a DNA sequence or as a protein sequence. (for example having length return 9 (aminoacids) in the above example or 27 (nucleotides)). I'm not sure if this is possible though, perhaps with convenience methods (the superclass method that we choose to be either DNA or Protein specific, and additional methods like numberOfNucleotides and numberOfAminoAcids). So in conclusion, if we want to add a stop aminoacid, it's fine with me, but I propose in that case to severely limit its use (like you can't create proteins with them). I'll leave that up to you guys... Cheers, Alex > - 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 ********************************************************* From mek at mekentosj.com Tue Sep 7 02:41:59 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 08:41:59 +0200 Subject: [Biococoa-dev] Optimizations In-Reply-To: References: Message-ID: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> This is impressive stuff John, well done! My experience with many of the CF classes is a drama, but I might start looking at it as well. Where speed is a bottleneck, I have absolutely no problem with these kind of optimizations in internal implementations. I do propose to add some extra lines of comments though, to describe a bit what you do and why you choose to use the CF classes there (for poor soles like me ;-) Alex Op 6-sep-04 om 22:30 heeft John Timmer het volgende geschreven: > Replying to myself here - > > Simply taking one of the methods (isRepresentedBy:) from > BCNucleotideDNA > that's used heavily in BCCodon, and changing this > > return [representedBy containsObject: entry]; > > To this > > return CFArrayContainsValue ( representedBy, CFRangeMake( 0, > CFArrayGetCount ( representedBy )), entry) ; > > > Drops ObjC_msgSend from the top processor user, replacing it with > CFEqual. > Times drop accordingly. Given that, it's probably worth going back and > looking for places we can replace an NSArray method with its CFArray > counterpart. > > If someone actually intends to do so on a specific file, let me know; > otherwise, I'll work on this on the airplane. > > Cheers, > > John > > _______________________________________________ > 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 MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From jtimmer at bellatlantic.net Tue Sep 7 08:38:24 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 07 Sep 2004 08:38:24 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> Message-ID: > This is impressive stuff John, well done! My experience with many of > the CF classes is a drama, but I might start looking at it as well. > Where speed is a bottleneck, I have absolutely no problem with these > kind of optimizations in internal implementations. I do propose to add > some extra lines of comments though, to describe a bit what you do and > why you choose to use the CF classes there (for poor soles like me ;-) Incidentally, one of the cool things about this is that the source of CoreFoundation is available in Darwin. You can actually take a look at the implementation and decide if there's any more speed you can squeeze out of things by implementing things yourself, or if you'd just do what Apple's doing already. It's also funny to see code like this: #if defined(DEBUG) __CFGenericValidateType(array, __kCFArrayTypeID); __CFArrayValidateRange(array, range, __PRETTY_FUNCTION__); #endif I haven't gone into finding "__PRETTY_FUNCTION__", but I am curious... By the way, is the alignment guy the same Serge Cohen who's been making the Cocoa-MySQL adapter? Cheers, JT _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Sep 7 10:44:49 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 16:44:49 +0200 Subject: [Biococoa-dev] Optimizations In-Reply-To: References: Message-ID: <7853186A-00DC-11D9-B507-000393CFDE0C@mekentosj.com> very nice John! I'll have a look at that. where did you download the source for Darwin? > I haven't gone into finding "__PRETTY_FUNCTION__", but I am curious... Same here! > > By the way, is the alignment guy the same Serge Cohen who's been > making the > Cocoa-MySQL adapter? Yes he is..... seems his fame his flying ahead of him or was this meant in a negative way ? ;-) I think he actually might be interested in the corefoundation source as well... I'll tell him about it... 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 jtimmer at bellatlantic.net Tue Sep 7 10:59:11 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 07 Sep 2004 10:59:11 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: <7853186A-00DC-11D9-B507-000393CFDE0C@mekentosj.com> Message-ID: > very nice John! I'll have a look at that. where did you download the > source for Darwin? Probably the easiest place is at open darwin - http://darwinsource.opendarwin.org/10.3.5/CF-299.31/ I don't know how often the CF version changes, but I'd guess that it's probably only with the OS versions. >> I haven't gone into finding "__PRETTY_FUNCTION__", but I am curious... > Same here! >> >> By the way, is the alignment guy the same Serge Cohen who's been >> making the >> Cocoa-MySQL adapter? > Yes he is..... seems his fame his flying ahead of him or was this meant > in a negative way ? ;-) > I think he actually might be interested in the corefoundation source as > well... I'll tell him about it... No, that was very much a positive. There's been some nice stuff based on that - CocoaMySQL has made my life immensely easier. And besides, I must bow before anyone who can code altivec ;). JT _______________________________________________ This mind intentionally left blank From james.balhoff at duke.edu Tue Sep 7 17:18:15 2004 From: james.balhoff at duke.edu (Jim Balhoff) Date: Tue, 7 Sep 2004 17:18:15 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> References: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> Message-ID: <6E507E30-0113-11D9-B91E-000A95EECBDE@duke.edu> Hey guys, I've just been lurking for a while, but I wanted to jump in with one reason I thought of to avoid CoreFoundation - portability. Currently, the BioCocoa website advertises GNUstep compatibility. The GNUstep Foundation works quite well and so it's not too much trouble to stay compatible with if you stick to the standard C and Foundation API. But if GNUstep is to be excluded, by all means optimize where needed. I am hoping to jump into BioCocoa in 2 or 3 months, since it looks like I'll be able to do lots more programming in a post-doc I'm trying to get after I graduate. Until then, I'll just keep listening. - Jim On Sep 7, 2004, at 2:41 AM, Alexander Griekspoor wrote: > This is impressive stuff John, well done! My experience with many of > the CF classes is a drama, but I might start looking at it as well. > Where speed is a bottleneck, I have absolutely no problem with these > kind of optimizations in internal implementations. I do propose to add > some extra lines of comments though, to describe a bit what you do and > why you choose to use the CF classes there (for poor soles like me ;-) > Alex From mek at mekentosj.com Tue Sep 7 17:27:29 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 23:27:29 +0200 Subject: [Biococoa-dev] GNUStep Compatibility (was: [Biococoa-dev] Optimizations) In-Reply-To: <6E507E30-0113-11D9-B91E-000A95EECBDE@duke.edu> References: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> <6E507E30-0113-11D9-B91E-000A95EECBDE@duke.edu> Message-ID: Hi Jim, Nice to hear from you again, seems you're well on you way for your graduation! For me, GNUstep compatibility is not high on my list, but perhaps the others think it's of more importance. I could imagine that at least marketing wise it seems nice that you can say you potentially address a far larger public. Although, I doubt if that extends practically at all. But I would like to hear especially Peter's comments on the issue as he's the one advertising GNUstep compatibility right now ;-) Cheers and good luck with the graduation! Alex Op 7-sep-04 om 23:18 heeft Jim Balhoff het volgende geschreven: > Hey guys, > > I've just been lurking for a while, but I wanted to jump in with one > reason I thought of to avoid CoreFoundation - portability. Currently, > the BioCocoa website advertises GNUstep compatibility. The GNUstep > Foundation works quite well and so it's not too much trouble to stay > compatible with if you stick to the standard C and Foundation API. > But if GNUstep is to be excluded, by all means optimize where needed. > > I am hoping to jump into BioCocoa in 2 or 3 months, since it looks > like I'll be able to do lots more programming in a post-doc I'm trying > to get after I graduate. Until then, I'll just keep listening. > > - Jim > > On Sep 7, 2004, at 2:41 AM, Alexander Griekspoor wrote: > >> This is impressive stuff John, well done! My experience with many of >> the CF classes is a drama, but I might start looking at it as well. >> Where speed is a bottleneck, I have absolutely no problem with these >> kind of optimizations in internal implementations. I do propose to >> add some extra lines of comments though, to describe a bit what you >> do and why you choose to use the CF classes there (for poor soles >> like me ;-) >> Alex > > _______________________________________________ > 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 Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* ********************************************************* ** 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 james.balhoff at duke.edu Tue Sep 7 17:40:51 2004 From: james.balhoff at duke.edu (Jim Balhoff) Date: Tue, 7 Sep 2004 17:40:51 -0400 Subject: [Biococoa-dev] GNUStep Compatibility (was: [Biococoa-dev] Optimizations) In-Reply-To: References: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> <6E507E30-0113-11D9-B91E-000A95EECBDE@duke.edu> Message-ID: <96BD5D94-0116-11D9-B91E-000A95EECBDE@duke.edu> On Sep 7, 2004, at 5:27 PM, Alexander Griekspoor wrote: > Hi Jim, > > Nice to hear from you again, seems you're well on you way for your > graduation! > For me, GNUstep compatibility is not high on my list, but perhaps the > others think it's of more importance. I could imagine that at least > marketing wise it seems nice that you can say you potentially address > a far larger public. Although, I doubt if that extends practically at > all. But I would like to hear especially Peter's comments on the issue > as he's the one advertising GNUstep compatibility right now ;-) I think you're right, the number of people using GNUstep, in particular to write bio-software, is probably very tiny. Even in comparison to such people using Cocoa/MacOS X. But I wanted to make sure it was a conscious decision. I have used GNUstep on Linux and had no problems with Foundation. AppKit worked pretty well, but there were a few quirks (but I think they've made tons of progress in the past several months since I've used it). However, there is no support for some of the newer additions such as bindings (that I know of). > Cheers and good luck with the graduation! Thanks! ____________________________________________ James P. Balhoff Dept. of Biology Duke University Durham, NC 27708-0338 USA From jtimmer at bellatlantic.net Tue Sep 7 17:47:06 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 07 Sep 2004 17:47:06 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: <6E507E30-0113-11D9-B91E-000A95EECBDE@duke.edu> Message-ID: Crap, I didn't even think of that. The gains are really substantial, literally cutting the time for a translation in half. I could probably do some function pointer lookups and use those to cut time down an equivalent amount, but (IMHO) they make the code incredibly difficult to follow. Plus, never really having used function pointers, I doubt I'd be any good at maintaining them. The other option would be to trap things with some #ifdefs, but that does ugly things to code readability as well. Is there any sense of who uses BioCocoa? If nobody much is doing anything with it using GNUstep, then this won't bother anyone. Thanks for pointing this out - JT PS - what area of biology do you work on? We seem to have a fairly broad spectrum already within this small group. > Hey guys, > > I've just been lurking for a while, but I wanted to jump in with one > reason I thought of to avoid CoreFoundation - portability. Currently, > the BioCocoa website advertises GNUstep compatibility. The GNUstep > Foundation works quite well and so it's not too much trouble to stay > compatible with if you stick to the standard C and Foundation API. But > if GNUstep is to be excluded, by all means optimize where needed. > > I am hoping to jump into BioCocoa in 2 or 3 months, since it looks like > I'll be able to do lots more programming in a post-doc I'm trying to > get after I graduate. Until then, I'll just keep listening. > > - Jim > > On Sep 7, 2004, at 2:41 AM, Alexander Griekspoor wrote: > >> This is impressive stuff John, well done! My experience with many of >> the CF classes is a drama, but I might start looking at it as well. >> Where speed is a bottleneck, I have absolutely no problem with these >> kind of optimizations in internal implementations. I do propose to add >> some extra lines of comments though, to describe a bit what you do and >> why you choose to use the CF classes there (for poor soles like me ;-) >> Alex > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Sep 7 17:52:37 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 7 Sep 2004 23:52:37 +0200 Subject: [Biococoa-dev] Team spectrum (was: [Biococoa-dev] Optimizations) Message-ID: <3BB43D9A-0118-11D9-B507-000393CFDE0C@mekentosj.com> > PS - what area of biology do you work on? We seem to have a fairly > broad > spectrum already within this small group. Just to complete the indexing of the group (I'm curious as well): I'm in cell biology ************************************************************** ** 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 james.balhoff at duke.edu Tue Sep 7 17:55:53 2004 From: james.balhoff at duke.edu (Jim Balhoff) Date: Tue, 7 Sep 2004 17:55:53 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: References: Message-ID: On Sep 7, 2004, at 5:47 PM, John Timmer wrote: > > PS - what area of biology do you work on? We seem to have a fairly > broad > spectrum already within this small group. > Molecular and developmental evolution - particularly gene regulatory sequences. Jim ____________________________________________ James P. Balhoff Dept. of Biology Duke University Durham, NC 27708-0338 USA From jtimmer at bellatlantic.net Tue Sep 7 18:10:26 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 07 Sep 2004 18:10:26 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: Message-ID: > On Sep 7, 2004, at 5:47 PM, John Timmer wrote: >> >> PS - what area of biology do you work on? We seem to have a fairly >> broad >> spectrum already within this small group. >> > > Molecular and developmental evolution - particularly gene regulatory > sequences. > Any gene family/species set in particular? I do developmental work in the vertebrate neural tube, and the conservation of some of the enhancers is spectacular (higher than the coding region between chickens and mice for some cases). I've been thinking of a side project doing some enhancer bashing, so I've thought about this a bit. Cheers, John _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Tue Sep 7 18:14:53 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 7 Sep 2004 18:14:53 -0400 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> Message-ID: <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> On Sep 7, 2004, at 2:24 AM, Alexander Griekspoor wrote: > Koen, > Both Tom and I discussed this and we have our doubt if this is the way > to go. We don't really see why we should add the intermediate > BCSequence class. I think this is the example of a manipulation you do > with a BCSequence (a digestion) which returns some sort of result that > by incidence is a collection of BCSequences as well. Similar examples > are perhaps PCR reactions, and especially DNA enzyme digests. To take > the latter as example, and how I would like to implement this is by > modelling things to real life. > > I propose the following new classes: > > BCEnzyme > | > ---------------BCRestrictionEnzyme > | > ---------------BCProtease > | > ---------------etc > > These can hold variables like optimal temperature, buffer conditions > etc. Not completely sure, but it might again be very handy to have a > predefined set as singletons (instead of instantiating 600 restriction > enzymes for each digest, let the BCRestrictionEnzyme create a > singleton dictionary the first time and access them from there the > next time). > > Then a BCUtilDigester(DNA/Protein) or something that can do the digest > ala your masscalculator (which I would like to call > BCUtilMassCalculator if that's ok by the way). I agree we should make BCProtease and BCRestrictionEnzyme work in a similar way. But I'm not sure why we need an additional class that executes the digest, as you propose. This is how I do the digest for proteins: 1. pass the sequence to a 'digest' object 2. tell the digest object which enzyme to use, it then retireves that info from a plist (see below) 3. get the NSString from the sequence, and make a NSScanner based on it 4. using the info in the plist, let the scanner find out where to cut the sequence, and store the numbers 5. after the scanner is finished, make ranges based on the numbers, and then subsequences 6. return an array with the subsequences, these are the peptides It's fine with me if we use BCSequenceProtein for the peptides. We could have additional parameters passed to the digest object, such as to allow missed cleavages. an example of an entry in the plist (for trypsin) is: Trypsin CleaveAt KR DontCleaveBefore P CleaveDirection C I use this in my own app, and it works very nice. - Koen. From mek at mekentosj.com Tue Sep 7 18:38:49 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 8 Sep 2004 00:38:49 +0200 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: Koen, > I agree we should make BCProtease and BCRestrictionEnzyme work in a > similar way. But I'm not sure why we need an additional class that > executes the digest, as you propose. > > This is how I do the digest for proteins: > > 1. pass the sequence to a 'digest' object > > 2. tell the digest object which enzyme to use, it then retireves that > info from a plist (see below) > > 3. get the NSString from the sequence, and make a NSScanner based on it > > 4. using the info in the plist, let the scanner find out where to cut > the sequence, and store the numbers > > 5. after the scanner is finished, make ranges based on the numbers, > and then subsequences > > 6. return an array with the subsequences, these are the peptides I get it, and that works indeed fine. The problem here is that the moment you get an array with fragments, you loose all info about the digest. A digest object could encapsulate that. But indeed you're right and perhaps you're only interested in sequences. So maybe we should offer both options. A BCDigest could also be implemented as an encapsulated message, storing both the enzymes, the sequence, and the fragments. You then would have to options, either send the BCUtilDigester the individual items and get back an array with fragments, or send it a digest object and let the digester fill it's fragment array. Or do you think keeping the digest info around is something we should completely hand of to the app developer? The other think I would like to add to a BCSequence is the info of which enzyme produced the 5' end and which the 3' end. Therefore, I proposed the BCFragment class, which could be a subclass of BCSequence that stores these additional BCEnzyme variables (which can also be nil by default if the end is untreated). The nice thing is that for the BCDigest story above, nothing changes still get an array of BCSequences returned, but as a convenience the digest object fills in which enzyme produced the ends. An alternative way that would solve the problem is to store this information in the (to be implemented) features/annotations of a BCSequence. But I very much like the ideas above better. > We could have additional parameters passed to the digest object, such > as to allow missed cleavages. > > an example of an entry in the plist (for trypsin) is: > > Trypsin > > CleaveAt > KR > DontCleaveBefore > P > CleaveDirection > C > > > I use this in my own app, and it works very nice. Very nice indeed, the plists are definitely the way to go. Still, for restriction enzymes instantiating 600 enzymes each time would be to expensive I think, so that's where it would be nice to instantiate once from the plist and keep the objects around in a static dictionary. 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 Tue Sep 7 19:03:10 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 7 Sep 2004 19:03:10 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: References: Message-ID: <16855805-0122-11D9-A4F0-003065A5FDCC@earthlink.net> On Sep 7, 2004, at 10:59 AM, John Timmer wrote: > http://darwinsource.opendarwin.org/10.3.5/CF-299.31/ > Careful with that, you might break backward compatibility. - Koen. From kvddrift at earthlink.net Tue Sep 7 19:27:38 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 7 Sep 2004 19:27:38 -0400 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: <81AB3F3F-0125-11D9-A4F0-003065A5FDCC@earthlink.net> On Sep 7, 2004, at 6:38 PM, Alexander Griekspoor wrote: > I get it, and that works indeed fine. The problem here is that the > moment you get an array with fragments, you loose all info about the > digest. A digest object could encapsulate that. But indeed you're > right and perhaps you're only interested in sequences. So maybe we > should offer both options. A BCDigest could also be implemented as an > encapsulated message, storing both the enzymes, the sequence, and the > fragments. You then would have to options, either send the > BCUtilDigester the individual items and get back an array with > fragments, or send it a digest object and let the digester fill it's > fragment array. Or do you think keeping the digest info around is > something we should completely hand of to the app developer? I never thought of keeping the digest object around, but if the developer wants to keep it, why not? BCProtease *protease = [[BCProtease alloc] initWithSequence: aSeq] [protease setEnzyme: @trypsin]; // or based on a popup menu [protease digest] NSArray *thePeptides = [protease digestResult]; [protease release]; // optional > > The other think I would like to add to a BCSequence is the info of > which enzyme produced the 5' end and which the 3' end. Yes, that's taken care of in the plist using the CleaveDirection key. We have to add some code like: [newPeptide setCleavedAt: cleavedAtN]; // or 5' or 3' or cleavedAtC > Therefore, I proposed the BCFragment class, which could be a subclass > of BCSequence that stores these additional BCEnzyme variables (which > can also be nil by default if the end is untreated). The BCFragment would be similar to a separate BCPeptide class, correct? Then let's create both classes if that makes it easier. > The nice thing is that for the BCDigest story above, nothing changes > still get an array of BCSequences returned, but as a convenience the > digest object fills in which enzyme produced the ends. > Very nice indeed, the plists are definitely the way to go. Still, for > restriction enzymes instantiating 600 enzymes each time would be to > expensive I think, so that's where it would be nice to instantiate > once from the plist and keep the objects around in a static > dictionary. I'm not familiair with restriction enzyms, can you explain why you have to instantiate 600 enzymes if you're just using one? - Koen. From jtimmer at bellatlantic.net Tue Sep 7 20:43:28 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 07 Sep 2004 20:43:28 -0400 Subject: [Biococoa-dev] Optimizations In-Reply-To: <16855805-0122-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: > > On Sep 7, 2004, at 10:59 AM, John Timmer wrote: > >> http://darwinsource.opendarwin.org/10.3.5/CF-299.31/ >> > > Careful with that, you might break backward compatibility. > Well, like the Cocoa docs, the CF docs let you know about when a function was added. Looking at the latest version might not give you the actual code you're linking to, but it will give you what's presumably the most recently optimized version, which can be informative. Regardless, they have older versions to look at, too. There's also the likely probability that it is a common version with 10.2.8, as they are doing CoreFoundation security updates in tandem, as in today's case. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Tue Sep 7 21:36:02 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 7 Sep 2004 21:36:02 -0400 Subject: [Biococoa-dev] MW of DNA with ambiguous bases In-Reply-To: References: Message-ID: <71D83674-0137-11D9-A4F0-003065A5FDCC@earthlink.net> Hi, I'm working on some code in BCMassCalculator that takes care of ambigous bases. First I test to see if it is an ambiguous base as follows: if ( [aSymbol isKindOfClass: [BCNucleotideDNA class]] && ! [(BCNucleotideDNA *) aSymbol isSingleBase]) Is that correct? If true, it calculates a min and max value, based on the masses of the bases returned by representingBases and adds that to totalMin and totalMax. The new calculateMassWithRange returns an NSArray of two NSNumbers based on totalMin and totalMax, that can be interpreted by the client as needed. Now I need some DNA sequence that contains ambigous bases, so I can test this. Could someone paste some sequence for me (not too long, I'm still on dial-up ;-) thanks, - Koen. From mek at mekentosj.com Wed Sep 8 02:23:35 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 8 Sep 2004 08:23:35 +0200 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: <81AB3F3F-0125-11D9-A4F0-003065A5FDCC@earthlink.net> References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> <81AB3F3F-0125-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: <9D10F824-015F-11D9-B507-000393CFDE0C@mekentosj.com> Koen, > I never thought of keeping the digest object around, but if the > developer wants to keep it, why not? Indeed, that would be the idea. I was still thinking to have a digest object be fed to a digester "controller", more from a MVC model, but you're right that there's no reason to add the additional layer, I like the way you implemented the masscalculator, this one could be very alike. The like example as well: > BCProtease *protease = [[BCProtease alloc] initWithSequence: aSeq] Why BCProtease? This should be a BCDigest subclass (BCDigestDNA/RNA/Protein) right? Thus: [BCDigest *digest = [[BCDigest alloc] initWithSequence: aSeq]; Then the next step would be to instantiate the enzyme: > BCProtease *protease = [BCProtease enzymeWithName: @"trypsin"]; In principle BCProtease would be a subclass of BCEnzyme, just as BCRestrictionEnzyme, which all would have class methods to call for predefined enzymes (from a singleton dictionary), and methods to instantiate new ones from scratch/plist (like the BCSymbol subclasses). > [protease setEnzyme: @trypsin]; the reason for seeing things as digests instead of proteases would be to allow cleavage with multiple enzymes, like is commonly the case with restriction enzymes. Therefore, the enzymes should be an array which you can add and remove enzymes from. this line would then become: [digest addEnzyme: protease]; > // or based on a popup menu, well that's something appkit like, doesn't really matter here how the developer implements that. > [protease digest] [digest performDigestion]; would be a convenient way to start the digestion on cue, but we can also let the internal methods give the cue automatically if you ask for the digest results. In addition, if the object is kept around, adding and removing enzymes while a previous result is present should trigger a redigest. Something we have to watch out for is that the sequence object contained in the object is a mutable one, so potentially can be changed underneath us. Unless we do not store a pointer, but would copy it. This however might be expensive. So perhaps this is one of the examples where it would be handy to have both a mutable and immutable variants of the BCSequence class. Unless anyone of you can shed more light on the issue. > NSArray *thePeptides = [digest digestResult]; That would be the idea. This means that the result is cached by the digest object right? > [protease release]; // optional That would be the way to discard/keep things around. Very nice. >> >> The other think I would like to add to a BCSequence is the info of >> which enzyme produced the 5' end and which the 3' end. > > Yes, that's taken care of in the plist using the CleaveDirection key. > We have to add some code like: > > [newPeptide setCleavedAt: cleavedAtN]; // or 5' or 3' or > cleavedAtC Well that's not exactly what I meant. When you cut vector DNA with for instance EcoRI and BamHI, you would get for example: Fragment 1: EcoRI---------------BamHI Fragment 2: BamHI--------------EcoRI So what I thought was to store in a new BCSequenceDNA subclass, called BCFragmentDNA two variables like [fragment1 set5EndEnzyme: ecori]; // ecori and bamhi are of class BCEnzyme, or BCRestrictionEnzyme to be more precise [fragment1 set3EndEnzyme: bamhi]; indeed set by the digest object. for peptides that would be [peptide setCarboxyEnzyme: nil]; [peptide setAminoEnzyme: trypsin]; Although I hate the set5EndEnzyme already so if anyone could come up with a better name, ideally spanning all sequence types (DNA/RNA/Protein)..... Finally, besides the enzymes, the fragment class also needs to store the position it represents within the uncut sequence (see below) > >> Therefore, I proposed the BCFragment class, which could be a subclass >> of BCSequence that stores these additional BCEnzyme variables (which >> can also be nil by default if the end is untreated). > > The BCFragment would be similar to a separate BCPeptide class, > correct? Then let's create both classes if that makes it easier. If you mean you like BCPeptide better than BCFragmentProtein, yes. But BCPeptide would be at least a subclass of a general BCFragment class right? > >> The nice thing is that for the BCDigest story above, nothing changes >> still get an array of BCSequences returned, but as a convenience the >> digest object fills in which enzyme produced the ends. > >> Very nice indeed, the plists are definitely the way to go. Still, for >> restriction enzymes instantiating 600 enzymes each time would be to >> expensive I think, so that's where it would be nice to instantiate >> once from the plist and keep the objects around in a static >> dictionary. > > I'm not familiair with restriction enzyms, can you explain why you > have to instantiate 600 enzymes if you're just using one? Not so specifically for digest indeed (unless one feels the need to mix the content of his freezer and see how many bands he can produce of course ;-), but I was more thinking in the direction of mapping. So where are all the restriction enzyme sites inside my vector. Like a BCDigest, you could think in the direction of a very analogous BCMap which would return instead of an array of fragments, an array of positions. You would feed BCMap, a single sequence, enzyme(s), and it would return all cut positions. Again, you can keep the object around if you want to "cache" the results. To check a vector for the positions of all 600 available commercial restriction enzymes, one has to instantiate all of them each time. Therefore I like to have a predefined set available in a singleton dictionary, just like the proteases. The question is whether the mapping and digestion requires two separate classes, I think we can fuse them into one, as long as we provide sufficient methods to let them act in both ways. What we could do is have the class work as follows: BCDigest stores: enzymes array sequence results array mechanism: set sequence and enzymes call digest (can be triggered automatically if results are asked for) creates fragments in results array, which contain an NSRange variable as well with their location in the original sequence) results: (NSArray *)fragments; returns the array of fragments (NSArray *)cutpositions; returns the array of cutpositions by enumaration over the fragments' ranges This would create a very flexible class that can be used for mapping, determining cut positions, but also doing single and multiple enzyme digests. 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 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 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 Wed Sep 8 02:27:29 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 8 Sep 2004 08:27:29 +0200 Subject: [Biococoa-dev] MW of DNA with ambiguous bases In-Reply-To: <71D83674-0137-11D9-A4F0-003065A5FDCC@earthlink.net> References: <71D83674-0137-11D9-A4F0-003065A5FDCC@earthlink.net> Message-ID: <2877D75A-0160-11D9-B507-000393CFDE0C@mekentosj.com> I usually start hitting the acgt like an idiot to build my own dummy sequence. I guess most easy way to start is to generate a simple ACGTACGT and then add one or more ambiguous symbols to see if calculations are correct.... The list of symbols the method should support would be: ACGTNWMYRKHVDB-? Alex Op 8-sep-04 om 3:36 heeft Koen van der Drift het volgende geschreven: > Hi, > > I'm working on some code in BCMassCalculator that takes care of > ambigous bases. First I test to see if it is an ambiguous base as > follows: > > if ( [aSymbol isKindOfClass: [BCNucleotideDNA class]] && ! > [(BCNucleotideDNA *) aSymbol isSingleBase]) > > Is that correct? > > > If true, it calculates a min and max value, based on the masses of the > bases returned by representingBases and adds that to totalMin and > totalMax. The new calculateMassWithRange returns an NSArray of two > NSNumbers based on totalMin and totalMax, that can be interpreted by > the client as needed. > > Now I need some DNA sequence that contains ambigous bases, so I can > test this. Could someone paste some sequence for me (not too long, I'm > still on dial-up ;-) > > > > 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 Microsoft is not the answer, Microsoft is the question, NO is the answer ********************************************************* From peter.schols at bio.kuleuven.ac.be Wed Sep 8 03:18:00 2004 From: peter.schols at bio.kuleuven.ac.be (Peter Schols) Date: Wed, 8 Sep 2004 09:18:00 +0200 Subject: [Biococoa-dev] GNUStep Compatibility (was: [Biococoa-dev] Optimizations) In-Reply-To: References: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> <6E507E30-0113-11D9-B91E-000A95EECBDE@duke.edu> Message-ID: <3755C8EA-0167-11D9-8AA7-00039345483C@bio.kuleuven.ac.be> Hi Alex, Jim and others, Last year, we have tried to submit an application note about BC to Bioinformatics. The application note did not get accepted, mainly because the only reviewer (!) was a Mac-hater. Bioinformatics only accepts application notes about open-source software that runs on as much platforms as possible (mostly Java or C apps). That's the reason why we emphasized the cross-platform possibilities with our BC code. I think we should still try to submit an application note to BI (or another journal) within a few months, when we have a stable BC release. If the list agrees with that, compatibility with GNUstep would be necessary. On the other hand, I love many of the recent additions: bindings in Panther, core data in Tiger and I guess many of you like them too.... it will take the GNUstep team quite some time to integrate them, if they appear at all... Whether we should keep our framework below its own speed and possibilities just for the sake of GNUstep compatibility is a hard question. I'd be interested in your opinions. Peter On 07 Sep 2004, at 23:27, Alexander Griekspoor wrote: > Hi Jim, > > Nice to hear from you again, seems you're well on you way for your > graduation! > For me, GNUstep compatibility is not high on my list, but perhaps the > others think it's of more importance. I could imagine that at least > marketing wise it seems nice that you can say you potentially address > a far larger public. Although, I doubt if that extends practically at > all. But I would like to hear especially Peter's comments on the issue > as he's the one advertising GNUstep compatibility right now ;-) > Cheers and good luck with the graduation! > Alex > > Op 7-sep-04 om 23:18 heeft Jim Balhoff het volgende geschreven: > >> Hey guys, >> >> I've just been lurking for a while, but I wanted to jump in with one >> reason I thought of to avoid CoreFoundation - portability. >> Currently, the BioCocoa website advertises GNUstep compatibility. >> The GNUstep Foundation works quite well and so it's not too much >> trouble to stay compatible with if you stick to the standard C and >> Foundation API. But if GNUstep is to be excluded, by all means >> optimize where needed. >> >> I am hoping to jump into BioCocoa in 2 or 3 months, since it looks >> like I'll be able to do lots more programming in a post-doc I'm >> trying to get after I graduate. Until then, I'll just keep >> listening. >> >> - Jim >> >> On Sep 7, 2004, at 2:41 AM, Alexander Griekspoor wrote: >> >>> This is impressive stuff John, well done! My experience with many of >>> the CF classes is a drama, but I might start looking at it as well. >>> Where speed is a bottleneck, I have absolutely no problem with these >>> kind of optimizations in internal implementations. I do propose to >>> add some extra lines of comments though, to describe a bit what you >>> do and why you choose to use the CF classes there (for poor soles >>> like me ;-) >>> Alex >> >> _______________________________________________ >> 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 > > Microsoft is not the answer, > Microsoft is the question, > NO is the answer > > ********************************************************* > > > ********************************************************* > ** 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 > > ********************************************************* > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev From mek at mekentosj.com Wed Sep 8 03:51:10 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 8 Sep 2004 09:51:10 +0200 Subject: [Biococoa-dev] GNUStep Compatibility (was: [Biococoa-dev] Optimizations) In-Reply-To: <3755C8EA-0167-11D9-8AA7-00039345483C@bio.kuleuven.ac.be> References: <0516566E-0099-11D9-B507-000393CFDE0C@mekentosj.com> <6E507E30-0113-11D9-B91E-000A95EECBDE@duke.edu> <3755C8EA-0167-11D9-8AA7-00039345483C@bio.kuleuven.ac.be> Message-ID: Ha Peter, Now we're starting to talk about the real thing, we need a PR person ;-) Again, for me the only reason to stay GNUStep compatible is a marketing technical one. The question would be to John and Koen, how much work would it be to either optimize without CF usage, or optimize only on our platform (probably using compiler tricks to switch between with or without optimization)? I do have noticed indeed that without the "on-multiple-platform" argument it's often hard to sell a Cocoa framework to the mass or get articles/sponsorships... Alex Op 8-sep-04 om 9:18 heeft Peter Schols het volgende geschreven: > Hi Alex, Jim and others, > > Last year, we have tried to submit an application note about BC to > Bioinformatics. The application note did not get accepted, mainly > because the only reviewer (!) was a Mac-hater. Bioinformatics only > accepts application notes about open-source software that runs on as > much platforms as possible (mostly Java or C apps). That's the reason > why we emphasized the cross-platform possibilities with our BC code. I > think we should still try to submit an application note to BI (or > another journal) within a few months, when we have a stable BC > release. If the list agrees with that, compatibility with GNUstep > would be necessary. On the other hand, I love many of the recent > additions: bindings in Panther, core data in Tiger and I guess many of > you like them too.... it will take the GNUstep team quite some time to > integrate them, if they appear at all... > > Whether we should keep our framework below its own speed and > possibilities just for the sake of GNUstep compatibility is a hard > question. I'd be interested in your opinions. > > Peter > > > On 07 Sep 2004, at 23:27, Alexander Griekspoor wrote: > >> Hi Jim, >> >> Nice to hear from you again, seems you're well on you way for your >> graduation! >> For me, GNUstep compatibility is not high on my list, but perhaps the >> others think it's of more importance. I could imagine that at least >> marketing wise it seems nice that you can say you potentially address >> a far larger public. Although, I doubt if that extends practically at >> all. But I would like to hear especially Peter's comments on the >> issue as he's the one advertising GNUstep compatibility right now ;-) >> Cheers and good luck with the graduation! >> Alex >> >> Op 7-sep-04 om 23:18 heeft Jim Balhoff het volgende geschreven: >> >>> Hey guys, >>> >>> I've just been lurking for a while, but I wanted to jump in with one >>> reason I thought of to avoid CoreFoundation - portability. >>> Currently, the BioCocoa website advertises GNUstep compatibility. >>> The GNUstep Foundation works quite well and so it's not too much >>> trouble to stay compatible with if you stick to the standard C and >>> Foundation API. But if GNUstep is to be excluded, by all means >>> optimize where needed. >>> >>> I am hoping to jump into BioCocoa in 2 or 3 months, since it looks >>> like I'll be able to do lots more programming in a post-doc I'm >>> trying to get after I graduate. Until then, I'll just keep >>> listening. >>> >>> - Jim >>> >>> On Sep 7, 2004, at 2:41 AM, Alexander Griekspoor wrote: >>> >>>> This is impressive stuff John, well done! My experience with many >>>> of the CF classes is a drama, but I might start looking at it as >>>> well. >>>> Where speed is a bottleneck, I have absolutely no problem with >>>> these kind of optimizations in internal implementations. I do >>>> propose to add some extra lines of comments though, to describe a >>>> bit what you do and why you choose to use the CF classes there (for >>>> poor soles like me ;-) >>>> Alex >>> >>> _______________________________________________ >>> 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 >> >> Microsoft is not the answer, >> Microsoft is the question, >> NO is the answer >> >> ********************************************************* >> >> >> ********************************************************* >> ** 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 >> >> ********************************************************* >> >> _______________________________________________ >> Biococoa-dev mailing list >> Biococoa-dev at bioinformatics.org >> https://bioinformatics.org/mailman/listinfo/biococoa-dev > > _______________________________________________ > 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 jtimmer at bellatlantic.net Wed Sep 8 12:20:39 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 08 Sep 2004 12:20:39 -0400 Subject: [Biococoa-dev] GNUStep Compatibility In-Reply-To: Message-ID: I looked over the GNUstep site, and they do have a compiler directive (#ifndef GNUSTEP) that they specifically recommend for avoiding problems like this. Helpfully, it was part of an FAQ that pointed out a fundamental problem that's going to be significant going forward - using Xcode for development will automatically include Cocoa/Cocoa.h, and THAT ALONE is incompatible with GNUstep. To keep things GNUstep compatible, we're going to have to go back and edit pretty much all of the source code we've made recently in order to ifndef every set of import statements, and we have to be very careful going forward. Given all this, I think it might be valuable to have someone sign up to the GNUstep-dev mailing list and hash out some of the issues. They may have some specific thoughts on cross-platform optimizations. If nobody else volunteers, I guess I'll wind up doing it, since I'm the one who's caused the problem anyway. Incidentally, I've only optimized existing methods so far, so it should be relatively simple (if extremely tedious) to go back in the CVS history, figure out the differences, and place the previous ObjC only method back within the appropriate compiler directives. My optimistic thought is that this is going to be very painful right now, but if we figure out a system soon, maintaining compatibility going forward might not be that bad. My fear is that Apple's Xcode updates will make it harder. To me, the decision seems to be about whether it's worth losing some PR and academic credibility in order to provide something to a community that's unlikely to care. I'm not entirely sure where I stand on that issue. John > Now we're starting to talk about the real thing, we need a PR person > ;-) Again, for me the only reason to stay GNUStep compatible is a > marketing technical one. The question would be to John and Koen, how > much work would it be to either optimize without CF usage, or optimize > only on our platform (probably using compiler tricks to switch between > with or without optimization)? > I do have noticed indeed that without the "on-multiple-platform" > argument it's often hard to sell a Cocoa framework to the mass or get > articles/sponsorships... > Alex > > Op 8-sep-04 om 9:18 heeft Peter Schols het volgende geschreven: > >> Hi Alex, Jim and others, >> >> Last year, we have tried to submit an application note about BC to >> Bioinformatics. The application note did not get accepted, mainly >> because the only reviewer (!) was a Mac-hater. Bioinformatics only >> accepts application notes about open-source software that runs on as >> much platforms as possible (mostly Java or C apps). That's the reason >> why we emphasized the cross-platform possibilities with our BC code. I >> think we should still try to submit an application note to BI (or >> another journal) within a few months, when we have a stable BC >> release. If the list agrees with that, compatibility with GNUstep >> would be necessary. On the other hand, I love many of the recent >> additions: bindings in Panther, core data in Tiger and I guess many of >> you like them too.... it will take the GNUstep team quite some time to >> integrate them, if they appear at all... >> >> Whether we should keep our framework below its own speed and >> possibilities just for the sake of GNUstep compatibility is a hard >> question. I'd be interested in your opinions. >> _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Wed Sep 8 13:35:43 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 8 Sep 2004 19:35:43 +0200 Subject: [Biococoa-dev] GNUStep Compatibility In-Reply-To: References: Message-ID: <82602951-01BD-11D9-8E8C-000393CFDE0C@mekentosj.com> Ok guys listen up, why don't we go for a strategy change and dump the GNUStep compatibility. So our goals was to make a great Cocoa framework that would: - be powerful and still easy to work with - leverage all the advantages not only Cocoa but also are beloved platform brings - with compact and clean open-source code And we set our minimum compatibility to MacOSX 10.2.8 Now the question is whether it should be GNUStep compatibility, which would have the huge advantage that it: - would bring our framework to the mass. - would skyrocket our credibility both in an academic and commercial way Well, guess what, the other side has a number of great frameworks already (biojava i.e.) and who makes gnusteps apps for windows nowadays? I don't even know of one! So the number of developers that it would attract or would use our framework would be virtually nil (at least that's my prediction). Thus, does it bring our framework to the mass, yes, but only as a marketing fairytail. Then the credibility issue is that a credible thought? I do believe that it would be helpful to get publications/attention etc., but I just shot it down a few lines ago, so a reviewer can if he wants. Even worse, we haven't talked about the disadvantages yet. Does the following weight up against the benefits, starting with the goals we originally set: - it would place definitely limit the number of options we have, automatically making our framework less powerful, but also less easy to work with. - we couldn't leverage many great features Cocoa offers, let alone the fact that all new stuff would never be an option - the code will turn in a mess with all the if-defs around and double implementations Furthermore, would it mean we can't use XCode and have to go back to Project Builder, no way! And finally, we're with a small group of people, the efforts and time it takes to check all this, read the mailinglists, find out workarounds, optimize two implementations, can be way better spend on other things! So why don't we just dump the GNUStep thing, I have the feeling we all think this way. I agree we're all reluctant because of the PR thing in the future, but first of all we're a long way from that and second I have thought of taking a different strategy. Why don't we try to build this killer Cocoa framework that would be a real Cocoa equivalent of the BioJava framework. It doesn't have to be as big at the start, but it has to offer the same core functions and be of good quality. Well that was our goal from the onset right? Next, when we are at that stage, we contact the people of the Open Bioinformatics Foundation (OBF, www.open-bio.org), the umbrella organization of BioPerl, -Java, -Python, etc. and apply to become a formal project and join their foundation. Apple is even a sponsor of them, and I can contact some people at Apple that I met at WWDC to actually help us with that if necessary. Once under that umbrella, I'm convinced that gives just as much credibility and PR as being GNUStep compliant. I think even more in fact. Journals for instance will definitely recognize you of being of importance with such a foundation behind you, even if your project is Mac only, the fact that your a sister project of BioJava and BioPerl would make it less of a problem. Well, I won't put all my money on it, but I'm willing to bet it's a better strategy in many respects.... What do you guys think? Alexs Op 8-sep-04 om 18:20 heeft John Timmer het volgende geschreven: > I looked over the GNUstep site, and they do have a compiler directive > (#ifndef GNUSTEP) that they specifically recommend for avoiding > problems > like this. Helpfully, it was part of an FAQ that pointed out a > fundamental > problem that's going to be significant going forward - using Xcode for > development will automatically include Cocoa/Cocoa.h, and THAT ALONE is > incompatible with GNUstep. To keep things GNUstep compatible, we're > going > to have to go back and edit pretty much all of the source code we've > made > recently in order to ifndef every set of import statements, and we > have to > be very careful going forward. > > Given all this, I think it might be valuable to have someone sign up > to the > GNUstep-dev mailing list and hash out some of the issues. They may > have > some specific thoughts on cross-platform optimizations. If nobody else > volunteers, I guess I'll wind up doing it, since I'm the one who's > caused > the problem anyway. > > Incidentally, I've only optimized existing methods so far, so it > should be > relatively simple (if extremely tedious) to go back in the CVS history, > figure out the differences, and place the previous ObjC only method > back > within the appropriate compiler directives. > > My optimistic thought is that this is going to be very painful right > now, > but if we figure out a system soon, maintaining compatibility going > forward > might not be that bad. My fear is that Apple's Xcode updates will > make it > harder. To me, the decision seems to be about whether it's worth > losing > some PR and academic credibility in order to provide something to a > community that's unlikely to care. I'm not entirely sure where I stand > on > that issue. > > John > > >> Now we're starting to talk about the real thing, we need a PR person >> ;-) Again, for me the only reason to stay GNUStep compatible is a >> marketing technical one. The question would be to John and Koen, how >> much work would it be to either optimize without CF usage, or optimize >> only on our platform (probably using compiler tricks to switch between >> with or without optimization)? >> I do have noticed indeed that without the "on-multiple-platform" >> argument it's often hard to sell a Cocoa framework to the mass or get >> articles/sponsorships... >> Alex >> >> Op 8-sep-04 om 9:18 heeft Peter Schols het volgende geschreven: >> >>> Hi Alex, Jim and others, >>> >>> Last year, we have tried to submit an application note about BC to >>> Bioinformatics. The application note did not get accepted, mainly >>> because the only reviewer (!) was a Mac-hater. Bioinformatics only >>> accepts application notes about open-source software that runs on as >>> much platforms as possible (mostly Java or C apps). That's the reason >>> why we emphasized the cross-platform possibilities with our BC code. >>> I >>> think we should still try to submit an application note to BI (or >>> another journal) within a few months, when we have a stable BC >>> release. If the list agrees with that, compatibility with GNUstep >>> would be necessary. On the other hand, I love many of the recent >>> additions: bindings in Panther, core data in Tiger and I guess many >>> of >>> you like them too.... it will take the GNUstep team quite some time >>> to >>> integrate them, if they appear at all... >>> >>> Whether we should keep our framework below its own speed and >>> possibilities just for the sake of GNUstep compatibility is a hard >>> question. I'd be interested in your opinions. >>> > > _______________________________________________ > 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 MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From jtimmer at bellatlantic.net Wed Sep 8 13:58:23 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 08 Sep 2004 13:58:23 -0400 Subject: [Biococoa-dev] RNA vs. DNA In-Reply-To: Message-ID: Okay, simple question that's arising out of fear alone: If I want to create the RNA equivalents of the symbol and sequence classes, is there anything I'd need to do aside from a find and replace with "uridine" for "thymidine" and "U" for "T"? Are ambiguous bases also used for RNA? The reason I'm asking is that I'm gradually realizing that formalizing the translation code would be easiest to do working with DNA and RNA in parallel, and from the BioCocoa perspective, RNA doesn't exist at the moment. Figure I might as well fix that omission. Cheers, John _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Wed Sep 8 14:10:52 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 8 Sep 2004 20:10:52 +0200 Subject: [Biococoa-dev] RNA vs. DNA In-Reply-To: References: Message-ID: <6B8D7E81-01C2-11D9-8E8C-000393CFDE0C@mekentosj.com> > If I want to create the RNA equivalents of the symbol and sequence > classes, > is there anything I'd need to do aside from a find and replace with > "uridine" for "thymidine" and "U" for "T"? Yes, replace uracil for thymidine ;-) > Are ambiguous bases also used > for RNA? I believe so, but if there's a 100% replacement for all T's for U's, that I'm not 100% sure. > The reason I'm asking is that I'm gradually realizing that formalizing > the > translation code would be easiest to do working with DNA and RNA in > parallel, and from the BioCocoa perspective, RNA doesn't exist at the > moment. Figure I might as well fix that omission. It's certainly more than welcome! Great! 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 LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From peter.schols at bio.kuleuven.ac.be Wed Sep 8 17:17:38 2004 From: peter.schols at bio.kuleuven.ac.be (Peter Schols) Date: Wed, 8 Sep 2004 23:17:38 +0200 Subject: [Biococoa-dev] GNUStep Compatibility In-Reply-To: <82602951-01BD-11D9-8E8C-000393CFDE0C@mekentosj.com> References: <82602951-01BD-11D9-8E8C-000393CFDE0C@mekentosj.com> Message-ID: <82CAA1E9-01DC-11D9-8060-003065D0AD9E@bio.kuleuven.ac.be> Alex, I think you are totally right and your comments are very convincing and they make a lot of sense. As I explained, the only reason that GNUstep is even mentioned on the BC homepage is to get the application note accepted in Bioinformatics (which BTW did not help). I never tried to compile it on GNUstep. I totally agree that we should focus on making BC a great Cocoa and Mac OS X framework and that the rest will follow automatically. So I'd agree to dump GNUstep compatibility for the time being. peter On 08 Sep 2004, at 19:35, Alexander Griekspoor wrote: > Ok guys listen up, why don't we go for a strategy change and dump the > GNUStep compatibility. > > So our goals was to make a great Cocoa framework that would: > - be powerful and still easy to work with > - leverage all the advantages not only Cocoa but also are beloved > platform brings > - with compact and clean open-source code > > And we set our minimum compatibility to MacOSX 10.2.8 > > Now the question is whether it should be GNUStep compatibility, which > would have the huge advantage that it: > - would bring our framework to the mass. > - would skyrocket our credibility both in an academic and commercial > way > > Well, guess what, the other side has a number of great frameworks > already (biojava i.e.) and who makes gnusteps apps for windows > nowadays? I don't even know of one! So the number of developers that > it would attract or would use our framework would be virtually nil (at > least that's my prediction). Thus, does it bring our framework to the > mass, yes, but only as a marketing fairytail. > > Then the credibility issue is that a credible thought? I do believe > that it would be helpful to get publications/attention etc., but I > just shot it down a few lines ago, so a reviewer can if he wants. > > Even worse, we haven't talked about the disadvantages yet. Does the > following weight up against the benefits, starting with the goals we > originally set: > - it would place definitely limit the number of options we have, > automatically making our framework less powerful, but also less easy > to work with. > - we couldn't leverage many great features Cocoa offers, let alone the > fact that all new stuff would never be an option > - the code will turn in a mess with all the if-defs around and double > implementations > > Furthermore, would it mean we can't use XCode and have to go back to > Project Builder, no way! And finally, we're with a small group of > people, the efforts and time it takes to check all this, read the > mailinglists, find out workarounds, optimize two implementations, can > be way better spend on other things! > > So why don't we just dump the GNUStep thing, I have the feeling we all > think this way. I agree we're all reluctant because of the PR thing in > the future, but first of all we're a long way from that and second I > have thought of taking a different strategy. > > Why don't we try to build this killer Cocoa framework that would be a > real Cocoa equivalent of the BioJava framework. It doesn't have to be > as big at the start, but it has to offer the same core functions and > be of good quality. Well that was our goal from the onset right? > Next, when we are at that stage, we contact the people of the Open > Bioinformatics Foundation (OBF, www.open-bio.org), the umbrella > organization of BioPerl, -Java, -Python, etc. and apply to become a > formal project and join their foundation. Apple is even a sponsor of > them, and I can contact some people at Apple that I met at WWDC to > actually help us with that if necessary. Once under that umbrella, I'm > convinced that gives just as much credibility and PR as being GNUStep > compliant. I think even more in fact. Journals for instance will > definitely recognize you of being of importance with such a foundation > behind you, even if your project is Mac only, the fact that your a > sister project of BioJava and BioPerl would make it less of a problem. > Well, I won't put all my money on it, but I'm willing to bet it's a > better strategy in many respects.... > > What do you guys think? > Alexs > > > > Op 8-sep-04 om 18:20 heeft John Timmer het volgende geschreven: > >> I looked over the GNUstep site, and they do have a compiler directive >> (#ifndef GNUSTEP) that they specifically recommend for avoiding >> problems >> like this. Helpfully, it was part of an FAQ that pointed out a >> fundamental >> problem that's going to be significant going forward - using Xcode for >> development will automatically include Cocoa/Cocoa.h, and THAT ALONE >> is >> incompatible with GNUstep. To keep things GNUstep compatible, we're >> going >> to have to go back and edit pretty much all of the source code we've >> made >> recently in order to ifndef every set of import statements, and we >> have to >> be very careful going forward. >> >> Given all this, I think it might be valuable to have someone sign up >> to the >> GNUstep-dev mailing list and hash out some of the issues. They may >> have >> some specific thoughts on cross-platform optimizations. If nobody >> else >> volunteers, I guess I'll wind up doing it, since I'm the one who's >> caused >> the problem anyway. >> >> Incidentally, I've only optimized existing methods so far, so it >> should be >> relatively simple (if extremely tedious) to go back in the CVS >> history, >> figure out the differences, and place the previous ObjC only method >> back >> within the appropriate compiler directives. >> >> My optimistic thought is that this is going to be very painful right >> now, >> but if we figure out a system soon, maintaining compatibility going >> forward >> might not be that bad. My fear is that Apple's Xcode updates will >> make it >> harder. To me, the decision seems to be about whether it's worth >> losing >> some PR and academic credibility in order to provide something to a >> community that's unlikely to care. I'm not entirely sure where I >> stand on >> that issue. >> >> John >> >> >>> Now we're starting to talk about the real thing, we need a PR person >>> ;-) Again, for me the only reason to stay GNUStep compatible is a >>> marketing technical one. The question would be to John and Koen, how >>> much work would it be to either optimize without CF usage, or >>> optimize >>> only on our platform (probably using compiler tricks to switch >>> between >>> with or without optimization)? >>> I do have noticed indeed that without the "on-multiple-platform" >>> argument it's often hard to sell a Cocoa framework to the mass or get >>> articles/sponsorships... >>> Alex >>> >>> Op 8-sep-04 om 9:18 heeft Peter Schols het volgende geschreven: >>> >>>> Hi Alex, Jim and others, >>>> >>>> Last year, we have tried to submit an application note about BC to >>>> Bioinformatics. The application note did not get accepted, mainly >>>> because the only reviewer (!) was a Mac-hater. Bioinformatics only >>>> accepts application notes about open-source software that runs on as >>>> much platforms as possible (mostly Java or C apps). That's the >>>> reason >>>> why we emphasized the cross-platform possibilities with our BC >>>> code. I >>>> think we should still try to submit an application note to BI (or >>>> another journal) within a few months, when we have a stable BC >>>> release. If the list agrees with that, compatibility with GNUstep >>>> would be necessary. On the other hand, I love many of the recent >>>> additions: bindings in Panther, core data in Tiger and I guess many >>>> of >>>> you like them too.... it will take the GNUstep team quite some time >>>> to >>>> integrate them, if they appear at all... >>>> >>>> Whether we should keep our framework below its own speed and >>>> possibilities just for the sake of GNUstep compatibility is a hard >>>> question. I'd be interested in your opinions. >>>> >> >> _______________________________________________ >> 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 > > MacOS X: The power of UNIX with the simplicity of the Mac > > *************************************************************** > > _______________________________________________ > Biococoa-dev mailing list > Biococoa-dev at bioinformatics.org > https://bioinformatics.org/mailman/listinfo/biococoa-dev From kvddrift at earthlink.net Wed Sep 8 18:42:15 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 8 Sep 2004 18:42:15 -0400 Subject: [Biococoa-dev] GNUStep Compatibility In-Reply-To: <82CAA1E9-01DC-11D9-8060-003065D0AD9E@bio.kuleuven.ac.be> References: <82602951-01BD-11D9-8E8C-000393CFDE0C@mekentosj.com> <82CAA1E9-01DC-11D9-8060-003065D0AD9E@bio.kuleuven.ac.be> Message-ID: <55007CE8-01E8-11D9-A866-003065A5FDCC@earthlink.net> On Sep 8, 2004, at 5:17 PM, Peter Schols wrote: > > So I'd agree to dump GNUstep compatibility for the time being. > Me too :) - Koen. From kvddrift at earthlink.net Wed Sep 8 19:53:20 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 8 Sep 2004 19:53:20 -0400 Subject: [Biococoa-dev] MW of DNA with ambiguous bases In-Reply-To: References: Message-ID: <432D0426-01F2-11D9-A866-003065A5FDCC@earthlink.net> On Sep 7, 2004, at 10:04 PM, John Timmer wrote: >> >> Now I need some DNA sequence that contains ambigous bases, so I can >> test this. Could someone paste some sequence for me (not too long, I'm >> still on dial-up ;-) > > GAATTCNRYYRNMKGAATTCHVDBGAATTC > > That shouldn't stress the dialup. > Great - I've got the code working. Now to implement it seamlessly in the rest of the code, here's what I propose. Instead of returning a float, the molecularWeight method will now return an NSArray (or NSDictionary) with a minimal mass and maximum mass. If there are no ambigous symbols, both values will be the same, if they are they will differ. This is a much better solution then using the value zero for unambigous bases, that will give a much too low MW. The same code can be used for any BCSequence, which makes everything much simpler. We can remove the molecularWeight from BCNucleotideDNA and from BCSequenceDNA as well as from the base template.plist. Let me know what you think and I will add the changes to CVS. cheers, - Koen. From kvddrift at earthlink.net Wed Sep 8 23:38:49 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 8 Sep 2004 23:38:49 -0400 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: <9D10F824-015F-11D9-B507-000393CFDE0C@mekentosj.com> References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> <81AB3F3F-0125-11D9-A4F0-003065A5FDCC@earthlink.net> <9D10F824-015F-11D9-B507-000393CFDE0C@mekentosj.com> Message-ID: On Sep 8, 2004, at 2:23 AM, Alexander Griekspoor wrote: >> BCProtease *protease = [[BCProtease alloc] initWithSequence: aSeq] > Why BCProtease? This should be a BCDigest subclass > (BCDigestDNA/RNA/Protein) right? > Thus: > [BCDigest *digest = [[BCDigest alloc] initWithSequence: aSeq]; Right. > > Then the next step would be to instantiate the enzyme: >> BCProtease *protease = [BCProtease enzymeWithName: @"trypsin"]; > In principle BCProtease would be a subclass of BCEnzyme, just as > BCRestrictionEnzyme, which all would have class methods to call for > predefined enzymes (from a singleton dictionary), and methods to > instantiate new ones from scratch/plist (like the BCSymbol > subclasses). > >> [protease setEnzyme: @trypsin]; > the reason for seeing things as digests instead of proteases would be > to allow cleavage with multiple enzymes, like is commonly the case > with restriction enzymes. Therefore, the enzymes should be an array > which you can add and remove enzymes from. > this line would then become: > [digest addEnzyme: protease]; Good idea. I will see how that fits in my code. I hope we can make a general BCDigest class, without subclassing. Although I am not sure yet how to implement multiple enzymes. Should they be handled one by one, or all at the same time (by 'summing their cleavage sites')? >> [protease digest] > [digest performDigestion]; > would be a convenient way to start the digestion on cue, but we can > also let the internal methods give the cue automatically if you ask > for the digest results. In addition, if the object is kept around, > adding and removing enzymes while a previous result is present should > trigger a redigest. Sounds like a good plan. > Something we have to watch out for is that the sequence object > contained in the object is a mutable one, so potentially can be > changed underneath us. Unless we do not store a pointer, but would > copy it. This however might be expensive. If we just store the sequenceString, which makes the use of an NSScanner very easy, then we can store it as an NSString: @implementation BCDigest -(id) initWithSequence:(BCSequence *)seq { if (self = [super init]) { [self setSequenceString: [seq sequenceString]]; .... blah } - (void) setSequenceString:(NSString *)s { [s retain]; [sequenceString release]; sequenceString = s; } > So perhaps this is one of the examples where it would be handy to have > both a mutable and immutable variants of the BCSequence class. Unless > anyone of you can shed more light on the issue. See snippet above. > >> NSArray *thePeptides = [digest digestResult]; > That would be the idea. This means that the result is cached by the > digest object right? ?Que? >> Yes, that's taken care of in the plist using the CleaveDirection key. >> We have to add some code like: >> >> [newPeptide setCleavedAt: cleavedAtN]; // or 5' or 3' or >> cleavedAtC > > Well that's not exactly what I meant. When you cut vector DNA with > for instance EcoRI and BamHI, you would get for example: > Fragment 1: EcoRI---------------BamHI > Fragment 2: BamHI--------------EcoRI > > So what I thought was to store in a new BCSequenceDNA subclass, called > BCFragmentDNA two variables like > [fragment1 set5EndEnzyme: ecori]; // ecori and bamhi are of class > BCEnzyme, or BCRestrictionEnzyme to be more precise > [fragment1 set3EndEnzyme: bamhi]; > indeed set by the digest object. > > for peptides that would be > [peptide setCarboxyEnzyme: nil]; > [peptide setAminoEnzyme: trypsin]; > > Although I hate the set5EndEnzyme already so if anyone could come up > with a better name, ideally spanning all sequence types > (DNA/RNA/Protein)..... > > Finally, besides the enzymes, the fragment class also needs to store > the position it represents within the uncut sequence (see below) > > >> >>> Therefore, I proposed the BCFragment class, which could be a >>> subclass of BCSequence that stores these additional BCEnzyme >>> variables (which can also be nil by default if the end is >>> untreated). The fragments are just sequences, and once created they no nothing about where they originate from (just as in a petridish). Why not keep that data in the BCDigest class that did the actual cutting? But I am open to more discussion, because below I suggested a BCPeptide class :) Or we make a BCDigest return a dictionary that looks something like: fragment1 sequence GATATAGATCGAT start 23 end 32 startEnzyme bamhi endEnzyme ecori There - all info stored together :) > Like a BCDigest, you could think in the direction of a very analogous > BCMap which would return instead of an array of fragments, an array of > positions. You would feed BCMap, a single sequence, enzyme(s), and it > would return all cut positions. This is already how I code my digest class. First create an array of cutpositions using the NSScanner, then feed those numbers to the actual digest, which returns the fragments. > The question is whether the mapping and digestion requires two > separate classes, I think we can fuse them into one, as long as we > provide sufficient methods to let them act in both ways. Yes - see comment above. - Koen. From mek at mekentosj.com Thu Sep 9 02:16:34 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 9 Sep 2004 08:16:34 +0200 Subject: [Biococoa-dev] MW of DNA with ambiguous bases In-Reply-To: <432D0426-01F2-11D9-A866-003065A5FDCC@earthlink.net> References: <432D0426-01F2-11D9-A866-003065A5FDCC@earthlink.net> Message-ID: > Instead of returning a float, the molecularWeight method will now > return an NSArray (or NSDictionary) with a minimal mass and maximum > mass. If there are no ambigous symbols, both values will be the same, > if they are they will differ. This is a much better solution then > using the value zero for unambigous bases, that will give a much too > low MW. Sounds perfect 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 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 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 Sep 9 07:19:56 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 9 Sep 2004 13:19:56 +0200 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> <81AB3F3F-0125-11D9-A4F0-003065A5FDCC@earthlink.net> <9D10F824-015F-11D9-B507-000393CFDE0C@mekentosj.com> Message-ID: <2DB603D0-0252-11D9-8E8C-000393CFDE0C@mekentosj.com> >>> the reason for seeing things as digests instead of proteases would >>> be to allow cleavage with multiple enzymes, like is commonly the >>> case with restriction enzymes. Therefore, the enzymes should be an >>> array which you can add and remove enzymes from. >> this line would then become: >> [digest addEnzyme: protease]; > > > Good idea. I will see how that fits in my code. I hope we can make a > general BCDigest class, without subclassing. Although I am not sure > yet how to implement multiple enzymes. Should they be handled one by > one, or all at the same time (by 'summing their cleavage sites')? The way I did that in EnzymeX was to have a custom class EXMapCut (don't bother the stupid name) that stores the position and the enzyme, which I instantiated for each position an enzyme cuts. When you do this for each enzyme and store all of the cut objects in array, then the rest is simply to sort the array on position and itterate over the array and create the fragment objects accordingly. I could imagine that you could do this with a dictionary or set as well to prevent the need for a custom object. > >> Something we have to watch out for is that the sequence object >> contained in the object is a mutable one, so potentially can be >> changed underneath us. Unless we do not store a pointer, but would >> copy it. This however might be expensive. > > If we just store the sequenceString, which makes the use of an > NSScanner very easy, then we can store it as an NSString: > > [snippet] I'm afraid this leads again to discussions we had before, but I'm not in favour of this approach for two reasons. First, you could just as well then copy the handed BCSequence and have your own copy that can't be edited. Second, we should use strings only within implementations and not as variables. Now if I want to ask the digest for its sequence, this has first to be created again from the sequencestring (losing all features for example)! >> So perhaps this is one of the examples where it would be handy to >> have both a mutable and immutable variants of the BCSequence class. >> Unless anyone of you can shed more light on the issue. > > See snippet above. I think we should still consider this option. Although, it's not of high priority right now. >>> NSArray *thePeptides = [digest digestResult]; >> That would be the idea. This means that the result is cached by the >> digest object right? > ?Que? > What I meant is that by calling [digest performDigest], the digest objects performs the digest and stores the fragments in an array, thus caching the result (you can ask the results many times without the need for recalculation). >>> Yes, that's taken care of in the plist using the CleaveDirection >>> key. We have to add some code like: >>> >>> [newPeptide setCleavedAt: cleavedAtN]; // or 5' or 3' or >>> cleavedAtC >> >> Well that's not exactly what I meant. When you cut vector DNA with >> for instance EcoRI and BamHI, you would get for example: >> Fragment 1: EcoRI---------------BamHI >> Fragment 2: BamHI--------------EcoRI >> >> So what I thought was to store in a new BCSequenceDNA subclass, >> called BCFragmentDNA two variables like >> [fragment1 set5EndEnzyme: ecori]; // ecori and bamhi are of >> class BCEnzyme, or BCRestrictionEnzyme to be more precise >> [fragment1 set3EndEnzyme: bamhi]; >> indeed set by the digest object. >> >> for peptides that would be >> [peptide setCarboxyEnzyme: nil]; >> [peptide setAminoEnzyme: trypsin]; >> >> Although I hate the set5EndEnzyme already so if anyone could come up >> with a better name, ideally spanning all sequence types >> (DNA/RNA/Protein)..... >> >> Finally, besides the enzymes, the fragment class also needs to store >> the position it represents within the uncut sequence (see below) >> >> >>> >>>> Therefore, I proposed the BCFragment class, which could be a >>>> subclass of BCSequence that stores these additional BCEnzyme >>>> variables (which can also be nil by default if the end is >>>> untreated). > > > The fragments are just sequences, and once created they no nothing > about where they originate from (just as in a petridish). That is why the BCFragments should be subclasses of BCSequence that store the enzymes and range withing the uncut sequence. > Why not keep that data in the BCDigest class that did the actual > cutting? But I am open to more discussion, because below I suggested a > BCPeptide class :) Exactly ;-) We both want the BCFragment subclass so it seems ;-) > Or we make a BCDigest return a dictionary that looks something like: > > fragment1 > > sequence > GATATAGATCGAT > start > 23 > end > 32 > startEnzyme > bamhi > endEnzyme > ecori > > > There - all info stored together :) That's not a bad idea either, although I would prefer to store not a string but a BCSequence object under the "sequence" key in the dictionary, and the enzymes as objects as well. The start and stop could just be a single NSRange variable. Hey, wait a minute, there we have our BCFragment class ;-) But again, this might be a good alternative. The real advantage of a BCFragment class that you could easily add logic for sorting for example, because how do you sort this dictionary on cutposition for example, or worse on enzymes? >> Like a BCDigest, you could think in the direction of a very analogous >> BCMap which would return instead of an array of fragments, an array >> of positions. You would feed BCMap, a single sequence, enzyme(s), and >> it would return all cut positions. > > This is already how I code my digest class. First create an array of > cutpositions using the NSScanner, then feed those numbers to the > actual digest, which returns the fragments. Yep, exactly the plan. This brings up another thought I had, perhaps it would be nice to actually create an NSScanner equivalent for our BCSequences, I know the omni frameworks have constructed there own scanner as well, so we might look through their code for hints how to do it. The big advantage would be that we could in the implementations stay native in BCSequences instead of converting everything to strings all the time. 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 ********************************************************* From kvddrift at earthlink.net Thu Sep 9 20:36:44 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 9 Sep 2004 20:36:44 -0400 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: <2DB603D0-0252-11D9-8E8C-000393CFDE0C@mekentosj.com> References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> <81AB3F3F-0125-11D9-A4F0-003065A5FDCC@earthlink.net> <9D10F824-015F-11D9-B507-000393CFDE0C@mekentosj.com> <2DB603D0-0252-11D9-8E8C-000393CFDE0C@mekentosj.com> Message-ID: <7D79A694-02C1-11D9-AC7D-003065A5FDCC@earthlink.net> On Sep 9, 2004, at 7:19 AM, Alexander Griekspoor wrote: > The way I did that in EnzymeX was to have a custom class EXMapCut > (don't bother the stupid name) that stores the position and the > enzyme, which I instantiated for each position an enzyme cuts. When > you do this for each enzyme and store all of the cut objects in array, > then the rest is simply to sort the array on position and itterate > over the array and create the fragment objects accordingly. I could > imagine that you could do this with a dictionary or set as well to > prevent the need for a custom object. >> >>> Something we have to watch out for is that the sequence object >>> contained in the object is a mutable one, so potentially can be >>> changed underneath us. Unless we do not store a pointer, but would >>> copy it. This however might be expensive. >> >> If we just store the sequenceString, which makes the use of an >> NSScanner very easy, then we can store it as an NSString: >> >> [snippet] > > I'm afraid this leads again to discussions we had before, but I'm not > in favour of this approach for two reasons. First, you could just as > well then copy the handed BCSequence and have your own copy that can't > be edited. Second, we should use strings only within implementations > and not as variables. Now if I want to ask the digest for its > sequence, this has first to be created again from the sequencestring > (losing all features for example)! I think it is fine to use a BCSequence, I was under the impression that you thought it would be expensive, which is why I suggested to use the sequenceString. But using a BCSequence is more logical. >> Why not keep that data in the BCDigest class that did the actual >> cutting? But I am open to more discussion, because below I suggested >> a BCPeptide class :) > Exactly ;-) We both want the BCFragment subclass so it seems ;-) I guess so ;-) So, if I understand correctly, we have a general BCDigest object that is fed a BCSequence. Then after the digest, the BCDigest object spits out an array of BCFragments, containing all the needed information. And the BCFragment class is a subclass of BCSequence. But wait, then you lose the specific BCSequenceProtein and BCSequenceDNA features. So maybe we should have a BCFragmentProtein (or BCPeptide) and a BCFragmentDNA (or BCOligoNucleotide). > The start and stop could just be a single NSRange variable. Hey, wait > a minute, there we have our BCFragment class ;-) But again, this might > be a good alternative. The real advantage of a BCFragment class that > you could easily add logic for sorting for example, because how do you > sort this dictionary on cutposition for example, or worse on enzymes? You've convinced me here. >> This is already how I code my digest class. First create an array of >> cutpositions using the NSScanner, then feed those numbers to the >> actual digest, which returns the fragments. > Yep, exactly the plan. This brings up another thought I had, perhaps > it would be nice to actually create an NSScanner equivalent for our > BCSequences, I know the omni frameworks have constructed there own > scanner as well, so we might look through their code for hints how to > do it. The big advantage would be that we could in the implementations > stay native in BCSequences instead of converting everything to strings > all the time. Sounds fine - you've just assigned yourself some homework for the weekend! - Koen. From mek at mekentosj.com Fri Sep 10 05:18:09 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Fri, 10 Sep 2004 11:18:09 +0200 Subject: [Biococoa-dev] peptides and proteins In-Reply-To: <7D79A694-02C1-11D9-AC7D-003065A5FDCC@earthlink.net> References: <96982274-0096-11D9-B507-000393CFDE0C@mekentosj.com> <57E69E9A-011B-11D9-A4F0-003065A5FDCC@earthlink.net> <81AB3F3F-0125-11D9-A4F0-003065A5FDCC@earthlink.net> <9D10F824-015F-11D9-B507-000393CFDE0C@mekentosj.com> <2DB603D0-0252-11D9-8E8C-000393CFDE0C@mekentosj.com> <7D79A694-02C1-11D9-AC7D-003065A5FDCC@earthlink.net> Message-ID: <5531B16E-030A-11D9-819B-000393CFDE0C@mekentosj.com> >>> Why not keep that data in the BCDigest class that did the actual >>> cutting? But I am open to more discussion, because below I suggested >>> a BCPeptide class :) >> Exactly ;-) We both want the BCFragment subclass so it seems ;-) > > I guess so ;-) So, if I understand correctly, we have a general > BCDigest object that is fed a BCSequence. Then after the digest, the > BCDigest object spits out an array of BCFragments, containing all the > needed information. And the BCFragment class is a subclass of > BCSequence. But wait, then you lose the specific BCSequenceProtein and > BCSequenceDNA features. So maybe we should have a BCFragmentProtein > (or BCPeptide) and a BCFragmentDNA (or BCOligoNucleotide). That was exactly the plan, but to keep things general I mentioned the BCFragment superclass in the examples. I prefer BCFragmentDNA/RNA for nucleotides as oligos are not necessarily made by enzyme cleavage, but I leave it up to you if you want to call the protein version BCFragmentProtein or BCPeptide... >>> This is already how I code my digest class. First create an array of >>> cutpositions using the NSScanner, then feed those numbers to the >>> actual digest, which returns the fragments. >> Yep, exactly the plan. This brings up another thought I had, perhaps >> it would be nice to actually create an NSScanner equivalent for our >> BCSequences, I know the omni frameworks have constructed there own >> scanner as well, so we might look through their code for hints how to >> do it. The big advantage would be that we could in the >> implementations stay native in BCSequences instead of converting >> everything to strings all the time. > > > Sounds fine - you've just assigned yourself some homework for the > weekend! That's a deal! My girlfriend is out of town anyway this weekend, so I'll have a look at onmi's scanner ;-) 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 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 a.griekspoor at nki.nl Fri Sep 10 14:18:50 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Fri, 10 Sep 2004 20:18:50 +0200 Subject: [Biococoa-dev] CVS from XCode [really solved] In-Reply-To: References: <680C8985-EF14-11D8-927C-000393CFDE0C@nki.nl> Message-ID: Hi Guys, You probably remember that I managed to get XCode work with CVS once, and afterwards it never did again. But now it's really solved and it works again..... Thanks to a program called CVL (Concurrent Version Librarian, http://www.sente.ch/software/cvl/ ) who gave me a more informative error description than XCode did. It's a handy program by the way, which allows you to visually do all CVS commands, including delete. So the problem was that I somewhere had read to copy the .cvswrappers file from the developers folder to my home directory, as it would be necessary to work with nib and stuff. But that is if you run your own cvs server only. The one I had now copied was not supported by bioinformatics and gave some kind of short circuit. So after deleting the file, everything works perfectly! So that means I'm really in business. And to come back to the promise I made to Koen, I'll have a look at a BCScanner, which should be so difficult to implement (although it will be tricky to make it a bloody fast one). Also for that I think I'll add a BCSymbol set as well, analogous to the NSCharacterset.... Anyway, you will hopefully see it popup on CVS ;-) Cheers, Alex Op 16-aug-04 om 17:41 heeft Alexander Griekspoor het volgende geschreven: > I'm so ashamed! > I was looking around for help on the web to get my XCode working. So > the obvious thing to do was Googling. > - Hey, someone knows how.... > - An email from a certain Jim Balhoff, hmmm rings a bell doesn't it? > - Hey, it from the BioCocoa archives! > - Hey, it's directed to me ;-) > - OOPS! > > [BEGIN] >> >> - There is one more thing you should do in order to make Xcode work >> with the CVS repository over ssh: >> If you?d like to use ssh without having to type your password every >> time (useful if you are accessing CVS via Xcode, for example), you?ll >> want to create a public/private key pair with the ssh-keygen command. >> The advantage of doing this is that your scripts will be able to run >> without human intervention. The disadvantage is that anyone who can >> access your account on your local Mac OS X box will also be able to >> access those remote servers which have stored your public key. > > There is another way to do this, which works very well. Use > SSHPassKey to store your password in the Mac OS X keychain. It can be > configured so that Xcode will use this to get the cvs password (you > don't need to install the Project Builder plug-in mentioned in the > ReadMe). Look here: > > > - Jim > [END] > > That did the trick indeed. The things I did to make XCode work with > BioInformatics CVS: > 1 Download the program Jim pointed me to: > http://www.codefab.com/unsupported/SSHPassKey_v1.1-1.dmg > 2 Copy the app to your applications folder and run it > 3 Click "Configure Login Environment to use SSHPassKey > 4 Log off and back in > 5 Open terminal and set the environment variables and your loginname: > For Bash: > export CVS_RSH='ssh' > export CVSROOT=':ext:loginname at bioinformatics.org:/cvsroot' > > For Tsch: > setenv CVS_RSH 'ssh' > setenv CVSROOT ':ext:loginname at bioinformatics.org:/cvsroot' > 6 Do a checkout: > cvs checkout BioCocoa > your password will be asked (and stored by SSHPassKey in the keychain) > 7 Open the project in Xcode and then follow the steps in this > documents: > http://developer.apple.com/documentation/DeveloperTools/Conceptual/ > Xcode_SCM/ > 8 SSHPassKey will ask you for your password now instead of XCode. > > That should do it!! > Thanks a lot Jim, sorry for not recognizing your hints earlier... > Cheers, > Alex > > Op 16-aug-04 om 1:39 heeft Alexander Griekspoor het volgende > geschreven: > >> John, >> >> Did you get the CVS working for you already? Perhaps you or one of >> the other can help me out here. >> Using Apple's document here: >> http://developer.apple.com/documentation/DeveloperTools/Conceptual/ >> Xcode_SCM/ProjectSetup/ProjectSetup.html#//apple_ref/doc/uid/ >> TP40001208 >> I managed to checkout the framework and import it in XCode. >> Everything works fine (checked out ok using my username and password) >> but now XCode keeps asking me for authentication which fails every >> time. It seems this is a "known" issue if I believe this snippet from >> the following link: http://maczealots.com/tutorials/xcode-cvs/ >> >> [BEGIN] >> You are also going to need to set SSH up so that it won't need to >> enter a password when accessing your repository's machine. XCode has >> some sort of issues when it comes to entering an authorization >> password that I could not get past. On your laptop enter the >> following commands >> ssh-keygen -t dsa >> >> Hit enter to accept the default values for each prompt. Next, you >> will need to copy the contents of the id_dsa.pub file so you can >> paste it into the authorized_keys file on the repository machine. On >> the client machine: >> cat ~/.ssh/id_dsa.pub >> (Copy the output) >> ssh justin at Gavin.local >> vi ~/.ssh/authorized_keys >> (Paste previous output and save the file) >> >> If you can now ssh to the repository machine without entering a >> password, you should have no trouble with XCode asking for a >> password. >> >> [END] >> >> I don't believe I have access to that file, but perhaps someone else >> has the answer to this question.... (I did activate ssh connections >> in Xcode) >> 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 >> >> 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. > > ********************************************************* > > _______________________________________________ > 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 iRNAi, do you? http://www.mekentosj.com/irnai ********************************************************* From kvddrift at earthlink.net Fri Sep 10 17:28:07 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 10 Sep 2004 17:28:07 -0400 Subject: [Biococoa-dev] CVS from XCode [really solved] In-Reply-To: References: <680C8985-EF14-11D8-927C-000393CFDE0C@nki.nl> Message-ID: <4E65D818-0370-11D9-AC7D-003065A5FDCC@earthlink.net> On Sep 10, 2004, at 2:18 PM, Alexander Griekspoor wrote: > So that means I'm really in business. And to come back to the promise > I made to Koen, I'll have a look at a BCScanner, which should be so > difficult to implement I hope you mean not so difficult? > (although it will be tricky to make it a bloody fast one). Also for > that I think I'll add a BCSymbol set as well, analogous to the > NSCharacterset.... You think those classes will be faster than the ones in Foundation? If there is just a little gain, I wonder if it is worthwhile to persue. Are you still using the sequenceString to parse the sequences? Make sure you read the chapter on Class Clusters in the DevTools documentation. > Anyway, you will hopefully see it popup on CVS ;-) I cannot wait! - Koen. From a.griekspoor at nki.nl Fri Sep 10 17:33:33 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Fri, 10 Sep 2004 23:33:33 +0200 Subject: [Biococoa-dev] CVS from XCode [really solved] In-Reply-To: <4E65D818-0370-11D9-AC7D-003065A5FDCC@earthlink.net> References: <680C8985-EF14-11D8-927C-000393CFDE0C@nki.nl> <4E65D818-0370-11D9-AC7D-003065A5FDCC@earthlink.net> Message-ID: <10F0E535-0371-11D9-819B-000393CFDE0C@nki.nl> >> So that means I'm really in business. And to come back to the promise >> I made to Koen, I'll have a look at a BCScanner, which should be so >> difficult to implement > > I hope you mean not so difficult? Oops, yes indeed... > You think those classes will be faster than the ones in Foundation? If > there is just a little gain, I wonder if it is worthwhile to persue. > Are you still using the sequenceString to parse the sequences? Make > sure you read the chapter on Class Clusters in the DevTools > documentation. Well, I hope that they will be just as fast, to start with ;-) The idea would be to do all testing on the symbols directly, without any need for the sequencestring. I've the headers in place, now only the implementations are left ;-) Thanks for the documentation tip! 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 kvddrift at earthlink.net Fri Sep 10 18:11:41 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 10 Sep 2004 18:11:41 -0400 Subject: [Biococoa-dev] MW of DNA with ambiguous bases In-Reply-To: References: <432D0426-01F2-11D9-A866-003065A5FDCC@earthlink.net> Message-ID: <64806D14-0376-11D9-AC7D-003065A5FDCC@earthlink.net> On Sep 9, 2004, at 2:16 AM, Alexander Griekspoor wrote: >> Instead of returning a float, the molecularWeight method will now >> return an NSArray (or NSDictionary) with a minimal mass and maximum >> mass. If there are no ambigous symbols, both values will be the same, >> if they are they will differ. This is a much better solution then >> using the value zero for unambigous bases, that will give a much too >> low MW. > > Sounds perfect Koen! > It's now in CVS, with some code in the demo app as a test. - Koen. From kvddrift at earthlink.net Fri Sep 10 21:19:29 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 10 Sep 2004 21:19:29 -0400 Subject: [Biococoa-dev] the decorator pattern Message-ID: Hi, One of the many software design patterns is the decorator pattern. Basically the idea is to add additional functionality to an object without subclassing. Usually the decoration takes place during runtime, and therefore is dynamic, in contrast to subclassing which is static. Real examples are adding a border to a shape in a drawing program, or a style to a text (bold, italics). So maybe we should think about using the decorator pattern in BioCocoa to add temporarily additional functionality to existing classes. For instance a modification, annotation, or digest info. After the discussion with Alex about the subclasses after a digest, I still had a feeling that all those subclasses aren't really necessary. Anyway, I will have to read more about this, to see how it exactly is implemented (most sample code and tutorials I found is in Java and very short), and if it is really useful for BioCocoa. I will post later if I know more. Why do you guys think? cheers, - Koen. From mek at mekentosj.com Sat Sep 11 03:14:46 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 11 Sep 2004 09:14:46 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: References: Message-ID: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> Hi Koen, After you mentioned the "Design Patterns" book by Gamma et al. I decided to buy a second hand copy from Amazon ;-) Unfortunately, I haven't had the time to read it, but one example I remembered from skimming through the book. Guess which ;-) Indeed the best example is NSScrollView in which you can place any other type of view. And in a way, I think BCDigest can be considered a decorator as well, the other name for this pattern is "wrapper". It's kind of a bag, holding other objects and has the ability to add functionality without the need to add to the class itself. BCDigest holds a number of BCSequences and adds the possibility to do a digest without putting the logic of doing digests into the BCSequence class. I'm not sure if this helps us in here, but then again my experience is not much. If I go back to the question whether we need a BCFragment class (I think you were hinting to that), then perhaps a decorator could indeed help, although I would rather call it a wrapper in that case. The idea was to store not only the sequence, but also the enzymes that produced both ends and for example the original position in the uncut sequence. The solution we came up with was to have a BCFragment class that is a subclass of BCSequence which adds the needed variables to store the enzymes and position. And it would quickly mean three other classes, BCFragmentDNA/RNA/Protein. The 'decorator' pattern might indeed help, as we could make BCFragment normally descend of NSObject and act as a simple wrapper that stores a BCSequence (any type), the BCEnzymes which produce each end, and the position in the uncut sequence. The BCDigest class simply spits out BCFragments in this case. I think you're right Koen, this is indeed better than further subclassing BCSequence. Certainly because it would mean you can nicely keep things separated for all kinds of manipulations through the addition of single wrapper objects instead of getting tons of different BCSequence subclasses. I'm not sure if the features/annotations would benefit from this approach, it somehow feels the wrong way around for those. There the BCSequence acts as a wrapper for a number of sequences, and these are also intrinsic parts of all BCSequence objects, guess therefore these belong just in the class itself. But if you can show otherwise, I'm looking forward to that.... Great suggestion! Alex Ps. perhaps I should really start reading the book to further mine new insights ;-) Op 11-sep-04 om 3:19 heeft Koen van der Drift het volgende geschreven: > Hi, > > One of the many software design patterns is the decorator pattern. > Basically the idea is to add additional functionality to an object > without subclassing. Usually the decoration takes place during > runtime, and therefore is dynamic, in contrast to subclassing which is > static. Real examples are adding a border to a shape in a drawing > program, or a style to a text (bold, italics). > > So maybe we should think about using the decorator pattern in BioCocoa > to add temporarily additional functionality to existing classes. For > instance a modification, annotation, or digest info. After the > discussion with Alex about the subclasses after a digest, I still had > a feeling that all those subclasses aren't really necessary. > > Anyway, I will have to read more about this, to see how it exactly is > implemented (most sample code and tutorials I found is in Java and > very short), and if it is really useful for BioCocoa. I will post > later if I know more. > > > Why do you guys think? > > > 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 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 4Peaks - For Peaks, Four Peaks. 2004 Winner of the Apple Design Awards Best Mac OS X Student Product http://www.mekentosj.com/4peaks ********************************************************* From kvddrift at earthlink.net Sat Sep 11 09:39:21 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 11 Sep 2004 09:39:21 -0400 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> Message-ID: On Sep 11, 2004, at 3:14 AM, Alexander Griekspoor wrote: > The idea was to store not only the sequence, but also the enzymes that > produced both ends and for example the original position in the uncut > sequence. The solution we came up with was to have a BCFragment class > that is a subclass of BCSequence which adds the needed variables to > store the enzymes and position. And it would quickly mean three other > classes, BCFragmentDNA/RNA/Protein. The 'decorator' pattern might > indeed help, as we could make BCFragment normally descend of NSObject > and act as a simple wrapper that stores a BCSequence (any type), the > BCEnzymes which produce each end, and the position in the uncut > sequence. The BCDigest class simply spits out BCFragments in this > case. That's exactly what I had in mind. Are you going to work on this, otherwise I can try something this weekend, if I can find some time. > I'm not sure if the features/annotations would benefit from this > approach, it somehow feels the wrong way around for those. There the > BCSequence acts as a wrapper for a number of sequences, and these are > also intrinsic parts of all BCSequence objects, guess therefore these > belong just in the class itself. But if you can show otherwise, I'm > looking forward to that.... I don't know yet - but maybe we can use it for modifications? I will need to think about this a little bit more. > > Ps. perhaps I should really start reading the book to further mine new > insights ;-) Maybe I should get my own copy as well, I only had it checked out from the library a long time ago. - Koen. From mek at mekentosj.com Sat Sep 11 09:47:21 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 11 Sep 2004 15:47:21 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> Message-ID: <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> >> The idea was to store not only the sequence, but also the enzymes >> that produced both ends and for example the original position in the >> uncut sequence. The solution we came up with was to have a BCFragment >> class that is a subclass of BCSequence which adds the needed >> variables to store the enzymes and position. And it would quickly >> mean three other classes, BCFragmentDNA/RNA/Protein. The 'decorator' >> pattern might indeed help, as we could make BCFragment normally >> descend of NSObject and act as a simple wrapper that stores a >> BCSequence (any type), the BCEnzymes which produce each end, and the >> position in the uncut sequence. The BCDigest class simply spits out >> BCFragments in this case. > > That's exactly what I had in mind. Are you going to work on this, > otherwise I can try something this weekend, if I can find some time. Very nice! I'm currently working on the scanner, so go ahead if you like! Also, I made some rearrangements of groups in the project file, they do not (yet) represent a change in files so far, but I would like to do that as well. Can you guys let me know two things, first if I update the project file in the CVS, do you automatically get these changes if you use XCode as your SCM? John you had some experience with this wasn't it? The other thing is, could we agree on a timespan I get to do the changes. That would mean that you guys would have to check everything back in and not touch the CVS for a certain time. We should easily be able to pick a time where it's day here and still night at your places... > > >> I'm not sure if the features/annotations would benefit from this >> approach, it somehow feels the wrong way around for those. There the >> BCSequence acts as a wrapper for a number of sequences, and these are >> also intrinsic parts of all BCSequence objects, guess therefore these >> belong just in the class itself. But if you can show otherwise, I'm >> looking forward to that.... > > I don't know yet - but maybe we can use it for modifications? I will > need to think about this a little bit more. Definitely! > >> >> Ps. perhaps I should really start reading the book to further mine >> new insights ;-) > > > Maybe I should get my own copy as well, I only had it checked out from > the library a long time ago. It certainly is a nice overview. I decided to take a gamble and order a second hand copy at amazon, instead of a brand new one. Well it turned out great as it certainly looks almost new! Let me know about the CVS.... 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 Sat Sep 11 09:59:35 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 11 Sep 2004 09:59:35 -0400 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: On Sep 11, 2004, at 9:47 AM, Alexander Griekspoor wrote: >> That's exactly what I had in mind. Are you going to work on this, >> otherwise I can try something this weekend, if I can find some time. > Very nice! I'm currently working on the scanner, so go ahead if you > like! OK :) > Also, I made some rearrangements of groups in the project file, they > do not (yet) represent a change in files so far, but I would like to > do that as well. Can you guys let me know two things, first if I > update the project file in the CVS, do you automatically get these > changes if you use XCode as your SCM? John you had some experience > with this wasn't it? The other thing is, could we agree on a timespan > I get to do the changes. That would mean that you guys would have to > check everything back in and not touch the CVS for a certain time. We > should easily be able to pick a time where it's day here and still > night at your places... John is on vacation, if I remember correctly. I would say go ahead in the next 24 hours, I am not going to commit anything. Just make sure that you also update your pbproj file, otherwise you only move file around (in CVS). Another more drastic solution would be that you rearrange stuff in CVS, then let us know, and we can do a complete fresh checkout. - Koen. From mek at mekentosj.com Sat Sep 11 10:01:12 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 11 Sep 2004 16:01:12 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> > John is on vacation, if I remember correctly. I would say go ahead in > the next 24 hours, I am not going to commit anything. Just make sure > that you also update your pbproj file, otherwise you only move file > around (in CVS). Another more drastic solution would be that you > rearrange stuff in CVS, then let us know, and we can do a complete > fresh checkout. Ok, I'll rearrange some stuff then, probably it's indeed gonna require a fresh checkout. I'll let you guys know when I'm done.... Oh and Koen, do you agree if I change the BCMassCalculator to BCUtilMassCalculator? 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 Mac vs Windows 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From kvddrift at earthlink.net Sat Sep 11 10:23:01 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 11 Sep 2004 10:23:01 -0400 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: <16050A54-03FE-11D9-B135-003065A5FDCC@earthlink.net> On Sep 11, 2004, at 10:01 AM, Alexander Griekspoor wrote: > Ok, I'll rearrange some stuff then, probably it's indeed gonna require > a fresh checkout. I'll let you guys know when I'm done.... > Oh and Koen, do you agree if I change the BCMassCalculator to > BCUtilMassCalculator? > Yep, go ahead. Other things on my wishlist: rename StringAdditions to BCUtilString put the original BCReader et al in a separate folder named BCFiles or something like that rename Translation to BCTranslation should BCUtilTranslation be in BCTranslation or BCUtils? maybe we can have a folder BCTools with subfolders BCUtils, BCTranslation, BCDigest, etc ? make sure the folder structure in the project corresponds to that in the Xcode project. that's all folks ;) - Koen. From mek at mekentosj.com Sat Sep 11 10:32:41 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 11 Sep 2004 16:32:41 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <16050A54-03FE-11D9-B135-003065A5FDCC@earthlink.net> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> <16050A54-03FE-11D9-B135-003065A5FDCC@earthlink.net> Message-ID: <70434F7E-03FF-11D9-97D4-000393CFDE0C@mekentosj.com> > Yep, go ahead. Other things on my wishlist: > > rename StringAdditions to BCUtilString I'll do that > put the original BCReader et al in a separate folder named BCFiles or > something like that Did that ;-) > rename Translation to BCTranslation That as well > should BCUtilTranslation be in BCTranslation or BCUtils? Yep > maybe we can have a folder BCTools with subfolders BCUtils, > BCTranslation, BCDigest, etc ? Something like that would indeed be handy... I'll see what I can come up with. > > make sure the folder structure in the project corresponds to that in > the Xcode project. That's the plan indeed! If anything else comes up, let me know... 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 Sat Sep 11 11:26:42 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 11 Sep 2004 11:26:42 -0400 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <70434F7E-03FF-11D9-97D4-000393CFDE0C@mekentosj.com> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> <16050A54-03FE-11D9-B135-003065A5FDCC@earthlink.net> <70434F7E-03FF-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: On Sep 11, 2004, at 10:32 AM, Alexander Griekspoor wrote: > If anything else comes up, let me know... > We should also make one demo app, both for the original SeqConv and the new demo app. I can fuse both and commit that in a couple of days. - Koen. From mek at mekentosj.com Sat Sep 11 11:28:03 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 11 Sep 2004 17:28:03 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> <16050A54-03FE-11D9-B135-003065A5FDCC@earthlink.net> <70434F7E-03FF-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: <2BFF621E-0407-11D9-97D4-000393CFDE0C@mekentosj.com> > We should also make one demo app, both for the original SeqConv and > the new demo app. I can fuse both and commit that in a couple of days. I'm not sure Koen, I like the idea more to have a couple of smaller (and thus easier to understand) demo apps that demonstrate specific tasks. SeqIO and Sequence manipulations are quite far apart. I have already created a folder "Examples" which should contain all examples. Also, I will rename demo_app to something more descriptive... Is that ok? 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 Sat Sep 11 11:54:34 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 11 Sep 2004 11:54:34 -0400 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <2BFF621E-0407-11D9-97D4-000393CFDE0C@mekentosj.com> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> <16050A54-03FE-11D9-B135-003065A5FDCC@earthlink.net> <70434F7E-03FF-11D9-97D4-000393CFDE0C@mekentosj.com> <2BFF621E-0407-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: On Sep 11, 2004, at 11:28 AM, Alexander Griekspoor wrote: > I'm not sure Koen, I like the idea more to have a couple of smaller > (and thus easier to understand) demo apps that demonstrate specific > tasks. That makes more sense. > SeqIO and Sequence manipulations are quite far apart. I have already > created a folder "Examples" which should contain all examples. Also, I > will rename demo_app to something more descriptive... Is that ok? No problem for me - I guess it should contain the word 'translate'. - Koen. From mek at mekentosj.com Sat Sep 11 11:55:36 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 11 Sep 2004 17:55:36 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <1AACD8C3-03F9-11D9-97D4-000393CFDE0C@mekentosj.com> <0A1723FA-03FB-11D9-97D4-000393CFDE0C@mekentosj.com> <16050A54-03FE-11D9-B135-003065A5FDCC@earthlink.net> <70434F7E-03FF-11D9-97D4-000393CFDE0C@mekentosj.com> <2BFF621E-0407-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: <0568718E-040B-11D9-97D4-000393CFDE0C@mekentosj.com> >> SeqIO and Sequence manipulations are quite far apart. I have already >> created a folder "Examples" which should contain all examples. Also, >> I will rename demo_app to something more descriptive... Is that ok? > > No problem for me - I guess it should contain the word 'translate'. Okiedo ;-) ********************************************************* ** 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 Sep 11 15:40:34 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 11 Sep 2004 15:40:34 -0400 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> Message-ID: <72EB0298-042A-11D9-B135-003065A5FDCC@earthlink.net> On Sep 11, 2004, at 3:14 AM, Alexander Griekspoor wrote: > I think you're right Koen, this is indeed better than further > subclassing BCSequence. Certainly because it would mean you can nicely > keep things separated for all kinds of manipulations through the > addition of single wrapper objects instead of getting tons of > different BCSequence subclasses. > We already have some in BioCocoa: BCUtilDNATranslator, BCUtilMassCalculator. Anyway, I am working now on the digest code, and want to make sure that I get the design right. 1. BCUtilDigest is fed a BCSequence and enzyme information and does the digest either by an external trigger or internally. 2. It returns an NSArray of BCFragment objects which are wrappers conatining all info: the sequence, the original location, the enzyme. Do we need a separate BCUtilDigestProtein, BCUtilDigestDNA? We have to make sure BTW, that we use the 1-based counting when dealing with subsequences. cheers, - Koen. From mek at mekentosj.com Sat Sep 11 16:01:01 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sat, 11 Sep 2004 22:01:01 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <72EB0298-042A-11D9-B135-003065A5FDCC@earthlink.net> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <72EB0298-042A-11D9-B135-003065A5FDCC@earthlink.net> Message-ID: <4E616399-042D-11D9-97D4-000393CFDE0C@mekentosj.com> >> I think you're right Koen, this is indeed better than further >> subclassing BCSequence. Certainly because it would mean you can >> nicely keep things separated for all kinds of manipulations through >> the addition of single wrapper objects instead of getting tons of >> different BCSequence subclasses. >> > > We already have some in BioCocoa: BCUtilDNATranslator, > BCUtilMassCalculator. That wasn't so much the problem. What I meant was having not only the additional BCFragment class, but then in addition a BCFragmentDNA, -RNA and -Protein/Peptide class. That makes 4 already... > Anyway, I am working now on the digest code, and want to make sure > that I get the design right. > > 1. BCUtilDigest is fed a BCSequence and enzyme information and does > the digest either by an external trigger or internally. > > 2. It returns an NSArray of BCFragment objects which are wrappers > conatining all info: the sequence, the original location, the enzyme. Exactly the plan! > > Do we need a separate BCUtilDigestProtein, BCUtilDigestDNA? Nope, not for a reason that I can think of at least. > We have to make sure BTW, that we use the 1-based counting when > dealing with subsequences. Good point. 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 kvddrift at earthlink.net Sat Sep 11 19:12:49 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 11 Sep 2004 19:12:49 -0400 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <4E616399-042D-11D9-97D4-000393CFDE0C@mekentosj.com> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <72EB0298-042A-11D9-B135-003065A5FDCC@earthlink.net> <4E616399-042D-11D9-97D4-000393CFDE0C@mekentosj.com> Message-ID: <192BA222-0448-11D9-B135-003065A5FDCC@earthlink.net> On Sep 11, 2004, at 4:01 PM, Alexander Griekspoor wrote: >> Anyway, I am working now on the digest code, and want to make sure >> that I get the design right. >> >> 1. BCUtilDigest is fed a BCSequence and enzyme information and does >> the digest either by an external trigger or internally. >> >> 2. It returns an NSArray of BCFragment objects which are wrappers >> conatining all info: the sequence, the original location, the enzyme. > > Exactly the plan! > Can you post the headers for the BCScanner, so I know how to use that class. thanks, - Koen. From mek at mekentosj.com Sat Sep 11 19:14:02 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 12 Sep 2004 01:14:02 +0200 Subject: [Biococoa-dev] the decorator pattern In-Reply-To: <192BA222-0448-11D9-B135-003065A5FDCC@earthlink.net> References: <4331AD09-03C2-11D9-819B-000393CFDE0C@mekentosj.com> <72EB0298-042A-11D9-B135-003065A5FDCC@earthlink.net> <4E616399-042D-11D9-97D4-000393CFDE0C@mekentosj.com> <192BA222-0448-11D9-B135-003065A5FDCC@earthlink.net> Message-ID: <44BEC4C1-0448-11D9-97D4-000393CFDE0C@mekentosj.com> I'll post them to you personally as attaching them to the list would hold up my email anyway. In addition, the should be in the repository not to long from now. At least, if I can find a freakin' way to update the whole thing at once.... They're underway Koen... Alex Op 12-sep-04 om 1:12 heeft Koen van der Drift het volgende geschreven: > > On Sep 11, 2004, at 4:01 PM, Alexander Griekspoor wrote: > >>> Anyway, I am working now on the digest code, and want to make sure >>> that I get the design right. >>> >>> 1. BCUtilDigest is fed a BCSequence and enzyme information and does >>> the digest either by an external trigger or internally. >>> >>> 2. It returns an NSArray of BCFragment objects which are wrappers >>> conatining all info: the sequence, the original location, the >>> enzyme. >> >> Exactly the plan! >> > > Can you post the headers for the BCScanner, so I know how to use that > class. > > thanks, > > - 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 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 a.griekspoor at nki.nl Sat Sep 11 20:11:23 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Sun, 12 Sep 2004 02:11:23 +0200 Subject: [Biococoa-dev] Halfway Message-ID: <47F307B8-0450-11D9-97D4-000393CFDE0C@nki.nl> Ok guys, I think I have done most work on the CVS level, although I now fully understand why people are advocating Subversion so much lately. Let's hope BioInformatics.org makes that shift quickly as well. Anyway, it's far from ready, so please DO NOT check out or update the current version. Tomorrow I'll fix all links in the project file, and hopefully we're back in business then again... 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 LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From a.griekspoor at nki.nl Sun Sep 12 10:55:10 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Sun, 12 Sep 2004 16:55:10 +0200 Subject: [BioCocoa-dev] NEW VERSION Message-ID: Hooray! I managed to get all restructuring work done. ******************************* ******************************* ******************************* WARNING - We all have to do a fresh checkout from the CVS before continuing ******************************* ******************************* ******************************* Also, before you all start to launch the terminal, use the following command to checkout: cvs checkout -P BioCocoa The -P or Prune command tells CVS not to download empty directories. Because of the way CVS works, one cannot delete directories from the CVS repository anymore once they have been created. That means that there are some remnant folders there (like BCSequence in the root) that you will download when you use the checkout command without the -P argument. If you have code that hasn't been checked in (Koen's work with the BCDigest for instance, then checkout the new version as stated above and copy paste the code from your old project in the newly downloaded one. After that continue to use the new one and commit the changes to the repository from there. As said, I have made many small but also larger enhancements to the framework, here are the ones I can still remember: - restructuring of file/folder hierarchy to represent the object tree. - prepared for having a foundation and appkit part (appkit folder is empty so won't be checked out, but is already on server). - renamed/-ordered targets - added a global header and global defines that can be used in demo's/apps (see translation demo controller) - added BCTools directory for things as digesters, translators, sequence property calculators (like MW, PI etc) - added BCGeneticCode to harbor BCCodon / BCGeneticCode - added BCSequenceIO to harbor the forthcoming IO classes - moved all imports whereever possible to .m files instead of .h (except for defines) - added files for BCScanner / BCSymbolSet (implementations forthcoming though) - synchronized copyright notices - reorganized/renamed template plists - renamed BCUtils/BCTools Both the framework and the example app should build perfectly fine (except for 23 warnings because of the empty scanner implementation). Please have a look at the changes, all comments are welcome! One remark, if you want to add a new file, it is best to first create it in the finder (by copying an existing one), drag it to the folder and rename it the way you want. Than add it to the xcode project, and put it in the right group there as well. Now you can add the file to the repository and commit the updated xcode project in addition. I hope to add the implementations soon for the missing files. Cheerio! Alex Ps. One current bug, somehow the translation demo app shows it's name in the menubar in chinese on my system ;-) ********************************************************* ** 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 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 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 Sun Sep 12 11:43:06 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 12 Sep 2004 11:43:06 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: Message-ID: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> On Sep 12, 2004, at 10:55 AM, Alexander Griekspoor wrote: > Please have a look at the changes, all comments are welcome! Very, very nice work Alex! Maybe your girlfriend should go out of town more often ;-) One question, is this contruction now needed: #import "../BCSymbol/BCNucleotideDNA.h" to import headers? > > One remark, if you want to add a new file, it is best to first create > it in the finder (by copying an existing one), drag it to the folder > and rename it the way you want. Than add it to the xcode project, and > put it in the right group there as well. Now you can add the file to > the repository and commit the updated xcode project in addition. Why not use the 'Add File...' option within Xcode? > > Ps. One current bug, somehow the translation demo app shows it's name > in the menubar in chinese on my system ;-) > LOL - same here. I will look into that. BTW, maybe all the demo projects should have the nice BC icon thats now used in the SequenceConverter app. I am also working on a shell script that automatically updates the deocumentation, I will make it go into the (tadaa) Documentation folder that you added. thanks again Alex! - Koen. From a.griekspoor at nki.nl Sun Sep 12 15:12:07 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Sun, 12 Sep 2004 21:12:07 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> Message-ID: >> Please have a look at the changes, all comments are welcome! > > Very, very nice work Alex! Maybe your girlfriend should go out of town > more often ;-) I'll tell her that ;-) > One question, is this contruction now needed: > > #import "../BCSymbol/BCNucleotideDNA.h" > > to import headers? Yes, if the header is in a different subfolder physically. thus: BCSequence -> BCSequenceDNA BCSymbol -> BCNucleotideDNA Then if in BCSequence.h you want to link to BCNucleotideDNA.h, you would get the above in the .m file Please don't link in the .h file wherever possible. Use the @class BCSequence, BCSymbol; expressions to satisfy the compiler, all linking should be done in the m file. Two exceptions, when you want to link to the superclass (BCSequence.h for instance for BCSequenceDNA) and if you need the enums defined in BCFoundationDefines (see the masscalculator's header as an example). >> One remark, if you want to add a new file, it is best to first create >> it in the finder (by copying an existing one), drag it to the folder >> and rename it the way you want. Than add it to the xcode project, and >> put it in the right group there as well. Now you can add the file to >> the repository and commit the updated xcode project in addition. > > Why not use the 'Add File...' option within Xcode? That would be perfectly fine as well, as long as you make sure you create the file in the proper subdirectory. I didn't think of that. >> Ps. One current bug, somehow the translation demo app shows it's name >> in the menubar in chinese on my system ;-) > > LOL - same here. I will look into that. BTW, maybe all the demo > projects should have the nice BC icon thats now used in the > SequenceConverter app. That would be nice indeed. No offense to Peter's work, but I'll see if I can come up with a more general mascotte/icon for the framework. If anyone has a suggestion, send it in! > I am also working on a shell script that automatically updates the > deocumentation, I will make it go into the (tadaa) Documentation > folder that you added. Great, I already thought of doing that, but I decided to skip that for later, great to see you are doing that already. Now we only have to document all the code properly ;-) Seems John is the best pupil of the class in that respect. > > thanks again Alex! You're welcome, again it was about time that I showed some real input from my side.... 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 ********************************************************* ********************************************************* ** 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 Mac vs Windows 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From kvddrift at earthlink.net Sun Sep 12 15:39:42 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 12 Sep 2004 15:39:42 -0400 Subject: [Biococoa-dev] BCSymbolSet Message-ID: <7E21BB9C-04F3-11D9-890A-003065A5FDCC@earthlink.net> Hoi Alex, Do we really need a BCSymbolSet? NSMutableSet already allows adding of objects: - (void)addObject:(id)anObject I use this for an NSCountedSet, and it works very well. cheers, - Koen. From kvddrift at earthlink.net Sun Sep 12 15:42:53 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 12 Sep 2004 15:42:53 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> Message-ID: On Sep 12, 2004, at 3:12 PM, Alexander Griekspoor wrote: >> I am also working on a shell script that automatically updates the >> deocumentation, I will make it go into the (tadaa) Documentation >> folder that you added. > Great, I already thought of doing that, but I decided to skip that for > later, great to see you are doing that already. It's now in CVS. The results end up in a Documentation folder at the root BioCocoa level, but not in the same folder in the project. - Koen. From mek at mekentosj.com Sun Sep 12 16:00:52 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 12 Sep 2004 22:00:52 +0200 Subject: [Biococoa-dev] Re: BCSymbolSet In-Reply-To: <7E21BB9C-04F3-11D9-890A-003065A5FDCC@earthlink.net> References: <7E21BB9C-04F3-11D9-890A-003065A5FDCC@earthlink.net> Message-ID: <72F1EA3D-04F6-11D9-BD78-000393CFDE0C@mekentosj.com> Ha Koen, I like the idea of having such a set, especially to have the class methods to get the predefined set. But you did save me a lot of work as indeed I can simply make BCSymbolSet a subclass of BCMutableSet (not NSCountedSet because you want only a single instance of a symbol in the set at max). But most methods are there already in the BCMutableSet, so that will be simple. I had it based on an array, but the documentation says "use sets as an alternative to arrays when the order of elements isn?t important and performance in testing whether an object is contained in the set is a consideration. While arrays are ordered, testing them for membership is slower than testing sets.", so in general a great idea Koen! Thanks! Alex Op 12-sep-04 om 21:39 heeft Koen van der Drift het volgende geschreven: > Hoi Alex, > > Do we really need a BCSymbolSet? NSMutableSet already allows adding of > objects: > > - (void)addObject:(id)anObject > > > I use this for an NSCountedSet, and it works very well. > > > > cheers, > > - 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 Mac vs Windows 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From a.griekspoor at nki.nl Sun Sep 12 16:12:25 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Sun, 12 Sep 2004 22:12:25 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> Message-ID: <1066790C-04F8-11D9-BD78-000393CFDE0C@nki.nl> Koen, running the script takes ages, does it take so long to build the docs? It runs for a couple of minutes already... Second, have you tried clicking the "Run only when installing" option, then it won't run every time you do a development build... Alex Op 12-sep-04 om 21:42 heeft Koen van der Drift het volgende geschreven: > > On Sep 12, 2004, at 3:12 PM, Alexander Griekspoor wrote: > >>> I am also working on a shell script that automatically updates the >>> deocumentation, I will make it go into the (tadaa) Documentation >>> folder that you added. >> Great, I already thought of doing that, but I decided to skip that >> for later, great to see you are doing that already. > > > It's now in CVS. The results end up in a Documentation folder at the > root BioCocoa level, but not in the same folder in the project. > > > - 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 kvddrift at earthlink.net Sun Sep 12 16:30:47 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 12 Sep 2004 16:30:47 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: <1066790C-04F8-11D9-BD78-000393CFDE0C@nki.nl> References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> <1066790C-04F8-11D9-BD78-000393CFDE0C@nki.nl> Message-ID: On Sep 12, 2004, at 4:12 PM, Alexander Griekspoor wrote: > Koen, running the script takes ages, does it take so long to build the > docs? It runs for a couple of minutes already... > Second, have you tried clicking the "Run only when installing" option, > then it won't run every time you do a development build... > Just a few seconds here. You could try to run the script from the terminal to see what's going on. Put this is a text file, name it hd and store it at the rrot level of BioCocoa.Then cd to that folder in the terminal, and type ./hd at the prompt. #! /bin/bash mkdir -p Documentation headerdoc2html -o Documentation BCFoundation gatherheaderdoc Documentation And that box is indeed off, so I will check it. - Koen. From a.griekspoor at nki.nl Sun Sep 12 16:45:18 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Sun, 12 Sep 2004 22:45:18 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> <1066790C-04F8-11D9-BD78-000393CFDE0C@nki.nl> Message-ID: > > Just a few seconds here. You could try to run the script from the > terminal to see what's going on. Put this is a text file, name it hd > and store it at the rrot level of BioCocoa.Then cd to that folder in > the terminal, and type ./hd at the prompt. > > #! /bin/bash > > mkdir -p Documentation > > headerdoc2html -o Documentation BCFoundation > gatherheaderdoc Documentation Somehow that doesn't work. But subsequently running the two commands in the terminal shows that the first (creating the docs) is blazing fast, but the second takes ages "finding files". Well if this is only done on deployment that's fine with me, but it's strange isn't it? Also, strangely when I build the BioCocoa target it now launches the sequence converter app when it finishes. How's that happening? 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 Sun Sep 12 19:41:20 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 12 Sep 2004 19:41:20 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> <1066790C-04F8-11D9-BD78-000393CFDE0C@nki.nl> Message-ID: <3F7839EF-0515-11D9-A0F5-003065A5FDCC@earthlink.net> On Sep 12, 2004, at 4:45 PM, Alexander Griekspoor wrote: > > Somehow that doesn't work. But subsequently running the two commands > in the terminal shows that the first (creating the docs) is blazing > fast, but the second takes ages "finding files". Well if this is only > done on deployment that's fine with me, but it's strange isn't it? Are you sure the headerdoc2html command worked? You should see the output in the terminal, and the results in BioCocoa/Documentation. Maybe if it didn't create anyfiles, gatherheaderdoc keeps looking for files, what you describe. > Also, strangely when I build the BioCocoa target it now launches the > sequence converter app when it finishes. How's that happening? To add the headerdoc script, I updated the files koen.pbxuser and project.pbxproj from the CLI. Maybe something went wrong there? BTW, is there a way to that from Xcode directly? If I select just the top file in the project, then everything that I am working gets commited, not just the pbproj files. - Koen. From kvddrift at earthlink.net Sun Sep 12 20:37:38 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 12 Sep 2004 20:37:38 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: Message-ID: <1D029AF4-051D-11D9-A0F5-003065A5FDCC@earthlink.net> On Sep 12, 2004, at 10:55 AM, Alexander Griekspoor wrote: > Ps. One current bug, somehow the translation demo app shows it's name > in the menubar in chinese on my system ;-) > Always problems with Chinese Menu ;-) Anyway, that should hopefully be fixed in CVS now. - Koen. From kvddrift at earthlink.net Sun Sep 12 20:38:11 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 12 Sep 2004 20:38:11 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> Message-ID: <30FC361E-051D-11D9-A0F5-003065A5FDCC@earthlink.net> On Sep 12, 2004, at 3:12 PM, Alexander Griekspoor wrote: > No offense to Peter's work, but I'll see if I can come up with a more > general mascotte/icon for the framework. If anyone has a suggestion, > send it in! > Actually, I like the current one a lot. - Koen. From a.griekspoor at nki.nl Mon Sep 13 02:26:57 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Mon, 13 Sep 2004 08:26:57 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: <3F7839EF-0515-11D9-A0F5-003065A5FDCC@earthlink.net> References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> <1066790C-04F8-11D9-BD78-000393CFDE0C@nki.nl> <3F7839EF-0515-11D9-A0F5-003065A5FDCC@earthlink.net> Message-ID: >> Somehow that doesn't work. But subsequently running the two commands >> in the terminal shows that the first (creating the docs) is blazing >> fast, but the second takes ages "finding files". Well if this is only >> done on deployment that's fine with me, but it's strange isn't it? > > > Are you sure the headerdoc2html command worked? You should see the > output in the terminal, and the results in BioCocoa/Documentation. > Maybe if it didn't create anyfiles, gatherheaderdoc keeps looking for > files, what you describe. It creates the files, successfully finishes within a second and I have checked that they indeed exist and look ok.... > > > >> Also, strangely when I build the BioCocoa target it now launches the >> sequence converter app when it finishes. How's that happening? > > > To add the headerdoc script, I updated the files koen.pbxuser and > project.pbxproj from the CLI. Maybe something went wrong there? BTW, > is there a way to that from Xcode directly? I do everything from within XCode, except for nib files for which somehow XCode doesn't see that they have been updated. But for the rest XCode is your friend. Select SCM from the SCM menu, which brings up a pane that shows all files that have been edited. Also, it shows a log of the console. You can select the files to add and select add to repository from the SCM menu, or Commit if you want to commit your edits. Although files edited by others show up as well, and you can select update to latest. > If I select just the top file in the project, then everything that I > am working gets commited, not just the pbproj files. After updating from within XCode, the script showed up in the target so I guess it worked. But for some strange reason the sequence converter app still launches when the framework is build, that wasn't so before. 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 ********************************************************* ********************************************************* ** 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 Mon Sep 13 02:29:01 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Mon, 13 Sep 2004 08:29:01 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: <30FC361E-051D-11D9-A0F5-003065A5FDCC@earthlink.net> References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> <30FC361E-051D-11D9-A0F5-003065A5FDCC@earthlink.net> Message-ID: <33CC352C-054E-11D9-BD78-000393CFDE0C@nki.nl> > >> No offense to Peter's work, but I'll see if I can come up with a >> more general mascotte/icon for the framework. If anyone has a >> suggestion, send it in! >> > > Actually, I like the current one a lot. Me too, but it represents an application so is perfectly suitable for the demo-apps, but it doesn't represent a framework. Not that it irritates me, absolutely not. 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 LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From kvddrift at earthlink.net Sun Sep 19 21:15:37 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 19 Sep 2004 21:15:37 -0400 Subject: [Biococoa-dev] [BioCocoa] Alignments In-Reply-To: References: Message-ID: <94713BC2-0AA2-11D9-947E-003065A5FDCC@earthlink.net> On Sep 7, 2004, at 1:44 AM, Alexander Griekspoor wrote: > This is more a newsflash, but perhaps nice to let you guys know is > that I've spoken to Serge Cohen, a French programmer here in the > institute and have asked him if he could help us look at implementing > alignments. He's a mac enthusiast as well, and works on a program for > automatic modeling of Xray structures. He also wrote some stuff for > organizing and parsing pubmed entries, so perhaps he has some more > things he can help us with. Lucky for us, he absolutely wants to > contribute with the alignment algorithms, something I don't really > have a lot of experience with at least. Very nice is that he has quite > some experience with altivec enhancements as well, would be nice to > have altivec enabled alignments ;-) > I'll introduce him to the framework once the core is more or less > stable... > That's great news - have you discussed with him our current layout/design of the framework? It seems he is a very experienced programmer, so maybe he spots some flaws that we can correct in the early development stage. Also, check out: http://www.bioalgorithms.info/ Very useful information. - Koen. From jtimmer at bellatlantic.net Tue Sep 21 15:05:24 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 21 Sep 2004 15:05:24 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> Message-ID: I'm back! Very nice work on cleaning up the CVS repository. I think I just made a mess of things again ;). I went through and added/updated files to the current versions I worked on while I was on vacation, but I haven't had a chance to update to the new import setup, and I think I overwrote some of the cleaned up versions. When I'm at home tonight, I will go through and carefully compare versions and get things cleaned up. In the mean time, I'd imagine I broke some stuff - my apologies. Incidentally, all translation is now handled nicely through BCSequenceCodon, so the only difficult step is creating a codon sequence from a DNA sequence. I hope to have that done over the weekend. Cheers, John _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Sep 21 15:31:04 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 21 Sep 2004 21:31:04 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: Message-ID: grrr. some people just don't read the lines even if you make them bold, size 24pts.... ok, try to fix the stuff, and for gods sake take a good look at the new folder hierarchy both in the CVS and the XCode project! And again folks as we have some spare folders around, use the prune option when doing a fresh checkout. I'll send you a zip file containing the project as it should be before you checked in for comparison. Great to hear of the BCSequenceCodon stuff now being fully functional! From my side I have good and bad news as well, our website that I have been working on for many weeks already is nearing completion, and I hope to finish it this weekend, after which I will focus on BioCocoa more. Unfortunately, that means that the empty BCSymbolSet and BCScanner will stay empty for another week or so. But it's first on the list. OK, to prevent these things from happening in the future, let us all first finish reading the emails that have been sent to the mailinglist after returning from a break-away period before committing any personal changes made in the meantime. Cheers, Alex Op 21-sep-04 om 21:05 heeft John Timmer het volgende geschreven: > I'm back! > > Very nice work on cleaning up the CVS repository. I think I just made > a mess > of things again ;). I went through and added/updated files to the > current > versions I worked on while I was on vacation, but I haven't had a > chance to > update to the new import setup, and I think I overwrote some of the > cleaned > up versions. > > When I'm at home tonight, I will go through and carefully compare > versions > and get things cleaned up. In the mean time, I'd imagine I broke some > stuff > - my apologies. > > Incidentally, all translation is now handled nicely through > BCSequenceCodon, > so the only difficult step is creating a codon sequence from a DNA > sequence. > I hope to have that done over the weekend. > > Cheers, > > John > > _______________________________________________ > 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 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 a.griekspoor at nki.nl Tue Sep 21 15:38:34 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Tue, 21 Sep 2004 21:38:34 +0200 Subject: [Biococoa-dev] Fusion problems Message-ID: John, I just did a fresh checkout, but at least the CVS folder hierarchy has not changed at all, so I guess it's only a matter of checking if all file changes are still there, but if CVS did a good job, things must have fused correctly right. Chances are not big that you have undone the things I changed while editing your files. Anyway, you will discover soon enough... 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 Mac vs Windows 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From jtimmer at bellatlantic.net Tue Sep 21 15:44:26 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 21 Sep 2004 15:44:26 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: Message-ID: Alex - Calm down, it's not so bad (mostly because I did read the emails). I didn't add files in any places they shouldn't. I simply over-wrote the new #import statements. They still exist in the previous revision, and getting them back is as simple as comparing the current and previous versions in FileMerge and carefully choosing the two versions. I finished up about three classes while waiting on hold. I'll be done in a half hour or so. You should see how much code I added - it's well worth a momentary hiccup. John > grrr. some people just don't read the lines even if you make them bold, > size 24pts.... > ok, try to fix the stuff, and for gods sake take a good look at the new > folder hierarchy both in the CVS and the XCode project! > And again folks as we have some spare folders around, use the prune > option when doing a fresh checkout. > I'll send you a zip file containing the project as it should be before > you checked in for comparison. > Great to hear of the BCSequenceCodon stuff now being fully functional! > > From my side I have good and bad news as well, our website that I have > been working on for many weeks already is nearing completion, and I > hope to finish it this weekend, after which I will focus on BioCocoa > more. Unfortunately, that means that the empty BCSymbolSet and > BCScanner will stay empty for another week or so. But it's first on the > list. > > OK, to prevent these things from happening in the future, let us all > first finish reading the emails that have been sent to the mailinglist > after returning from a break-away period before committing any personal > changes made in the meantime. _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Sep 21 16:11:33 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 21 Sep 2004 22:11:33 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: Message-ID: <6EF7C4E5-0C0A-11D9-B0BD-000393CFDE0C@mekentosj.com> > You should see how much code I added - it's well worth a momentary > hiccup. There was not a doubt in my mind that thought otherwise John! I only thought the damage was worse because of the way you described it, sorry for being so picky.... Having messed around with CVS doesn't make you particularly happy after a few hours ;-) Keep up the good work! Alex Op 21-sep-04 om 21:44 heeft John Timmer het volgende geschreven: > Alex - > > Calm down, it's not so bad (mostly because I did read the emails). I > didn't > add files in any places they shouldn't. I simply over-wrote the new > #import > statements. They still exist in the previous revision, and getting > them > back is as simple as comparing the current and previous versions in > FileMerge and carefully choosing the two versions. I finished up about > three classes while waiting on hold. I'll be done in a half hour or > so. > > > John > > > >> grrr. some people just don't read the lines even if you make them >> bold, >> size 24pts.... >> ok, try to fix the stuff, and for gods sake take a good look at the >> new >> folder hierarchy both in the CVS and the XCode project! >> And again folks as we have some spare folders around, use the prune >> option when doing a fresh checkout. >> I'll send you a zip file containing the project as it should be before >> you checked in for comparison. >> Great to hear of the BCSequenceCodon stuff now being fully functional! >> >> From my side I have good and bad news as well, our website that I >> have >> been working on for many weeks already is nearing completion, and I >> hope to finish it this weekend, after which I will focus on BioCocoa >> more. Unfortunately, that means that the empty BCSymbolSet and >> BCScanner will stay empty for another week or so. But it's first on >> the >> list. >> >> OK, to prevent these things from happening in the future, let us all >> first finish reading the emails that have been sent to the mailinglist >> after returning from a break-away period before committing any >> personal >> changes made in the meantime. > > > _______________________________________________ > 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 Mac vs Windows 65 million years ago, there were more dinosaurs than humans. Where are the dinosaurs now? ********************************************************* From jtimmer at bellatlantic.net Tue Sep 21 16:40:56 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 21 Sep 2004 16:40:56 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: <6EF7C4E5-0C0A-11D9-B0BD-000393CFDE0C@mekentosj.com> Message-ID: Because of the momentary panic my careless wording caused, I took a break from real work and fixed as much as I could. Things now build with just a few warnings. I've tried as best as possible to adhere to the new setup, but I'm sure there's a couple of spots where I missed something. If it's simple, please fix it and if it's not, please tell me so that I can. One thing that probably doesn't work right now is the translation method for converting a DNA/RNA sequence to a codon sequence. I should have that fixed later tonight. I'll look over the new structure of the build and fix the bundle issues as soon as I can. John _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Sep 21 16:52:58 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 21 Sep 2004 22:52:58 +0200 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: Message-ID: <37D8A91C-0C10-11D9-B0BD-000393CFDE0C@mekentosj.com> Thanks John! As you say, the panic was bigger than the actual problems, I'll have a check later, but I guess you fixed most if not all already... Let us celebrate by throwing in a thought I got while attending an, otherwise very boring, bioinformatics talk yesterday. These people had used opensource software to integrate a lot of data in a database based on the BioSQL schema. Although, my knowledge is limited in this area -John you have much more experience with databases isn't it? - I thought it might be nice to keep this setup in mind for our "general, xml based" file format we want to setup. The BioSQL project already is a shared initiative of all Open-bio projects, and located at: http://obda.open-bio.org/ If you go to the webcvs and download the tarball, it contains an overview pdf and documentation (although limited and no real examples). It might help us setup things like annotations and features as well. Perhaps nice to keep in the back of our heads... Cheers, Alex Op 21-sep-04 om 22:40 heeft John Timmer het volgende geschreven: > Because of the momentary panic my careless wording caused, I took a > break > from real work and fixed as much as I could. Things now build with > just a > few warnings. I've tried as best as possible to adhere to the new > setup, > but I'm sure there's a couple of spots where I missed something. If > it's > simple, please fix it and if it's not, please tell me so that I can. > > One thing that probably doesn't work right now is the translation > method for > converting a DNA/RNA sequence to a codon sequence. I should have that > fixed > later tonight. > > I'll look over the new structure of the build and fix the bundle > issues as > soon as I can. > > John > > > _______________________________________________ > 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 LabAssistant - Get your life organized! http://www.mekentosj.com/labassistant ********************************************************* From kvddrift at earthlink.net Tue Sep 21 17:51:49 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 21 Sep 2004 17:51:49 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: <70E73996-04D2-11D9-890A-003065A5FDCC@earthlink.net> <1066790C-04F8-11D9-BD78-000393CFDE0C@nki.nl> <3F7839EF-0515-11D9-A0F5-003065A5FDCC@earthlink.net> Message-ID: <70B8423E-0C18-11D9-81A1-003065A5FDCC@earthlink.net> John, Is this working for you? - Koen. On Sep 13, 2004, at 2:26 AM, Alexander Griekspoor wrote: >>> Somehow that doesn't work. But subsequently running the two commands >>> in the terminal shows that the first (creating the docs) is blazing >>> fast, but the second takes ages "finding files". Well if this is >>> only done on deployment that's fine with me, but it's strange isn't >>> it? >> >> >> Are you sure the headerdoc2html command worked? You should see the >> output in the terminal, and the results in BioCocoa/Documentation. >> Maybe if it didn't create anyfiles, gatherheaderdoc keeps looking for >> files, what you describe. > > It creates the files, successfully finishes within a second and I have > checked that they indeed exist and look ok.... >> >> >> >>> Also, strangely when I build the BioCocoa target it now launches the >>> sequence converter app when it finishes. How's that happening? >> >> >> To add the headerdoc script, I updated the files koen.pbxuser and >> project.pbxproj from the CLI. Maybe something went wrong there? BTW, >> is there a way to that from Xcode directly? > > I do everything from within XCode, except for nib files for which > somehow XCode doesn't see that they have been updated. But for the > rest XCode is your friend. Select SCM from the SCM menu, which brings > up a pane that shows all files that have been edited. Also, it shows a > log of the console. You can select the files to add and select add to > repository from the SCM menu, or Commit if you want to commit your > edits. Although files edited by others show up as well, and you can > select update to latest. > > >> If I select just the top file in the project, then everything that I >> am working gets commited, not just the pbproj files. > After updating from within XCode, the script showed up in the target > so I guess it worked. But for some strange reason the sequence > converter app still launches when the framework is build, that wasn't > so before. > > 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 > > ********************************************************* > > > ********************************************************* > ** 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 > From kvddrift at earthlink.net Tue Sep 21 18:48:49 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 21 Sep 2004 18:48:49 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: Message-ID: <676384FD-0C20-11D9-81A1-003065A5FDCC@earthlink.net> On Sep 21, 2004, at 4:40 PM, John Timmer wrote: > Because of the momentary panic my careless wording caused, I took a > break > from real work and fixed as much as I could. Things now build with > just a > few warnings. I've tried as best as possible to adhere to the new > setup, > but I'm sure there's a couple of spots where I missed something. If > it's > simple, please fix it and if it's not, please tell me so that I can. John, I don't see the BCSequenceCodon that you added so something must still be wrong. Please make sure you also update the pbproj file so BioCocoa knows about new additions. - Koen. From jtimmer at bellatlantic.net Tue Sep 21 20:17:19 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 21 Sep 2004 20:17:19 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: <676384FD-0C20-11D9-81A1-003065A5FDCC@earthlink.net> Message-ID: It was working on my machine, so to make sure it's okay I just did a clean checkout, and it seems to be there. Building indicates that it generates 37K worth of code, so as far as I can tell, everything's okay. I'm not sure what the problem is - you have any better luck since the mail? John > >> Because of the momentary panic my careless wording caused, I took a >> break >> from real work and fixed as much as I could. Things now build with >> just a >> few warnings. I've tried as best as possible to adhere to the new >> setup, >> but I'm sure there's a couple of spots where I missed something. If >> it's >> simple, please fix it and if it's not, please tell me so that I can. > > > John, I don't see the BCSequenceCodon that you added so something must > still be wrong. > > Please make sure you also update the pbproj file so BioCocoa knows > about new additions. > > > - 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 Tue Sep 21 20:54:46 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 21 Sep 2004 20:54:46 -0400 Subject: [BioCocoa-dev] NEW VERSION In-Reply-To: References: Message-ID: On Sep 21, 2004, at 8:17 PM, John Timmer wrote: > It was working on my machine, so to make sure it's okay I just did a > clean > checkout, and it seems to be there. Building indicates that it > generates > 37K worth of code, so as far as I can tell, everything's okay. I'm > not sure > what the problem is - you have any better luck since the mail? > Yep, now they're there. Strange. I do get some warnings, though: BCToolTranslatorDNA.m:43: `BCCodon' may not respond to `-matchesTriplet:' BCToolTranslatorDNA.m:43: cannot find method `-matchesTriplet:'; return type `id' assumed BCToolTranslatorDNA.m:51: `BCCodon' may not respond to `+unmatched' BCToolTranslatorDNA.m:51: cannot find method `+unmatched'; return type `id' assumed I think you can solve that by declaring these methods in BCCodon.h instead of BCCodonDNA.h and BCCodonRNA.h. If a method is declared in a class, than it is not necessary to declare it again in all it's subclasses. - Koen. From kvddrift at earthlink.net Wed Sep 22 20:22:09 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 22 Sep 2004 20:22:09 -0400 Subject: [Biococoa-dev] BCNucleotideRNA Message-ID: <9BA1ED90-0CF6-11D9-848F-003065A5FDCC@earthlink.net> John, Some comments on the class BCNucleotideRNA. - Is it necessary to duplicate all the code from BCNucleotideDNA, except for the uridine instead of thymidine? Why not have a class BCNucleotide that takes care of everything, and just have two subclasses with the small differences? - The method molecularWeight is deprecated, please don't keep adding it. We now use BCToolsMassCalculator for all MW calculations. - There is no need to use #import , for the BCFoundation classes is sufficient. - Please use the Copyright line as in the other files cheers, - Koen. From jtimmer at bellatlantic.net Wed Sep 22 20:38:04 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Wed, 22 Sep 2004 20:38:04 -0400 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: <9BA1ED90-0CF6-11D9-848F-003065A5FDCC@earthlink.net> Message-ID: > - Is it necessary to duplicate all the code from BCNucleotideDNA, > except for the uridine instead of thymidine? Why not have a class > BCNucleotide that takes care of everything, and just have two > subclasses with the small differences? That was my long-term intention. I just wanted to get things working quickly so that I could get translation and codons handled. Once I was happy with how they worked, I figured I could go back and sort out a better class structure. Even so, all the base methods have to be separate for DNA and RNA, as they need to return something different so that == works as expected, so the classes won't shrink as much as I'd have hoped. > - The method molecularWeight is deprecated, please don't keep adding > it. We now use BCToolsMassCalculator for all MW calculations. Sorry, that didn't exist when I left on vacation, and as you noticed, I simply copied the DNA file over. I'll delete it the next time I have time for some coding. > - There is no need to use #import , for the BCFoundation > classes is sufficient. Yeah, that's just what comes when you create a new class with Xcode. I tried to go back and catch all of them, but I guess I missed a few. For something like this, you should feel free to just correct it. The same things can be said for this: > - Please use the Copyright line as in the other files Cheers, John _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Thu Sep 23 04:17:56 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 23 Sep 2004 10:17:56 +0200 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: Message-ID: <12F3BB09-0D39-11D9-906E-000393CFDE0C@mekentosj.com> I'm afraid a few of these things are indeed attributable to all changes made in John's vacation. It's a pity there's not a single good log of changes from what I did, but that was impossible given the fact I had to do a complete new import to get the new folder hierarchy.. I guess we just all three have to check on regular basis what should still be changed... >> - Is it necessary to duplicate all the code from BCNucleotideDNA, >> except for the uridine instead of thymidine? uridine (uri?dine) ([umacr]r?[ibreve]-d[emacr]n)??a pyrimidine nucleoside, uracil linked by its N1 nitrogen to the C1 carbon of ribose. It is a component of ribonucleic acid, and its nucleotides participate in the biosynthesis of polysaccharides and some polysaccharide-containing compounds. Symbol U. So is it uridine or uracil ? I think uracil as we're talking about the complete nucleotide right, not only the base... That would be my daily portion of nitpicking ;-) >> Why not have a class >> BCNucleotide that takes care of everything, and just have two >> subclasses with the small differences? > That was my long-term intention. I just wanted to get things working > quickly so that I could get translation and codons handled. Once I was > happy with how they worked, I figured I could go back and sort out a > better > class structure. Even so, all the base methods have to be separate > for DNA > and RNA, as they need to return something different so that == works as > expected, so the classes won't shrink as much as I'd have hoped. That's fair. The only thing we have to keep thinking of if in that case there isn't a better alternative of doing things such that we can put more stuff in the superclass, like we did earlier for the string searching methods. But I'm not in the position to judge over that, I leave that up to you guys... 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 MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From a.griekspoor at nki.nl Thu Sep 23 04:21:30 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Thu, 23 Sep 2004 10:21:30 +0200 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: Message-ID: <9258F052-0D39-11D9-906E-000393CFDE0C@nki.nl> John, In your nucleotideRNA class, you take the nucleotides.plist and then cleverly replace everything T for U. But next, in the actual instantiating you do this: tempDict = [baseDefinitions objectForKey: @"T"]; if ( tempDict != nil && [tempDict isKindOfClass: [NSDictionary class]] ) { uridineRepresentation = [[BCNucleotideRNA alloc] initWithSymbol: 'U']; [baseDefinitions removeObjectForKey: @"T"]; } That should be [baseDefinitions objectForKey: @"U"]; then isn't it? Haven't changed it though... Alex Op 23-sep-04 om 2:38 heeft John Timmer het volgende geschreven: > > >> - Is it necessary to duplicate all the code from BCNucleotideDNA, >> except for the uridine instead of thymidine? Why not have a class >> BCNucleotide that takes care of everything, and just have two >> subclasses with the small differences? > That was my long-term intention. I just wanted to get things working > quickly so that I could get translation and codons handled. Once I was > happy with how they worked, I figured I could go back and sort out a > better > class structure. Even so, all the base methods have to be separate > for DNA > and RNA, as they need to return something different so that == works as > expected, so the classes won't shrink as much as I'd have hoped. > >> - The method molecularWeight is deprecated, please don't keep adding >> it. We now use BCToolsMassCalculator for all MW calculations. > Sorry, that didn't exist when I left on vacation, and as you noticed, I > simply copied the DNA file over. I'll delete it the next time I have > time > for some coding. > >> - There is no need to use #import , for the >> BCFoundation >> classes is sufficient. > Yeah, that's just what comes when you create a new class with Xcode. I > tried to go back and catch all of them, but I guess I missed a few. > For > something like this, you should feel free to just correct it. The same > things can be said for this: >> - Please use the Copyright line as in the other files > > > Cheers, > > John > > > _______________________________________________ > 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 Thu Sep 23 07:10:48 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Thu, 23 Sep 2004 07:10:48 -0400 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: <12F3BB09-0D39-11D9-906E-000393CFDE0C@mekentosj.com> Message-ID: > I'm afraid a few of these things are indeed attributable to all changes > made in John's vacation. It's a pity there's not a single good log of > changes from what I did, but that was impossible given the fact I had > to do a complete new import to get the new folder hierarchy.. I guess > we just all three have to check on regular basis what should still be > changed... Part of that was my over-excitement about checking in all the new code. If I worked more carefully over the course of a few days, I'm sure I could have done a better job. The downside is that things probably wouldn't have built during that time because of partial class implementations, etc. Does anyone have a preference for prioritizing these sorts of situations? Careful coding with build failure vs. a bit more sloppy with things always working? > uridine (uri?dine) ([umacr]r?[ibreve]-d[emacr]n)??a pyrimidine > nucleoside, uracil linked by its N1 nitrogen to the C1 carbon of > ribose. It is a component of ribonucleic acid, and its nucleotides > participate in the biosynthesis of polysaccharides and some > polysaccharide-containing compounds. Symbol U. > > So is it uridine or uracil ? I think uracil as we're talking about the > complete nucleotide right, not only the base... > That would be my daily portion of nitpicking ;-) Actually, your decision is right, but you misread the definition. Uridine == uracil + sugar. I tried to keep that consistent for all bases. > In your nucleotideRNA class, you take the nucleotides.plist and then > cleverly replace everything T for U. But next, in the actual > instantiating you do this: Yes, that was me being sloppy during the "oh damn, I messed up all the imports" stage, where I went back and copied a very early version of the file. I'll go fix that now..... An unrelated aside: does anyone know of an example of an ObjC class with detailed comments where headerdoc can do its magic properly? I'd love to find out what I'm doing wrong there, but can't figure out how to google for such a beast.... JT _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Thu Sep 23 07:29:14 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Thu, 23 Sep 2004 13:29:14 +0200 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: Message-ID: > Does anyone > have a preference for prioritizing these sorts of situations? Careful > coding with build failure vs. a bit more sloppy with things always > working? I would say the first, BUT that would be if I was alone because then I know exactly what is the problem and what I still have to do to make it work again. Here we are with more people and the problem is that if two people are in this situation, you start fixing things and still it doesn't work. Second, if I as a third person would like to do a lot of testing, I can't because the framework doesn't build. Thus, I guess we should only check things back in if it works again, until then just keep things for yourself until you're finished, or have something that works. Careful coding with things always working ;-) > >> uridine (uri?dine) ([umacr]r?[ibreve]-d[emacr]n)??a pyrimidine >> nucleoside, uracil linked by its N1 nitrogen to the C1 carbon of >> ribose. It is a component of ribonucleic acid, and its nucleotides >> participate in the biosynthesis of polysaccharides and some >> polysaccharide-containing compounds. Symbol U. >> >> So is it uridine or uracil ? I think uracil as we're talking about the >> complete nucleotide right, not only the base... >> That would be my daily portion of nitpicking ;-) > Actually, your decision is right, but you misread the definition. > Uridine > == uracil + sugar. I tried to keep that consistent for all bases. You're right, I see it now. These are the typical things I had to learn once, but forgot again ;-) A nucleoside (with an s) consists of a nitrogenous base covalently attached to a (ribose or deoxyribose) sugar but without the phosphate group. A nucleotide (with a t) consists of a nitrogenous base, a sugar, and a phosphate group. So, a nucleotide is a "nucleoside mono-phosphate." A nucleic acid contains a chain of nucleotides covalently linked together to form a sugar-phosphate backbone with protruding nitrogenous bases. In RNA (ribonucleic acid), the sugar groups are ribose, whereas in DNA (deoxyribonucleic acid), deoxyribose sugars are present instead of ribose. So uracil is the base, uridine is the nucleotide. It's funny to see that (like me) almost everyone mixes these things up. Much like homologous and orthologous... > An unrelated aside: does anyone know of an example of an ObjC class > with > detailed comments where headerdoc can do its magic properly? I'd love > to > find out what I'm doing wrong there, but can't figure out how to > google for > such a beast.... http://sourceforge.net/projects/agkit/ I had the example from AGRegex part of the AGKit you can download from the link above. I'm not sure if that one is 100% correct though... 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 Thu Sep 23 20:22:55 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Thu, 23 Sep 2004 20:22:55 -0400 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: Message-ID: On Sep 23, 2004, at 7:29 AM, Alexander Griekspoor wrote: > > A nucleoside (with an s) consists of a nitrogenous base covalently > attached > to a (ribose or deoxyribose) sugar but without the phosphate group. > > A nucleotide (with a t) consists of a nitrogenous base, a sugar, and a > phosphate group. So, a nucleotide is a "nucleoside mono-phosphate." In that case, should all the occurances of 'base' in the code be replaced by 'nucleotide'? Eg in isSingleBase, representedBases, etc. It's up to you guys, whatever you think is more accepted in the field. Also, when we do the MW calculation of a BCNucleotideDNA, we actually are calculating just the MW of the bases? If so, should we add the mass of a (deoxy)ribose and a phosphate to each unit? - Koen. From mek at mekentosj.com Fri Sep 24 01:46:22 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Fri, 24 Sep 2004 07:46:22 +0200 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: Message-ID: <10AD1A9E-0DED-11D9-852C-000393CFDE0C@mekentosj.com> > In that case, should all the occurances of 'base' in the code be > replaced by 'nucleotide'? Officially yes. I'm in favour of that as well, but leave it up to you, as you have created these classes. > Eg in isSingleBase, representedBases, etc. It's up to you guys, > whatever you think is more accepted in the field. Also, when we do > the MW calculation of a BCNucleotideDNA, we actually are calculating > just the MW of the bases? If so, should we add the mass of a > (deoxy)ribose and a phosphate to each unit? We should definitely calculate nucleotide masses instead of those of bases, but I have no clue if we're doing that already.... 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 Fri Sep 24 21:20:16 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Fri, 24 Sep 2004 21:20:16 -0400 (GMT-04:00) Subject: [Biococoa-dev] BCNucleotideRNA Message-ID: <29319676.1096075217289.JavaMail.root@gonzo.psp.pas.earthlink.net> -----Original Message----- From: Alexander Griekspoor Sent: Sep 24, 2004 1:46 AM To: Koen van der Drift Cc: John Timmer , BioCocoa Mailinglist Subject: Re: [Biococoa-dev] BCNucleotideRNA > In that case, should all the occurances of 'base' in the code be > replaced by 'nucleotide'? Officially yes. I'm in favour of that as well, but leave it up to you, as you have created these classes. Actually, these are John's classes, so I'll leave it up to him. > Eg in isSingleBase, representedBases, etc. It's up to you guys, > whatever you think is more accepted in the field. Also, when we do > the MW calculation of a BCNucleotideDNA, we actually are calculating > just the MW of the bases? If so, should we add the mass of a > (deoxy)ribose and a phosphate to each unit? We should definitely calculate nucleotide masses instead of those of bases, but I have no clue if we're doing that already.... I will check that this weekend, and make some changes, if needed. - Koen. From kvddrift at earthlink.net Sat Sep 25 06:45:28 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 25 Sep 2004 06:45:28 -0400 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: Message-ID: <03C90DD6-0EE0-11D9-88DF-003065A5FDCC@earthlink.net> On Sep 22, 2004, at 8:38 PM, John Timmer wrote: > > >> - Is it necessary to duplicate all the code from BCNucleotideDNA, >> except for the uridine instead of thymidine? Why not have a class >> BCNucleotide that takes care of everything, and just have two >> subclasses with the small differences? > That was my long-term intention. I just wanted to get things working > quickly so that I could get translation and codons handled. Once I was > happy with how they worked, I figured I could go back and sort out a > better > class structure. Even so, all the base methods have to be separate > for DNA > and RNA, as they need to return something different so that == works as > expected, so the classes won't shrink as much as I'd have hoped. I still think we can add a BCNucleotide class, because there are a couple of methods that are exactly the same in both classes. I had another look at BioJava to see how they solve this. Actually, they only have a Symbol class, no SymbolDNA, SymbolRNA, SymbolAminoAcid, etc. The same for Sequence, no subclassing. What they do is pass the right Alphabet (I think this is what Alex is working on in BCSymbolSet) to create a sequence, and you know you're dealing with DNA, RNA, Protein, etc. It uses a couple of more classes (Alphabet, AlphabetManager, SequenceFactory, etc), but is a very elegant solution, IMO. - Koen. From kvddrift at earthlink.net Sat Sep 25 16:35:20 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 25 Sep 2004 16:35:20 -0400 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: Message-ID: <6B2C14A7-0F32-11D9-BA32-003065A5FDCC@earthlink.net> On Sep 25, 2004, at 9:29 AM, John Timmer wrote: > Just to let you guys know, the grant I run a database for us up for > renewal, > and I've got a huge rebuild coming up over the next few days. I > probably > won't be able to do anything code-wise until the end of next week. > Good luck with the grant! > Looking up methods in an ObjC superclass is significantly slower > than having them in the object being used. I didn't know that. Is this only for ObjC, or also for other OO languages, such as C++ and Java? > > Elegant implementation != elegant use. A single class looks cleaner, > but > all the complementation/representation abilities in the bases are > extremely > useful, but make no sense applied to amino acids. That's where wrappers or decorators come in handy, like we already do for translation and mass calculation, and later for digesting and other stuff. > There's also going to be > a bunch of situations where you'd have to waste time asking what type > of > sequence something is, which I personally would find extraordinarily > inelegant ;). If you do it just once before each calculation, I don't see how much extra time that would take. Check the sequence once, then do something with 1000 symbols. You already are using a lot of type testing in your nucleotide classes, so one more test wouldn't hurt, I guess. In fact it could speed things up: if we know we are dealing with a DNA sequence (because it was created by using a strict DNA BCSymbolSet), then there is no need to test each symbol as well. > Although we can't > prevent stupidity (and I'm an occasional practitioner), I think we > should > try to design our classes to make some of these things a bit harder to > do. > Separating classes, some basic error testing, and using ID as little as > possible should help a great deal. I agree :) > In most cases, it is probably a balancing act where there's no single > right > answer, and the elegance/practicality decision will just be made by > whoever > writes the class. I'm not sure if I agree here. I think we should agree on a similar approach for all classes. That would make things more transparent not only for us, but also for users. (I guess I shouldn't have used the word 'elegant' ;-) cheers, - Koen. From kvddrift at earthlink.net Sat Sep 25 20:22:40 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 25 Sep 2004 20:22:40 -0400 Subject: [Biococoa-dev] translation demo Message-ID: <2D5CA318-0F52-11D9-BA32-003065A5FDCC@earthlink.net> Hi, Is anyone able to build the translation demo? I think it has to do with the line: #import which should be changed to something else after the recent code reorganisation. I tried #import "../BCFoundation/BCFoundation.h" But that still gives errors. thanks, - Koen. From kvddrift at earthlink.net Sat Sep 25 20:46:23 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sat, 25 Sep 2004 20:46:23 -0400 Subject: [Biococoa-dev] translation demo In-Reply-To: <2D5CA318-0F52-11D9-BA32-003065A5FDCC@earthlink.net> References: <2D5CA318-0F52-11D9-BA32-003065A5FDCC@earthlink.net> Message-ID: <7DB3E7C6-0F55-11D9-BA32-003065A5FDCC@earthlink.net> On Sep 25, 2004, at 8:22 PM, Koen van der Drift wrote: > Hi, > > Is anyone able to build the translation demo? I think it has to do > with the line: > > #import > To reply to myself, I replaced that line with: #import "../../BCFoundation/BCGeneticCode/BCCodon.h" #import "../../BCFoundation/BCSequence/BCSequenceDNA.h" #import "../../BCFoundation/BCSequence/BCSequenceProtein.h" #import "../../BCFoundation/BCTools/BCTranslation/BCToolTranslatorDNA.h" #import "../../BCFoundation/BCUtils/BCUtilStrings.h" But still get 2 warnings: theController.m:54: cannot find method `+translateDNASequence:usingGeneticCode:'; return type `id' assumed theController.m:54: `BCToolTranslatorDNA' may not respond to `+translateDNASequence:usingGeneticCode:' I don;t understand that because BCToolTranslatorDNA.h is in the lines above. If I start the app anyway, enter a sequence and click the button, I get this error: 2004-09-25 20:40:07.478 Translation[1316] Attempt to mutate immutable NSString with replaceOccurrencesOfString:withString:options:range: Which happens in BCGeneticCode.m, line 181 Although the NSString in question (aKey) is an NSMutableString, I think it points to an NSString, so maybe that's why the error occurs. Any ideas? thanks, - Koen. From mek at mekentosj.com Sun Sep 26 05:12:33 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 26 Sep 2004 11:12:33 +0200 Subject: [Biococoa-dev] translation demo In-Reply-To: <7DB3E7C6-0F55-11D9-BA32-003065A5FDCC@earthlink.net> References: <2D5CA318-0F52-11D9-BA32-003065A5FDCC@earthlink.net> <7DB3E7C6-0F55-11D9-BA32-003065A5FDCC@earthlink.net> Message-ID: <335B554B-0F9C-11D9-82F4-000393CFDE0C@mekentosj.com> Ok guys, I think I fixed most stuff, a few remarks about the changes I made: Please always use #import instead of #include, the first checks whether a header has already been included. I found one in BCNucleotideRNA, I guess John did a bit to much C programming in the meantime ;-) I experienced all the problems Koen described, and managed to pinpoint them back to the new BCCodonRNA and -DNA headers. First, most headers John added were still marked as project instead of public in the target, thus not ending up in the headers directory of the framework. The translation app couldn't see them this way. Still, changing this didn't completely fix stuff. The trick is that we now satisfy the compiler with the @class directive instead of using header imports in the .h file. In BCCodon we had already put a few, and apparently if you then put the same there again in a direct subclass this results in errors. To prevent this, just leave all @class calls away first, and only add those that the compiler starts to complain about. Anyway, the frameworks build fine again. I noticed still a few problem in BCToolTranslatorDNA. First a few compiler complaints because of the use of BCCodon while methods in BCCodonDNA were called (- matchesTriplet; + unmatched;). I fixed that one by typing to BCCodonDNA (as it is a DNA translator anyway we are specialized already anyway). Then the errors Koen described: > But still get 2 warnings: > > theController.m:54: cannot find method > `+translateDNASequence:usingGeneticCode:'; return type `id' assumed > theController.m:54: `BCToolTranslatorDNA' may not respond to > `+translateDNASequence:usingGeneticCode:' > > I don;t understand that because BCToolTranslatorDNA.h is in the lines > above. I think this one is now fixed with the @class problems > If I start the app anyway, enter a sequence and click the button, I > get this error: > > 2004-09-25 20:40:07.478 Translation[1316] Attempt to mutate immutable > NSString with replaceOccurrencesOfString:withString:options:range: > > Which happens in BCGeneticCode.m, line 181 > > Although the NSString in question (aKey) is an NSMutableString, I > think it points to an NSString, so maybe that's why the error occurs. That one is still there and happens here: + (NSMutableDictionary *) priv_createCodonArraysFromDictionary: (NSDictionary *)entry { NSMutableArray *DNAArray = [NSMutableArray array]; NSMutableArray *RNAArray = [NSMutableArray array]; NSEnumerator *keyEnumerator = [entry keyEnumerator]; NSMutableString *aKey; BCCodon *aCodon, *RNACodon; while ( aKey = [keyEnumerator nextObject] ) { aCodon = [[[BCCodonDNA alloc] initWithDNASequenceString: aKey andAminoAcidString: [entry objectForKey: aKey]] autorelease]; if ( aCodon != nil ) [DNAArray addObject: aCodon]; =====>>> [aKey replaceOccurrencesOfString: @"T" withString: @"U" options: NSCaseInsensitiveSearch range: NSMakeRange(0, 3)]; Although aKey is typed as a mutable string you probably get normal strings from the enumerator and thus you can't replace the occurences of T for U. One other little thing. John you created two "private methods" in BCGeneticCode. They are not private however as they are in the public header file. The way to do this is to create kind of a private category inside the .m file. I changed it, so take a look at BCGeneticCode.m to see what I mean. This way they are completely invisible to the developer. Of course he has the source, so if he wants to per se, he can still call it, but at least he will get some warnings ;-) Finally, the header doc shell scripts gives me troubles, and the project seemed not to have remembered the "only on installing" checkbox, anyone a clue on this one? I'll continue with the other discussion we had.... Cheers, Alex Op 26-sep-04 om 2:46 heeft Koen van der Drift het volgende geschreven: > > On Sep 25, 2004, at 8:22 PM, Koen van der Drift wrote: > >> Hi, >> >> Is anyone able to build the translation demo? I think it has to do >> with the line: >> >> #import >> > > > To reply to myself, I replaced that line with: > > #import "../../BCFoundation/BCGeneticCode/BCCodon.h" > #import "../../BCFoundation/BCSequence/BCSequenceDNA.h" > #import "../../BCFoundation/BCSequence/BCSequenceProtein.h" > #import > "../../BCFoundation/BCTools/BCTranslation/BCToolTranslatorDNA.h" > #import "../../BCFoundation/BCUtils/BCUtilStrings.h" > > But still get 2 warnings: > > theController.m:54: cannot find method > `+translateDNASequence:usingGeneticCode:'; return type `id' assumed > theController.m:54: `BCToolTranslatorDNA' may not respond to > `+translateDNASequence:usingGeneticCode:' > > I don;t understand that because BCToolTranslatorDNA.h is in the lines > above. > > > If I start the app anyway, enter a sequence and click the button, I > get this error: > > 2004-09-25 20:40:07.478 Translation[1316] Attempt to mutate immutable > NSString with replaceOccurrencesOfString:withString:options:range: > > Which happens in BCGeneticCode.m, line 181 > > Although the NSString in question (aKey) is an NSMutableString, I > think it points to an NSString, so maybe that's why the error occurs. > > > Any ideas? > > 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 Mac vs Windows 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 MacOS X: The power of UNIX with the simplicity of the Mac *************************************************************** From mek at mekentosj.com Sun Sep 26 05:38:41 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 26 Sep 2004 11:38:41 +0200 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: <6B2C14A7-0F32-11D9-BA32-003065A5FDCC@earthlink.net> References: <6B2C14A7-0F32-11D9-BA32-003065A5FDCC@earthlink.net> Message-ID: Part two ;-) First the email of Koen: >>> - Is it necessary to duplicate all the code from BCNucleotideDNA, >>> except for the uridine instead of thymidine? Why not have a class >>> BCNucleotide that takes care of everything, and just have two >>> subclasses with the small differences? >> That was my long-term intention. I just wanted to get things working >> quickly so that I could get translation and codons handled. Once I >> was >> happy with how they worked, I figured I could go back and sort out a >> better >> class structure. Even so, all the base methods have to be separate >> for DNA >> and RNA, as they need to return something different so that == works >> as >> expected, so the classes won't shrink as much as I'd have hoped. > > I still think we can add a BCNucleotide class, because there are a > couple of methods that are exactly the same in both classes. Yep, I saw that as well. For instance one of the troubles encountered was the presence of the +unmatched and -matchesTriplet calls that aren't there in BCCodon but exist in BCCodonDNA and BCCodonRNA. If we would have a general BCNucleotide class, it would completely make the BCCodonDNA and -RNA class unnecessary as all BCCodon methods could then be the same for both types of nucleotides. It makes more sense to have a BCSymbol --> BCNucleotide --> BCNucleotideDNA / BCNucleotideRNA, if that would save a lot of divergence in other classes like BCCodon and a lot of tools probably. > I had another look at BioJava to see how they solve this. Actually, > they only have a Symbol class, no SymbolDNA, SymbolRNA, > SymbolAminoAcid, etc. The same for Sequence, no subclassing. What they > do is pass the right Alphabet (I think this is what Alex is working on > in BCSymbolSet) to create a sequence, and you know you're dealing with > DNA, RNA, Protein, etc. It uses a couple of more classes (Alphabet, > AlphabetManager, SequenceFactory, etc), but is a very elegant > solution, IMO. Yes, it is. Still, that doesn't exclude that ours is not elegant as well ;-) Seriously, we have discussed this way back and I pointed to the way BioJava does things. Indeed the alphabet stuff is quite nice, but overall I like the way we have done things just as much. In fact the way we use class methods to generate shared instances, instead of factory objects is something more elegant in my opinion. I think the question is not so much whether type checking is a problem, what we should try to do is design our methods in a way it works as general as possible. The BCNucleotide discussion is a nice example. You could have two translator to codons for DNA and RNA, but with the nucleotide class, we can make a single translator for nucleotides. It's key to keep this solution in mind all the time. The BCSymbolSet is indeed a way to create Alphabets, which can come in handy during all kinds of situations, but the way we have different nucleotides has advantages as well. Somehow, I missed or didn't receive John's reply, I'm not sure if the parts Koen quotes contain the entire mail, so sorry beforehand for missing anything critical in my comments... >> Just to let you guys know, the grant I run a database for us up for >> renewal, >> and I've got a huge rebuild coming up over the next few days. I >> probably >> won't be able to do anything code-wise until the end of next week. >> > > Good luck with the grant! Let me copy that! >> Looking up methods in an ObjC superclass is significantly slower >> than having them in the object being used. > > I didn't know that. Is this only for ObjC, or also for other OO > languages, such as C++ and Java? I was curious as well, and did some searching on the web on the Objective-C runtime. I found this snippet: The method is looked up BY NAME, first in the class and then in each superclass in order. Once a successful lookup has occurred (or failed to occur) the associated function pointer (or pointer to the error function) is cached so that future invocations are fast (~ 2-3x a simple function call). So it seems you're right in principle, but given the fact that most methods we're talking about are only one superclass up, and that after the first time, the function pointer is cached, I can hardly imagine that you will see anything of this. >> Elegant implementation != elegant use. A single class looks cleaner, >> but >> all the complementation/representation abilities in the bases are >> extremely >> useful, but make no sense applied to amino acids. > > That's where wrappers or decorators come in handy, like we already do > for translation and mass calculation, and later for digesting and > other stuff. Yep. >> There's also going to be >> a bunch of situations where you'd have to waste time asking what type >> of >> sequence something is, which I personally would find extraordinarily >> inelegant ;). > > If you do it just once before each calculation, I don't see how much > extra time that would take. Check the sequence once, then do > something with 1000 symbols. You already are using a lot of type > testing in your nucleotide classes, so one more test wouldn't hurt, I > guess. In fact it could speed things up: if we know we are dealing > with a DNA sequence (because it was created by using a strict DNA > BCSymbolSet), then there is no need to test each symbol as well. This is certainly true, as said I'm not particular in favour of switching to a alphabet based system, but it would be certainly handy to have a quick and inexpensive way of knowing whether a sequence is strict as it optimizes things enormously. >> Although we can't prevent stupidity (and I'm an occasional >> practitioner), I think we should >> try to design our classes to make some of these things a bit harder >> to do. >> Separating classes, some basic error testing, and using ID as little >> as >> possible should help a great deal. > > I agree :) > >> In most cases, it is probably a balancing act where there's no single >> right >> answer, and the elegance/practicality decision will just be made by >> whoever >> writes the class. > I'm not sure if I agree here. I think we should agree on a similar > approach for all classes. That would make things more transparent not > only for us, but also for users. I definitely copy this. Consistency rules! Perhaps a lot of discussion as the result, but in the end we have to decide how to do it and do it that way for all similar situations. Also, if later on we find a better solution, we should go back and change all classes to work similar. It will be much easier to learn how things work, and for a developer to implement things, but also it is the only way in which we can together optimize things. If all implementations are different, it would be impossible to improve those made by others. 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 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 Sun Sep 26 09:44:05 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 26 Sep 2004 09:44:05 -0400 Subject: [Biococoa-dev] translation demo In-Reply-To: <335B554B-0F9C-11D9-82F4-000393CFDE0C@mekentosj.com> Message-ID: Unfortunately, the grant's not for me and isn't paying me. It's the department chairman's though, so it seems worth making some effort for ;). Just to let you guys know, I'm planning on changing the DNATranslator to a generic tool class (BCToolRibosome?) that can handle both DNA and RNA with the same method. The method's going to wind up looking very similar to the existing one, but will be more broadly applicable. Sorry about the #include - just must have gone braindead for a moment. > > That one is still there and happens here: > > + (NSMutableDictionary *) priv_createCodonArraysFromDictionary: > (NSDictionary *)entry { > NSMutableArray *DNAArray = [NSMutableArray array]; > NSMutableArray *RNAArray = [NSMutableArray array]; > NSEnumerator *keyEnumerator = [entry keyEnumerator]; > NSMutableString *aKey; > BCCodon *aCodon, *RNACodon; > while ( aKey = [keyEnumerator nextObject] ) { > aCodon = [[[BCCodonDNA alloc] initWithDNASequenceString: aKey > andAminoAcidString: [entry objectForKey: aKey]] autorelease]; > if ( aCodon != nil ) > [DNAArray addObject: aCodon]; > =====>>> [aKey replaceOccurrencesOfString: @"T" withString: @"U" > options: NSCaseInsensitiveSearch range: NSMakeRange(0, 3)]; > > Although aKey is typed as a mutable string you probably get normal > strings from the enumerator and thus you can't replace the occurences > of T for U. Right, I'll fix that to make a mutable copy. > One other little thing. John you created two "private methods" in > BCGeneticCode. They are not private however as they are in the public > header file. The way to do this is to create kind of a private category > inside the .m file. I changed it, so take a look at BCGeneticCode.m to > see what I mean. This way they are completely invisible to the > developer. Of course he has the source, so if he wants to per se, he > can still call it, but at least he will get some warnings ;-) Thanks, I'll look it over - that's something I'm not savvy with, so this will be educational for me. Cheers, John _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Sun Sep 26 09:55:13 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 26 Sep 2004 09:55:13 -0400 Subject: [Biococoa-dev] translation demo In-Reply-To: <335B554B-0F9C-11D9-82F4-000393CFDE0C@mekentosj.com> Message-ID: > Ok guys, I think I fixed most stuff, a few remarks about the changes I > made: > Okay, the BCGeneticCode bug should be fixed. So much for focusing on PHP for the weekend.... One aside related to the superclass lookup issue: I think we should keep in mind that a lot of what people are going to be using the framework for is with very long arrays of symbols (ie - sequences). Given that, anything we can do to speed up something done within our BCSymbols is likely to have a very significant impact on general usage. Initialization activities are always going to be slow, but we should try to optimize everything else as much as reasonably possible. I guess the symbols are singletons, so caching superclass method addresses is going to be very effective in this example. Even so, I hate situations where something is slow the first time, then much faster after that.... Cheers, JT _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Sun Sep 26 09:57:11 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 26 Sep 2004 15:57:11 +0200 Subject: [Biococoa-dev] translation demo In-Reply-To: References: Message-ID: > Just to let you guys know, I'm planning on changing the DNATranslator > to a > generic tool class (BCToolRibosome?) that can handle both DNA and RNA > with > the same method. The method's going to wind up looking very similar > to the > existing one, but will be more broadly applicable. Nice! I would prefer BCToolTranslator though... Will that replace the DNATranslator or come in addition? 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 ********************************************************* From kvddrift at earthlink.net Sun Sep 26 11:08:28 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 26 Sep 2004 11:08:28 -0400 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: <12F3BB09-0D39-11D9-906E-000393CFDE0C@mekentosj.com> References: <12F3BB09-0D39-11D9-906E-000393CFDE0C@mekentosj.com> Message-ID: On Sep 23, 2004, at 4:17 AM, Alexander Griekspoor wrote: > I'm afraid a few of these things are indeed attributable to all > changes made in John's vacation. It's a pity there's not a single good > log of changes from what I did, but that was impossible given the fact > I had to do a complete new import to get the new folder hierarchy.. I > guess we just all three have to check on regular basis what should > still be changed... I know of several cvs based projects (bioperl, fink, etc) that send out emails when something gets commited to cvs. I will check the Bioinformatics.org website to see if that can be done for use too. - Koen. From kvddrift at earthlink.net Sun Sep 26 11:27:52 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 26 Sep 2004 11:27:52 -0400 Subject: [Biococoa-dev] translation demo In-Reply-To: References: Message-ID: On Sep 26, 2004, at 9:55 AM, John Timmer wrote: > Okay, the BCGeneticCode bug should be fixed. So much for focusing on > PHP > for the weekend.... > The example still doesn;t work. The following code (in theController.m) NSMutableString *aString = [NSMutableString string]; for ( i = 0; i < [translation count]; i++ ) { [aString appendString: [[translation objectAtIndex: i] aminoAcidSymbolString]]; } results in an empty aString. - Koen. From kvddrift at earthlink.net Sun Sep 26 11:56:27 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Sun, 26 Sep 2004 11:56:27 -0400 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: References: <6B2C14A7-0F32-11D9-BA32-003065A5FDCC@earthlink.net> Message-ID: <9FAC771C-0FD4-11D9-BA32-003065A5FDCC@earthlink.net> On Sep 26, 2004, at 5:38 AM, Alexander Griekspoor wrote: > >> I had another look at BioJava to see how they solve this. Actually, >> they only have a Symbol class, no SymbolDNA, SymbolRNA, >> SymbolAminoAcid, etc. The same for Sequence, no subclassing. What >> they do is pass the right Alphabet (I think this is what Alex is >> working on in BCSymbolSet) to create a sequence, and you know you're >> dealing with DNA, RNA, Protein, etc. It uses a couple of more >> classes (Alphabet, AlphabetManager, SequenceFactory, etc), but is a >> very elegant solution, IMO. > > Yes, it is. Still, that doesn't exclude that ours is not elegant as > well ;-) Seriously, we have discussed this way back and I pointed to > the way BioJava does things. Indeed the alphabet stuff is quite nice, > but overall I like the way we have done things just as much. In fact > the way we use class methods to generate shared instances, instead of > factory objects is something more elegant in my opinion. I agree for the way we create the symbols. But for creating sequences, I still think it would be beneficial if we pass a string (or other BCSequence) plus the required BCSymbolSet either to BCSequence, or to an external class that will return a BCSequence. We don't have to replace the current code, this can be just an additional way to do things. >>> Looking up methods in an ObjC superclass is significantly slower >>> than having them in the object being used. >> >> I didn't know that. Is this only for ObjC, or also for other OO >> languages, such as C++ and Java? > > I was curious as well, and did some searching on the web on the > Objective-C runtime. I found this snippet: > > The method is looked up BY NAME, first in the class and then in each > superclass in order. Once a successful lookup has occurred (or failed > to occur) the associated function pointer (or pointer to the error > function) is cached so that future invocations are fast (~ 2-3x a > simple function call). > > So it seems you're right in principle, but given the fact that most > methods we're talking about are only one superclass up, and that after > the first time, the function pointer is cached, I can hardly imagine > that you will see anything of this. The first lookup is during the init of the symbols, so any further manipulations should be fast, if I understand you correctly? - Koen. From mek at mekentosj.com Sun Sep 26 14:37:55 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Sun, 26 Sep 2004 20:37:55 +0200 Subject: [Biococoa-dev] BCNucleotideRNA In-Reply-To: <9FAC771C-0FD4-11D9-BA32-003065A5FDCC@earthlink.net> References: <6B2C14A7-0F32-11D9-BA32-003065A5FDCC@earthlink.net> <9FAC771C-0FD4-11D9-BA32-003065A5FDCC@earthlink.net> Message-ID: <2E31DB06-0FEB-11D9-A048-000393CFDE0C@mekentosj.com> >> Yes, it is. Still, that doesn't exclude that ours is not elegant as >> well ;-) Seriously, we have discussed this way back and I pointed to >> the way BioJava does things. Indeed the alphabet stuff is quite nice, >> but overall I like the way we have done things just as much. In fact >> the way we use class methods to generate shared instances, instead of >> factory objects is something more elegant in my opinion. > > I agree for the way we create the symbols. But for creating sequences, > I still think it would be beneficial if we pass a string (or other > BCSequence) plus the required BCSymbolSet either to BCSequence, or to > an external class that will return a BCSequence. We don't have to > replace the current code, this can be just an additional way to do > things. Sure we can add this possibility, let see how the BCSymbolSet turns out and then discuss how to add that exactly... >>>> Looking up methods in an ObjC superclass is significantly slower >>>> than having them in the object being used. >>> >>> I didn't know that. Is this only for ObjC, or also for other OO >>> languages, such as C++ and Java? >> >> I was curious as well, and did some searching on the web on the >> Objective-C runtime. I found this snippet: >> >> The method is looked up BY NAME, first in the class and then in each >> superclass in order. Once a successful lookup has occurred (or failed >> to occur) the associated function pointer (or pointer to the error >> function) is cached so that future invocations are fast (~ 2-3x a >> simple function call). >> >> So it seems you're right in principle, but given the fact that most >> methods we're talking about are only one superclass up, and that >> after the first time, the function pointer is cached, I can hardly >> imagine that you will see anything of this. > > The first lookup is during the init of the symbols, so any further > manipulations should be fast, if I understand you correctly? I'm not sure whether the methods are looked up for the first time when called or when the class is initialized. Anyway, I think it doesn't matter in either case.. 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 ********************************************************* ********************************************************* ** 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 jtimmer at bellatlantic.net Sun Sep 26 16:46:21 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Sun, 26 Sep 2004 16:46:21 -0400 Subject: [Biococoa-dev] translation demo In-Reply-To: Message-ID: >> Just to let you guys know, I'm planning on changing the DNATranslator >> to a >> generic tool class (BCToolRibosome?) that can handle both DNA and RNA >> with >> the same method. The method's going to wind up looking very similar >> to the >> existing one, but will be more broadly applicable. > > Nice! I would prefer BCToolTranslator though... > Will that replace the DNATranslator or come in addition? The current DNATranslator doesn't work (as Koen's seeing) due to all the changes in the underlying classes it uses. I'm planning on replacing it, and I'm pretty sure that, using all the methods I've added to those classes, I can get it to work as a single method. I'm hoping to get to work on it in a couple of days. JT _______________________________________________ This mind intentionally left blank From jtimmer at bellatlantic.net Tue Sep 28 12:52:52 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 28 Sep 2004 12:52:52 -0400 Subject: [Biococoa-dev] NSValue addition In-Reply-To: Message-ID: Just to inform everyone: I've added a file to the Utils section that adds a few methods as a category to NSValue (I wrote it a little while ago, but it got lost in the shuffle). Since a lot of what we do will use NSRanges and they can be stored in arrays as NSValues, I added a method that assumes NSRange values, and allows sorting of the array. This may be the easiest way to find things like "the longest" - put all possible ranges into the array, and then sort it. It's how I'm handling some of the ORF methods. Cheers, JT _______________________________________________ This mind intentionally left blank From mek at mekentosj.com Tue Sep 28 14:42:49 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Tue, 28 Sep 2004 20:42:49 +0200 Subject: [Biococoa-dev] NSValue addition In-Reply-To: References: Message-ID: <325EE75A-117E-11D9-BF77-000393CFDE0C@mekentosj.com> Although certainly very handy, the way how I usually do this is to have comparison objects in the wrapper objects we use. For instance in my enzymeX object that represents a cut in the DNA, I have a method sortOnCutPosition. Next, you can simply do [theArrayWithCutObjects sortUsingSelector: @selector(sortOnCutPosition:)]; That works beautifully, and again shows how useful this decorator/wrapper objects are we discussed earlier.... Nevertheless, nice to see these new possibilities added! Cheers, Alex Op 28-sep-04 om 18:52 heeft John Timmer het volgende geschreven: > Just to inform everyone: > > I've added a file to the Utils section that adds a few methods as a > category > to NSValue (I wrote it a little while ago, but it got lost in the > shuffle). > Since a lot of what we do will use NSRanges and they can be stored in > arrays > as NSValues, I added a method that assumes NSRange values, and allows > sorting of the array. > > This may be the easiest way to find things like "the longest" - put all > possible ranges into the array, and then sort it. It's how I'm > handling > some of the ORF methods. > > 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 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 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 Tue Sep 28 18:31:09 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 28 Sep 2004 18:31:09 -0400 Subject: [Biococoa-dev] NSValue addition In-Reply-To: References: Message-ID: <186B5B92-119E-11D9-980B-003065A5FDCC@earthlink.net> On Sep 28, 2004, at 12:52 PM, John Timmer wrote: > Just to inform everyone: > > I've added a file to the Utils section that adds a few methods as a > category > to NSValue (I wrote it a little while ago, but it got lost in the > shuffle). > Since a lot of what we do will use NSRanges and they can be stored in > arrays > as NSValues, I added a method that assumes NSRange values, and allows > sorting of the array. > > This may be the easiest way to find things like "the longest" - put all > possible ranges into the array, and then sort it. It's how I'm > handling > some of the ORF methods. John, Looks good, although I agree with Alex to put such functionality in wrappers. Just a small comment, would you mind renaming it to something that starts with BCUtil... ? thanks, - Koen. From jtimmer at bellatlantic.net Tue Sep 28 19:24:24 2004 From: jtimmer at bellatlantic.net (John Timmer) Date: Tue, 28 Sep 2004 19:24:24 -0400 Subject: [Biococoa-dev] NSValue addition In-Reply-To: <186B5B92-119E-11D9-980B-003065A5FDCC@earthlink.net> Message-ID: > Looks good, although I agree with Alex to put such functionality in > wrappers. Just a small comment, would you mind renaming it to something > that starts with BCUtil... ? No, no problem - I'll try to get to that tomorrow. Just to comment on where Ranges are useful - let's say you want to mark a DNA sequence's ORFs >25bp long. You translate it, then ask the BCCodonSequence where the ORFs are. You create an ORF object, but then you're already two objects removed from the original sequence. The intermediate item, the CodonSequence, doesn't know about either of them, or how to keep all the information in synch if anything changes. Returning an array of ranges will allow you to quickly mark them in the original sequence. I'm not saying there's no call for wrappers, just when there are obvious uses for something like a Range, you should also supply those methods. JT _______________________________________________ This mind intentionally left blank From kvddrift at earthlink.net Tue Sep 28 20:04:31 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Tue, 28 Sep 2004 20:04:31 -0400 Subject: [Biococoa-dev] NSValue addition In-Reply-To: References: Message-ID: <23414490-11AB-11D9-980B-003065A5FDCC@earthlink.net> On Sep 28, 2004, at 7:24 PM, John Timmer wrote: > >> Looks good, although I agree with Alex to put such functionality in >> wrappers. Just a small comment, would you mind renaming it to >> something >> that starts with BCUtil... ? > > No, no problem - I'll try to get to that tomorrow. > > Just to comment on where Ranges are useful - let's say you want to > mark a > DNA sequence's ORFs >25bp long. You translate it, then ask the > BCCodonSequence where the ORFs are. You create an ORF object, but then > you're already two objects removed from the original sequence. The > intermediate item, the CodonSequence, doesn't know about either of > them, or > how to keep all the information in synch if anything changes. > > Returning an array of ranges will allow you to quickly mark them in the > original sequence. I'm not saying there's no call for wrappers, just > when > there are obvious uses for something like a Range, you should also > supply > those methods. What would be really nice for the user, is a wrapper that uses that code (BCValueAdditions) to do everything behind the scenes. So you pass a sequence, set some parameters, and get in return your array of subsequences. - Koen. From mek at mekentosj.com Wed Sep 29 01:31:26 2004 From: mek at mekentosj.com (Alexander Griekspoor) Date: Wed, 29 Sep 2004 07:31:26 +0200 Subject: [Biococoa-dev] NSValue addition In-Reply-To: References: Message-ID: > I'm not saying there's no call for wrappers, just when > there are obvious uses for something like a Range, you should also > supply > those methods. Absolulely! ********************************************************* ** 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 ********************************************************* ********************************************************* ** 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 a.griekspoor at nki.nl Wed Sep 29 08:03:52 2004 From: a.griekspoor at nki.nl (Alexander Griekspoor) Date: Wed, 29 Sep 2004 14:03:52 +0200 Subject: [Biococoa-dev] New Mekentosj.com Message-ID: To those that have expressed their interest in the complete redesign of our website, Tom and I are enlightened to announce its release. The new website is rebuild from the ground up and uses a combination of the new webstandards xhtml and CSS (cascading style sheets), making it text based and reducing bandwidth uses up to 50%. Most important, we have added a lot more information, especially on the science part of our work, both the science about our programs and the science we do here in the lab. At the moment we are still hunting some layout bugs that you may encounter, and some parts are not yet available (did I say "Cubism"), but in general there is lot of new stuff to see ;-) Have a look at http://www.mekentosj.com Cheers, Alex Ps. due to the proxy server, the 4Peaks webpage can still appear as the old version within the NKI, the rest of the site should work fine though... ********************************************************* ** 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 kvddrift at earthlink.net Wed Sep 29 21:03:21 2004 From: kvddrift at earthlink.net (Koen van der Drift) Date: Wed, 29 Sep 2004 21:03:21 -0400 Subject: [Biococoa-dev] CVS commit notifications Message-ID: <85F6927B-127C-11D9-BA70-003065A5FDCC@earthlink.net> 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.