Loading ...
Sorry, an error occurred while loading the content.

Request for Assistance with Module: List-Compare

Expand Messages
  • James E Keenan
    I would like to request the assistance of fellow members of Perl Seminar NY in testing a Perl module I have just written called List::Compare. Pleased find
    Message 1 of 8 , Jun 9, 2002
    • 0 Attachment
      I would like to request the assistance of fellow members of Perl Seminar NY
      in testing a Perl module I have just written called List::Compare. Pleased
      find attached a tar file List-Compare-0.05.tar.gz.

      I would ask that you try to install this module on your system using the
      normal 'make' or make-like procedure (e.g., 'nmake' on Windows) that you
      would use to install a module you had just downloaded from CPAN.

      I am interested in hearing whether (a) the module installs properly; (b) the
      module works; and (c) the documentation is useful.

      Since this is the first module I have attempted to build, per instructions
      from the Camel book, the Cookbook and various perldoc, ...

      ... and since this is the first module I've written which I would like to
      upload to CPAN ...

      ... I'd like to get some comments before I make a fool of myself by
      uploading a defective module.

      So far I've installed this on Windows (Win98SE) and Linux (Red Hat 7.2).
      I'd be interested in hearing whether it successfully installs on Macintosh,
      other *nix OSs, etc.

      Thanks in advance.

      Jim Keenan
      jkeen@...
    • Josh Rabinowitz
      The docs look pretty good, James, and the module builds and self-tests fine. I just have the two comments I had before, plus another few: 1) I d suggest this
      Message 2 of 8 , Jun 10, 2002
      • 0 Attachment
        The docs look pretty good, James, and the module builds and self-tests fine.

        I just have the two comments I had before, plus another few:

        1) I'd suggest this module is pretty inefficient and is not really
        appropriate for any large-scale use. If I want to compute just the
        intersection of two sets, your library also computes a bunch of other
        sets I may not need. Perhaps defer each computation until they ask
        for it, and avoid computing extra stuff the user may not ask for.

        2) Set::Scalar does almost all the same things (if not all the same
        things), and I bargain it does them more efficiently and flexibly.
        Check it out. Ideally your module would provide at least one
        non-trivial function that Set::Scalar does not.

        3) I'd avoid using multiple function (method) names that do the exact
        same thing. (IE your methods get_symdiff() and
        get_symmetric_difference()). It creates confusion for users and extra
        work for the maintainer (you). I'd suggest just making one method
        (named well) for each purpose.

        4) It probably belongs more in the Set:: namespace than the List::
        namespace... check out existing modules in each namespace to see for
        yourself. I'd suggest perhaps Set::Compare.

        5) Also mention Set::Scalar in your perldocs and why users would use
        one library or another. You may want to contact the author of
        Set::Scalar for input too.

        6) Have you contact comp.lang.perl.modules or modules@... for
        feedback too, as recommended at
        http://www.cpan.org/modules/04pause.html ?

        I'd definitely recommend getting Set::Scalar to work for you and
        making your module better/different (if it makes sense) before
        submitting to CPAN. According to its perldocs, Set::Scalar has
        methods for:
        $u = $s->union($t);
        $i = $s->intersection($t);
        $d = $s->difference($t);
        $e = $s->symmetric_difference($t);
        $v = $s->unique($t);
        $c = $s->complement;
        among others. If you need help getting Set::Scalar to do what you
        want, write back or read the perldocs for Set::Scalar more carefully.

        Josh "joshr" Rabinowitz
        joshr Perl Training: http://joshr.com/html/perl_training.html

        >I would like to request the assistance of fellow members of Perl Seminar NY
        >in testing a Perl module I have just written called List::Compare. Pleased
        >find attached a tar file List-Compare-0.05.tar.gz.
        >
        >I would ask that you try to install this module on your system using the
        >normal 'make' or make-like procedure (e.g., 'nmake' on Windows) that you
        >would use to install a module you had just downloaded from CPAN.
        >
        >I am interested in hearing whether (a) the module installs properly; (b) the
        >module works; and (c) the documentation is useful.
        >
        >Since this is the first module I have attempted to build, per instructions
        >from the Camel book, the Cookbook and various perldoc, ...
        >
        >... and since this is the first module I've written which I would like to
        >upload to CPAN ...
        >
        >... I'd like to get some comments before I make a fool of myself by
        >uploading a defective module.
        >
        >So far I've installed this on Windows (Win98SE) and Linux (Red Hat 7.2).
        >I'd be interested in hearing whether it successfully installs on Macintosh,
        >other *nix OSs, etc.
        >
        >Thanks in advance.
        >
        >Jim Keenan
        >jkeen@...
        >
        >Content-Type: application/x-gzip;
        > name="List-Compare-0.05.tar.gz"
        >Content-Disposition: attachment;
        > filename="List-Compare-0.05.tar.gz"
        >
        >Attachment converted: HD:List-Compare-0.05.tar.gz (????/----) (000E41D0)
      • Glenn Maciag
        Jim, I was able to install it on Macintosh OS 8.1 successfully using the tools provided with MacPerl. Because I m only running the 5.004 version of MacPerl, I
        Message 3 of 8 , Jun 10, 2002
        • 0 Attachment
          Jim, I was able to install it on Macintosh OS 8.1 successfully using the tools
          provided with MacPerl. Because I'm only running the 5.004 version of MacPerl,
          I had to make a couple of minor edits to the module to get it to run (you might
          actually want to consider doing that yourself for greater compatability), but
          once I did that it worked. The one thing which surprised me was that
          duplicates within a set were not preserved. But I see that you've mentioned
          that in the docs.

          The documentation looks fine. Some of the formatting, especially around the
          urls, look a little strange, but I'm betting that's due to my old version of
          MacPerl and has nothing to do with you. One thing you might want to edit out,
          though, is this line:

          # Below is stub documentation for your module. You better edit it!

          Glenn
        • gbens
          Jim, It installed properly on Mac OS X. I will look into testing and docs later this week, and also try to install on Mac OS 9 with MacPerl. grb
          Message 4 of 8 , Jun 10, 2002
          • 0 Attachment
            Jim,

            It installed properly on Mac OS X. I will look into testing and docs later this week,
            and also try to install on Mac OS 9 with MacPerl.

            grb
            --- In perlsemny@y..., "James E Keenan" <jkeen@c...> wrote:
            > I would like to request the assistance of fellow members of Perl Seminar NY
            > in testing a Perl module I have just written called List::Compare. Pleased
            > find attached a tar file List-Compare-0.05.tar.gz.
            >
            > I would ask that you try to install this module on your system using the
            > normal 'make' or make-like procedure (e.g., 'nmake' on Windows) that you
            > would use to install a module you had just downloaded from CPAN.
            >
            > I am interested in hearing whether (a) the module installs properly; (b) the
            > module works; and (c) the documentation is useful.
            >
            > Since this is the first module I have attempted to build, per instructions
            > from the Camel book, the Cookbook and various perldoc, ...
            >
            > ... and since this is the first module I've written which I would like to
            > upload to CPAN ...
            >
            > ... I'd like to get some comments before I make a fool of myself by
            > uploading a defective module.
            >
            > So far I've installed this on Windows (Win98SE) and Linux (Red Hat 7.2).
            > I'd be interested in hearing whether it successfully installs on Macintosh,
            > other *nix OSs, etc.
            >
            > Thanks in advance.
            >
            > Jim Keenan
            > jkeen@c...
          • Soren Andersen
            On Sun, 9 Jun 2002 14:36:23 -0400, James E Keenan ... Installs ok on Cygwin-Perl (Win98SE). No problems that I can see with how you ve got the module laid
            Message 5 of 8 , Jun 11, 2002
            • 0 Attachment
              On Sun, 9 Jun 2002 14:36:23 -0400, "James E Keenan"
              <jkeen@...> said:
              > I would like to request the assistance of fellow members of Perl
              > Seminar NY in testing a Perl module I have just written called
              > List::Compare. Pleased find attached a tar file
              > List-Compare-0.05.tar.gz.
              >
              > I would ask that you try to install this module on your system
              > using the normal 'make' or make-like procedure (e.g., 'nmake' on
              > Windows) that you would use to install a module you had just
              > downloaded from CPAN.
              >
              > I am interested in hearing whether (a) the module installs properly;
              > (b) the module works; and (c) the documentation is useful.

              Installs ok on Cygwin-Perl (Win98SE). No problems that I can see with
              how you've got the module laid out. No comment on the useability or
              other factors, I noted that you've already gotten feedback in that vein
              from other readers.

              My Perl: 5.6.1.

              Regards,
              Soren Andersen

              --
              The makefiles which eventually result from using 'automake' 1.5x are monstrosities. Sheer hellish madness. Several dozen targets, named obscene things like "am_remake_your_mother"; utterly counter-intuitive, buried in 4 or 5 levels of indirection, swamped in a thousand lines of baffling, migraine-inducing auto-generated superfluity. [These] Makefiles ought to be taken out and bled to death slowly, shot, burned, staked through the heart, generally Buffy-ated to the maximum possible extent.
              -- Soren Andersen (me) in
              <http://groups.google.com/groups?selm=Xns91D2A2408EF9Dsorenngrp89%4064.8.1.226>


              --
              http://fastmail.fm/ - The professional email service
            • James E Keenan
              ... From: Josh Rabinowitz To: Sent: Monday, June 10, 2002 7:20 AM Subject: Re: [perlsemny] Request
              Message 6 of 8 , Jun 13, 2002
              • 0 Attachment
                ----- Original Message -----
                From: "Josh Rabinowitz" <joshr-perlsemny@...>
                To: <perlsemny@yahoogroups.com>
                Sent: Monday, June 10, 2002 7:20 AM
                Subject: Re: [perlsemny] Request for Assistance with Module: List-Compare

                > 1) I'd suggest this module is pretty inefficient and is not really
                > appropriate for any large-scale use. If I want to compute just the
                > intersection of two sets, your library also computes a bunch of other
                > sets I may not need. Perhaps defer each computation until they ask
                > for it, and avoid computing extra stuff the user may not ask for.
                >
                I don't think efficiency in "large-scale use" is the point of the original
                (Cookbook) code or of my OO-implementation; simplicity and clarity is the
                point. If on your day job you have to maintain a web or database server
                that has to do lots of comparisons among lists of, say >10E6 size, then you
                perhaps should look elsewhere. On my day job, the lists I need to compare
                are all of < 10E3 size ... so no script in which I've used List::Compare has
                ever taken more than 1 second to execute!

                I would also argue that this code is clear enough that it would prove
                heuristically useful if one were teaching intermediate level Perl students
                an introduction to object-oriented Perl.

                > 2) Set::Scalar does almost all the same things (if not all the same
                > things), and I bargain it does them more efficiently and flexibly.
                > Check it out. Ideally your module would provide at least one
                > non-trivial function that Set::Scalar does not.
                > [snip]
                > I'd definitely recommend getting Set::Scalar to work for you and
                > making your module better/different (if it makes sense) before
                > submitting to CPAN. According to its perldocs, Set::Scalar has
                > methods for:
                > $u = $s->union($t);
                > $i = $s->intersection($t);
                > $d = $s->difference($t);
                > $e = $s->symmetric_difference($t);
                > $v = $s->unique($t);
                > $c = $s->complement;

                I had studied Set::Scalar before making the presentation at perlsemny last
                month and, at your suggestion, re-studied it. Set::Scalar *does* return
                intersections, unions and quite a few other things, but (as your citations
                from Set::Scalar's POD above demonstrate) in every instance it returns these
                things as *strings* rather than lists. To be specific, Set::Scalar returns
                always returns strings like this:

                (alpha beta gamma delta)

                that is: an open paren, the 1st element, a wordspace, the 2nd element, a
                wordspace ... the last element, a close paren. That's very useful if you
                want a clean typographic representation of a set, but not if what you really
                want is the values in a set. It's almost as if Set::Scalar is a fancy
                'sprintf'. Indeed, the section of the Set::Scalar POD from which you quote
                is called "Displaying."

                > 3) I'd avoid using multiple function (method) names that do the exact
                > same thing. (IE your methods get_symdiff() and
                > get_symmetric_difference()). It creates confusion for users and extra
                > work for the maintainer (you). I'd suggest just making one method
                > (named well) for each purpose.
                >
                They're simple aliases, so it's no more work for me. I offer them in the
                spirit of TIMTOWTDI. I have revised the documentation to spell out that
                they're just aliases, so I think most Perl users will understand. And, in
                any case, it's not unprecedented: Set::Scalar, for instance, provides
                aliases for at least 4 of its methods!

                > 4) It probably belongs more in the Set:: namespace than the List::
                > namespace... check out existing modules in each namespace to see for
                > yourself. I'd suggest perhaps Set::Compare.
                >
                I disagree. When I was developing this module I was concerned with
                comparing lists, not with comparing or displaying sets. If I was working in
                the field of mathematical set theory, I would go to the Set namespace. But
                I'm not and I think most Perl users will think first of comparing lists
                rather than comparing sets.

                > 5) Also mention Set::Scalar in your perldocs and why users would use
                > one library or another. You may want to contact the author of
                > Set::Scalar for input too.
                >
                The latest version of the module, available at
                http://www.concentric.net/~Jkeen/list/List-Compare-0.07.tar.gz
                contains POD revised to include an extensive discussion of 4 similar or
                similarly-named modules.

                > 6) Have you contact comp.lang.perl.modules or modules@... for
                > feedback too, as recommended at
                > http://www.cpan.org/modules/04pause.html ?
                >
                Yes. I've posted on both module@... and on comp.lang.perl.modules.
                I've gotten some feedback from Dave Cross (author of Array::Compare) and
                Terrence Brannon (author of an extension to one of the other modules I
                discuss in the POD, Graham Barr's List::Util) and have contacted Jarkko
                Hietaniemi (author of Set::Scalar) as well.

                Jim Keenan
                jkeen@...
              • Josh Rabinowitz
                Hi Jim, PerlSemNY members; Many of your points are reasonable, Jim, and though I don t agree with almost any of your conclusions, TMTOWDI all the way. While
                Message 7 of 8 , Jun 14, 2002
                • 0 Attachment
                  Hi Jim, PerlSemNY members;

                  Many of your points are reasonable, Jim, and though I don't agree
                  with almost any of your conclusions, TMTOWDI all the way.

                  While your module may be an illustrative example, I try not to teach
                  what I consider poor programming styles that students will probably
                  eventually need to unlearn (such as computing
                  computationally-expensive data that is likely to never be requested
                  -- soon the students will write code opening and closing the same
                  file over and over in a tight loop instead of opening and closing it
                  once! :)

                  Now, two corrections.

                  1) First of all, the snippet I pulled from the Set::Scalar perldocs
                  were not from the Displaying segment of the docs, but from the
                  Querying segment-- I just checked. (I've been using Set::Scalar
                  version 1.17). Further reading of the Set::Scalar perldocs reveals
                  that:

                  2) While some Set::Scalar comparison methods _do_ return strings
                  (such as "equal", "disjoint", and "proper subset"), the ones relevant
                  to our discussion (such as intersection(), union(), and the other
                  methods that make sense to have return sets) return Set::Scalar
                  objects.

                  I suspect your stringification confusion stems from the fact that
                  when these Set::Scalar objects are placed in double quotes, they wind
                  up using the Set::Scalar::as_string_callback() function to get
                  converted to strings like
                  (1 2 3 4).

                  However, if you call members() on the _Set::Scalar object_ returned
                  by methods like union() and intersection(), you get the list of
                  elements (as a true perl array!).

                  You might want to update your docs to reflect this -- I wholly
                  disagree that Set::Scalar "is focused on returning a typographically
                  succinct string containing the members of the resultant set" --
                  though it does provide that (trivial) function nicely.

                  Here's a small perl program to prove all I state about Set::Scalar:

                  ----- test-set-scalar.pl -----
                  #!/usr/local/bin/perl -w
                  use strict;

                  # script to prove that pertinent Set::Scalar set methods return
                  # Set::Scalar objects, not strings

                  use Set::Scalar;

                  # set up two Set::Scalars
                  my $s = Set::Scalar->new(qw( 1 2 3 4 5 10 11 12 13 14));
                  my $s2 = Set::Scalar->new(qw( 1 2 4 5 6 10 11 13 14 14));

                  #compute the intersection
                  my $intersection = $s->intersection($s2);

                  # $intersection is a Set::Scalar object that when viewed in a
                  # scalar context, appears like a string
                  print "Jim says you get a string back, ok:\n";
                  print "$intersection\n";
                  print " -- but that's a conversion from the \$intersection object\n";

                  # If you call the members() function of the $intersection object
                  # (it is _not_ a string!), then you get the list members

                  print "Watch, just call members() and you get the list out!\n";

                  my @intersect_list = $intersection->members(); # like so...
                  # note that @intersect_list is a true list

                  print "intersection is " . join(", ", @intersect_list ) . "\n";
                  __END__

                  So what I said about RTFM still holds. I suppose I should have
                  pointed out the members() method earlier, but I didn't realize this
                  thread would go so far before somebody picked up the reference.

                  And OK, I'll bite... what's the fundamental difference between a Set
                  and a List that makes you conclude that it belongs in the List::
                  namespace and not the Set:: namespace? I assume Lists preserve
                  ordering and duplicates, and Sets do not?

                  I agree that your new module properly and correctly should be placed
                  according to the definition of what a Set and a List is, and which
                  your module more closely models. If it models Lists, then put it in
                  the List:: namespace.

                  In summary, TMTOWDI, but I still unwaveringly hold almost each and
                  every one of my above (and below) stated opinions, with the exception
                  that perhaps it does make sense for a module with the functionality
                  yours has to go into the List:: namespace.

                  Sometimes I think that actual module writing is less work than
                  explaining it, figuring out how it should work, be named, and return
                  stuff!

                  joshr

                  >----- Original Message -----
                  >From: "Josh Rabinowitz" <joshr-perlsemny@...>
                  >To: <perlsemny@yahoogroups.com>
                  >Sent: Monday, June 10, 2002 7:20 AM
                  >Subject: Re: [perlsemny] Request for Assistance with Module: List-Compare
                  >
                  >> 1) I'd suggest this module is pretty inefficient and is not really
                  >> appropriate for any large-scale use. If I want to compute just the
                  >> intersection of two sets, your library also computes a bunch of other
                  >> sets I may not need. Perhaps defer each computation until they ask
                  >> for it, and avoid computing extra stuff the user may not ask for.
                  >>
                  >I don't think efficiency in "large-scale use" is the point of the original
                  >(Cookbook) code or of my OO-implementation; simplicity and clarity is the
                  >point. If on your day job you have to maintain a web or database server
                  >that has to do lots of comparisons among lists of, say >10E6 size, then you
                  >perhaps should look elsewhere. On my day job, the lists I need to compare
                  >are all of < 10E3 size ... so no script in which I've used List::Compare has
                  >ever taken more than 1 second to execute!
                  >
                  >I would also argue that this code is clear enough that it would prove
                  >heuristically useful if one were teaching intermediate level Perl students
                  >an introduction to object-oriented Perl.
                  >
                  >> 2) Set::Scalar does almost all the same things (if not all the same
                  >> things), and I bargain it does them more efficiently and flexibly.
                  >> Check it out. Ideally your module would provide at least one
                  >> non-trivial function that Set::Scalar does not.
                  >> [snip]
                  >> I'd definitely recommend getting Set::Scalar to work for you and
                  >> making your module better/different (if it makes sense) before
                  >> submitting to CPAN. According to its perldocs, Set::Scalar has
                  >> methods for:
                  >> $u = $s->union($t);
                  >> $i = $s->intersection($t);
                  >> $d = $s->difference($t);
                  >> $e = $s->symmetric_difference($t);
                  >> $v = $s->unique($t);
                  >> $c = $s->complement;
                  >
                  >I had studied Set::Scalar before making the presentation at perlsemny last
                  >month and, at your suggestion, re-studied it. Set::Scalar *does* return
                  >intersections, unions and quite a few other things, but (as your citations
                  >from Set::Scalar's POD above demonstrate) in every instance it returns these
                  >things as *strings* rather than lists. To be specific, Set::Scalar returns
                  >always returns strings like this:
                  >
                  > (alpha beta gamma delta)
                  >
                  >that is: an open paren, the 1st element, a wordspace, the 2nd element, a
                  >wordspace ... the last element, a close paren. That's very useful if you
                  >want a clean typographic representation of a set, but not if what you really
                  >want is the values in a set. It's almost as if Set::Scalar is a fancy
                  >'sprintf'. Indeed, the section of the Set::Scalar POD from which you quote
                  >is called "Displaying."
                  >
                  >> 3) I'd avoid using multiple function (method) names that do the exact
                  >> same thing. (IE your methods get_symdiff() and
                  >> get_symmetric_difference()). It creates confusion for users and extra
                  >> work for the maintainer (you). I'd suggest just making one method
                  >> (named well) for each purpose.
                  >>
                  >They're simple aliases, so it's no more work for me. I offer them in the
                  >spirit of TIMTOWTDI. I have revised the documentation to spell out that
                  >they're just aliases, so I think most Perl users will understand. And, in
                  >any case, it's not unprecedented: Set::Scalar, for instance, provides
                  >aliases for at least 4 of its methods!
                  >
                  >> 4) It probably belongs more in the Set:: namespace than the List::
                  >> namespace... check out existing modules in each namespace to see for
                  >> yourself. I'd suggest perhaps Set::Compare.
                  >>
                  >I disagree. When I was developing this module I was concerned with
                  >comparing lists, not with comparing or displaying sets. If I was working in
                  >the field of mathematical set theory, I would go to the Set namespace. But
                  >I'm not and I think most Perl users will think first of comparing lists
                  >rather than comparing sets.
                  >
                  >> 5) Also mention Set::Scalar in your perldocs and why users would use
                  >> one library or another. You may want to contact the author of
                  >> Set::Scalar for input too.
                  > >
                  >The latest version of the module, available at
                  >http://www.concentric.net/~Jkeen/list/List-Compare-0.07.tar.gz
                  >contains POD revised to include an extensive discussion of 4 similar or
                  >similarly-named modules.
                  >
                  >> 6) Have you contact comp.lang.perl.modules or modules@... for
                  >> feedback too, as recommended at
                  >> http://www.cpan.org/modules/04pause.html ?
                  >>
                  >Yes. I've posted on both module@... and on comp.lang.perl.modules.
                  >I've gotten some feedback from Dave Cross (author of Array::Compare) and
                  >Terrence Brannon (author of an extension to one of the other modules I
                  >discuss in the POD, Graham Barr's List::Util) and have contacted Jarkko
                  >Hietaniemi (author of Set::Scalar) as well.
                  >
                  >Jim Keenan
                  >jkeen@...
                • Soren Andersen
                  I d like to express thanks to James and Josh for allowing me the chance to see the peer review process in action, up-close and in detail. This is a very
                  Message 8 of 8 , Jun 15, 2002
                  • 0 Attachment
                    I'd like to express thanks to James and Josh for allowing me the
                    chance to see the peer review process in action, up-close and in
                    detail. This is a very valuable thing because peer review (warning:
                    imperfect metaphor approaching) is the driveshaft in the system that
                    is "Open Source software". It's probably not always easy on every
                    participant every time, but it's invaluable. 'One of those things',
                    like eating our vegetables, that we don't always find tasty but that
                    is good for us, I'll observe. The main thing that charcaterizes good
                    peer review is honest *effort* -- not everybody always getting
                    everything "right" or being "perfect", but everbody *trying*. I see
                    the clear evidence for honest effort both parties made in the
                    exchanges between James and Josh and it's edifying and educational,
                    sets a good example. Particularly, I want to acknowledge that it made
                    me happy to see James come right back with a detailed, dignified
                    'defense' of his proposed CPAN module. Not that one would expect
                    anything else from Brooklyn, which is supposed to be (in the world of
                    geohuman stereotypes) synonymous with 'scrappy' ;-).

                    BTW, I need to be lame-o and ask about an announcement for this
                    month's Perl Sem meeting -- is there to be one? I've just visited the
                    Yahoo! Group site and tried to use the Calendar to check, and need to
                    report the apparent and maybe trivial anomaly that clicking on June's
                    supposed meeting date brings up December's Announcement (as does every
                    other month):

                    Event Name: Perl Seminar NY monthly session
                    Date: Tuesday, December 18, 2001 Time: 6:15pm-8:15pm
                    Description: Monthly session at: NYPC
                    481 8th Avenue, Suite 1560 (Hotel New Yorker, northwest corner 8 Ave &
                    34 St), Manhattan Trains: A/C/E to 34 St & 8 Ave; 1/2/3 to 34 St & 7
                    Ave; LIRR/NJT to Penn Station

                    Thanks,
                    Soren Andersen


                    --
                    Access all of your messages and folders wherever you are!
                    http://fastmail.fm - Get your mail using the web or your email software
                  Your message has been successfully submitted and would be delivered to recipients shortly.