in reply to Re (tilly) 1: New sections and move one
in thread New sections and move one

I'm using ActiveState for (yuk!) Windows cause that's my client platform. I have not been able to successfully install a CPAN module (as yet) unless ActiveState had it in it's PPM repository already. (I heard Brian Ingerson is on a leave of absence from ActiveState, when I called to complain that installing from the respository is throwing errors like never before, like missing dependent modules).

Please excuse me quickly throwing together some examples of what I mean. They were quickly tested, but I'm sure someone could make them better! What I'm suggesting is like the following examples. Someone new to Perl could use these right away on faith and learn what they mean after they "Saved the Day!" with their boss or client.

Update: Revised rtrim to use sexeger as suggested below! 
sub rtrim {
    # Right trim spaces
    my @out=@_;
    for (@out) {
        $_ = reverse $_;
        s/^\s+//;
        $_ = reverse $_;
    }
    return wantarray ? @out : $out[0];
}

sub ltrim {
    # Left trim spaces
    my @out=@_;
    for (@out) {
        s/^\s+//;
    }
    return wantarray ? @out : $out[0];
}

sub trim {
    # Trim extra spaces from both left and right
    my @out=@_;
    for (@out) {
        s/^\s+//;
        s/\s+$//;
    }
    return wantarray ? @out : $out[0];
}

sub trimall {
    # Trim all extra spaces from both left and right and middle
    my @out=@_;
    for (@out) {
        $_= join ' ',split;
    }
    return wantarray ? @out : $out[0];
}

[download]
Again, this could be the start of the "String related" category of the Perl Monks' "Subroutine Library." I don't think these kind of onezie subroutines would find a welcome home in CPAN as one routine per submission. If they were in a module, then I have the same 'discovery' and 'install' problems I have today. As onezies they would fail CPANTS for sure not being modules!

..:::::: aquacade ::::::..

Replies are listed 'Best First'.
Still unconvinced, sorry
by tilly (Archbishop) on Aug 12, 2001 at 21:17 UTC
    I remain unconvinced. For pure Perl modules on CPAN I have had good luck under Windows just downloading, untarring, and then copying them manually. Other than the need to find something that will handle .tar.gz files on Windows, I don't see what is gained by having such modules on PerlMonks.

    As for the examples that you give, your routines make perfect sense if you are working in a language like VB with poor string handling capability. But in Perl I, and I think most experienced Perl developers, find it much easier and more reasonable to just inline the regular expressions in question where needed.

    A better example might be something like: 

    # Runs a system command with basic error handling.
sub run_system {
  if ($verbose) {
    my ($cmd, @args) = @_;
    print "Running '$cmd'\n";
    if (@args) {
      print "  with arguments '@args'\n";
    }
  }
  if (system(@_)) {
    my $cmd = shift;
    my $arg_msg = "";
    if (@_) {
      $arg_msg = " with args ['@_']";
    }
    confess("Running '$cmd'$arg_msg failed on return code ($?)\n");
  }
}

    [download]
    But how many truly useful ones are there? The fact is that the built-ins in Perl combined with its flexibility make a lot of the basic utility functions you might write in a different language (VB, C, etc) pretty much useless. I cannot think of enough for me to want a new section. Instead I think that they belong in Snippets. True, that needs improvement (eg making it searchable). Perhaps it should have categories, etc. But I think that it is the right place for this.
[reply]
[d/l]
      I agree with you completely, from your point of view! The very new users I'm thinking of are coming from VB, Java, C, or whatever, could use a "crutch" to get their job done UNTIL they themselves are as you put it "experienced Perl programmers."

      Please step "outside the box" for just a moment where as a new Perl user I'm trying to build a mental bridge from any other programming language to Perl while resynthesizing this knowledge into working code to, in my example stay gainfully employed.

      The subroutines would not only point someone toward WHAT they need to lookup in the Camel and learn, but eliminate the thrashing around with 'how in the heck can I do THAT in Perl.'

      You are greatly respected. Enough that you were a valued reviewer of the new 3rd Llama. I defer to you and other elder wise Monks regarding the value of a "Subroutine Library" section. What I showed is not meant to be a module, but four separate routines showing HOW it could be done in Perl.

      Other personal examples I've needed are: to commatize an integer or float, to round to whole dollars (not trunc), to right or left pad string or number, and so on. Yes I can, with much effort, research, and embarassment, eventually find an answer. I envision the "Subroutine Library" as a companion link to the "New2Perl" link for new Perl users not experts.

      As a contrite Monk, I can only petition for change. I love this site and and thankful for the help I'm receiving. Thanks again for sharing your perspectives!

      ..:::::: aquacade ::::::..

