On Mar 28, 2013, at 4:56 AM, Yanni Chiu <[email protected]> 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
