[Bioperl-l] Re: cloning and Storable

Will Spooner whs at sanger.ac.uk
Fri Sep 5 13:10:23 EDT 2003


On Fri, 5 Sep 2003, Heikki Lehvaslaiho wrote:

> Will,
> 
> We are claiming to support perl 5.005 and luckily it was the first perl
> release that contained Data::Dumper in core, so go ahead and add it. You
> could  use it as the default storage method as it is guarantied to be
> present.

Data::Dumper is a great debug tool, but has it's little ...problems... 

Now solved though - new code goes with Storable if it can, but uses
Data::Dumper as a fallback. Users can set $Bio::Root::Storable::BINARY to
false to force the use of Data::Dumper. 

Have mailed the latest module + test seperately.

> 
> How do I know? RpmFind has info about all the rpms for a the past few
> years. Here is a list of 5.005 modules:
> 
> http://fr2.rpmfind.net//linux/RPM/redhat/6.2/i386/perl-5.00503-10.i386.html

Thats a good trick ;)

Will





> 
> 	-Heikki
> 
> On Fri, 2003-09-05 at 15:16, Will Spooner wrote:
> > On Fri, 5 Sep 2003, Heikki Lehvaslaiho wrote:
> > 
> > > Will,
> > > 
> > > This does not solve my problem but is a great module to add into
> > > bioperl. I'll do it right now if you promise to write a test file in
> > > near future. ;-)
> > > 
> > > 
> > > I added the following text into docs:
> > > 
> > > Anyone planning to use Bio::Root::Storable in bioperl modules:
> > > Storable is not part of all perl core libraries. When inheriting from
> > > it, you have to do:
> > >     eval { require Storable; };
> > > and fail gracefully.
> > > 
> > 
> > I have plans to add an ASCII option that replaces Storable with
> > Data::Dumper. That's a core Perl 5.8 module, but I don't know about
> > earlier versions.
> > 
> > Will
> > 
> > 
> > > 
> > > 	-Heikki
> > > 
> > > On Fri, 2003-09-05 at 09:39, Will Spooner wrote:
> > > > This may be a good time to mention that we have developed a
> > > > Bio::Root::Storable module for use with the Ensembl web site. 
> > > > 
> > > > This module is used specifically for serialising/retrieving Search objects
> > > > to disk after parsing with SearchIO. It is in production, and works very
> > > > well, even in a high-throughput environment.
> > > > 
> > > > The implementation is generic (can be inhereted by any bioperl object),
> > > > and even implements a clone() method.
> > > > 
> > > > I have attached the module to this mail, and pasted the description below.
> > > > I would be delighted to see this module incorperated into BioPerl if
> > > > appropriate. I don't know whether it will solve Hekki's problem, but may 
> > > > provide an alternative to writing a new serialiser!
> > > > 
> > > > Regards,
> > > > 
> > > > Will
> > > > 
> > > > ---
> > > > Will Spooner                   whs at sanger.ac.uk
> > > > Ensembl Web Developer    http://www.ensembl.org
> > > > 
> > > > 
> > > > NAME
> > > >   Bio::Root::Storable - object serialisation methods
> > > > 
> > > > SYNOPSIS
> > > >     my $storable = Bio::Root::Storable->new();
> > > > 
> > > >     # Store/retrieve using class retriever
> > > >     my $token     = $storable->store();
> > > >     my $storable2 = Bio::Root::Storable->retrieve( $token );
> > > > 
> > > >     # Store/retrieve using object retriever
> > > >     my $storable2 = $storable->new_retrievable();
> > > >     $storable2->retrieve();
> > > > 
> > > > DESCRIPTION
> > > >   Generic module that allows objects to be safely stored/retrieved from
> > > >   disk. Can be inhereted by any BioPerl object. As it will not usually be
> > > >   the first class in the inheretence list, _initialise_storable() should
> > > >   be called during object instantiation.
> > > > 
> > > >   Currently stores objects in binary format (using the Perl Storable
> > > >   module). This can cause problems when storing and retrieving with different
> > > >   versions of Storable (e.g. on different machines). An ASCII storage
> > > >   option (using Data::Dumper) may be implemented in the future.
> > > > 
> > > >   Object storage is recursive; If the object being stored contains other
> > > >   storable objects, these will be stored seperately, and replaced by a
> > > >   skeleton object in the parent heirarchy. When the parent is later
> > > >   retrieved, its children remain in the skeleton state until explicitly
> > > >   retrieved by the parent. This lazy-retrieve approach has obvious memory
> > > >   efficiency benefits for certain applications.
> > > > 
> > > -- 
> > > ______ _/      _/_____________________________________________________
> > >       _/      _/                      http://www.ebi.ac.uk/mutations/
> > >      _/  _/  _/  Heikki Lehvaslaiho    heikki_at_ebi ac uk
> > >     _/_/_/_/_/  EMBL Outstation, European Bioinformatics Institute
> > >    _/  _/  _/  Wellcome Trust Genome Campus, Hinxton
> > >   _/  _/  _/  Cambs. CB10 1SD, United Kingdom
> > >      _/      Phone: +44 (0)1223 494 644   FAX: +44 (0)1223 494 468
> > > ___ _/_/_/_/_/________________________________________________________
> > > 
> > 
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l at portal.open-bio.org
> > http://portal.open-bio.org/mailman/listinfo/bioperl-l
> -- 
> ______ _/      _/_____________________________________________________
>       _/      _/                      http://www.ebi.ac.uk/mutations/
>      _/  _/  _/  Heikki Lehvaslaiho    heikki_at_ebi ac uk
>     _/_/_/_/_/  EMBL Outstation, European Bioinformatics Institute
>    _/  _/  _/  Wellcome Trust Genome Campus, Hinxton
>   _/  _/  _/  Cambs. CB10 1SD, United Kingdom
>      _/      Phone: +44 (0)1223 494 644   FAX: +44 (0)1223 494 468
> ___ _/_/_/_/_/________________________________________________________
> 




More information about the Bioperl-l mailing list