2017-12-12 8:52 GMT+01:00 Andrei Chis <[email protected]>: > I think this was added because on windows if we did not rebuild accessors, > some offsets were nil in external structures. Can that still be an issue? >
Not only Windows. Problem was in Pharo 6 where external OSWindow not worked because of nil offsets. And Bloc solved it by manual initialisation after loading code. > > Cheers, > Andrei > > On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <[email protected]> > wrote: > >> >> >> On 12 Dec 2017, at 04:29, Martin Dias <[email protected]> wrote: >> >> Should the rebuild changes be logged? >> Maybe we can have EpMonitor suspendDuring: […] >> >> >> no they not. >> what should be suspended is field regeneration on bloc config ;) >> >> Esteban >> >> >> Martín >> >> On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <[email protected]> >> wrote: >> >>> :) This looks interesting: >>> >>> So, postload of bloc and some classes (MozEnum, SpartaCairoEnum) doing a >>> rebuild with this author. >>> >>> 2017-12-11 22:27 GMT+01:00 Esteban Lorenzano <[email protected]>: >>> >>>> honestly, this should not be happening. >>>> Now, I have no idea why it is happening at all ;) >>>> >>>> I mean, there is no automatic process that would have a UFFI name there >>>> (the only place where this can happen is on #rebuildFieldAccessors and that >>>> will use an UFFIGenerator author, not just UFFI. >>>> And also that method needs to be executed by hand… >>>> >>>> weird… can you search for UFFI in system? >>>> >>>> Esteban >>>> >>>> On 11 Dec 2017, at 22:00, Nicolai Hess <[email protected]> wrote: >>>> >>>> It happens not only from lgit-classes but from other FFI-Subclasses >>>> too, for example AthensCairoMatrix. >>>> >>>> And some methods have a strange version history (see screenshot). >>>> The timestamp of all of the UFFI changes are during loading gtoolkit. >>>> Maybe during loading we have multiple reinitializations that will >>>> recreate autogenerated methods, again and again ? >>>> >>>> 2017-12-11 21:49 GMT+01:00 Nicolai Hess <[email protected]>: >>>> >>>>> But these aren't method changes. >>>>> The class definition is changed. (see screenshot) >>>>> It looks like it adds new class variables, even though they were >>>>> alreday in the original fresh image. >>>>> >>>>> >>>>> 2017-12-11 13:49 GMT+01:00 Max Leske <[email protected]>: >>>>> >>>>>> Without taking a closer look, those are probably auto generated >>>>>> methods. >>>>>> >>>>>> Max >>>>>> >>>>>> >>>>>> >>>>>> On 10 December 2017 at 12:13:08, Nicolai Hess ([email protected]) >>>>>> wrote: >>>>>> >>>>>> How come, loading a github project writes strange code change entries >>>>>> for classes >>>>>> like >>>>>> LGitFetchOptions >>>>>> LGitRemoteCallbacks >>>>>> ... >>>>>> >>>>>> For example, in a Pharo 6.1 image I load bloc like this: >>>>>> >>>>>> Metacello new >>>>>> baseline: 'Bloc'; >>>>>> repository: 'github://pharo-graphics/Bloc:pharo6.1/src'; >>>>>> load: #core >>>>>> >>>>>> In my Epicea code change window I see this entries (see screenshot). >>>>>> And the final "new" version of this classes, (class definitions) just >>>>>> look like the >>>>>> original class definition in a fresh image. >>>>>> >>>>>> >>>>>> >>>>> >>>> <PharoScreenshot.1.png> >>>> >>>> >>>> >>> >> >> >
