Hi,

It looks you got bit by this issue:

https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-does-not-work-well-with-Undeclareds

It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo.

On Thu, Apr 26, 2018 at 8:44 AM, Tim Mackinnon <tim@testit.works> wrote:
That should be ���re-saved ��� it, the issue went away.


Sent from my iPhone

On 25 Apr 2018, at 23:43, Tim Mackinnon <tim@testit.works> wrote:

Hi - I think I had this issue a long while back, but I just hit it again (desperately trying to get back into Pharo again)���

I was trying out Willow - and had a method like this:

initializeContainerView

| behaviorDetails scopeSelection |

behaviorDetails := IdentifiedWebView
forDivNamed: 'behavior-details'
containing: WPPagerDutyUserDetailsView new��
applying: [ :div :constants |��
���.

Where I had a class reference to:��WPPagerDutyUserDetailsView, I deleted that class thinking I didn���t need it and then spotted the above method referenced it and so I brought it back via Epicea.

However when I ran my Willow Application, my web page was showing an error message ���Error, ObsoleteClassWPPagerDutyUserDetailsView does not implement���.��� - essentially it seemed like this method was referencing the class I had deleted and not the one I had restored.

When I went back to this method and simply reserved it, everything worked properly.

I recall Marcus (at the time) mentioning that the Opal compiler was supposed to detect these kinds of changes and rebind things properly - but it seems that this isn���t the case - or potentially restoring something from Epicea subverts this?

I can raise a bug if its genuine - but I���m just musing on this at the moment?


Tim



--

������

Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - http://www.cnrs.fr


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13