headers
Dave Messina | 1 Feb 14:47
Picon
Picon
Favicon

Re: trunk version vs. branch version

I would think we'd want to set trunk to 1.006001 -- right past 1.6 --
because
- it needs to be >1.6
- it works for the other distros which need to be set to require something
after 1.6.0

BUT
- it won't be >1.6.1 (i.e. 1.006100, I think), which is likely to be the
next release

I'm presuming that it might be problematic to have trunk at or close to 1.7
and then bump all the requirements backwards to make them work with the
1.6.x releases.

But perhaps there are compelling reasons to make the trunk version peri-1.7?
If so, I'd still argue for something like 1.006900 so we have room for
1.7-alpha releases that are <1.00700, similar to what you did for the
1.6-alphas.

Dave
Permalink | Reply | 4 comments |
headers
Martin Senger | 2 Feb 02:20
Picon

Re: Need some bioperl-run tests

> I have also noticed that Pise.t and AnalysisFactory_soap.t tests are
> failing.  I have updated the tests so they run to completion, but (if
> possible) I need some indication whether these web services are still
> available

The AnalysisFactory_soap could be used to access various tools - but the
primary target was EMBOSS tools running at EBI. The software providing them
at EBI - the Soaplab wrapper - went to its second version (Soaplab2), and
even though it is still possible to provide backward compatible services, I
am not sure that these old (Soaplab1) services are still maintained at EBI
(I am cc-ing this to Mahmut who would be the best person to know).

Martin

--

-- 
Martin Senger
email: martin.senger <at> gmail.com,m.senger <at> cgiar.org
skype: martinsenger
Permalink | Reply | 0 comments |
headers
Chris Fields | 2 Feb 17:30
Favicon
Gravatar

Re: trunk version vs. branch version

On Feb 1, 2009, at 7:47 AM, Dave Messina wrote:

> I would think we'd want to set trunk to 1.006001 -- right past 1.6 --
> because
> - it needs to be >1.6
> - it works for the other distros which need to be set to require  
> something
> after 1.6.0
>
> BUT
> - it won't be >1.6.1 (i.e. 1.006100, I think), which is likely to be  
> the
> next release

(Actually, that would be 1.6.100, or the 100th point release, if we  
stick to using numeric version nomenclature.  The vstring version  
v1.6.1 would be 1.006001.  But I see your point.)

The reason I bring this up is simple semantics: we need a way to  
distinguish main trunk from the 1.6 branch for developers.  bioperl- 
live's VERSION should always be ahead of any CPAN releases so we can  
add in a 'use Bio::Root::Foo #.######'  if we want to indicate whether  
one should use the latest code (trunk) vs. latest release.

One possiblity: we could have trunk's VERSION follow directly after  
the latest CPAN release as an alpha, so it would be 1.006000_001.  If  
we decide that an alpha is necessary for 1.6.1, we release  
1.006000_001 and increment trunk to 1.006000_002, otherwise we would  
release 1.006001 and trunk would increment to 1.006001_001.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Mark A. Jensen | 2 Feb 17:25
Picon
Favicon
Gravatar

little wiki bug?

Folks-
Is the <perl>...</perl> tag processing within our purview? I was looking closely and 
noticed that an expression like

 for (0..$#a) { print $a[$_]; }

will display 

 #a { print $a[$_]; }

formatted as a comment. 

cheers, 
MAJ
Permalink | Reply | 3 comments |
headers
Chris Fields | 2 Feb 17:40
Favicon
Gravatar

Re: [ANNOUNCEMENT] Alpha 1.6 releases of BioPerl-db

So, for this particular test, should it pass with either an empty  
string or undef?  It apparently works for all other tests.

chris

On Jan 30, 2009, at 11:13 AM, Hilmar Lapp wrote:

> I think this has something to do with the database connection  
> configuration file (t/DBHarness.conf). I suspect in your version it  
> sets 'port' to an empty string, rather than not setting it at all,  
> or setting it explicitly to undef.
>
> The test that's failing is one of a series of tests that verify that  
> the connection attributes can be round-tripped through a DSN string.  
> Specifying 'port' in the DSN string as an empty value is illegal  
> though, so it gets left out whether it's undef or an empty string.  
> When parsed back, the port isn't found in the string and hence left  
> undef (meaning, use whatever your DBD driver thinks is the right  
> default).
>
> 	-hilmar
>
> On Jan 29, 2009, at 7:28 AM, Johann PELLET wrote:
>
>> Dear Chris,
>>
>> I have the following error on my Mac machine: (BioPerl 1.6, BioPerl- 
>> run
>> 1.6) when I try to install Bioperl-db ( biosql-1.0.1):
>>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Jason Stajich | 2 Feb 17:59
Gravatar

Re: trunk version vs. branch version

>
> Kind of what I'm thinking, which is a nicer middle ground (it is  
> pre-1.7, and is a stable target).  Anyone else?
>
Wordpress designates the main trunk as "2.8-bleeding-edge" while the  
latest stable release was 2.7.x

So pre-1.7 or some sort of 1.7 designate seems a sensible to me.

-jason

> chris
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l <at> lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l

Jason Stajich
jason <at> bioperl.org
Permalink | Reply | 0 comments |
headers
Johann PELLET | 2 Feb 18:09
Picon
Favicon

Re: [ANNOUNCEMENT] Alpha 1.6 releases of BioPerl-db


Le 2 févr. 09 à 17:40, Chris Fields a écrit :

> So, for this particular test, should it pass with either an empty  
> string or undef?  It apparently works for all other tests.
>
>
> chris
Here, my t/DBHarness.biosql.conf :
{
	'port' => '',
	'schema_sql' => ['../biosql-schema/sql/biosqldb-mysql.sql'],
	'dbname' => 'biosql',
	'host' => 'localhost',
	'database' => 'biosql',
	'password' => '****',
	'user' => '****',
	'driver' => 'Pg',
}

I have as I said this error:
>>> t/01dbadaptor.....1/23
>>> #   Failed test in t/01dbadaptor.t at line 44.
>>> #          got: undef
>>> #     expected: ''
>>> # Looks like you failed 1 test of 23.
>>> t/01dbadaptor..... Dubious, test returned 1 (wstat 256, 0x100)
>>> Failed 1/23 subtests

If I change  the postgresql port in the t/DBHarness.biosql.conf
(Continue reading)

Permalink | Reply | 1 comment |
headers
Hilmar Lapp | 2 Feb 18:45
Picon
Gravatar

Re: [ANNOUNCEMENT] Alpha 1.6 releases of BioPerl-db


On Feb 2, 2009, at 12:09 PM, Johann PELLET wrote:

> [...] Here, my t/DBHarness.biosql.conf :
> {
> 	'port' => '',

Just remove this line. Or replace '' with undef.

> [...]
> So for the first test, if the port is not empty, it's ok now. But I  
> still have other errors t02 and t09.

t09 is an expected failure (the test is TODO).

t02 seems to pass, though it looks like the #tests expected is wrong.  
Should be inspected, but is probably harmless.

	-hilmar
--

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================
Permalink | Reply | 0 comments |
headers
Hilmar Lapp | 2 Feb 18:45
Picon
Gravatar

Re: [ANNOUNCEMENT] Alpha 1.6 releases of BioPerl-db


On Feb 2, 2009, at 11:40 AM, Chris Fields wrote:

> So, for this particular test, should it pass with either an empty  
> string or undef?

It could. Though strictly speaking, setting the port to an empty  
string isn't correct. It needs to be a number or undef.

But who wants to be strict these days ...

	-hilmar

--

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================
Permalink | Reply | 2 comments |
headers
Chris Fields | 2 Feb 19:46
Favicon
Gravatar

Re: [ANNOUNCEMENT] Alpha 1.6 releases of BioPerl-db

Here are the relevant lines in bioperl-db's Build.PL that seem to be  
causing the problem.

     $config{port} = $build->prompt("Port the server is running on  
(optional, '' for none)?", $config{port});
     $config{port} = '' if $config{port} eq "''";

I have changed that to set the conf file port to undef instead  
(unquoted).  It will be in the next RC (next few days).

chris

On Feb 2, 2009, at 11:45 AM, Hilmar Lapp wrote:

>
> On Feb 2, 2009, at 11:40 AM, Chris Fields wrote:
>
>> So, for this particular test, should it pass with either an empty  
>> string or undef?
>
>
> It could. Though strictly speaking, setting the port to an empty  
> string isn't correct. It needs to be a number or undef.
>
> But who wants to be strict these days ...
>
> 	-hilmar
>
> -- 
> ===========================================================
(Continue reading)

Permalink | Reply | 1 comment |

Gmane