Re: [Pharo-project] FileSystem question
Hi colin You confirmed what I like :) But my question was more about moving entry API to FSReference API. |working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. -- 2010-02-14T10:34:31+00:00 cache entry modification. -- 2010-02-14T10:34:31+00:00 cache entry size give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code. cache creation. -- 2010-02-14T10:34:31+00:00 cache modification. -- 2010-02-14T10:34:31+00:00 cache size On Feb 16, 2010, at 8:23 AM, Colin Putney wrote: stephane ducasse stephane.duca...@free.fr wrote: I like the way FSFilePluginPrims encapsulate the primitive calls. Lukas Renggli replied: I think this is a separate object because some filesystems might not provide this information or might provide a different set of information. An external filesystem (FTP, HTTP) might not know the size, creation or modification timestamp. Zip archives might provide different information. I guess that's the reason why this is a separate object. Sort of. That's the rationale for handles. FSDiskHandle isolates the stream from the primitives, so it's possible to have the primitives in the handle and still have the stream work with different types of filesystems. I moved the primitives to a separate object for a several reasons: One was to make them private. The stream should not be able to call primitives directly, and putting them in a separate object that the stream doesn't have access to makes that clear. (It's not full capability security because the stream can violate encapsulation via #instVarAt: or other trickery, but the need to do that is a sign that you shouldn't). Second, the primitives provided by FilePlugin aren't ideal, and eventually I want to have some primitives designed specifically for Filesystem. It wouldn't be a drop-in replacement for FilePlugin, but if the FilePlugin primitives are all in one place, it should be fairly simple to port to another primitive object with a slightly different protocol. Finally, I like the way it looks: Primitives close: id is nicer than self primClose: id. at least to my eye. :-) Colin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
On 2010-02-15, at 9:36 AM, stephane ducasse wrote: |working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. -- 2010-02-14T10:34:31+00:00 cache entry modification. -- 2010-02-14T10:34:31+00:00 cache entry size give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code. cache creation. -- 2010-02-14T10:34:31+00:00 cache modification. -- 2010-02-14T10:34:31+00:00 cache size Yes, references could provide direct access to the information in the entry. But I made it a separate object for a couple of reasons. The main one is performance. If you need to fetch several pieces of information it's more efficient to make one trip to the disk and keep all the information in one object. I ran into this problem while implementing the directory tree visitor code - it was slow, slow, slow until I implemented FSDirectoryEntry. Colin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
[Pharo-project] FileSystem question
|working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. -- 2010-02-14T10:34:31+00:00 cache entry modification. -- 2010-02-14T10:34:31+00:00 cache entry size give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code. cache creation. -- 2010-02-14T10:34:31+00:00 cache modification. -- 2010-02-14T10:34:31+00:00 cache size I like the way FSFilePluginPrims encapsulate the primitive calls. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
I think this is a separate object because some filesystems might not provide this information or might provide a different set of information. An external filesystem (FTP, HTTP) might not know the size, creation or modification timestamp. Zip archives might provide different information. I guess that's the reason why this is a separate object. Lukas On 15 February 2010 18:36, stephane ducasse stephane.duca...@free.fr wrote: |working cache| working := FSDiskFilesystem current working. cache := working / 'package-cache'. cache entry cache entry creation. -- 2010-02-14T10:34:31+00:00 cache entry modification. -- 2010-02-14T10:34:31+00:00 cache entry size give me access to the file descriptor now I was wondering why we could not have the API of description at the level of FSreference to avoid that navigation code. cache creation. -- 2010-02-14T10:34:31+00:00 cache modification. -- 2010-02-14T10:34:31+00:00 cache size I like the way FSFilePluginPrims encapsulate the primitive calls. Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
stephane ducasse stephane.duca...@free.fr wrote: I like the way FSFilePluginPrims encapsulate the primitive calls. Lukas Renggli replied: I think this is a separate object because some filesystems might not provide this information or might provide a different set of information. An external filesystem (FTP, HTTP) might not know the size, creation or modification timestamp. Zip archives might provide different information. I guess that's the reason why this is a separate object. Sort of. That's the rationale for handles. FSDiskHandle isolates the stream from the primitives, so it's possible to have the primitives in the handle and still have the stream work with different types of filesystems. I moved the primitives to a separate object for a several reasons: One was to make them private. The stream should not be able to call primitives directly, and putting them in a separate object that the stream doesn't have access to makes that clear. (It's not full capability security because the stream can violate encapsulation via #instVarAt: or other trickery, but the need to do that is a sign that you shouldn't). Second, the primitives provided by FilePlugin aren't ideal, and eventually I want to have some primitives designed specifically for Filesystem. It wouldn't be a drop-in replacement for FilePlugin, but if the FilePlugin primitives are all in one place, it should be fairly simple to port to another primitive object with a slightly different protocol. Finally, I like the way it looks: Primitives close: id is nicer than self primClose: id. at least to my eye. :-) Colin ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
Are there some examples (not tests)? Mason and Monticello 2 use it, as far as I know. What is the difference between FSReference and FSPath? Did you read the class comments? FSPath: I an abstract filesystem path, independent of the string representation used to describe paths on a specific filesystem. I provide methods for navigating the filesystem hierarchy and working with absolute and relative paths. I only refer to a concrete file or directory with regard to a specific filesystem. FSReference: I combine a filesystem and path, which is sufficient to refer to a concrete file or directory. I provide methods for navigating my filesystem, performing filesystem operations and opening and closing files. I am the primary mechanism for working with files and directories. So most likely you are only interested in FSReference. FSPath is only used for relative paths independent of the filesystem, or path that cross or are independent of filesystem boundaries. For example how can I print in the Transcript all the files in my current dir? FSDiskFilesystem current working children Lukas -- Lukas Renggli http://www.lukas-renggli.ch ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
Of course I read them :)
this is the first thing I do.
Are there some examples (not tests)?
Mason and Monticello 2 use it, as far as I know.
sure
Now I mean little examples in the sense of a little tutorial (see below the rio
one).
I will probably start to write something like that for me.
What is the difference between FSReference and FSPath?
Did you read the class comments?
FSPath: I an abstract filesystem path, independent of the string
representation used to describe paths on a specific filesystem. I
provide methods for navigating the filesystem hierarchy and working
with absolute and relative paths. I only refer to a concrete file or
directory with regard to a specific filesystem.
FSReference: I combine a filesystem and path, which is sufficient to
refer to a concrete file or directory. I provide methods for
navigating my filesystem, performing filesystem operations and opening
and closing files. I am the primary mechanism for working with files
and directories.
So most likely you are only interested in FSReference. FSPath is only
used for relative paths independent of the filesystem, or path that
cross or are independent of filesystem boundaries.
Ok so FSPath is a kind of internal representation of /usr/bin/
For example how can I print in the Transcript all the files in my current
dir?
FSDiskFilesystem current working children
Instantiating and Building Paths
The most concise method for creating a Rio is via: 1.below, the following are
equivalent:
• 'myFile.txt' asRio
• Cwd / 'myFile.txt'
• Rio / 'myFile.txt'
• Rio new:'myFile.txt' - the verbose form
Rio's may be constucted using the #/ and #, operators like so.
Cwd / 'package-cache' / 'Rio-Core' , '-kph.20' , '.mcz'.
Deconstructing the Rio Path and File Name
Given myFile := Cwd / 'myFile.3.txt'.
• myFile full = '/media/hda1/squeak/myFile.3.txt'
• myFile fileName = 'myFile.3.txt'
• myFile parent = '/media/hda1/squeak'
• myFile base = 'myFile'
• myFile version = 3
• myFile ext = 'txt'
• myFile path = ''.
• myFile full split = #('/' 'media' 'hda1' 'squeak' 'myFile.3.txt')
Adjusting the Rio Path and File Name
Given myFile := Cwd / 'myFile.3.txt'.
(#parent: and #full: will set the path relative to the default directory).
• myFile fileName: 'another.txt' = (Rio new:'another.txt').
• myFile base: 'temp' = (Rio new: 'temp.3.txt').
• myFile version: 4 = (Rio new: 'myFile.4.txt').
• myFile ext: 'html' = (Rio new: 'myFile.3.html').
• myFile parent: 'temp' = (Rio new: 'temp/myFile.3.txt')
• myFile full: '/media/hda1/squeak/temp/myFile.3.txt' = (Rio new:
'temp/myFile.3.txt')
File Versions Helpers
If there exists a file, Cwd / 'temp.4.txt'. Then there are some utilities for
obtaining the latest and next version file rio's.
• 'temp.txt' asRio latestVersion = (Rio new: 'temp.4.txt').
• 'temp.txt' asRio nextVersion = (Rio new: 'temp.5.txt').
A Word About Style
Rio may be used in two distinct styles. In addition to the traditional
smalltalk cascading messages style, Rio supports a sentence like 'sequential'
style. Whenever an example below uses the 'sequential' style for conciseness,
suffice to say there is a traditional equivalent.
sequential:
'myFile.zip' asRio zip addAll: '/tmp/files' asRio all files
cascading:
(Rio new: 'myFile)
setModeToZip;
addAll: ((Rio new:'/tmp/files')
setModeToRecursive;
yourself) files;
yourself.
Introducing Modes - 'Renaming' Mode
When a Rio is #setModeToRenaming, all of the above fileName and path
manipulations are simultaneously actualized on disk. Below is an example using
Rio's 'sequential' style for configuring modes:
• myFile rename base: 'temp'. = is equivalent to = 'myFile.3.txt'
asRio renameTo: 'temp.3.txt'.
When a mode is set using 'cascading' style, (e.g. #setModeToRenaming) the mode
flag is set on the given instance as you would expect. In contrast, when a mode
is set in sequential style, a new instance is created, making the mode setting
temporary for the remainer of that 'sequential sentence'. This convention
applies to all modes. e.g.
• cascading: (myFile setModeToRenaming; yourself) base:'temp'. – the
renamng mode flag of myFile is set.
• sequential: myFile rename base: 'temp'. – myFile itself is untouched,
the renaming mode flag is set in the myFile copy that performs #base:
File Stat
All of the typical stat information about files and directories is directly
obtainable from a Rio.
• myFile fileSize
• myFile modificationTime returns a DateAndTime
• myFile creationTime returns a DateAndTime
• myFile isFile
• myFile exists
• myFile isDirectory
Directory Queries #select:ing
Internally the operating
[Pharo-project] FileSystem question
I'm trying to move some of the examples of Coral from rio to filesystem and I get some questions. Are there some examples (not tests)? What is the difference between FSReference and FSPath? For example how can I print in the Transcript all the files in my current dir? Stef ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Re: [Pharo-project] FileSystem question
Den 12.02.2010 16:18, skrev Stéphane Ducasse: I'm trying to move some of the examples of Coral from rio to filesystem and I get some questions. Are there some examples (not tests)? What is the difference between FSReference and FSPath? For example how can I print in the Transcript all the files in my current dir? Stef _ There's probably an easier way, but: (FSDiskFilesystem current childrenAt: FSDiskFilesystem current workingDirectory) do: [:each | each printOn: Transcript cr ]. Transcript flush. Speaking of current dir... FSDiskFilesystem current workingDirectory isWorkingDirectory - false, at least on Windows :) Cheers, Henry ___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
