AcePerl

 view release on metacpan or  search on metacpan

Ace/Browser/GeneSubs.pm  view on Meta::CPAN

require Exporter;
@ISA = Exporter;

@EXPORT = qw(ENTREZ ENTREZP PROTEOME SWISSPROT PUBMED NCBI);
@EXPORT_OK = ();
%EXPORT_TAGS = ();

# Foreign URLs
use constant ENTREZ      => 'http://www.ncbi.nlm.nih.gov:80/entrez/query.fcgi?cmd=Search&db=Nucleotide&doptcmdl=GenBank&term=';
use constant ENTREZP     => 'http://www.ncbi.nlm.nih.gov:80/entrez/query.fcgi?cmd=Search&db=Protein&doptcmdl=GenPep&term=';
use constant NCBI        => 'http://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query';
use constant PROTEOME    => 'http://www.proteome.com/WormPD/';
use constant SWISSPROT   => 'http://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?db=p&form=1&field=Sequence+ID&term=';
use constant PUBMED      => 'http://www.ncbi.nlm.nih.gov/htbin-post/Entrez/query?db=m&form=4&term=nematode [ORGANISM]+AND+';

1;

Ace/Local.pm  view on Meta::CPAN

      $self->{'status'} = STATUS_ERROR;
      return;
    }

    # check for prompt

    # The following checks were implemented using regexps and $' and
    # friends.  I have changed this to use {r}index and substr (a)
    # because they're much faster than regexps and (b) because using
    # $' and $` causes all regexps in a program to execute
    # very slowly due to excessive and unnecessary pre/post-match
    # copying -- tim.cutts@incyte.com 08 Sep 1999

    # Note, don't need to search the whole buffer for the prompt;
    # just need to search the new data and the prompt length from
    # any previous data.

    $searchfrom = ($len <= $plen) ? 0 : ($len - $plen);

    if (($pos = index($self->{'buffer'},
		      $self->{'prompt'},

Makefile.PL  view on Meta::CPAN

it under the same terms as Perl itself.  See DISCLAIMER.txt for
disclaimers of warranty.

=cut


END
  close F;

  eval <<END;
sub MY::postamble {
'
install-browser :
	util/install.pl acebrowser/htdocs $html_path
	util/install.pl acebrowser/cgi-bin $cgi_path
	util/install.pl acebrowser/conf $conf_path
	mkdir $html_path/images
	chmod go+rwx $html_path/images
';
}
END

RPC/Makefile.PL  view on Meta::CPAN

	      'VERSION_FROM' => 'RPC.pm', # finds $VERSION
	      'DEFINE'	     => '',
	      'MYEXTLIB'     => '../acelib/libaceperl.a',
	      'LIBS'         => ['-lc'],
	      'OBJECT'       => '$(O_FILES)',
	      'XSPROTOARG'   => '-noprototypes',
	      'XS'           => { 'RPC.xs'  => 'RPC.c' },
	      'INC'	     => "-I$headers",
);

sub MY::postamble {
    my $definition = guess_definition();
    warn "Using $definition definitions to build ace library.\n";
"
\$(MYEXTLIB): ../acelib/Makefile
	cd ../acelib && \$(MAKE) ACEDB_MACHINE=$definition all
";
}

sub guess_definition {
    return $ENV{ACEDB_MACHINE} if $ENV{ACEDB_MACHINE};

docs/GFF_Spec.html  view on Meta::CPAN

additional information, as described above under [group].  But the
sentiment of this paragraph still applies - don't overuse the
tag-value syntax. The use of tag-value pairs (with whitespace) renders problematic the parsing of
Version 1 style comments (following the group field, without a '#' character), so in Version 2,
such [group] trailing comments <B>must</B> start with the "#", as noted above.

<A NAME="meta_info"><h4> ## comment lines for meta information </h4>

There is a set of standardised (i.e. parsable) ## line types that can
be used optionally at the top of a gff file.  The philosophy is a
little like the special set of %% lines at the top of postscript
files, used for example to give the BoundingBox for EPS files.<P>

Current proposed ## lines are:

<dl>

  <dt><pre> ##gff-version 1 </pre>
  <dd> GFF version - in case it is a real success and we want to
change it.  The current version is 2. (<b>Version 2 change</b>!)

docs/GFF_Spec.html  view on Meta::CPAN

 <li> Integrated gene parsing. Several GFF files from different
researchers can be combined to provide the features used by an
integrated genefinder.  As mentioned above, this has the advantage
that different combinations of sensors and dynamic programming methods
for assembling sensor scores into consistent gene parses can be easily
explored.<P>

 <li> Reporting final predictions. GFF format can also be used to
communicate finished gene predictions. One simply reports final
predicted exons and other predicted gene features, either with their
original scores. or with some sort of posterior scores, rather than,
or in addition to, reporting all candidate gene features with their
scores.  To show that a set of the components belong to a single
prediction, a "group" field can be added to all the accepted sites.
This is useful for comparing the outputs of several integrated
genefinders among themselves, and to "confirmed" GFF files.  A
particular advantage of having the same format for both raw sensor
feature score files and final gene parse files is that one can easily
explore the possibility of combining the final gene parses from
several different genefinders, using another round of dynamic
programming, into a single integrated predicted parse.<P>