synchro results from the CPAN

use 5.005;
use strict 'vars';

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 all matches for this distribution

AnyEvent-Digest

1 match

lib/AnyEvent/Digest.pm view on Meta::CPAN


specifies an amount of read unit for addfile(). Default to 65536 = 64KiB.

=item C<backend>

specifies a backend module to handle asynchronous read. Available backends are C<'idle'> and C<'aio'>. Default to C<'idle'>.

=back

=head2 C<add_async(@dat)>

view all matches for this distribution

AnyEvent-Discord-Client

1 match

lib/AnyEvent/Discord/Client.pm view on Meta::CPAN


    my $typing_watcher = $bot->typing($channel);
    
    # Now, do a potentially very slow operation, like calling an API.
    
    # Once the API responds, even asynchronously, disable the watcher:
    undef $typing_watcher;

=item C<add_commands(I<%commands>)>

Installs new commands - chat messages that begin with the C<prefix> given during construction and any key from the given hash.  When seen as a chat message, the corresponding subref of the registered command will be invoked.  The subref is passed a r...

lib/AnyEvent/Discord/Client.pm view on Meta::CPAN

      },
    );

=item C<api(I<$method>, I<$path>, I<$data>, I<$cb>)>

Invokes the Discord API asynchronously and returns immediately.  C<$method> is the HTTP method to use; C<$path> is the endpoint to call.  If C<$data> is a reference, it is sent as JSON; otherwise, if it is defined, it is sent as a C<x-www-form-urlenc...

=item C<api_sync(I<$method>, I<$path>, I<$data>)>

Invokes the Discord API synchronously and returns the result of the call.  C<$method> is the HTTP method to use; C<$path> is the endpoint to call.  If C<$data> is a reference, it is sent as JSON; otherwise, if it is defined, it is sent as a C<x-www-f...

=item C<websocket_send(I<$op>, I<$d>)>

Sends a raw WebSocket payload as per the L<Discord Gateway|https://discordapp.com/developers/docs/topics/gateway> documentation.

view all matches for this distribution

AnyEvent-EC2-Tiny

5 results

lib/AnyEvent/EC2/Tiny.pm view on Meta::CPAN

package AnyEvent::EC2::Tiny;
{
  $AnyEvent::EC2::Tiny::VERSION = '0.002';
}
# ABSTRACT: Tiny asynchronous (non-blocking) interface to EC2 using AnyEvent

use Moo;
use Carp;
use HTTP::Tiny;
use AnyEvent::HTTP;

lib/AnyEvent/EC2/Tiny.pm view on Meta::CPAN


=pod

=head1 NAME

AnyEvent::EC2::Tiny - Tiny asynchronous (non-blocking) interface to EC2 using AnyEvent

=head1 VERSION

version 0.002

lib/AnyEvent/EC2/Tiny.pm view on Meta::CPAN

        },
    );

=head1 DESCRIPTION

This is a basic asynchronous, non-blocking, interface to EC2 based on
L<Net::EC2::Tiny>. It's relatively compatible while the only difference is
with regards to the callbacks and returned information.

=head1 METHODS

view all matches for this distribution

AnyEvent-FCP

2 results

FCP.pm view on Meta::CPAN

these over sending requests yourself is that they handle the necessary
serialisation, protocol quirks, and replies.

All of them exist in two versions, the variant shown in this manpage, and
a variant with an extra C<_> at the end, and an extra C<$cb> argument. The
version as shown is I<synchronous> - it will wait for any replies, and
either return the reply, or croak with an error. The underscore variant
returns immediately and invokes one or more callbacks or condvars later.

For example, the call

FCP.pm view on Meta::CPAN

   my $fcp = new AnyEvent::FCP;

   # let us look at the global request list
   $fcp->watch_global_ (1);

   # list them, synchronously
   my $req = $fcp->list_persistent_requests;

   # go through all requests
