No subject
Thu Aug 20 06:46:28 UTC 2009
* New upstream release
Modified:
trunk/libcommon-sense-perl/Changes
trunk/libcommon-sense-perl/META.json
trunk/libcommon-sense-perl/META.yml
trunk/libcommon-sense-perl/README
trunk/libcommon-sense-perl/debian/changelog
trunk/libcommon-sense-perl/sense.pm
Modified: trunk/libcommon-sense-perl/Changes
URL: http://svn.debian.org/wsvn/pkg-perl/trunk/libcommon-sense-perl/Changes?rev=46784&op=diff
==============================================================================
--- trunk/libcommon-sense-perl/Changes (original)
+++ trunk/libcommon-sense-perl/Changes Thu Nov 5 14:29:25 2009
@@ -1,4 +1,12 @@
Revision history for perl pragma common::sense.
+
+2.02 Wed Nov 4 12:04:08 CET 2009
+ - no functional changes.
+ - add META.yml clarification to the faq, tune the docs a bit
+ and add a "much reduced typing" section.
+ - unfortunately, the tone of the manpage has tightened and is
+ more serious in many parts now. We consider this a bug that we
+ plan to fix before 2100.
2.01 Mon Oct 5 17:01:48 CEST 2009
- add a FAQ section.
Modified: trunk/libcommon-sense-perl/META.json
URL: http://svn.debian.org/wsvn/pkg-perl/trunk/libcommon-sense-perl/META.json?rev=46784&op=diff
==============================================================================
--- trunk/libcommon-sense-perl/META.json (original)
+++ trunk/libcommon-sense-perl/META.json Thu Nov 5 14:29:25 2009
@@ -1,1 +1,1 @@
-{"no_index":{"directory":["t","inc"]},"meta-spec":{"version":1.4,"url":"http://module-build.sourceforge.net/META-spec-v1.4.html"},"generated_by":"ExtUtils::MakeMaker version 6.54","distribution_type":"module","version":"2.01","name":"common-sense","author":[],"license":"unknown","build_requires":{"ExtUtils::MakeMaker":0},"requires":{},"abstract":null,"configure_requires":{"ExtUtils::MakeMaker":0}}
+{"no_index":{"directory":["t","inc"]},"meta-spec":{"version":1.4,"url":"http://module-build.sourceforge.net/META-spec-v1.4.html"},"generated_by":"ExtUtils::MakeMaker version 6.54","distribution_type":"module","version":"2.02","name":"common-sense","author":[],"license":"unknown","build_requires":{"ExtUtils::MakeMaker":0},"requires":{},"abstract":null,"configure_requires":{"ExtUtils::MakeMaker":0}}
Modified: trunk/libcommon-sense-perl/META.yml
URL: http://svn.debian.org/wsvn/pkg-perl/trunk/libcommon-sense-perl/META.yml?rev=46784&op=diff
==============================================================================
--- trunk/libcommon-sense-perl/META.yml (original)
+++ trunk/libcommon-sense-perl/META.yml Thu Nov 5 14:29:25 2009
@@ -11,7 +11,7 @@
},
"generated_by" : "ExtUtils::MakeMaker version 6.54",
"distribution_type" : "module",
- "version" : "2.01",
+ "version" : "2.02",
"name" : "common-sense",
"author" : [],
"license" : "unknown",
Modified: trunk/libcommon-sense-perl/README
URL: http://svn.debian.org/wsvn/pkg-perl/trunk/libcommon-sense-perl/README?rev=46784&op=diff
==============================================================================
--- trunk/libcommon-sense-perl/README (original)
+++ trunk/libcommon-sense-perl/README Thu Nov 5 14:29:25 2009
@@ -18,7 +18,32 @@
DESCRIPTION
This module implements some sane defaults for Perl programs, as defined
by two typical (or not so typical - use your common sense) specimens of
- Perl coders.
+ Perl coders. In fact, after working out details on which warnings and
+ strict modes to enable and make fatal, we found that we (and our code
+ written so far, and others) fully agree on every option, even though we
+ never used warnings before, so it seems this module indeed reflects a
+ "common" sense among some long-time Perl coders.
+
+ The basic philosophy behind the choices made in common::sense can be
+ summarised as: "enforcing strict policies to catch as many bugs as
+ possible, while at the same time, not limiting the expressive power
+ available to the programmer".
+
+ Two typical examples of this philosophy are uninitialised and malloc
+ warnings:
+
+ "undef" is a well-defined feature of perl, and enabling warnings for
+ using it rarely catches any bugs, but considerably limits you in what
+ you can do, so uninitialised warnings are disabled.
+
+ Freeing something twice on the C level is a serious bug, usually causing
+ memory corruption. It often leads to side effects much later in the
+ program and there are no advantages to not reporting this, so malloc
+ warnings are fatal by default.
+
+ What follows is a more thorough discussion of what this module does, and
+ why it does it, and what the advantages (and disadvantages) of this
+ approach are.
use strict qw(subs vars)
Using "use strict" is definitely common sense, but "use strict
@@ -63,6 +88,12 @@
If your code isn't alive, it's dead, Jim - be an active maintainer.
+ But nobody forces you to use those extra features in modules meant
+ for older versions of perl - common::sense of course works there as
+ well. There is also an important other mode where having additional
+ features by default is useful: commandline hacks and internal use
+ scripts: See "much reduced typing", below.
+
no warnings, but a lot of new errors
Ah, the dreaded warnings. Even worse, the horribly dreaded "-w"
switch: Even though we don't care if other people use warnings (and
@@ -112,6 +143,22 @@
We quickly agreed that indeed the code should be changed, even
though it happened to do the right thing when the warning was
switched off.
+
+ much reduced typing
+ Especially with version 2.0 of common::sense, the amount of
+ boilerplate code you need to add to gte *this* policy is daunting.
+ Nobody would write this out in throwaway scripts, commandline hacks
+ or in quick internal-use scripts.
+
+ By using common::sense you get a defined set of policies (ours, but
+ maybe yours, too, if you accept them), and they are easy to apply to
+ your scripts: typing "use common::sense;" is even shorter than "use
+ warnings; use strict; use feature ...".
+
+ And you can immediately use the features of your installed perl,
+ which is more difficult in code you release, but not usually an
+ issue for internal-use code (downgrades of your production perl
+ should be rare, right?).
mucho reduced memory usage
Just using all those pragmas mentioned in the SYNOPSIS together
@@ -208,6 +255,11 @@
How about quoting this: get a clue, you fucktarded amoeba.
+ quanth
+
+ common sense is beautiful, json::xs is fast, Anyevent, EV are fast and
+ furious. I love mlehmannware ;)
+
FREQUQNTLY ASKED QUESTIONS
Or frequently-come-up confusions.
@@ -243,12 +295,15 @@
Well, we don't do this either - we selectively disagree with the
usefulness of some warnings over others. This module is aimed at
experienced Perl programmers, not people migrating from other
- languages who might be surprised about stuff such as "undef".
-
- In fact, this module is considerably *more* strict than the
- canonical "use strict; use warnings", as it makes all warnings fatal
- in nature, so you can get away with as many things as with the
- canonical approach.
+ languages who might be surprised about stuff such as "undef". On the
+ other hand, this does not exclude the usefulness of this module for
+ total newbies, due to its strictness in enforcing policy, while at
+ the same time not limiting the expresive power of perl.
+
+ This module is considerably *more* strict than the canonical "use
+ strict; use warnings", as it makes all its warnings fatal in nature,
+ so you can not get away with as many things as with the canonical
+ approach.
This was not implemented in version 1.0 because of the daunting
number of warning categories and the difficulty in getting exactly
@@ -270,6 +325,15 @@
thing - it leads to better APIs, more thought about interworking of
modules and so on.
+ Why do you use JSON and not YAML for your META.yml?
+ This is not true - YAML supports a large subset of JSON, and this
+ subset is what META.yml is written in, so it would be correct to say
+ "the META.yml is written in a common subset of YAML and JSON".
+
+ The META.yml follows the YAML, JSON and META.yml specifications, and
+ is correctly parsed by CPAN, so if you have trouble with it, the
+ problem is likely on your side.
+
But! But!
Yeah, we know.
Modified: trunk/libcommon-sense-perl/debian/changelog
URL: http://svn.debian.org/wsvn/pkg-perl/trunk/libcommon-sense-perl/debian/changelog?rev=46784&op=diff
==============================================================================
--- trunk/libcommon-sense-perl/debian/changelog (original)
+++ trunk/libcommon-sense-perl/debian/changelog Thu Nov 5 14:29:25 2009
@@ -1,3 +1,12 @@
+libcommon-sense-perl (2.02-1) UNRELEASED; urgency=low
+
+ From Changes file: "no functional changes."
+ IGNORE-VERSION: 2.02-1
+
+ * New upstream release
+
+ -- Jonathan Yu <jawnsy at cpan.org> Wed, 04 Nov 2009 20:09:12 -0500
+
libcommon-sense-perl (2.01-2) UNRELEASE; urgency=low
* Update my email address
Modified: trunk/libcommon-sense-perl/sense.pm
URL: http://svn.debian.org/wsvn/pkg-perl/trunk/libcommon-sense-perl/sense.pm?rev=46784&op=diff
==============================================================================
--- trunk/libcommon-sense-perl/sense.pm (original)
+++ trunk/libcommon-sense-perl/sense.pm Thu Nov 5 14:29:25 2009
@@ -21,7 +21,32 @@
This module implements some sane defaults for Perl programs, as defined by
two typical (or not so typical - use your common sense) specimens of Perl
-coders.
+coders. In fact, after working out details on which warnings and strict
+modes to enable and make fatal, we found that we (and our code written so
+far, and others) fully agree on every option, even though we never used
+warnings before, so it seems this module indeed reflects a "common" sense
+among some long-time Perl coders.
+
+The basic philosophy behind the choices made in common::sense can be
+summarised as: "enforcing strict policies to catch as many bugs as
+possible, while at the same time, not limiting the expressive power
+available to the programmer".
+
+Two typical examples of this philosophy are uninitialised and malloc
+warnings:
+
+C<undef> is a well-defined feature of perl, and enabling warnings for
+using it rarely catches any bugs, but considerably limits you in what you
+can do, so uninitialised warnings are disabled.
+
+Freeing something twice on the C level is a serious bug, usually causing
+memory corruption. It often leads to side effects much later in the
+program and there are no advantages to not reporting this, so malloc
+warnings are fatal by default.
+
+What follows is a more thorough discussion of what this module does,
+and why it does it, and what the advantages (and disadvantages) of this
+approach are.
=over 4
@@ -70,6 +95,12 @@
If your code isn't alive, it's dead, Jim - be an active maintainer.
+But nobody forces you to use those extra features in modules meant for
+older versions of perl - common::sense of course works there as well.
+There is also an important other mode where having additional features by
+default is useful: commandline hacks and internal use scripts: See "much
+reduced typing", below.
+
=item no warnings, but a lot of new errors
@@ -122,6 +153,24 @@
happened to do the right thing when the warning was switched off.
+=item much reduced typing
+
+Especially with version 2.0 of common::sense, the amount of boilerplate
+code you need to add to gte I<this> policy is daunting. Nobody would write
+this out in throwaway scripts, commandline hacks or in quick internal-use
+scripts.
+
+By using common::sense you get a defined set of policies (ours, but maybe
+yours, too, if you accept them), and they are easy to apply to your
+scripts: typing C<use common::sense;> is even shorter than C<use warnings;
+use strict; use feature ...>.
+
+And you can immediately use the features of your installed perl, which
+is more difficult in code you release, but not usually an issue for
+internal-use code (downgrades of your production perl should be rare,
+right?).
+
+
=item mucho reduced memory usage
Just using all those pragmas mentioned in the SYNOPSIS together wastes
@@ -141,7 +190,7 @@
package common::sense;
-our $VERSION = '2.01';
+our $VERSION = '2.02';
# paste this into perl to find bitmask
@@ -253,6 +302,11 @@
How about quoting this: get a clue, you fucktarded amoeba.
+quanth
+
+ common sense is beautiful, json::xs is fast, Anyevent, EV are fast and
+ furious. I love mlehmannware ;)
+
=head1 FREQUQNTLY ASKED QUESTIONS
Or frequently-come-up confusions.
@@ -296,11 +350,14 @@
Well, we don't do this either - we selectively disagree with the
usefulness of some warnings over others. This module is aimed at
experienced Perl programmers, not people migrating from other languages
-who might be surprised about stuff such as C<undef>.
-
-In fact, this module is considerably I<more> strict than the canonical
-C<use strict; use warnings>, as it makes all warnings fatal in nature, so
-you can get away with as many things as with the canonical approach.
+who might be surprised about stuff such as C<undef>. On the other hand,
+this does not exclude the usefulness of this module for total newbies, due
+to its strictness in enforcing policy, while at the same time not limiting
+the expresive power of perl.
+
+This module is considerably I<more> strict than the canonical C<use
+strict; use warnings>, as it makes all its warnings fatal in nature, so
+you can not get away with as many things as with the canonical approach.
This was not implemented in version 1.0 because of the daunting number
of warning categories and the difficulty in getting exactly the set of
@@ -323,6 +380,16 @@
leads to better APIs, more thought about interworking of modules and so
on.
+=item Why do you use JSON and not YAML for your META.yml?
+
+This is not true - YAML supports a large subset of JSON, and this subset
+is what META.yml is written in, so it would be correct to say "the
+META.yml is written in a common subset of YAML and JSON".
+
+The META.yml follows the YAML, JSON and META.yml specifications, and is
+correctly parsed by CPAN, so if you have trouble with it, the problem is
+likely on your side.
+
=item But! But!
Yeah, we know.
More information about the Pkg-perl-cvs-commits
mailing list