No Metadata in 7.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

No Metadata in 7.0

Henrik-Nergaard

Hi,

I had a look at the Pharo 7.0 today and see metadata for methods (Author and timestamp) has been removed*, what is the reason for this?

Having the ability to find methods created around the same time and/or by author is quite useful when fixing bugs in the core libraries.

There is also quite a lot of history that is lost as well with this change (I am always impressed when I stumble upon methods over 15-20 years old!).

 

Could this be reverted, please?

[*] all methods have a stamp, but it is the same for all with only a timestamp from the bootstrap(?).

 

Best regards,

Henrik


Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

alistairgrant
Hi Henrik,

On Sun, Jul 09, 2017 at 08:10:28PM +0000, Henrik Nergaard wrote:

> Hi,
>
> I had a look at the Pharo 7.0 today and see metadata for methods (Author and
> timestamp) has been removed*, what is the reason for this?
>
> Having the ability to find methods created around the same time and/or by
> author is quite useful when fixing bugs in the core libraries.
>
> There is also quite a lot of history that is lost as well with this change (I
> am always impressed when I stumble upon methods over 15-20 years old!).
>
> Could this be reverted, please?
>
> [*] all methods have a stamp, but it is the same for all with only a timestamp
> from the bootstrap(?).
>
> Best regards,
>
> Henrik

I think this is answered in:

http://forum.world.st/Pharo-7-Method-Version-Browser-does-not-include-author-name-tp4952906p4952912.html

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

Guillermo Polito
In reply to this post by Henrik-Nergaard


On Sun, Jul 9, 2017 at 10:10 PM, Henrik Nergaard <[hidden email]> wrote:

Hi,

I had a look at the Pharo 7.0 today and see metadata for methods (Author and timestamp) has been removed*, what is the reason for this?

Having the ability to find methods created around the same time and/or by author is quite useful when fixing bugs in the core libraries.

There is also quite a lot of history that is lost as well with this change (I am always impressed when I stumble upon methods over 15-20 years old!).

 

Could this be reverted, please?

[*] all methods have a stamp, but it is the same for all with only a timestamp from the bootstrap(?).


Hi Henrik,

I'm sorry about that, it's probably a side effect of the bootstrap. We may have to track down the cause, so if you can help, it's most welcome :). For that I can explain you the process as it is today:

 1st) We previously exported all code from Pharo to FileTree (Metadataless I think). This step is not done anymore.
 2nd) We bootstrap from the packages on FileTree by first compiling methods without metadata.

 3rd) We export all bootstrap packages from filetree to MCZ


 4th) Once the first image is ready (without source code nor meta-data) we install monticello and we reload all mcz files
        This regenerates the source code and should load all metadata in mczs


So either it is that the metadata is lost in Filetree because it is metadataless, or it is lost in the intermediate conversion to mcz, or in the loading.

Guille
 

 

Best regards,

Henrik





--

   

Guille Polito


Research Engineer

French National Center for Scientific Research - http://www.cnrs.fr



Web: http://guillep.github.io

Phone: +33 06 52 70 66 13

Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

Pavel Krivanek-3
The metadata are lost because of the metadata-less FileTree format. In FileTree the method metadata are not stored in the method file but in a class specific file. All methods metadata in one file. If you use FileTree with metadata, it causes a lot of needless changes and conflicts.

So we have no methods metadata because the repository does not contain them.

However the real question is if we need them in the form we had them until now because they are flattened as soon as a new changes file (release) is created and it stores only information about the last person who touched the method, not about the author nor wider history.

What we need to do is to export older versions to the Pharo Git repository and take method history information from the VCS. Do not try to duplicate VCS behavior with the changes file because the purpose of changes file is different. 

Cheers,
-- Pavel




2017-07-10 10:15 GMT+02:00 Guillermo Polito <[hidden email]>:


On Sun, Jul 9, 2017 at 10:10 PM, Henrik Nergaard <[hidden email]> wrote:

Hi,

I had a look at the Pharo 7.0 today and see metadata for methods (Author and timestamp) has been removed*, what is the reason for this?

Having the ability to find methods created around the same time and/or by author is quite useful when fixing bugs in the core libraries.

There is also quite a lot of history that is lost as well with this change (I am always impressed when I stumble upon methods over 15-20 years old!).

 

Could this be reverted, please?

[*] all methods have a stamp, but it is the same for all with only a timestamp from the bootstrap(?).


Hi Henrik,

