Problem loading FFI

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?

Regards
Andreas

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

Matthew Fulmer wrote:

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.

  

I've been using universes.

Try again,

the server was broken. When I got such error with Universes or MC, I try
to reach the server (generally sources.squeakfoundation.org) by a web
browser,

Cheers,

--
Martial

Andreas Wacknitz a écrit :
| Matthew Fulmer wrote:
| >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.
| >
| >  
| I've been using universes.

|

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:

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

El 8/16/07 4:06 PM, "Ken Causey" <[hidden email]> 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:   [hidden email]
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" <[hidden email]> 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

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:

--
-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 <[hidden email]> wrote:

"Jason Johnson" <[hidden email]> 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