> On 12 Dec 2017, at 08:52, Andrei Chis <[email protected]> wrote: > > 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?
it should not. and even if that’s the case, you do not need to regenerate accessors: executing #compileFields instead #rebuildFieldAccessors should solve any initialisation problems without actually regenerate all structures, which is what you are doing :) Esteban > > Cheers, > Andrei > > On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <[email protected] > <mailto:[email protected]>> wrote: > > >> On 12 Dec 2017, at 04:29, Martin Dias <[email protected] >> <mailto:[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] >> <mailto:[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] >> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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] >>> <mailto:[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> >> >> >> > >
