I am trying to use scamper to read html files from disk, i.e. using url like file://path/file.html In Squeak 3.5 it worked fine, but with >=3.7 it doesn't work. I always get an "Error retrieving this URL" message. It also happens using browser:about as url. I am using squeak on Debian and everything else seems to be fine. I don't have a windows machine to test if it is a problem related to the filesystem. After searching in this list and in bugs.impara.de, nobody else has noticed this behaviour, so maybe it is because of my setup. Can anybody else confirm this error before sending a bug report? Regards.
Try putting one extra '/' after the uri:
file:///path/file.html
otherwise your 'path' part would have to be relative to FileDirectory default. If it is relative, I'm not sure :-)
Brian
On Mar 3, 2005, at 5:44 AM, José L. Redrejo Rodríguez wrote:
I am trying to use scamper to read html files from disk, i.e. using url like file://path/file.html In Squeak 3.5 it worked fine, but with >=3.7 it doesn't work. I always get an "Error retrieving this URL" message. It also happens using browser:about as url. I am using squeak on Debian and everything else seems to be fine. I don't have a windows machine to test if it is a problem related to the filesystem. After searching in this list and in bugs.impara.de, nobody else has noticed this behaviour, so maybe it is because of my setup. Can anybody else confirm this error before sending a bug report? Regards.
Brian Brown rbb@techgame.net wrote:
Try putting one extra '/' after the uri:
file:///path/file.html
otherwise your 'path' part would have to be relative to FileDirectory default. If it is relative, I'm not sure :-)
Eh... no. :) Or rather - yes - you need an extra slash *always* - but no - it doesn't make the path "absolute" or anything, it just separates the path from the host. This is the syntax for a file URL:
file://<host>/<absolutepathtofile>
You may omit <host> implying "localhost" (thus getting 3 slashes in a row), but that is it. The path is always absolute according to the standard, but in Squeak you can still tell the URL if it should be interpreted as absolute or as relative to FileDirectory default. Check class comment of FileUrl and also the UrlTest class.
regards, Göran
PS. I worked hard on getting FileUrl correct, and I think and hope it is. :)
goran.krampe@bluefish.se wrote:
You may omit <host> implying "localhost" (thus getting 3 slashes in a row), but that is it. The path is always absolute according to the standard, but in Squeak you can still tell the URL if it should be
for the gazilionst time: relative URIs/URLs are allowed by the standard (http://www.faqs.org/rfcs/rfc2396.html).
They just have to be resolved against an absolute URI in order to access the resource identified/located by it.
And the URLs in Squeak are still broken and should be replaced by one of the existing standard compliant URI implementations.
OK, stepping of my soap box with the broken record sounding...
Michael
Hi!
Michael Rueger michael@impara.de wrote:
goran.krampe@bluefish.se wrote:
You may omit <host> implying "localhost" (thus getting 3 slashes in a row), but that is it. The path is always absolute according to the standard, but in Squeak you can still tell the URL if it should be
for the gazilionst time: relative URIs/URLs are allowed by the standard (http://www.faqs.org/rfcs/rfc2396.html).
Eh, hmmm, this feels like deja vu. :) Ah, it is:
http://lists.squeakfoundation.org/pipermail/squeak-dev/2004-April/07778 8.html
They just have to be resolved against an absolute URI in order to access the resource identified/located by it.
And the URLs in Squeak are still broken and should be replaced by one of the existing standard compliant URI implementations.
OK, stepping of my soap box with the broken record sounding...
I still am confused at what to think. See the posting above. It does not seem clear cut at all.
Michael
regards, Göran
Gee how timely, I was working on Tk4/Sophie this morning and coding up a FileURL for a font file.
say FileUrl absoluteFromText: 'file:///Library/Fonts/Corsiva.ttf'.
But the problem is on the mac when I ask for the pathForFile I get back
':Library:Fonts:Corsiva.ttf'
The leading ':' implies under HFS+ to use the current working directory and of course we don't get the file open. In this case the path should be: 'Library:Fonts:Corsiva.ttf''
Now if I say FileUrl absoluteFromText: 'file:Library/Fonts/Corsiva.ttf'. which gets me a non-absolute file URL object, then I'll get the HFS+ correct, but that's wrong...
On Mar 3, 2005, at 6:31 AM, goran.krampe@bluefish.se wrote:
PS. I worked hard on getting FileUrl correct, and I think and hope it is. :)
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Right so the Tweak image I have might be 3.8 (mostly) but it's not quite. I see "Change Set: FixUrlAgain3 Date: 18 October 2004 Author: Andreas Raab
A third attempt at fixing FileUrl>>pathForFile."
fixes the issue.
On Mar 3, 2005, at 11:58 AM, John M McIntosh wrote:
Gee how timely, I was working on Tk4/Sophie this morning and coding up a FileURL for a font file.
say FileUrl absoluteFromText: 'file:///Library/Fonts/Corsiva.ttf'.
But the problem is on the mac when I ask for the pathForFile I get back
':Library:Fonts:Corsiva.ttf'
The leading ':' implies under HFS+ to use the current working directory and of course we don't get the file open. In this case the path should be: 'Library:Fonts:Corsiva.ttf''
Now if I say FileUrl absoluteFromText: 'file:Library/Fonts/Corsiva.ttf'. which gets me a non-absolute file URL object, then I'll get the HFS+ correct, but that's wrong...
On Mar 3, 2005, at 6:31 AM, goran.krampe@bluefish.se wrote:
PS. I worked hard on getting FileUrl correct, and I think and hope it is. :)
--
==== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================= ====
-- ======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
I'm curious why you don't deprecate the HFS+ pathing conventions and switch to unix style paths since the apis are there on OSX.
On Mar 3, 2005, at 11:58 AM, John M McIntosh wrote:
Gee how timely, I was working on Tk4/Sophie this morning and coding up a FileURL for a font file.
say FileUrl absoluteFromText: 'file:///Library/Fonts/Corsiva.ttf'.
But the problem is on the mac when I ask for the pathForFile I get back
':Library:Fonts:Corsiva.ttf'
The leading ':' implies under HFS+ to use the current working directory and of course we don't get the file open. In this case the path should be: 'Library:Fonts:Corsiva.ttf''
Now if I say FileUrl absoluteFromText: 'file:Library/Fonts/Corsiva.ttf'. which gets me a non-absolute file URL object, then I'll get the HFS+ correct, but that's wrong...
On Mar 3, 2005, at 6:31 AM, goran.krampe@bluefish.se wrote:
PS. I worked hard on getting FileUrl correct, and I think and hope it is. :)
--
==== John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================= ====
It's being considered. In fact we've thought about support both at the same time. However under the covers the carbon vm uses FSSpecs for the most part since it has code that runs on both os-9 and os-x. It also has full alias support which is missing in the Unix version. It really comes down to many hours of work/testing to convert and write new code to handle this. Also for this particular problem it still would affect os-8/9 users. I will note that it's fixed in later changesets not found in the older image I was working with.
On Mar 4, 2005, at 12:13 AM, Todd Blanchard wrote:
I'm curious why you don't deprecate the HFS+ pathing conventions and switch to unix style paths since the apis are there on OSX.
On Mar 3, 2005, at 11:58 AM, John M McIntosh wrote:--
======================================================================== === John M. McIntosh johnmci@smalltalkconsulting.com 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ======================================================================== ===
Hi John!
John M McIntosh johnmci@smalltalkconsulting.com wrote:
Gee how timely, I was working on Tk4/Sophie this morning and coding up a FileURL for a font file.
say FileUrl absoluteFromText: 'file:///Library/Fonts/Corsiva.ttf'.
But the problem is on the mac when I ask for the pathForFile I get back
':Library:Fonts:Corsiva.ttf'
Just tried in my 3.8 and given Andreas fix back in October (I think) it looks good. I threw in a MacHFSPlusFileDirectory to see it (I am on Linux) though, but it looks good to me.
The leading ':' implies under HFS+ to use the current working directory and of course we don't get the file open. In this case the path should be: 'Library:Fonts:Corsiva.ttf''
Good. :)
Now if I say FileUrl absoluteFromText: 'file:Library/Fonts/Corsiva.ttf'. which gets me a non-absolute file URL object, then I'll get the HFS+ correct, but that's wrong...
Oh yes, that is wrong. Now you are relying on a bit of "smartness" in FileUrl>>privateInitializeFromText: which, if there aren't two slashes after "file:" - meaning it can't possibly be a correct FileUrl - then it tries to handle *everything* after "file:" as the path.
And since the current logic for detecting "absoluteness" checks for a leading "/" (which given my coding and reliance on RFC1738 (and the presumption that all FileUrls *are* absolute) is a trick, because in a correctly formed FileUrl there is always a slash after <host>, becuase it is the separator) it will think that the path is not absolute.
But again, that is just code I threw in to be able to "decently handle malformed file URLs".
regards, Göran
On 03/03/05 09:44, "L. Redrejo José Rodríguez" jredrejo@edu.juntaextremadura.net wrote:
I am trying to use scamper to read html files from disk, i.e. using url like file://path/file.html In Squeak 3.5 it worked fine, but with >=3.7 it doesn't work. I always get an "Error retrieving this URL" message. It also happens using browser:about as url. I am using squeak on Debian and everything else seems to be fine. I don't have a windows machine to test if it is a problem related to the filesystem. After searching in this list and in bugs.impara.de, nobody else has noticed this behaviour, so maybe it is because of my setup. Can anybody else confirm this error before sending a bug report? Regards.
Here a slow and dirty solution. 1 Go to SM 2 Load Network-HTML-md.4 3 | input aText sf| input := FileStream oldFileNamed: afileName. aText := (HtmlParser parse: input) formattedText.
sf := (ScrollableField new) yourself;
color: (Color r: 0.972 g: 0.972 b: 0.662).
sf setMyText: aText.
sf openInHand
From the book "1001 stupid things to do with Squeak"
Edgar
squeak-dev@lists.squeakfoundation.org
-
Brian Brown -
goran.krampe＠bluefish.se -
John M McIntosh -
José L. Redrejo Rodríguez -
Lic. Edgar J. De Cleene -
Michael Rueger -
Todd Blanchard