Hello community,
here is the log from the commit of package perl-AnyEvent for openSUSE:Factory
checked in at Mon Jul 19 15:09:51 CEST 2010.
--------
--- perl-AnyEvent/perl-AnyEvent.changes 2010-05-05 15:52:23.000000000 +0200
+++ /mounts/work_src_done/STABLE/perl-AnyEvent/perl-AnyEvent.changes 2010-07-06 10:45:51.000000000 +0200
@@ -1,0 +2,15 @@
+Tue Jul 6 08:39:05 UTC 2010 - chris@computersalat.de
+
+- update to 5.271
+ - backport to perl 5.8.x.
+- 5.27 Sun Jun 6 12:12:05 CEST 2010
+ - postpone differently in AnyEvent::Socket now, as
+ when not, canceling the connection attempt might fail
+ (found by Felix Antonius Wilhelm Ostmann).
+ - explicitly check for non-stream sockets in AE::Handle, too many
+ clueless people fell into the trap of this somehow working.
+ - simplified and reworked the "OTHER MODULES" section.
+ - better/more condvar examples.
+- spec created by cpanspec 1.78
+
+-------------------------------------------------------------------
calling whatdependson for head-i586
Old:
----
AnyEvent-5.261.tar.bz2
New:
----
AnyEvent-5.271.tar.bz2
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Other differences:
------------------
++++++ perl-AnyEvent.spec ++++++
--- /var/tmp/diff_new_pack.NWEhfL/_old 2010-07-19 15:06:55.000000000 +0200
+++ /var/tmp/diff_new_pack.NWEhfL/_new 2010-07-19 15:06:55.000000000 +0200
@@ -1,5 +1,5 @@
#
-# spec file for package perl-AnyEvent (Version 5.261)
+# spec file for package perl-AnyEvent (Version 5.271)
#
# Copyright (c) 2010 SUSE LINUX Products GmbH, Nuernberg, Germany.
#
@@ -19,61 +19,63 @@
Name: perl-AnyEvent
-Summary: Provide framework for multiple event loops
-Version: 5.261
+Summary: DBI of event loop programming
+Version: 5.271
Release: 1
License: Artistic License, GPL
Group: Development/Libraries/Perl
-Url: http://search.cpan.org/perldoc?AnyEvent
-Source: http://search.cpan.org/CPAN/authors/id/M/ML/MLEHMANN/AnyEvent-%{version}.tar.bz2
+Url: http://search.cpan.org/dist/AnyEvent/
+#Source: http://www.cpan.org/modules/by-module/AnyEvent/AnyEvent-%{version}.tar.gz
+Source: AnyEvent-%{version}.tar.bz2
+BuildArch: noarch
BuildRoot: %{_tmppath}/%{name}-%{version}-build
BuildRequires: perl
+%if 0%{?suse_version} < 1120
BuildRequires: perl-macros
+%endif
+#
Requires: perl = %{perl_version}
+Recommends: perl(Async::Interrupt) >= 1
+Recommends: perl(EV) >= 3.05
+Recommends: perl(Guard) >= 1.02
Recommends: perl(JSON) >= 2.09
-Recommends: perl(EV) >= 3.4
Recommends: perl(JSON::XS) >= 2.2
-Recommends: perl(Async::Interrupt) >= 1.0
-Recommends: perl(Net::SLeay) >= 1.33
-Recommends: perl(Guard) >= 1.02
-BuildArch: noarch
+Recommends: perl(Net::SSLeay) >= 1.33
%description
-Glib, POE, IO::Async, Event... CPAN offers event models by the dozen nowadays. So what is different about AnyEvent?
-
-Executive Summary: AnyEvent is compatible, AnyEvent is free of policy and AnyEvent is small and efficient.
+AnyEvent provides an identical interface to multiple event loops. This
+allows module authors to utilise an event loop without forcing module users
+to use the same event loop (as only a single event loop can coexist
+peacefully at any one time).
-First and foremost, AnyEvent is not an event model itself, it only interfaces
-to whatever event model the main program happens to use, in a pragmatic way.
-For event models and certain classes of immortals alike, the statement "there
-can only be one" is a bitter reality: In general, only one event loop can be
-active at the same time in a process. AnyEvent cannot change this, but it can
-hide the differences between those event loops.
+The interface itself is vaguely similar, but not identical to the Event
+module.
Author: Marc Lehmann
%prep
-%setup -n AnyEvent-%{version}
+%setup -q -n AnyEvent-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
-%{__make}
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+%{__make} %{?_smp_mflags}
%check
%{__make} test
%install
-make pure_install DESTDIR="%{buildroot}"
-find %{buildroot} -type f -name .packlist -print0 | xargs -0 --no-run-if-empty rm -f
-find %{buildroot} -depth -type d -print0 | xargs -0 --no-run-if-empty rmdir 2>/dev/null || true
+%perl_make_install
+# remove .packlist file
+%{__rm} -rf $RPM_BUILD_ROOT%perl_vendorarch
+# remove perllocal.pod file
+%{__rm} -rf $RPM_BUILD_ROOT%perl_archlib
%perl_gen_filelist
%clean
%{__rm} -rf $RPM_BUILD_ROOT
%files -f %{name}.files
-# normally you only need to check for doc files
-%defattr(-, root, root, 0755)
-%doc COPYING Changes README
+%defattr(-,root,root,-)
+%doc Changes COPYING README
%changelog
++++++ AnyEvent-5.261.tar.bz2 -> AnyEvent-5.271.tar.bz2 ++++++
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/AnyEvent-5.261/Changes new/AnyEvent-5.271/Changes
--- old/AnyEvent-5.261/Changes 2010-04-28 16:13:42.000000000 +0200
+++ new/AnyEvent-5.271/Changes 2010-06-08 12:05:30.000000000 +0200
@@ -1,6 +1,16 @@
Revision history for Perl extension AnyEvent.
-TODO: docs signal for condvar
+5.271 Tue Jun 8 12:05:46 CEST 2010
+ - backport to perl 5.8.x.
+
+5.27 Sun Jun 6 12:12:05 CEST 2010
+ - postpone differently in AnyEvent::Socket now, as
+ when not, canceling the connection attempt might fail
+ (found by Felix Antonius Wilhelm Ostmann).
+ - explicitly check for non-stream sockets in AE::Handle, too many
+ clueless people fell into the trap of this somehow working.
+ - simplified and reworked the "OTHER MODULES" section.
+ - better/more condvar examples.
5.261 Wed Apr 28 16:13:36 CEST 2010
- AF_INET6 was not properly used from Socket6 during configuration
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/AnyEvent-5.261/META.yml new/AnyEvent-5.271/META.yml
--- old/AnyEvent-5.261/META.yml 2010-04-28 16:15:43.000000000 +0200
+++ new/AnyEvent-5.271/META.yml 2010-06-08 12:06:02.000000000 +0200
@@ -1,6 +1,6 @@
--- #YAML:1.0
name: AnyEvent
-version: 5.261
+version: 5.271
abstract: ~
author: []
license: unknown
@@ -14,7 +14,7 @@
directory:
- t
- inc
-generated_by: ExtUtils::MakeMaker version 6.56
+generated_by: ExtUtils::MakeMaker version 6.55_02
meta-spec:
url: http://module-build.sourceforge.net/META-spec-v1.4.html
version: 1.4
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/AnyEvent-5.261/README new/AnyEvent-5.271/README
--- old/AnyEvent-5.261/README 2010-04-28 16:15:43.000000000 +0200
+++ new/AnyEvent-5.271/README 2010-06-08 12:06:02.000000000 +0200
@@ -7,7 +7,7 @@
SYNOPSIS
use AnyEvent;
- # if you prefer function calls, look at the L<AE> manpage for
+ # if you prefer function calls, look at the AE manpage for
# an alternative API.
# file handle or descriptor readable
@@ -473,10 +473,10 @@
Example: fork a process and wait for it
my $done = AnyEvent->condvar;
-
- my $pid = fork or exit 5;
-
- my $w = AnyEvent->child (
+
+ my $pid = fork or exit 5;
+
+ my $w = AnyEvent->child (
pid => $pid,
cb => sub {
my ($pid, $status) = @_;
@@ -484,8 +484,8 @@
$done->send;
},
);
-
- # do something else, then wait for process exit
+
+ # do something else, then wait for process exit
$done->recv;
IDLE WATCHERS
@@ -541,8 +541,8 @@
event loop and will only block when necessary (usually when told by the
user).
- The instrument to do that is called a "condition variable", so called
- because they represent a condition that must become true.
+ The tool to do that is called a "condition variable", so called because
+ they represent a condition that must become true.
Now is probably a good time to look at the examples further below.
@@ -557,13 +557,27 @@
as if it were a callback, read about the caveats in the description for
the "->send" method).
- Condition variables are similar to callbacks, except that you can
- optionally wait for them. They can also be called merge points - points
- in time where multiple outstanding events have been processed. And yet
- another way to call them is transactions - each condition variable can
- be used to represent a transaction, which finishes at some point and
- delivers a result. And yet some people know them as "futures" - a
- promise to compute/deliver something that you can wait for.
+ Since condition variables are the most complex part of the AnyEvent API,
+ here are some different mental models of what they are - pick the ones
+ you can connect to:
+
+ * Condition variables are like callbacks - you can call them (and pass
+ them instead of callbacks). Unlike callbacks however, you can also
+ wait for them to be called.
+
+ * Condition variables are signals - one side can emit or send them,
+ the other side can wait for them, or install a handler that is
+ called when the signal fires.
+
+ * Condition variables are like "Merge Points" - points in your program
+ where you merge multiple independent results/control flows into one.
+
+ * Condition variables represent a transaction - function that start
+ some kind of transaction can return them, leaving the caller the
+ choice between waiting in a blocking fashion, or setting a callback.
+
+ * Condition variables represent future values, or promises to deliver
+ some result, long before the result is available.
Condition variables are very useful to signal that something has
finished, for example, if you write a module that does asynchronous http
@@ -1009,7 +1023,7 @@
The following is a non-exhaustive list of additional modules that use
AnyEvent as a client and can therefore be mixed easily with other
AnyEvent modules and other event loops in the same program. Some of the
- modules come with AnyEvent, most are available via CPAN.
+ modules come as part of AnyEvent, the others are available via CPAN.
AnyEvent::Util
Contains various utility functions that replace often-used but
@@ -1030,50 +1044,44 @@
AnyEvent::DNS
Provides rich asynchronous DNS resolver capabilities.
- AnyEvent::HTTP
- A simple-to-use HTTP library that is capable of making a lot of
- concurrent HTTP requests.
-
- AnyEvent::HTTPD
- Provides a simple web application server framework.
-
- AnyEvent::FastPing
- The fastest ping in the west.
+ AnyEvent::HTTP, AnyEvent::IRC, AnyEvent::XMPP, AnyEvent::GPSD,
+ AnyEvent::IGS, AnyEvent::FCP
+ Implement event-based interfaces to the protocols of the same name
+ (for the curious, IGS is the International Go Server and FCP is the
+ Freenet Client Protocol).
+
+ AnyEvent::Handle::UDP
+ Here be danger!
+
+ As Pauli would put it, "Not only is it not right, it's not even
+ wrong!" - there are so many things wrong with AnyEvent::Handle::UDP,
+ most notably it's use of a stream-based API with a protocol that
+ isn't streamable, that the only way to improve it is to delete it.
+
+ It features data corruption (but typically only under load) and
+ general confusion. On top, the author is not only clueless about UDP
+ but also fact-resistant - some gems of his understanding: "connect
+ doesn't work with UDP", "UDP packets are not IP packets", "UDP only
+ has datagrams, not packets", "I don't need to implement proper error
+ checking as UDP doesn't support error checking" and so on - he
+ doesn't even understand what's wrong with his module when it is
+ explained to him.
AnyEvent::DBI
- Executes DBI requests asynchronously in a proxy process.
+ Executes DBI requests asynchronously in a proxy process for you,
+ notifying you in an event-bnased way when the operation is finished.
AnyEvent::AIO
- Truly asynchronous I/O, should be in the toolbox of every event
- programmer. AnyEvent::AIO transparently fuses IO::AIO and AnyEvent
- together.
-
- AnyEvent::BDB
- Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently
- fuses BDB and AnyEvent together.
-
- AnyEvent::GPSD
- A non-blocking interface to gpsd, a daemon delivering GPS
- information.
-
- AnyEvent::IRC
- AnyEvent based IRC client module family (replacing the older
- Net::IRC3).
-
- AnyEvent::XMPP
- AnyEvent based XMPP (Jabber protocol) module family (replacing the
- older Net::XMPP2>.
-
- AnyEvent::IGS
- A non-blocking interface to the Internet Go Server protocol (used by
- App::IGS).
-
- Net::FCP
- AnyEvent-based implementation of the Freenet Client Protocol,
- birthplace of AnyEvent.
+ Truly asynchronous (as opposed to non-blocking) I/O, should be in
+ the toolbox of every event programmer. AnyEvent::AIO transparently
+ fuses IO::AIO and AnyEvent together, giving AnyEvent access to
+ event-based file I/O, and much more.
- Event::ExecFlow
- High level API for event-based execution flow control.
+ AnyEvent::HTTPD
+ A simple embedded webserver.
+
+ AnyEvent::FastPing
+ The fastest ping in the west.
Coro
Has special support for AnyEvent via Coro::AnyEvent.
@@ -1845,8 +1853,8 @@
before the first watcher gets created, e.g. with a "BEGIN" block:
BEGIN { delete $ENV{PERL_ANYEVENT_MODEL} }
-
- use AnyEvent;
+
+ use AnyEvent;
Similar considerations apply to $ENV{PERL_ANYEVENT_VERBOSE}, as that can
be used to probe what backend is used and gain other information (which
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/AnyEvent-5.261/lib/AnyEvent/Handle.pm new/AnyEvent-5.271/lib/AnyEvent/Handle.pm
--- old/AnyEvent-5.261/lib/AnyEvent/Handle.pm 2010-03-13 21:33:21.000000000 +0100
+++ new/AnyEvent-5.271/lib/AnyEvent/Handle.pm 2010-06-08 12:05:12.000000000 +0200
@@ -1,6 +1,6 @@
=head1 NAME
-AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent
+AnyEvent::Handle - non-blocking I/O on streaming handles via AnyEvent
=head1 SYNOPSIS
@@ -33,7 +33,7 @@
=head1 DESCRIPTION
This module is a helper module to make it easier to do event-based I/O on
-filehandles.
+stream-based filehandles (sockets, pipes or other stream things).
The LAnyEvent::Intro tutorial contains some well-documented
AnyEvent::Handle examples.
@@ -534,6 +534,12 @@
sub _start {
my ($self) = @_;
+ # too many clueless people try to use udp and similar sockets
+ # with AnyEvent::Handle, do them a favour.
+ my $type = getsockopt $self->{fh}, Socket::SOL_SOCKET (), Socket::SO_TYPE ();
+ Carp::croak "AnyEvent::Handle: only stream sockets supported, anything else will NOT work!"
+ if Socket::SOCK_STREAM () != (unpack "I", $type) && defined $type;
+
AnyEvent::Util::fh_nonblocking $self->{fh}, 1;
$self->{_activity} =
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/AnyEvent-5.261/lib/AnyEvent/Socket.pm new/AnyEvent-5.271/lib/AnyEvent/Socket.pm
--- old/AnyEvent-5.261/lib/AnyEvent/Socket.pm 2010-01-11 18:42:05.000000000 +0100
+++ new/AnyEvent-5.271/lib/AnyEvent/Socket.pm 2010-06-05 11:47:32.000000000 +0200
@@ -799,8 +799,10 @@
can be used as a normal perl file handle as well.
Unless called in void context, C returns a guard object that
-will automatically abort connecting when it gets destroyed (it does not do
-anything to the socket after the connect was successful).
+will automatically cancel the connection attempt when it gets destroyed
+- in which case the callback will not be invoked. Destroying it does not
+do anything to the socket after the connect was successful - you cannot
+"uncall" a callback that has been invoked already.
Sometimes you need to "prepare" the socket before connecting, for example,
to C<bind> it to some port, or you want a specific connect timeout that
@@ -896,7 +898,11 @@
return unless exists $state{fh};
my $target = shift @target
- or return (%state = (), _postpone $connect);
+ or return _postpone sub {
+ return unless exists $state{fh};
+ %state = ();
+ $connect->();
+ };
my ($domain, $type, $proto, $sockaddr) = @$target;
diff -urN '--exclude=CVS' '--exclude=.cvsignore' '--exclude=.svn' '--exclude=.svnignore' old/AnyEvent-5.261/lib/AnyEvent.pm new/AnyEvent-5.271/lib/AnyEvent.pm
--- old/AnyEvent-5.261/lib/AnyEvent.pm 2010-04-28 16:13:51.000000000 +0200
+++ new/AnyEvent-5.271/lib/AnyEvent.pm 2010-06-08 12:05:44.000000000 +0200
@@ -9,7 +9,7 @@
use AnyEvent;
- # if you prefer function calls, look at the L<AE> manpage for
+ # if you prefer function calls, look at the AE manpage for
# an alternative API.
# file handle or descriptor readable
@@ -558,8 +558,8 @@
AnyEvent is slightly different: it expects somebody else to run the event
loop and will only block when necessary (usually when told by the user).
-The instrument to do that is called a "condition variable", so called
-because they represent a condition that must become true.
+The tool to do that is called a "condition variable", so called because
+they represent a condition that must become true.
Now is probably a good time to look at the examples further below.
@@ -574,13 +574,29 @@
were a callback, read about the caveats in the description for the C<<
->send >> method).
-Condition variables are similar to callbacks, except that you can
-optionally wait for them. They can also be called merge points - points
-in time where multiple outstanding events have been processed. And yet
-another way to call them is transactions - each condition variable can be
-used to represent a transaction, which finishes at some point and delivers
-a result. And yet some people know them as "futures" - a promise to
-compute/deliver something that you can wait for.
+Since condition variables are the most complex part of the AnyEvent API, here are
+some different mental models of what they are - pick the ones you can connect to:
+
+=over 4
+
+=item * Condition variables are like callbacks - you can call them (and pass them instead
+of callbacks). Unlike callbacks however, you can also wait for them to be called.
+
+=item * Condition variables are signals - one side can emit or send them,
+the other side can wait for them, or install a handler that is called when
+the signal fires.
+
+=item * Condition variables are like "Merge Points" - points in your program
+where you merge multiple independent results/control flows into one.
+
+=item * Condition variables represent a transaction - function that start
+some kind of transaction can return them, leaving the caller the choice
+between waiting in a blocking fashion, or setting a callback.
+
+=item * Condition variables represent future values, or promises to deliver
+some result, long before the result is available.
+
+=back
Condition variables are very useful to signal that something has finished,
for example, if you write a module that does asynchronous http requests,
@@ -1059,7 +1075,7 @@
The following is a non-exhaustive list of additional modules that use
AnyEvent as a client and can therefore be mixed easily with other AnyEvent
modules and other event loops in the same program. Some of the modules
-come with AnyEvent, most are available via CPAN.
+come as part of AnyEvent, the others are available via CPAN.
=over 4
@@ -1084,60 +1100,48 @@
Provides rich asynchronous DNS resolver capabilities.
-=item LAnyEvent::HTTP
+=item LAnyEvent::HTTP, LAnyEvent::IRC, LAnyEvent::XMPP, LAnyEvent::GPSD, LAnyEvent::IGS, LAnyEvent::FCP
-A simple-to-use HTTP library that is capable of making a lot of concurrent
-HTTP requests.
-
-=item LAnyEvent::HTTPD
-
-Provides a simple web application server framework.
-
-=item LAnyEvent::FastPing
-
-The fastest ping in the west.
+Implement event-based interfaces to the protocols of the same name (for
+the curious, IGS is the International Go Server and FCP is the Freenet
+Client Protocol).
+
+=item LAnyEvent::Handle::UDP
+
+Here be danger!
+
+As Pauli would put it, "Not only is it not right, it's not even wrong!" -
+there are so many things wrong with AnyEvent::Handle::UDP, most notably
+it's use of a stream-based API with a protocol that isn't streamable, that
+the only way to improve it is to delete it.
+
+It features data corruption (but typically only under load) and general
+confusion. On top, the author is not only clueless about UDP but also
+fact-resistant - some gems of his understanding: "connect doesn't work
+with UDP", "UDP packets are not IP packets", "UDP only has datagrams, not
+packets", "I don't need to implement proper error checking as UDP doesn't
+support error checking" and so on - he doesn't even understand what's
+wrong with his module when it is explained to him.
=item LAnyEvent::DBI
-Executes L<DBI> requests asynchronously in a proxy process.
+Executes L<DBI> requests asynchronously in a proxy process for you,
+notifying you in an event-bnased way when the operation is finished.
=item LAnyEvent::AIO
-Truly asynchronous I/O, should be in the toolbox of every event
-programmer. AnyEvent::AIO transparently fuses LIO::AIO and AnyEvent
-together.
+Truly asynchronous (as opposed to non-blocking) I/O, should be in the
+toolbox of every event programmer. AnyEvent::AIO transparently fuses
+LIO::AIO and AnyEvent together, giving AnyEvent access to event-based
+file I/O, and much more.
-=item LAnyEvent::BDB
-
-Truly asynchronous Berkeley DB access. AnyEvent::BDB transparently fuses
-L<BDB> and AnyEvent together.
-
-=item LAnyEvent::GPSD
-
-A non-blocking interface to gpsd, a daemon delivering GPS information.
-
-=item LAnyEvent::IRC
-
-AnyEvent based IRC client module family (replacing the older Net::IRC3).
-
-=item LAnyEvent::XMPP
-
-AnyEvent based XMPP (Jabber protocol) module family (replacing the older
-Net::XMPP2>.
-
-=item LAnyEvent::IGS
-
-A non-blocking interface to the Internet Go Server protocol (used by
-LApp::IGS).
-
-=item LNet::FCP
+=item LAnyEvent::HTTPD
-AnyEvent-based implementation of the Freenet Client Protocol, birthplace
-of AnyEvent.
+A simple embedded webserver.
-=item LEvent::ExecFlow
+=item LAnyEvent::FastPing
-High level API for event-based execution flow control.
+The fastest ping in the west.
=item L<Coro>
@@ -1161,7 +1165,7 @@
use Carp ();
-our $VERSION = '5.261';
+our $VERSION = '5.271';
our $MODEL;
our $AUTOLOAD;
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Remember to have fun...
--
To unsubscribe, e-mail: opensuse-commit+unsubscribe@opensuse.org
For additional commands, e-mail: opensuse-commit+help@opensuse.org