This thread reminded me of something I'd posted a while ago:
---snip---
Date: Wed, 26 Nov 2008 14:23:11 +
From: Tim Bunce
To: Richard Hainsworth , perl6-language@perl.org
Subject: Re: Files, Directories, Resources, Operating Systems
On Wed, Nov 26, 2008 at 12:40:41PM +0100, Mark Overmeer w
On Wed, Jun 30, 2010 at 4:29 AM, Richard Hainsworth wrote:
It is normally implied that a program already has a 'local' environment,
> including a 'local' filesystem. Thus the syntax
> my $fn = open('/path/to/directory/filename', :r) or die $!;
> implies a local file sytem.
>
> The idea of an impli
On Wed, Jun 30, 2010 at 10:29 AM, Richard Hainsworth
wrote:
> Would it make sense to define $*FS as the implied local file system, and
> thus that a bare 'open' is sugar for
> my $fh = $*FS.open('/path/to/directory/filename', :r);
>
> This then means that there is an implicit
> $*FS.connect();
> t
Sounds like a sound generalization to make.
On Wed, Jun 30, 2010 at 1:29 AM, Richard Hainsworth
wrote:
> This then means that there is an implicit
> $*FS.connect();
> that makes the local system available to the program.
"mount" is the jargon to make a filesystem available, looking
backwards, t
If I might offer a late viewpoint after reading the Aaron's expanded
email (attached below).
When originally I suggested using 'open' instead of 'connect', the aim
was to keep consistency with the paradigm of files on the local system.
However, as Aaron's post suggests, when dealing with remo
First off, I again have to caution that this thread is conflating
"open" with filesystem interaction. While open is one of many ways of
interacting with a filesystem, it isn't even remotely sufficient (nor
my immediate focus). One can ask for and modify filesystem metadata,
security information, an
On Thu, 2010-06-10 at 21:17 -0400, Brandon S. Allbery KF8NH wrote:
> On Jun 10, 2010, at 07:22 , Leon Timmermans wrote:
> > I agree it should be similar to normal FS interactoin to make matters
> > as intuitive as possible, but I horrified by the idea of overloading
> > open() that way. That's a P
On 06/10/2010 05:07 AM, Mark J. Reed wrote:
On Thursday, June 10, 2010, Leon Timmermans wrote:
I agree it should be similar to normal FS interactoin to make matters
as intuitive as possible, but I horrified by the idea of overloading
open() that way
But open is already overloaded in p5, with
On Thu, Jun 10, 2010 at 2:07 PM, Mark J. Reed wrote:
> But open is already overloaded in p5, with pipes etc. We don't want
> to repeat the mistakes of the past, and the fact that open(FH, $foo)
> could run an arbitrary shell command was arguably a mistake, but
> transparent access to storage wher
On Jun 10, 2010, at 07:22 , Leon Timmermans wrote:
I agree it should be similar to normal FS interactoin to make matters
as intuitive as possible, but I horrified by the idea of overloading
open() that way. That's a PHP mistake I wouldn't like seeing repeated.
If you want open to do something tha
On Thursday, June 10, 2010, Leon Timmermans wrote:
> I agree it should be similar to normal FS interactoin to make matters
> as intuitive as possible, but I horrified by the idea of overloading
> open() that way
But open is already overloaded in p5, with pipes etc. We don't want
to repeat the mi
On Thu, Jun 10, 2010 at 9:15 AM, Richard Hainsworth
wrote:
> Ideally [at least, what I would like], managing a file on a remote resource
> should be the same as managing one locally, eg.
>
> my Amazon $fn = open("$path-to-input-file-location/$file-name", :r) or die
> $!;
> for $fn.readlines { };
>
Ideally [at least, what I would like], managing a file on a remote
resource should be the same as managing one locally, eg.
my Amazon $fn = open("$path-to-input-file-location/$file-name", :r) or
die $!;
for $fn.readlines { };
$fn.close;
my Google $fn = open("$path-to-output-file-location/$fil
On Wed, Jun 9, 2010 at 10:04 AM, Aaron Sherman wrote:
> Has anyone begun to consider what kind of filesystem interface we want
> for things like sftp, Amazon S3, Google Storage and other remote
> storage possibilities? Is there any extant work out there, or should I
> just start spit-balling?
In
On a lark, I submitted a request to Google for membership in the
Google Storage beta on the basis of doing something virtual
filesystemish for Perl 6. The bastards gave me an account, so now I
feel as if I should do something.
Has anyone begun to consider what kind of filesystem interface we want
15 matches
Mail list logo