view release on metacpan or  search on metacpan

inc/Module/Install.pm  view on Meta::CPAN

use 5.004;
use strict 'vars';

use vars qw{$VERSION};
BEGIN {
    # All Module::Install core packages now require synchronised versions.
    # This will be used to ensure we don't accidentally load old or
    # different versions of modules.
    # This is not enforced yet, but will be some time in the next few
    # releases once we can make sure it won't clash with custom
    # Module::Install extensions.

 view release on metacpan or  search on metacpan

SkyX_Test.pl  view on Meta::CPAN

  sleep 1;
}

sub testsky6DirectGuide {
  print "Testing 100% of sky6DirectGuide module.\n";
  $SX->sky6DirectGuide->IAsynchronous(0);
  print "  IAsynchronous set to: " . $SX->sky6DirectGuide->IAsynchronous . "\n";
  $SX->sky6DirectGuide->MoveTelescope(900,900);
  print "Finished testing sky6DirectGuide module.\n";
  sleep 1;
}

SkyX_Test.pl  view on Meta::CPAN

  my $target = shift;
  print "Testing sky6RASCOMTele module.\n";

#  Abort() - Not tested
#  CommutateMotors - Not tested.
  print "  Connecting to mount, Set Asynchronous mode off, and Unpark\n";
  $SX->sky6RASCOMTele->Connect();
  if ($SX->sky6RASCOMTele->IsConnected) { 
    print "  Connected to Telescope. \n";
  }else{
    print "  Did not connect to Telescope! \n";
  }
  $SX->sky6RASCOMTele->Asynchronous(0);
  $SX->sky6RASCOMTele->Unpark();
# DoCommand() - Not tested (I have a paramount)
  print "  Testing FindHome\n";
  $SX->sky6RASCOMTele->FindHome();
  print "  Home.\n";

SkyX_Test.pl  view on Meta::CPAN

# We'll use this later
#   ccdsoftCamera::LastImageFileName
  $SX->ccdsoftCamera->Autoguider(0);
  $SX->ccdsoftCamera->Frame(1);
  $SX->ccdsoftCamera->Connect();
  $SX->ccdsoftCamera->Asynchronous(0);
  $SX->ccdsoftCamera->ImageUseDigitizedSkySurvey(1);
  $SX->ccdsoftCamera->AutoSaveOn(1);
  print "  Taking photo (DSS)\n";
  $SX->ccdsoftCamera->ExposureTime(1);
  $SX->ccdsoftCamera->TakeImage();

 view release on metacpan or  search on metacpan

