[squeak-dev] Problems installing FFI on 3.10 release

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> Andreas Raab
> Sent: 01 April 2008 10:27 AM
> To: The general-purpose Squeak developers list
> Subject: [squeak-dev] Re: Problems installing FFI on 3.10 release
>
>
> Andrew Tween wrote:
> > It loads ok, from Universe, if it is the first thing loaded.
> > It fails to load in a 3.10 developer image -see
> > http://bugs.squeak.org/view.php?id=6952
>
> Yeah, I was just looking at this. BTW, has anyone actually tried to work
> with the Squeak-dev image naively? It's a complete screw-up; here is my
> experience with sq3.10-7159dev08.03.1.image:
> * Try to open a new browser; looks like the system is frozen; three
> seconds later the browser *finally* appears
> * Try to open a Universe browser (basic); no search facility; oh well...
> * Try to open a Universe browser (enhanced); it has search (yay!);
> search for "FFI"; it explodes (some OB internal error)
> * Open the basic universe browser again; open every goddamn tree to find
> the FFI; each tree takes about five seconds to open them all because
> it's so goddamn slooooooooow
> * about a minute later, finally, FINALLY, find the FFI; click on FFI
> version 3.9 and "select package"; wait ten seconds before it *finally*
> selects something
> * Try loading it; it explodes; abort it; expect to find the so-called
> "atomic" load to leave no traces behind; find out that that's not true
> * Quit and go through the same process again; try with 3.9.1; it
> explodes again
> * Open a debugger; find the place where it goes wrong; "browse" to it;
> ten endless seconds later a browser *finally* appears
> * Navigate to ExternalType; try to understand what is wrong with
> StructTypes; WHERE THE HELL IS CLASS VAR REFS IN OB???
>
> Giving up. This is completely and utterly unusable. Every single step
> takes five seconds or more. I have never seen a Squeak image that has
> frustrated me more and that made the simplest and most basic things
> painful and unusable.
>
> If this is a "developer" image then I'm a graphics artist.
>
> For comparison, the good ol' Browser macroBenchmark:
>
> [saveMorphs := World submorphs.
> World removeAllMorphs."heh, heh"
> time := Time millisecondsToRun:[1 to: 10 do: [:i |
> Browser fullOnClass: Object selector: #printOn:].
> World submorphs do: [:m | m delete. self currentWorld doOneCycle].
> ]] ensure:[World addAllMorphs: saveMorphs].
> time
>
> executes in 44,120 msecs in the Squeak-dev image; in my Qwaq image
> (which uses Shout and TT fonts; Squeak-dev only uses Shout) this
> executes in a mere 6,173 msecs. That is about 7x faster than Squeak-dev.
> How do you people get work done?
>
> Apologies for the rant, but when I'm trying to fix problems I'm not
> particularly tolerant towards any "improvements" that serve no other
> purpose than distracting me from getting the job done.
>
> And apologies to everyone using 3.10 and trying to load the FFI but I
> can't fix the problem in a system that is *that* slow. Not unless
> someone buys me a 4GHz quadruple core box with two bazillion bytes of
> memory first.
>
> Cheers,
>    - Andreas
>

>
> If this is a "developer" image then I'm a graphics artist.
>
> For comparison, the good ol' Browser macroBenchmark:
>
> [saveMorphs := World submorphs.
> World removeAllMorphs."heh, heh"
> time := Time millisecondsToRun:[1 to: 10 do: [:i |
> Browser fullOnClass: Object selector: #printOn:].
> World submorphs do: [:m | m delete. self currentWorld doOneCycle].
> ]] ensure:[World addAllMorphs: saveMorphs].
> time
>
> executes in 44,120 msecs in the Squeak-dev image; in my Qwaq image
> (which uses Shout and TT fonts; Squeak-dev only uses Shout) this
> executes in a mere 6,173 msecs. That is about 7x faster than
> Squeak-dev. How do you people get work done?
>
> Apologies for the rant, but when I'm trying to fix problems I'm not
> particularly tolerant towards any "improvements" that serve no other
> purpose than distracting me from getting the job done.
>
> And apologies to everyone using 3.10 and trying to load the FFI but I
> can't fix the problem in a system that is *that* slow. Not unless
> someone buys me a 4GHz quadruple core box with two bazillion bytes of
> memory first.
>
> Cheers,
>   - Andreas
>
>
>

> Igor Stasenko wrote:
>
> > Anyone tried to install subject onto fresh 3.10 image?
> >
> > It stops with error, trying to react on class change notification,
> > while it's own internal structures still not initialized (StructTypes
> > classvar).
> > Seem like a simple order of initialization bug.
> >
> >
>  Packages which depend upon a specific initialization order are coming
> unstuck in the latest MC1.5
>

> 2008/4/1 Keith Hodges <[hidden email]>:
>  
>> Igor Stasenko wrote:
>>
>>    
>>> Anyone tried to install subject onto fresh 3.10 image?
>>>
>>> It stops with error, trying to react on class change notification,
>>> while it's own internal structures still not initialized (StructTypes
>>> classvar).
>>> Seem like a simple order of initialization bug.
>>>
>>>
>>>      
>>  Packages which depend upon a specific initialization order are coming
>> unstuck in the latest MC1.5
>>
>>    
>
> Yes, it looks like bug in MC. Because in CLEAN Squeak3dot10.7159.image
> it loaded ok.
> But after i installed LPF & Installer, FFI fails to load.
>
>  
>>  Keith
>>
>>    

>
> Igor Stasenko wrote:
>
> > 2008/4/1 Keith Hodges <[hidden email]>:
> >
> >
> > > Igor Stasenko wrote:
> > >
> > >
> > >
> > > > Anyone tried to install subject onto fresh 3.10 image?
> > > >
> > > > It stops with error, trying to react on class change notification,
> > > > while it's own internal structures still not initialized (StructTypes
> > > > classvar).
> > > > Seem like a simple order of initialization bug.
> > > >
> > > >
> > > >
> > > >
> > >  Packages which depend upon a specific initialization order are coming
> > > unstuck in the latest MC1.5
> > >
> > >
> > >
> >
> > Yes, it looks like bug in MC. Because in CLEAN Squeak3dot10.7159.image
> > it loaded ok.
> > But after i installed LPF & Installer, FFI fails to load.
> >
> >
> >
> > >  Keith
> > >
> > >
> > >
> >
>  I specifically reversed the order in which post load actions are executed.
> This ensures that overriding methods get loaded after the method which they
> are overriding.
>
>  Ok, I put it another way....  if your package depends upon a specific
> initialization order, it shouldnt. Nowhere is it defined that class A will
> recieve #initialize before class B. So strictly speaking it is not a bug in
> MC1.5 and it isn't easily fixed in MC1.5 at present.
>

> On Tue, Apr 01, 2008 at 10:54:57PM -0700, Andreas Raab wrote:
>>> No kidding. I was particularly frustrated by Monticello 1.5. I tried
>>> reverting to an earlier release that's been a workhorse for me,  
>>> but it
>>> seems to have some trait-related problems... gave up for now.
>>
>> I was wondering about the purpose of MC 1.5. I *thought* its whole  
>> reason
>> for existence was to support atomic loading. Now that I find out that
>> that's not true it makes me wonder what it has over the "regular" MC?
>
> MC1.5 was made to solve the problem: Croquet, Impara, and Squeak
> 3.10 had different, incompatible MC versions. MC1.5 incorporates
>  all the bug fixes from each fork, and then fixes several bugs
>  relating to dependencies between packages:
>
> - overridden methods are properly restored when the overriding
>  package is removed
> - Packages can be loaded out-of-order; if there are extensions
>  in package A for a class defined in package B, they will be in
>  the right place no matter whether A or B is loaded first
> - Postscripts and preambles work
>
> and various similar bug fixes. The recently introduced bug that
> class initialization methods run in a different version than
> before is being fixed, or has been; I don't know.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
>

> Hi matthew
>
> do you know if the patch of ralph supporting "atomic loading"  and
> possibly breaking the
> systemChangenotifier is included in MC1.5? Because this would really
> stop me from looking
> at it for the moment.
>
> Stef
>