TODO
   for my $req (values %$req) {

view all matches for this distribution

AnyEvent-FDpasser

3 results

lib/AnyEvent/FDpasser.pm view on Meta::CPAN

        ## Spurious ready notification or signal: put the cb back on the queue
        unshift @{$self->{ibuf}}, $cb;
      } elsif ($!{EMSGSIZE} || $!{EMFILE} || $!{ENFILE}) {
        ## File descriptor table is full. This should be very unlikely given the close+duping
        ## technique used to detect this. In this case the descriptor stream may be
        ## desynchronised and we must shutdown the passer.

        my $err = $!;

        carp "AnyEvent::FDpasser - file descriptor table full, closing passer: $!";

lib/AnyEvent/FDpasser.pm view on Meta::CPAN

Creating a passer object before forking is fine since doing this doesn't install any AnyEvent watchers. Also, using the filesystem with C<AF_UNIX> sockets (or more portably, C<fdpasser_server>, C<fdpasser_accept>, and C<fdpasser_connect>) obviates th...


=head2 Control channels

A useful design is to have a "control channel" associated with each passer that sends over data related to file descriptors being passed. As long as the control channel is a synchronised and ordered queue of messages, each message can indicate how ma...

With both the BSD and SysV APIs it is possible to use the passer filehandle to transfer control data but this module does not support this in order to keep the API simple. However, instead you can use a separate socket connection as your control chan...


=head2 Portability

In order to use the SysV interface, set the C<FDPASSER_SYSV> environment variable when running C<Makefile.PL>:

lib/AnyEvent/FDpasser.pm view on Meta::CPAN


Any system call that creates new descriptors in your process can fail because your process has exceed its NOFILE resource limit. Also, it can fail because the system has run out of resources and can't handle new files or (more likely on modern system...

In order to pass a file descriptor between processes, a new descriptor needs to be allocated in the receiving process. Therefore, the C<recvmsg> and C<ioctl> system calls used to implement descriptor passing can fail unexpectedly. Failing to create a...

So what should we do? We could silently ignore it when a descriptor fails to transfer, but then we run the risk of desynchronising the descriptor stream. Another possibility is indicating to the application that this descriptor has failed to transfer...

None of the above "solutions" are very appealing so this module uses a trick known as the "close-dup slot reservation" trick. Actually I just made that name up now but it sounds pretty cool don't you think? The idea is that when the passer object is ...

When it comes time to receive a descriptor, we close the sentinel descriptor, receive the descriptor from the sending process, and then attempt to dup another descriptor. Because we just cleared a descriptor table entry, there should always be a free...

If duping fails, we stop trying to receive any further descriptors and instead retry at regular intervals (while not interrupting the event loop). Hopefully eventually the full descriptor table issue will clear up and we will be able to resume receiv...

Note that a descriptor could be created between closing and receiving if your program uses asynchronous signal handlers or threads that create descriptors, so don't do that. Signals that are handled synchronously (like normal AnyEvent signal watchers...

This trick is similar to a trick described in Marc Lehmann's libev POD document, section "special problem of accept()ing when you can't," although the purpose of employing the trick in this module is somewhat different.

view all matches for this distribution

AnyEvent-FTP

15 results

lib/AnyEvent/FTP.pm view on Meta::CPAN


use strict;
use warnings;
use 5.010;

# ABSTRACT: Simple asynchronous FTP client and server
our $VERSION = '0.19'; # VERSION


1;

lib/AnyEvent/FTP.pm view on Meta::CPAN


=encoding UTF-8

=head1 NAME

AnyEvent::FTP - Simple asynchronous FTP client and server

=head1 VERSION

version 0.19

view all matches for this distribution

AnyEvent-FileLock

3 results

lib/AnyEvent/FileLock.pm view on Meta::CPAN

1;
__END__

=head1 NAME

AnyEvent::FileLock - Lock files asynchronously

=head1 SYNOPSIS

  use AnyEvent::FileLock;

view all matches for this distribution

AnyEvent-Filesys-Watcher

1 match

t/32-filter.t view on Meta::CPAN

	modify_attrs_on_test_files test EXISTS DELETED);

$|++;

# Filters can only be tested with the fallback backend.  The other backends
# may merge events and that make it hard to synchronize.

test(
	setup => sub { create_test_files(qw(foo ignoreme)) },
	description => 'scalar filter',
	expected => {

view all matches for this distribution

AnyEvent-Finger

10 results

lib/AnyEvent/Finger.pm view on Meta::CPAN

use warnings;
use base qw( Exporter );

our @EXPORT_OK = qw( finger_client finger_server );

# ABSTRACT: Simple asynchronous finger client and server
our $VERSION = '0.14'; # VERSION


sub finger_client ($$$;$)
{

lib/AnyEvent/Finger.pm view on Meta::CPAN


=encoding UTF-8

=head1 NAME

AnyEvent::Finger - Simple asynchronous finger client and server

=head1 VERSION

version 0.14

lib/AnyEvent/Finger.pm view on Meta::CPAN

   $tx->res->done;
 };

=head1 DESCRIPTION

This distribution provides an asynchronous finger server and
client which can be used by any event loop supported by
L<AnyEvent>.  This specific module provides a simple procedural
interface to client and server classes also in this distribution.

=head1 FUNCTIONS

view all matches for this distribution

AnyEvent-Fork-Pool

2 results

Pool.pm view on Meta::CPAN


=over 4

=item async => $boolean (default: 0)

Whether to use the synchronous or asynchronous RPC backend.

=item on_error => $callback->($message) (default: die with message)

The callback to call on any (fatal) errors.

Pool.pm view on Meta::CPAN

=back

=head1 POOL PARAMETERS RECIPES

This section describes some recipes for pool parameters. These are mostly
meant for the synchronous RPC backend, as the asynchronous RPC backend
changes the rules considerably, making workers themselves responsible for
their scheduling.

=over 4

Pool.pm view on Meta::CPAN


If you need a deterministic low latency, you should set the C<load>
parameter to C<1>. This ensures that never more than one job is sent to
each worker. This avoids having to wait for a previous job to finish.

This makes most sense with the synchronous (default) backend, as the
asynchronous backend can handle multiple requests concurrently.

=item lowest latency - set load = 1 and idle = max

To achieve the lowest latency, you additionally should disable any dynamic
resizing of the pool by setting C<idle> to the same value as C<max>.

view all matches for this distribution

AnyEvent-Fork-RPC

3 results

This module implements a simple RPC protocol and backend for processes
created via L<AnyEvent::Fork> or L<AnyEvent::Fork::Remote>, allowing you
to call a function in the child process and receive its return values (up
to 4GB serialised).

It implements two different backends: a synchronous one that works like a
normal function call, and an asynchronous one that can run multiple jobs
concurrently in the child, using AnyEvent.

It also implements an asynchronous event mechanism from the child to the
parent, that could be used for progress indications or other information.

=head1 EXAMPLES

=head2 Example 1: Synchronous Backend

   6  requests handled
   /tmp/somepath/6: No such file or directory

Obviously, none of the directories I am trying to delete even exist. Also,
the events and responses are processed in exactly the same order as
they were created in the child, which is true for both synchronous and
asynchronous backends.

Note that the parentheses in the call to C<AnyEvent::Fork::RPC::event> are
not optional. That is because the function isn't defined when the code is
compiled. You can make sure it is visible by pre-loading the correct
backend module in the call to C<require>:


Since the backend module declares the C<event> function, loading it first
ensures that perl will correctly interpret calls to it.

And as a final remark, there is a fine module on CPAN that can
asynchronously C<rmdir> and C<unlink> and a lot more, and more efficiently
than this example, namely L<IO::AIO>.

=head3 Example 1a: the same with the asynchronous backend

This example only shows what needs to be changed to use the async backend
instead. Doing this is not very useful, the purpose of this example is
to show the minimum amount of change that is required to go from the
synchronous to the asynchronous backend.

To use the async backend in the previous example, you need to add the
C<async> parameter to the C<AnyEvent::Fork::RPC::run> call:

      ->AnyEvent::Fork::RPC::run ("MyWorker::run",

C<$done> before or after returning from the function. Third, having both
returned from the function and having called the C<$done> callback, the
child process may exit at any time, so you should call C<$done> only when
you really I<are> done.

=head2 Example 2: Asynchronous Backend

This example implements multiple count-downs in the child, using
L<AnyEvent> timers. While this is a bit silly (one could use timers in the
parent just as well), it illustrates the ability to use AnyEvent in the
child and the fact that responses can arrive in a different order then the


This concludes the async example. Since L<AnyEvent::Fork> does not
actually fork, you are free to use about any module in the child, not just
L<AnyEvent>, but also L<IO::AIO>, or L<Tk> for example.

=head2 Example 3: Asynchronous backend with Coro

With L<Coro> you can create a nice asynchronous backend implementation by
defining an rpc server function that creates a new Coro thread for every
request that calls a function "normally", i.e. the parameters from the
parent process are passed to it, and any return values are returned to the
parent process, e.g.:

The C<run> function creates a new thread for every invocation, using the
first argument as function name, and calls the C<$done> callback on it's
return values. This makes it quite natural to define the C<add> and C<mul>
functions to add or multiply two numbers and return the result.

Since this is the asynchronous backend, it's quite possible to define RPC
function that do I/O or wait for external events - their execution will
overlap as needed.

The above could be used like this:

used to load any modules that provide the serialiser or function. It can
not, however, create events.

=item done => $function (default: C<CORE::exit>)

The function to call when the asynchronous backend detects an end of file
condition when reading from the communications socket I<and> there are no
outstanding requests. It is ignored by the synchronous backend.

By overriding this you can prolong the life of a RPC process after e.g.
the parent has exited by running the event loop in the provided function
(or simply calling it, for example, when your child process uses L<EV> you
could provide L<EV::run> as C<done> function).

The actual API in the child is documented in the section that describes
the calling semantics of the returned C<$rpc> function.

If you want to pre-load the actual back-end modules to enable memory
sharing, then you should load C<AnyEvent::Fork::RPC::Sync> for
synchronous, and C<AnyEvent::Fork::RPC::Async> for asynchronous mode.

If you use a template process and want to fork both sync and async
children, then it is permissible to load both modules.

=item serialiser => $string (default: C<$AnyEvent::Fork::RPC::STRING_SERIALISER>)


=over 4

=item Synchronous Backend

The synchronous backend is very simple: when the process waits for another
request to arrive and the writing side (usually in the parent) is closed,
it will exit normally, i.e. as if your main program reached the end of the
file.

That means that if your parent process exits, the RPC process will usually

shouldn't exit your parent while there are still outstanding requests).

The process is usually quiescent when it happens, so it should rarely be a
problem, and C<END> handlers can be used to clean up.

=item Asynchronous Backend

For the asynchronous backend, things are more complicated: Whenever it
listens for another request by the parent, it might detect that the socket
was closed (e.g. because the parent exited). It will sotp listening for
new requests and instead try to write out any remaining data (if any) or
simply check whether the socket can be written to. After this, the RPC
process is effectively done - no new requests are incoming, no outstanding

Since chances are high that there are event watchers that the RPC server
knows nothing about (why else would one use the async backend if not for
the ability to register watchers?), the event loop would often happily
continue.

This is why the asynchronous backend explicitly calls C<CORE::exit> when
it is done (under other circumstances, such as when there is an I/O error
and there is outstanding data to write, it will log a fatal message via
L<AnyEvent::Log>, also causing the program to exit).

You can override this by specifying a function name to call via the C<done>


=over 4

=item Synchronous

The synchronous backend does not rely on any external modules (well,
except L<common::sense>, which works around a bug in how perl's warning
system works). This keeps the process very small, for example, on my
system, an empty perl interpreter uses 1492kB RSS, which becomes 2020kB
after C<use warnings; use strict> (for people who grew up with C64s around
them this is probably shocking every single time they see it). The worker
process in the first example in this document uses 1792kB.

Since the calls are done synchronously, slow jobs will keep newer jobs
from executing.

The synchronous backend also has no overhead due to running an event loop
- reading requests is therefore very efficient, while writing responses is
less so, as every response results in a write syscall.

If the parent process is busy and a bit slow reading responses, the child
waits instead of processing further requests. This also limits the amount

does something and returns something.

It's hard to use modules or code that relies on an event loop, as the
child cannot execute anything while it waits for more input.

=item Asynchronous

The asynchronous backend relies on L<AnyEvent>, which tries to be small,
but still comes at a price: On my system, the worker from example 1a uses
3420kB RSS (for L<AnyEvent>, which loads L<EV>, which needs L<XSLoader>
which in turn loads a lot of other modules such as L<warnings>, L<strict>,
L<vars>, L<Exporter>...).

view all matches for this distribution

AnyEvent-FriendFeed-Realtime

1 match

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 all matches for this distribution

AnyEvent-Future

2 results

lib/AnyEvent/Future.pm view on Meta::CPAN


This subclass of L<Future> integrates with L<AnyEvent>, allowing the C<await>
method to block until the future is ready. It allows C<AnyEvent>-using code to
be written that returns C<Future> instances, so that it can make full use of
C<Future>'s abilities, including L<Future::Utils>, and also that modules using
it can provide a C<Future>-based asynchronous interface of their own.

For a full description on how to use Futures, see the L<Future> documentation.

=cut

view all matches for this distribution

AnyEvent-GDB

2 results

GDB.pm view on Meta::CPAN

=head1 NAME

AnyEvent::GDB - asynchronous GDB machine interface interface

=head1 SYNOPSIS

   use AnyEvent::GDB;

GDB.pm view on Meta::CPAN


=back

=head2 EVENTS

AnyEvent::GDB is asynchronous in nature, as the goal of the MI interface
is to be fully asynchronous. Due to this, a user of this interface must
be prepared to handle various events.

When an event is produced, the GDB object will look for the following four
handlers and, if found, will call each one in order with the GDB object
and event name (without C<on_>) as the first two arguments, followed by

view all matches for this distribution

AnyEvent-Gearman

4 results

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 all matches for this distribution

AnyEvent-Gmail-Feed

1 match

}
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 all matches for this distribution

AnyEvent-GnuPG

1 match

    my @version = $gpg->version;
    # returns ( 1, 4, 18 ) for example

=head2 version_cb

Asynchronous variant of L</version>.

=head2 gen_key(%params)

This methods is used to create a new gpg key pair. The methods croaks if there is an error. It is a good idea to press random keys on the keyboard while running this methods because it consumes a lot of entropy from the computer. Here are the paramet...

        name => "My name"
    );

=head2 gen_key_cb(%params[, cb => $callback|$condvar])

Asynchronous variant of L</gen_key>.

=head2 import_keys(%params)

Import keys into the GnuPG private or public keyring. The method croaks if it encounters an error. Parameters:

        keys => [qw[ key.pub key.sec ]]
    );

=head2 import_keys_cb(%args[, cb => $callback|$condvar])

Asynchronous variant of L</import_keys>. It returns the number of keys imported.

=head2 import_key($string)

Import one single key into the GnuPG private or public keyring. The method croaks if it encounters an error.


    $gpg->import_keys($string);

=head2 import_key_cb($string[, $callback|$condvar])

Asynchronous variant of L</import_key>.

=head2 export_keys(%params)

Exports keys from the GnuPG keyrings. The method croaks if it encounters an error. Parameters:

        output => "keyring.pub"
    );

=head2 export_keys_cb(%params[, cb => $callback|$condvar])

Asynchronous variant of L</export_keys>.

=head2 encrypt(%params)

This method is used to encrypt a message, either using assymetric or symmetric cryptography. The methods croaks if an error is encountered. Parameters:

        passphrase => $secret
    );

=head2 encrypt_cb(%params[, cb => $callback|$condvar])

Asynchronous variant of L</encrypt>.

=head2 sign(%params)

This method is used create a signature for a file or stream of data.

        armor => 1
    );

=head2 sign_cb(%params[, cb => $callback|$condvar])

Asynchronous variant of L</sign>.

=head2 clearsign(%params)

This methods clearsign a message. The output will contains the original message with a signature appended. It takes the same parameters as the L</sign> method.

=head2 clearsign_cb(%params[, cb => $callback|$condvar])

Asynchronous variant of L</clearsign>.

=head2 verify(%params)

This method verifies a signature against the signed message. The methods croaks if the signature is invalid or an error is encountered. If the signature is valid, it returns an hash with the signature parameters. Here are the method's parameters:

        file => "file.txt"
    );

=head2 verify_cb(%params[, cb => $callback|$condvar])

Asynchronous variant of L</verify>.

=head2 decrypt(%params)

This method decrypts an encrypted message. It croaks, if there is an error while decrypting the message. If the message was signed, this method also verifies the signature. If decryption is sucessful, the method either returns the valid signature par...

        passphrase => $secret
    );

=head2 decrypt_cb(%params[, cb => $callback|$condvar])

Asynchronous variant of L</decrypt>.

=head1 API OVERVIEW

The API is accessed through methods on a AnyEvent::GnuPG object which is a wrapper around the B<gpg> program. All methods takes their argument using named parameters, and errors are returned by throwing an exception (using croak). If you wan't to cat...

view all matches for this distribution

AnyEvent-Groonga

1 match

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 all matches for this distribution

AnyEvent-HTTP-LWP-UserAgent-Determined

1 match

lib/AnyEvent/HTTP/LWP/UserAgent/Determined.pm view on Meta::CPAN


