Smalltalk › Pharo › Pharo Smalltalk Developers

loading from github changes lgit classes?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

12 messages Options

Nicolai Hess-3-2

loading from github changes lgit classes?

How come, loading a github project writes strange code change entries for classes

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.png (288K) Download Attachment

Max Leske

Re: loading from github changes lgit classes?

Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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.

Nicolai Hess-3-2

Re: loading from github changes lgit classes?

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 <[hidden email]>:

Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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.png (164K) Download Attachment

Nicolai Hess-3-2

Re: loading from github changes lgit classes?

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 <[hidden email]>:

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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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 (100K) Download Attachment

EstebanLM

Re: loading from github changes lgit classes?

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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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: '<a href="github://pharo-graphics/Bloc:" class="">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>

Nicolai Hess-3-2

Re: loading from github changes lgit classes?

:) 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 <[hidden email]>:

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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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>

PharoScreenshot.3.png (102K) Download Attachment

tinchodias

Re: loading from github changes lgit classes?

Should the rebuild changes be logged?

Maybe we can have EpMonitor suspendDuring: [...]

Martín

On Mon, Dec 11, 2017 at 6:42 PM, Nicolai Hess <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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>

EstebanLM

Re: loading from github changes lgit classes?

In reply to this post by Nicolai Hess-3-2

this is a problem on Bloc configuration: unlike NativeBoost, UFFI fields accessors do NOT need to be regenerated each time, so that chunk of code is incorrect.

Esteban

On 11 Dec 2017, at 22:42, Nicolai Hess <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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>

<PharoScreenshot.3.png>

EstebanLM

Re: loading from github changes lgit classes?

In reply to this post by tinchodias

On 12 Dec 2017, at 04:29, Martin Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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>

Andrei Chis

Re: loading from github changes lgit classes?

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?

Cheers,

Andrei

On Tue, Dec 12, 2017 at 7:39 AM, Esteban Lorenzano <[hidden email]> wrote:

On 12 Dec 2017, at 04:29, Martin Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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>

EstebanLM

Re: loading from github changes lgit classes?

On 12 Dec 2017, at 08:52, Andrei Chis <[hidden email]> 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 <[hidden email]> wrote:

On 12 Dec 2017, at 04:29, Martin Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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>

Denis Kudriashov

Re: loading from github changes lgit classes?

In reply to this post by Andrei Chis

2017-12-12 8:52 GMT+01:00 Andrei Chis <[hidden email]>:

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 <[hidden email]> wrote:

On 12 Dec 2017, at 04:29, Martin Dias <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]>:
Without taking a closer look, those are probably auto generated methods.

Max

On 10 December 2017 at 12:13:08, Nicolai Hess ([hidden email]) 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>