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 <nicolaih...@gmail.com> 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 <nicolaih...@gmail.com > <mailto:nicolaih...@gmail.com>>: > 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 <maxle...@gmail.com > <mailto:maxle...@gmail.com>>: > Without taking a closer look, those are probably auto generated methods. > > Max > > > > On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaih...@gmail.com > <mailto:nicolaih...@gmail.com>) 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>
