Bleadperl v5.19.2-276-g38be3d0 breaks LEONT/Const-Fast-0.014.tar.gz

p5pRT commented 11 years ago

Migrated from rt.perl.org#119189 (status was 'resolved')

Searchable as RT119189$

p5pRT commented 11 years ago

From @andk

git bisect

commit 38be3d0038ef87b22af88f80db1fbeb0292ce53b Author: Father Chrysostomos \sprout@cpan\.org Date: Sun Aug 4 11:22:03 2013 -0700

Don’t let list const modification affect future retvals

diagnostics

http://www.cpantesters.org/cpan/report/60ca6d08-fe27-11e2-9875-5209f2ff63fb

Also affected: DANKOGAI/Data-Lock-1.02.tar.gz as in

http://www.cpantesters.org/cpan/report/1d45d002-fe1a-11e2-b08a-12aaf1ff63fb

perl -V

Summary of my perl5 (revision 5 version 19 subversion 3) configuration: Commit id: 38be3d0038ef87b22af88f80db1fbeb0292ce53b Platform: osname=linux\, osvers=3.9-1-amd64\, archname=x86_64-linux-ld uname='linux k83 3.9-1-amd64 #1 smp debian 3.9.8-1 x86_64 gnulinux ' config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e -Dmyhostname=k83 -Dinstallusrbinperl=n -Uversiononly -Dusedevel -des -Ui_db -Uuseithreads -Duselongdouble -DDEBUGGING=-g' hint=recommended\, useposix=true\, d_sigaction=define useithreads=undef\, usemultiplicity=undef useperlio=define\, d_sfio=undef\, uselargefiles=define\, usesocks=undef use64bitint=define\, use64bitall=define\, uselongdouble=define usemymalloc=n\, bincompat5005=undef Compiler: cc='cc'\, ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64'\, optimize='-O2 -g'\, cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion=''\, gccversion='4.8.1'\, gccosandvers='' intsize=4\, longsize=8\, ptrsize=8\, doublesize=8\, byteorder=12345678 d_longlong=define\, longlongsize=8\, d_longdbl=define\, longdblsize=16 ivtype='long'\, ivsize=8\, nvtype='long double'\, nvsize=16\, Off_t='off_t'\, lseeksize=8 alignbytes=16\, prototype=define Linker and Libraries: ld='cc'\, ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc -lgdbm_compat perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=\, so=so\, useshrplib=false\, libperl=libperl.a gnulibc_version='2.17' Dynamic Linking: dlsrc=dl_dlopen.xs\, dlext=so\, d_dlsymun=undef\, ccdlflags='-Wl\,-E' cccdlflags='-fPIC'\, lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Characteristics of this binary (from libperl): Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV PERL_HASH_FUNC_ONE_AT_A_TIME_HARD PERL_MALLOC_WRAP PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV PERL_USE_DEVEL USE_64_BIT_ALL USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_LONG_DOUBLE USE_PERLIO USE_PERL_ATOF Built under linux Compiled at Aug 7 2013 05:17:32 @INC: /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/site_perl/5.19.3/x86_64-linux-ld /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/site_perl/5.19.3 /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/5.19.3/x86_64-linux-ld /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.2-276-g38be3d0/127e/lib/5.19.3 .

-- andreas

p5pRT commented 11 years ago

From @cpansprout

On Tue Aug 06 20:42:33 2013\, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:

git bisect ---------- commit 38be3d0038ef87b22af88f80db1fbeb0292ce53b Author: Father Chrysostomos \sprout@cpan\.org Date: Sun Aug 4 11:22:03 2013 -0700
Don’t let list const modification affect future retvals
diagnostics ----------- http://www.cpantesters.org/cpan/report/60ca6d08-fe27-11e2-9875- 5209f2ff63fb

Also affected: DANKOGAI/Data-Lock-1.02.tar.gz as in

http://www.cpantesters.org/cpan/report/1d45d002-fe1a-11e2-b08a- 12aaf1ff63fb

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

To work around this\, I would have to add *more* Internals:: functions for constant.pm to use. I hope I don’t have to do that.

--

Father Chrysostomos

p5pRT commented 11 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 11 years ago

From @Leont

