Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem in documentation of Fcntl constants #1079

Closed
p5pRT opened this issue Jan 25, 2000 · 23 comments
Closed

Problem in documentation of Fcntl constants #1079

p5pRT opened this issue Jan 25, 2000 · 23 comments

Comments

@p5pRT
Copy link

p5pRT commented Jan 25, 2000

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

Searchable as RT2032$

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From warren-odom@stenocall.com

After a discussion in the perl.misc newsgroup, everyone agreed that the
operation should be a logical OR, not an ADD. I'm submitting this as a
documentation bug, in hopes that this is the appropriate channel to get the
document changed. In conjunction with the bug in the definition of the
constants themselves (reported in my previous Email), this caused me
tremendous problems.

  -- Warren

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

After a discussion in the perl.misc newsgroup, everyone agreed that the
operation should be a logical OR, not an ADD. I'm submitting this as a
documentation bug, in hopes that this is the appropriate channel to get the
document changed. In conjunction with the bug in the definition of the
constants themselves (reported in my previous Email), this caused me
tremendous problems.

One "adds in" a bit using bitwise OR, not logical OR.
Note also that flock bits are powers of two, which means integer add
and bitwise OR are the same for the domain involved.

--tom

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

(copy of message that was sent to Tom Christiansen, in reply to his
message...)

OK, I was using "logical OR" as a synomym for "bitwise OR." Anyway, first
of all, addition doesn't work for the Fcntl constants, as I reported a few
minutes ago [ID 20000125.001]. Second, of course I noticed that the flock
bits are powers of two-and was roundly criticized in the newsgroup for
assuming so. And I have to admit it's not good programming practice.
Symbolic constants are not only mnemonic devices, but also
information-hiding devices. And you can't rule out (in principle) multi-bit
constants and/or the programmer's accidental duplication of a constant in
the addition, causing arithmetic carry problems. For the full discussion,
please see the thread beginning 1/19/2000 entitled "Problem with Fcntl
constants."