lib/Astro/SpaceTrack.pm  view on Meta::CPAN

		name	=> 'All payloads',
		satcat	=> {
		    OBJECT_TYPE	=> 'PAYLOAD',
		},
	    },
	    geosynchronous => {		# GEO
		name	=> 'Geosynchronous satellites',
#		number	=> 3,
		# We have to go through satcat to eliminate bodies that
		# are not on orbit, since tle_latest includes bodies
		# decayed in the last two years or so
#		satcat	=> {

lib/Astro/SpaceTrack.pm  view on Meta::CPAN

		tle => {
		    EPOCH	=> '>now-30',
		},
#		number => 23,
	    },
	    bright_geosynchronous => {
		favorite	=> 'brightgeo',
		name => 'Bright Geosynchronous satellites',
		tle => {
		    EPOCH	=> '>now-30',
		},
	    },
	    human_spaceflight => {

lib/Astro/SpaceTrack.pm  view on Meta::CPAN

    Name            Description
    full            Full catalog
    payloads        All payloads
    navigation      Navigation satellites
    weather         Weather satellites
    geosynchronous  Geosynchronous bodies
    iridium         Iridium satellites
    orbcomm         OrbComm satellites
    globalstar      Globalstar satellites
    intelsat        Intelsat satellites
    inmarsat        Inmarsat satellites
    amateur         Amateur Radio satellites
    visible         Visible satellites
    special         Special satellites
    bright_geosynchronous
                    Bright Geosynchronous satellites
    human_spaceflight
                    Human Spaceflight
    well_tracked_objects
                    Well-Tracked Objects having
		    unknown country and launch point

 view release on metacpan or  search on metacpan

doc/astronomical-notes.pod  view on Meta::CPAN

Although this text  is stored in the  L<Astro::Sunrise> repository, it
also  documents the  L<DateTime::Event::Sunrise> module,  which has  a
very  similar core  (astronomical computations)  and a  different API.
Since both  modules move at different  speeds, it may happen  that the
text you  are reading is  not synchronised with  the L<Astro::Sunrise>
module.

=head1 Why This Text? For Whom?

The main purpose of this text is to explain how the sunrises

doc/astronomical-notes.pod  view on Meta::CPAN

The variation of the duration of the day is a tiny
variation, but with our modern measure instruments, we
can measure it. Since the time when scientists abolished the
astronomical standard of time for an atomic
standard, it has been necessary to add 27 leap seconds
over 47 years to synchronise the atomic timescale with
the Earth's spin.

For the moment, all adjustments have consisted in
adding a leap second. But it can happen that we
would have to synchronise in the other direction by removing
a second. So this phenomenon produces fluctuations
rather than a slow drift in a single direction.

=head3 The Equation Of Time

doc/astronomical-notes.pod  view on Meta::CPAN

The concept of I<Mean Sun> is a virtual Sun like this, calibrated so it crosses
the meridian at 12:00 (Local Mean Time) each day, and which minimizes the difference
between the real local noon and the mean local noon. 

I will also consider several "virtual homocinetic suns" or VHS (no relation with
magnetic tapes). These virtal suns are synchronised with the real Sun at some 
convenient point and then move with a constant angular speed.

=head1 Computing Sunrise and Sunset

Computing sunrise and sunset consists in taking in account both the variation of

doc/astronomical-notes.pod  view on Meta::CPAN

Let us look a bit farther into  the past. In January 2019, I published
version  0.98   of  L<Astro::Sunrise>,  with  the   precise  algorithm
implemented as explained in the  preceding paragraph. For test data, I
did not know how to cross-check  with authoritative sources, so I just
checked  they  looked plausible  and  that  the iterative  computation
stopped after  a few iterations. At  this time, I did  not synchronise
L<DateTime::Event::Sunrise> with L<Astro::Sunrise>, because it was not
the proper time yet.

Then in  April 2020, a user  created an RT ticket,  explaining that he
had   compared  the   results   of  L<DateTime::Event::Sunrise>   with
authoritative websites and  that the results were  not precise enough.
Of course  the results were  not precise,  I had not  yet synchronised
L<DateTime::Event::Sunrise>  with L<Astro::Sunrise>.  Yet this  ticket
gave  me two  things: first,  a  website which  would provide  precise
day-after-day computations of sunrise, sunset and real solar noon, and
second a few round tuits to upgrade L<DateTime::Event::Sunrise> to the
same level as L<Astro::Sunrise>, with real tests values.

 view release on metacpan or  search on metacpan

inc/Module/Install.pm  view on Meta::CPAN

use 5.004;
use strict 'vars';

use vars qw{$VERSION};
BEGIN {
    # All Module::Install core packages now require synchronised versions.
    # This will be used to ensure we don't accidentally load old or
    # different versions of modules.
    # This is not enforced yet, but will be some time in the next few
    # releases once we can make sure it won't clash with custom
    # Module::Install extensions.

 view release on metacpan or  search on metacpan

lib/Astro/Coord/ECI.pm  view on Meta::CPAN

    my $denom = $body->mean_angular_velocity -
	$self->mean_angular_velocity;
##  my $retro = $denom >= 0 ? 0 : 1;
    ($denom = abs ($denom)) < 1e-11 and croak <<eod;
Error - The next_azimuth() method will not work for geosynchronous
        bodies.
eod

    my $apparent = TWOPI / $denom;
    my $begin = $self->universal;

lib/Astro/Coord/ECI.pm  view on Meta::CPAN

The current time of both C<$coord> and C<$body> objects are left at the
returned time.

The algorithm is by successive approximation. It will croak if the
period of the C<$body> is close to synchronous, and will probably not
work well for bodies in highly eccentric orbits. The calculation is to
the nearest second, and the time returned is the first even second after
the body crosses the meridian.

=item ( $time, $above ) = $coord->next_meridian( $want )

lib/Astro/Coord/ECI.pm  view on Meta::CPAN

The current time of both C<$coord> and its C<station> are left at the
returned time.

The algorithm is by successive approximation. It will croak if the
period of the C<$body> is close to synchronous, and will probably not
work well for bodies in highly eccentric orbits. The calculation is to
the nearest second, and the time returned is the first even second after
the body crosses the meridian.

=cut

lib/Astro/Coord/ECI.pm  view on Meta::CPAN

    my $denom = $body->mean_angular_velocity -
	$self->mean_angular_velocity;
    my $retro = $denom >= 0 ? 0 : 1;
    ($denom = abs ($denom)) < 1e-11 and croak <<'EOD';
Error - The next_meridian() method will not work for geosynchronous
        bodies.
EOD

    my $apparent = TWOPI / $denom;
    my $begin = $self->universal;

 view release on metacpan or  search on metacpan

README.rst  view on Meta::CPAN

===============================================================================
Async::Blackboard
===============================================================================

Async::Blackboard is a data-driven workflow manager for asynchronous
applications.  It's designed to be used to control the ordering of asynchronous
actions which have data-dependencies, by allowing components to subscribe to
the publication of a named values on a per-request basis.

Async is used soley for the management of value timeouts, where asynchronous
actions are intended to fulfill parts of the request under tight time
constraints, where further action may take place in the absence of a value
being provided.

Development

 view release on metacpan or  search on metacpan

lib/Async/Chain.pm  view on Meta::CPAN

            log(...);
        };

=head1 RATIONALE

A asynchronous code often have deep nested callbacks, therefore it is tangled
and hard to change. This module help to converta a code like following to some
more readable form. Also, with C<chain> you can easily skip some unneeded steps
in this thread. For example jump to log step after the first failed query in
the chain.

 view release on metacpan or  search on metacpan

inc/Module/Install.pm  view on Meta::CPAN

use File::Find ();
use File::Path ();

use vars qw{$VERSION $MAIN};
BEGIN {
	# All Module::Install core packages now require synchronised versions.
	# This will be used to ensure we don't accidentally load old or
	# different versions of modules.
	# This is not enforced yet, but will be some time in the next few
	# releases once we can make sure it won't clash with custom
	# Module::Install extensions.

 view release on metacpan or  search on metacpan

lib/Async/Event/Interval.pm  view on Meta::CPAN

__END__

=head1 NAME

Async::Event::Interval - Scheduled and one-off asynchronous events

=for html
<a href="https://github.com/stevieb9/async-event-interval/actions"><img src="https://github.com/stevieb9/async-event-interval/workflows/CI/badge.svg"/></a>
<a href='https://coveralls.io/github/stevieb9/async-event-interval?branch=master'><img src='https://coveralls.io/repos/stevieb9/async-event-interval/badge.svg?branch=master&service=github' alt='Coverage Status' /></a>

lib/Async/Event/Interval.pm  view on Meta::CPAN

        $$json = ...; # Fetch JSON from website
    }

=head1 DESCRIPTION

Very basic implementation of asynchronous events triggered by a timed interval.
If a time of zero is specified, we'll run the event only once.

=head1 METHODS - EVENT OPERATION

=head2 new($delay, $callback, @params)

 view release on metacpan or  search on metacpan

Group.pm  view on Meta::CPAN

  {
    my $self = shift ;
    warn "$self->{name} ",shift if $self->{test} ;
  }

# Call a set of asynchronous functions which MUST have their set of user
# callbacks.. Note that the user call-back invoked when the function MUST
# call the asyncDone function with a result.
#
# When all function calls are over (i.e. all call-back were performed)
# all the returned results are logically 'anded' and the resulting result

Group.pm  view on Meta::CPAN

    # initialize 
    $self->{result} = 1 ;
    $self->{out} = '' ;

    # compute nb of asynchronous calls that will be done
    $self->{onGoing} = scalar (@{$args{set}}) ;

    # make up some log message
    $self->printEvent("asynCall called for ".
                      $self->{onGoing}." calls");

Group.pm  view on Meta::CPAN

__END__

=head1 NAME

Async::Group - Perl class to deal with simultaneous asynchronous calls

=head1 SYNOPSIS

 use Async::Group ;
 use strict ;

Group.pm  view on Meta::CPAN

       )


