OK, Matthew jumped the gun a bit there. The problem in fact had little or nothing to do with SqueakMap.
First let me explain that the mysterious EOCD message is an unzipping error message. The SqueakMap client fetches some data and thinks it is a SAR or MCZ or some other zipped content and blithely hands it over to be unzipped, the unzipper barfs on it because in fact it is an HTTP error message and not zipped at all. So at best the complaint could be here that the client does not properly check for HTTP error messages.
The root of this particular problem was in fact that the server FFI was trying to fetch it's constituent packages from was down: source.squeakfoundation.org. I have now fixed this and successfully test loaded FFI. Please give it another try.
Ken
P.S. Where did you get a 7142 image? I can't get past 7141.
Mathew said:
On Thu, Aug 16, 2007 at 08:17:53PM +0200, Andreas Wacknitz wrote:
If have problems loading FFI-3.9.1 into a fresh 3.10-7142 image. I'll get an "Error: can't find EOCD position". See the appended SqueakDebug.log file. Is this a temporary problem?
How are you installing it? Use universes. Squeakmap is currently broken.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
Hello
First let me explain that the mysterious EOCD message is an unzipping error message. The SqueakMap client fetches some data and thinks it is a SAR or MCZ or some other zipped content and blithely hands it over to be unzipped, the unzipper barfs on it because in fact it is an HTTP error message and not zipped at all. So at best the complaint could be here that the client does not properly check for HTTP error messages.
Now things get clearer. I was complaining about EOCD error, too.
Thanks for the explanation Enno
What is the appropriate way in Squeak to check for HTTP error messages, then? Maybe I can fix this pretty quickly. The (only, thankfully) relevant line in SqueakMap is in SMFileCache>>getStream: which does:
| stream | [stream := aDownloadable downloadUrl asUrl retrieveContents contentStream binary. (aDownloadable correctSha1sum: stream contents) ifFalse: [self error: 'Incorrect SHA checksum of file from orginal URL']] on: Exception do: [:ex | Transcript show: 'Download from original url (', aDownloadable downloadUrl, ') failed with this exception: ', ex messageText;cr. ...
I assume that the first line of this method needs to be split up so that we can check the response code at some point. Someone more knowledgeable than me, could you point out how to do this?
I looked at some senders of retrieveContents, and none seem to check response codes, so there is likely a lot of improvement to be made across the board in this area.
On Aug 16, 2007, at 12:18 PM, Enno Schwass wrote:
Hello
First let me explain that the mysterious EOCD message is an unzipping error message. The SqueakMap client fetches some data and thinks it is a SAR or MCZ or some other zipped content and blithely hands it over to be unzipped, the unzipper barfs on it because in fact it is an HTTP error message and not zipped at all. So at best the complaint could be here that the client does not properly check for HTTP error messages.
Now things get clearer. I was complaining about EOCD error, too.
Thanks for the explanation Enno
-- -Brian http://briantrice.com
I'm afraid you are going to have to bypass the abstraction provided by HttpUrl and use HTTPSocket or the like directly or perhaps use another abstraction on top of it which has more intelligence in this regard.
Ken
On Thu, 2007-08-16 at 15:29 -0700, Brian Rice wrote:
What is the appropriate way in Squeak to check for HTTP error messages, then? Maybe I can fix this pretty quickly. The (only, thankfully) relevant line in SqueakMap is in SMFileCache>>getStream: which does:
It seems like this is always something you would want to know, right? In that case maybe HttpUrl should be change to throw exceptions or at least have an #onHTTPErrorResponse: type protocol.
On 8/17/07, Ken Causey ken@kencausey.com wrote:
I'm afraid you are going to have to bypass the abstraction provided by HttpUrl and use HTTPSocket or the like directly or perhaps use another abstraction on top of it which has more intelligence in this regard.
Ken
On Thu, 2007-08-16 at 15:29 -0700, Brian Rice wrote:
What is the appropriate way in Squeak to check for HTTP error messages, then? Maybe I can fix this pretty quickly. The (only, thankfully) relevant line in SqueakMap is in SMFileCache>>getStream: which does:
"Jason Johnson" jason.johnson.081@gmail.com writes:
It seems like this is always something you would want to know, right? In that case maybe HttpUrl should be change to throw exceptions or at least have an #onHTTPErrorResponse: type protocol.
Some such refactoring would be great. It's a long-standing issue:
http://bugs.squeak.org/view.php?id=6495
I haven't thought it through in a while, but my suggested refactoring at the time was this:
Errors should be reported better. One refactoring would be to make an "DownloadError" subclass of MIMEDocument. Then, we could robustly track which downloads are errors, without breaking compatibility with code that simply displays the result whether it was an error or not (e.g., Scamper).
Anyone interested in making a little ErroneousMIMEDocument class to patch this up?
-Lex
El 8/16/07 4:06 PM, "Ken Causey" ken@kencausey.com escribió:
P.S. Where did you get a 7142 image? I can't get past 7141.
You are having some trouble ?
the 7142ReformatOnscanForEqSmallConstant-di.cs
Reporter: MarcusDenker Summary: 0002788: Bug: Use of == for arithmetic equality Description: From: Dan.Ingalls@Post.Harvard.edu Subject: Bug: Use of == for arithmetic equality Date: 13. Februar 2006 18:37:42 GMT+01:00
I send mail to v3dot list about how manage this important change (reformat 172 methods)
1) same as we doing until now 2) via old .cs 3) put a complete image into ftp
I could load the update, the code is :
ReleaseBuilderFor3dot10 new updatePackages: 'Collections-edc.90(89).mcd CollectionsTests-edc.74(73).mcd Graphics-edc.42(41).mcd Kernel-edc.166(165).mcd KernelTests-edc.58(57).mcd Monticello-edc.313(312).mcd Morphic-edc.129(128).mcd MorphicExtras-edc.34(33).mcd Multilingual-edc.29(28).mcd ST80-edc.40(39).mcd System-edc.106(105).mcd Tests-edc.33(32).mcd Tools-edc.85(84).mcd'.
ReleaseBuilderFor3dot10 new loadTogether: #('EToys-edc.25.mcz' 'Network-edc.34.mcz' 'Traits-edc.230.mcz' 'XML-Parser-edc.4.mcz') merge: false.
is working for me, I wish know if some have troubles too for doing a complete image and put into ftp
Edgar
On Thu, 2007-08-16 at 17:38 -0300, Edgar J. De Cleene wrote:
El 8/16/07 4:06 PM, "Ken Causey" ken@kencausey.com escribió:
P.S. Where did you get a 7142 image? I can't get past 7141.
You are having some trouble ?
Well, maybe and maybe not.
At the time I sent the message if I tried to load updates it simply said none were available. I've tried again just now and do in fact get 7142. In truth I assumed Andreas had made a typo. In any case, I wouldn't assume for now that there is actually any problem.
Ken
squeak-dev@lists.squeakfoundation.org
-
Brian Rice -
Edgar J. De Cleene -
Enno Schwass -
Jason Johnson -
Ken Causey -
Lex Spoon