why FileDirectory sucks
Locked
12
12
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
> 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
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: [hidden email] [mailto:[hidden email]] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
Yikes!!!! :) Anybody else for #parent or #up as a helper?
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli Sent: Wednesday, July 01, 2009 12:08 PM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
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: [hidden email] [mailto:[hidden email]] On Behalf Of Lukas Renggli Sent: Wednesday, July 01, 2009 12:11 PM To: [hidden email] 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On Wed, Jul 1, 2009 at 9:42 AM, Stéphane Ducasse <[hidden email]> wrote:
Hi guys 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: why FileDirectory sucks
|
|
On Jul 1, 2009, at 1:28 PM, Stephen Pair wrote:
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stephen Pair
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 <[hidden email] > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Wed, Jul 1, 2009 at 2:18 PM, John M McIntosh <[hidden email]> wrote: So I'd suggest one thinks about reusing the URI logic 2009/7/1 Cameron Sanders <[hidden email]>
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stephen Pair
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2009/7/1 Michael Rueger <[hidden email]>:
> 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 :-) > '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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Lukas Renggli
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
:)
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: [hidden email] [mailto:[hidden email] > ] On Behalf Of Lukas Renggli > Sent: Wednesday, July 01, 2009 12:08 PM > To: [hidden email] > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stephen Pair
On Jul 1, 2009, at 7:28 PM, Stephen Pair wrote: > On Wed, Jul 1, 2009 at 9:42 AM, Stéphane Ducasse <[hidden email] > > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by johnmci
> 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 <[hidden email] >>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Michael Rueger-6
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Michael Rueger-6
On Wed, Jul 1, 2009 at 5:32 PM, Michael Rueger <[hidden email]> wrote:
I think I would obliterate FileDirectory and write something more like "FileSystem default defaultDirectory", which would answer a URI.
- Stephen
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |