Naming the modules; Mailing lists

[Steven E. Brenner]

n.b.  I received two copies of this message.  Please make sure that my
address on the vsns-bcd-perl is just 'brenner@akamail.com'

--

I take it we agree on the text for the mailing-list annoucment?  Do you
want to send the 'final beta' text to be checked?

Are there comments from anyone besides me?


--

> > Similar comments apply to the text of the bioperl web page.  I would
> > suggest making the page 1/10th of its current length, and putting all the
> > details onto sub-pages; details below
> 
> I'd rather not like to do this; adding a TOC should suffice ?! The main reason 
> is that updating becomes more messy if there are a lot of pages; and I could
> no longer just overwrite one page via netscape whenever you desire an update.
> Also, a lot of ppl love longer pages b/c they can print them out in one go.
> ok? If no, will change this asap.


I suppose I could live with the long page, and the improvements made are
already very significnat.  But let's keep open the possibility of multiple
pages in the future?

Some comments:

- The texture-mapped DNA is kind of neat.  Unfortunately, unless you know
that it is DNA, you would have difficulty recognizing it as such!  

- The headers should be put in bigger text

- The related links should be closer together (get rid of the <p> marks

- The table of contents should be more detailed (e.g., include the 
names of the two modules at the top)

- The mailing list really should be on a separate page, because it needs
to include the charter.  Also, right now the paragraph format of the
information about the mailing lists is difficult to interpret.  More about
lists below.

- Why don't you use index.html as the default welcome page on your site?
index.html is the standard default page!   I do think that the mirror is
potentially useful.


----

Regarding lists

> I feel that we need a list for user's questions, and there are not enough ppl
> yet to mandate a split users<->developers. (Since the interaction users<->
> developers is very useful, especially in the early stages, a split should 
> only be done if too much mail is created.)

  I see the point here.  However, we should warn people that vsns-bcd-perl
will occasionally have high volume.  It should be indicated only for
people who intend to ask questions or comment about the list.


> If you feel there should be a split, we should have vsns-bcd-perl for users,
> and vsns-bcd-perl-guts for the developers.

  As you suggest, I think that this might be something to do in the
future.  



> > I would include a lot more informaiton here.  First, give a brief
> > introduction to the bioperl projects (2 sentences).  The explain the list
> > (2 sentences), and point people towards a charter (similar to the old one
> > at http://scop.mrc-lmb.cam.ac.uk/pub/bioperl/)
> > 
> > Then tell people where to go for more informaiton.. the bioperl homepage
> > and the archives.
> 
> Note that this means double work in updating; no time for that I think !
> (Better a short welcome message than an outdated one.)
> There should definitely be a pointer to a general mailing list charter 
> (no spams, etc), if you prepare one.

A couple of sentences should be chosen which won't go out of date.  If you
look at the old bioperl list charter, you can see that it is still mostly
relevant.


> > >   VSNSBCD  The Bioperl Project mailing list
> > >            Mail to majordomo@lists.uni-bielefeld.de with body
> > >            "subscribe vsns-bcd-perl". There is an announcement-only
> > >            low-volume mailing list too, mail with body
> > >            "subscribe vsns-bcd-perl-announce" instead.
> > 
> > Looks good, except, I'm going to change the VSNSBCD to just Bioperl.  
> 
> Ok, although I'd love to see VSNSBCD mentioned... But life is a compromise :)

It mentions vsns-bcd in the actual mailing list name!  VSNSBCD does things
besides bioperl, so it would be an inappropriate name for hte support
list.



> 
> First, we need to resolve the following
> >>>>>>>> 
> [I wrote] [...] 
> http://world.std.com/~swmcd/steven/Perl/module_mechanics.html
> also reflects that resentment, and the offerings -re-
> ``Building Related Perl Modules'' and
> ``Testing a module from a Perl program'' made me feel uneasy.

I don't understand why.  Note that there is also documentation about this
stuff in the actual Perl manpages	


> But as the page's author says, ``You get used to it. Really.'' Oh well.
> Maybe you've got better recommandations than the ones on that page ?
> <<<<<<<<
> As I said, I've run into trouble anyway, getting a variety of make problems.
> I'll work again through the module_mechanics recommandations of _you_
> recommand them. But maybe it's easier if you just do this yourself, because
> then you can set things up in exactly the way you like. I can prepare
> a Bio::UnivAln tar file _without_ the PGPLOT stuff as soon as you request it.

Yes -- please build it without any PGPLOT stuff for now, if that's what's
causing the problem. 



Right now I'm running on a temporary computer system, so I do not have any
decent facilities for doing much of anything.  (That's part of why I made
my comments on the paper!)  If you can get me a fully working package, I
can test it.



> > Steve
> 
> Steve wrote, -re- my comments about his snail-mail
> > > Just 4 comments now:
> > > *Pls reload Bio::UnivAln, take another look at consensus() !
> > Will try to do soon.
> > 
> > > *Also, the Fasta Regexp: I'm still not sure that mine is wrong !
> > Yours is ok; just strange.  Also, how does all of this code deal with
> > DOS-formatted files (i.e., that end in \r\n).
> 
> uh, uh... Have you got a solution for this?
> Is it just DOS, or WinNT/Win95 as well ?

It is Windows systems too.  But let's ignore it for now.

> > > *Re the last page of the snail: I still think it's easy to extract a column 
> > > as a string, but I guess it's the last time I'm mentioning that..
> > It is not easy to exract a column which corresponds to a desired column in
> > one of the sequences.  I _always_ index off of one of the sequences, not
> > the alignment (whose numbering is arbitrary and would change if a longer
> > sequence were added).
> 
> I hope that this can easily be worked in by adding a record 
> {'numbering'}[$seq_number], once numbering is resolved for Bio::Seq. (It 
> would need proper accessors, like {'names'}{'seqs'}[$seq_number]{'id'} and 
> ...{'desc'} do.)

That only works if $seq_number is integral.  And it would be extremely
slow. 



Cheers, 
  Steve