I'm sorry about that, it's probably a side effect of the bootstrap. We may have to track down the cause, so if you can help, it's most welcome :). For that I can explain you the process as it is today:

 1st) We previously exported all code from Pharo to FileTree (Metadataless I think). This step is not done anymore.
 2nd) We bootstrap from the packages on FileTree by first compiling methods without metadata.

 3rd) We export all bootstrap packages from filetree to MCZ


 4th) Once the first image is ready (without source code nor meta-data) we install monticello and we reload all mcz files
        This regenerates the source code and should load all metadata in mczs


So either it is that the metadata is lost in Filetree because it is metadataless, or it is lost in the intermediate conversion to mcz, or in the loading.

Guille
 

 

Best regards,

Henrik





--

   

Guille Polito


Research Engineer

French National Center for Scientific Research - http://www.cnrs.fr



Web: http://guillep.github.io

Phone: <a href="tel:+33%206%2052%2070%2066%2013" value="+33652706613" target="_blank">+33 06 52 70 66 13


Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

Nicolai Hess-3-2


2017-07-10 10:31 GMT+02:00 Pavel Krivanek <[hidden email]>:


However the real question is if we need them in the form we had them until now because they are flattened as soon as a new changes file (release) is created and it stores only information about the last person who touched the method, not about the author nor wider history.

For me, YES!
I always take this data as a hint to track down bugs. Especially in this community were different people do bug fixes or introduce something new /change something,
it is really helpfull and valueable to track this changes by the method history. (not only *who* did the change, but also, in what context, what else had changed.
And I think it is much easier to do this from within the image instead of looking at the git diff).

That hte history is already lost when we created a new changes/sources for release is something that always disturbed me. And I hoped there would be some
way to reload the "real" history with all intermediate changes.

 





2017-07-10 10:15 GMT+02:00 Guillermo Polito <[hidden email]>:


On Sun, Jul 9, 2017 at 10:10 PM, Henrik Nergaard <[hidden email]> wrote:

Hi,

I had a look at the Pharo 7.0 today and see metadata for methods (Author and timestamp) has been removed*, what is the reason for this?

Having the ability to find methods created around the same time and/or by author is quite useful when fixing bugs in the core libraries.

There is also quite a lot of history that is lost as well with this change (I am always impressed when I stumble upon methods over 15-20 years old!).

 

Could this be reverted, please?

[*] all methods have a stamp, but it is the same for all with only a timestamp from the bootstrap(?).


Hi Henrik,

I'm sorry about that, it's probably a side effect of the bootstrap. We may have to track down the cause, so if you can help, it's most welcome :). For that I can explain you the process as it is today:

 1st) We previously exported all code from Pharo to FileTree (Metadataless I think). This step is not done anymore.
 2nd) We bootstrap from the packages on FileTree by first compiling methods without metadata.

 3rd) We export all bootstrap packages from filetree to MCZ


 4th) Once the first image is ready (without source code nor meta-data) we install monticello and we reload all mcz files
        This regenerates the source code and should load all metadata in mczs


So either it is that the metadata is lost in Filetree because it is metadataless, or it is lost in the intermediate conversion to mcz, or in the loading.

Guille
 

 

Best regards,

Henrik





--

   

Guille Polito


Research Engineer

French National Center for Scientific Research - http://www.cnrs.fr



Web: http://guillep.github.io

Phone: <a target="_blank" value="+33652706613" href="tel:+33%206%2052%2070%2066%2013">+33 06 52 70 66 13



Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

alistairgrant
On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote:

>
> 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <[hidden email]>:
>
>     However the real question is if we need them in the form we had them until
>     now because they are flattened as soon as a new changes file (release) is
>     created and it stores only information about the last person who touched
>     the method, not about the author nor wider history.
>
> For me, YES!
>
> I always take this data as a hint to track down bugs. Especially in
> this community were different people do bug fixes or introduce
> something new /change something, it is really helpfull and valueable
> to track this changes by the method history. (not only *who* did the
> change, but also, in what context, what else had changed.  And I think
> it is much easier to do this from within the image instead of looking
> at the git diff).

Are the two really mutually exclusive?  Given the move to Iceberg
wouldn't it make sense to extend Iceberg to be able to analyse the git
history from within the image?


> That hte history is already lost when we created a new changes/sources
> for release is something that always disturbed me. And I hoped there
> would be some way to reload the "real" history with all intermediate
> changes.

Cheers,
Alistair


Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

Nicolai Hess-3-2


