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 <nicolaihess@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 <nicolaihess@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 <maxleske@gmail.com>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess (nicolaihess@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>