The point is, a literal reading of the documentation (and isn't that how
it's supposed to be read?) states that integer addition is the proper way to
combine these constants, when in fact not only is it not good practice-but
also just plain doesn't work.

  -- Warren

-----Original Message-----
From​: Tom Christiansen [mailto​:tchrist@​chthon.perl.com]
Sent​: Tuesday, January 25, 2000 12​:31 PM
To​: Warren Odom
Cc​: perl5-porters@​perl.org; tchrist@​chthon.perl.com
Subject​: Re​: [ID 20000125.002] Problem in documentation of Fcntl constants

After a discussion in the perl.misc newsgroup, everyone agreed that the
operation should be a logical OR, not an ADD. I'm submitting this as a
documentation bug, in hopes that this is the appropriate channel to get the
document changed. In conjunction with the bug in the definition of the
constants themselves (reported in my previous Email), this caused me
tremendous problems.

One "adds in" a bit using bitwise OR, not logical OR.
Note also that flock bits are powers of two, which means integer add
and bitwise OR are the same for the domain involved.

--tom

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

I think you are overreaching.

And Perl has historically expected people to use 1, 2, 4, and 8. It's
only recently that the constants were available.

  % perl -le 'use Fcntl "​:flock"; print LOCK_SH'
  1
  % perl -le 'use Fcntl "​:flock"; print LOCK_EX'
  2
  % perl -le 'use Fcntl "​:flock"; print LOCK_NB'
  4
  % perl -le 'use Fcntl "​:flock"; print LOCK_UN'
  8

Sounds like people are too uptight. Perl is well-defined
as to what flock(FH, 6) means. It has to be, because a lot
of cruddy systems don't have a proper flock(2), so it has
to convert.

--tom

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From @RandalSchwartz

"Warren" == Warren Odom <warren-odom@​stenocall.com> writes​:

Warren> The point is, a literal reading of the documentation (and
Warren> isn't that how it's supposed to be read?) states that integer
Warren> addition is the proper way to combine these constants, when in
Warren> fact not only is it not good practice-but also just plain
Warren> doesn't work.

But it *does* work. You just happened to stumble into a combination
of factors... that the AUTOLOADed constants can get parsed in an
unexpected way.

2 + 4 is 2 | 4. Same value. Adding works fine.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@​stonehenge.com> <URL​:http​://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

From pp_sys.c​:

  # ifdef FLOCK
  static int FLOCK (int, int);

  /*
  * These are the flock() constants. Since this sytems doesn't have
  * flock(), the values of the constants are probably not available.
  */
  # ifndef LOCK_SH
  # define LOCK_SH 1
  # endif
  # ifndef LOCK_EX
  # define LOCK_EX 2
  # endif
  # ifndef LOCK_NB
  # define LOCK_NB 4
  # endif
  # ifndef LOCK_UN
  # define LOCK_UN 8
  # endif
  # endif /* emulating flock() */

  #endif /* no flock() */

  fcntl_emulate_flock(int fd, int operation)
  {
  struct flock flock;
 
  switch (operation & ~LOCK_NB) {
  case LOCK_SH​:
  flock.l_type = F_RDLCK;
  break;
  case LOCK_EX​:
  flock.l_type = F_WRLCK;
  break;
  case LOCK_UN​:
  flock.l_type = F_UNLCK;
  break;
  default​:
  errno = EINVAL;
  return -1;
  }
  flock.l_whence = SEEK_SET;
  flock.l_start = flock.l_len = (Off_t)0;
 
  return fcntl(fd, (operation & LOCK_NB) ? F_SETLK : F_SETLKW, &flock);
  }

The values of LOCK_?? are "famous". People pass in 6, and expect it to
mean FLOCK_EX|FLOCK_NB. In fact, you'll break programs if you don't do
this.

--tom

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

<<I think you are overreaching....Sounds like people are too uptight.>>

Man, now I kinda wish you'd been there to support me in the newsgroup! I
was just condensing and relaying to you the main points of opposition that
were raised there, as I defended my use of addition. But, as I said, even I
had to ultimately abandon that defense. (Of course, you are quite welcome
to add your comments to the newsgroup thread.)

<<And Perl has historically expected people to use 1, 2, 4, and 8. It's
only recently that the constants were available.>>

Well, yes, there are lots of things that mankind did before better solutions
were available. In my early programming years, I probably would have
maintained that addition was just as good as OR-ing, and numeric constants
just as good as symbolic ones-but not since I was taught good programming
practice. Every book and article on the subject has symbolic constants as
one of the "must do" things.

But I don't see why any objection would be raised to saying "or" instead of
"add" in the documentation. It's so each to change. After all, every Perl
book on my "CD Bookshelf" (including yours) that covers these constants
either says to use OR, or refers to the flock manpage which also says to use
OR.

And, again, using addition gives the wrong answer.

  -- Warren

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

Avoiding the encapsulation vs. expose-the-ductwork debate, the point still
remains that that the :flock constants are prototyped as sub LOCK_SH {...}
not sub LOCK_SH() { ... }​:

  *$AUTOLOAD = sub { $val };

causing a working C idiom LOCK_SH + LOCK_NB to fail in Perl.

Here's one possible fix against 5.5's Fcntl.pm, if a fix is desired
(sorry, no diff -u at this client's site)​:
-----------------------------------8<------------------------------------
53,92c53,93
< @​EXPORT =
< qw(
< FD_CLOEXEC
< F_DUPFD
< F_EXLCK
< F_GETFD
< F_GETFL
< F_GETLK
< F_GETOWN
< F_POSIX
< F_RDLCK
< F_SETFD
< F_SETFL
< F_SETLK
< F_SETLKW
< F_SETOWN
< F_SHLCK
< F_UNLCK
< F_WRLCK
< O_ACCMODE
< O_APPEND
< O_ASYNC
< O_BINARY
< O_CREAT
< O_DEFER
< O_DSYNC
< O_EXCL
< O_EXLOCK
< O_NDELAY
< O_NOCTTY
< O_NONBLOCK
< O_RDONLY
< O_RDWR
< O_RSYNC
< O_SHLOCK
< O_SYNC
< O_TEXT
< O_TRUNC
< O_WRONLY
< );


BEGIN {
@​EXPORT =
qw(
FD_CLOEXEC
F_DUPFD
F_EXLCK
F_GETFD
F_GETFL
F_GETLK
F_GETOWN
F_POSIX
F_RDLCK
F_SETFD
F_SETFL
F_SETLK
F_SETLKW
F_SETOWN
F_SHLCK
F_UNLCK
F_WRLCK
O_ACCMODE
O_APPEND
O_ASYNC
O_BINARY
O_CREAT
O_DEFER
O_DSYNC
O_EXCL
O_EXLOCK
O_NDELAY
O_NOCTTY
O_NONBLOCK
O_RDONLY
O_RDWR
O_RSYNC
O_SHLOCK
O_SYNC
O_TEXT
O_TRUNC
O_WRONLY
);
94,109c95,117
< # Other items we are prepared to export if requested
< @​EXPORT_OK = qw(
< FAPPEND
< FASYNC
< FCREAT
< FDEFER
< FEXCL
< FNDELAY
< FNONBLOCK
< FSYNC
< FTRUNC
< LOCK_EX
< LOCK_NB
< LOCK_SH
< LOCK_UN
< );


\# Other items we are prepared to export if requested
@&#8203;EXPORT\_OK = qw\(
      FAPPEND
      FASYNC
      FCREAT
      FDEFER
      FEXCL
      FNDELAY
      FNONBLOCK
      FSYNC
      FTRUNC
      LOCK\_EX
      LOCK\_NB
      LOCK\_SH
      LOCK\_UN
\);

for ( @​EXPORT, @​EXPORT_OK ) {
my $sub = "sub $_() ;" ;
eval $sub ;
die "$@​​: $sub" if $@​ ;
}
}

114c122
< FNDELAY FNONBLOCK FSYNC FTRUNC)],


               FNDELAY FNONBLOCK FSYNC FTRUNC\)\]\,

131c139
< *$AUTOLOAD = sub { $val };


\*$AUTOLOAD = sub\(\) \{ $val \};

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

"Warren" == Warren Odom <warren-odom@​stenocall.com> writes​:

Warren> The point is, a literal reading of the documentation (and
Warren> isn't that how it's supposed to be read?) states that integer
Warren> addition is the proper way to combine these constants, when in
Warren> fact not only is it not good practice-but also just plain
Warren> doesn't work.

<<But it *does* work. You just happened to stumble into a combination
of factors... that the AUTOLOADed constants can get parsed in an
unexpected way.
2 + 4 is 2 | 4. Same value. Adding works fine.>>

I'm not sure how to respond to this, because your example is not an
illustration of what I'm talking about. Yes, 2 + 4 is the same as 2 | 4,
but the point is, we've seen clearly that LOCK_EX + LOCK_NB is not the same
as LOCK_EX | LOCK_NB. Adding of those Fcntl symbolic constants (in various
contexts, including the context for which they are specifically designed)
doesn't work (and by that I mean it gives the wrong answer, implying 2 + 4 =
2 or 4 + 2 = 4, depending on the ordering of the constants). The reason it
fails (unexpected parsing) doesn't matter.

And since every other Perl reference says use OR, and since it's an
easy--almost trivial--change, what's the problem with bringing the
"official" documentation in line with them? If I stumbled into this
situation, others will too. In fact, according to his newsgroup posting,
Larry Rosler already stumbled into it a few months ago.

  -- Warren

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

If a fix is that simple, then great--you have definitely brightened up my
day....

  -- Warren

-----Original Message-----
From​: Barrie Slaymaker [mailto​:barries@​slaysys.com]
Sent​: Tuesday, January 25, 2000 2​:43 PM
To​: Tom Christiansen
Cc​: Warren Odom; perl5-porters@​perl.org
Subject​: Re​: [ID 20000125.002] Problem in documentation of Fcntl constants

Avoiding the encapsulation vs. expose-the-ductwork debate, the point still
remains that that the :flock constants are prototyped as sub LOCK_SH {...}
not sub LOCK_SH() { ... }​:

  *$AUTOLOAD = sub { $val };

causing a working C idiom LOCK_SH + LOCK_NB to fail in Perl.

Here's one possible fix against 5.5's Fcntl.pm, if a fix is desired
(sorry, no diff -u at this client's site)​:
-----------------------------------8<------------------------------------
53,92c53,93
< @​EXPORT =
< qw(
< FD_CLOEXEC
< F_DUPFD
< F_EXLCK
< F_GETFD
< F_GETFL
< F_GETLK
< F_GETOWN
< F_POSIX
< F_RDLCK
< F_SETFD
< F_SETFL
< F_SETLK
< F_SETLKW
< F_SETOWN
< F_SHLCK
< F_UNLCK
< F_WRLCK
< O_ACCMODE
< O_APPEND
< O_ASYNC
< O_BINARY
< O_CREAT
< O_DEFER
< O_DSYNC
< O_EXCL
< O_EXLOCK
< O_NDELAY
< O_NOCTTY
< O_NONBLOCK
< O_RDONLY
< O_RDWR
< O_RSYNC
< O_SHLOCK
< O_SYNC
< O_TEXT
< O_TRUNC
< O_WRONLY
< );


BEGIN {
@​EXPORT =
qw(
FD_CLOEXEC
F_DUPFD
F_EXLCK
F_GETFD
F_GETFL
F_GETLK
F_GETOWN
F_POSIX
F_RDLCK
F_SETFD
F_SETFL
F_SETLK
F_SETLKW
F_SETOWN
F_SHLCK
F_UNLCK
F_WRLCK
O_ACCMODE
O_APPEND
O_ASYNC
O_BINARY
O_CREAT
O_DEFER
O_DSYNC
O_EXCL
O_EXLOCK
O_NDELAY
O_NOCTTY
O_NONBLOCK
O_RDONLY
O_RDWR
O_RSYNC
O_SHLOCK
O_SYNC
O_TEXT
O_TRUNC
O_WRONLY
);
94,109c95,117
< # Other items we are prepared to export if requested
< @​EXPORT_OK = qw(
< FAPPEND
< FASYNC
< FCREAT
< FDEFER
< FEXCL
< FNDELAY
< FNONBLOCK
< FSYNC
< FTRUNC
< LOCK_EX
< LOCK_NB
< LOCK_SH
< LOCK_UN
< );


\# Other items we are prepared to export if requested
@&#8203;EXPORT\_OK = qw\(
      FAPPEND
      FASYNC
      FCREAT
      FDEFER
      FEXCL
      FNDELAY
      FNONBLOCK
      FSYNC
      FTRUNC
      LOCK\_EX
      LOCK\_NB
      LOCK\_SH
      LOCK\_UN
\);

for ( @​EXPORT, @​EXPORT_OK ) {
my $sub = "sub $_() ;" ;
eval $sub ;
die "$@​​: $sub" if $@​ ;
}
}

114c122
< FNDELAY FNONBLOCK FSYNC FTRUNC)],


               FNDELAY FNONBLOCK FSYNC FTRUNC\)\]\,

131c139
< *$AUTOLOAD = sub { $val };


\*$AUTOLOAD = sub\(\) \{ $val \};

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

Avoiding the encapsulation vs. expose-the-ductwork debate, the point still
remains that that the :flock constants are prototyped as sub LOCK_SH {...}
not sub LOCK_SH() { ... }​:

*$AUTOLOAD = sub { $val };

causing a working C idiom LOCK_SH + LOCK_NB to fail in Perl.

Oh, I see. Yes, the whole default context coercion prototypes were
introduced to address this very sort of issue. I didn't realize
that they hadn't been fixed up.

--tom

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From [Unknown Contact. See original ticket]

Warren Odom wrote​:

If a fix is that simple, then great--you have definitely brightened up my
day....