2017-07-10 11:22 GMT+02:00 Alistair Grant <[hidden email]>:
On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote:
>
> 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <[hidden email]>:
>
>     However the real question is if we need them in the form we had them until
>     now because they are flattened as soon as a new changes file (release) is
>     created and it stores only information about the last person who touched
>     the method, not about the author nor wider history.
>
> For me, YES!
>
> I always take this data as a hint to track down bugs. Especially in
> this community were different people do bug fixes or introduce
> something new /change something, it is really helpfull and valueable
> to track this changes by the method history. (not only *who* did the
> change, but also, in what context, what else had changed.  And I think
> it is much easier to do this from within the image instead of looking
> at the git diff).

Are the two really mutually exclusive?  Given the move to Iceberg
wouldn't it make sense to extend Iceberg to be able to analyse the git
history from within the image?


No, they are not mutually exclusive, it is just that you can not see the history now.
Maybe iceberg will solve this, but for now you can not see the history
 (and as a windows user, I can not even use iceberg).

 


> That hte history is already lost when we created a new changes/sources
> for release is something that always disturbed me. And I hoped there
> would be some way to reload the "real" history with all intermediate
> changes.

Cheers,
Alistair



Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

Pavel Krivanek-3

2017-07-10 11:32 GMT+02:00 Nicolai Hess <[hidden email]>:


2017-07-10 11:22 GMT+02:00 Alistair Grant <[hidden email]>:
On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote:
>
> 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <[hidden email]>:
>
>     However the real question is if we need them in the form we had them until
>     now because they are flattened as soon as a new changes file (release) is
>     created and it stores only information about the last person who touched
>     the method, not about the author nor wider history.
>
> For me, YES!
>
> I always take this data as a hint to track down bugs. Especially in
> this community were different people do bug fixes or introduce
> something new /change something, it is really helpfull and valueable
> to track this changes by the method history. (not only *who* did the
> change, but also, in what context, what else had changed.  And I think
> it is much easier to do this from within the image instead of looking
> at the git diff).

Are the two really mutually exclusive?  Given the move to Iceberg
wouldn't it make sense to extend Iceberg to be able to analyse the git
history from within the image?


No, they are not mutually exclusive, it is just that you can not see the history now.
Maybe iceberg will solve this, but for now you can not see the history
 (and as a windows user, I can not even use iceberg).

 


> That hte history is already lost when we created a new changes/sources
> for release is something that always disturbed me. And I hoped there
> would be some way to reload the "real" history with all intermediate
> changes.

Cheers,
Alistair




Reply | Threaded
Open this post in threaded view
|

Re: No Metadata in 7.0

Stephane Ducasse-3
In reply to this post by Nicolai Hess-3-2
Hi nicolai

we should really fix that. I know that it is painful because we got
out our confort zone.
I really hope that we will be able to do something better. Now what we
should do is incrementally
rebuild a better system.
About the git support on windows. I thought it was working what is the
problem on your side?


Stef

On Mon, Jul 10, 2017 at 11:32 AM, Nicolai Hess <[hidden email]> wrote:

>
>
> 2017-07-10 11:22 GMT+02:00 Alistair Grant <[hidden email]>:
>>
>> On Mon, Jul 10, 2017 at 11:15:27AM +0200, Nicolai Hess wrote:
>> >
>> > 2017-07-10 10:31 GMT+02:00 Pavel Krivanek <[hidden email]>:
>> >
>> >     However the real question is if we need them in the form we had them
>> > until
>> >     now because they are flattened as soon as a new changes file
>> > (release) is
>> >     created and it stores only information about the last person who
>> > touched
>> >     the method, not about the author nor wider history.
>> >
>> > For me, YES!
>> >
>> > I always take this data as a hint to track down bugs. Especially in
>> > this community were different people do bug fixes or introduce
>> > something new /change something, it is really helpfull and valueable
>> > to track this changes by the method history. (not only *who* did the
>> > change, but also, in what context, what else had changed.  And I think
>> > it is much easier to do this from within the image instead of looking
>> > at the git diff).
>>
>> Are the two really mutually exclusive?  Given the move to Iceberg
>> wouldn't it make sense to extend Iceberg to be able to analyse the git
>> history from within the image?
>
>
>
> No, they are not mutually exclusive, it is just that you can not see the
> history now.
> Maybe iceberg will solve this, but for now you can not see the history
>  (and as a windows user, I can not even use iceberg).
>
>
>>
>>
>>
>> > That hte history is already lost when we created a new changes/sources
>> > for release is something that always disturbed me. And I hoped there
>> > would be some way to reload the "real" history with all intermediate
>> > changes.
>>
>> Cheers,
>> Alistair
>>
>>
>