Партнёры:
Хостинг:
IO-stringy - I/O on in-core objects like strings and arrays
IO::
::AtomicFile adpO Write a file which is updated atomically ERYQ
::Lines bdpO I/O handle to read/write to array of lines ERYQ
::Scalar RdpO I/O handle to read/write to a string ERYQ
::ScalarArray RdpO I/O handle to read/write to array of scalars ERYQ
::Wrap RdpO Wrap old-style FHs in standard OO interface ERYQ
::WrapTie adpO Tie your handles & retain full OO interface ERYQ
In the more-traditional IO::Handle front, we have IO::AtomicFile which may be used to painlessly create files which are updated atomically.
And in the ``this-may-prove-useful'' corner, we have IO::Wrap, whose exported wraphandle() function will clothe anything that's not a blessed object in an IO::Handle-like wrapper... so you can just use OO syntax and stop worrying about whether your function's caller handed you a string, a globref, or a FileHandle.
seek() on unopened file
...then you are probably trying to use one of these functions on one of our IO:: classes with an old Perl. The remedy is to simply use the OO version; e.g.:
$SH->seek(0,0); ### GOOD: will work on any 5.005
seek($SH,0,0); ### WARNING: will only work on 5.005_57 and beyond
perl Makefile.PL
make
make test
make install
For everyone else out there... if you've never installed Perl code before, or you're trying to use this in an environment where your sysadmin or ISP won't let you do interesting things, relax: since this module contains no binary extensions, you can cheat. That means copying the directory tree under my ``./lib'' directory into someplace where your script can ``see'' it. For example, under Linux:
cp -r IO-stringy-1.234/lib/* /path/to/my/perl/
Now, in your Perl code, do this:
use lib "/path/to/my/perl";
use IO::Scalar; ### or whatever
Ok, now you've been told. At this point, anyone who whines about not being given enough information gets an unflattering haiku written about them in the next change log. I'll do it. Don't think I won't.
Will the sudden sensitivity to $/ hose anyone out there? I'm worried, so you have to enable it explicitly in 1.x. It will be on by default in 2.x, though only IO::Scalar has been implemented.
Isn't it the case that real operating system file descriptors
maintain an independent read and write file position (and
seek(2) resets them both)?
(My answer: perhaps, but stdio's fseek/ftell manpages seem to imply a single file position indicator, and I'm trying to be IO::-ish.) Binkley also pointed out some issues with his implementation:
For example, what does eof or tell return? The read position or
the write position? (I assumed read position was more important).
Your opinions on this are most welcome. (Me, I'm just squeamish that this will break some code which depends on the existing behavior, and that attempts to maintain backwards-compatibility will slow down the code.)
Added support for consulting $/ in IO::Scalar and IO::ScalarArray. The old "use_RS()" is not even an option. Unsupported record separators will cause a croak().
Added a lot of regression tests to supoprt the above.
Better on-line docs (hyperlinks to individual functions).
I thought more about giving IO::Scalar two separate handles, one for reading and one for writing, as suggested by Binkley. His points about what tell() and eof() return are, I think, show-stoppers for this feature. Even the manpages for stdio's fseek() seem to imply a single file position indicator, not two. So I think I will take this off the TO DO list. Remedy: you can always have two handles open on the same scalar, one which you only write to, and one which you only read from. That should give the same effect.
First off, many many thanks to Doug Wilson, who has provided an invaluable service by patching IO::Scalar and friends so that they (1) inherit from IO::Handle, (2) automatically tie themselves so that the "new()" objects can be used in native i/o constructs, and (3) doing it so that the whole damn thing passes its regression tests. As Doug knows, my globref Kung-Fu was not up to the task; he graciously provided the patches. This has earned him a seat at the Co-Authors table, and the right to have me address him as sensei.
Performance of IO::Scalar::print() has been improved by as much as 2x for lots of little prints, with the cost of forcing those who print-then-seek-then-print to explicitly seek to end-of-string before printing again. Thanks to Juergen Zeller for this patch.
Added the COPYING file, which had been missing from prior versions. Thanks to Albert Chin-A-Young for pointing this out.
IO::Scalar consults $/ by default (1.x ignored it by default). Yes, I still need to support IO::ScalarArray.
Enough info there?
Here's unflattering haiku:
Forgot the line, "make"! ;-)
Removed not-fully-blank lines from modules; these were causing lots of POD-related warnings. Thanks to Nicolas Joly for the suggestion.
New ``TO DO'' section, because people who submit patches/ideas should at least know that they're in the system... and that I won't lose their stuff. Please read it.
New entries in ``AUTHOR''. Please read those too.
Nasty bug fixed in IO::Scalar::write(). Apparently, the offset and the number-of-bytes arguments were, for all practical purposes, reversed. You were okay if you did all your writing with print(), but boy was this a stupid bug! Thanks to Richard Jones for finding this one. For you, Rich, a double-length haiku:
Newspaper headline
typeset by dyslexic man
loses urgency
BABY EATS FISH is
simply not equivalent
to FISH EATS BABY
New sysread and syswrite methods for IO::Scalar. Thanks again to Richard Jones for this.
Richard Jones
B. K. Oxley (binkley)
Doru Petrescu
Doug Wilson (for picking up the ball I dropped, and doing tie() right)
Go to http://www.zeegee.com for the latest downloads and on-line documentation for this module.
Enjoy. Yell if it breaks.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |