Re: r25182 - docs/Perl6/Spec
Em Sex, 2009-02-06 às 02:07 -0500, Brandon S. Allbery KF8NH escreveu: +=head2 IO::POSIX + +Indicates that this object can perform standard posix IO operations. I don't like that wording, but getting it right seems tricky. Do we want/need to deal with POSIX conformance levels? When I suggested the name IO::POSIX, it was certainly pointing in that direction. Someone with a deeper understanding on that matter could certainly help mapping that out. In a pratical sense, we're probably going to see IO::Linux26 which might does IO::POSIXsomelevel as well as does IO::BSDinpart and does IO::SysVsomewhat. Additionally, we may have IO::Win32 which doesn't seem to fit in any of those roles... I would think fcntl() is just the Unix version of a more general concept, which is probably wider than POSIX. Maybe this wider concepts can be expressed in their own roles, as already been suggested here, as we have IO::Readable and IO::Writeable. IO::Flock is something that looks right to me, where IO::Linux26 does IO::Flock (even if IO::POSIX doesn't). (I use flock as an example because I'm not sure how fcntl applies to a non-posix OS, since that's the name of a POSIX function). Even given this, if we want compatibility we might provide stuff in IO::POSIX (IO::VMS, IO::Windows, whatever) which translates to these calls. I think that's up to the more concrete roles IO::Linux26, IO::Win32 IO::Solaris etc daniel
Re: r25182 - docs/Perl6/Spec
On 2009 Feb 6, at 6:24, Daniel Ruoso wrote: Em Sex, 2009-02-06 às 02:07 -0500, Brandon S. Allbery KF8NH escreveu: I would think fcntl() is just the Unix version of a more general concept, which is probably wider than POSIX. Maybe this wider concepts can be expressed in their own roles, as already been suggested here, as we have IO::Readable and IO::Writeable. IO::Flock is something that looks right to me, where IO::Linux26 does IO::Flock (even if IO::POSIX doesn't). (I use flock as an example because I'm not sure how fcntl applies to a non-posix OS, since that's the name of a POSIX function). fcntl = file descriptor control/configuration. While the name itself is POSIX, the range of possible actions described by it is larger than that. (Yes, one could just compose roles with individual actions, thus making fcntl() disappear altogether. But you will not be thanked by someone who has to work out exactly which roles s/he needs to implement for a given IO-like object, nor by the unfortunate tasked with porting perl5 code.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: r25182 - docs/Perl6/Spec
On 2009 Feb 4, at 11:45, Aaron Crane wrote:
FWIW, I prefer the traditional spelling, writable. Google suggests
that writeable is more common on the web, though; 4.8 versus 3.7
Mghits.
I have to admit that writable suggests to me that you can serve a
writ on it; an unlikely case for even Perl6 I/O. :)
+=head2 IO::POSIX
+
+Indicates that this object can perform standard posix IO operations.
I don't like that wording, but getting it right seems tricky. The
problem is that I don't think you mean for IO::POSIX to contain
methods corresponding to POSIX-ish read(2), write(2), given that
methods of those names exist in other roles. But those are precisely
what I'd think of as most obviously falling into the category of
standard POSIX I/O operations.
Do we want/need to deal with POSIX conformance levels?
* It seems a little odd to put an flock method in an IO::POSIX role,
given that POSIX specifies fcntl(F_SETLK) in place of traditional
BSD-ish flock(). I'd be in favour of having .fcntl in IO::POSIX, but
with an additional role providing .flock (IO::Flock, presumably).
I would think fcntl() is just the Unix version of a more general
concept, which is probably wider than POSIX. As such, we may want to
think about what is suitable for this. (I can see some ioctl() stuff
fitting here, and possibly even some of setsockopt(), from the POSIXy
end. I also have the impression that {,Open}VMS has some interest
here.) Locking would then be a separate interface, even though on
POSIX it uses the same system call as fileDescriptorConfigure or
whatever the general call here is named.
Likewise POSIX pathconf() seems like a specific variant of a more
general interface based on paths instead of file descriptors.
Although I'm not sure what else would fit in here (ignoring something
like pioctl() that only a small subset of Perl6 users would care
about)... but that's quite possibly because I'm not very familiar with
non-Unix/POSIX options.
Even given this, if we want compatibility we might provide stuff in
IO::POSIX (IO::VMS, IO::Windows, whatever) which translates to these
calls.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH
PGP.sig
Description: This is a digitally signed message part
Re: r25182 - docs/Perl6/Spec
On 2009 Feb 4, at 12:56, Leon Timmermans wrote: On Wed, Feb 4, 2009 at 4:37 PM, pugs-comm...@feather.perl6.nl wrote: +=item method IO dup() Do we really want that? POSIX' dup does something different from what many will expect. In particular, the new file descriptors share the offset, which can result in some really confusing situations. In IO::POSIX? Yes; you're asking for POSIX semantics, if that isn't what you want, IO::POSIX is not where you should be. If there's something more general out there, it can be dup() in some other namespace than IO::POSIX. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
r25182 - docs/Perl6/Spec
Author: ruoso Date: 2009-02-04 16:37:16 +0100 (Wed, 04 Feb 2009) New Revision: 25182 Modified: docs/Perl6/Spec/S16-io.pod Log: [spec/S16] proposed role-based api Modified: docs/Perl6/Spec/S16-io.pod === --- docs/Perl6/Spec/S16-io.pod 2009-02-04 15:21:11 UTC (rev 25181) +++ docs/Perl6/Spec/S16-io.pod 2009-02-04 15:37:16 UTC (rev 25182) @@ -15,16 +15,108 @@ Version: 18 This is a draft document. Many of these functions will work as in Perl -5, except we're trying to rationalize everything into packages. For +5, except we're trying to rationalize everything into roles. For now you can assume most of the important functions will automatically be in the * namespace. However, with IO operations in particular, many of them are really methods on an IO handle, and if there is a corresponding global function, it's merely an exported version of the method. -As a starting point, you can help by finding the official Perl 5 documentation -for these functions and copying it here. +=head1 Roles +The functionality of IO objects is broken down into several roles, +which should identify the features each object supports. + +=head2 IO + +The base role only tags that this is an IO object for more generic +purposes. It doesn't specify any methods or attributes. + +=head2 IO::Readable + +This role provides unbuffered read access to the data stream. + +=over + +=item method Int read($buf is rw, int $length) + +Tries to read $lenght bytes and store in $buf. The contents of $buf +are replaced and the actual number of bytes read is returned. A return +of 0 means end of file. It might return unthrown failures, to be +specified by each IO implementation. + +=back + +=head2 IO::Writeable + +This role provides unbuffered write access to the data stream. + +=over + +=item method Int write($buf, int $length) + +Tries to write $length bytes of $buf. The actual number of bytes +written is returned. It might return unthrown failures, to be +specified by each IO implementation. + +=back + +=head2 IO::FileDescriptor + +This role indicates that this object actually represents an open file +descriptor in the os level. + +=over + +=item has int $.fileno + +File descriptors are always native integers, conforming to C89. + +=back + +=head2 IO::Closeable + +This role indicates that this object can be closed. + +=over + +=item method Bool close() + +returns True on success, but might return an unthrown failure. + +=back + +=head2 IO::Buffered + +Indicates that this object performs buffering. The management of the +buffer is completely implementation specific. + +=item method Bool flush() + +Flushes the buffers associated with this object. + +=item has Bool $.autoflush is rw + +Forces this object to keep its buffers empty + +=head2 IO::POSIX + +Indicates that this object can perform standard posix IO operations. + +=over + +=item method IO dup() + +=item has Bool $.blocking is rw + +=item method Bool flock(:$r,:$w) + +=item method Bool funlock() + +=item ... + +=back + =head1 Filehandles, files, and directories =over 4
Re: r25182 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl writes: +=item method Int read($buf is rw, int $length) I'm not sure that using a native int is the right thing here. If whatever the implementation uses as int is narrower than size_t, that forces the programmer to use an Int and do the necessary loop. On the other hand, accepting Int allows bignums. If a bignum $length is too big to be represented by a native int, but still small enough to use as a byte count for an I/O operation, then .read can do the loop internally, freeing the programmer from worrying about such things. (And if $length is too big for the memory space, or otherwise inappropriate for .read, we can throw an exception.) +Tries to read $lenght bytes and store in $buf. The contents of $buf Typo; should be $length, obviously. +=head2 IO::Writeable FWIW, I prefer the traditional spelling, writable. Google suggests that writeable is more common on the web, though; 4.8 versus 3.7 Mghits. +=head2 IO::POSIX + +Indicates that this object can perform standard posix IO operations. I don't like that wording, but getting it right seems tricky. The problem is that I don't think you mean for IO::POSIX to contain methods corresponding to POSIX-ish read(2), write(2), given that methods of those names exist in other roles. But those are precisely what I'd think of as most obviously falling into the category of standard POSIX I/O operations. +=item method Bool flock(:$r,:$w) I realise this part of the specification still seems to be at the stub stage, but I'll note that: * We'll also need a way of getting at the LOCK_NB behaviour * The normal terms for flock() are shared and exclusive locks, not read and write locks * It seems a little odd to put an flock method in an IO::POSIX role, given that POSIX specifies fcntl(F_SETLK) in place of traditional BSD-ish flock(). I'd be in favour of having .fcntl in IO::POSIX, but with an additional role providing .flock (IO::Flock, presumably). -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r25182 - docs/Perl6/Spec
Em Qua, 2009-02-04 às 16:45 +, Aaron Crane escreveu: pugs-comm...@feather.perl6.nl writes: +=item method Int read($buf is rw, int $length) I'm not sure that using a native int is the right thing here. If whatever the implementation uses as int is narrower than size_t, that forces the programmer to use an Int and do the necessary loop. native int can't be undefined, failures are undefined. The use of Int here is to support it returning unthrown exceptions. +=head2 IO::POSIX + +Indicates that this object can perform standard posix IO operations. I don't like that wording, but getting it right seems tricky. The problem is that I don't think you mean for IO::POSIX to contain methods corresponding to POSIX-ish read(2), write(2), given that methods of those names exist in other roles. But those are precisely what I'd think of as most obviously falling into the category of standard POSIX I/O operations. That actually surprised me, for some reason I did think read and write were standard C, not POSIX (that's what happens when you don't have experience in non-unix OSs). And maybe you're indeed right, since you can change the way you access a file in POSIX, it would be strange to de-compose a Writeable role if you change the way you access the io. but having separated roles for read and write would make it easier to implement application level io objects (not backed by operating system file descriptors). That probably means IO::POSIX does IO::Readable does IO::Writeable. +=item method Bool flock(:$r,:$w) I realise this part of the specification still seems to be at the stub stage, but I'll note that: Yes, it was meant purely as an example, a more carefull planning of that would be needed. daniel
Re: r25182 - docs/Perl6/Spec
Daniel Ruoso writes: Em Qua, 2009-02-04 às 16:45 +, Aaron Crane escreveu: pugs-comm...@feather.perl6.nl writes: +=item method Int read($buf is rw, int $length) I'm not sure that using a native int is the right thing here. If whatever the implementation uses as int is narrower than size_t, that forces the programmer to use an Int and do the necessary loop. native int can't be undefined, failures are undefined. The use of Int here is to support it returning unthrown exceptions. Sorry, it was the native-int $length parameter I was talking about -- I think it should be a boxed Int instead. POSIX-ish read(2), write(2) That actually surprised me, for some reason I did think read and write were standard C, not POSIX C stdio has fread(), fwrite() working on FILE*, with APIs similar (but not identical) to POSIX read(), write(). C stdio doesn't known anything about POSIX-ish file descriptors. That probably means IO::POSIX does IO::Readable does IO::Writeable. Yes, indeed. Sorry, I should have thought of that. -- Aaron Crane ** http://aaroncrane.co.uk/
Re: r25182 - docs/Perl6/Spec
On Wed, Feb 4, 2009 at 4:37 PM, pugs-comm...@feather.perl6.nl wrote: +=head2 IO + +The base role only tags that this is an IO object for more generic +purposes. It doesn't specify any methods or attributes. + Shouldn't IO::readable and IO::Writable do IO? + +=head2 IO::Closeable + I still think this should be in a more general namespace than IO. + +=item method IO dup() + Do we really want that? POSIX' dup does something different from what many will expect. In particular, the new file descriptors share the offset, which can result in some really confusing situations. Leon
Re: r25182 - docs/Perl6/Spec
Leon Timmermans writes: On Wed, Feb 4, 2009 at 4:37 PM, pugs-comm...@feather.perl6.nl wrote: +=item method IO dup() Do we really want that? If we label a thing as POSIX, it should certainly make all the POSIX functionality available, IMHO. I'd consider arguments that we should pick different names for specific functions where the POSIX names are particularly awkward, but I think a good default would be to match the names as well. Or else avoid the label POSIX. POSIX' dup does something different from what many will expect. In particular, the new file descriptors share the offset, which can result in some really confusing situations. To my knowledge, there's no alternative -- that is, there's no POSIX functionality which allows the creation of a file descriptor open on the same underlying object as an existing fd, but with its own file offset. Assuming I'm right, that doesn't mean users shouldn't get access to POSIX dup() for when it *is* what they want. I agree that also providing a less surprising method would be a good thing, assuming it can be widely implemented. But it needn't live in IO::POSIX. -- Aaron Crane ** http://aaroncrane.co.uk/
