[Pharo-project] why FileDirectory sucks
Hi guys we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks. I have a file FileDirectory default and now I want to get two levels up. Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic. Smalltalk deserves a better library for file. What a crap this stuff. Stef
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
FileDirectory default containingDirectory containingDirectory Yes, it took me a long time to find out the first time. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
Yikes!!!! :) Anybody else for #parent or #up as a helper? -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Wednesday, July 01, 2009 12:08 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why FileDirectory sucks
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
FileDirectory default containingDirectory containingDirectory Yes, it took me a long time to find out the first time. 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
:) Yes! On Jul 1, 2009, at 7:18 PM, Schwab,Wilhelm K wrote:
Yikes!!!! :) Anybody else for #parent or #up as a helper?
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr ] On Behalf Of Lukas Renggli Sent: Wednesday, July 01, 2009 12:08 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why FileDirectory sucks
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
FileDirectory default containingDirectory containingDirectory
Yes, it took me a long time to find out the first time.
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
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Smalltalk deserves a better library for file. What a crap this stuff.
The problem is that a good platform independent library is not a trivial thing. Also from the architectural point of view this is a rather difficult problem. The biggest problem is though that the primitives where everything is built upon are arcane too. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
One thing that seems to be missing is a good abstraction of relative paths, and some type of #, message to allow relative ones to be tacked onto full ones (FileDirectory etc.)?? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Wednesday, July 01, 2009 12:11 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] why FileDirectory sucks
Smalltalk deserves a better library for file. What a crap this stuff.
The problem is that a good platform independent library is not a trivial thing. Also from the architectural point of view this is a rather difficult problem. The biggest problem is though that the primitives where everything is built upon are arcane too. 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
Schwab,Wilhelm K wrote:
One thing that seems to be missing is a good abstraction of relative paths, and some type of #, message to allow relative ones to be tacked onto full ones (FileDirectory etc.)??
In Sophie and to an even larger extent in an experimental fork I based everything on URIs using resolveRelativePath: where needed. The resolving rules for URIs are well spec'ed and deal with both relative and absolute paths. Platform specific path strings are created only when needed. Michael
On Jul 1, 2009, at 7:10 PM, Lukas Renggli wrote:
Smalltalk deserves a better library for file. What a crap this stuff.
The problem is that a good platform independent library is not a trivial thing. Also from the architectural point of view this is a rather difficult problem. The biggest problem is though that the primitives where everything is built upon are arcane too.
Yes. I know. Thanks for the containerDirectory. I ended up cutting string .... grgr
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
Stef, One approach might be to use the #fullName and #pathNameDelimiter to create a collection of parent directories. Also see #pathParts, but that is probably not quite what you want, because it focuses on the names, but #do:separatedBy: could help correct that. So far, I have created some simple helper methods that will allow myriad senders in my Dolphin code to (hopefully) continue to work under Pharo. However, Dolphin has a Windows-only bias and Pharo needs to work with various conventions, so the "correct" abstraction for directory naming will have to be different from Dolphin's. Should there be a #, for concatenation? #parent to move up, with obvious caveat of throwing an exception? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, July 01, 2009 8:43 AM To: Pharo Development Subject: [Pharo-project] why FileDirectory sucks Hi guys we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks. I have a file FileDirectory default and now I want to get two levels up. Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic. Smalltalk deserves a better library for file. What a crap this stuff. Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jul 1, 2009 at 9:42 AM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Hi guys
we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks.
I have a file
FileDirectory default
and now I want to get two levels up.
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
Smalltalk deserves a better library for file. What a crap this stuff.
Stef
LoL...how many years did it take you to come to this conclusion? Anyway, if anyone does take up the job of rewriting the file system interface, I have a suggestion based on some recent stuff we've done here at work. We wanted a way of running test cases for code that uses the file system, but we didn't want to actually use the file system (for speed...when you run many thousands of test cases, hitting the disk can really slow things down). We wanted to substitute an in memory simulation of a file system. We had to go to great lengths to accomplish this (in VisualWorks). It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives). - Stephen
On Jul 1, 2009, at 1:28 PM, Stephen Pair wrote:
On Wed, Jul 1, 2009 at 9:42 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi guys
we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks.
I have a file
FileDirectory default
and now I want to get two levels up.
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
Smalltalk deserves a better library for file. What a crap this stuff.
Stef
LoL...how many years did it take you to come to this conclusion? Anyway, if anyone does take up the job of rewriting the file system interface, I have a suggestion based on some recent stuff we've done here at work. We wanted a way of running test cases for code that uses the file system, but we didn't want to actually use the file system (for speed...when you run many thousands of test cases, hitting the disk can really slow things down). We wanted to substitute an in memory simulation of a file system. We had to go to great lengths to accomplish this (in VisualWorks). It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives).
- Stephen
A related notion, but a tangent (and then returning to the above thread)... One thing I did in Java (in 2001) and Python (later) --and have been considering doing in my current smalltalk code base-- was to create "Accessors" to access relational DB's, directory based files, and memory-based 2d-tables in a generic fashion. An Accessor, as I defined it, looked a lot like a combo of a DB connection and results set. The file-based Accessors were opened on a directory as the DB, where the files were tables (and those could be read or written in several formats: CSV, tab-delimited, etc.), and subdirectories were treated like tables of Blobs; another variant allowed an accessor to be opened on a directory as if it were bound to a specific table, and so the directory looked like a table of Blobs. Obviously, any level of complexity, and "auto" handling of file types is possible. (And I am not describing what I did well, there was symmetry and a recursive nature... and I'm too lazy to look and detail it right now; instead my goal is just to kick some ideas out.) Obviously the Accessors allowed me to ignore the data source. I keep puzzling that I have not encountered this type of thing elsewhere. And back to the main topic here... aren't URL's fairly well generalized? Are they not the right way to fully generalize locations? -cam
Well actually in Sophie we used URI http://en.wikipedia.org/wiki/URI *hint* all that code is MIT By using relative URI then asking for the read or readwrite stream later we could build URI constructs that referred to disk, to a server in the cloud, to memory. Oh and let's not forget the Squeak file primitive logic is *so* crippled that asking if a file exists either means opening the file, or iterating over N files in your directory to confirm it exists. Again for Sophie we added a FFI call to see if the operating system would tell us if the file existed. So I'd suggest one thinks about reusing the URI logic PS we also went to great pains to ensure the URI got encoded correctly so unicode aware file systems actually would end up with the proper characters. On 1-Jul-09, at 10:28 AM, Stephen Pair wrote:
On Wed, Jul 1, 2009 at 9:42 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi guys
we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks.
I have a file
FileDirectory default
and now I want to get two levels up.
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
Smalltalk deserves a better library for file. What a crap this stuff.
Stef
LoL...how many years did it take you to come to this conclusion? Anyway, if anyone does take up the job of rewriting the file system interface, I have a suggestion based on some recent stuff we've done here at work. We wanted a way of running test cases for code that uses the file system, but we didn't want to actually use the file system (for speed...when you run many thousands of test cases, hitting the disk can really slow things down). We wanted to substitute an in memory simulation of a file system. We had to go to great lengths to accomplish this (in VisualWorks). It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives).
- Stephen _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
On Wed, Jul 1, 2009 at 2:18 PM, John M McIntosh < johnmci@smalltalkconsulting.com> wrote:
So I'd suggest one thinks about reusing the URI logic
2009/7/1 Cameron Sanders <camsanders01@roadrunner.com>
And back to the main topic here... aren't URL's fairly well generalized? Are they not the right way to fully generalize locations?
Yes, I think they are, our code just has a lot of legacy use of Filename (in VW). But I think there are still some pitfalls with URIs...one that I can think if is having a good means of efficiently reusing connections as you interact with a URI and still keep your client code blissfully unaware of where the actual data associated with the URI is coming from. That can get tricky especially as you consider that some connections aren't stateless (like FTP connections). - Stephen
Well actually in Sophie we used URI http://en.wikipedia.org/wiki/URI *hint* all that code is MIT
I know I just did not find time.... Good I do not know why a moment I thought that the sophie license was different.
By using relative URI then asking for the read or readwrite stream later we could build URI constructs that referred to disk, to a server in the cloud, to memory.
Oh and let's not forget the Squeak file primitive logic is *so* crippled that asking if a file exists either means opening the file, or iterating over N files in your directory to confirm it exists. Again for Sophie we added a FFI call to see if the operating system would tell us if the file existed.
So I'd suggest one thinks about reusing the URI logic
PS we also went to great pains to ensure the URI got encoded correctly so unicode aware file systems actually would end up with the proper characters.
this is on my radar but it is full.
On 1-Jul-09, at 10:28 AM, Stephen Pair wrote:
On Wed, Jul 1, 2009 at 9:42 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi guys
we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks.
I have a file
FileDirectory default
and now I want to get two levels up.
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
Smalltalk deserves a better library for file. What a crap this stuff.
Stef
LoL...how many years did it take you to come to this conclusion? Anyway, if anyone does take up the job of rewriting the file system interface, I have a suggestion based on some recent stuff we've done here at work. We wanted a way of running test cases for code that uses the file system, but we didn't want to actually use the file system (for speed...when you run many thousands of test cases, hitting the disk can really slow things down). We wanted to substitute an in memory simulation of a file system. We had to go to great lengths to accomplish this (in VisualWorks). It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives).
- Stephen _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Well actually in Sophie we used URI http://en.wikipedia.org/wiki/URI *hint* all that code is MIT
I know I just did not find time.... Good I do not know why a moment I thought that the sophie license was different.
It actually is. New BSD, which is basically MIT with the advertising clause. So if we add code from Sophie (other than fixes) we would need to list the new BSD license as well. Michael
On 1-Jul-09, at 4:02 PM, Michael Rueger wrote:
It actually is. New BSD, which is basically MIT with the advertising clause. So if we add code from Sophie (other than fixes) we would need to list the new BSD license as well.
Michael
I must turn the A/C up another notch before talking about licensing issues without rechecking... Grab some ice water, goodness knows we don't need another license thread... -- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Stephen Pair wrote:
accomplish this (in VisualWorks). It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives).
broken record... ;-) ...use URIs :-) Then send things like stream, writeStream etc to the URI and have the scheme dispatch resolve the rest. Michael
2009/7/1 Michael Rueger <m.rueger@acm.org>:
Stephen Pair wrote:
accomplish this (in VisualWorks). Â It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives).
broken record... ;-)
...use URIs :-)
how then i could write a 'FileDirectory default' in terms of URIs? 'file://.' asURI ?
Then send things like stream, writeStream etc to the URI and have the scheme dispatch resolve the rest.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
how then i could write a 'FileDirectory default' in terms of URIs? 'file://.' asURI ?
No, you would still write FileDirectory default :-) But then you would do something like (FileDirectory default uri resolveRelativePath: 'myDir/images') directory I know, doesn't look to elegant, but it's of context you rarely really work with directories, but rather paths. Also take into account the FileLocations package which gives you calls for userDataURI, tempURI etc, allowing to transparently integrate with you platform specific paths. Michael
Ok I also like some parts of the rio api. Arg too much to do. Stef On Jul 1, 2009, at 11:32 PM, Michael Rueger wrote:
Igor Stasenko wrote:
how then i could write a 'FileDirectory default' in terms of URIs? 'file://.' asURI ?
No, you would still write FileDirectory default :-)
But then you would do something like
(FileDirectory default uri resolveRelativePath: 'myDir/images') directory
I know, doesn't look to elegant, but it's of context you rarely really work with directories, but rather paths.
Also take into account the FileLocations package which gives you calls for userDataURI, tempURI etc, allowing to transparently integrate with you platform specific paths.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Wed, Jul 1, 2009 at 5:32 PM, Michael Rueger <m.rueger@acm.org> wrote:
Igor Stasenko wrote:
how then i could write a 'FileDirectory default' in terms of URIs? 'file://.' asURI ?
No, you would still write FileDirectory default :-)
But then you would do something like
(FileDirectory default uri resolveRelativePath: 'myDir/images') directory
I think I would obliterate FileDirectory and write something more like "FileSystem default defaultDirectory", which would answer a URI. - Stephen
I think there is a whole day of reading on the squeak list now about backwards forward compatibility if you change the meaning of FileSystem default defaultDirectory and have it return a URI, that would break things, or assumptions etc. Personally I'd think it should be URI defaultFileSystemDirectory and others, temp, document, vm, etc.. Er so FileSystem default defaultDirectory would really do ^URI defaultFileSystemDirectory absolutePath On 1-Jul-09, at 4:01 PM, Stephen Pair wrote:
On Wed, Jul 1, 2009 at 5:32 PM, Michael Rueger <m.rueger@acm.org> wrote: Igor Stasenko wrote:
how then i could write a 'FileDirectory default' in terms of URIs? 'file://.' asURI ?
No, you would still write FileDirectory default :-)
But then you would do something like
(FileDirectory default uri resolveRelativePath: 'myDir/images') directory
I think I would obliterate FileDirectory and write something more like "FileSystem default defaultDirectory", which would answer a URI.
- Stephen
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Ok I also like some parts of the rio api. Arg too much to do. Stef On Jul 1, 2009, at 11:32 PM, Michael Rueger wrote:
Igor Stasenko wrote:
how then i could write a 'FileDirectory default' in terms of URIs? 'file://.' asURI ?
No, you would still write FileDirectory default :-)
But then you would do something like
(FileDirectory default uri resolveRelativePath: 'myDir/images') directory
I know, doesn't look to elegant, but it's of context you rarely really work with directories, but rather paths.
Also take into account the FileLocations package which gives you calls for userDataURI, tempURI etc, allowing to transparently integrate with you platform specific paths.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Pharoers, In my image I have a few methods that make file access a little more legible: Http // 'www.slashdot.org/' File // '/Users/dave/hello.c' It reads just like a protocol string :) Both of these class methods return a ByteString, what I typically need 99% of the time. When I need a stream for some strange reason: ReadStream on: (File // '/Users/dave/hello.c') . For my needs, this approach has made file access both straight forward while remaining true to the URI semantics. Dave -- -=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
2009/7/1 Igor Stasenko <siguctua@gmail.com>:
2009/7/1 Michael Rueger <m.rueger@acm.org>:
Stephen Pair wrote:
accomplish this (in VisualWorks). Â It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives).
broken record... ;-)
...use URIs :-)
how then i could write a 'FileDirectory default' in terms of URIs? 'file://.' asURI ?
Path @ 'file://' Path @ 'file://c:\file.txt' ( Path @ 'file://c:\file.txt' ) readStream contents. ( Path @ 'file://c:\file.txt' ) writeStream. ( Path @ 'http://www.dreamtheater.net/' ) readStream contents. ( Path @ 'app://yourContainer1.yourContainer2.yourObject' ) readStream etc.
Then send things like stream, writeStream etc to the URI and have the scheme dispatch resolve the rest.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Jul 1, 2009, at 7:28 PM, Stephen Pair wrote:
On Wed, Jul 1, 2009 at 9:42 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote: Hi guys
we should really consider to have an alternate (may be building on / rewriting part of RIO) but FileDirectory sucks.
I have a file
FileDirectory default
and now I want to get two levels up.
Well after 20 min looking around I could not find a way. I'm probably too stupid for squeak arcane logic.
Smalltalk deserves a better library for file. What a crap this stuff.
Stef
LoL...how many years did it take you to come to this conclusion?
No I knew it. I just got burned regularly.
Anyway, if anyone does take up the job of rewriting the file system interface, I have a suggestion based on some recent stuff we've done here at work. We wanted a way of running test cases for code that uses the file system, but we didn't want to actually use the file system (for speed...when you run many thousands of test cases, hitting the disk can really slow things down). We wanted to substitute an in memory simulation of a file system. We had to go to great lengths to accomplish this (in VisualWorks). It would be really cool if things like filenames and directories didn't make assumptions about the file system with which they are used (so that you could have filenames for in memory file systems, or filenames for other file systems that one might connect with in ways other than the built in local file system primitives).
nice idea.
- Stephen _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (10)
-
Cameron Sanders -
David Goehrig -
Hernán Morales Durand -
Igor Stasenko -
John M McIntosh -
Lukas Renggli -
Michael Rueger -
Schwab,Wilhelm K -
Stephen Pair -
Stéphane Ducasse