On Wed\, Aug 7\, 2013 at 9:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

If you ask me\, some function to make stuff readonly should have been made API somewhere a long time ago. Same goes for getting the refcount I suppose (setting it is pure insanity).

Leon

p5pRT commented 11 years ago

From @ap

* Leon Timmermans \fawaka@gmail\.com [2013-08-21 13:00]:

If you ask me\, some function to make stuff readonly should have been made API somewhere a long time ago. Same goes for getting the refcount I suppose (setting it is pure insanity).

It’s easy enough to set it… so long as you aren’t trying to decrease it anyway. ;-)

p5pRT commented 11 years ago

From @cpansprout

On Wed Aug 21 03:56:31 2013\, LeonT wrote:

On Wed\, Aug 7\, 2013 at 9:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

If you ask me\, some function to make stuff readonly should have been made API somewhere

Suggestions?

a long time ago. Same goes for getting the refcount I suppose (setting it is pure insanity).

You can use B for that.

--

Father Chrysostomos

p5pRT commented 11 years ago

From @demerphq

On 21 August 2013 17:21\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

On Wed Aug 21 03:56:31 2013\, LeonT wrote:

On Wed\, Aug 7\, 2013 at 9:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

If you ask me\, some function to make stuff readonly should have been made API somewhere

Suggestions?

Mauve. :-)

Yves

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

p5pRT commented 11 years ago

From @Leont

On Wed\, Aug 21\, 2013 at 5:21 PM\, Father Chrysostomos via RT \< perlbug-followup@perl.org> wrote:

Suggestions?

Scalar::Util comes to mind\, even if it can be used on non-scalars.

You can use B for that.

I don't think that's really better than using Internals::

Leon

p5pRT commented 11 years ago

From @nwc10

On Thu\, Aug 22\, 2013 at 12:57:22PM +0200\, Leon Timmermans wrote:

On Wed\, Aug 21\, 2013 at 5:21 PM\, Father Chrysostomos via RT \< perlbug-followup@perl.org> wrote:

Suggestions?

Scalar::Util comes to mind\, even if it can be used on non-scalars.

Possibly there ought to be a restriction to using it only on scalars.

Setting the "read only" flag can mean different things on the other types. It's (currently) used to mark restricted hashes\, which aren't exactly read-only.

av.c suggests that arrays honour it\, at least partially. Note\, I don't trust arrays flagged READONLY to actually be immutable (given the contortions of the source) but I haven't actually found an exception. Yet.

Also\, Scalar::Util already has a readonly() function to read it\, but I'm not sure what "it" is. In that\, part of the frustration is that the flag bit SVf_READONLY means a whole bunch of things\, which might not always have the semantics of "read only" that the programmer thought. It's not well defined. Or at least\, not well specified.

You can use B for that.

I don't think that's really better than using Internals::

Devel::Peek::SvREFCNT

Nicholas Clark

p5pRT commented 11 years ago

From @cpansprout

On Thu Aug 22 04:14:44 2013\, nicholas wrote:

On Thu\, Aug 22\, 2013 at 12:57:22PM +0200\, Leon Timmermans wrote:

On Wed\, Aug 21\, 2013 at 5:21 PM\, Father Chrysostomos via RT \< perlbug-followup@perl.org> wrote:

Suggestions?

Scalar::Util comes to mind\, even if it can be used on non-scalars.

Possibly there ought to be a restriction to using it only on scalars.

That wouldn’t help Const::Fast\, as the failures are precisely due to a change in the way SvREADONLY(@a\,1) works\, for the sake of constant.pm.

Setting the "read only" flag can mean different things on the other types. It's (currently) used to mark restricted hashes\, which aren't exactly read-only.

av.c suggests that arrays honour it\, at least partially. Note\, I don't trust arrays flagged READONLY to actually be immutable (given the contortions of the source) but I haven't actually found an exception. Yet.

Also\, Scalar::Util already has a readonly() function to read it\, but I'm not sure what "it" is. In that\, part of the frustration is that the flag bit SVf_READONLY means a whole bunch of things\, which might not always have the semantics of "read only" that the programmer thought. It's not well defined. Or at least\, not well specified.

