Category: Modules
Author/Contact Info Send me a message or visit my home page.
Description:

I've recently been writing tutorials for SDL Perl (and will put them on the new SDL Perl homepage shortly. These are pure-POD tutorials which explain a concept and demonstrate some basic, working code.

I tend to learn best by playing around with code, changing it to see what happens with different parameters and logic. So why not provide a demo program with these tutorials?

It's handy to install POD tutorials as normal modules so they're available to all users on a system. It's a little more difficult to install demo programs, though, unless you also store them in the modules.

You can download Pod::ToDemo from my home page or grab it here. I'm particularly interested in alternate name suggestions before I upload it to the CPAN.

package Pod::ToDemo;

use strict;

use vars '$VERSION';
$VERSION = '0.10';

sub write_demo
{
    my ($filename, $demo) = @_;
    my $caller_package    = (caller())[0];

    die "Usage:\n\t$0 $caller_package <filename>\n"   unless $filename
+;
    die "Cowardly refusing to overwrite '$filename'\n" if  -e $filenam
+e;

    open( my $out, '>', $filename )
        or die "Cannot write '$filename': $!\n";
    print $out $demo;
}

1;
__END__

=head1 NAME

Pod::ToDemo - writes a demo program from a tutorial POD

=head1 SYNOPSIS

    use Pod::ToDemo;

    # write nothing unless used directly
    return 1 if defined caller();

    Pod::ToDemo::write_demo( shift( @ARGV ), "#!$^X\n" . <<'END_HERE')
+;

    use strict;
    use warnings;

    print "Hi, here is my demo program!\n";
    END_HERE

=head1 DESCRIPTION

Pod::ToDemo allows you to write POD-only modules that serve
as tutorials which can write out demo programs if they're
invoked directly.  That is, while L<SDL::Tutorial> is a
tutorial on writing beginner SDL applications with Perl,
you can invoke it as:

    $ perl -MSDL::Tutorial sdl_demo.pl

and it will write a bare-bones demo program called
C<sdl_demo.pl>, based on the
tutorial.

=head1 USAGE

Call C<Pod::ToDemo::write_demo()> with two arguments. 
C<$filename> is the name of the file to write.  If there's
no name, this function will C<die()> with an error message.
If a file already exists with this name, this function will
also C<die()> with another error message.  The second
argument, C<$demo>, is the text of the demo program to
write.

If you're using this in tutorial modules, as you should be,
you will probably want to protect programs that
inadvertently use the tutorial from attempting to write demo
files.  That's what these two lines do:

    # write nothing unless used directly
    return 1 if defined caller();

If there's a defined caller, this module has been used from
another module.  The demo file will only be written if the
module has been used directly.  Note that the returned value
here will be taken as the return value of the module -- it
must be true or the caller's C<use()> will fail!

=head1 AUTHOR

chromatic, E<lt>chromatic@wgz.orgE<gt>

=head1 BUGS

No known bugs.

=head1 COPYRIGHT

Copyright (c) 2003, chromatic.  All rights reserved.  This
module is distributed under the same terms as Perl itself,
in the hope that it is useful but certainly under no
guarantee.
Replies are listed 'Best First'.
Re: Pod::ToDemo
by Aristotle (Chancellor) on Dec 26, 2003 at 23:09 UTC

    I'd suggest sticking to POD but going a step further: extract =begin file foo.pl / =end file POD sections. It would then be Pod::Archive or some such. Could even have =begin uufile to include binary files, such as textures used in an SDL demo.

    I also dislike the semantics of useing the POD file to extract. I'd prefer to have to run it as in something like perl `perldoc -l SDL::Tutorial`. Pod::Archive should then probably check $0 to find the file to extract from, and it should probably take at least a commandline option to pass a destination path.

    Musing on, I could imagine Pod::Archive as a generic way to package miscellaneous files with a script or module; in that case it should actually have an API and only do the selfextractor magic when asked to, maybe as in use Pod::Archive qw(:selfextractor);.

    Hmm. This is big. I don't know if you want to go there. And I'd like to try my hand at it myself, as it'd be something novel and really useful to "christen" my still empty CPAN directory with. It would probably be very neat to have for a number of projects out there (how to distribute extraneous misc files along with a script's distribution tarball was a repeated question on the Gtk2-Perl list), and relying on POD would be robust, unlike the source filter in Inline::Files.

    Makeshifts last the longest.

      I like your ideas, but agree they're getting ahead of my intentions for this module. Pod::Archive sounds like a good idea.

      In the meantime, I'm uploading this now as Pod::ToDemo. It's worth considering whether to extract the demo from POD sections; maybe the next version will do that.

Re: Pod::ToDemo
by princepawn (Parson) on Dec 27, 2003 at 06:07 UTC
    This is an idea worth pursuing:
    1. I don't know where SDL::Tutorial is or how it looks and if certain parts of it are marked as =for code or something. And the links to the SDL site dont help. There is a tutorial there written in PHP.
    2. I personally just create a directory of working code and inline it into POD via Text::Template. The DBIx::Recordset::Playground distribution contains about 20 examples and I inline them using a couple of Text::Template macros I wrote. If people want working code, they just cd to the directory where the code is and run it!

    PApp::SQL and CGI::Application rock the house