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.
Hi "Igor Stasenko" siguctua@gmail.com wrote in message news:4a5f5f320803311638k61efe03fr87bcb8fdde05ccca@mail.gmail.com...
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.
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
Cheers, Andy
-- Best regards, Igor Stasenko AKA sig.
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
On 1-Apr-08, at 2:27 AM, Andreas Raab wrote:
WHERE THE HELL IS CLASS VAR REFS IN OB???
Click on a class. Choose "chase variables" from the context menu. Click the "class" tab.
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.
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.
Colin
Colin Putney wrote:
On 1-Apr-08, at 2:27 AM, Andreas Raab wrote:
WHERE THE HELL IS CLASS VAR REFS IN OB???
Click on a class. Choose "chase variables" from the context menu. Click the "class" tab.
Yeah, that was just the thing that pushed me over the edge. I was seeing myself working in five-seconds intervals trying to find my way through OB via "click ... wait five seconds ... no wrong place ... click ... wait five more seconds ... no still wrong place ... click ... wait five more seconds .... etc" and since I had just been through that painful process in the Universe browser I just couldn't bear the thought of my valuable spare time wasted in that way. If there would have been a "class var refs" straight from the OB menu I might have fixed it but that was just too much for me.
BTW, I just tried this again and OB is terribly confusing - if you happen to have the "class" tab selected "chase variables" gives you the metaclass variables which is really confusing. So you need to know that when you want to look at a class var that is being used by a class method you have to select "instance", "chase pointers", and the "class" tab again; where the same operation without first selecting "instance" ends you up in Object>>DependentsFields. Very confusing.
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.
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?
Cheers, - Andreas
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.
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
On Apr 2, 2008, at 9:06 AM, Matthew Fulmer wrote:
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/
stephane ducasse wrote:
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
Stef,
Ralph's non-atomic atomic loading code was used as inspiration for MC1.5's code
MC1.5 does contain prototypical real SystemEditor based atomic loading code which does not support traits and so is not yet enabled.
Keith
Stef,
Ralph's non-atomic atomic loading code was used as inspiration for MC1.5's code
So could you explain the main idea? Because I remember been scared with lukas and other about the trick used and afraid it should break all the logic of the SystemChangeNotifier.
MC1.5 does contain prototypical real SystemEditor based atomic loading code which does not support traits and so is not yet enabled.
Keith
For the benchmark, try with the noAnimationForWindowClosing switched off (PreferenceBrowser, windows category). Also, try selecting the standard browser as default. I get around 7000 to 10000 depending on the ui theme used.
-----Original Message----- From: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@lists.squeakfoundation.org]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
In my M3 image, your benchmark gives 6.7 x faster than Squeak-dev. After evaluating Preferences slowMachine, it goes to 17.7 x. And it is 5Mb and 749 classes while Squeak-dev is 20Mb and 2812 classes.
It seems different people have different ideas on what a developer's image should be!
Cheers, Juan Vuletich
Andreas Raab wrote:
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
Keith
2008/4/1 Keith Hodges keith_hodges@yahoo.co.uk:
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 keith_hodges@yahoo.co.uk:
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.
Keith
2008/4/4 Keith Hodges keith_hodges@yahoo.co.uk:
Igor Stasenko wrote:
2008/4/1 Keith Hodges keith_hodges@yahoo.co.uk:
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.
You are correct. And there are can be a simple workaround. One way is to put in PackageMainClass class>>initialize calls of #privateInitizalize (or whatever) to other classes in correct order.
Keith
On a second thought i think there is still something wrong :)
An ExternalStructure class having method #doneCompiling on a class side. And it get called by ClassBuilder before ExternalStructure being properly initialized.
Here is a top of call stack:
UndefinedObject(Object)>>doesNotUnderstand: #at:ifAbsent: [] in ExternalType class>>noticeModificationOf: {[:cls | type := StructTypes at: cls name ifAbsent: []. type ifNo...]} ExternalStructure class(Behavior)>>withAllSubclassesDo: ExternalType class>>noticeModificationOf: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ExternalStructure class>>doneCompiling ClassBuilder>>name:inEnvironment:subclassOf:type:instanceVariableNames:classVariableNames:poolDictionaries:category:unsafe:
squeak-dev@lists.squeakfoundation.org
-
Andreas Raab -
Andrew Tween -
Colin Putney -
Gary Chambers -
Igor Stasenko -
Juan Vuletich -
Keith Hodges -
Matthew Fulmer -
stephane ducasse