On Mar 28, 2013, at 4:56 AM, Yanni Chiu <yanni@rogers.com> wrote:
I had noticed that package loading seemed extremely slow, but did not look further into it. I think I saw mention that it's due to some usage of #become:, during the compiling of code. Based on build times (of just loading the rough equivalent code), it seems about 3 times slower to do a build on a Pharo-2.0 vs. Pharo-1.4.
Yes, this is known and we should analyze it⦠one thing we need to get rid of os the #become: when updating the source pointer. There seems to be something slow with announcing changes, too.
Another thing I've noticed is occasional sluggishness in the UI. It's hard to pinpoint, I often feel like my clicks are being lost.
I have not seen that one.
The behaviour of the TestRunner was odd. Eventually I discovered running tests via the Nautilus browser, but the UI feedback is extremely confusing for "abstract" test cases. I still don't quite understand the results I see there, so I do a final run of the tests in the TestRunner.
Odd in which sense? related to the progress bar?
Another strange issue I had with test cases was to do with the interaction of the deprecation warnings. In by build script, I run: Deprecation raiseWarning: false. Deprecation showWarning: false. so the build can run headless. It took me a few hours, and a careful single stepping, to find that the deprecation exceptions were being swallowed. I'm sure the TestRunner did not behave this way before. If you ran a test, you would still see the deprecation exceptions. It was really frustrating to see your test fail, but have the stack cleared out before you could debug the exception that caused the test failure.
Can you add a bug tracker entry for that one? Marcus