Mailing List Archive: Perl: porters

PL_no_symref[]

Index | Next | Previous | View Threaded

nick at ccl4

Nov 2, 2009, 3:34 AM

Post #1 of 7 (504 views)
Permalink

PL_no_symref[]

On Mon, Oct 26, 2009 at 11:35:06PM +0100, Yves Orton wrote:
> In perl.git, the branch blead has been updated
>
> <http://perl5.git.perl.org/perl.git/commitdiff/9134ea20ecf6c7a898519ea43ac463bc4da08840?hp=2699d6345b651c48a820507d6287ddca1f5b2ee4>
>
> - Log -----------------------------------------------------------------
> commit 9134ea20ecf6c7a898519ea43ac463bc4da08840
> Author: Yves Orton <demerphq [at] gmail>
> Date: Mon Oct 26 21:52:05 2009 +0100
>
> add an elipses to string/ref warnings when str longer than 32 chars
>
> Wasted a few minutes more than necessary trying to work out why the
> string was truncated when in fact it was the error message that was
> truncating the string.

This seems a very sensible thing to do from the point of view of the core.

> EXTCONST char PL_no_symref[]
> - INIT("Can't use string (\"%.32s\") as %s ref while \"strict refs\" in use");
> + INIT("Can't use string (\"%.32s\"%s) as %s ref while \"strict refs\" in use");

However, I find two references to PL_no_symref on CPAN - Data::Alias and
Sub::Name. With the change to a printf-style format string they now ouptut
garbage (or if unlucky, SEGV). Fortunately Data::Alias fails its tests because
of this. Sub::Name doesn't though.

Given that there's exactly one reference to PL_no_symref in the core (now),
I think for it, it would be best to inline the literal string, deprecate it
from perl.h, and encourage the CPAN code also to inline the literal string.
(either the old version that they expect, or changed to add the elipses)

But I suspect (or fear) that in general, strings defined in perl.h are part
of the "API" we export.

Nicholas Clark

demerphq at gmail

Nov 3, 2009, 3:04 AM

Post #2 of 7 (661 views)
Permalink

Re: PL_no_symref[] [In reply to]

2009/11/2 Nicholas Clark <nick [at] ccl4>:
> On Mon, Oct 26, 2009 at 11:35:06PM +0100, Yves Orton wrote:
>> In perl.git, the branch blead has been updated
>>
>> <http://perl5.git.perl.org/perl.git/commitdiff/9134ea20ecf6c7a898519ea43ac463bc4da08840?hp=2699d6345b651c48a820507d6287ddca1f5b2ee4>
>>
>> - Log -----------------------------------------------------------------
>> commit 9134ea20ecf6c7a898519ea43ac463bc4da08840
>> Author: Yves Orton <demerphq [at] gmail>
>> Date: Mon Oct 26 21:52:05 2009 +0100
>>
>> add an elipses to string/ref warnings when str longer than 32 chars
>>
>> Wasted a few minutes more than necessary trying to work out why the
>> string was truncated when in fact it was the error message that was
>> truncating the string.
>
> This seems a very sensible thing to do from the point of view of the core.
>
>
>> EXTCONST char PL_no_symref[]
>> - INIT("Can't use string (\"%.32s\") as %s ref while \"strict refs\" in use");
>> + INIT("Can't use string (\"%.32s\"%s) as %s ref while \"strict refs\" in use");
>
> However, I find two references to PL_no_symref on CPAN - Data::Alias and
> Sub::Name. With the change to a printf-style format string they now ouptut
> garbage (or if unlucky, SEGV). Fortunately Data::Alias fails its tests because
> of this. Sub::Name doesn't though.

Both of these modules are in the "known problematic" category tho.

> Given that there's exactly one reference to PL_no_symref in the core (now),
> I think for it, it would be best to inline the literal string, deprecate it
> from perl.h, and encourage the CPAN code also to inline the literal string.
> (either the old version that they expect, or changed to add the elipses)
>
> But I suspect (or fear) that in general, strings defined in perl.h are part
> of the "API" we export.

If Matthijs fixes his code then there is no problem.

Maybe I look at this differently than you. But I have done evil things
with the internals of perl before in XS. I would hate to think that
you or anyone else would consider breaking that code a reason not to
improve Perl.

I find it interesting actually as both of these modules satisfy my
personal criteria for adding to perl. They solve problems that are
incredibly difficult to solve *without* diddling with perls innerds,
and they solve problems that a lot of people have said they would
appreciate solutions to.

There is an expression in precedent-based legal systems "Hard cases
make bad law", and I think this is a hard case.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

nick at ccl4

Nov 3, 2009, 6:35 AM

Post #3 of 7 (481 views)
Permalink

Re: PL_no_symref[] [In reply to]

