Re: CPAN Testers, and {build,test}_requires.

[Daniel Pittman]

p...@0ne.us p...@0ne.us writes:

 I see that you used Dist::Zilla v2.101040 to build the dist.  Unfortunately,
 there was a bug in the way dzil managed the requires. It simply deleted the
 prereqs instead of managing them intelligently.

[...]

 So, all you need to do is re-release your dist with a updated Dist::Zilla
 and it should work better :)

...done.  Also, I found my humiliating first release bug, which was to ship
code from the scratch repository where I was experimenting with Dist::Zilla
rather than the repository with code that actually, y'know, worked.

So, now 1.1 is up and has real tests and working code.  Plus the less broken
Makefile.PL.  Yay.

 Welcome to CPAN!

Thanks.
Daniel

-- 
✣ Daniel Pittman✉ dan...@rimspace.net☎ +61 401 155 707
   ♽ made with 100 percent post-consumer electrons

Re: XML::Reader

[Klaus]

On Tue, May 11, 2010 at 7:49 AM, Jonathan Rockway j...@jrock.us wrote:

 * On Tue, Apr 27 2010, Klaus wrote:
  I have released XML::Reader (ver 0.34)
  http://search.cpan.org/~keichner/XML-Reader-0.34/lib/XML/Reader.pmhttp://search.cpan.org/%7Ekeichner/XML-Reader-0.34/lib/XML/Reader.pm