=head1 IMPLEMENTATION

This class works by overriding L<AnyEvent::HTTP::LWP::UserAgent>'s C<simple_request> method
with its own around-method that just loops.  See the source of this
module; it's straightforward with caution of asynchronous nature.

=head1 SEE ALSO

L<LWP>, L<LWP::UserAgent>, L<LWP::UserAgent::Determined>, L<AnyEvent::HTTP>, L<AnyEvent::HTTP::LWP::UserAgent>

view all matches for this distribution

AnyEvent-HTTP-LWP-UserAgent

1 match

lib/AnyEvent/HTTP/LWP/UserAgent.pm view on Meta::CPAN

	    unless ($class->can("authenticate")) {
		$response->header("Client-Warning" =>
				  "Unsupported authentication scheme '$scheme'");
		next CHALLENGE;
	    }
# TODO: Maybe able to be more asynchronous
	    $cv->send($class->authenticate($self, $proxy, $challenge, $response,
					$request, $arg, $size)); return;
	}
	$cv->send($response); return
    }

lib/AnyEvent/HTTP/LWP/UserAgent.pm view on Meta::CPAN

  $cv->recv;

=head1 DESCRIPTION

When you use Coro you have a choice: you can use L<Coro::LWP> or L<AnyEvent::HTTP>
(if you want to make asynchronous HTTP requests).
If you use Coro::LWP, some modules may work incorrectly (for example Cache::Memcached)
because of global change of IO::Socket behavior.
AnyEvent::HTTP uses different programming interface, so you must change more of your
old code with LWP::UserAgent (and HTTP::Request and so on), if you want to make
asynchronous code.

AnyEvent::HTTP::LWP::UserAgent uses AnyEvent::HTTP inside but have an interface of
LWP::UserAgent.
You can safely use this module in Coro environment (and possibly in AnyEvent too).

lib/AnyEvent/HTTP/LWP/UserAgent.pm view on Meta::CPAN

=head1 ASYNC METHODS