On Tue, Nov 03, 2009 at 12:04:38PM +0100, demerphq wrote:

> I find it interesting actually as both of these modules satisfy my
> personal criteria for adding to perl. They solve problems that are
> incredibly difficult to solve *without* diddling with perls innerds,
> and they solve problems that a lot of people have said they would
> appreciate solutions to.

If the solution is "add it to core" then the only way to solve problems
like this is to either

1: "break" the "rules" to innovate
2: do it in core

I'd much prefer to solve the problem of the core not being flexible in these
areas, so that it is possible to reliably innovate these sorts of solutions
on CPAN, *and* things we've not yet thought of.

Hence I'd prefer it if people who found that parts of the core they want
exposed aren't, worked towards exposing them via a (relatively) sane,
documented, tested API. Which should long-term be maintainable.

(Which the patches that Zefram has presented in the past week start to work
towards)

Nicholas Clark

nick at ccl4

Nov 3, 2009, 6:38 AM

Post #4 of 7 (478 views)
Permalink

Re: PL_no_symref[] [In reply to]

On Tue, Nov 03, 2009 at 12:04:38PM +0100, demerphq wrote:

> Maybe I look at this differently than you. But I have done evil things
> with the internals of perl before in XS. I would hate to think that
> you or anyone else would consider breaking that code a reason not to
> improve Perl.

Oh, I missed that. If anything is relying on using something non-public, then
to my mind it has said that it's prepared to keep both pieces if that thing
changes.

The solution should be to figure out how to make that functionality public.

Nicholas Clark

zefram at fysh

Nov 3, 2009, 6:45 AM

Post #5 of 7 (485 views)
Permalink

Re: PL_no_symref[] [In reply to]

Nicholas Clark wrote:
>Oh, I missed that. If anything is relying on using something non-public, then
>to my mind it has said that it's prepared to keep both pieces if that thing
>changes.

That's my attitude with the modules where I've #defined PERL_CORE,
or otherwise fiddled with undocumented functions and data structures.
This is what testing against dev releases is for.

>The solution should be to figure out how to make that functionality public.

That too. People do ugly things to get cool stuff working; our aim
should be to support the cool stuff cleanly. Take hints from the ugly
that exists in the wild.

-zefram

demerphq at gmail

Nov 3, 2009, 7:12 AM

Post #6 of 7 (479 views)
Permalink

Re: PL_no_symref[] [In reply to]

2009/11/3 Nicholas Clark <nick [at] ccl4>:
> On Tue, Nov 03, 2009 at 12:04:38PM +0100, demerphq wrote:
>
>> Maybe I look at this differently than you. But I have done evil things
>> with the internals of perl before in XS. I would hate to think that
>> you or anyone else would consider breaking that code a reason not to
>> improve Perl.
>
> Oh, I missed that. If anything is relying on using something non-public, then
> to my mind it has said that it's prepared to keep both pieces if that thing
> changes.
>
> The solution should be to figure out how to make that functionality public.

I agree. And i think stuff like the internal error message strings
are an example.

Probably what should happen is that usage of the error messages is
wrapped in a routine and then we dont worry that we "broke" these
modules, as they should be using the new api anyway.

cheers
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

demerphq at gmail

Nov 3, 2009, 7:15 AM

Post #7 of 7 (477 views)
Permalink

Re: PL_no_symref[] [In reply to]

2009/11/3 Nicholas Clark <nick [at] ccl4>:
> On Tue, Nov 03, 2009 at 12:04:38PM +0100, demerphq wrote:
>
>> I find it interesting actually as both of these modules satisfy my
>> personal criteria for adding to perl. They solve problems that are
>> incredibly difficult to solve *without* diddling with perls innerds,
>> and they solve problems that a lot of people have said they would
>> appreciate solutions to.
>
> If the solution is "add it to core" then the only way to solve problems
> like this is to either
>
> 1: "break" the "rules" to innovate
> 2: do it in core

and

3: add an api to do it in core.

> I'd much prefer to solve the problem of the core not being flexible in these
> areas, so that it is possible to reliably innovate these sorts of solutions
> on CPAN, *and* things we've not yet thought of.
>
> Hence I'd prefer it if people who found that parts of the core they want
> exposed aren't, worked towards exposing them via a (relatively) sane,
> documented, tested API. Which should long-term be maintainable.
>
> (Which the patches that Zefram has presented in the past week start to work
> towards)

I think the likelyhood is that we get 1, followed by 3. At least that
is the pattern that has happened with my hacks. They were first 1,
proved to be sufficiently useful that they ended up as 3.

I think this is fine as well, we just have to relax our reluctance to
break stuff so that it only applies to stuff we *specifically* stated
as reliable. Random vars and etc used internally dont count IMO.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads