Mailing List Archive: Perl: porters

5.16.0, perlport, corelist, and pseudo-blockers

Index | Next | Previous | View Threaded

perl.p5p at rjbs

May 1, 2012, 7:57 PM

Post #1 of 10 (104 views)
Permalink

5.16.0, perlport, corelist, and pseudo-blockers

So, hey, I just built this:

This is perl 5, version 16, subversion 0 (v5.16.0 (v5.15.9-270-g03b5aaf))
built for darwin-2level
(with 1 registered patch, see perl -V for more detail)

Woo!

I know we have some smoke reports to deal with and some other building issues
to consider, but I'm trying to get the boring stuff done on a branch to
facilitate things getting done at all.

Here are two things about which I'd like input:

(1) What's up with perlport's "Supported Versions"?

It has two "Supported Versions" sections. One is labeled 5.12, the other 5.8.
Neither is labeled 5.14.

My plan is to delete the 5.8 one and update the 5.12 one to read "5.16" with
the needed changes, if any.

(2) Sneaking in C<corelist --diff X Y>

A massivehuge "Updated Modules" section is a drag to read. Nobody is going to.
It should be a list of things that changed that we know are of note. i.e.,
"Selected Module Updates." Then we can say "for a complete set of changes,
consult corelist."

...but corelist doesn't let you say "what changed from 5.14.2 to 5.16.0?"

My commit e9eb411, available at rjbs/corelist-diff, adds this:

corelist --diff 5.14.2 5.16.0

It's ripped off of the corelist-diff script in ./Porting.

--
rjbs

Attachments:

signature.asc (0.48 KB)

h.m.brand at xs4all

May 1, 2012, 11:50 PM

Post #2 of 10 (94 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Tue, 1 May 2012 22:57:30 -0400, Ricardo Signes
<perl.p5p [at] rjbs> wrote:

>
> So, hey, I just built this:
>
> This is perl 5, version 16, subversion 0 (v5.16.0 (v5.15.9-270-g03b5aaf))
> built for darwin-2level
> (with 1 registered patch, see perl -V for more detail)
>
> Woo!

