[seek-dev] Re: [kepler-dev] Query Builder Code Review
Bertram Ludaescher
ludaesch at sdsc.edu
Mon Aug 16 07:03:45 PDT 2004
Rod:
I think you migh have overinterpreted this. Email makes it easy to
read more into things, misunderstand the tone, etc.
just my $0.02
Bertram
>>>>> "rs" == Rod Spears <rods at ku.edu> writes:
RS>
RS> Edward,
RS> I was merely trying to have discussion about the Kepler style guide. I
RS> think your previous remarks were very divisive and inappropriate.
RS>
RS> Rod
RS>
RS>
RS> Edward A Lee wrote:
RS>
>>
>> Well, it seems very unlikely we'll ever agree here...
>> But I'm not giving up yet...
>>
>> Nobody is arguing for "every single file, module and/or
>> line of code looking exactly the same." This is a polarizing
>> statement...
>>
>> I'm arguing that the relatively _unimportant_ properties be dealt
>> with consistently.
>>
>> Unfortunately, many programmers feel that where the curly braces
>> go is actually extremely important, and they love to argue about
>> it... Too bad the same level of energy doesn't go into the important
>> things...
>>
>> Since coding style is really about the unimportant details,
>> it really has nothing to do with the "great commercial
>> software dilemma." Whether software sells has little to do with
>> coding style... I do believe that consistent coding style
>> promotes better software, but it's not because the coding
>> style makes the software look better. It's because other
>> programmers on the team can more easily understand your code.
>>
>> Unfortunately, programmers who are so dogmatic about
>> unimportant issues are also likely to be dogmatic about important
>> ones, leading to "Frankenware," where everyone's contribution
>> has a different approach to concurrency, UI design, etc.
>> But that is a separate issue... On any collaborative project,
>> there are always people contributing who you wish were not
>> contributing...
>>
>> As for the idea that software is publication, I agree it's a radical
>> idea, and it will require a cultural change to take hold. Cultural
>> changes are hard because there is a lot of dogma out there.
>> But I firmly believe that a good piece of software should be given
>> as much credibility for, say, tenure and promotion, as a good
>> series of papers... At Berkeley it is, but I think this is relatively
>> rare... But culturally, we have a long way to go...
>>
>> As for "being as productive as possible," a real risk that Kepler
>> faces is an explosion of actors. It is _not_ more likely to be used
>> if there are 10,000 actors in the library. In fact, it's less likely
>> to be used. Having less than 100 well-designed actors with orthogonal
>> functionality, a coherent design (parameter names, port names, icon
>> designs, concurrency styles, granularity, ...) is what will make
>> it likely to be used. This cannot happen if people aren't reading
>> each other's code. Dogmatically refusing to follow a coding
>> style will discourage people from reading your code.
>>
>> More is not better...
>>
>> Edward
>>
>>
>> At 10:10 AM 8/13/2004 -0500, Rod Spears wrote:
>>
>>> Sorry, I completely disagree. Writing software is certainly not the
>>> same as publishing academic papers, and I think it is a fascinating
>>> thought that Open Source could/should be considered a published work
>>> (sounds like a discussion for another day).
>>>
>>> The reality of Open Source software is that if you put a lot of rules
>>> in place you begin to limit the contributions, and that can be both
>>> good and bad. There is certainly a desired level of quality and
>>> certainly rules enforce that etc. etc. It was always a very difficult
>>> line to walk; that is, to encourage contributions and then figure out
>>> "how" to accept good work that may not fit exactly into the place it
>>> needs to fit.
>>>
>>> For example on Mozilla, the lack of every single file, module and/or
>>> line of code looking exactly the same was never a problem for anyone
>>> contributing to the project (I can't say it hurt productivity or the
>>> quality of the code).
>>>
>>> This discussion and it is one I have had over and over, reminds me of
>>> the great commercial software dilemma: Would a software engineer
>>> rather write:
>>> 1) A perfectly engineered piece of software with no bugs, that
>>> doesn't sell a dime.
>>> 2) A rather odd piece of software with some questionable design and
>>> architectural decisions that sells millions of copies.
>>>
>>> Certainly when writing commercial code, productivity ranks up there
>>> with quality and all the other important aspects of creating great
>>> software. I have seen this over and over again at the start of every
>>> project. The engineers wrangle over coding style for weeks, nobody
>>> can agree but with the higher levels of a style guide and in the end
>>> everyone gets worn down and tired of the discussion. And then
>>> everyone writes their code adhering to those general guidelines. I
>>> have yet to work on a commercial project where the style guide for
>>> coding was dictated to the engineers.
>>>
>>> But Kepler (with contributions from SEEK) is not a commercial
>>> project. So I guess I am at a loss to what its true priorities should
>>> be. My priorities from the beginning have always been to create
>>> something that people will actually use. To reach that goal I want to
>>> be as productive as possible.
>>>
>>> In my personal opinion the Ptolemy style guide is quite unique and so
>>> completely different than any other style guide I have used, that I
>>> find it cramping my style (pun intended). So I did what I did for the
>>> sake of getting my work done in a timely manner. (I could argue that
>>> because I used a style guide that is more comfortable to myself, the
>>> quality of my code is higher than if I struggled to "think" about my
>>> code as others "think" about their code)
>>>
>>> I stand by what I said earlier about a general style guide with
>>> module ownership and adapting to the style of the owner. It just
>>> seems odd that I need to adapt to Ptolemy's style guide (which is
>>> basically what Kepler's style guide is) and I doubt I will ever
>>> change a line of Ptolemy code. Of course if I did, I would be more
>>> than happy to adhere to its style completely.
>>>
>>> Rod
>>>
>>>
>>> Edward A Lee wrote:
>>>
>>>>
>>>> I would not take lightly making exceptions to the coding style...
>>>> Do it once, and everyone will feel free to do it, and you will not
>>>> have a coding style anymore...
>>>>
>>>> If you are publishing an academic paper, the editors of the journal
>>>> or conference proceedings get to decide on formatting issues. You
>>>> may have strong preferences about font, layout, reference styles,
>>>> header styles, etc., but you are not given a choice. Should that
>>>> be changed? I don't think so...
>>>>
>>>> Open source software should be viewed as form of publication.
>>>> The same principle should apply.
>>>>
>>>> Edward
>>>>
>>>> At 01:29 PM 8/12/2004 -0500, Rod Spears wrote:
>>>>
>>>>> I agree that we should have a more "formal" meeting about our
>>>>> Kepler coding standards. And I agree that one style does not fit all.
>>>>>
>>>>> But I still think we need to have some way to distinguish the scope
>>>>> of a variable from its prefix. If folks don't like what I have
>>>>> proposed then pick something, but it can be rather confusing
>>>>> without a prefix (as I have found when reading some of the current
>>>>> code).
>>>>>
>>>>> As a suggestion consider this:
>>>>> On Mozilla we had a general set of guidelines, which most us
>>>>> followed, but not everyone unfortunately. Of coarse, we could never
>>>>> agree on the curly brace issue, but we did a fairly good job on
>>>>> deciding on file names, interface file names, method argues, class
>>>>> data member names, and global names.
>>>>>
>>>>> The other overriding rule (especially because we had the notion of
>>>>> module ownership), was that you were to always make attempt to
>>>>> follow the coding standard of the files(s) you were working in.
>>>>>
>>>>> Meaning those who spent a lot of time in their modules had a little
>>>>> more flexibility in the style for those files, thus making it
>>>>> easier and more natural for those developers. Then, if by chance,
>>>>> you found yourself making changes to other people's code, you
>>>>> adapted to their style. The obvious idea was that you probably
>>>>> weren't going to be doing a lot of editting in other peoples code.
>>>>> Which, as it turns out, was pretty much true.
>>>>>
>>>>> I don't expect to be editting much if any Ptolemy code, etc. And it
>>>>> wouldn't make a lot of sense for someone to spend much time in the
>>>>> QB trying to fix a bug when I should probably be the fixing it.
>>>>>
>>>>> I think there is an economies of scale thing in here somewhere ;-)
>>>>>
>>>>> (Besides, outside of variable naming conventions, a lot of code can
>>>>> be reformatted with Eclipse or other tools)
>>>>>
>>>>> Rod
>>>>>
>>>>>
>>>>> Edward A Lee wrote:
>>>>>
>>>>> At 11:17 AM 8/12/2004 -0500, Rod Spears wrote:
>>>>>>
>>>>>>> Also, there seems to be some varying feelings and opinions about
>>>>>>> the coding style for Kepler. My approach which I am sure differs
>>>>>>> from Kepler is as follows:
>>>>>>>
>>>>>>> 1) All method arguments start with a lowercase "a"
>>>>>>> 2) All class data members all start with "m" (unless they are final)
>>>>>>> 3) All local variables have no prefix.
>>>>>>>
>>>>>>> It is my belief that you should always be able to look at a
>>>>>>> variable in the code and understand it's scope. I disagree with
>>>>>>> the approach where both the method arguments and the local
>>>>>>> variables have no prefix and are often distinguished by a
>>>>>>> "this.", which is rather verbose at times.
>>>>>>
>>>>>>
>>>>> While I think these are valid points,
>>>>> I would like to make a case for following the coding style anyway...
>>>>>>
>>>>> There is no coding style that will appeal to everyone (I guarantee
>>>>> it).
>>>>> The benefits of having a uniform coding style, however, far outweigh
>>>>> _any_ benefits you might derive from any particular coding style.
>>>>>>
>>>>> So, I would suggest that the discussion needs to be:
>>>>>>
>>>>> 1) What changes should be made to the uniform coding style?
>>>>> 2) Who's going to do the work to convert the existing code base
>>>>> to conform with any changes in the coding style?
>>>>>>
>>>>> Number 2 suggests that changes had better have pretty compelling
>>>>> reasons... I don't find the above reasons compelling enough...
>>>>> (nor are they consistent: What if I name a local variable "model"?
>>>>> Is it a class data member?).
>>>>>>
>>>>> I think the concerns addressed by this proposal are adequately
>>>>> addressed by keeping methods short and by choosing readable
>>>>> names for variables that a compositions of full words and clearly
>>>>> define the role of the variable.
>>>>>>
>>>>> Edward
>>>>>>
>>>>>>
>>>>>>
>>>>> ------------
>>>>> Edward A. Lee, Professor
>>>>> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>>>> phone: 510-642-0455, fax: 510-642-2739
>>>>> <mailto:eal at eecs.Berkeley.EDU>eal at eecs.Berkeley.EDU,
>>>>> <http://ptolemy.eecs.berkeley.edu/~eal>http://ptolemy.eecs.berkeley.edu/~eal
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rod Spears
>>>>> Biodiversity Research Center
>>>>> University of Kansas
>>>>> 1345 Jayhawk Boulevard
>>>>> Lawrence, KS 66045, USA
>>>>> Tel: 785 864-4082, Fax: 785 864-5335
>>>>
>>>>
>>>> ------------
>>>> Edward A. Lee, Professor
>>>> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>>>> phone: 510-642-0455, fax: 510-642-2739
>>>> <mailto:eal at eecs.Berkeley.EDU>eal at eecs.Berkeley.EDU,
>>>> http://ptolemy.eecs.berkeley.edu/~eal
>>>
>>>
>>>
>>> --
>>> Rod Spears
>>> Biodiversity Research Center
>>> University of Kansas
>>> 1345 Jayhawk Boulevard
>>> Lawrence, KS 66045, USA
>>> Tel: 785 864-4082, Fax: 785 864-5335
>>
>>
>> ------------
>> Edward A. Lee, Professor
>> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
>> phone: 510-642-0455, fax: 510-642-2739
>> eal at eecs.Berkeley.EDU, http://ptolemy.eecs.berkeley.edu/~eal
>>
>> _______________________________________________
>> seek-dev mailing list
>> seek-dev at ecoinformatics.org
>> http://www.ecoinformatics.org/mailman/listinfo/seek-dev
RS>
RS>
RS>
RS> --
RS> Rod Spears
RS> Biodiversity Research Center
RS> University of Kansas
RS> 1345 Jayhawk Boulevard
RS> Lawrence, KS 66045, USA
RS> Tel: 785 864-4082, Fax: 785 864-5335
RS>
RS> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
RS> <html>
RS> <head>
RS> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
RS> <title></title>
RS> </head>
RS> <body bgcolor="#ffffff" text="#000000">
RS> Edward,<br>
RS> <br>
RS> I was merely trying to have discussion about the Kepler style guide. I
RS> think your previous remarks were very divisive and inappropriate. <br>
RS> <br>
RS> Rod<br>
RS> <br>
RS> <br>
RS> Edward A Lee wrote:<br>
RS> <blockquote
RS> cite="mid5.1.0.14.2.20040813085449.01f3f6c0 at mho.eecs.berkeley.edu"
RS> type="cite"><br>
RS> Well, it seems very unlikely we'll ever agree here...
RS> <br>
RS> But I'm not giving up yet...
RS> <br>
RS> <br>
RS> Nobody is arguing for "every single file, module and/or
RS> <br>
RS> line of code looking exactly the same." This is a polarizing
RS> <br>
RS> statement...
RS> <br>
RS> <br>
RS> I'm arguing that the relatively _unimportant_ properties be dealt
RS> <br>
RS> with consistently.
RS> <br>
RS> <br>
RS> Unfortunately, many programmers feel that where the curly braces
RS> <br>
RS> go is actually extremely important, and they love to argue about
RS> <br>
RS> it... Too bad the same level of energy doesn't go into the important
RS> <br>
RS> things...
RS> <br>
RS> <br>
RS> Since coding style is really about the unimportant details,
RS> <br>
RS> it really has nothing to do with the "great commercial
RS> <br>
RS> software dilemma." Whether software sells has little to do with
RS> <br>
RS> coding style... I do believe that consistent coding style
RS> <br>
RS> promotes better software, but it's not because the coding
RS> <br>
RS> style makes the software look better. It's because other
RS> <br>
RS> programmers on the team can more easily understand your code.
RS> <br>
RS> <br>
RS> Unfortunately, programmers who are so dogmatic about
RS> <br>
RS> unimportant issues are also likely to be dogmatic about important
RS> <br>
RS> ones, leading to "Frankenware," where everyone's contribution
RS> <br>
RS> has a different approach to concurrency, UI design, etc.
RS> <br>
RS> But that is a separate issue... On any collaborative project,
RS> <br>
RS> there are always people contributing who you wish were not
RS> <br>
RS> contributing...
RS> <br>
RS> <br>
RS> As for the idea that software is publication, I agree it's a radical
RS> <br>
RS> idea, and it will require a cultural change to take hold. Cultural
RS> <br>
RS> changes are hard because there is a lot of dogma out there.
RS> <br>
RS> But I firmly believe that a good piece of software should be given
RS> <br>
RS> as much credibility for, say, tenure and promotion, as a good
RS> <br>
RS> series of papers... At Berkeley it is, but I think this is relatively
RS> <br>
RS> rare... But culturally, we have a long way to go...
RS> <br>
RS> <br>
RS> As for "being as productive as possible," a real risk that Kepler
RS> <br>
RS> faces is an explosion of actors. It is _not_ more likely to be used
RS> <br>
RS> if there are 10,000 actors in the library. In fact, it's less likely
RS> <br>
RS> to be used. Having less than 100 well-designed actors with orthogonal
RS> <br>
RS> functionality, a coherent design (parameter names, port names, icon
RS> <br>
RS> designs, concurrency styles, granularity, ...) is what will make
RS> <br>
RS> it likely to be used. This cannot happen if people aren't reading
RS> <br>
RS> each other's code. Dogmatically refusing to follow a coding
RS> <br>
RS> style will discourage people from reading your code.
RS> <br>
RS> <br>
RS> More is not better...
RS> <br>
RS> <br>
RS> Edward
RS> <br>
RS> <br>
RS> <br>
RS> At 10:10 AM 8/13/2004 -0500, Rod Spears wrote:
RS> <br>
RS> <blockquote type="cite">Sorry, I completely disagree. Writing
RS> software is certainly not the same as publishing academic papers, and I
RS> think it is a fascinating thought that Open Source could/should be
RS> considered a published work (sounds like a discussion for another day).
RS> <br>
RS> <br>
RS> The reality of Open Source software is that if you put a lot of rules
RS> in place you begin to limit the contributions, and that can be both
RS> good and bad. There is certainly a desired level of quality and
RS> certainly rules enforce that etc. etc. It was always a very difficult
RS> line to walk; that is, to encourage contributions and then figure out
RS> "how" to accept good work that may not fit exactly into the place it
RS> needs to fit.
RS> <br>
RS> <br>
RS> For example on Mozilla, the lack of every single file, module and/or
RS> line of code looking exactly the same was never a problem for anyone
RS> contributing to the project (I can't say it hurt productivity or the
RS> quality of the code).
RS> <br>
RS> <br>
RS> This discussion and it is one I have had over and over, reminds me of
RS> the great commercial software dilemma: Would a software engineer rather
RS> write:
RS> <br>
RS> 1) A perfectly engineered piece of software with no bugs, that doesn't
RS> sell a dime.
RS> <br>
RS> 2) A rather odd piece of software with some questionable design and
RS> architectural decisions that sells millions of copies.
RS> <br>
RS> <br>
RS> Certainly when writing commercial code, productivity ranks up there
RS> with quality and all the other important aspects of creating great
RS> software. I have seen this over and over again at the start of every
RS> project. The engineers wrangle over coding style for weeks, nobody can
RS> agree but with the higher levels of a style guide and in the end
RS> everyone gets worn down and tired of the discussion. And then everyone
RS> writes their code adhering to those general guidelines. I have yet to
RS> work on a commercial project where the style guide for coding was
RS> dictated to the engineers.
RS> <br>
RS> <br>
RS> But Kepler (with contributions from SEEK) is not a commercial project.
RS> So I guess I am at a loss to what its true priorities should be. My
RS> priorities from the beginning have always been to create something that
RS> people will actually use. To reach that goal I want to be as productive
RS> as possible.
RS> <br>
RS> <br>
RS> In my personal opinion the Ptolemy style guide is quite unique and so
RS> completely different than any other style guide I have used, that I
RS> find it cramping my style (pun intended). So I did what I did for the
RS> sake of getting my work done in a timely manner. (I could argue that
RS> because I used a style guide that is more comfortable to myself, the
RS> quality of my code is higher than if I struggled to "think" about my
RS> code as others "think" about their code)
RS> <br>
RS> <br>
RS> I stand by what I said earlier about a general style guide with module
RS> ownership and adapting to the style of the owner. It just seems odd
RS> that I need to adapt to Ptolemy's style guide (which is basically what
RS> Kepler's style guide is) and I doubt I will ever change a line of
RS> Ptolemy code. Of course if I did, I would be more than happy to adhere
RS> to its style completely.
RS> <br>
RS> <br>
RS> Rod
RS> <br>
RS> <br>
RS> <br>
RS> Edward A Lee wrote:
RS> <br>
RS> <blockquote type="cite"><br>
RS> I would not take lightly making exceptions to the coding style...
RS> <br>
RS> Do it once, and everyone will feel free to do it, and you will not
RS> <br>
RS> have a coding style anymore...
RS> <br>
RS> <br>
RS> If you are publishing an academic paper, the editors of the journal
RS> <br>
RS> or conference proceedings get to decide on formatting issues. You
RS> <br>
RS> may have strong preferences about font, layout, reference styles,
RS> <br>
RS> header styles, etc., but you are not given a choice. Should that
RS> <br>
RS> be changed? I don't think so...
RS> <br>
RS> <br>
RS> Open source software should be viewed as form of publication.
RS> <br>
RS> The same principle should apply.
RS> <br>
RS> <br>
RS> Edward
RS> <br>
RS> <br>
RS> At 01:29 PM 8/12/2004 -0500, Rod Spears wrote:
RS> <br>
RS> <blockquote type="cite">I agree that we should have a more
RS> "formal" meeting about our Kepler coding standards. And I agree that
RS> one style does not fit all.
RS> <br>
RS> <br>
RS> But I still think we need to have some way to distinguish the scope of
RS> a variable from its prefix. If folks don't like what I have proposed
RS> then pick something, but it can be rather confusing without a prefix
RS> (as I have found when reading some of the current code).
RS> <br>
RS> <br>
RS> As a suggestion consider this:
RS> <br>
RS> On Mozilla we had a general set of guidelines, which most us followed,
RS> but not everyone unfortunately. Of coarse, we could never agree on the
RS> curly brace issue, but we did a fairly good job on deciding on file
RS> names, interface file names, method argues, class data member names,
RS> and global names.
RS> <br>
RS> <br>
RS> The other overriding rule (especially because we had the notion of
RS> module ownership), was that you were to always make attempt to follow
RS> the coding standard of the files(s) you were working in.
RS> <br>
RS> <br>
RS> Meaning those who spent a lot of time in their modules had a little
RS> more flexibility in the style for those files, thus making it easier
RS> and more natural for those developers. Then, if by chance, you found
RS> yourself making changes to other people's code, you adapted to their
RS> style. The obvious idea was that you probably weren't going to be doing
RS> a lot of editting in other peoples code. Which, as it turns out, was
RS> pretty much true.
RS> <br>
RS> <br>
RS> I don't expect to be editting much if any Ptolemy code, etc. And it
RS> wouldn't make a lot of sense for someone to spend much time in the QB
RS> trying to fix a bug when I should probably be the fixing it.
RS> <br>
RS> <br>
RS> I think there is an economies of scale thing in here somewhere ;-)
RS> <br>
RS> <br>
RS> (Besides, outside of variable naming conventions, a lot of code can be
RS> reformatted with Eclipse or other tools)
RS> <br>
RS> <br>
RS> Rod
RS> <br>
RS> <br>
RS> <br>
RS> Edward A Lee wrote:
RS> <br>
RS> <blockquote type="cite">At 11:17 AM 8/12/2004 -0500, Rod Spears
RS> wrote:
RS> <br>
RS> <blockquote type="cite">Also, there seems to be some varying
RS> feelings and opinions about the coding style for Kepler. My approach
RS> which I am sure differs from Kepler is as follows:
RS> <br>
RS> <br>
RS> 1) All method arguments start with a lowercase "a"
RS> <br>
RS> 2) All class data members all start with "m" (unless they are final)
RS> <br>
RS> 3) All local variables have no prefix.
RS> <br>
RS> <br>
RS> It is my belief that you should always be able to look at a variable in
RS> the code and understand it's scope. I disagree with the approach where
RS> both the method arguments and the local variables have no prefix and
RS> are often distinguished by a "this.", which is rather verbose at times.
RS> <br>
RS> </blockquote>
RS> <br>
RS> While I think these are valid points,
RS> <br>
RS> I would like to make a case for following the coding style anyway...
RS> <br>
RS> <br>
RS> There is no coding style that will appeal to everyone (I guarantee it).
RS> <br>
RS> The benefits of having a uniform coding style, however, far outweigh
RS> <br>
RS> _any_ benefits you might derive from any particular coding style.
RS> <br>
RS> <br>
RS> So, I would suggest that the discussion needs to be:
RS> <br>
RS> <br>
RS> 1) What changes should be made to the uniform coding style?
RS> <br>
RS> 2) Who's going to do the work to convert the existing code base
RS> <br>
RS> to conform with any changes in the coding style?
RS> <br>
RS> <br>
RS> Number 2 suggests that changes had better have pretty compelling
RS> <br>
RS> reasons... I don't find the above reasons compelling enough...
RS> <br>
RS> (nor are they consistent: What if I name a local variable "model"?
RS> <br>
RS> Is it a class data member?).
RS> <br>
RS> <br>
RS> I think the concerns addressed by this proposal are adequately
RS> <br>
RS> addressed by keeping methods short and by choosing readable
RS> <br>
RS> names for variables that a compositions of full words and clearly
RS> <br>
RS> define the role of the variable.
RS> <br>
RS> <br>
RS> Edward
RS> <br>
RS> <br>
RS> <br>
RS> <br>
RS> ------------
RS> <br>
RS> Edward A. Lee, Professor
RS> <br>
RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
RS> <br>
RS> phone: 510-642-0455, fax: 510-642-2739
RS> <br>
RS> <a class="moz-txt-link-rfc2396E" href="mailto:eal at eecs.Berkeley.EDU"><mailto:eal at eecs.Berkeley.EDU></a><a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>,
RS> <a class="moz-txt-link-rfc2396E" href="http://ptolemy.eecs.berkeley.edu/~eal"><http://ptolemy.eecs.berkeley.edu/~eal></a><a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
RS> <br>
RS> </blockquote>
RS> <br>
RS> <br>
RS> --
RS> <br>
RS> Rod Spears
RS> <br>
RS> Biodiversity Research Center
RS> <br>
RS> University of Kansas
RS> <br>
RS> 1345 Jayhawk Boulevard
RS> <br>
RS> Lawrence, KS 66045, USA
RS> <br>
RS> Tel: 785 864-4082, Fax: 785 864-5335
RS> <br>
RS> </blockquote>
RS> <br>
RS> ------------
RS> <br>
RS> Edward A. Lee, Professor
RS> <br>
RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
RS> <br>
RS> phone: 510-642-0455, fax: 510-642-2739
RS> <br>
RS> <a class="moz-txt-link-rfc2396E" href="mailto:eal at eecs.Berkeley.EDU"><mailto:eal at eecs.Berkeley.EDU></a><a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>,
RS> <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
RS> <br>
RS> </blockquote>
RS> <br>
RS> <br>
RS> --
RS> <br>
RS> Rod Spears
RS> <br>
RS> Biodiversity Research Center
RS> <br>
RS> University of Kansas
RS> <br>
RS> 1345 Jayhawk Boulevard
RS> <br>
RS> Lawrence, KS 66045, USA
RS> <br>
RS> Tel: 785 864-4082, Fax: 785 864-5335
RS> <br>
RS> </blockquote>
RS> <br>
RS> ------------
RS> <br>
RS> Edward A. Lee, Professor
RS> <br>
RS> 518 Cory Hall, UC Berkeley, Berkeley, CA 94720
RS> <br>
RS> phone: 510-642-0455, fax: 510-642-2739
RS> <br>
RS> <a class="moz-txt-link-abbreviated" href="mailto:eal at eecs.Berkeley.EDU">eal at eecs.Berkeley.EDU</a>, <a class="moz-txt-link-freetext" href="http://ptolemy.eecs.berkeley.edu/~eal">http://ptolemy.eecs.berkeley.edu/~eal</a>
RS> <br>
RS> <br>
RS> _______________________________________________
RS> <br>
RS> seek-dev mailing list
RS> <br>
RS> <a class="moz-txt-link-abbreviated" href="mailto:seek-dev at ecoinformatics.org">seek-dev at ecoinformatics.org</a>
RS> <br>
RS> <a class="moz-txt-link-freetext" href="http://www.ecoinformatics.org/mailman/listinfo/seek-dev">http://www.ecoinformatics.org/mailman/listinfo/seek-dev</a>
RS> <br>
RS> </blockquote>
RS> <br>
RS> <br>
RS> <div class="moz-signature">-- <br>
RS> <table>
RS> <tbody>
RS> <tr>
RS> <td
RS> style="border: 1px solid gray; font-size: 8pt; font-family: arial,sans-serif;">Rod
RS> Spears<br>
RS> Biodiversity Research Center<br>
RS> University of Kansas<br>
RS> 1345 Jayhawk Boulevard<br>
RS> Lawrence, KS 66045, USA<br>
RS> Tel: 785 864-4082, Fax: 785 864-5335<br>
RS> </td>
RS> </tr>
RS> </tbody>
RS> </table>
RS> </div>
RS> </body>
RS> </html>
More information about the Kepler-dev
mailing list