=head1 DESCRIPTION

If you sometimes have to launch several asynchronous calls in
parrallel and want to call one call-back function when all these calls
are finished, this module may be for you.

Async::Group is a class which enables you to call several asynchronous
routines.  Each routine may have their own callback. When all the
routine are over (i.e.  all their callback were called), Async::Group
will call the global callback given by the user.

Note that one Async::Group objects must be created for each group of

Group.pm  view on Meta::CPAN

 - callback : global user callback function


=head2 callDone(result, [string])

Function to be called back each time an asynchronous call is finished.

When all function calls are over (i.e. all call-back were performed)
all the returned results are logically 'anded', the passed strings are
concatenated and the resulting result is passed to the global user
call-back function passed with the run() method.

 view release on metacpan or  search on metacpan

lib/Async/Hooks.pm  view on Meta::CPAN

package Async::Hooks;
{
  $Async::Hooks::VERSION = '0.16';
}

# ABSTRACT: Hook system with asynchronous capabilities

use Mo qw(is default);
use Carp 'confess';
use Async::Hooks::Ctl;
use namespace::clean;

lib/Async/Hooks.pm  view on Meta::CPAN

__END__
=pod

=head1 NAME

Async::Hooks - Hook system with asynchronous capabilities

=head1 VERSION

version 0.16

lib/Async/Hooks.pm  view on Meta::CPAN

important state modifications.

There are other modules that provide the same functionality (see
L<SEE ALSO> section). The biggest diference is that you can pause
processing of the chain of callbacks at any point and start a
asynchronous network request, and resume processing when that request
completes.

Developers are not expect to subclass from C<Async::Hooks>. The
recomended usage is to stick a C<Async::Hooks> instance in a slot or as
a singleton for your whole app, and then delegate some methods to it.

lib/Async/Hooks.pm  view on Meta::CPAN

C<< $ctl->decline() >> or C<< $ctl->done() >>. You can also use
C<next()> or C<declined()> as alias to C<decline()>, and C<stop()>
as alias to C<done()>, whatever feels better.

But you can delay that decision. You can start a network request,
asynchronously, and only decide to decline or stop when the response
arrives. For example, if you use the L<AnyEvent::HTTP|AnyEvent::HTTP>
module to make a HTTP request, you could do something like this:

    sub check_server_is_up_cb {
      my ($ctl, $args) = @_;

lib/Async/Hooks.pm  view on Meta::CPAN

=item * L<Notification::Center|Notification::Center>

=back

Of those four, only L<Object::Event|Object::Event> version 1.0 and later
provides the same ability to pause a chain, do some asynchrounous work
and resume chain processing later.

=head1 ACKNOWLEDGEMENTS

The code was inspired by the C<run_hook_chain> and C<hook_chain_fast>

 view release on metacpan or  search on metacpan

Interrupt.pm  view on Meta::CPAN

=head1 NAME

Async::Interrupt - allow C/XS libraries to interrupt perl asynchronously

=head1 SYNOPSIS

 use Async::Interrupt;

=head1 DESCRIPTION

This module implements a single feature only of interest to advanced perl
modules, namely asynchronous interruptions (think "UNIX signals", which
are very similar).

Sometimes, modules wish to run code asynchronously (in another thread,
or from a signal handler), and then signal the perl interpreter on
certain events. One common way is to write some data to a pipe and use an
event handling toolkit to watch for I/O events. Another way is to send
a signal. Those methods are slow, and in the case of a pipe, also not
asynchronous - it won't interrupt a running perl interpreter.

This module implements asynchronous notifications that enable you to
signal running perl code from another thread, asynchronously, and
sometimes even without using a single syscall.

=head2 USAGE SCENARIOS

=over 4

Interrupt.pm  view on Meta::CPAN

      cb   => \&_signal_check, # defined later
   );

Then, for each signal to hook, create an Async::Interrupt object. The
callback just sets a global variable, as we are only interested in
synchronous signals (i.e. when the event loop polls), which is why the
pipe draining is not done automatically.

   my $interrupt = new Async::Interrupt
      cb             => sub { undef $SIGNAL_RECEIVED{$signum} },
      signal         => $signum,

Interrupt.pm  view on Meta::CPAN

   $self
}

=item ($signal_func, $signal_arg) = $async->signal_func

Returns the address of a function to call asynchronously. The function
has the following prototype and needs to be passed the specified
C<$signal_arg>, which is a C<void *> cast to C<IV>:

   void (*signal_func) (void *signal_arg, int value)

Interrupt.pm  view on Meta::CPAN

C<$value> must be in the valid range for a C<sig_atomic_t>, except C<0>
(1..127 is portable).

If the function is called while the Async::Interrupt object is already
signaled but before the callbacks are being executed, then the stored
C<value> is either the old or the new one. Due to the asynchronous
nature of the code, the C<value> can even be passed to two consecutive
invocations of the callback.

=item $address = $async->c_var

Interrupt.pm  view on Meta::CPAN

This method does not need to be called normally, as it will be invoked
automatically. However, it can be used to force handling of outstanding
interrupts while the object is blocked.