http://doc.procura.nl/smoke/index.html is still pretty dark red
(thus so is http://perl5.test-smoke.org/)

> I know we have some smoke reports to deal with and some other building issues
> to consider, but I'm trying to get the boring stuff done on a branch to
> facilitate things getting done at all.
>
> Here are two things about which I'd like input:
>
> (1) What's up with perlport's "Supported Versions"?
>
> It has two "Supported Versions" sections. One is labeled 5.12, the other 5.8.
> Neither is labeled 5.14.
>
> My plan is to delete the 5.8 one and update the 5.12 one to read "5.16" with
> the needed changes, if any.
>
> (2) Sneaking in C<corelist --diff X Y>
>
> A massivehuge "Updated Modules" section is a drag to read. Nobody is going to.
> It should be a list of things that changed that we know are of note. i.e.,
> "Selected Module Updates." Then we can say "for a complete set of changes,
> consult corelist."
>
> ...but corelist doesn't let you say "what changed from 5.14.2 to 5.16.0?"
>
> My commit e9eb411, available at rjbs/corelist-diff, adds this:
>
> corelist --diff 5.14.2 5.16.0
>
> It's ripped off of the corelist-diff script in ./Porting.
>

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.14 porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

chris at bingosnet

May 2, 2012, 3:04 AM

Post #3 of 10 (92 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Tue, May 01, 2012 at 10:57:30PM -0400, Ricardo Signes wrote:
>
> (2) Sneaking in C<corelist --diff X Y>
>
> A massivehuge "Updated Modules" section is a drag to read. Nobody is going to.
> It should be a list of things that changed that we know are of note. i.e.,
> "Selected Module Updates." Then we can say "for a complete set of changes,
> consult corelist."
>
> ...but corelist doesn't let you say "what changed from 5.14.2 to 5.16.0?"
>
> My commit e9eb411, available at rjbs/corelist-diff, adds this:
>
> corelist --diff 5.14.2 5.16.0
>
> It's ripped off of the corelist-diff script in ./Porting.
>

I do like this, but I could see the utility in it being implemented
in Module::CoreList as a function instead that corelist just calls,
then there would be programmatic mechanism rather than it case of
having to scrape output from corelist.

</my two pennyworth>

--
Chris Williams
aka BinGOs
PGP ID 0x4658671F
http://www.gumbynet.org.uk
==========================

xdaveg at gmail

May 2, 2012, 3:59 AM

Post #4 of 10 (93 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Tue, May 1, 2012 at 10:57 PM, Ricardo Signes
<perl.p5p [at] rjbs> wrote:
> (1) What's up with perlport's "Supported Versions"?
>
> It has two "Supported Versions" sections. One is labeled 5.12, the other 5.8.
> Neither is labeled 5.14.

Bitrot, I'd guess.

> My plan is to delete the 5.8 one and update the 5.12 one to read "5.16" with
> the needed changes, if any.

+1

> (2) Sneaking in C<corelist --diff X Y>

Great in concept, but I suggest holding that for 5.17 on general
principle. Yes, the long list sucks, but people can suck it up one
more time.

And as BinGOs says, we can probably do it better with more time and thought.

-- David

abigail at abigail

May 2, 2012, 4:52 AM

Post #5 of 10 (91 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Tue, May 01, 2012 at 10:57:30PM -0400, Ricardo Signes wrote:
>
>
> (2) Sneaking in C<corelist --diff X Y>
>
> A massivehuge "Updated Modules" section is a drag to read. Nobody is going to.

Perhaps not.

> It should be a list of things that changed that we know are of note. i.e.,
> "Selected Module Updates." Then we can say "for a complete set of changes,
> consult corelist."

Noone is going to read a dictionary or phonebook either. But we don't
select some notable words or phone numbers, referring to the full
dictionary or phone book for the rest. My guess, most people will never
read perldelta. The few people that do will know how to skip a few pages
in their pager, and how to search for the modules they are interested
in. If you make a selection, you leave out things. Causing people to
consult another document -- which will be the same drag to read. That
is, if they even spot the line "for a complete set of changes..." while
searching for their favourite modules.

Abigail

nick at ccl4

May 2, 2012, 6:12 AM

Post #6 of 10 (91 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Wed, May 02, 2012 at 11:04:39AM +0100, Chris 'BinGOs' Williams wrote:
> On Tue, May 01, 2012 at 10:57:30PM -0400, Ricardo Signes wrote:
> >
> > (2) Sneaking in C<corelist --diff X Y>

> > ...but corelist doesn't let you say "what changed from 5.14.2 to 5.16.0?"
> >
> > My commit e9eb411, available at rjbs/corelist-diff, adds this:
> >
> > corelist --diff 5.14.2 5.16.0
> >
> > It's ripped off of the corelist-diff script in ./Porting.
> >
>
> I do like this, but I could see the utility in it being implemented
> in Module::CoreList as a function instead that corelist just calls,
> then there would be programmatic mechanism rather than it case of
> having to scrape output from corelist.

Making it a function (instead of something that needs running) makes it
easier to write tests for.
Not screenscraping makes it less fragile.

However, making it a function before we're sure that it's the right interface
isn't a great idea either.

Nicholas Clark

tchrist at perl

May 2, 2012, 6:25 AM

Post #7 of 10 (92 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

> Making it a function (instead of something that needs running) makes it
> easier to write tests for.

Is

$s = `proggie`;

really that much harder than:

$s = f();

Just curious.

> Not screenscraping makes it less fragile.

I wonder if you aren't using "screenscaping"
in a different way than I'm used to.

--tom

nick at ccl4

May 2, 2012, 6:26 AM

Post #8 of 10 (90 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Wed, May 02, 2012 at 01:52:34PM +0200, Abigail wrote:
> On Tue, May 01, 2012 at 10:57:30PM -0400, Ricardo Signes wrote:
> >
> >
> > (2) Sneaking in C<corelist --diff X Y>
> >
> > A massivehuge "Updated Modules" section is a drag to read. Nobody is going to.
>
> Perhaps not.
>
> > It should be a list of things that changed that we know are of note. i.e.,
> > "Selected Module Updates." Then we can say "for a complete set of changes,
> > consult corelist."

Not exactly that phrase...

> Noone is going to read a dictionary or phonebook either. But we don't
> select some notable words or phone numbers, referring to the full
> dictionary or phone book for the rest. My guess, most people will never
> read perldelta. The few people that do will know how to skip a few pages
> in their pager, and how to search for the modules they are interested
> in. If you make a selection, you leave out things. Causing people to
> consult another document -- which will be the same drag to read. That
> is, if they even spot the line "for a complete set of changes..." while
> searching for their favourite modules.

That's a fair point, if the other *thing* really would be a document.
But it can't be. Module::Corelist can only automate reporting of which
*version numbers* changed between releases.

However, that's really part of the problem. The current policy of "mention
everything which changed" generates a perldelta with a lot of lines like
this:

=item *

C<B::Deparse> has been upgraded from version 1.12 to 1.13.

=item *

C<B::Lint> has been upgraded from version 1.13 to 1.14.

=item *

C<CPAN::Meta> has been upgraded from version 2.120351 to 2.120630.

=item *

C<CPANPLUS> has been upgraded from version 0.9118 to 0.9121.

=item *

C<Data::Dumper> has been upgraded from version 2.135_05 to 2.135_06.

=item *

C<Digest::SHA> has been upgraded from version 5.70 to 5.71.

=item *

C<ExtUtils::CBuilder> has been upgraded from version 0.280205 to 0.280206.

=item *

C<HTTP::Tiny> has been upgraded from version 0.016 to 0.017.

=item *

C<Module::CoreList> has been upgraded from version 2.60 to 2.65.

=item *

C<Pod::Html> has been upgraded from version 1.14 to 1.1501.

=item *

C<Pod::Perldoc> has been upgraded from version 3.15_15 to 3.17.

=item *

C<Pod::Simple> has been upgraded from version 3.19 to 3.20.

=item *

C<Socket> has been upgraded from version 1.98 to 2.000.

which don't fit the *intent* of the perldelta, which is to summarise the
key changes.

[.yes, I deliberately quoted the longest block that I could find]

Really, we should only be entering items into that bit of perldelta if it's
a significant change - version bumps due to typo fixes or Pod formatting
corrections don't count. But the corollary also holds - if a module has
a significant upgrade, that should be summarised there.

So I think that

a) changing the intro text to be clear that significant upgrades only are
mentioned, typo fixes and similar minor corrections are not
b) getting rid of all the above lines of *non*-summaries
c) listing the names (only) of modules that changed but didn't make the summary
list (in a vertically efficient format, so not simply another =item list)
d) describing the tool to get the version number change, and mention git log

would increase the information density of the perldelta, without removing
any meaningful content.

Nicholas Clark

xdaveg at gmail

May 2, 2012, 6:55 AM

Post #9 of 10 (91 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Wed, May 2, 2012 at 9:25 AM, Tom Christiansen <tchrist [at] perl> wrote:
> Is
>
> $s = `proggie`;
>
> really that much harder than:
>
> $s = f();
>
> Just curious.

In the general case, yes, mostly due to portability/path issues. E.g.
is 'proggie' in PATH? Is the right 'proggie' first? Does it have a
shebang that runs it against the wrong perl interpreter? `$^X
/path/to/proggie` is a reasonably safe way to do it, but that already
requires one to realize where the naive `proggie` approach could go
wrong.

Second order: it's often easier to get (structured) data back from a
function and test correctness than to capture output and parse it for
correctness, plus the data is probably more constant than the output
formatting, which makes tests less fragile. Some actual output
testing is always good, but that's not where I prefer to start.

Third (or even fourth) order: backticks don't capture STDERR, so
testing errors requires additional complexity. (shameless
self-promotion: c.f. Capture::Tiny)

Of course, if a program takes *arguments*, testing those directly via
system() or qx// is important, too, instead of just mocking @ARGV and
assuming the function works just like the actual program.

-- David

nick at ccl4

May 2, 2012, 7:27 AM

Post #10 of 10 (92 views)
Permalink

Re: 5.16.0, perlport, corelist, and pseudo-blockers [In reply to]

On Wed, May 02, 2012 at 09:55:13AM -0400, David Golden wrote:
> On Wed, May 2, 2012 at 9:25 AM, Tom Christiansen <tchrist [at] perl> wrote:
> > Is
> >
> > � �$s = `proggie`;
> >
> > really that much harder than:
> >
> > � �$s = f();
> >
> > Just curious.

> Second order: it's often easier to get (structured) data back from a
> function and test correctness than to capture output and parse it for
> correctness, plus the data is probably more constant than the output
> formatting, which makes tests less fragile. Some actual output
> testing is always good, but that's not where I prefer to start.

Also, output intended for humans isn't an API.

Code which has to parse "pretty" output inevitably makes assumptions about
the structure, which runs the risk of blows up when someone tries to make
what they rightly think is a cosmetic change.

See, for instance, all the recent "fun" when Carp added a single character
to its output. Or that we got complaints when we slightly changed the output
of `perl -v` because someone, somewhere was relying on its format.

Yes, in this case, both ends of the pipeline are under our control, so such
explosions aren't going to happen anywhere near as easily. But we still have
to figure out how to instruct the outer program how to correctly call the
*uninstalled* inner program with the correct interpreter and correct library
path overrides, which is also pain.

Once testing gets involved, it's generally much easier to write something as
a module that implements the guts, and the harder-to-test part (be it invoked
command, CGI script, webservice, etc) as the thinnest practical layer round
that.

Nicholas Clark

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads