I was just taking a look at the FileMan package (https://github.com/mumez/FileMan) since I've heard it mentioned as having some improved file name handling. It looks like it would need a little mangling for Squeak 6 and it seems to have a difference in how "this string' asDirectoryEntry works that might be a problem.
Current trunk Squeak will return nil if one tries to do 'nonexistentfilename' asDirectoryEntry but FileMan will create an FmDirectoryEntry; so any code that anticipates nil meaning "the file wasn't there" will have issues.
Is anyone using this? Updating it?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A titanic intellect... In a world full of icebergs.
On 2024-04-04, at 4:55 PM, Tim Rowledge tim@rowledge.org wrote:
Current trunk Squeak will return nil if one tries to do 'nonexistentfilename' asDirectoryEntry but FileMan will create an FmDirectoryEntry; so any code that anticipates nil meaning "the file wasn't there" will have issues.
For example, SmalltalkImage>>#patchSystem
As a contrast, there are several methods where returning nil will cause an error, just for fun. See e.g. GIFReadWriterTest>>#testColorsFileOutIn, CommandShell class>>#fileExists:inDirectory:, and then again SmalltalkImage>>#locateSourcesEntry: wouldn't crash but would behave potentially dangerously.
To nil, or not to nil, is that the question?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One too many lights out in his Christmas tree.
Aside from the issue of no-file-means-nil vs no-file-means-object there is an interestingly tricky thing in that FileMan more explicitly splits file entry objects and directory entry objects. Squeak uses DirectoryEntry and makes an instance of a suitable subclass (which is one of the things making no-file-means-object tricky you can't make the right thing if it isn't there to check) whereas FileMan exposes #asDirectoryEntry such that it makes an object that only works for directories, and a asFileEntry similar for files.
All of which is making it hard to think of nice clean ways to make trunk code that will keep working properly if FileMan is installed.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CWB: Carry With Borrow
If you have a copy of OSProcess and CommandShell loaded in your Squeak image, take a look at senders of #useFileMan. These methods are attempting to maintain compatibility across Cuis (FileMan), Pharo (FileSystem), and Squeak (default for OSProcess/CommandShell).
The differences between Cuis and Squeak are not great, but if the goal was to move trunk to FileMan as the preferred interface, then the conversion would need to be carefully managed in order to keep external packages functioning as the trunk moved to the new file system interface.
Dave
On 2024-04-08 19:54, Tim Rowledge wrote:
Aside from the issue of no-file-means-nil vs no-file-means-object there is an interestingly tricky thing in that FileMan more explicitly splits file entry objects and directory entry objects. Squeak uses DirectoryEntry and makes an instance of a suitable subclass (which is one of the things making no-file-means-object tricky you can't make the right thing if it isn't there to check) whereas FileMan exposes #asDirectoryEntry such that it makes an object that only works for directories, and a asFileEntry similar for files.
All of which is making it hard to think of nice clean ways to make trunk code that will keep working properly if FileMan is installed.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CWB: Carry With Borrow
That's a lot of work done for the compatibility. I noticed some other issues in the classes as loaded from the https://github.com/mumez/FileMan page - for example there seem to be a lot of trivially duplicated methods between FmFileIOAccessor & FmFileDirectoryFileIOAccessor, and some methods that appear to ignore important things.
I dunno. File systems & file names etc might even be harder than Time & Dates.
I really should back out of the rabbit hole and get back to what I was meant to be doing...
On 2024-04-08, at 3:29 PM, lewis@mail.msen.com wrote:
If you have a copy of OSProcess and CommandShell loaded in your Squeak image, take a look at senders of #useFileMan. These methods are attempting to maintain compatibility across Cuis (FileMan), Pharo (FileSystem), and Squeak (default for OSProcess/CommandShell).
The differences between Cuis and Squeak are not great, but if the goal was to move trunk to FileMan as the preferred interface, then the conversion would need to be carefully managed in order to keep external packages functioning as the trunk moved to the new file system interface.
Dave
On 2024-04-08 19:54, Tim Rowledge wrote:
Aside from the issue of no-file-means-nil vs no-file-means-object there is an interestingly tricky thing in that FileMan more explicitly splits file entry objects and directory entry objects. Squeak uses DirectoryEntry and makes an instance of a suitable subclass (which is one of the things making no-file-means-object tricky you can't make the right thing if it isn't there to check) whereas FileMan exposes #asDirectoryEntry such that it makes an object that only works for directories, and a asFileEntry similar for files.
All of which is making it hard to think of nice clean ways to make trunk code that will keep working properly if FileMan is installed.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: CWB: Carry With Borrow
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Aio, quantitas magna frumentorum est. = Yes, that is a very large amount of corn.
FileMan has been adopted in Cuis, and is actively used and maintained there:
http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-td4857651.html
In my personal opinion, the FileMan approach is very good. It is conceptually clean and is not unnecessarily tied to any operating system.
IMHO the current Squeak file interface is actually better that it is given credit for, but if we wanted to move to something better then I would suggest looking at the Cuis implementation of FileMan and consider adopting that.
Dave
On 2024-04-04 23:55, Tim Rowledge wrote:
I was just taking a look at the FileMan package (https://github.com/mumez/FileMan) since I've heard it mentioned as having some improved file name handling. It looks like it would need a little mangling for Squeak 6 and it seems to have a difference in how "this string' asDirectoryEntry works that might be a problem.
Current trunk Squeak will return nil if one tries to do 'nonexistentfilename' asDirectoryEntry but FileMan will create an FmDirectoryEntry; so any code that anticipates nil meaning "the file wasn't there" will have issues.
Is anyone using this? Updating it?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A titanic intellect... In a world full of icebergs.
And of course we should remember to give credit to Masashi Umezawa, the author and designer of FileMan.
Dave
On 2024-04-05 02:54, lewis@mail.msen.com wrote:
FileMan has been adopted in Cuis, and is actively used and maintained there:
http://forum.world.st/New-Commit-FileMan-adoption-and-tweaks-td4857651.html
In my personal opinion, the FileMan approach is very good. It is conceptually clean and is not unnecessarily tied to any operating system.
IMHO the current Squeak file interface is actually better that it is given credit for, but if we wanted to move to something better then I would suggest looking at the Cuis implementation of FileMan and consider adopting that.
Dave
On 2024-04-04 23:55, Tim Rowledge wrote:
I was just taking a look at the FileMan package (https://github.com/mumez/FileMan) since I've heard it mentioned as having some improved file name handling. It looks like it would need a little mangling for Squeak 6 and it seems to have a difference in how "this string' asDirectoryEntry works that might be a problem.
Current trunk Squeak will return nil if one tries to do 'nonexistentfilename' asDirectoryEntry but FileMan will create an FmDirectoryEntry; so any code that anticipates nil meaning "the file wasn't there" will have issues.
Is anyone using this? Updating it?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- A titanic intellect... In a world full of icebergs.
squeak-dev@lists.squeakfoundation.org
-
lewis＠mail.msen.com -
Tim Rowledge