by the way, I have now released a new version of XML::Reader (ver 0.35)
with some bug fixes, warts removed, relicensing, etc...
http://search.cpan.org/~keichner/XML-Reader-0.35/lib/XML/Reader.pmhttp://www.google.com/url?sa=Dq=http://search.cpan.org/%7Ekeichner/XML-Reader-0.35/lib/XML/Reader.pmusg=AFQjCNFMDvw04s1jwrzMvJCddJWgkjfcJg


  To explain the module, I have created a small demonstration program
  that extracts XML-subtrees (for example any path that ends with '/.../
  a') memory efficiently.
 
  An XML document can be very large (possibly many gigabytes), but is
  composed of XML-subtrees, each of which is only a few kilobytes in
  size. The demonstration program reads XML-subtrees one by one, only
  the memory for one subtree is held at a time. Each subtree can then be
  processed further at your convenience (for example by using regular
  expressions, or, by using other XML-Modules, such as XML::Simple). In
  principle, XML::Reader has no event driven callback functions, you
  have to loop over the XML-document yourself and the resulting XML-
  subtree is represented in text format.

 So apparently I am rather behind on module-authors, but I just thought
 I'd ask if you've taken a look at XML::Twig?  That seems to be the main
 module for this sort of thing, and seems to have an established
 userbase.  Maybe patches to that would be more productive than
 reinventing the wheel?


Thanks for your message.

I would position XML::Reader in the same space as XML::Twig and
XML::TokeParser.

I have taken a look at XML::Twig which has an established userbase
and I agree in that XML::Reader duplicates many of the functionalities
already provided by XML::Twig.

However, unlike XML::Twig, XML::Reader does not rely on callback
functions to parse the XML. With XML::Reader you loop over the
XML-document yourself and the resulting XML-elements (and/or
XML-subtrees) are represented in text format. This style of processing
XML is similar to the classic pattern:

open my $fh, '', 'file.txt'; while ($fh) { do_sth($_); } close $fh;

This pattern is also implemented by XML::TokeParser. However,
unlike XML::TokeParser, XML::Reader records the full XML path as
it processes the XML-document, therefore it can target not only
specific tags, but it can also target a full path of nested element
tags (a simplified XPath like expression).

I would say that XML::Reader fills an ecological niche that is
neither filled by XML::Twig, nor by XML::TokeParser.

Regards,
Klaus

Re: CPAN Testers, and {build,test}_requires.

[Aristotle Pagaltzis]

* David Golden xda...@gmail.com [2010-05-11 15:40]:
 On Tue, May 11, 2010 at 9:04 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
  * Daniel Pittman dan...@rimspace.net [2010-05-11 05:00]:
  Also, the approach Dist::Zilla takes with the
  'configure_requires' and 'build_requires' keys is to remove
  them when running on an older version of EU:MM.
 
  Is a better approach to add them to 'requires', but only on
  older versions of EU::MM, so that the generated code has
  those extra details on platforms that don't support the
  newer fields?
 
  By the time Makefile.PL runs, it is already too late to
  satisfy an unmet `configure_requires` dependency. There is
  simply nothing you can do on such old installations.

 That's correct but misleading. Newer EU::MM supports
 BUILD_REQUIRES and CONFIGURE_REQUIRES as arguments. Dist::Zilla
 generates a Makefile.PL that deletes those on older EU::MM to
 keep EU::MM from complaining about unknown arguments.

That is still incomplete if you really want to be explicit about
the conditions to which the deletion of these keys is relevant,
owing to the fact that Makefile.PL was designed to do double duty
for both end users and distribution authors.

Dist::Zilla splits the distribution author parts from the end
user parts of the toolchain, and confines Makefile.PL to the
latter role. And to end users, only the `configure_requires` key
in the dzil-generated META file is relevant, which cannot be
emulated from within Makefile.PL.

 Dist::Zilla does correctly add configure_requires to META and
 the generated Makefile.PL has:

use ExtUtils::MakeMaker 6.31;

Yes, Dist::Zilla takes over the distribution author part of the
toolchain responsibilities, and ticks all the boxes there.

 None of that is really relevant to the situation at hand, which
 is about a build requirement for Test::More not being met.

Naturally, since it was a tangential inquiry that Daniel included
in his post and Apocalypse didn’t address.

Regards,
-- 
Aristotle Pagaltzis // http://plasmasturm.org/

Re: XML::Reader

[Klaus]

On Tue, May 11, 2010 at 4:14 PM, Dana Hudes dhu...@hudes.org wrote:
 Klaus,
 Thanks for contributing to CPAN

Dana,
Thanks for your message

 From: Klaus klau...@gmail.com
 Date: Tue, 11 May 2010 10:10:33 +0200
  I would position XML::Reader in the same space as XML::Twig
  and XML::TokeParser.
 
  I have taken a look at XML::Twig which has an established
  userbase and I agree in that XML::Reader duplicates many of
  the functionalities already provided by XML::Twig.
 
  However, unlike XML::Twig, XML::Reader does not rely on
  callback functions to parse the XML. With XML::Reader you
  loop over the XML-document yourself and the resulting XML-
  elements (and/or XML-subtrees) are represented in text format.
  This style of processing XML is similar to the classic pattern:
 
  open my $fh, '', 'file.txt'; while ($fh) { do_sth($_); } close $fh;
 
  This pattern is also implemented by XML::TokeParser. However,
  unlike XML::TokeParser, XML::Reader records the full XML path
  as it processes the XML-document, therefore it can target not
  only specific tags, but it can also target a full path of nested
  element tags (a simplified XPath like expression).
 
  I would say that XML::Reader fills an ecological niche that is
  neither filled by XML::Twig, nor by XML::TokeParser.

 On the question of callbacks: This is Perl, there's more than way
 to do it (whatever 'it' is ). That said the use of callbacks is very
 Perlish. Indeed Perl itself uses callbacks in it's builtins: look at
 sort(), the comparison function is a callback.

I agree, callbacks are Perlish. However, what my module wants to
achieve is not necessarily being Perlish, but most importantly it
wants to provide an alternative way of processing XML. (as you
said, there is more than one way to do it).

 It is also true that while callbacks provide a clean interface
 (instead of overloading a generic object method, for example) you
 are adding another function call to processing. But instead of
 having a clean function call you have substituted calling an
 iterator from your object. This is actually more costly.

Also agreed.

In XML::Reader, I have added layers of abstraction to provide the
alternative interface. This is costly in terms of CPU. I see
this cost as consequence of the design. Having said this, I am
always looking for improvements to the performance of XML::Reader.

While we are talking about performance, we should also mention
memory consumption. XML::Reader uses pure text representation
to produce XML subtrees which is very memory efficient. If we
compare this to similar modules that use the DOM-approach to
represent XML-subtrees, we find that memory consumption is
better with XML::Reader.

 Look at XML::Simple. You get back a data structure and deal with
 it yourself using native Perl iteration (foreach). You can then do
 whatever you want: write to a file, find the piece you want or do
 some tranformation and turn it back into XML.

Coincidently, XML::Simple is a good example of how XML::Reader
cooperates nicely with existing modules.

The following example assumes that we are dealing with a huge
XML-file that does not fit entirely into memory for XML::Simple.
Therefore the strategy is to extract smaller sized sub-trees from
the XML file, each sub-tree fits into memory and can be
processed by XML::Simple.

As I already posted on comp.lang.perl.misc

subject Get XML content using XML::Twig
http://groups.google.com/group/comp.lang.perl.misc/msg/8ec3a393e37ae8f4

 [...]
 As I said before, take the advice of Tad McClellan and John
 Bokma first. If, for whatever reason, you can't follow their
 advice, (and, for whatever reason, you can't use XML::Twig
 either) there is always my shameless plug XML::Reader.
 [...]

later post, same subject Get XML content using XML::Twig
http://groups.google.com/group/comp.lang.perl.misc/msg/390696dd67c3939d

 This new version allows to write the same program (...the
 program that uses XML::Reader to capture sub-trees from
 a potentially very big XML file into a buffer and pass that
 buffer to XML::Simple...) even shorter:

 use strict;
 use warnings;
 use XML::Reader 0.34;

 use XML::Simple;
 use Data::Dumper;

 my $rdr = XML::Reader-newhd(\*DATA, {filter = 5},
{ root = '/Data/ConnectionList/Connection/FileItemList
 /FileItem/FileType', branch = '*' },
  );
 while ($rdr-iterate) {
my $buffer = $rdr-rval;
my $ref = XMLin($buffer);
print Dumper($ref), \n\n;
 }

Usage of wantarray

[Lutz Gehlen]

Hello everybody,
recently, I read the following statement in a CPAN Ratings entry:
this package also uses wantarray (a transgression amongst interface
sensibilities).

I also sometimes use wantarray and don't see anything bad about it
if the behaviour is documented (which should also be the case
otherwise). I wondered if the above statement reflects the general
opinion among experienced Perl authors. If yes I would be interested
in the reasons.

Thank you for your comments
Lutz

Re: XML::Reader

[Dana Hudes]

Klaus,
Thanks for contributing to CPAN 

On the question of callbacks: This is Perl, there's more than way to do it 
(whatever 'it' is ). That said the use of callbacks is very Perlish. Indeed 
Perl itself uses callbacks in it's builtins: look at sort(), the comparison 
function is a callback. 

It is also true that while callbacks provide a clean interface (instead of 
overloading a generic object method, for example) you are adding another 
function call to processing. But instead of having a clean function call you 
have substituted calling an iterator from your object. This is actually more 
costly. 

Look at XML::Simple. You get back a data structure and deal with it yourself 
using native Perl iteration (foreach). You can then do whatever you want: write 
to a file, find the piece you want or do some tranformation and turn it back 
into XML.  
Sent from my BlackBerry® smartphone with Nextel Direct Connect

-Original Message-
From: Klaus klau...@gmail.com
Date: Tue, 11 May 2010 10:10:33 
To: Jonathan Rockwayj...@jrock.us
Cc: module-authors@perl.org
Subject: Re: XML::Reader

On Tue, May 11, 2010 at 7:49 AM, Jonathan Rockway j...@jrock.us wrote:

 * On Tue, Apr 27 2010, Klaus wrote:
  I have released XML::Reader (ver 0.34)
  http://search.cpan.org/~keichner/XML-Reader-0.34/lib/XML/Reader.pmhttp://search.cpan.org/%7Ekeichner/XML-Reader-0.34/lib/XML/Reader.pm


by the way, I have now released a new version of XML::Reader (ver 0.35)
with some bug fixes, warts removed, relicensing, etc...
http://search.cpan.org/~keichner/XML-Reader-0.35/lib/XML/Reader.pmhttp://www.google.com/url?sa=Dq=http://search.cpan.org/%7Ekeichner/XML-Reader-0.35/lib/XML/Reader.pmusg=AFQjCNFMDvw04s1jwrzMvJCddJWgkjfcJg


  To explain the module, I have created a small demonstration program
  that extracts XML-subtrees (for example any path that ends with '/.../
  a') memory efficiently.
 
  An XML document can be very large (possibly many gigabytes), but is
  composed of XML-subtrees, each of which is only a few kilobytes in
  size. The demonstration program reads XML-subtrees one by one, only
  the memory for one subtree is held at a time. Each subtree can then be
  processed further at your convenience (for example by using regular
  expressions, or, by using other XML-Modules, such as XML::Simple). In
  principle, XML::Reader has no event driven callback functions, you
  have to loop over the XML-document yourself and the resulting XML-
  subtree is represented in text format.

 So apparently I am rather behind on module-authors, but I just thought
 I'd ask if you've taken a look at XML::Twig?  That seems to be the main
 module for this sort of thing, and seems to have an established
 userbase.  Maybe patches to that would be more productive than
 reinventing the wheel?


Thanks for your message.

I would position XML::Reader in the same space as XML::Twig and
XML::TokeParser.

I have taken a look at XML::Twig which has an established userbase
and I agree in that XML::Reader duplicates many of the functionalities
already provided by XML::Twig.

However, unlike XML::Twig, XML::Reader does not rely on callback
functions to parse the XML. With XML::Reader you loop over the
XML-document yourself and the resulting XML-elements (and/or
XML-subtrees) are represented in text format. This style of processing
XML is similar to the classic pattern:

open my $fh, '', 'file.txt'; while ($fh) { do_sth($_); } close $fh;

This pattern is also implemented by XML::TokeParser. However,
unlike XML::TokeParser, XML::Reader records the full XML path as
it processes the XML-document, therefore it can target not only
specific tags, but it can also target a full path of nested element
tags (a simplified XPath like expression).

I would say that XML::Reader fills an ecological niche that is
neither filled by XML::Twig, nor by XML::TokeParser.

Regards,
Klaus

Re: XML::Reader

[Jonathan Rockway]

* On Tue, May 11 2010, Klaus wrote:
 However, unlike XML::Twig, XML::Reader does not rely on callback
 functions to parse the XML. With XML::Reader you loop over the
 XML-document yourself and the resulting XML-elements (and/or
 XML-subtrees) are represented in text format. This style of processing
 XML is similar to the classic pattern:

 open my $fh, '', 'file.txt'; while ($fh) { do_sth($_); } close $fh;

FWIW, it's very easy to make callback-based code look like an iterator.
Here's an example script.

  use strict;
  use warnings;
  use feature ':5.10';

  use Coro;
  use Coro::Handle;
  use Coro::Channel;

Imagine you have a routine that calls a callback for each event, like
receiving a line from a filehandle:

  sub call_on_line(){
  my $cb = shift;
  async {
  my $fh = unblock \*STDIN;
  while(my $line = $fh-readline){
  chomp $line;
  $cb-($line);
  }
  };
  }

(Ignore the implementation here, it's just an example.)

You can loop over the results of the callback, like this:

  my $chan = Coro::Channel-new;

  call_on_line { $chan-put(@_) };

  async {
  while(my $item = $chan-get) {
  say GOT ITEM: $item;
  }
  }-join;

So I'm not sure there's a point in writing a module just to be
loop-driven instead of callback-driven; it's easy to convert
callback-based code to blocking code.

When in doubt, if you are trying to write something reusable, make it
callback-driven instead of blocking.  Then the consumer can easily
choose how to use it.

Regards,
Jonathan Rockway

--
print just = another = perl = hacker = if $,=$