Yeah\, this whole area is a case in which people poke at the internals\, see what happens\, go ‘Oh\, neat!’\, and then start writing tests and depending on transient behaviour.

Until recently\, perl would merrily modify read-only scalars at compile time\, so the read-only flag has not offered any real protection.

--

Father Chrysostomos

p5pRT commented 11 years ago

From @ap

* Father Chrysostomos via RT \perlbug\-followup@perl\.org [2013-08-22 17:40]:

On Thu Aug 22 04:14:44 2013\, nicholas wrote:

On Thu\, Aug 22\, 2013 at 12:57:22PM +0200\, Leon Timmermans wrote:

Scalar::Util comes to mind\, even if it can be used on non-scalars.

Possibly there ought to be a restriction to using it only on scalars.

That wouldn’t help Const::Fast\, as the failures are precisely due to a change in the way SvREADONLY(@a\,1) works\, for the sake of constant.pm.

I don’t think that changes Nicholas’ point\, not at all really.

If that is what Const::Fast requires then there needs to be a function in… well unfortunately we have no corresponding Array::Util\, but maybe it is time for such.

Because…

Yeah\, this whole area is a case in which people poke at the internals\, see what happens\, go ‘Oh\, neat!’\, and then start writing tests and depending on transient behaviour.

… the only hope of ever getting out from under that mess is by offering API based on semantics\, not implementation\, i.e. these functions should be documented not as “sets the read-only flag” but as “makes the scalar read-only”\, and then likewise “makes the hash restricted” etc\, and they should do everything it takes to achieve whatever the docs say they do.

The point is that each such function should be named and documented after the end it achieves\, not the means it uses to provide it\, which should be of no concern or business to its user. Only that way will there ever be any hope of reducing the level of intimacy of CPAN with perl’s insides to some appropriate level.

Regards\, -- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 11 years ago

From @cpansprout

On Wed Aug 21 11:00:59 2013\, demerphq wrote:

On 21 August 2013 17:21\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

On Wed Aug 21 03:56:31 2013\, LeonT wrote:

On Wed\, Aug 7\, 2013 at 9:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

If you ask me\, some function to make stuff readonly should have been made API somewhere

Suggestions?

Mauve. :-)

OK\, let’s use this as an opportunity to discuss it. Where was the last thread on this (the one in which you complained about my cryptic response)?

--

Father Chrysostomos

p5pRT commented 11 years ago

From @tonycoz

On Sat\, Aug 24\, 2013 at 07:16:13PM -0700\, Father Chrysostomos via RT wrote:

On Wed Aug 21 11:00:59 2013\, demerphq wrote:

On 21 August 2013 17:21\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

On Wed Aug 21 03:56:31 2013\, LeonT wrote:

On Wed\, Aug 7\, 2013 at 9:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

If you ask me\, some function to make stuff readonly should have been made API somewhere

Suggestions?

Mauve. :-)

OK\, let’s use this as an opportunity to discuss it. Where was the last thread on this (the one in which you complained about my cryptic response)?

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be implemented as XS or pure perl\, and so would be available on any perl as:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what was available.

