Hi Brian
I am trying to get my servers working with Omnigene and the Ensembl viewer
and all the other DAS viewers out there.
Can someone Copy and Paste a typical output from querying the server:
say chr1 at postion 10000 to 20000.
Thanks
Foo
From hyyuan@gate.sinica.edu.tw Fri May 10 04:37:03 2002
From: hyyuan@gate.sinica.edu.tw (=?big5?B?pHCmdA==?=)
Date: Fri, 10 May 2002 11:37:03 +0800
Subject: [DAS] how to retrieve gene name on das server?
Message-ID: <003601c1f7d3$f39f2d60$0103a8c0@HOUSTON>
This is a multi-part message in MIME format.
------=_NextPart_000_0033_01C1F817.019F2DF0
Content-Type: text/plain;
charset="big5"
Content-Transfer-Encoding: quoted-printable
I am new in DAS..
I tried some example to query dazzle server..
I have a question?
If I want to retrieve a list of gene names in some specified region(for =
example chr1,1:100000)
how to do it..
Does DAS can provide these kinds of quries.
retrieve a lists of gene name in a region?
or retrieve a lists of protein name in a region?
or the main problem is I should try=20
another DAS server..
I am a little confused about which das server provide what queries?
thank you
Hsiang-yu
Institute of Biomedical Science
Academia Sinica
------=_NextPart_000_0033_01C1F817.019F2DF0
Content-Type: text/html;
charset="big5"
Content-Transfer-Encoding: quoted-printable
I am new in DAS..
I tried some example to query dazzle =
server..
I have a question?
If I want to retrieve a list of gene names in some =
specified=20
region(for example chr1,1:100000)
how to do it..
Does DAS can provide these kinds of =
quries.
retrieve a lists of gene name in a =
region?
or retrieve a lists of protein name in a =
region?
or the main problem is I should try
another DAS server..
I am a little confused about which das server =
provide what=20
queries?
thank you
&nbs=
p; =
; =
=20
Hsiang-yu
&nbs=
p; =
; =
=20
Institute of Biomedical Science
&nbs=
p; =
; =
=20
Academia Sinica
------=_NextPart_000_0033_01C1F817.019F2DF0--
From FCheung@tigr.org Fri May 10 15:13:49 2002
From: FCheung@tigr.org (Cheung, Foo)
Date: Fri, 10 May 2002 10:13:49 -0400
Subject: [DAS] RE:
Message-ID:
I manage to get it sort of working.
Foo
woo hoo!
-----Original Message-----
From: Cheung, Foo
To: 'gilmanb@harpo.wi.mit.edu '
Cc: 'das@biodas.org '
Sent: 5/9/02 10:55 AM
Hi Brian
I am trying to get my servers working with Omnigene and the Ensembl
viewer and all the other DAS viewers out there.
Can someone Copy and Paste a typical output from querying the server:
say chr1 at postion 10000 to 20000.
Thanks
Foo
From avc@sanger.ac.uk Mon May 13 19:40:30 2002
From: avc@sanger.ac.uk (Tony Cox)
Date: Mon, 13 May 2002 19:40:30 +0100 (BST)
Subject: [DAS] Re: "detailed view" das view problem
In-Reply-To:
Message-ID:
On 13 May 2002, Frank R Visser wrote:
Hi Frank,
This is a tricky one. Most of the contig code will do selects on features that
fall entrirely within the bounds of the region you are looking at. There are
areas of the code that have been optimised so that partial or overlapping
features are returned. One often gets into horrible situations where one has to
"walk" outwards from the viewable region to try and catch incomplete features,
but then you run into the problems of how far do you walk to find a feature that
may or may not be there? Yuck.
I'm not sure what the DAS spec says on this point...ah here it is:
"Annotation servers are only required to return annotations which are completely
contained within the indicated segment. Servers may also return annotations
which overlap the segment, but are not completely contained within
them."
...which I guess means you can do what you like to be OK with the spec and is
therefore both a feature and a bug ;-)
You should however be able to get features that completely overlap the viewable
region. Do you noe see these? I think we need to look at how the features are
selected and see if we can catch these things.
Tony
+>Hello,
+>
+>I have a problem with the "Detailed View" viewer. If I zoom in on a feature,
+>and
+>the begin point of the feature falls out of the window, the feature disappears.
+>As an example, switching on the DAS NCBI GenomeScan feature, this URL shows the
+>a feature:
+>
+>http://www.ensembl.org/Homo_sapiens/contigview?chr=2&vc_start=39675358
+>
+>but this URL, which should show a small part of the feature, does not:
+>
+>http://www.ensembl.org/Homo_sapiens/contigview?highlight=&chr=2&vc_start=3963535
+>9&vc_end=39670000&x=31&y=15
+>
+>It even explicitly states that there are no such features in the
+>region which is wrong. This is causing problems for me because I am
+>being asked to publish, using DAS, several large areas, which are (a
+>lot) bigger than 1MB and therefore are almost always invisible.
+>
+>Is this done by design or is this a bug? If this is not a bug, what is
+>the reason for it?
+>
+>Txh for any feedback,
+>
+>Frank
+>
+>
******************************************************
Tony Cox Email:avc@sanger.ac.uk
Sanger Institute WWW:www.sanger.ac.uk
Wellcome Trust Genome Campus Webmaster
Hinxton Tel: +44 1223 834244
Cambs. CB10 1SA Fax: +44 1223 494919
******************************************************
From td2@sanger.ac.uk Mon May 13 20:01:22 2002
From: td2@sanger.ac.uk (Thomas Down)
Date: Mon, 13 May 2002 20:01:22 +0100
Subject: [DAS] Re: "detailed view" das view problem
In-Reply-To: ; from avc@sanger.ac.uk on Mon, May 13, 2002 at 07:40:30PM +0100
References:
Message-ID: <20020513200121.B604@adnah.sanger.ac.uk>
On Mon, May 13, 2002 at 07:40:30PM +0100, Tony Cox wrote:
>
> I'm not sure what the DAS spec says on this point...ah here it is:
>
> "Annotation servers are only required to return annotations which are completely
> contained within the indicated segment. Servers may also return annotations
> which overlap the segment, but are not completely contained within
> them."
>
> ...which I guess means you can do what you like to be OK with the spec and is
> therefore both a feature and a bug ;-)
>
> You should however be able to get features that completely overlap the viewable
> region. Do you noe see these? I think we need to look at how the features are
> selected and see if we can catch these things.
Hmmm, this is news to me. Hmmm . This clause seems to have been added between versions 0.9971
and 1.0 of the specification. I read previous versions as implying
`overlaps' semantics.
Is there any reason why the specifications allow `contains' semantics
as a valid alternative? It seems to make client developers' life a lot
harder. Are there any cases where it makes life substantially easier
for server developers? How many current server implementations are
actually taking advantage of this flexibility?
Thomas.
From matthew_pocock@yahoo.co.uk Mon May 13 19:54:49 2002
From: matthew_pocock@yahoo.co.uk (Matthew Pocock)
Date: Mon, 13 May 2002 19:54:49 +0100
Subject: [DAS] Re: "detailed view" das view problem
References:
Message-ID: <3CE00BF9.5000703@yahoo.co.uk>
Hi.
Is there a rationalle for only guaranteeing to return features entirely
contained by a region, rather than returning all features overlapping
the range? In principle you could have features that have one end in
your viewer region and another end at one/other end of the chromsome
being viewed. This should realy be pulled down but in the 'must be
contained' case is only pulled down when you fetch the whole chromosome.
Assuming feature a and b have a start and end property, the overlaps
query is quite easy to express:
a overlaps b iff not (
a.end < b.start || a.start > b.end
)
Matthew
Tony Cox wrote:
> On 13 May 2002, Frank R Visser wrote:
>
> Hi Frank,
>
> This is a tricky one. Most of the contig code will do selects on features that
> fall entrirely within the bounds of the region you are looking at. There are
> areas of the code that have been optimised so that partial or overlapping
> features are returned. One often gets into horrible situations where one has to
> "walk" outwards from the viewable region to try and catch incomplete features,
> but then you run into the problems of how far do you walk to find a feature that
> may or may not be there? Yuck.
>
> I'm not sure what the DAS spec says on this point...ah here it is:
>
> "Annotation servers are only required to return annotations which are completely
> contained within the indicated segment. Servers may also return annotations
> which overlap the segment, but are not completely contained within
> them."
>
> ...which I guess means you can do what you like to be OK with the spec and is
> therefore both a feature and a bug ;-)
>
> You should however be able to get features that completely overlap the viewable
> region. Do you noe see these? I think we need to look at how the features are
> selected and see if we can catch these things.
>
>
> Tony
>
>
>
> +>Hello,
> +>
> +>I have a problem with the "Detailed View" viewer. If I zoom in on a feature,
> +>and
> +>the begin point of the feature falls out of the window, the feature disappears.
> +>As an example, switching on the DAS NCBI GenomeScan feature, this URL shows the
> +>a feature:
> +>
> +>http://www.ensembl.org/Homo_sapiens/contigview?chr=2&vc_start=39675358
> +>
> +>but this URL, which should show a small part of the feature, does not:
> +>
> +>http://www.ensembl.org/Homo_sapiens/contigview?highlight=&chr=2&vc_start=3963535
> +>9&vc_end=39670000&x=31&y=15
> +>
> +>It even explicitly states that there are no such features in the
> +>region which is wrong. This is causing problems for me because I am
> +>being asked to publish, using DAS, several large areas, which are (a
> +>lot) bigger than 1MB and therefore are almost always invisible.
> +>
> +>Is this done by design or is this a bug? If this is not a bug, what is
> +>the reason for it?
> +>
> +>Txh for any feedback,
> +>
> +>Frank
> +>
> +>
>
> ******************************************************
> Tony Cox Email:avc@sanger.ac.uk
> Sanger Institute WWW:www.sanger.ac.uk
> Wellcome Trust Genome Campus Webmaster
> Hinxton Tel: +44 1223 834244
> Cambs. CB10 1SA Fax: +44 1223 494919
> ******************************************************
>
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das
>
From vissef00@mh.uk.sbphrd.com Mon May 13 21:19:31 2002
From: vissef00@mh.uk.sbphrd.com (Frank R Visser)
Date: 13 May 2002 21:19:31 +0100
Subject: [DAS] Re: "detailed view" das view problem
In-Reply-To:
References:
Message-ID:
Tony Cox writes:
> On 13 May 2002, Frank R Visser wrote:
>
> I'm not sure what the DAS spec says on this point...ah here it is:
>
> "Annotation servers are only required to return annotations which are completely
> contained within the indicated segment. Servers may also return annotations
> which overlap the segment, but are not completely contained within
> them."
>
> ...which I guess means you can do what you like to be OK with the spec and is
> therefore both a feature and a bug ;-)
But, when I query my annotation server, it actually returns the
'correct' result: it says there is a feature in this region which
overlaps the actual view area. Because the features are so large they
are in chromosomal coordinates. Ensembl takes it upon itself to throw
away the result. If the annotation server does not return a result I
could understand it, but that is not the case.
So I would classify it as a bug in Ensembl: the annotation server
reports a result, the viewer decides that it is not a real hit...
>
> You should however be able to get features that completely overlap the viewable
> region. Do you noe see these? I think we need to look at how the features are
> selected and see if we can catch these things.
Nope, if the begin and end-point are outside the view region it does
not display. Just go the website and try some extended features.
From shearsey@rexagen.com Tue May 14 01:36:02 2002
From: shearsey@rexagen.com (Simon Hearsey)
Date: Mon, 13 May 2002 17:36:02 -0700
Subject: [DAS] 1 Mb detailed view limit
Message-ID: <54B85DDA23FB8D46AB78596A5B367D540F4FDC@canal2.regulomecorp.com>
Is there a way to change the limit on the Contigview so that it will display more than 1 megabace? I'm running an Ensembl server and a DAS (using tomcat4) server. I get the "Detailed view is not available for the current 2.1 Mb view." type message if I try to display features for a region greater that 1 Mb.
Thanks,
Simon Hearsey
From avc@sanger.ac.uk Tue May 14 08:44:53 2002
From: avc@sanger.ac.uk (Tony Cox)
Date: Tue, 14 May 2002 08:44:53 +0100 (BST)
Subject: [DAS] 1 Mb detailed view limit
In-Reply-To: <54B85DDA23FB8D46AB78596A5B367D540F4FDC@canal2.regulomecorp.com>
Message-ID:
On Mon, 13 May 2002, Simon Hearsey wrote:
Dear Simon,
+>Is there a way to change the limit on the Contigview so that it will display
+>more than 1 megabace? I'm running an Ensembl server and a DAS (using
+>tomcat4) server.
my condolences ;)
+>I get the "Detailed view is not available for the current
+>2.1 Mb view." type message if I try to display features for a region greater
+>that 1 Mb. Thanks, Simon Hearsey
This is an internal limit imposed for performance reasons at the Ensembl server
end. We could allow users to select arbitrary genome region but it could cripple
the server if somebody wanted to look at every feature on chromosome N for
instance - of course they would get bored waiting for the answer amd go off and
do the same query on a different chromosome....
...meanwhile back at the ranch we are watching servers die painful deaths.
We could review the contigview limit but in all honesty I suspect the mimit is
never going to be ideal for everybody and we have to draw a balance between the
needs of specialised uers and general performance for the masses.
Of course, the solution to this is for you to have a local Ensembl installation
where you can change the defaults to whatever you need.
regards
Tony
+>
+>
+>
+>_______________________________________________
+>DAS mailing list
+>DAS@biodas.org
+>http://biodas.org/mailman/listinfo/das
+>
******************************************************
Tony Cox Email:avc@sanger.ac.uk
Sanger Institute WWW:www.sanger.ac.uk
Wellcome Trust Genome Campus Webmaster
Hinxton Tel: +44 1223 834244
Cambs. CB10 1SA Fax: +44 1223 494919
******************************************************
From shearsey@rexagen.com Tue May 14 16:56:26 2002
From: shearsey@rexagen.com (Simon Hearsey)
Date: Tue, 14 May 2002 08:56:26 -0700
Subject: [DAS] 1 Mb detailed view limit
Message-ID: <54B85DDA23FB8D46AB78596A5B367D540F4FE3@canal2.regulomecorp.com>
Dear Tony et al,
I should have been more clear, I am running the Ensembl server locally as well as a local DAS server. I have tried, unfruitfully, to find where the configuration is that sets the limit to 1Mb. Can you point me in the direction of the code?
Thanks,
Simon
-----Original Message-----
From: Tony Cox [mailto:avc@sanger.ac.uk]
Sent: Tuesday, May 14, 2002 12:45 AM
To: Simon Hearsey
Cc: das@biodas.org
Subject: Re: [DAS] 1 Mb detailed view limit
On Mon, 13 May 2002, Simon Hearsey wrote:
Dear Simon,
+>Is there a way to change the limit on the Contigview so that it will display
+>more than 1 megabace? I'm running an Ensembl server and a DAS (using
+>tomcat4) server.
my condolences ;)
+>I get the "Detailed view is not available for the current
+>2.1 Mb view." type message if I try to display features for a region greater
+>that 1 Mb. Thanks, Simon Hearsey
This is an internal limit imposed for performance reasons at the Ensembl server
end. We could allow users to select arbitrary genome region but it could cripple
the server if somebody wanted to look at every feature on chromosome N for
instance - of course they would get bored waiting for the answer amd go off and
do the same query on a different chromosome....
...meanwhile back at the ranch we are watching servers die painful deaths.
We could review the contigview limit but in all honesty I suspect the mimit is
never going to be ideal for everybody and we have to draw a balance between the
needs of specialised uers and general performance for the masses.
Of course, the solution to this is for you to have a local Ensembl installation
where you can change the defaults to whatever you need.
regards
Tony
+>
+>
+>
+>_______________________________________________
+>DAS mailing list
+>DAS@biodas.org
+>http://biodas.org/mailman/listinfo/das
+>
******************************************************
Tony Cox Email:avc@sanger.ac.uk
Sanger Institute WWW:www.sanger.ac.uk
Wellcome Trust Genome Campus Webmaster
Hinxton Tel: +44 1223 834244
Cambs. CB10 1SA Fax: +44 1223 494919
******************************************************
From avc@sanger.ac.uk Tue May 14 17:26:32 2002
From: avc@sanger.ac.uk (Tony Cox)
Date: Tue, 14 May 2002 17:26:32 +0100 (BST)
Subject: [DAS] 1 Mb detailed view limit
In-Reply-To: <54B85DDA23FB8D46AB78596A5B367D540F4FE3@canal2.regulomecorp.com>
Message-ID:
On Tue, 14 May 2002, Simon Hearsey wrote:
+>Dear Tony et al, I should have been more clear, I am running the Ensembl
+>server locally as well as a local DAS server. I have tried, unfruitfully,
+>to find where the configuration is that sets the limit to 1Mb. Can you
+>point me in the direction of the code? Thanks, Simon
It is in the module WebUserConfig::contigviewtop ('default_vc_size')
cheers
Tony
+>
+>-----Original Message-----
+>From: Tony Cox [mailto:avc@sanger.ac.uk]
+>Sent: Tuesday, May 14, 2002 12:45 AM
+>To: Simon Hearsey
+>Cc: das@biodas.org
+>Subject: Re: [DAS] 1 Mb detailed view limit
+>
+>
+>On Mon, 13 May 2002, Simon Hearsey wrote:
+>
+>Dear Simon,
+>
+>+>Is there a way to change the limit on the Contigview so that it will display
+>+>more than 1 megabace? I'm running an Ensembl server and a DAS (using
+>+>tomcat4) server.
+>
+>my condolences ;)
+>
+>+>I get the "Detailed view is not available for the current
+>+>2.1 Mb view." type message if I try to display features for a region greater
+>+>that 1 Mb. Thanks, Simon Hearsey
+>
+>This is an internal limit imposed for performance reasons at the Ensembl server
+>end. We could allow users to select arbitrary genome region but it could cripple
+>the server if somebody wanted to look at every feature on chromosome N for
+>instance - of course they would get bored waiting for the answer amd go off and
+>do the same query on a different chromosome....
+>
+>...meanwhile back at the ranch we are watching servers die painful deaths.
+>
+>We could review the contigview limit but in all honesty I suspect the mimit is
+>never going to be ideal for everybody and we have to draw a balance between the
+>needs of specialised uers and general performance for the masses.
+>
+>Of course, the solution to this is for you to have a local Ensembl installation
+>where you can change the defaults to whatever you need.
+>
+>regards
+>
+>Tony
+>
+>+>
+>+>
+>+>
+>+>_______________________________________________
+>+>DAS mailing list
+>+>DAS@biodas.org
+>+>http://biodas.org/mailman/listinfo/das
+>+>
+>
+>******************************************************
+>Tony Cox Email:avc@sanger.ac.uk
+>Sanger Institute WWW:www.sanger.ac.uk
+>Wellcome Trust Genome Campus Webmaster
+>Hinxton Tel: +44 1223 834244
+>Cambs. CB10 1SA Fax: +44 1223 494919
+>******************************************************
+>
+>_______________________________________________
+>DAS mailing list
+>DAS@biodas.org
+>http://biodas.org/mailman/listinfo/das
+>
******************************************************
Tony Cox Email:avc@sanger.ac.uk
Sanger Institute WWW:www.sanger.ac.uk
Wellcome Trust Genome Campus Webmaster
Hinxton Tel: +44 1223 834244
Cambs. CB10 1SA Fax: +44 1223 494919
******************************************************
From lstein@cshl.org Tue May 14 18:05:39 2002
From: lstein@cshl.org (Lincoln Stein)
Date: Tue, 14 May 2002 13:05:39 -0400
Subject: [DAS] DAS2 Spec?
In-Reply-To:
References:
Message-ID: <15585.17379.638749.210578@pesto.lsjs.org>
I'm afraid not yet.
Lincoln
Schreiber, Mark writes:
> Hi -
>
> Being new to DAS I was cruising the biodas.org and noticed the RFCs for
> DAS/2. Is there a finalised specification for DAS/2?
>
> Thanks
>
> Mark
>
> Mark Schreiber
> Bioinformatics
> AgResearch Invermay
> PO Box 50034
> Mosgiel
> New Zealand
>
> PH: +64 3 489 9175
> FAX: +64 3 489 3739
>
>
>
> =======================================================================
> Attention: The information contained in this message and/or attachments
> from AgResearch Limited is intended only for the persons or entities
> to which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipients is prohibited by AgResearch
> Limited. If you have received this message in error, please notify the
> sender immediately.
> =======================================================================
>
>
>
>
>
> DAS2 Spec?
>
>
>
>
> Hi -
>
>
> Being new to DAS I was cruising the biodas.org and noticed the RFCs for DAS/2. Is there a finalised specification for DAS/2?
>
> Thanks
>
>
> Mark
>
>
> Mark Schreiber
>
>
Bioinformatics
>
>
AgResearch Invermay
>
>
PO Box 50034
>
>
Mosgiel
>
>
New Zealand
>
>
>
>
PH: +64 3 489 9175
>
>
FAX: +64 3 489 3739
>
>
>
>
>
>
>
>
> Attention: The information contained in
> this message and/or attachments from AgResearch Limited is intended only for the
> persons or entities to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or other use of,
> or taking of any action in reliance upon, this information by persons or
> entities other than the intended recipients is prohibited by AgResearch Limited.
> If you have received this message in error, please notify the sender
> immediately.
>
>
>
>
>
>
>
>
>
>
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
Positions available at my lab: see http://stein.cshl.org/#hire
========================================================================
From lstein@cshl.org Tue May 14 18:07:42 2002
From: lstein@cshl.org (Lincoln Stein)
Date: Tue, 14 May 2002 13:07:42 -0400
Subject: [DAS] Small bug in LDAS
In-Reply-To:
References:
Message-ID: <15585.17502.964500.803463@pesto.lsjs.org>
Gee, thanks!
Lincoln
Leonardo Marino-Ramirez writes:
> Dear all,
>
> I am testing the LDAS server to provide annotations from a database
> created with GMOD and I found a small bug in the das script:
>
> I was trying to interface with the Bio::DAS library and I was getting no
> dna output from the script below:
>
> #!/usr/local/bin/perl
> #
> # PROGRAM : das_tofu
> #
> # PURPOSE : Simple driver for Bio::Das get features associated with
> # a genomic region
> #
>
> use strict;
> use Bio::Das;
> use Getopt::Std;
>
> use vars qw($opt_d
> $opt_s
> $opt_e
> );
>
> getopt('dse');
>
> # contact a DAS server using the "ecoli" data source
> my $das = Bio::Das->new('http://tofu.tamu.edu/cgi-bin/das' =>
> $opt_d);
>
> # fetch a segment
> my $segment = $das->segment(-ref=>'K12',-start=>$opt_s,-stop=>$opt_e);
>
> # get features and DNA from segment
> my @features = $segment->features;
> my $dna = $segment->dna;
>
> # find out what data sources are available:
> my $db = Bio::Das->new('http://tofu.tamu.edu/cgi-bin/das');
> my @sources = $db->sources;
>
> # find out what feature types are available
> my @types = $db->types;
>
> # get the entry points
> my @entry_poitns = $db->entry_points;
>
> print "Features: @features\n";
> print "DNA: $dna\n";
> print "Sources: @sources\n";
> print "Types: @types\n";
> print "Entry points: @entry_poitns\n";
>
> I found that the error was comming from a missing ">". See the diff below:
>
> diff das /home/httpd/cgi-bin/das
> 1c1
> < #!/usr/bin/perl
> ---
> > #!/usr/local/bin/perl
> 116c116
> < print qq( ---
> > print qq(\n);
>
> I had to fix the perl path manually also.
>
> Thanks, Leonardo
>
> --
>
> ___ _/ _______________________________________________________________
> _/
> _/ _/ _/_/_/ Leonardo Marino-Ramirez lmarino@tamu.edu
> _/ _/_/ _/_/ _/ Biochemistry Department, Texas A&M University
> _/_/_/_/ _/ _/_/_/ 2128 TAMU, College Station, TX 77843-2128, USA
> _/ _/ _/ Voice: (979) 862-4055 Fax: (979) 845-9274
> ___ _/ _/ _/ ________________________________________________
>
>
>
>
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
Positions available at my lab: see http://stein.cshl.org/#hire
========================================================================
From lstein@cshl.org Tue May 14 18:07:07 2002
From: lstein@cshl.org (Lincoln Stein)
Date: Tue, 14 May 2002 13:07:07 -0400
Subject: [DAS] Re: "detailed view" das view problem
In-Reply-To: <20020513200121.B604@adnah.sanger.ac.uk>
References:
<20020513200121.B604@adnah.sanger.ac.uk>
Message-ID: <15585.17467.53213.153535@pesto.lsjs.org>
I thought that clause was put in at your (Thomas's) request!!!!
Lincoln
Thomas Down writes:
> On Mon, May 13, 2002 at 07:40:30PM +0100, Tony Cox wrote:
> >
> > I'm not sure what the DAS spec says on this point...ah here it is:
> >
> > "Annotation servers are only required to return annotations which are completely
> > contained within the indicated segment. Servers may also return annotations
> > which overlap the segment, but are not completely contained within
> > them."
> >
> > ...which I guess means you can do what you like to be OK with the spec and is
> > therefore both a feature and a bug ;-)
> >
> > You should however be able to get features that completely overlap the viewable
> > region. Do you noe see these? I think we need to look at how the features are
> > selected and see if we can catch these things.
>
> Hmmm, this is news to me. Hmmm spec>. This clause seems to have been added between versions 0.9971
> and 1.0 of the specification. I read previous versions as implying
> `overlaps' semantics.
>
> Is there any reason why the specifications allow `contains' semantics
> as a valid alternative? It seems to make client developers' life a lot
> harder. Are there any cases where it makes life substantially easier
> for server developers? How many current server implementations are
> actually taking advantage of this flexibility?
>
> Thomas.
>
>
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
Positions available at my lab: see http://stein.cshl.org/#hire
========================================================================
From roadhouse@inorbit.com Fri May 17 01:08:28 2002
From: roadhouse@inorbit.com (Wild Cats)
Date: Thu, 16 May 2002 19:08:28 -0500
Subject: [DAS] Call me 59786
Message-ID: <20020517000828.17341.qmail@mail.com>
Hello I am your hot lil horny toy.
I am the one you dream About,
I am a very open minded person,
Love to talk about and any subject.
Fantasy is my way of life,
Ultimate in sex play.
Ummmmmmmmmmmmmm
I am Wet and ready for you.
It is not your looks but your imagination that matters most,
With My sexy voice I can make your dream come true...
Hurry Up! call me let me Cummmmm for you..........................
TOLL-FREE: 1-877-451-TEEN (1-877-451-8336)
For phone billing: 1-900-993-2582
--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
From calf@adexec.com Fri May 17 01:08:36 2002
From: calf@adexec.com (Wild Cats)
Date: Thu, 16 May 2002 19:08:36 -0500
Subject: [DAS] Call me 86099
Message-ID: <20020517000836.18561.qmail@mail.com>
Hello I am your hot lil horny toy.
I am the one you dream About,
I am a very open minded person,
Love to talk about and any subject.
Fantasy is my way of life,
Ultimate in sex play.
Ummmmmmmmmmmmmm
I am Wet and ready for you.
It is not your looks but your imagination that matters most,
With My sexy voice I can make your dream come true...
Hurry Up! call me let me Cummmmm for you..........................
TOLL-FREE: 1-877-451-TEEN (1-877-451-8336)
For phone billing: 1-900-993-2582
--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup
From sameeze4us@yahoo.com Fri May 17 06:43:01 2002
From: sameeze4us@yahoo.com (DR SAM EZE)
Date: Fri, 17 May 2002 05:43:01
Subject: [DAS] very ugent
Message-ID: <200205170444.g4H4iNdo000379@pw600a.bioperl.org>
Dear Sir,
I AM MAKING THIS CONTACT WITH YOU IN GOODFAITH. I GOT YOUR EMAIL ADRESS FROM THE FORIEGN DEPARTMENT IN OUR MINISTRY OF FOREIGN AFFAIRS OFFICE. I AM WORKING WITH THE STANDARD TRUST BANK LIMITED, APAPA BRANCH LAGOS. MY PURPOSE OF WRITING YOU IS TO ASK FOR YOUR
ASSISTANCE TO PROVIDE YOUR BANK ACCOUNT WHERE I CAN SUCCESSFULLY SECURE THE SUM OF $10.5 MILLION (TEN MILLION FIVE HUNDRED THOUSAND UNITED STATES DOLLARS) FOR YOUR INFORMATION, THERE IS ONE JAPANESE BUSINESS MERCHANT BASED HERE IN NIGERIA AND HIS NAME IS TOSHIO KUZITO HE IS THE OWNER OF KUZITO FISHERIES NIG. LTD, LOCATED AT NO125 INDUSTRIAL ZONE , OSHODI/APAPA EXPRESSWAY, ISOLO HERE IN LAGOS.
THIS MAN DIED IN A PLANE CRASH IN 1999 TOGETHER WITH HIS WIFE AND 3 CHILDREN. HE IS BANKING WITH MY BANK AND I'M HIS ACCOUNTING OFFICER. HOWEVER,SINCE THE DEATH OF MR TOSHIO, I HAVE BEEN TRYING TO CONTACT ANY OF HIS RELATION IN THE CITY OF OSAKA, HIS HOME COUNTRY THROUGH HIS ADDRESS WITH ME, TO LET HIS PEOPLE KNOW ABOUT HIS MONEY IN OUR BANK BUT I DID NOT RECIEVE ANY RESPONSE. NOW I HAVE DECIDED TO LINK ANYBODY TO STAND AS THE NEXT OF KIN TO MR
TOSHIO IN OTHER TO CLAIM THE MONEY.
NOTE THAT THERE IS NO RISK INVOLVED IN THIS TRANSACTION ATALL AS I WILL GIVE EVERY INFORMATION ABOUT MR TOSHIO AND ALL HIS BANKING RELATION WITH US. THIS TRANSACTION WILL GO THROUGH NORMAL BANKING PROCESS ONLY THAT YOU HAVE TO STAND FIRM AS THE NEXT
OF KIN TO MR TOSHIO JUST TO CLAIM THIS MONEY. I WILL DIRECT YOU ON HOW TO APPLY FOR THE CLAIM OF THIS MONEY.PLEASE IF YOU ARE INTERESTED AND CAPABLE TO CARRY OUT THIS DEAL WITH ME, SEND ME YOUR FULL BANK DETAILS WHERE THIS MONEY WILL BE TRANSFERED AND ALSO
GIVE ME YOUR MOBILE PHONE AND FAX NUMBERS OR ANY PHONE NUMBER I CAN REACH YOU DIRECTLY.
NOTE THAT WE CAN CONCLUDE THIS DEAL WITHIN 2 WEEK YOU APPLIED FOR THE CLAIM. I HAVE DECIDED TO SHARE THE MONEY EQUAL WITH YOU PROVIDED YOU WILL GIVE ME ALL THE
ASSITANCE NEEDED.
I'M WAITING FOR YOUR URGENT RESPONSE.
BEST REGARDS,
Dr. sam eze
From sac@bioperl.org Sat May 18 03:20:41 2002
From: sac@bioperl.org (Steve Chervitz)
Date: Fri, 17 May 2002 19:20:41 -0700 (PDT)
Subject: [DAS] mysql.sock trouble
Message-ID: <20020518022041.16450.qmail@web13702.mail.yahoo.com>
DAS folks,
This may be more of a mysql issue than a DAS issue, and is more of an FYI since
I have a mostly satisfactory resolution, but I was getting a connection error
when using the ldas_load.pl script:
$ ldas_load.pl --create --database dicty test.das
DBI->connect(dicty) failed: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (111) at
/nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/caching_handle.pm
line 140
------------- EXCEPTION: Bio::Root::Exception -------------
MSG: Can't connect to database: Can't connect to local MySQL server through
socket '/tmp/mysql.sock' (111)
STACK: Error::throw
STACK: Bio::Root::Root::throw
/nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/Root/Root.pm:315
STACK: Bio::DB::GFF::Adaptor::dbi::caching_handle::new
/nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/caching_handle.pm:90
STACK: Bio::DB::GFF::Adaptor::dbi::new
/nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi.pm:74
STACK: Bio::DB::GFF::Adaptor::dbi::mysql::new
/nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/mysql.pm:253
STACK: Bio::DB::GFF::Adaptor::dbi::mysqlopt::new
/nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/mysqlopt.pm:149
STACK: Bio::DB::GFF::new
/nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF.pm:550
STACK: /usr/local/bin/ldas_load.pl:50
-----------------------------------------------------------
I could succesfully connect to the dicty database using mysql on the
command-line, so my mysql setup appeared OK.
My /tmp/mysql.sock was apparently defunct, probably from an old mysql install
that I did over a year ago. The real socket from the latest mysql installation
was at /var/lib/mysql/mysql.sock and wasn't been recognized. I tried deleting
/tmp/mysql.sock and re-installing LDasServer, but still no go.
Problem was solved by restarting mysqld with --socket=/tmp/mysql.sock
This however created another annoyance in that the mysqladmin now requires that
I specify the --socket, since it defaults to /var/lib/mysql/mysql.sock.
So it seems I have to use /tmp/mysql.sock to appease the LDasServer, but it
complicates my mysql installation. Any suggestions from the mysql jocks out
there?
Here's my version info:
mysqladmin Ver 8.23 Distrib 3.23.49a, for pc-linux-gnu on i686
Steve
=====
Steve Chervitz
sac@bioperl.org
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
From marino@tofu.tamu.edu Sat May 18 05:01:07 2002
From: marino@tofu.tamu.edu (Leonardo Marino-Ramirez)
Date: Fri, 17 May 2002 23:01:07 -0500 (CDT)
Subject: [DAS] mysql.sock trouble
In-Reply-To: <20020518022041.16450.qmail@web13702.mail.yahoo.com>
Message-ID:
Steve,
I think that I found something that could be useful to you:
http://www.mysql.com/doc/C/a/Can_not_connect_to_server.html and
http://www.mysql.com/doc/P/r/Problems_with_mysql.sock.html
in synthesis you can try to symlink it: "ln -s /var/lib/mysql/mysql.sock
/tmp"
I hope it works for you.
Leonardo
On Fri, 17 May 2002, Steve Chervitz wrote:
> DAS folks,
>
> This may be more of a mysql issue than a DAS issue, and is more of an FYI since
> I have a mostly satisfactory resolution, but I was getting a connection error
> when using the ldas_load.pl script:
>
> $ ldas_load.pl --create --database dicty test.das
> DBI->connect(dicty) failed: Can't connect to local MySQL server through socket
> '/tmp/mysql.sock' (111) at
> /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/caching_handle.pm
> line 140
> ------------- EXCEPTION: Bio::Root::Exception -------------
> MSG: Can't connect to database: Can't connect to local MySQL server through
> socket '/tmp/mysql.sock' (111)
> STACK: Error::throw
> STACK: Bio::Root::Root::throw
> /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/Root/Root.pm:315
> STACK: Bio::DB::GFF::Adaptor::dbi::caching_handle::new
> /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/caching_handle.pm:90
> STACK: Bio::DB::GFF::Adaptor::dbi::new
> /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi.pm:74
> STACK: Bio::DB::GFF::Adaptor::dbi::mysql::new
> /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/mysql.pm:253
> STACK: Bio::DB::GFF::Adaptor::dbi::mysqlopt::new
> /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/mysqlopt.pm:149
> STACK: Bio::DB::GFF::new
> /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF.pm:550
> STACK: /usr/local/bin/ldas_load.pl:50
> -----------------------------------------------------------
>
> I could succesfully connect to the dicty database using mysql on the
> command-line, so my mysql setup appeared OK.
>
> My /tmp/mysql.sock was apparently defunct, probably from an old mysql install
> that I did over a year ago. The real socket from the latest mysql installation
> was at /var/lib/mysql/mysql.sock and wasn't been recognized. I tried deleting
> /tmp/mysql.sock and re-installing LDasServer, but still no go.
>
> Problem was solved by restarting mysqld with --socket=/tmp/mysql.sock
>
> This however created another annoyance in that the mysqladmin now requires that
> I specify the --socket, since it defaults to /var/lib/mysql/mysql.sock.
>
> So it seems I have to use /tmp/mysql.sock to appease the LDasServer, but it
> complicates my mysql installation. Any suggestions from the mysql jocks out
> there?
>
> Here's my version info:
> mysqladmin Ver 8.23 Distrib 3.23.49a, for pc-linux-gnu on i686
>
> Steve
>
>
> =====
> Steve Chervitz
> sac@bioperl.org
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das
>
--
___ _/ _______________________________________________________________
_/
_/ _/ _/_/_/ Leonardo Marino-Ramirez lmarino@tamu.edu
_/ _/_/ _/_/ _/ Biochemistry Department, Texas A&M University
_/_/_/_/ _/ _/_/_/ 2128 TAMU, College Station, TX 77843-2128, USA
_/ _/ _/ Voice: (979) 862-4055 Fax: (979) 845-9274
___ _/ _/ _/ ________________________________________________
From vastrik@ebi.ac.uk Mon May 20 09:01:20 2002
From: vastrik@ebi.ac.uk (Imre Vastrik)
Date: Mon, 20 May 2002 09:01:20 +0100
Subject: [DAS] mysql.sock trouble
References: <20020518022041.16450.qmail@web13702.mail.yahoo.com>
Message-ID: <3CE8AD50.C3820D1C@ebi.ac.uk>
Steve Chervitz wrote:
>
> My /tmp/mysql.sock was apparently defunct, probably from an old mysql install
> that I did over a year ago. The real socket from the latest mysql installation
> was at /var/lib/mysql/mysql.sock and wasn't been recognized. I tried deleting
> /tmp/mysql.sock and re-installing LDasServer, but still no go.
>
> Problem was solved by restarting mysqld with --socket=/tmp/mysql.sock
>
> This however created another annoyance in that the mysqladmin now requires that
> I specify the --socket, since it defaults to /var/lib/mysql/mysql.sock.
You could also set up an environmental variable called MYSQL_UNIX_PORT
pointing to the socket (in sh: export
MYSQL_UNIX_PORT=/tmp/my_own_mysqld.sock). If this variable is set when
starting up the daemon or client the socket it points to is going to be
used.
Another way around the situation is not to use 'localhost' as the host
when setting up the connection (either with mysql client or
programmatically via DBI) but to use the "full name" of the machine the
server is running on. This is because (if I remeber correctly) the unix
socket is used only if the host is "localhost", otherwise tcp/ip
connection to specified port (usually 3306) is used (even if the address
specified is really the same box you work on).
Rgds.,
i
From bushra@genome.wi.mit.edu Mon May 20 17:56:38 2002
From: bushra@genome.wi.mit.edu (Bushra Rehman)
Date: Mon, 20 May 2002 12:56:38 -0400
Subject: [DAS] das version
Message-ID: <3CE92AC6.D91E041A@genome.wi.mit.edu>
Hi,
I'm doing some preliminary investigation for setting up a DAS
client/server. Does anyone have an opinion as to what version would be a
good choice to use (stable, not too many bugs etc)...? Thanks, bushra
From lstein@cshl.org Mon May 20 18:51:18 2002
From: lstein@cshl.org (Lincoln Stein)
Date: Mon, 20 May 2002 13:51:18 -0400
Subject: [DAS] mysql.sock trouble
In-Reply-To:
References:
Message-ID: <0205201351180U.21774@fontina>
I think this has been addressed already (I'm reading my e-mail backwards),
but the best of all solution to is set the socket path correctly in
/etc/my.cnf:
[client]
port = 3306
socket = /var/lib/mysql/mysql.sock
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
These two stanzas tell both the client and the server to use the same socket.
Lincoln
On Saturday 18 May 2002 00:01, Leonardo Marino-Ramirez wrote:
> Steve,
>
> I think that I found something that could be useful to you:
>
> http://www.mysql.com/doc/C/a/Can_not_connect_to_server.html and
> http://www.mysql.com/doc/P/r/Problems_with_mysql.sock.html
>
> in synthesis you can try to symlink it: "ln -s /var/lib/mysql/mysql.sock
> /tmp"
>
> I hope it works for you.
>
> Leonardo
>
> On Fri, 17 May 2002, Steve Chervitz wrote:
> > DAS folks,
> >
> > This may be more of a mysql issue than a DAS issue, and is more of an FYI
> > since I have a mostly satisfactory resolution, but I was getting a
> > connection error when using the ldas_load.pl script:
> >
> > $ ldas_load.pl --create --database dicty test.das
> > DBI->connect(dicty) failed: Can't connect to local MySQL server through
> > socket '/tmp/mysql.sock' (111) at
> > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/ca
> >ching_handle.pm line 140
> > ------------- EXCEPTION: Bio::Root::Exception -------------
> > MSG: Can't connect to database: Can't connect to local MySQL server
> > through socket '/tmp/mysql.sock' (111)
> > STACK: Error::throw
> > STACK: Bio::Root::Root::throw
> > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/Root/Root.pm:315
> > STACK: Bio::DB::GFF::Adaptor::dbi::caching_handle::new
> > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/ca
> >ching_handle.pm:90 STACK: Bio::DB::GFF::Adaptor::dbi::new
> > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi.pm
> >:74 STACK: Bio::DB::GFF::Adaptor::dbi::mysql::new
> > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/my
> >sql.pm:253 STACK: Bio::DB::GFF::Adaptor::dbi::mysqlopt::new
> > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/my
> >sqlopt.pm:149 STACK: Bio::DB::GFF::new
> > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF.pm:550
> > STACK: /usr/local/bin/ldas_load.pl:50
> > -----------------------------------------------------------
> >
> > I could succesfully connect to the dicty database using mysql on the
> > command-line, so my mysql setup appeared OK.
> >
> > My /tmp/mysql.sock was apparently defunct, probably from an old mysql
> > install that I did over a year ago. The real socket from the latest mysql
> > installation was at /var/lib/mysql/mysql.sock and wasn't been recognized.
> > I tried deleting /tmp/mysql.sock and re-installing LDasServer, but still
> > no go.
> >
> > Problem was solved by restarting mysqld with --socket=/tmp/mysql.sock
> >
> > This however created another annoyance in that the mysqladmin now
> > requires that I specify the --socket, since it defaults to
> > /var/lib/mysql/mysql.sock.
> >
> > So it seems I have to use /tmp/mysql.sock to appease the LDasServer, but
> > it complicates my mysql installation. Any suggestions from the mysql
> > jocks out there?
> >
> > Here's my version info:
> > mysqladmin Ver 8.23 Distrib 3.23.49a, for pc-linux-gnu on i686
> >
> > Steve
> >
> >
> > =====
> > Steve Chervitz
> > sac@bioperl.org
> >
> > __________________________________________________
> > Do You Yahoo!?
> > LAUNCH - Your Yahoo! Music Experience
> > http://launch.yahoo.com
> > _______________________________________________
> > DAS mailing list
> > DAS@biodas.org
> > http://biodas.org/mailman/listinfo/das
From sac@bioperl.org Mon May 20 21:04:48 2002
From: sac@bioperl.org (Steve Chervitz)
Date: Mon, 20 May 2002 13:04:48 -0700 (PDT)
Subject: [DAS] mysql.sock trouble
In-Reply-To: <0205201351180U.21774@fontina>
Message-ID: <20020520200448.94163.qmail@web13708.mail.yahoo.com>
Thanks for the replies. The symlink trick works. The /etc/my.cnf file didn't
work. I stopped mysqld, created the /etc/my.cnf file, re-started mysqld, but
ldas_load.pl still throws a DBI->connect error complaining that it can't
connect via /tmp/mysql.sock. If I then create symlink and re-try, it's happy.
I also tried uninstalling and re-installing mysql (from rpms) with the
/etc/my.cnf file in place. Still no go.
Steve
--- Lincoln Stein wrote:
> I think this has been addressed already (I'm reading my e-mail backwards),
> but the best of all solution to is set the socket path correctly in
> /etc/my.cnf:
>
> [client]
> port = 3306
> socket = /var/lib/mysql/mysql.sock
>
> [mysqld]
> datadir=/var/lib/mysql
> socket=/var/lib/mysql/mysql.sock
>
> These two stanzas tell both the client and the server to use the same socket.
>
> Lincoln
>
>
>
>
> On Saturday 18 May 2002 00:01, Leonardo Marino-Ramirez wrote:
> > Steve,
> >
> > I think that I found something that could be useful to you:
> >
> > http://www.mysql.com/doc/C/a/Can_not_connect_to_server.html and
> > http://www.mysql.com/doc/P/r/Problems_with_mysql.sock.html
> >
> > in synthesis you can try to symlink it: "ln -s /var/lib/mysql/mysql.sock
> > /tmp"
> >
> > I hope it works for you.
> >
> > Leonardo
> >
> > On Fri, 17 May 2002, Steve Chervitz wrote:
> > > DAS folks,
> > >
> > > This may be more of a mysql issue than a DAS issue, and is more of an FYI
> > > since I have a mostly satisfactory resolution, but I was getting a
> > > connection error when using the ldas_load.pl script:
> > >
> > > $ ldas_load.pl --create --database dicty test.das
> > > DBI->connect(dicty) failed: Can't connect to local MySQL server through
> > > socket '/tmp/mysql.sock' (111) at
> > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/ca
> > >ching_handle.pm line 140
> > > ------------- EXCEPTION: Bio::Root::Exception -------------
> > > MSG: Can't connect to database: Can't connect to local MySQL server
> > > through socket '/tmp/mysql.sock' (111)
> > > STACK: Error::throw
> > > STACK: Bio::Root::Root::throw
> > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/Root/Root.pm:315
> > > STACK: Bio::DB::GFF::Adaptor::dbi::caching_handle::new
> > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/ca
> > >ching_handle.pm:90 STACK: Bio::DB::GFF::Adaptor::dbi::new
> > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi.pm
> > >:74 STACK: Bio::DB::GFF::Adaptor::dbi::mysql::new
> > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/my
> > >sql.pm:253 STACK: Bio::DB::GFF::Adaptor::dbi::mysqlopt::new
> > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/dbi/my
> > >sqlopt.pm:149 STACK: Bio::DB::GFF::new
> > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF.pm:550
> > > STACK: /usr/local/bin/ldas_load.pl:50
> > > -----------------------------------------------------------
> > >
> > > I could succesfully connect to the dicty database using mysql on the
> > > command-line, so my mysql setup appeared OK.
> > >
> > > My /tmp/mysql.sock was apparently defunct, probably from an old mysql
> > > install that I did over a year ago. The real socket from the latest mysql
> > > installation was at /var/lib/mysql/mysql.sock and wasn't been recognized.
> > > I tried deleting /tmp/mysql.sock and re-installing LDasServer, but still
> > > no go.
> > >
> > > Problem was solved by restarting mysqld with --socket=/tmp/mysql.sock
> > >
> > > This however created another annoyance in that the mysqladmin now
> > > requires that I specify the --socket, since it defaults to
> > > /var/lib/mysql/mysql.sock.
> > >
> > > So it seems I have to use /tmp/mysql.sock to appease the LDasServer, but
> > > it complicates my mysql installation. Any suggestions from the mysql
> > > jocks out there?
> > >
> > > Here's my version info:
> > > mysqladmin Ver 8.23 Distrib 3.23.49a, for pc-linux-gnu on i686
> > >
> > > Steve
> > >
> > >
> > > =====
> > > Steve Chervitz
> > > sac@bioperl.org
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > LAUNCH - Your Yahoo! Music Experience
> > > http://launch.yahoo.com
> > > _______________________________________________
> > > DAS mailing list
> > > DAS@biodas.org
> > > http://biodas.org/mailman/listinfo/das
> _______________________________________________
> DAS mailing list
> DAS@biodas.org
> http://biodas.org/mailman/listinfo/das
=====
Steve Chervitz
sac@bioperl.org
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
From lstein@cshl.org Mon May 20 22:14:29 2002
From: lstein@cshl.org (Lincoln Stein)
Date: Mon, 20 May 2002 17:14:29 -0400
Subject: [DAS] mysql.sock trouble
In-Reply-To: <20020520200448.94163.qmail@web13708.mail.yahoo.com>
References: <20020520200448.94163.qmail@web13708.mail.yahoo.com>
Message-ID: <0205201714292N.21774@fontina>
Urrrgh. I bet that the RedHat RPM wants my.cnf to be in
some weird place like /usr/etc.
Lincoln
On Monday 20 May 2002 16:04, Steve Chervitz wrote:
> Thanks for the replies. The symlink trick works. The /etc/my.cnf file
> didn't work. I stopped mysqld, created the /etc/my.cnf file, re-started
> mysqld, but ldas_load.pl still throws a DBI->connect error complaining that
> it can't connect via /tmp/mysql.sock. If I then create symlink and re-try,
> it's happy.
>
> I also tried uninstalling and re-installing mysql (from rpms) with the
> /etc/my.cnf file in place. Still no go.
>
> Steve
>
> --- Lincoln Stein wrote:
> > I think this has been addressed already (I'm reading my e-mail
> > backwards), but the best of all solution to is set the socket path
> > correctly in /etc/my.cnf:
> >
> > [client]
> > port = 3306
> > socket = /var/lib/mysql/mysql.sock
> >
> > [mysqld]
> > datadir=/var/lib/mysql
> > socket=/var/lib/mysql/mysql.sock
> >
> > These two stanzas tell both the client and the server to use the same
> > socket.
> >
> > Lincoln
> >
> > On Saturday 18 May 2002 00:01, Leonardo Marino-Ramirez wrote:
> > > Steve,
> > >
> > > I think that I found something that could be useful to you:
> > >
> > > http://www.mysql.com/doc/C/a/Can_not_connect_to_server.html and
> > > http://www.mysql.com/doc/P/r/Problems_with_mysql.sock.html
> > >
> > > in synthesis you can try to symlink it: "ln -s
> > > /var/lib/mysql/mysql.sock /tmp"
> > >
> > > I hope it works for you.
> > >
> > > Leonardo
> > >
> > > On Fri, 17 May 2002, Steve Chervitz wrote:
> > > > DAS folks,
> > > >
> > > > This may be more of a mysql issue than a DAS issue, and is more of an
> > > > FYI since I have a mostly satisfactory resolution, but I was getting
> > > > a connection error when using the ldas_load.pl script:
> > > >
> > > > $ ldas_load.pl --create --database dicty test.das
> > > > DBI->connect(dicty) failed: Can't connect to local MySQL server
> > > > through socket '/tmp/mysql.sock' (111) at
> > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > >i/ca ching_handle.pm line 140
> > > > ------------- EXCEPTION: Bio::Root::Exception -------------
> > > > MSG: Can't connect to database: Can't connect to local MySQL server
> > > > through socket '/tmp/mysql.sock' (111)
> > > > STACK: Error::throw
> > > > STACK: Bio::Root::Root::throw
> > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/Root/Root.pm:315
> > > > STACK: Bio::DB::GFF::Adaptor::dbi::caching_handle::new
> > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > >i/ca ching_handle.pm:90 STACK: Bio::DB::GFF::Adaptor::dbi::new
> > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > >i.pm
> > > >
> > > >:74 STACK: Bio::DB::GFF::Adaptor::dbi::mysql::new
> > > >
> > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > >i/my sql.pm:253 STACK: Bio::DB::GFF::Adaptor::dbi::mysqlopt::new
> > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > >i/my sqlopt.pm:149 STACK: Bio::DB::GFF::new
> > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF.pm:550
> > > > STACK: /usr/local/bin/ldas_load.pl:50
> > > > -----------------------------------------------------------
> > > >
> > > > I could succesfully connect to the dicty database using mysql on the
> > > > command-line, so my mysql setup appeared OK.
> > > >
> > > > My /tmp/mysql.sock was apparently defunct, probably from an old mysql
> > > > install that I did over a year ago. The real socket from the latest
> > > > mysql installation was at /var/lib/mysql/mysql.sock and wasn't been
> > > > recognized. I tried deleting /tmp/mysql.sock and re-installing
> > > > LDasServer, but still no go.
> > > >
> > > > Problem was solved by restarting mysqld with --socket=/tmp/mysql.sock
> > > >
> > > > This however created another annoyance in that the mysqladmin now
> > > > requires that I specify the --socket, since it defaults to
> > > > /var/lib/mysql/mysql.sock.
> > > >
> > > > So it seems I have to use /tmp/mysql.sock to appease the LDasServer,
> > > > but it complicates my mysql installation. Any suggestions from the
> > > > mysql jocks out there?
> > > >
> > > > Here's my version info:
> > > > mysqladmin Ver 8.23 Distrib 3.23.49a, for pc-linux-gnu on i686
> > > >
> > > > Steve
> > > >
> > > >
> > > > =====
> > > > Steve Chervitz
> > > > sac@bioperl.org
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > LAUNCH - Your Yahoo! Music Experience
> > > > http://launch.yahoo.com
> > > > _______________________________________________
> > > > DAS mailing list
> > > > DAS@biodas.org
> > > > http://biodas.org/mailman/listinfo/das
> >
> > _______________________________________________
> > DAS mailing list
> > DAS@biodas.org
> > http://biodas.org/mailman/listinfo/das
>
> =====
> Steve Chervitz
> sac@bioperl.org
>
> __________________________________________________
> Do You Yahoo!?
> LAUNCH - Your Yahoo! Music Experience
> http://launch.yahoo.com
From sac@bioperl.org Mon May 20 23:07:59 2002
From: sac@bioperl.org (Steve Chervitz)
Date: Mon, 20 May 2002 15:07:59 -0700 (PDT)
Subject: [DAS] entry_points trouble (was mysql.sock trouble)
In-Reply-To: <0205201714292N.21774@fontina>
Message-ID: <20020520220759.18061.qmail@web13703.mail.yahoo.com>
I just tried /usr/etc, but still no luck. The symlink will do.
BTW, in running through the server test in the LDasServer README, all of the
commands work as advertised with the exception of the entry_points command. I
get an empty ENTRY_POINTS element:
http://siena/cgi-bin/das/dicty/entry_points
Output from "ldasdump.pl --database dicty" looks fine, so I know data was
loaded OK.
Why might the server show no entry points?
Steve
--- Lincoln Stein wrote:
> Urrrgh. I bet that the RedHat RPM wants my.cnf to be in
> some weird place like /usr/etc.
>
> Lincoln
>
> On Monday 20 May 2002 16:04, Steve Chervitz wrote:
> > Thanks for the replies. The symlink trick works. The /etc/my.cnf file
> > didn't work. I stopped mysqld, created the /etc/my.cnf file, re-started
> > mysqld, but ldas_load.pl still throws a DBI->connect error complaining that
> > it can't connect via /tmp/mysql.sock. If I then create symlink and re-try,
> > it's happy.
> >
> > I also tried uninstalling and re-installing mysql (from rpms) with the
> > /etc/my.cnf file in place. Still no go.
> >
> > Steve
> >
> > --- Lincoln Stein wrote:
> > > I think this has been addressed already (I'm reading my e-mail
> > > backwards), but the best of all solution to is set the socket path
> > > correctly in /etc/my.cnf:
> > >
> > > [client]
> > > port = 3306
> > > socket = /var/lib/mysql/mysql.sock
> > >
> > > [mysqld]
> > > datadir=/var/lib/mysql
> > > socket=/var/lib/mysql/mysql.sock
> > >
> > > These two stanzas tell both the client and the server to use the same
> > > socket.
> > >
> > > Lincoln
> > >
> > > On Saturday 18 May 2002 00:01, Leonardo Marino-Ramirez wrote:
> > > > Steve,
> > > >
> > > > I think that I found something that could be useful to you:
> > > >
> > > > http://www.mysql.com/doc/C/a/Can_not_connect_to_server.html and
> > > > http://www.mysql.com/doc/P/r/Problems_with_mysql.sock.html
> > > >
> > > > in synthesis you can try to symlink it: "ln -s
> > > > /var/lib/mysql/mysql.sock /tmp"
> > > >
> > > > I hope it works for you.
> > > >
> > > > Leonardo
> > > >
> > > > On Fri, 17 May 2002, Steve Chervitz wrote:
> > > > > DAS folks,
> > > > >
> > > > > This may be more of a mysql issue than a DAS issue, and is more of an
> > > > > FYI since I have a mostly satisfactory resolution, but I was getting
> > > > > a connection error when using the ldas_load.pl script:
> > > > >
> > > > > $ ldas_load.pl --create --database dicty test.das
> > > > > DBI->connect(dicty) failed: Can't connect to local MySQL server
> > > > > through socket '/tmp/mysql.sock' (111) at
> > > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > > >i/ca ching_handle.pm line 140
> > > > > ------------- EXCEPTION: Bio::Root::Exception -------------
> > > > > MSG: Can't connect to database: Can't connect to local MySQL server
> > > > > through socket '/tmp/mysql.sock' (111)
> > > > > STACK: Error::throw
> > > > > STACK: Bio::Root::Root::throw
> > > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/Root/Root.pm:315
> > > > > STACK: Bio::DB::GFF::Adaptor::dbi::caching_handle::new
> > > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > > >i/ca ching_handle.pm:90 STACK: Bio::DB::GFF::Adaptor::dbi::new
> > > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > > >i.pm
> > > > >
> > > > >:74 STACK: Bio::DB::GFF::Adaptor::dbi::mysql::new
> > > > >
> > > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > > >i/my sql.pm:253 STACK: Bio::DB::GFF::Adaptor::dbi::mysqlopt::new
> > > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF/Adaptor/db
> > > > >i/my sqlopt.pm:149 STACK: Bio::DB::GFF::new
> > > > > /nfs/linux/pkg/perl/build-1/lib/site_perl/5.6.1/Bio/DB/GFF.pm:550
> > > > > STACK: /usr/local/bin/ldas_load.pl:50
> > > > > -----------------------------------------------------------
> > > > >
> > > > > I could succesfully connect to the dicty database using mysql on the
> > > > > command-line, so my mysql setup appeared OK.
> > > > >
> > > > > My /tmp/mysql.sock was apparently defunct, probably from an old mysql
> > > > > install that I did over a year ago. The real socket from the latest
> > > > > mysql installation was at /var/lib/mysql/mysql.sock and wasn't been
> > > > > recognized. I tried deleting /tmp/mysql.sock and re-installing
> > > > > LDasServer, but still no go.
> > > > >
> > > > > Problem was solved by restarting mysqld with --socket=/tmp/mysql.sock
> > > > >
> > > > > This however created another annoyance in that the mysqladmin now
> > > > > requires that I specify the --socket, since it defaults to
> > > > > /var/lib/mysql/mysql.sock.
> > > > >
> > > > > So it seems I have to use /tmp/mysql.sock to appease the LDasServer,
> > > > > but it complicates my mysql installation. Any suggestions from the
> > > > > mysql jocks out there?
> > > > >
> > > > > Here's my version info:
> > > > > mysqladmin Ver 8.23 Distrib 3.23.49a, for pc-linux-gnu on i686
> > > > >
> > > > > Steve
> > > > >
> > > > >
> > > > > =====
> > > > > Steve Chervitz
> > > > > sac@bioperl.org
> > > > >
> > > > > __________________________________________________
> > > > > Do You Yahoo!?
> > > > > LAUNCH - Your Yahoo! Music Experience
> > > > > http://launch.yahoo.com
> > > > > _______________________________________________
> > > > > DAS mailing list
> > > > > DAS@biodas.org
> > > > > http://biodas.org/mailman/listinfo/das
> > >
> > > _______________________________________________
> > > DAS mailing list
> > > DAS@biodas.org
> > > http://biodas.org/mailman/listinfo/das
> >
> > =====
> > Steve Chervitz
> > sac@bioperl.org
> >
> > __________________________________________________
> > Do You Yahoo!?
> > LAUNCH - Your Yahoo! Music Experience
> > http://launch.yahoo.com
=====
Steve Chervitz
sac@bioperl.org
__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com
From Dr. Carter"
Dear das:
You may ask yourself
> How to make people respect you
> How to win friends
> How to let your conduct help your health, work, job, career, relationships, spirit, mind, well-being, ...
> How to make your life smoother and happier
> How to do whatever you like without being unpleasant to other people
> How to develop good conduct in your children or students
> How to make the world peaceful and better
You can find all the answers to these questions, and much more, in this great handbook:
"Complete Conduct Principles for the 21st Century" by Dr. John Newton
It is the best educational GIFT idea for children, friends, relatives, classmates, students, parents, teachers, other educators, ..., particularly at this special time.
BENEFITS to each individual reader: Many! -- such as for health, work, job, career, self-improvement, education, relationships, spirit, mind, well-being, and much more -- almost all the areas that are important to you in the 21st century. People around you will benefit, too. (Please see the PREFACE of the book for details.)
EVERYONE may find this handbook useful and helpful, regardless of age (from children to oldsters), occupation, rank, status, gender, religious beliefs, nationality, country, or region.
If you are a parent or a teacher, you can learn how to develop good conduct in your children or students from this handbook. Please advise your children or students to read the book. It will result in great benefits for both you and them.
(Note: If you are interested in the issue of School Violence, Youth Problems, Violence Prevention, or Conduct Education in the 21st Century, please see the APPENDIX below.)
This book is a must for EVERYONE to be better prepared for personal conduct for the 21st century.
The book's content is obvious from its title. The complete useful conduct principles cover not only what we should do, but also what we should not do -- especially those faults people make often and easily.
This timely, unique, and very important handbook is designed to suit most people, and is self-contained and user-friendly.
This book is significantly different and better than competitive works.
Some of its innovative contents may help solve problems that Western culture cannot.
The book's merit and importance have been recognized and praised by many experts, elected public officials, and world leaders.
How to make the world peaceful and better ---
You can find the solution in the book.
Let's work together to make the world peaceful and better!
The author, John Newton, holds a Ph.D. from MIT, and does researches at Harvard. His long-term research on "The personal conduct in the human society of the 21st century" resulted in this book. It is published by Nicer Century World Organization, headquartered beside Harvard University and MIT, two leading institutes of new knowledge and literature.
The book is available in two types of binding: Hardcover (ISBN 0967370574; case bound, Smyth sewn; with dust jacket) and Paperback (ISBN 0967370582; perfect bound). Both editions are unabridged, and are printed on 60 lb, natural, acid-free, excellent and healthful paper. You can get the book from many fine on-line bookstores and traditional bookstores. For your convenience, I herewith provide you with a link directly to the book page in the shopping directory of Yahoo!, the world's No. 1 Internet directory:
http://shopping.yahoo.com/shop?d=b&id=3680641&clink=dmpr-hm/rp&cf=setup
Some bookstores there offer great discounts (for a limited time). Note that some of the bookstores may disappear there if out-of-stock. In that case, you may want to go to another bookstore. Of course, you may freely go to other bookstores at any time, even if they are not listed in Yahoo!.
Please forward this e-mail to people you know -- children, friends, relatives, classmates, students, parents, teachers, other educators, ..., because they can benefit from it, too. This can be a wonderful kindness you provide to them!
das, best wishes to you!
Sincerely yours,
Tom Carter, Ph.D.
President, Nicer Century World Organization
Massachusetts, USA
(Nicer Century World Organization is an educational, non-profit, non-partisan organization; it endeavors to make the 21st century nicer than ever before. To accomplish its mission, Nicer Century World Organization is proud to introduce this book.)
-----------------------------------------------------------
APPENDIX: School Violence, Youth Problems, Violence Prevention, and Conduct Education in the 21st Century
In recent years school violence has made many pieces of nation-shaking highlighted headline news, which have astounded the Americans. It may happen at any school, at any time, and by students of any age. Some experts believe this is the most important national crisis the U.S. is facing.
"In the 21st century the problem will happen not only continuously in the U.S. but also in lots of other countries all over the world, if we do not act." said Dr. John Newton in the late 20th century. Recent tragedies have proved this warning prediction.
"The most effective and proper way to solve the problem is appropriate conduct education." said Dr. Newton.
"The significance of the problem" is much more important than "the number of people killed in schools".
In addition to shooting and killing, other kinds of school violence, such as rape, sexual assault, aggravated assault, robbery, bullying, mugging, fighting, theft, harassment, ..., and other youth problems, like suicide, suicide attempt, suicide inclination, pessimism, sense of inferiority, lose of self-control, relationship problems, emotion problems, drug abuse, discrimination, ..., cannot be ignored, either.
Some measures may handle a few "symptoms" temporarily and partially but are not solutions for education, particularly in view of our responsibilities for the whole society.
Now an effective, proper, comprehensive, deep-rooted and permanent solution is needed!
The book, "Complete Conduct Principles for the 21st Century" by Dr. John Newton, is regarded as "the very one that can effectively help solve the problem of school violence in a right way" by some experts in education, including Dr. Steve White, who pointed out clearly: "If students, teachers and parents can learn the conduct principles in this book well, then that 'unsolvable' problem will be solved. It is not difficult at all to learn them, because the book is a simple, easy, clear, convenient and self-contained handbook, well designed to suit most people." The book was also praised as "a compendium of concisely expressed, practical, informative, pertinent, workable advice" by Michael J. Carson, a professional book reviewer.
"Unlike most books of this subject, it is NOT a religious book, nor is a collection of old conduct rules."
As analyzed in the Preface of the book, "from now on learning good conduct should be placed as No. 1 in education."
The book's merit and importance have been recognized and praised by many education experts, elected public officials, and world leaders. Some educational units, ranging from the level of nation or state to individual school or university, have ordered the book either as textbook/reference book or as an active action to prevent school violence, to improve education and to benefit students, teachers & parents.
"The book will also be effective for violence prevention for the whole society."
Hence, to prevent school violence and other violence, to improve education, and to benefit students, teachers, parents, & the whole society, I earnestly request you to inform the students, teachers, parents, school library and other relevant people you know of the availability of the book.
A reasonable method you may consider choosing is to simply forward this letter to them.
Although it will be helpful and appreciated, it is NOT necessary that you state any endorsement or the like.
Your efforts to prevent school violence and other violence, to improve education, and to benefit students, teachers, parents, & the whole society will be highly appreciated.
From scott@genome.clemson.edu Tue May 28 22:28:19 2002
From: scott@genome.clemson.edu (Scott J. Pearson)
Date: Tue, 28 May 2002 17:28:19 -0400 (EDT)
Subject: [DAS] DAS and Oracle
Message-ID:
I am trying to integrate DAS with Oracle to provide better performance
than with MySQL. Has anyone performed this integration before? If so, I
would appreciate any tips that you might provide.
Gratefully,
Scott
---
Scott J. Pearson
Clemson University Genome Institute
scott@genome.clemson.edu
From pow@ebi.ac.uk Wed May 29 10:40:52 2002
From: pow@ebi.ac.uk (Jean-Jack Riethoven)
Date: Wed, 29 May 2002 10:40:52 +0100 (BST)
Subject: [DAS] DAS and Oracle
In-Reply-To:
Message-ID:
On Tue, 28 May 2002, Scott J. Pearson wrote:
> I am trying to integrate DAS with Oracle to provide better performance
> than with MySQL. Has anyone performed this integration before? If so, I
> would appreciate any tips that you might provide.
I don't have any generic tips for you, but I did do the very minor changes
in the Dazzle code to get it to work with Oracle in stead of the default
my SQL.
>From your query I am not sure if this is what you are after (i.e.
modifying existing DAS servers to work with Oracle), but in case you are
this is what you need to do (for Dazzle).
1. Make sure Dazzle runs in an environment which is suitable for Oracle
SQL. Meaning: set the required environment variables to suit your system.
If you can run sqlplus, things should be ok.
2. Pack up the required Oracle classes into a jar file. Do not go for the
thin drivers. (some Oracle installations do not have the jar file handy,
or only the thin drivers)
3. Copy this jar file into Dazzle's WEB-INF/lib directory. (if you are
paranoid, or if more servlets use Oracle, move it into Tomcat's
/common/libs/ directory as well).
4. Modify some Java code.
4a. Ensembl-das package:
4a1: AbstractSeqFeature.java: load oracle.jdbc.driver.OracleDriver in
place of the mm.mysql one
4a2: EnsemblHolder.java: in getEnsembl function: do the same as in 4a1
4b Ensembl package:
4b1: JDBCConnectionPool.java: disable the big SQL selects option (mySQL
tweak)
5. And build + move jars to Dazzle WEB-INF/lib
6. If you are using the same table structures as Ensembl (in their mySQL
example) then you are set to go. Else, you need some tweaking in the
Abstract...Source you are using, esp. in the select statements and
following code.
That should do the trick.
We are using modifications of the RemoteGenericSeqFeatureSource plugin
together with the Abstract class (we are using Ensembl's DAS servers as
reference, but if you have them in-house you need another adaptor).
Hope this answers some questions for you, or at least gave you some leads
if you are not using Dazzle :)
With kind regards,
Drs. Jean-Jack Riethoven
EMBL Outstation - Hinxton pow@ebi.ac.uk ICQ#: 3433929
European Bioinformatics Institute Phone: (+44) 1223 494635
Wellcome Trust Genome Campus Fax : (+44) 1223 494468
Hinxton, Cambridge CB10 1SD URL : http://industry.ebi.ac.uk/
UNITED KINGDOM
From o_lyttelton@hotmail.com Fri May 31 10:58:07 2002
From: o_lyttelton@hotmail.com (Oliver Lyttelton)
Date: Fri, 31 May 2002 09:58:07 +0000
Subject: [DAS] Insanity nearing, how stupid am I being!(Retrieve feature list from das ensembl)
Message-ID:
Hello,
Really simple one but I'm crawling up the wall on account of it! I can
retrieve features from the reference server using a url such as :-
http://servlet.sanger.ac.uk:8080/das/ensembl428/features?segment=X:10,50000
but as soon as I try and get a list of features from an annotation server,
for example repeats from ens428rep, using a url like
http://servlet.sanger.ac.uk:8080/das/ens428rep/features?segment=X:10,58000
I get an empty xml document in return:-
-
-
Do I need to include more parameters or what. Please help, I've tried a lot
of combinations!
Also, testing the urls in internet explorer 6 causes the browser to crash
approximately 50% of the time. (You've gotta love microsoft...)
Thanks all for help.
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
From td2@sanger.ac.uk Fri May 31 13:06:28 2002
From: td2@sanger.ac.uk (Thomas Down)
Date: Fri, 31 May 2002 13:06:28 +0100
Subject: [DAS] Insanity nearing, how stupid am I being!(Retrieve feature list from das ensembl)
In-Reply-To: ; from o_lyttelton@hotmail.com on Fri, May 31, 2002 at 09:58:07AM +0000
References:
Message-ID: <20020531130628.B26577@adnah.sanger.ac.uk>
On Fri, May 31, 2002 at 09:58:07AM +0000, Oliver Lyttelton wrote:
> Hello,
> Really simple one but I'm crawling up the wall on account of it! I can
> retrieve features from the reference server using a url such as :-
>
> http://servlet.sanger.ac.uk:8080/das/ensembl428/features?segment=X:10,50000
>
>
> but as soon as I try and get a list of features from an annotation server,
> for example repeats from ens428rep, using a url like
>
> http://servlet.sanger.ac.uk:8080/das/ens428rep/features?segment=X:10,58000
>
> I get an empty xml document in return:-
That particular data source doesn't actually serve anything
in chromosomal coordinates. However, if you fetch features from
an individual assembly contig it will work fine:
http://servlet.sanger.ac.uk:8080/das/ens428rep/features?segment=AB019441.1.1.157090
A client should be able to discover the whole assembly structure
from the reference server -- there's a section on this in the DAS
specification. If assembly-navigation doesn't appeal to you, there
are some toolkits which will take care of it for you: for example,
the DAS package in BioJava.
> Also, testing the urls in internet explorer 6 causes the browser to crash
> approximately 50% of the time. (You've gotta love microsoft...)
*sigh* not a lot I can do to help here (other than to bingle
Mozilla a little bit). However, I do find the simple command-line
`wget' tool very useful for testing purposes.
Thomas.
From o_lyttelton@hotmail.com Fri May 31 15:39:48 2002
From: o_lyttelton@hotmail.com (Oliver Lyttelton)
Date: Fri, 31 May 2002 14:39:48 +0000
Subject: [DAS] How do you map novel sequences and retrieve local feature info?
Message-ID:
Dear all,
I want first to thank Thomas Down for his swift and illuminating answer
this morning. Unfortunately, while it has helped me delve deeper, it has not
yet taken me out of the woods.
The basic problem is that I want to automatically map short sequences
(100-600bp) which a colleague is retrieving via wet-lab experiments, onto
the human genome. I then want to retrieve a list of all interesting features
located near the sequence of interest.
NCBI offer an automated http protocol for retrieving the results of blast
queries in xml format but the problem is that their human genome database
returns hits relative to NT_XXXXXX segment numbers and these do not always
match up to the ensembl draft sequence. I need to use the ensembl blast
sequence, so that I can retrieve local features from the ensembl das
service.
The obvious answer is to use the ensembl human genome blast page which
returns hits relative to contigs on the golden path, conveniently compatible
with the das features request from the ensembl das website.
This works manually, but there doesn't appear to be any automated standard
http protocol. I could still hack it, and just manually create the required
http requests and disect the responses using RE pattern matching, but they
could change the screens without notification, and XML would be a lot nicer
than having to decode the blast_format blast results page.
I don't want to have to store a local copy of the genome assembly because
this seems like cracking an egg with a mallet, and I ain't got the disk
space....
Has anyone got any ideas?
_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com