As Tom mentions later, it seems that it shouldn't be necessary. And if
it is, it could be done with lower CPU overhead in atleast two ways​:
just manually listing all of the prototypes, and by overloading import
and only eval()-ing when necessary.

Just let me know if it's wanted...

- Barrie

@p5pRT
Copy link
Author

p5pRT commented Jan 25, 2000

From @gsar

On Tue, 25 Jan 2000 17​:45​:11 EST, Barrie Slaymaker wrote​:

As Tom mentions later, it seems that it shouldn't be necessary. And if
it is, it could be done with lower CPU overhead in atleast two ways​:
just manually listing all of the prototypes, and by overloading import
and only eval()-ing when necessary.

I think the better approach is to make h2xs generate newCONSTSUB() entries
for constants, and do away with encouraging the AUTOLOAD-based mechanism
altogether. ext/B/defsubs_h.PL does this already.

Sarathy
gsar@​ActiveState.com

@p5pRT
Copy link
Author

p5pRT commented Jan 26, 2000

From [Unknown Contact. See original ticket]

Gurusamy Sarathy writes​:

On Tue, 25 Jan 2000 17​:45​:11 EST, Barrie Slaymaker wrote​:

As Tom mentions later, it seems that it shouldn't be necessary. And if
it is, it could be done with lower CPU overhead in atleast two ways​:
just manually listing all of the prototypes, and by overloading import
and only eval()-ing when necessary.

I think the better approach is to make h2xs generate newCONSTSUB() entries
for constants, and do away with encouraging the AUTOLOAD-based mechanism
altogether. ext/B/defsubs_h.PL does this already.

This in an enormous overhead. Imagine loading a module with 6000
constants taking 6M just-for-nothing.

Putting prototypes may be a better solution for largish modules​:
prototypes takes circa 120bytes per a proto.

Ilya

@p5pRT
Copy link
Author

p5pRT commented Jan 26, 2000

From @gsar

On Wed, 26 Jan 2000 15​:43​:22 EST, Ilya Zakharevich wrote​:

Gurusamy Sarathy writes​:

I think the better approach is to make h2xs generate newCONSTSUB() entries
for constants, and do away with encouraging the AUTOLOAD-based mechanism
altogether. ext/B/defsubs_h.PL does this already.

This in an enormous overhead. Imagine loading a module with 6000
constants taking 6M just-for-nothing.

Putting prototypes may be a better solution for largish modules​:
prototypes takes circa 120bytes per a proto.

OK, h2xs should be able to generate those automatically too. That lets
us keep the AUTOLOAD based scheme.

Advance thanks to the person who's going to send me the patch.

Sarathy
gsar@​ActiveState.com

@p5pRT
Copy link
Author

p5pRT commented Jan 28, 2000

From [Unknown Contact. See original ticket]

Gurusamy Sarathy writes​:

This in an enormous overhead. Imagine loading a module with 6000
constants taking 6M just-for-nothing.

Putting prototypes may be a better solution for largish modules​:
prototypes takes circa 120bytes per a proto.

OK, h2xs should be able to generate those automatically too. That lets
us keep the AUTOLOAD based scheme.

Advance thanks to the person who's going to send me the patch.

I would not *deeply* thank anyone who implements such a botched
workaround. The problem is that AUTOLOAD mechanism turned out to be a
hindrance, not an advantage. *This* is the problem to solve.

"Real" autoload would provide a way to get a reference to the
autoloaded subroutine without executing it, and would allow a
compile-time hook (when the name of the subroutine is first seen).

Say, a compile-time hook could provide the prototype for the
subroutine, and the run-time hook would define the subroutine's body.
Or the compile-time hook could load the definition of the subroutine
itself, if preferable.

Given the current preference of no-new-magic-uppercase-names, what about

  use autoload proto => \&get_proto, body => \&get_body;

or some such? BTW, return of undef from these subroutines could mean
"continue searching", which would help digest another can of worms...

Ilya

@p5pRT
Copy link
Author

p5pRT commented Jan 29, 2000

From [Unknown Contact. See original ticket]

On Sat, Jan 29, 2000 at 02​:05​:32AM -0500, Ilya Zakharevich <ilya@​math.ohio-state.edu> wrote​:

"Real" autoload would provide a way to get a reference to the
autoloaded subroutine without executing it, and would allow a

Oh yes ;)

Given the current preference of no-new-magic-uppercase-names, what about

use autoload proto => \&get_proto, body => \&get_body;

modules like the gimp do not know wether a function to autoload exists
before it is being called, so it would be even cooler if there were some kind
of fall-back mechanism who behaved similar to the current AUTOLOAD, except
that it would return a reference.

BTW, it might be even better to have some hook which only _looked_ wether
some function exists, but neither loads it nor executes it. _I_ definitely
would have uses for this kind of hook.

--
  -----==- |
  ----==-- _ |
  ---==---(_)__ __ ____ __ Marc Lehmann +--
  --==---/ / _ \/ // /\ \/ / pcg@​opengroup.org |e|
  -=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
  The choice of a GNU generation |
  |

@p5pRT
Copy link
Author

p5pRT commented Jan 29, 2000

From [Unknown Contact. See original ticket]

Marc Lehmann writes​:

"Real" autoload would provide a way to get a reference to the
autoloaded subroutine without executing it, and would allow a

Given the current preference of no-new-magic-uppercase-names, what about

use autoload proto => \&get_proto, body => \&get_body;

modules like the gimp do not know wether a function to autoload exists
before it is being called, so it would be even cooler if there were some kind
of fall-back mechanism who behaved similar to the current AUTOLOAD, except
that it would return a reference.

Yes, this is body => \&get_body in the above example.

BTW, it might be even better to have some hook which only _looked_ wether
some function exists, but neither loads it nor executes it. _I_ definitely
would have uses for this kind of hook.

This is exactly proto => \&get_proto.

Ilya

@p5pRT
Copy link
Author

p5pRT commented Jul 13, 2005

From @schwern

[warren-odom@​stenocall.com - Tue Jan 25 02​:26​:08 2000]​:

After a discussion in the perl.misc newsgroup, everyone agreed that the
operation should be a logical OR, not an ADD. I'm submitting this as a
documentation bug, in hopes that this is the appropriate channel to
get the
document changed. In conjunction with the bug in the definition of the
constants themselves (reported in my previous Email), this caused me
tremendous problems.

Anyone remember what this bug was all about? I read what information is
in the tracker but it rapidly devolves into an autoload discussion.

@p5pRT
Copy link
Author

p5pRT commented Jul 5, 2006

@smpeters - Status changed from 'open' to 'stalled'

@p5pRT
Copy link
Author

p5pRT commented Jul 10, 2010

From @gannett-ggreer

On Tue Jul 12 19​:51​:57 2005, schwern wrote​:

[warren-odom@​stenocall.com - Tue Jan 25 02​:26​:08 2000]​:

After a discussion in the perl.misc newsgroup, everyone agreed that the
operation should be a logical OR, not an ADD. I'm submitting this as a
documentation bug, in hopes that this is the appropriate channel to
get the
document changed. In conjunction with the bug in the definition of the
constants themselves (reported in my previous Email), this caused me
tremendous problems.

Anyone remember what this bug was all about? I read what information is
in the tracker but it rapidly devolves into an autoload discussion.

This was fixed in ea3105b by Gurusamy
Sarathy on February 2nd, 2000​:

"" flock() pod talks about "adding" in the sense of "or-ing" ""

It formerly read "If LOCK_NB is added to LOCK_SH..." but now reads "If
LOCK_NB is bitwise-or'ed with LOCK_SH...

So this ticket can be closed.

http​://rt.perl.org/rt3/Ticket/Display.html?id=2032

--
George Greer

@p5pRT
Copy link
Author

p5pRT commented Jul 10, 2010

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

@p5pRT
Copy link
Author

p5pRT commented Jul 11, 2010

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant