commit perl-AnyEvent for openSUSE:Factory

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