[reply]

        While tilly's perfectly capable of defending himself, I thought I'd point out that there are fewer people able to think outside the box as quickly or clearly as he can. He brings up a fair point; CPAN is more than a module resource, it's also a resource for well (and badly) written code.

        As I'm sure you've noticed by now, we don't like handing out crutches. Programmers have to solve a lot of different types of problems in very different ways, especially Perl programmers. What might be an effective hack for an administrator would be completely inappropriate for a public CGI script. What works on one OS needs a different approach on another. And so on.

        Thus, we prefer to help people learn to build their own solutions, the solutions appropriate for their given specific task and needs. While certain idioms and solutions can be generalized for different situations, these are either a) trivial or b) few and far between. The ones that can be "universally" applicable have already been documented, either in the O'Reilly books, the POD, our archives, and other good resources.

        For example, you asked for:

        Other examples I've needed are commatize a number, right/left pad string or number, etc., etc..

        Guess what. You already have these in a book that you either own or have read in the bookstore; specifically Llama3. There's a very good discussion of commatizing numbers in one of the later chapters, along with a number of discussions of formatting using printf and sprintf. If you've haven't finished the book, yet, hang in there. You'll find starting places for what you're looking for.

        Note: (If you need the page numbers, /msg me. My copy's at work and I'll look them up tomorrow. Since the index of the book was written before the prose, I suspect you can find these discussions using the index.)

        Don't forget that the archives contain a number of discussions from people solving the same problems. The code is in here; you just have to take the initiative, invest in your own learning curve, and suit your code to the action. Experience is the best teacher and you gain experience through practice.

        If you don't, then how will you learn and truly master Perl?

        --f

[reply]
        Other examples I've needed are commatize a number, right/left pad string or number, etc., etc..

        Most of these things exist in the Q&A Section. For these sorts of things, I don't think that we need a new section - they either fall under the category of snippet or Q&A.

        I think that simply reorganising the top menu bar would help new users more than adding even more categories. There has been a lot of talk over the past few months about guides for new users, new user ettiquette etc, but the main problem with all of that was education - new users need to know where to find info. We don't need to create extra things for this, but perhaps just oganise things a little differently.

        Most users have grown accustomed to where to look for things, where to post things, how not to behave etc... but only through experience. I suggest something like the following (structure-wise, I know the design sucks...):

          Site tools Getting help (serious)? Stuff Peer review Fun  
        Monastery Gates Super Search Q & A PerlMonks Discussion Snippets CUFP Newest Nodes
        My Homenode Help Tutorials Meditations Code Obfu  
        Log out Library Seekers of Perl Wisdom Perl News Reviews Poetry Offering Plate


        It should only require a change to a couple of html templates. Importantly, it places less of an emphasis on SOPW, showing that there may be answers already to the question. Also, it should reduce the number of "I need help with foo" posts to discussions and meditations.

        Update: Ok, since this is some-way down the discussion, the indentation makes it look really stupid. But remember I'm talking about layout rather than design. If anyone else thinks this might be useful, we could perhaps start a new discussion and thrash out a design we all like. I don't know what vroom's schedule is like these days, but it should only be a 5 minute copy-and-paste - from my limited familiarity of Everything

        Error: Keyboard not attached. Press F1 to continue.
[reply]
Re: Re: Re (tilly) 1: New sections and move one
by elusion (Curate) on Aug 13, 2001 at 03:42 UTC
    On a slightly off note,
    I think your rtrim example could be improved using sexegers.

    elusion :

[reply]
[d/l]

In Section Perl Monks Discussion