One reason why one might want to do that is when you want to switch
from asynchronous interruptions to synchronous one, using e.g. an event
loop. To do that, one would first C<< $async->block >> the interrupt
object, then register a read watcher on the C<pipe_fileno> that calls C<<
$async->handle >>.

This disables asynchronous interruptions, but ensures that interrupts are
handled by the event loop.

=item $async->signal_hysteresis ($enable)

Enables or disables signal hysteresis (default: disabled). If a POSIX

Interrupt.pm  view on Meta::CPAN

=back

=head1 THE Async::Interrupt::EventPipe CLASS

Pipes are the predominant utility to make asynchronous signals
synchronous. However, pipes are hard to come by: they don't exist on the
broken windows platform, and on GNU/Linux systems, you might want to use
an C<eventfd> instead.

This class creates selectable event pipes in a portable fashion: on
windows, it will try to create a tcp socket pair, on GNU/Linux, it will

 view release on metacpan or  search on metacpan

lib/Async/MergePoint.pm  view on Meta::CPAN

use Carp;

=head1 NAME

C<Async::MergePoint> - resynchronise diverged control flow

=head1 SYNOPSIS

 use Async::MergePoint;

lib/Async/MergePoint.pm  view on Meta::CPAN

Often in program logic, multiple different steps need to be taken that are
independent of each other, but their total result is needed before the next
step can be taken. In synchonous code, the usual approach is to do them
sequentially. 

An asynchronous or event-based program could do this, but if each step
involves some IO idle time, better overall performance can often be gained by
running the steps in parallel. A C<Async::MergePoint> object can then be used
to wait for all of the steps to complete, before passing the combined result
of each step on to the next stage.

lib/Async/MergePoint.pm  view on Meta::CPAN

complete. When all of the required items are so marked, the C<on_finished>
continuation is invoked.

For use cases where code may be split across several different lexical scopes,
it may not be convenient or possible to share a lexical variable, to pass on
the result of some asynchronous operation. In these cases, when an item is
marked as complete a value can also be provided which contains the results of
that step. The C<on_finished> callback is passed a hash (in list form, rather
than by reference) of the collected item values.

This module was originally part of the L<IO::Async> distribution, but was

lib/Async/MergePoint.pm  view on Meta::CPAN

   }
}

=head1 EXAMPLES

=head2 Asynchronous Plugins

Consider a program using C<Module::Pluggable> to provide a plugin architecture
to respond to events, where sometimes the response to an event may require
asynchronous work. A C<MergePoint> object can be used to coordinate the
responses from the plugins to this event.

 my $merge = Async::MergePoint->new();

 foreach my $plugin ( $self->plugins ) {

lib/Async/MergePoint.pm  view on Meta::CPAN

    ....
    $merge->needs( __PACKAGE__ );
    $merge->done( __PACKAGE__ => $result );
 }

Whereas, to handle the event asynchronously the plugin can instead perform:

 sub handle_event
 {
    my ( $event, $merge, @args ) = @_;
    ....

 view release on metacpan or  search on metacpan

lib/Async/Methods.pm  view on Meta::CPAN

  use Mojo::UserAgent;
  
  my $ua = Mojo::UserAgent->new;
  
  # Normal synchronous code
  
  print $ua->get('http://trout.me.uk/')->result->body;
  
  # Equivalent code running synchronously atop promises
  
  print $ua->get_p('http://trout.me.uk')->then::result->await::body;
  
  # Equivalent code within an async subroutine
  

lib/Async/Methods.pm  view on Meta::CPAN

  print fetch($url)->await::this;

=head1 DESCRIPTION

L<Async::Methods> provides a set of helper methods operating via namespace
that make chaining together asynchronous methods easier. This is not at all
meant to be a replacement for the C<async> and C<await> keywords available
via L<Future::AsyncAwait> or the C<-async_await> flag to L<Mojo::Base> and
in fact is largely meant to be used I<with> such facilities.

Note that in the following code I use C<$p> for example variables but they

 view release on metacpan or  search on metacpan

lib/Async/Microservice/Time.pm  view on Meta::CPAN

    curl "http://localhost:8085/v1/epoch"  -H "accept: application/json"
    curl "http://localhost:8085/v1/datetime?time_zone=local" -H "accept: application/json"

=head1 DESCRIPTION

This is an example asynchronous http micro service using L<Async::Microservice>.
View the source code it's minimal.

=head1 METHODS

=head2 service_name

 view release on metacpan or  search on metacpan

lib/Async/Queue.pm  view on Meta::CPAN

}


=head1 NAME

Async::Queue - control concurrency of asynchronous tasks

=head1 VERSION

Version 0.021

lib/Async/Queue.pm  view on Meta::CPAN

=over

=item L<AnyEvent::FIFO>

The goal of L<AnyEvent::FIFO> is the same as that of L<Async::Queue>: to control concurrency level of asynchronous tasks.
The big difference is that L<AnyEvent::FIFO> is a queue of subroutines while L<Async::Queue> is a queue of tasks (data).
In L<Async::Queue>, worker subroutine is registered with the object in advance.
In L<AnyEvent::FIFO>, it is workers that are pushed to the queue.

You can emulate L<AnyEvent::FIFO> with L<Async::Queue> by pushing subroutine references to it as tasks.

 view release on metacpan or  search on metacpan

lib/Async/ResourcePool.pm  view on Meta::CPAN

package Async::ResourcePool v0.1.3;

=head1 NAME

Async::ResourcePool - Resource pooling for asynchronous programs.

=head1 DESCRIPTION

This module implements the simple functionality of creating a source pool for
event-based/asynchronous programs.  It provides consumers with the ability to
have some code execute whenever a resource happens to be ready.  Further, it
allows resources to be categorized (by label) and limited as such.

=cut

 view release on metacpan or  search on metacpan

lib/Async/Stream.pm  view on Meta::CPAN

	return $self;
}

=head2 map($transformer)

Method makes synchronous transformation for stream, like usual map for array.

  $stream->map(sub { $_ * 2 })->to_arrayref(sub {print @{$_[0]}});

=cut
sub map {

 view release on metacpan or  search on metacpan

lib/Async/Template.pm  view on Meta::CPAN

    };


=head1 DESCRIPTION

Async::Template is the same as Template Toolkit with asynchronous interface and
with asynchronous operators ASYNC/AWAIT which can be used with any event
management system (like L<AnyEvent>).

To refer Template Toolkit language syntax, configure options, params and other
documentation folow this link L<Template>.

Operators like ASYNC/AWAIT itself is not an function or something wich applied
locally at the place where it is used in the code. Such operators affect all
the code generation and the execution sequences. Any block of code cease to be
a block if at least one async operator is exists in it. Loops, blocks,
conditions, switches, and so on become different in synchronous and asynchronous
implementations.

For example a synchronous loop is continuous sequence which at the end of loop
has a transition to the begin of the loop. But the asynchronous loop is not
a continuos sequence and to do transition to the begin of loop typical loop
operators can not be used because begin and end of loop located in different
unjoined betwen each other code sequences (in a different fuctions).
This is because at the middle of the loop at the place of async operator
presents a finish of the execution and return. This return must be supported
by each of parent block statement. Execution must be returned to the very top
of the execution - to the event loop. And after awaited event condition is
reached the execution must continue from that place from which it was returned.

Therefore to develop a compiler with asynchronous operators it need to have
different synchronous and asynchronous implementation for each block operator of
language and many more. And for synchronous an asynchronous function call. This
library represent itself compiler with modified grammar based on Template
Toolkit. This library provides implementation of asynchronous operators and the
code generation and asynchronous stack management and so on, uses itself as
library for asynchronous sequences and uses Template Toolkit as library for
execution generic synchronous sequences and also uses parts modified to be
asynchronous.


=head2 SYNC AND ASYNC BLOCKS 

Continuous sequence of execution is tеaring at the place of AWAIT operator.
The block is not only BLOCK operator statement but also IF, WHILE and etc...

Any block become asynchronous if it have at least one AWAIT operator or
another asynchronous block.

Any block is synchronous if it does not contain AWAIT operator or another
asynchronous block even if it has any amount of ASYNC opeartor

Any block does not become asynchronous if it has ASYNC operator inside
(if it has no AWAIT operator nor one or more asynchronous block).


=head2 TODO

As mentioned above, each block of code must be implemented differently
therefore this library has asynchronous implementation for most of block
operators of Template Toolkit language but not all yet.

The block operators which is not implemented as asynchronous will work anyway
with synchronous sequences (i.e. without AWAIT operator inside of it). 

Here the list of Template Toolkit operators async implementation of which does
not checked and/or implemented:

NEXT LAST STOP

lib/Async/Template.pm  view on Meta::CPAN

Serguei Okladnikov E<lt>oklaspec@gmail.comE<gt>

This L<Async::Template> package uses "Template Toolkit" (L<Template>)
as dependency and contains small amount modified parts of "Template Toolkit"
(modified grammar and continuous synchronous code which was necessary
to split for execution asynchronous sequences). The "Template Toolkit" was
written by Andy Wardley E<lt>abw@wardley.orgE<gt> and contributors, see
Template::Manual::Credits for details and repos contributors sections.


=head1 LICENSE 

 view release on metacpan or  search on metacpan

lib/Async/Util.pm  view on Meta::CPAN

=pod

=head1 NAME

Async::Util - Utilities for common asynchronous programming tasks

=head1 SYNOPSIS

    use Async::Util qw(amap azipmap achain);

    # async map
    amap(
        inputs => [ 'foo', 'bar' ],
        action => \&something_asynchronous,
        cb     => \&do_this_at_the_end,
    );

    # invoke action on the corresponding input
    azipmap(
        inputs  => [ 1, 1, 1 ],
        actions => [
            ... # asynchronous subs
        ],
        cb     => \&do_this_at_the_end,
    );

    # execute steps in order
    achain(
        input => 2,
        steps => [
            ... # asynchronous subs
        ],
        cb    => \&do_this_at_the_end,
    );

Examples using AnyEvent:

lib/Async/Util.pm  view on Meta::CPAN

    my ($res, $err) = $cv->recv; # $res is 6

=head1 DESCRIPTION

C<Async::Util> provides functionality for common tasks that come up when doing
asynchronous programming. This module's functions often take code refs. These
code refs are invoked with two arguments: the input and a callback to be
invoked on completion. When the provided callback is invoked it should be
passed an output argument and an optional error.

=head1 FUNCTIONS

=head2 amap

C<amap> is an asynchronous version of map:

    amap(
        inputs    => <ARRAY_REF>,
        action    => <CODE_REF>,
        cb        => <CODE_REF>,

 view release on metacpan or  search on metacpan

Async.pm  view on Meta::CPAN

__END__

=head1 NAME

Async - Asynchronous evaluation of Perl code (with optional timeouts)

=head1 SYNOPSIS

  my $proc = Async->new( sub { any perl code you want executed } );

Async.pm  view on Meta::CPAN

=head1 DESCRIPTION

This module runs some code in a separate process and retrieves its
result. Since the code is running in a separate process, your main
program can continue with whatever it was doing while the separate
code is executing. This separate code is called an I<asynchronous
computation>.

=head1 INTERFACE

To check if the asynchronous computation is complete you can call
the C<ready()>
method, which returns true if so, and false if it is still running.

After the asynchronous computation is complete, you should call the
C<error()> method to make sure that everything went all right.
C<error()> will return C<undef> if the computation completed normally,
and an error message otherwise.

Data returned by the computation can be retrieved with the C<result()>

Async.pm  view on Meta::CPAN

returned by the computation will be stringified. (See AsyncData below
for how to avoid this.) If the computation has not completed yet,
C<result()> will return an undefined value.

C<result()> takes an optional parameter, C<$force>. If C<$force> is
true, then the calling process will wait until the asynchronous
computation is complete before returning.

=head2 C<AsyncTimeout>

  use Async;
  $proc = AsyncTimeout->new( sub { ... }, $timeout, $special );

C<AsyncTimeout> implements a version of C<Async> that has an
automatic timeout. If the asynchronous computation does not complete
before C<$timeout> seconds have elapsed, it is forcibly terminated and
returns a special value C<$special>. The default special value is the
string "Timed out\n".

All the other methods for C<AsyncTimeout> are exactly the same as for

Async.pm  view on Meta::CPAN

  use Async;
  $proc = AsyncData->new( sub { ... } );

C<AsyncData> is just like C<Async> except that instead of returning a
string, the asynchronous computation may return any scalar value. If
the scalar value is a reference, the C<result()> method will yield a
refernce to a copy of this data structure.

The C<AsyncData> module requires that C<Storable> be installed.
C<AsyncData::new> will die if C<Storable> is unavailable.

Async.pm  view on Meta::CPAN

All the other methods for C<AsyncData> are exactly the same as for
C<Async>.

=head1 WARNINGS FOR THE PROGRAMMER

The asynchronous computation takes place in a separate process, so
nothing it does can affect the main program. For example, if it
modifies global variables, changes the current directory, opens and
closes filehandles, or calls C<die>, the parent process will be
unaware of these things. However, the asynchronous computation does
inherit the main program's file handles, so if it reads data from
files that the main program had open, that data will not be availble
to the main program; similarly the asynchronous computation can write
data to the same file as the main program if it inherits an open
filehandle for that file.

=head1 ERRORS

Async.pm  view on Meta::CPAN

  Couldn't make pipe: (reason)
  Couldn't fork: (reason)
  Read error: (reason)

If your asynchronous computation dies for any reason, that is not
considered to be an I<error>; that is the normal termination of the
process. Any messages written to C<STDERR> will go to the
computation's C<STDERR>, which is normally inherited from the main
program, and the C<result()> will be the empty string.

 view release on metacpan or  search on metacpan

lib/Asynchat.pm  view on Meta::CPAN

    $channel->found_terminator( ... )

 
=head1 DESCRIPTION

Asynchat builds on Asyncore, simplifying asynchronous clients and servers and making it easier to handle protocols whose elements are terminated by arbitrary strings, or are of variable length. 
 
Asyncore is a basic infrastructure for asyncronous socket programming. It provides an implementation of "reactive socket" and it provides hooks for handling events. Code must be written into these hooks (handlers).
 
Asynchat is intended as an abstract class. Override collect_incoming_data() and found_terminator() in a subclass to provide the implementation of the protocol you are writing.
 

 view release on metacpan or  search on metacpan

lib/Asyncore.pm  view on Meta::CPAN

__END__


=head1 NAME

Asyncore - basic infrastracture for asynchronous socket services

=head1 SYNOPSIS

    use Asyncore;
    use base qw( Asyncore::Dispatcher );

 view release on metacpan or  search on metacpan

share/lexicons/app/bsky/actor/getPreferences.json  view on Meta::CPAN

  "lexicon": 1,
  "id": "app.bsky.actor.getPreferences",
  "defs": {
    "main": {
      "type": "query",
      "description": "Get private preferences attached to the current account. Expected use is synchronization between multiple devices, and import/export during account migration. Requires auth.",
      "parameters": {
        "type": "params",
        "properties": {}
      },
      "output": {

 view release on metacpan or  search on metacpan

inc/Module/Install.pm  view on Meta::CPAN

use File::Find ();
use File::Path ();

use vars qw{$VERSION $MAIN};
BEGIN {
	# All Module::Install core packages now require synchronised versions.
	# This will be used to ensure we don't accidentally load old or
	# different versions of modules.
	# This is not enforced yet, but will be some time in the next few
	# releases once we can make sure it won't clash with custom
	# Module::Install extensions.

 view release on metacpan or  search on metacpan

inc/Module/Install.pm  view on Meta::CPAN

use File::Find ();
use File::Path ();

use vars qw{$VERSION $MAIN};
BEGIN {
	# All Module::Install core packages now require synchronised versions.
	# This will be used to ensure we don't accidentally load old or
	# different versions of modules.
	# This is not enforced yet, but will be some time in the next few
	# releases once we can make sure it won't clash with custom
	# Module::Install extensions.

 view release on metacpan or  search on metacpan

inc/Module/Install.pm  view on Meta::CPAN

use File::Find ();
use File::Path ();

use vars qw{$VERSION $MAIN};
BEGIN {
	# All Module::Install core packages now require synchronised versions.
	# This will be used to ensure we don't accidentally load old or
	# different versions of modules.
	# This is not enforced yet, but will be some time in the next few
	# releases once we can make sure it won't clash with custom
	# Module::Install extensions.

 view release on metacpan or  search on metacpan

inc/Module/Install.pm  view on Meta::CPAN

use File::Find ();
use File::Path ();

use vars qw{$VERSION $MAIN};
BEGIN {
	# All Module::Install core packages now require synchronised versions.
	# This will be used to ensure we don't accidentally load old or
	# different versions of modules.
	# This is not enforced yet, but will be some time in the next few
	# releases once we can make sure it won't clash with custom
	# Module::Install extensions.

 view release on metacpan or  search on metacpan

lib/AtteanX/Query/Cache.pm  view on Meta::CPAN

This is an alpha release of a system that is able to intercept SPARQL
queries if deployed in a proxy, and analyze the queries so that the
query can be evaluated on the proxy. It can look up in a cache on the
proxy, send parts of the query on to the remote endpoint, use Linked
Data Fragments when appropriate and so on. The analyzer may also
decide to prefetch certain data asynchronously.

It is known at present to have insufficient performance for any
practical use, but is released anyway as an alpha.