> From: Larry Wall <lwall@scalpel.netlabs.com>
>
> On a practical note, we've been putting off doing this until we switch
> to sfio, which when compared to stdio has Known Characteristics. But
> nobody's sent in a patch for that yet either...
>
> Larry
> From: William Setzer <setzer@guest3.math.ncsu.edu>
>
> So what is currently the status with the sfio stuff? I remember that
> "we" (those that were interested in doing an sfio port) decided to
> hold off for some reason that I don't remember, and someone else was
> working on an sfio module to test things in a less, er, permanent
> fashion. :-) Anyone want to refresh everyone else's memory? Is it
> time to again consider an sfio-based perl?
>
> William
> From: Kenneth Albanowski <kjahds@kjahds.com>
>
> Efficiency and/or portabilty was the issue. I'm sure. Perhaps if someone
> could dig up the most recent README for sfio, some people might get nudged
> into action.
>
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
The basic strategy was to develop an SFIO extension to a) play with
sfio concepts, and b) isolate and deal with portability issues.
Paul Marquess and I spoke by email with Phong <kpv@research.att.com>
and I think Paul may have a snapshot of a new not-quite-released
version. (That was back in May.)
Paul was doing the extension work and had made good progress (memory
management/ownership was a bit of a problem I recall) but it never quite
got finished. I think Paul went into higher priority work.
Replacing stdio with sfio within perl would indeed be a wonderful thing.
On the down side SFIO will have to be used in binary compatibility mode
since extensions will be linking to libraries linked against stdio. On
the upside perl can be intimate with sfio and, as Larry says, sfio has
Known Characteristics. Tied file handles with pushable disciplines are
the icing on the cake :-)
I've CC'd this to Paul and Phong.
Tim.
>
> On a practical note, we've been putting off doing this until we switch
> to sfio, which when compared to stdio has Known Characteristics. But
> nobody's sent in a patch for that yet either...
>
> Larry
> From: William Setzer <setzer@guest3.math.ncsu.edu>
>
> So what is currently the status with the sfio stuff? I remember that
> "we" (those that were interested in doing an sfio port) decided to
> hold off for some reason that I don't remember, and someone else was
> working on an sfio module to test things in a less, er, permanent
> fashion. :-) Anyone want to refresh everyone else's memory? Is it
> time to again consider an sfio-based perl?
>
> William
> From: Kenneth Albanowski <kjahds@kjahds.com>
>
> Efficiency and/or portabilty was the issue. I'm sure. Perhaps if someone
> could dig up the most recent README for sfio, some people might get nudged
> into action.
>
> Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
The basic strategy was to develop an SFIO extension to a) play with
sfio concepts, and b) isolate and deal with portability issues.
Paul Marquess and I spoke by email with Phong <kpv@research.att.com>
and I think Paul may have a snapshot of a new not-quite-released
version. (That was back in May.)
Paul was doing the extension work and had made good progress (memory
management/ownership was a bit of a problem I recall) but it never quite
got finished. I think Paul went into higher priority work.
Replacing stdio with sfio within perl would indeed be a wonderful thing.
On the down side SFIO will have to be used in binary compatibility mode
since extensions will be linking to libraries linked against stdio. On
the upside perl can be intimate with sfio and, as Larry says, sfio has
Known Characteristics. Tied file handles with pushable disciplines are
the icing on the cake :-)
I've CC'd this to Paul and Phong.
Tim.