view release on metacpan or search on metacpan
lib/Bigtop/Parser.pm view on Meta::CPAN
returns an array reference (which is why we have to join the result
in the above skeleton). After the children have been visited, the
callback (C<output_something> in the example) is called with their output
array reference. You can also pass an additional scalar (which is usually
a hash reference) to walk_postorder. It will be passed along to all
the child walk_postorders and to the callbacks.
With this module walking the tree, all you must do is provide the appropriate
callbacks. Put one at each level of the tree that interests you.
For example, if you are generating SQL, you need to put callbacks in
at least the following packages:
table_block
table_element_block
field_statement
lib/Bigtop/Parser.pm view on Meta::CPAN
in the lib/Bigtop subdirectory of Bigtop's build directory,
for the possible packages (or grep for package on this file).
There are also several chapters of the Gantry book devoted to explaining
how to use the AST to build backends.
The callbacks are called as methods on the current tree node. They receive
the output array reference from their children and the data scalar that
was passed to walk_postorder (if one was passed in the top level call).
So, a typical callback method might look like this:
sub output_something {
lib/Bigtop/Parser.pm view on Meta::CPAN
level is the name of a block. Under that, there is a fixed keyword for
each subblock type, etc.
=back
=head2 METHODS for use in walk_postorder callbacks
=over 4
=item dumpme
view release on metacpan or search on metacpan
lib/Bio/Biblio/IO/medlinexml.pm view on Meta::CPAN
} else {
$self->throw ("XML source to be parsed is unknown. Should be given in the new().");
}
# when parsing is done all citations have already been delivered
# to the caller using her callbacks - and nothing to be stored
# here, or parser put all citations into global @Cittaions where
# we want to copy there into this instance - so any caller can
# start parsing other XML input without overwriting already read
# citations from the first parser
if (@Citations) {
view release on metacpan or search on metacpan
lib/Bio/DB/HTS/Pileup.pm view on Meta::CPAN
Bio::DB::HTS::Pileup -- Object passed to pileup() callback
=head1 SYNOPSIS
See L<Bio::DB::HTS/The generic fetch() and pileup() methods> for how
this object is passed to pileup callbacks.
=head1 DESCRIPTION
A Bio::DB::HTS::Pileup object (or a Bio::DB::HTS::PileupWrapper
object) is passed to the callback passed to the Bio::DB::HTS->pileup()
view release on metacpan or search on metacpan
bin/bp_biofetch_genbank_proxy view on Meta::CPAN
%MAPPING = (genbank => {db=>'nucleotide',
rettype => 'gb'},
genpep => {db=>'protein',
rettype => 'gp'});
# we're doing everything in callbacks, so initialize globals.
$BUFFER = '';
%GOT = ();
print header('text/plain');
view release on metacpan or search on metacpan
lib/Bio/Das/Lite.pm view on Meta::CPAN
push @{$ar_ref}, $ref;
$DEBUG and print {*STDERR} q( )x($depth*2), qq(leaving _parse_branch\n);
#########
# only perform callbacks if we're at recursion depth zero
#
if($depth == 0 && $self->{'callback'}) {
$DEBUG and print {*STDERR} q( )x($depth*2), qq(executing callback at depth $depth\n);
$ref->{'dsn'} = $dsn;
my $callback = $self->{'callback'};
lib/Bio/Das/Lite.pm view on Meta::CPAN
Constructs an arrayref of DAS requests including parameters for each call
=head2 build_requests
Constructs the WWW::Curl callbacks
=head2 postprocess
Applies processing to the result set, e.g. removal of whitespace from sequence responses.
view release on metacpan or search on metacpan
lib/Bio/DB/EUtilities.pm view on Meta::CPAN
will work for 'seekable' data.
A callback specified using callback() will be used to filter objects
for any generated iterator. This behaviour is implemented for both
normal and lazy iterator types and is the default. If you don't want
this, make sure to reset any previously set callbacks via
reset_callback() (which just deletes the code ref).
TODO : generate seekable iterators ala HOP for seekable fh data
=head2 callback
view release on metacpan or search on metacpan
lib/Bio/Graphics/Glyph/decorated_transcript.pm view on Meta::CPAN
1) Type. For example used to specify decoration source (e.g. 'SignalP40')
2) Name. Decoration name. Used as decoration label by default (e.g. 'SP' for signal peptide)
3) Start. Start coordinate at the protein-level (1-based coordinate)
4) End. End coordinate at the protein-level
5) Score. Optional. Score associated with a decoration (e.g. Pfam E-value). This score can be used
to dynamically filter or color decorations via callbacks (see glyph options).
6) Description. Optional. User-defined description of decoration. The glyph ignores this description,
but it will be made available to callback functions for inspection. Special characters
like ':' or ',' that might interfere with the GFF tag parser should be avoided.
If callback functions are used as glyph parameters (see below), the callback is called for each
lib/Bio/Graphics/Glyph/decorated_transcript.pm view on Meta::CPAN
-end => $nt_end,
-score => $score,
-desc => $desc,
-seq_id => $feature->seq_id,
-strand => $feature->strand,
-attributes => { # remember protein coordinates for callbacks
'p_start' => $p_start,
'p_end' => $p_end
}
);
lib/Bio/Graphics/Glyph/decorated_transcript.pm view on Meta::CPAN
End coordinate at the protein-level
=item 5. score
Optional. Score associated with a decoration (e.g. Pfam E-value). This score can be used
to dynamically filter or color decorations via callbacks (see glyph options).
=item 6. description
Optional. User-defined description of decoration. The glyph ignores this description,
but it will be made available to callback functions for inspection. Special characters
view release on metacpan or search on metacpan
eg/testit.pl view on Meta::CPAN
my $type = $feature->primary_tag;
$type eq 'group' ? 'dashed'
: $type eq 'transcript' ? 'hat'
: $type eq 'alignment' ? 'solid'
: undef},
-all_callbacks => 1,
-connector_color => 'black',
-height => 10,
-bump => 1,
-linewidth=>2,
# -tkcolor => $colors[rand @colors],
eg/testit.pl view on Meta::CPAN
-orient => 'N',
-height => 8,
-base => 1,
-relative_coords => 1,
-tick => 2,
-all_callbacks => 1,
-bgcolor => 'red',
-key => 'Dynamically Added');
$track->add_feature($bigone,$zed_27,$abc3);
$track->add_group($predicted_exon1,$predicted_exon2,$confirmed_exon3);
view release on metacpan or search on metacpan
contrib/roary_plots/roary_files/MathJax.js view on Meta::CPAN
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
if(document.getElementById&&document.childNodes&&document.createElement){if(!(window.MathJax&&MathJax.Hub)){if(window.MathJax){window.MathJax={AuthorConfig:window.MathJax}}else{window.MathJax={}}MathJax.isPacked=true;MathJax.version="2.5";MathJax.fil...
view release on metacpan or search on metacpan
lib/Bio/DB/Bam/Pileup.pm view on Meta::CPAN
Bio::DB::Bam::Pileup -- Object passed to pileup() callback
=head1 SYNOPSIS
See L<Bio::DB::Sam/The generic fetch() and pileup() methods> for how
this object is passed to pileup callbacks.
=head1 DESCRIPTION
A Bio::DB::Bam::Pileup object (or a Bio::DB::Bam::PileupWrapper
object) is passed to the callback passed to the Bio::DB::Sam->pileup()
view release on metacpan or search on metacpan
lib/Bio/ToolBox/db_helper/alignment_callbacks.pm view on Meta::CPAN
package Bio::ToolBox::db_helper::alignment_callbacks;
use warnings;
use strict;
use Carp;
use Bio::ToolBox::db_helper::constants;
lib/Bio/ToolBox/db_helper/alignment_callbacks.pm view on Meta::CPAN
# passed parameters as array ref
# chromosome, start, stop, strand, strandedness, method, value, db, dataset
my $param = shift;
# check the current list of calculated callbacks
# cache the calculated callback method to speed up subsequent data
# collections it's likely only one method is ever employed in an
# execution, but just in case we will cache all that we calculate
my $string = sprintf "%s_%s_%s_%d", $param->[STND], $param->[STR],
$param->[METH], $param->[RETT];
lib/Bio/ToolBox/db_helper/alignment_callbacks.pm view on Meta::CPAN
__END__
=head1 NAME
Bio::ToolBox::db_helper::alignment_callbacks
=head1 DESCRIPTION
This module provides common callback subroutines for working with bam alignments.
It is generalized and may be used with either L<Bio::DB::Sam> or L<Bio::DB::HTS>
view release on metacpan or search on metacpan
scripts/biosql/load_ontology.pl view on Meta::CPAN
# don't forget to add namespace if the parser doesn't supply one
$ont->name($namespace) unless $ont->name();
print STDERR "Loading ontology ",$ont->name(),":\n\t... terms\n";
# in order to allow callbacks to the user and generally a
# better ability to interfere with and customize the upload
# process, we load all terms first here instead of simply
# going for the relationships
foreach my $term ($ont->get_all_terms()) {
view release on metacpan or search on metacpan
t/lib/Test/Harness/Straps.pm view on Meta::CPAN
$self->_reset_file_state;
$self->{file} = $name;
my $results = Test::Harness::Results->new;
# Set them up here so callbacks can have them.
$self->{totals}{$name} = $results;
while( defined(my $line = $it->next) ) {
$self->_analyze_line($line, $results);
last if $self->{saw_bailout};
}
view release on metacpan or search on metacpan
Bio/Event/EventHandlerI.pm view on Meta::CPAN
Title : start_document
Usage : $resultObj = $parser->start_document();
Function: Receive notification of the beginning of a document (the
input file of a parser). The parser will invoke this method
only once, before any other event callbacks.
Usually, a handler will reset any internal state structures
when this method is called.
Returns : none
view release on metacpan or search on metacpan
FlipFlop.pm view on Meta::CPAN
=head2 Overview
The initial state of a flip flop is false. It has an opportunity
to change state during each call to the C<test> method.
Two callbacks are provided at flip flop construction time, C<set> and
C<reset>. One or both of these callbacks may be evaluated when the
C<test> method is called. The callbacks are evaluated in scalar context,
and their return value is interpreted as a boolean.
While false, the flip flop evaluates the C<set> callback at each call to
the C<test> method. If the C<set> callback returns a true value, the
flip flop flips state to true. While true, the flip flop evaluates the
FlipFlop.pm view on Meta::CPAN
The C<new> method creates a new Bit::FlipFlop object. A newly created
flip flop's state is always false.
The C<set> and C<reset> arguments are required. They are sub refs that
are used for callbacks to test for setting or resetting the flip flop.
C<simultaneous_edges> is an optional argument that defaults to 1
(true) if unspecified. This argument governs whether the flip flop
may look for a leading edge and trailing edge within a single call to
the C<test> method.
view release on metacpan or search on metacpan
src/boost/mpi/config.hpp view on Meta::CPAN
#endif
#if defined(MPIAPI)
# define BOOST_MPI_CALLING_CONVENTION MPIAPI
#else
/** @brief Specifies the calling convention that will be used for callbacks
* from the underlying C MPI.
*
* This is a Windows-specific macro, which will be used internally to state
* the calling convention of any function that is to be used as a callback
* from MPI. For example, the internally-defined functions that are used in
* a call to @c MPI_Op_create. This macro is likely only to be useful to
* users that wish to bypass Boost.MPI, registering their own callbacks in
* certain cases, e.g., through @c MPI_Op_create.
*/
# define BOOST_MPI_CALLING_CONVENTION
#endif
view release on metacpan or search on metacpan
lib/Bot/BasicBot.pm view on Meta::CPAN
}
sub run {
my $self = shift;
# create the callbacks to the object states
POE::Session->create(
object_states => [
$self => {
_start => "start_state",
die => "die_state",
view release on metacpan or search on metacpan
lib/Bot/ChatBots/Telegram/Guide/Tutorial.pod view on Meta::CPAN
other again take advantage of L<Mojo::IOLoop> to do something (like the
new command C</remind>).
=item *
In both callbacks passed to L<Mojo::IOLoop> we use
a L<Bot::ChatBots::Telegram::Sender> object, relying upon the same object
that C<$bcb> uses to get new updates. As already anticipated, nothing
=item *
view release on metacpan or search on metacpan
v0.41
* Fixed bug that prevented bot from running.
v0.4
* Added support for MUC join parameters in config
* Added new module callbacks: muc_join, muc_part, muc_presence, muc_subject_change
* Added some hints and code snippets and example logger module
v0.3
* Added "presence" and "part" muc callbacks
* Added check for config and essential config settings presence
v0.2
* Added multilanguage support
view release on metacpan or search on metacpan
lib/Bot/Pastebot/Server/Http.pm view on Meta::CPAN
(
(defined $conf{iface})
? ( Address => $conf{iface} )
: ()
),
# TODO - Can we use the discrete callbacks?
Acceptor => sub {
POE::Session->create(
inline_states => {
_start => \&httpd_session_started,
got_flush => \&httpd_session_flushed,
view release on metacpan or search on metacpan
examples/webhook.pl view on Meta::CPAN
}
$bot -> process_update($c -> req -> json);
};
$bot -> set_callbacks(message => sub {
my (undef, $update) = @_;
my $chat_id = $$update{message}{from}{id};
my $text = $$update{message}{text};
eval {
view release on metacpan or search on metacpan
lib/pods/Box2D/b2Body.pod view on Meta::CPAN
=over 4
=item * C<Box2D::b2Shape> C<$shape> - the shape to be cloned.
=item * C<float32> C<$density> - the shape density (set to zero for static bodies). Warning:This function is locked during callbacks.
=back
Returns a C<Box2D::b2Fixture>
lib/pods/Box2D/b2Body.pod view on Meta::CPAN
Parameters:
=over 4
=item * C<Box2D::b2FixtureDef> C<$def> - the fixture definition. Warning:This function is locked during callbacks.
=back
Returns a C<Box2D::b2Fixture>
lib/pods/Box2D/b2Body.pod view on Meta::CPAN
Parameters:
=over 4
=item * C<Box2D::b2Fixture> C<$fixture> - the fixture to be removed. Warning:This function is locked during callbacks.
=back
=head2 GetAngle()
view release on metacpan or search on metacpan
lib/Bread/Board/Manual/Concepts.pod view on Meta::CPAN
control of some part of your application over to some other part
of your application, be it your code or an outside framework.
IoC is a common paradigm in GUI frameworks, whereby you give up
control of your application flow to the framework and install your
code at callbacks hooks within the framework. For example, take a
very simple command line interface; the application asks a
question, the user responds, the application processes the answer
and asks another question, and so on until it is done. Now consider
the GUI approach for the same application; the application displays
a screen and goes into an event loop, users actions are processed
view release on metacpan or search on metacpan
xt/author/pod_spelling_system.t view on Meta::CPAN
TODO
filename
filenames
login
callback
callbacks
standalone
VMS
hostname
hostnames
TCP
view release on metacpan or search on metacpan
t/expected-sample-pbib.html view on Meta::CPAN
(Phillips, 1999)) systems create a shared-object space by
synchronizing the replicated objects [[Clock-Architecture],
[Dragonfly-Architecture], [COAST-ooSyncGroupware]]. In later versions
of GroupKit (Roseman and Greenberg, 1992; Roseman and Greenberg, 1996) shared
“environments” have been introduced as shared data
structures that can trigger callbacks upon changes.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Application
designers thus have to decide to which degree or for which parts of
their application shared access to data is desirable or necessary.
For the Passage system, a shared data model enables a straightforward
access to data objects from different computers, which is necessary
view release on metacpan or search on metacpan
examples/params-validate.pl view on Meta::CPAN
}
sub check_cpr {
validate( @_,
{ cpr =>
{ callbacks =>
{ 'validate_cpr' => sub { validateCPR($_[0]); } } } } );
print $_[1]." is a valid CPR\n";
}
view release on metacpan or search on metacpan
examples/params-validate.pl view on Meta::CPAN
}
sub check_cvr {
validate( @_,
{ cvr =>
{ callbacks =>
{ 'validate_cvr' => sub { validateCVR($_[0]); } } } } );
print $_[1]." is a valid CVR\n";
}
view release on metacpan or search on metacpan
lib/Business/DK/FI.pm view on Meta::CPAN
#number has to be a positive number between 1 and 99999999999999
validate_pos(
@ARG,
{ type => SCALAR,
regex => qr/^\d+$/,
callbacks => {
'higher than 0' => sub { shift() >= 1 },
'lower than 99999999999999' =>
sub { shift() <= 99999999999999 },
},
},
view release on metacpan or search on metacpan
lib/Business/DK/PO.pm view on Meta::CPAN
use Business::DK::PO qw(validatePO);
sub check_cpr {
validate( @_,
{ po =>
{ callbacks =>
{ 'validate_po' => sub { validatePO($_[0]); } } } } );
print $_[1]." is a valid PO\n";
}
view release on metacpan or search on metacpan
t/004_end_to_end_pro.t view on Meta::CPAN
eval 'use Mojo::UserAgent';
$@ && plan skip_all => "Install Mojolicious to run this test";
# this is an "end to end" test - it will call the gocardless API
# using the details defined in the ENV variables below. you need
# to run t/gocardless_callback_reader.pl allowing the callbacks
# from gocardless to succeed, which feeds the details back into
# this script (hence "end to end") - note that the redirect URI
# and webhook URI in the sandbox/live developer settings will also
# need to match that of the address running the script
my ( $token,$url,$DEBUG ) = @ENV{qw/