Thanks Paul - I’d forgotten about that option (been using the close all to
right option).
It’s just jarring - but worse is that none of the debuggers (even the first
one) having anything useful in them... other than the error msg in the title.
So you have to start all over again.
Still, it
Hi Tim,
Just in the event you didn't know there is an option in the World menu to
close all the open debuggers.
Its in the "Windows" section, about half way down.
Paul
Tim Mackinnon wrote
> ...
>
> On the plus side - its rare that you crash you image and then have to
> recover changes -
Also, we have found that once the problem starts the image will present bad
behavior from that on.
Sometimes it can be fixed by restarting the UIProcess, but it is a brute
force process. You have to do it many times.
It is true that we cannot assert that the bug is not in other places.
On Tue,
This is a good writeup - however I get infinite debuggers when not running
tests too? So I’m wondering if there are multiple problems - or if this hints
at a wider issue?
Its not all of the time - but when you get it it, it seems to happen over and
over again. Its possible its when using
Hello,
We have implemented a "patch" for Pharo 7, that is already integrated. I
have created a slice to backport the "patch" to Pharo6.
Basically, the previous situation is the following:
- In the normal execution everything works, the problem is during the
execution of over.
- To implement
On 08/06/2018 12:46 AM, Guillermo Polito wrote:
> Pablo and Santi have made a fix 2 fridays ago (that I presume got
> integrated last week). The fix consists on changing a bit the
> exception handling during exception handling.
>
> https://github.com/pharo-project/pharo/pull/1621/files
>
> The fix
> On 6 Aug 2018, at 09:54, Tim Mackinnon wrote:
>
> Hey thanks - this is Pharo 6.1, with a zero conf downloaded yesterday, and a
> second image from a week ago. I guess its possible that I don’t have those
> changes - is there an easy way to check?
These changes are not in Pharo 6.1 but
Hey thanks - this is Pharo 6.1, with a zero conf downloaded yesterday, and a
second image from a week ago. I guess its possible that I don’t have those
changes - is there an easy way to check?
I’m happy to try applying them - or use a different image to test with - as it
seems that certain
Hi Tim,
Are you on Pharo 6 or 7? If in 7, what build are you using?
Pablo and Santi have made a fix 2 fridays ago (that I presume got
integrated last week). The fix consists on changing a bit the exception
handling during exception handling.
Hi tim
We know and we made huge progress because before we could not even reproduce
it.
We spent some times on it. I thought the solution found by pablo and santiago
got integrated.
Stef
> Guys - this really needs attention - I’ve spend hours now trying to debug
> some code and most of it
On Fri, Jun 29, 2018 at 5:54 PM Clément Bera wrote:
> Hi,
>
> Normally the pull request should break the exception tests, especially the
> ones with nested handler, since they are the reason 199 marked signalling
> contexts were introduced
>
Yes, but it's ok that on:do: is marked but why
Hi,
Normally the pull request should break the exception tests, especially the
ones with nested handler, since they are the reason 199 marked signalling
contexts were introduced.
Looking quickly this test in latest Pharo 7 for example:
ExceptionTests>>testHandlerContext
fails with the pull
12 matches
Mail list logo
