[FIX] Re: [BUG] Re: Bookmorphs not working in Linux?
Mark Guzdial
guzdial at cc.gatech.edu
Thu Jan 20 17:10:14 UTC 2000
Thanks, Bert. There was a missing period in your example, which I
fixed, but with this fix, I can't read books on Macs anymore! The
filename now has a leading ":" <sigh>
I'll dig further and see if I can fix this. Thanks!
Mark
At 6:32 PM +0100 1/20/00, Bert Freudenberg wrote:
>On Wed, 19 Jan 2000, Mark Guzdial wrote:
>
> > I'm producing BookMorphs for my lectures this term, and my
> > Linux-using students say that they can't read them. They say that
> > they try to load the book from the FileList, and they do get the
> > control buttons across the top, but no page. When they click "next
> > page" they get told that the file does not exist. Are any other
> > Linux-users having similar problems with BookMorphs?
> >
> > The bookmorphs are zipped at http://coweb.cc.gatech.edu/cs2340/7 if
> > you're looking for some examples to try.
>
>Hi Mark,
>
>that's a serious bug, though it seems unrelated to the operating system. I
>just looked into this and when debugging I managed to hang my Squeak which
>never happens otherwise.
>
>The root of the problem are file urls. The book loads fine, but the page
>looks for an url "file://var/Squeak/2.7/markbook/ch2-p1-tour1.sp", which
>is wrong, it should be file:/var/ ... Anyway, the resulting file path is
>"var/Squeak/2.7/markbook/ch2-p1-tour1.sp" which is wrong since the leading
>slash is missing. The default directory is "/var/Squeak/2.7". This leads
>to the absolute file
>"/var/Squeak/2.7/var/Squeak/2.7/markbook/ch2-p1-tour1.sp" since it is
>treated as relative path.
>
><btw>
> It is a a popular fallacy to take "something://" as the beginning
> (uninteresting) part of an URL. "something:" specifies a scheme,
> "//something" specifies an authority, and "/something" the path.
>
> see http://www.faqs.org/rfcs/rfc2396.html
>
> For file urls, this means that file:/path is okay as is
> file://localhost/path. Netscape does accept both as well as except
> file:///path, but in file://something "something" is looked up as host.
> A relative file would be file:relpath.
></btw>
>
>Okay, I digged a little deeper into this.
>
>The bug is in FileUrl>>pathForDirectory which ignores the isAbsolute inst
>var. The reason why it still works on a Mac seems to be
>MacFileDir>>fullPathFor: aPath - it simply does not check if aPath is
>absolute or relative, whereas the Win / Unix variants do. I'd consider the
>Mac behaviour a kludge that covers other inconsistencies.
>
>Anyway, here's a FIX. I'm not sure if this works on Mac/Windows. There
>should be a way to generate an absolute filepath from its components.
>
>-------------------------
>!FileUrl methodsFor: 'access' stamp: 'bf 1/20/2000 18:17'!
>pathForDirectory
> "Path using local file system's delimiter. $\ or $:"
>
> ^ String streamContents: [ :s |
> isAbsolute ifTrue:[ s nextPut: FileDirectory pathNameDelimiter]
> 1 to: self path size - 1 do: [ :ii |
> s nextPutAll: (path at: ii); nextPut: FileDirectory pathNameDelimiter
> ] ]! !
>-------------------------
>
>But still, several methods wrongly generate file:// urls (like
>FileDirectory>>url, FileStream>>url, FileUrl>>totext). These should be
>corrected.
>
> -Bert-
--------------------------
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280
(404) 894-5618 : Fax (404) 894-0673 : guzdial at cc.gatech.edu
http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
More information about the Squeak-dev
mailing list
|