At 2:20 PM -0700 5/2/98, Tim Rowledge wrote:
I found a confusion in the treatment of the paths held by FileDirectory whilst rying to make PWS run on my Acorn. Basically, the PWS code is assuming that there is a separator character at the end of the path (ie wibble::myDisc.foo.bar. ) whereas I had rather thought that they didn't.
The intended spec is that sending pathName to an instance of FileDirectory (or one of its platform dependent subclasses) should return a pathName that does NOT end in a separator character, so your directory primitives are correct.
We should fix the PWS code to not expect a trailing separator, then make FileDirectory class>on: strip off a trailing separator if one is supplied. Meanwhile, you'll probably just want to work around the problem.
-- John
P.S. Do you have a pointer to the problem methods in PWS? I noticed that ServerAction>serverDirectory is assumed to return a path ending in a delimiter for convenience, but that seems fair since it is used only as a prefix string to construct file names.
On Sun 03 May, Maloney wrote:
The intended spec is that sending pathName to an instance of FileDirectory (or one of its platform dependent subclasses) should return a pathName that does NOT end in a separator character, so your directory primitives are correct.
Oh good. I was beginning to wonder if anything else was likely to go wrong.
We should fix the PWS code to not expect a trailing separator, then make FileDirectory class>on: strip off a trailing separator if one is supplied.
Definitely. It ought to do more checking for bad characters etc as well.
P.S. Do you have a pointer to the problem methods in PWS?
It was SwikiAction class>setUp: that caused the problem. There is a line 'dir _ FileDirectory on: (ServerAction serverDirectory). (dir directoryNames includes: actionName)......' and if I put a dirsep at the end of the server dirname, the directoryNames is empty, so obviously the system decides I don't have a suitable directory with which to work. If I cut the dirsep, that part works, but later code in the same method assumes the dirsep to be there ie:- '((FileStream fileNamed: (ServerAction serverDirectory),'swiki',.....' which is going to make a path like ...foo.barswiki instead of .....foo.bar.swiki and confuse things!
I noticed that ServerAction>serverDirectory is assumed to return a path ending in a delimiter for convenience, but that seems fair since it is used only as a prefix string to construct file names.
Unfortunately not so in the setUp: code, hence the problem I had. Wouldn't it be better to create and use the FileDirectory object anyway, rather than repetitively building strings into paths without a decent protocol to handle pathname rules?
tim
At 6:37 PM -0700 5/3/98, Tim Rowledge wrote:
On Sun 03 May, Maloney wrote:
P.S. Do you have a pointer to the problem methods in PWS?
It was SwikiAction class>setUp: that caused the problem. There is a line 'dir _ FileDirectory on: (ServerAction serverDirectory). (dir directoryNames includes: actionName)......' and if I put a dirsep at the end of the server dirname, the directoryNames is empty, so obviously the system decides I don't have a suitable directory with which to work.
It's actually more common than just in setUp. Consider the ServerAction>>fileContents method, which is used for serving all files: fileContents: serverFileRef ^(FileStream fileNamed: (ServerAction serverDirectory) , serverFileRef) contentsOfEntireFile
Again, there's the assumption the serverDirectory ends in the path separator, and it's just concatenated on to the serverFile reference in order to grab the file. Just about every file reference is going to make this assumption, I fear.
Wouldn't it be better to create and use the FileDirectory object anyway, rather than repetitively building strings into paths without a decent protocol to handle pathname rules?
You're almost certainly correct. It's a case of knowing the right way vs. knowing a way. I'm still relatively novice and am only just recently started figuring out how to use FileDirectory objects, and I'd never heard of them six months ago. But I did know how to concatenate strings! :-)
In general, it's a hard problem -- you don't want to have someone spend ages learning everything in the image before he or she can start work in Smalltalk (or any large system), but how do you make sure that standard ways of doing things occur everywhere?
Also, Tim, be sure to check out the updates page at http://www.cc.gatech.edu/fac/mark.guzdial/squeak/pws/131updates.html A variety of bugs and enhancements have been made to PWS and Swiki's since the 1.31 release.
Mark
-------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
squeak-dev@lists.squeakfoundation.org
-
Maloney -
Mark Guzdial -
Tim Rowledge