headers
Lincoln Stein | 1 May 19:33
Picon
Gravatar

Re: Bio::DB::SeqFeature::Segment problem

Hi Jon,

Sounds like your multiple chromosome-1 problems have been cleared up. The
documentation should mention the exception and doesn't. I will fix it.

Lincoln

On Thu, Apr 30, 2009 at 12:40 PM, Jon Flowers <jonathanmflowers <at> gmail.com>wrote:

>
> Dear colleagues,
>
> I have set up a mySQL database and loaded a GFF3 and fasta file using
> Bio::DB::SeqFeature::Store::GFF3Loader.  Everything appears to be working
> normally except when I attempt to create a Bio::DB::SeqFeature::Segment
> object.
>
> The following works as expected:
>
> my $db = Bio::DB::SeqFeature::Store->new(-adaptor => 'DBI::mysql',
>                                                                 -dsn =>
> 'dbi:mysql:foo',
>                                                                 -user =>
> 'myuser',
>                                                                 -pass =>
> 'mypassword',
>                                                                 -write =>
> '1');
>
> my @features = $db->features(-seq_id=>'chr1',
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hilmar Lapp | 3 May 20:36
Picon
Gravatar

Re: Other object oddities

I agree, $seq->seq() could possibly be better named. Maybe $seq- 
 >seqstr()?

The thing is that having $seq->seq() return an object would be  
meaningless - it would be $self.

You can test what kind of object you have using ref() or isa():

	$seq = $obj->seq();
	# we need the sequence string
	$seq = $seq->seq() if ref($seq) && $seq->isa("Bio::PrimarySeqI");

There has been a naming consistency review, but it's been a long time.

-hilmar

On Apr 30, 2009, at 5:56 PM, Kevin Brown wrote:

> So, I'm using quite a bit of bioperl code in my own stuff and have  
> been
> seeing some oddities with the naming of methods. A good example  
> would be
> in the Bio::Seq and Bio::SeqFeature::Generic. Both have a method  
> called
> "seq" but in the latter case it returns an object (and expects an  
> object
> when doing a Set) and in the former it returns a string and expects a
> string when doing a Set.
>
> This makes for a bit of brain freeze on my part when the return from
(Continue reading)

Permalink | Reply | 22 comments |
headers
yi wang | 4 May 06:42
Picon

bioperl / emboss on windows

---------- Forwarded message ----------
From: yi wang <wangyi2412 <at> gmail.com>
Date: 2009/5/4
Subject: bioperl on windows
To: bioperl-l <at> bioperl.org

I have installed the bioperl and emboss on my* windows xp*, as guided on the
web. But it
--------------------- WARNING ---------------------
*MSG: Application [needle] is not available!*
---------------------------------------------------

use warnings;
use CGI;
use Bio::Perl;
use Bio::Root::Root;
use Bio::Factory::ApplicationFactoryI;
use Bio::Factory::EMBOSS;
use Bio::Tools::Run::EMBOSSApplication;

*my $f = Bio::Factory::EMBOSS -> new();*
*$f->program("needle");*
#my $factory = new Bio::Factory::EMBOSS;
#my $compseqapp = $factory->program("needle");

I checked the manual and the emboss.pm, write the programe as the demo, but
it could work! How could it be the problem? Thank you very much!
*Looking for your reply!*

Best Wishes,
(Continue reading)

Permalink | Reply | 7 comments |
headers
Scott Markel | 4 May 15:41
Favicon

Re: bioperl / emboss on windows

Is needle in your path?

Note that needle needs two input sequences, which you don't provide.
You might try invoking embossversion, which takes no inputs.

Scott

Scott Markel, Ph.D.
Principal Bioinformatics Architect  email:  smarkel <at> accelrys.com
Accelrys (SciTegic R&D)             mobile: +1 858 205 3653
10188 Telesis Court, Suite 100      voice:  +1 858 799 5603
San Diego, CA 92121                 fax:    +1 858 799 5222
USA                                 web:    http://www.accelrys.com

http://www.linkedin.com/in/smarkel
Vice President, Board of Directors:
    International Society for Computational Biology
Co-chair: ISCB Publications Committee
Associate Editor: PLoS Computational Biology
Editorial Board: Briefings in Bioinformatics

> -----Original Message-----
> From: bioperl-l-bounces <at> lists.open-bio.org [mailto:bioperl-l-
> bounces <at> lists.open-bio.org] On Behalf Of yi wang
> Sent: Sunday, 03 May 2009 9:43 PM
> To: bioperl-l <at> bioperl.org
> Subject: [Bioperl-l] bioperl / emboss on windows
> 
> ---------- Forwarded message ----------
> From: yi wang <wangyi2412 <at> gmail.com>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kevin Brown | 4 May 17:31
Picon
Favicon

Re: Other object oddities

I don't mind that Bio::Seq uses seq to return a string. In fact I prefer
that. Just would be nice if other objects obeyed the same convention.
Bio::SeqFeature::Generic returns an object for both entire_seq and seq,
but uses attach_seq to store the Bio::Seq object into the Feature.

Maybe SeqFeature could be adjusted so that ->seq returns the sequence
string of the feature (just like Bio::Seq) and ->feature_seq returns the
Bio::Seq object.

> -----Original Message-----
> From: Hilmar Lapp [mailto:hlapp <at> gmx.net] 
> Sent: Sunday, May 03, 2009 11:37 AM
> To: Kevin Brown
> Cc: BioPerl List
> Subject: Re: [Bioperl-l] Other object oddities
> 
> I agree, $seq->seq() could possibly be better named. Maybe $seq- 
>  >seqstr()?
> 
> The thing is that having $seq->seq() return an object would be  
> meaningless - it would be $self.
> 
> You can test what kind of object you have using ref() or isa():
> 
> 	$seq = $obj->seq();
> 	# we need the sequence string
> 	$seq = $seq->seq() if ref($seq) && 
> $seq->isa("Bio::PrimarySeqI");
> 
> There has been a naming consistency review, but it's been a long time.
(Continue reading)

Permalink | Reply | 21 comments |
headers
uludag | 4 May 17:39
Picon
Picon
Favicon

Re: bioperl / emboss on windows


It looks like EMBOSS was disabled in Bio\Factory\EMBOSS.pm for Windows
platform. After commenting out the related condition in the _program_list
function (as shown below) i don't get the "Application [needle] is not
available" error any more.

    if( #$^O =~ /MSWIN/i ||

Regards,
Mahmut

> I have installed the bioperl and emboss on my* windows xp*, as guided on
> the web. But it
> --------------------- WARNING ---------------------
> *MSG: Application [needle] is not available!*
> ---------------------------------------------------
>
>
> use warnings;
> use CGI;
> use Bio::Perl;
> use Bio::Root::Root;
> use Bio::Factory::ApplicationFactoryI;
> use Bio::Factory::EMBOSS;
> use Bio::Tools::Run::EMBOSSApplication;
>
>
>
> *my $f = Bio::Factory::EMBOSS -> new();*
> *$f->program("needle");*
(Continue reading)

Permalink | Reply | 5 comments |
headers
Mark A. Jensen | 4 May 17:50
Picon
Favicon
Gravatar

Re: Other object oddities

This is definitely a reasonable issue to chase down. How to do it needs
a little care. I personally see 'seq' and think 'object', and have resorted to
'seqstr' in my own code to hold/access just strings. FWIW, my preference would
be to have any object that has a seq object as a property return objects
when a '..._seq' accessor is called. However, the seq objects themselves
generally contain the sequence string in their seq() property. We wouldn't
want to disrupt that, but would it be worth creating an alias getter/setter for
the Seq classes seq() property called 'seqstr'? We could then count on

$foo->bar_seq, an object
$foo->bar_seq->seqstr, a string
$foo->seqstr, a string (not nec same as above)

cheers Mark
----- Original Message ----- 
From: "Kevin Brown" <Kevin.M.Brown <at> asu.edu>
Cc: "BioPerl List" <Bioperl-l <at> lists.open-bio.org>
Sent: Monday, May 04, 2009 11:31 AM
Subject: Re: [Bioperl-l] Other object oddities

>I don't mind that Bio::Seq uses seq to return a string. In fact I prefer
> that. Just would be nice if other objects obeyed the same convention.
> Bio::SeqFeature::Generic returns an object for both entire_seq and seq,
> but uses attach_seq to store the Bio::Seq object into the Feature.
>
> Maybe SeqFeature could be adjusted so that ->seq returns the sequence
> string of the feature (just like Bio::Seq) and ->feature_seq returns the
> Bio::Seq object.
>
>> -----Original Message-----
(Continue reading)

Permalink | Reply | 18 comments |
headers
Kevin Brown | 4 May 17:58
Picon
Favicon

Re: Other object oddities

I guess since my first exposure to BioPerl was reading in FASTA data,
that I picked up the preference for ->seq to be a string as that is what
happens in Bio::Seq objects. So, I see seq and think sequence string,
heheh.

Just be aware, ->seq returning/setting a string seems to be far more
common than it returning an object.

> -----Original Message-----
> From: Mark A. Jensen [mailto:maj <at> fortinbras.us] 
> Sent: Monday, May 04, 2009 8:51 AM
> To: Kevin Brown
> Cc: BioPerl List
> Subject: Re: [Bioperl-l] Other object oddities
> 
> This is definitely a reasonable issue to chase down. How to 
> do it needs
> a little care. I personally see 'seq' and think 'object', and 
> have resorted to
> 'seqstr' in my own code to hold/access just strings. FWIW, my 
> preference would
> be to have any object that has a seq object as a property 
> return objects
> when a '..._seq' accessor is called. However, the seq objects 
> themselves
> generally contain the sequence string in their seq() 
> property. We wouldn't
> want to disrupt that, but would it be worth creating an alias 
> getter/setter for
> the Seq classes seq() property called 'seqstr'? We could then count on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Fields | 4 May 17:53
Favicon
Gravatar

Re: bioperl / emboss on windows

Okay, so I assume everything works then?  I remember getting this to  
work at some point on WinXP years ago (I have since moved on to Linux/ 
Mac).

chris

On May 4, 2009, at 10:39 AM, uludag <at> ebi.ac.uk wrote:

>
> It looks like EMBOSS was disabled in Bio\Factory\EMBOSS.pm for Windows
> platform. After commenting out the related condition in the  
> _program_list
> function (as shown below) i don't get the "Application [needle] is not
> available" error any more.
>
>    if( #$^O =~ /MSWIN/i ||
>
> Regards,
> Mahmut
>
>
>> I have installed the bioperl and emboss on my* windows xp*, as  
>> guided on
>> the web. But it
>> --------------------- WARNING ---------------------
>> *MSG: Application [needle] is not available!*
>> ---------------------------------------------------
>>
>>
>> use warnings;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chris Fields | 4 May 18:04
Favicon
Gravatar

Re: Other object oddities

On May 4, 2009, at 10:31 AM, Kevin Brown wrote:

> I don't mind that Bio::Seq uses seq to return a string. In fact I  
> prefer
> that. Just would be nice if other objects obeyed the same convention.
> Bio::SeqFeature::Generic returns an object for both entire_seq and  
> seq,
> but uses attach_seq to store the Bio::Seq object into the Feature.

I think most of these are legacy issues that (for the most part) have  
just been dealt with ('they just work'), and with the thought that  
changing things breaks legacy code.  I agree with you, though; it's a  
good time to rethink how we're naming methods, work towards some  
consistency, and possibly do this for the next significant release.  I  
don't want to fall into the trap that perl 5.x had fallen into (and is  
working towards digging out of), namely fear of breaking old code.

> Maybe SeqFeature could be adjusted so that ->seq returns the sequence
> string of the feature (just like Bio::Seq) and ->feature_seq returns  
> the
> Bio::Seq object.

That would be a significant API change and would be inconsistent with  
seq() in other classes returning a Bio::Seq.  Not that it's any  
different than some of the current behavior, but if we want to correct  
this it should be done in a *consistent*, well-defined way.

My thoughts:

To me, seq() should always return a Bio::PrimarySeqI (derived from
(Continue reading)

Permalink | Reply | 1 comment |

Gmane