Well, yes to both. Now, about the performance, first I'd like to have a benchmark suite that runs all the time, to at least understand if we lose some performance, when/why was it. Of course, this would have an impact depending on how often are globals read/written. But I'd like to know with more certainty.
Also [SystemNavigation new isUsedClass: IceRepository] bench => '172.497 per second' So maybe we can pay the price of a couple of milliseconds every time we remove a class for the moment. I prefer a "bit slower" system that is more robust :) Also, how often do we remove classes? I don't think this is critical, and the robustness here pays for itself :) We can think about how to optimize it later. Guille On Wed, May 2, 2018 at 2:20 PM, teso...@gmail.com <teso...@gmail.com> wrote: > Two points. > > 1. Maybe we should centralize the removal of a class in a component as the > class installer. So we can have it all in one place, and if we need to > override and do fancy stuff. > 2. Yes to the messages to the environment, I am doing so to have multiple > environments sharing the same methods. We can check how much does it affect > the performance, because it opens a lot of different options to extend the > language. > > Cheers, > Pablo > > On Wed, May 2, 2018 at 2:09 PM, Marcus Denker <marcus.den...@inria.fr> > wrote: > >> >> >> > On 26 Apr 2018, at 09:28, Guillermo Polito <guillermopol...@gmail.com> >> wrote: >> > >> > Hi, >> > >> > It looks you got bit by this issue: >> > >> > https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-doe >> s-not-work-well-with-Undeclareds >> > >> > It's not particular to Epicea. There should be a better management of >> Undeclareds in general in all Pharo. >> > >> >> It can be fixed by moving the binding to undeclared in #removeFromSystem: >> >> This is done by adding >> >> Undeclared declare: self name asSymbol from: Smalltalk globals. >> >> before the "forgetClass: self logged:" line. >> >> What we need to do in addition: Only do that when the class is >> referenced. #isUsedClass: does that, but it does integrate over all methods >> in the system. >> >> (I sometimes wonder if we should not late-bind accesses to globals, that >> is, just compile them as message sends to the environment). >> >> Marcus >> >> >> > > > -- > Pablo Tesone. > teso...@gmail.com > -- 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