This would allow us to expose functions which probably should be exposed (like reftype perhaps) without cluttering the operator or global namespace\, and possibly allow for some optimizations (eg. replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name\, which AFAIK was never intended to be the final name\, so it was dropped.

Tony

p5pRT commented 11 years ago

From @ap

* Tony Cook \tony@develop\-help\.com [2013-08-26 01:45]:

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be implemented as XS or pure perl\, and so would be available on any perl as:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what was available.

This would allow us to expose functions which probably should be exposed (like reftype perhaps) without cluttering the operator or global namespace\, and possibly allow for some optimizations (eg. replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name\, which AFAIK was never intended to be the final name\, so it was dropped.

It wasn’t the name alone\, but yeah.

I think that describes the point of mauve poorly\, though. The idea was to provide core implementations of a number of functions mainly from Scalar::Util\, which would not require loading a module (and since this was a clean break these functions could also fix the niggly API design problems of the Scalar::Util functions)\, which Scalar::Util would then become a wrapper around (providing the old worse interface) where mauve was available.

Yves had the first inkling here: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=TCR8z+miH8T4j4Jzwq5ZmKh1mVSEuEbtQrSBE@mail.gmail.com

He started the fire: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTikHi8jbTshovEMQvdkROx8_JkrksaiqLpNDSDbB@mail.gmail.com

Unfortunately then-pumpking RGS didn’t like it at all: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=UHJ-1VMdZnh_KUrB=CTuageTErBGR1o728rGY@mail.gmail.com

So it went into quarantine: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=871v8twxr8.fsf@tardis.home.perldition.org

And ended up being something people merely pined for… http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20110427071804.GC6609@puppy http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CAOeq1c_Y=s6XeeP9TndE7RMqpcE60Yrinu5yzGO2YZ+DShfGCg@mail.gmail.com

Someday…

-- Aristotle Pagaltzis // \<http://plasmasturm.org/>

p5pRT commented 11 years ago

From @cpansprout

On Sun Aug 25 19:44:08 2013\, aristotle wrote:

* Tony Cook \tony@develop\-help\.com [2013-08-26 01:45]:

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be implemented as XS or pure perl\, and so would be available on any perl as:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what was available.

This would allow us to expose functions which probably should be exposed (like reftype perhaps) without cluttering the operator or global namespace\, and possibly allow for some optimizations (eg. replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name\, which AFAIK was never intended to be the final name\, so it was dropped.

It wasn’t the name alone\, but yeah.

I think that describes the point of mauve poorly\, though. The idea was to provide core implementations of a number of functions mainly from Scalar::Util\, which would not require loading a module (and since this was a clean break these functions could also fix the niggly API design problems of the Scalar::Util functions)\, which Scalar::Util would then become a wrapper around (providing the old worse interface) where mauve was available.

Yves had the first inkling here:

http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=TCR8z+miH8T4j4Jzwq5ZmKh1mVSEuEbtQrSBE@mail.gmail.com

He started the fire:

http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTikHi8jbTshovEMQvdkROx8_JkrksaiqLpNDSDbB@mail.gmail.com

Unfortunately then-pumpking RGS didn’t like it at all: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=UHJ- 1VMdZnh_KUrB=CTuageTErBGR1o728rGY@mail.gmail.com

So it went into quarantine:

http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=871v8twxr8.fsf@tardis.home.perldition.org

And ended up being something people merely pined for…

http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20110427071804.GC6609@puppy

http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CAOeq1c_Y=s6XeeP9TndE7RMqpcE60Yrinu5yzGO2YZ+DShfGCg@mail.gmail.com

Someday…

There was another thread last year on the topic\, not just touching on it. Ah\, here it is:

http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CANgJU+VaLN6oitD5JJ91QiYO4fjkn9n4X3YrBV_WYKkfrygm_Q@mail.gmail.com

--

Father Chrysostomos

p5pRT commented 11 years ago

From @xdg

On Wed\, Aug 7\, 2013 at 3:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

To work around this\, I would have to add *more* Internals:: functions for constant.pm to use. I hope I don’t have to do that.

I don't think constant.pm should have any priviledged status with respect to Internals. If it can use Internals\, then Internals is not really Internal.

I agree with Aristotle when he said this:

… the only hope of ever getting out from under that mess is by offering API based on semantics\, not implementation\, i.e. these functions should be documented not as “sets the read-only flag” but as “makes the scalar read-only”\, and then likewise “makes the hash restricted” etc\, and they should do everything it takes to achieve whatever the docs say they do.

The point is that each such function should be named and documented after the end it achieves\, not the means it uses to provide it\, which should be of no concern or business to its user. Only that way will there ever be any hope of reducing the level of intimacy of CPAN with perl’s insides to some appropriate level.

Frankly\, I'd be pretty happen to have a "set_readonly" added to Scalar::Util (or mauve). 99% of the time I want a read-only it's a scalar\, anyway. If the semantics don't work well for arrays and hashes\, then let's not bother.

David

-- David Golden \xdg@xdg\.me Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg

p5pRT commented 11 years ago

From @Leont

On Fri\, Sep 20\, 2013 at 10:01 PM\, David Golden \xdg@xdg\.me wrote:

On Wed\, Aug 7\, 2013 at 3:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

To work around this\, I would have to add *more* Internals:: functions for constant.pm to use. I hope I don’t have to do that.

I don't think constant.pm should have any priviledged status with respect to Internals. If it can use Internals\, then Internals is not really Internal.

Yes\, this.

If the semantics broke because internal reason that's one thing\, but breaking it because it's convenient in another module seems a bit unfair.

Leon

p5pRT commented 11 years ago

From @cpansprout

On Fri Sep 20 13:02:59 2013\, xdg@xdg.me wrote:

On Wed\, Aug 7\, 2013 at 3:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

To work around this\, I would have to add *more* Internals:: functions for constant.pm to use. I hope I don’t have to do that.

I don't think constant.pm should have any priviledged status with respect to Internals. If it can use Internals\, then Internals is not really Internal.

constant.pm is already special though\, in that it uses (and depends on) undocumented use of stash manipulation.

I agree with Aristotle when he said this:

… the only hope of ever getting out from under that mess is by offering API based on semantics\, not implementation\, i.e. these functions should be documented not as “sets the read-only flag” but as “makes the scalar read-only”\, and then likewise “makes the hash restricted” etc\, and they should do everything it takes to achieve whatever the docs say they do.

The point is that each such function should be named and documented after the end it achieves\, not the means it uses to provide it\, which should be of no concern or business to its user. Only that way will there ever be any hope of reducing the level of intimacy of CPAN with perl’s insides to some appropriate level.

Frankly\, I'd be pretty happen to have a "set_readonly" added to Scalar::Util (or mauve). 99% of the time I want a read-only it's a scalar\, anyway.

I have been thinking about this for a while. Since making something read-only is not a common task (like blessed or refaddr)\, it probably does not belong in libperl\, prior art notwithstanding. Scalar::Util is a good place for it. I would call it make_readonly.

(But I do want to get mauve resolved for 5.20. I’ve been mentally drafting a response to \CANgJU\+Vb=36TMZcqU7Ti70GV\_=jUL86EhfZFFhcZKAFLy\+3onQ@mail\.gmail\.com\, but it hasn’t materialised yet.)

If the semantics don't work well for arrays and hashes\, then let's not bother.

It’s precisely the array case that is now broken for Const::Fast.

Someone suggested adding Array::Util\, like Hash::Util. That may be the correct approach.

On the other hand\, we could cheat and allow Scalar::Util::make_readonly to take an array.

I think I prefer the former\, but I’m ambivalent.

--

Father Chrysostomos

p5pRT commented 10 years ago

From @andk

"Leon Timmermans via RT" \perlbug\-followup@perl\.org writes:

If the semantics broke because internal reason that's one thing\, but breaking it because it's convenient in another module seems a bit unfair.

I'm tempted to throw an ESTALLEDTOOLONG in\, especially given that there are 33 reverse dependencies [0] untested with blead since August 7.

-- andreas [0] https://metacpan.org/requires/distribution/Const-Fast

p5pRT commented 10 years ago

From perl5-porters@perl.org

Andreas Koenig wrote:

"Leon Timmermans via RT" \perlbug\-followup@perl\.org writes:

If the semantics broke because internal reason that's one thing\, but breaking it because it's convenient in another module seems a bit unfair.

Oddly\, nobody complained when I broke autobox for the sake of strict.pm.

I'm tempted to throw an ESTALLEDTOOLONG in\, especially given that there are 33 reverse dependencies [0] untested with blead since August 7.

But what does ESTALLEDTOOLONG mean?

The problem here is that nobody has commented on my proposed solu- tions. I have a third solution up my sleeve that I plan to imple- ment if nothing else. It may be controversial\, but it will not step on anybody's toes.

p5pRT commented 10 years ago

From @andk

Father Chrysostomos \sprout@cpan\.org writes:

I'm tempted to throw an ESTALLEDTOOLONG in\, especially given that there are 33 reverse dependencies [0] untested with blead since August 7.

But what does ESTALLEDTOOLONG mean?

Sorry\, I just felt like making up a funny sounding term. Probably best translation being Ping.

-- andreas

p5pRT commented 10 years ago

From @Leont

On Sun\, Dec 22\, 2013 at 2:38 PM\, Andreas Koenig \< andreas.koenig.7os6VVqR@franz.ak.mind.de> wrote:

"Leon Timmermans via RT" \perlbug\-followup@perl\.org writes:

If the semantics broke because internal reason that's one thing\, but breaking it because it's convenient in another module seems a bit unfair.

I'm tempted to throw an ESTALLEDTOOLONG in\, especially given that there are 33 reverse dependencies [0] untested with blead since August 7.

This is not stalled on technical grounds\, but on a lack of decision.

Leon

p5pRT commented 10 years ago

From @demerphq

On 26 August 2013 01:43\, Tony Cook \tony@develop\-help\.com wrote:

On Sat\, Aug 24\, 2013 at 07:16:13PM -0700\, Father Chrysostomos via RT wrote:

On Wed Aug 21 11:00:59 2013\, demerphq wrote:

On 21 August 2013 17:21\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

On Wed Aug 21 03:56:31 2013\, LeonT wrote:

On Wed\, Aug 7\, 2013 at 9:53 AM\, Father Chrysostomos via RT \perlbug\-followup@perl\.org wrote:

Oh no!

These two modules are using Internals:: functions\, so it is officially ‘their fault’.

If you ask me\, some function to make stuff readonly should have been made API somewhere

Suggestions?

Mauve. :-)

OK\, let’s use this as an opportunity to discuss it. Where was the last thread on this (the one in which you complained about my cryptic response)?

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be implemented as XS or pure perl\, and so would be available on any perl as:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what was available.

This would allow us to expose functions which probably should be exposed (like reftype perhaps) without cluttering the operator or global namespace\, and possibly allow for some optimizations (eg. replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name\, which AFAIK was never intended to be the final name\, so it was dropped.

Thanks\, this is an excellent summary.

Yves

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

p5pRT commented 10 years ago

From @demerphq

On 26 August 2013 04:43\, Aristotle Pagaltzis \pagaltzis@gmx\.de wrote:

* Tony Cook \tony@develop\-help\.com [2013-08-26 01:45]:

mauve was a placeholder namespace to expose documented internals.

On perl's which didn't expose those internals they could be implemented as XS or pure perl\, and so would be available on any perl as:

use mauve qw(reftype);

which would use the internal or XS/PP implementation depending on what was available.

This would allow us to expose functions which probably should be exposed (like reftype perhaps) without cluttering the operator or global namespace\, and possibly allow for some optimizations (eg. replacing the call with an operator.)

Unfortunately it turned into an annoying bikeshed over the name\, which AFAIK was never intended to be the final name\, so it was dropped.

It wasn’t the name alone\, but yeah.

I think that describes the point of mauve poorly\, though. The idea was to provide core implementations of a number of functions mainly from Scalar::Util\, which would not require loading a module (and since this was a clean break these functions could also fix the niggly API design problems of the Scalar::Util functions)\, which Scalar::Util would then become a wrapper around (providing the old worse interface) where mauve was available.

Yves had the first inkling here: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=TCR8z+miH8T4j4Jzwq5ZmKh1mVSEuEbtQrSBE@mail.gmail.com

He started the fire: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTikHi8jbTshovEMQvdkROx8_JkrksaiqLpNDSDbB@mail.gmail.com

Unfortunately then-pumpking RGS didn’t like it at all: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=AANLkTi=UHJ-1VMdZnh_KUrB=CTuageTErBGR1o728rGY@mail.gmail.com

So it went into quarantine: http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=871v8twxr8.fsf@tardis.home.perldition.org

And ended up being something people merely pined for… http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=20110427071804.GC6609@puppy http://www.nntp.perl.org/group/perl.perl5.porters/;msgid=CAOeq1c_Y=s6XeeP9TndE7RMqpcE60Yrinu5yzGO2YZ+DShfGCg@mail.gmail.com

Someday…

Yeah\, I still think this was a totally lost opportunity to move forward with some of these issues.

Yves

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

p5pRT commented 10 years ago

From @cpansprout

I have resolved this in commit 2c6c1df5c2dd by finding another way to meet constant.pm’s needs.

--

Father Chrysostomos

p5pRT commented 10 years ago

@cpansprout - Status changed from 'open' to 'resolved'

Perl / perl5