Re: [Pharo-dev] loading from github changes lgit classes?

[Denis Kudriashov]

2017-12-12 8:52 GMT+01:00 Andrei Chis :

> 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 
> wrote:
>
>>
>>
>> On 12 Dec 2017, at 04:29, Martin Dias  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 
>> 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 :
>>>
 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  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 :

> 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 :
>
>> 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)
>> 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.
>>
>>
>>
>
 



>>>
>>
>>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

> On 12 Dec 2017, at 08:52, Andrei Chis  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  > wrote:
> 
> 
>> On 12 Dec 2017, at 04:29, Martin Dias > > 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 > > 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 > >:
>> 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 >> > 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 >> >:
>>> 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 >> >:
>>> 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 
>>> ) 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.
 
 
>>> 
>>> 
>>> 
>> 
>> 
>> 
> 
> 

Re: [Pharo-dev] loading from github changes lgit classes?

[Andrei Chis]

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 
wrote:

>
>
> On 12 Dec 2017, at 04:29, Martin Dias  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 
> 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 :
>>
>>> 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  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 :
>>>
 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 :

> 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)
> 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.
>
>
>

>>> 
>>>
>>>
>>>
>>
>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

> On 12 Dec 2017, at 04:29, Martin Dias  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  > 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  >:
> 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 > > 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 > >:
>> 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 > >:
>> 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 
>> ) 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.
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

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  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  >:
> 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 > > 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 > >:
>> 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 > >:
>> 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 
>> ) 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.
>>> 
>>> 
>> 
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] loading from github changes lgit classes?

[Martin Dias]

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  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 :
>
>> 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  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 :
>>
>>> 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 :
>>>
 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)
 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.



>>>
>> 
>>
>>
>>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Nicolai Hess]

:) 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 :

> 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  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 :
>
>> 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 :
>>
>>> 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)
>>> 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.
>>>
>>>
>>>
>>
> 
>
>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Esteban Lorenzano]

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  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  >:
> 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  >:
> 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 
> ) 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.
>> 
>> 
> 
> 
> 

Re: [Pharo-dev] loading from github changes lgit classes?

[Nicolai Hess]

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 :

> 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 :
>
>> 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)
>> 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.
>>
>>
>>
>

Re: [Pharo-dev] loading from github changes lgit classes?

[Max Leske]

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) 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.