On 18 nov. 08, at 22:02, Marcus Denker wrote:
On 18.11.2008, at 18:25, Igor Stasenko wrote:
2008/11/18 Marcus Denker <[EMAIL PROTECTED]>:
On 18.11.2008, at 17:11, Simon Denier wrote:
If I dowload the latest 10156 image, do a ScriptLoader loadOB,
save it as
new image, quit and then relaunch the new image, my new image is
unusable
because almost unresponsive: something is eating 100% CPU time.
- problem is the same if I upgrade to 10157
- however there seems to be no problem if I just continue to work
in the
image without quitting.
It's a weird behaviour.
Yes, I will undo some process related changes... maybe removing
Process from
the specialObjectsArray was a dunb idea ;-)
I will put it back in.
Don't be so haste :)
:-)
I nevertheless did a 10158 which has the Process again in the
special objects array.
(This way people get a warning if they want to change the layout of
the class).
I still got this behavior after updating to 10159.
Perhaps this is not related to special objects after all.
Then this is more related to OB, since it only happens with images
where loadOB has been performed.
I'd rather try to reproduce the problem and find solution.
good!
a 100% cpu hog at startup time could be a problem with Delays, or
different semaphores which has dropped during #clearExternalObjects
but not correctly reinstantiated again at following startup phase.
I thin this one is *not* related (negative results are results,
too ;-))
Issue 232: Recreate Special Objects Array should preserve external
semaphores + Fix
Marcus
--
Marcus Denker -- [EMAIL PROTECTED]
http://www.iam.unibe.ch/~denker
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
Simon
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