The following methods are async version of corresponding methods w/o _async suffix.
Parameters are identical as originals.
However, return value becomes condition variable.
You can use it in a synchronous way by blocking wait

  $ua->simple_request_async(@args)->recv

or in an asynchronous way, also.

  $ua->simple_request_async(@args)->cb(sub { ... });

=over 4

view all matches for this distribution

AnyEvent-HTTP-MXHR

1 match

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 all matches for this distribution

AnyEvent-HTTPD-ExtDirect

2 results

README view on Meta::CPAN

    other gateways like Plack::Middleware::ExtDirect or CGI::ExtDirect, this
    module is in fact more of an application server than just a plugin. You
    can think of it as Plack framework and Plack::Middleware::ExtDirect
    combined into one package.

    That said, the asynchronous event based nature of AnyEvent::HTTPD allows
    using it both as a standalone application server, and as a part of a
    larger program that may do other things besides serving Ext.Direct or
    plain HTTP requests. See "Non-blocking server" below.

    If you are not familiar with Ext.Direct, more information can be found

view all matches for this distribution

AnyEvent-HTTPD

1 match

Changes view on Meta::CPAN

0.71    Sat Aug  8 00:43:58 CEST 2009
        - fixed the published tests. they used Coro.

0.7     Fri Aug  7 15:37:27 CEST 2009
        - fixed documentation in AE::HTTP::Request.
        - added asynchronous response functionality,
          for sending large files via AnyEvent::AIO for instance.
        - added tests to distribution (instead of maintainer only tests).
        - fixed a bug with reception of requests without headers.

0.6     Tue Jul 14 11:16:44 CEST 2009

Changes view on Meta::CPAN

        - fixed a bug in the url() method of AnyEvent::HTTPD::Request where
          the url wasn't get correctly. resulting in bad form behaviour.

0.02    Sat Mar 22 16:09:55 CET 2008
        - rewrote the module API to be more "async".
        - made it possible to respond to requests asynchronously
          in C<AnyEvent::HTTPD>.
        - added lots of example scripts.

0.01    Thu Mar 20 19:53:31 CET 2008
        - first release.

view all matches for this distribution

AnyEvent-Handle-Writer

1 match

use File::Path ();
use FindBin;

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 all matches for this distribution

AnyEvent-Ident

10 results

lib/AnyEvent/Ident.pm view on Meta::CPAN

use Exporter ();

our @ISA = qw( Exporter );
our @EXPORT_OK = qw( ident_server ident_client );

# ABSTRACT: Simple asynchronous ident client and server
our $VERSION = '0.08'; # VERSION


# keep the server object in scope so that
# we don't unbind from the port.  If you

lib/AnyEvent/Ident.pm view on Meta::CPAN


=encoding UTF-8

=head1 NAME

AnyEvent::Ident - Simple asynchronous ident client and server

=head1 VERSION

version 0.08

view all matches for this distribution

AnyEvent-Impl-NSRunLoop

1 match

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 all matches for this distribution

AnyEvent-InfluxDB

6 results

lib/AnyEvent/InfluxDB.pm view on Meta::CPAN

#ABSTRACT: An asynchronous library for InfluxDB time-series database
use strict;
use warnings;
package AnyEvent::InfluxDB;
our $AUTHORITY = 'cpan:AJGB';
$AnyEvent::InfluxDB::VERSION = '1.0.2.0';

lib/AnyEvent/InfluxDB.pm view on Meta::CPAN


=encoding UTF-8

=head1 NAME

AnyEvent::InfluxDB - An asynchronous library for InfluxDB time-series database

=head1 VERSION

version 1.0.2.0

lib/AnyEvent/InfluxDB.pm view on Meta::CPAN


    EV::run;

=head1 DESCRIPTION

Asynchronous client library for InfluxDB time-series database L<https://influxdb.com>.

This version is meant to be used with InfluxDB v1.0.0 or newer.

=head1 METHODS

view all matches for this distribution

AnyEvent-JSONRPC-Lite

1 match

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 all matches for this distribution

AnyEvent-JSONRPC

1 match