view release on metacpan or  search on metacpan

lib/Compress/BraceExpansion.pm  view on Meta::CPAN

=head1 BRACE EXPANSION?

Despite the name, this module does not perform brace expansion.  If it
did, it probably should have been located in the Shell:: heirarchy.
It attempts to do the opposite which might be referred to as 'brace
compression', hence the location it in the Compress:: heirarchy.  The
strings it generates could be used in a shell, but are more likely
useful to make a (potentially) human-readable compressed string.  I
chose the name BraceExpansion since that's the common term, so
hopefully it will be more recognizable than if it were named
BraceCompression.


=head1 CONSTRUCTOR

=over 8

=item C< new( ) >

Returns a reference to a new Compress::BraceExpansion object.

May be initialized with a hash of options:

    Compress::BraceExpansion->new( { strings => [ qw( abc abd ) ] } );

Or with an array ref:

    Compress::BraceExpansion->new( [ qw( abc abd ) ] );

Or with an array:

    Compress::BraceExpansion->new( qw( abc abd ) );

This is an inside-out perl class.  For more info, see "Perl Best
Practices" by Damian Conway

=back


=head1 METHODS

=over 8

=item C<shrink( )>

Perform brace compression on strings.  Returns a string that is
suitable for brace expansion by the shell.

This method has not been designed being called multiple times on the
same Compress::BraceExpansion object.  If you call shrink() more than
once on the same object, you're on your own.

=item C<enable_debug( )>

Enable various internal data structures to be printed to stdout.

=back


=head1 BUGS AND LIMITATIONS

The current algorithm is pretty ugly, and will only compress strings
that start and/or end with similar text.  I've been working on a new
algorithm that uses a weighted trie.

If multiple identical strings are supplied as input, they will only be
represented once in the resulting compressed string.  For example, if
"aaa aaa aab" was supplied as input to shrink(), then the result would
simply be "aa{a,b}".

This module has reasonably fast performance to at least 1000 inputs
strings.  I've run several tests where I cut a 10k word slice from
/usr/share/dict/words and have consistently achieved around 50%
compression.  However, even for strings that are very similar, the
output rapidly loses human readability beyond a couple hundred
characters.

Please report problems to VVu@geekfarm.org.

Patches and suggestions are welcome!


=head1 SEE ALSO

  - brace-compress - included command line script in scripts/ directory

  - http://www.gnu.org/software/bash/manual/bashref.html#SEC27

  - http://zsh.sourceforge.net/Doc/Release/zsh_13.html#SEC60


=head1 AUTHOR

Alex White  C<< <vvu@geekfarm.org> >>


=head1 LICENCE AND COPYRIGHT

Copyright (c) 2006, Alex White C<< <vvu@geekfarm.org> >>. All rights reserved.

All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are
met:

- Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

- Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

- Neither the name of the geekfarm.org nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR