Stories
Slash Boxes
Comments

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/
Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Wednesday January 31, 2007
12:08 AM

PPI::Tiny 0.01 Released!

[ #32286 ]

I admire PPI. It addresses a nearly intractable problem and solves it for almost every case admirably.

However, it's a really big distribution. It contains lots of modules, uses lots of memory, and can be slow. It does a lot.

Sometimes you don't need all of that overhead if you just want to parse a Perl document.

I've written a pure-Perl replacement that implements the barest minimum useful features in the hopes that it will be much more useful to people who want to parse Perl but can't afford the kilobytes of disk space it takes to do the job correctly. Until the CPAN mirrors sync, download PPI::Tiny from my own site.

Be sure to read the documentation carefully; I think I've listed every spot where it doesn't behave exactly like its heavyweight older brother accurately, but I might have missed a few. (In reality, there are only three or four, I believe. I might add those later.)

Enjoy!


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

PPI::Tiny 0.01 Released! 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I think you get to be an honorary Brit now.
  • ... that's like bronzy or steely... what's the word....

  • After reading this discussion [perl.org] I finally got the point...

    :-)

  • All the other Tiny modules outline the cases that they CAN be used for.

    For example, YAML::Tiny is intended to handle META.yml and typical simple config files.

    Second, you fail the criteria for ::Tiny suffixes in that aren't backwards compatible. You fail again because you have dependencies.

    Thirdly, why don't you take patches to add features?

    Fourthly, it's not about the kilobytes of disk, it's about the multimegabytes of ram. People can and have used simple regex miniparser instead of the full PPI module, and

    • ... the criteria I set for ::Tiny modules.

      I consider the other half of the distribution name more important, actually.

      • Fortunately, perfectly suitable modules already exist for people that care about the other half.
  • After both threads, I feel like I'm in 3rd grade again.

    If you don't like *::Tiny, don't use them. If you think they suck, submit a patch. If *::Tiny does what you need, without installed 42 other modules, (most of which in the XML namespace have various levels of compile headaches and lib versioning issues) then awesome.

    Really, what's the big deal again? It feels like quibbling about calling a non-pedigree cat a feline just because it's not a purebred.

    • Really, what's the big deal again?

      CPAN names are rare. They're first-come, first-served. Thus it seems rude to me to claim a namespace for a distribution that doesn't actually do what the name claims.

      There's tremendous potential for confusion among the vast majority of CPAN users who've never read use Perl. That seems, to me, highly unfair.

      I'm also much less of a fan of bandying about strong assertions such as "Oh yeah, well no real user ever really uses this feature or that feature" without some

      • I don't necessarily disagree with your overall naming issues. But if DBI and XML namespaces are so precious, they should be locked down, and registered to the appropriate set of users. But since we don't register namespaces any more on CPAN, game on as it seems.

        If it takes uploading DBI::Tiny (a templating system), CGI::Tiny (a configuration file format parser), Net::Tiny (a program to build and install distributions), and (just for you) Handel::Tiny (an interpreter for ColorForth) to demonstrate to every

        • XML::Tiny does have something to do with XML.

          Perhaps it does in the sense that what it parses bears a superficial resemblance to XML, in the same way that what PPI::Tiny parses bears a very superficial resemblance to what PPI parses.

          XML has a widely-distributed, well-understood, and well-implemented specification. It's easy to test a parser for compliance with the specification. If it fails, it's not an XML parser.

          That was the point of specifying XML.

          XML::Tiny deliberately does not implement th

          • > PPI::Tiny parses bears a very superficial resemblance to what PPI parses.

            Hardly. It bears more of a resemblence to String.pm

            NONE of the Tiny modules are in compliance with the standards they implement, and all of them make quite clear that they are for a very specific use case, and you should move to a real module as soon as it doesn't meet your needs.

            And the argument of implementing something DIFFERENT, as opposed to implementing something incompletely, is a complete straw man argument.
            • NONE of the Tiny modules are in compliance with the standards they implement, and all of them make quite clear that they are for a very specific use case, and you should move to a real module as soon as it doesn't meet your needs.

              In hindsight the bloke probably shouldn't have claimed that he "decided to do XML right" in his original post though ;-)
              • I agree.

                I've never had this sort of flamewar on any of the other Tiny modules, and they all have similar properties to this one.

                I think the main problem here was the somewhat antagonistic attitude of the post.

                • I think the main problem here was the somewhat antagonistic attitude of the post.

                  Exactly.

            • It bears more of a resemblence to String.pm.

              Without a specification, I can't see how anyone can decide what is and isn't PPI. I chose the example pretty carefully.

              YAML::Tiny doesn't parse YAML. That is, I can give it a valid YAML document--perfectly valid, according to the YAML specification--and the module will fail to parse it appropriately. The documentation makes it very clear that you aren't interested in parsing YAML. That's fine, but it makes me wonder why YAML is in the name of the distri

              • Yes, PPI is a suitable grey case, because it's an incomplete but suitably useful implementation of a language which itself does not have a specification. In fact, as I've pointed out in talks, at the deeper levels of understanding "There is no Perl".

                > YAML::Tiny doesn't parse YAML. That is, I can give it a valid YAML document--perfectly valid, according to the YAML specification--and the module will fail to parse it appropriately

                That's not entirely correct.

                If you give it a set of YAML documents, it will
                • What I should also mention here is that I think the argument really comes down to a question of "If you don't implement the full specification of $foo, can you call something a $foo parser".

                  In the sense that YAML::Syck does not parse the entire YAML specification, do we call YAML::Syck "not a YAML parser"?

                  I think there's a place for non-speck parsers, with suitable caveats, when you don't have the resources to run a full parser.

                  • It is fine to reject valid documents if they use format features you do not implement. It isn’t fine to just bumble on, returning junk to the API client. YAML::Tiny does the former. XML::Tiny does the latter. In fact, it will fail to reject a lot of malformed XML documents as well. And on top of it, it mangles the text content so that you cannot recover the original text unambiguously.

                    That is not an XML parser, it isn’t even a parser for a subset of XML. It is just a parser for stuff that ha

                    • Whether ignoring things like processing instructions and entity declarations instead of dealing with them properly means that the results are "junk" is a matter of opinion. In my experience - experience in which I only use XML because it's what some other guy has provided - ignoring them has always been just fine.

                      And on top of it, it mangles the text content so that you cannot recover the original text unambiguously.

                      Aye, and the next release will fix that. Although to be honest I don't consider it to be

                    • When you get & through, you *know* that it was originally &, because you know that I would have translated & :-)

                      Anyway, the shiny new no_entity_parsing and strict_entity_parsing options (on CPAN in the next few days) should fix that.

                • I don't really like the docs for XML::Tiny in that they talk about what the module DOESN'T do, rather than what it DOES do. I hope that will be fixed.
                  That's certainly a change I'm prepared to make. I'll also keep a section on what it doesn't do
      • I'd love to see you do this.
  • You misspelled your own name in the copyright statement at the end of lib/PPI/Tiny.pm. Maybe you need a t/developer/spelling.t?

    Or maybe Test::Spelling::Tiny? :-)

    package Test::Spelling::Tiny;
    use Test::More;
    use base 'Exporter';
    our @EXPORT = qw(spelt_chromatic_ok);
    sub spelt_chromatic_ok {
       my ($str, $desc);
       like $str, qr/chromatic/, $desc;
    }
    1;
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.