Smalltalk › Squeak › Squeak - Dev

The Trunk: System-mt.771.mcz

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

21 messages Options

commits-2

The Trunk: System-mt.771.mcz

Marcel Taeumel uploaded a new version of System to project The Trunk:
http://source.squeak.org/trunk/System-mt.771.mcz

==================== Summary ====================

Name: System-mt.771
Author: mt
Time: 17 October 2015, 6:38:55.72 pm
UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
Ancestors: System-cmm.770

Log change stamps at the granularity of seconds not only minutes.

Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.

=============== Diff against System-cmm.770 ===============

Item was changed:
----- Method: Utilities class>>changeStamp (in category 'identification') -----
changeStamp
"Answer a string to be pasted into source code to mark who changed it and when."
^ self authorInitials , ' ' , Date today mmddyyyy, ' ',
+ ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 8)!
- ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)!

Eliot Miranda-2

Re: The Trunk: System-mt.771.mcz

Hi Marcel,

> On Oct 17, 2015, at 10:47 AM, [hidden email] wrote:
>
> Marcel Taeumel uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-mt.771.mcz
>
> ==================== Summary ====================
>
> Name: System-mt.771
> Author: mt
> Time: 17 October 2015, 6:38:55.72 pm
> UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
> Ancestors: System-cmm.770
>
> Log change stamps at the granularity of seconds not only minutes.
>
> Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.

I think we should discuss this a bit further. This is all a soft touchy freely gut kind of thing for me: I don't like this change.

I think the granularity for time stamps needs to differentiate versions in different package commits. Within an image versions can be distinguished by their order in the changes file (the previous source position, can't remember what that's called and I'm on my phone). So there's no real need for fine granularity. One could also say that a second is a long time if one is auto generating methods.

I quite like being able to make several changes within the same minute because I can tell that they were related changes. With second granularity I have no chance.

Do you have a programmatic reason for wanting second granularity?

What to others think? Are there workflow implications to the granularity of time stamps? This is all very anal but, well, the changes file is all very anal anyway :-)

I

_,,,^..^,,,_ (phone)

marcel.taeumel

Re: The Trunk: System-mt.771.mcz

Hi Eliot,

actually, I would like to store the timestamp in all its details. ;-) Just like Monticello does.

In my case, I wanted to quickly find out, which version is actually loaded in the image. In my environment, I filter-out all those duplicate entries in the changes file that occur when loading an older version:

And show them like this:

Yes, you don't see seconds there, but at least the comparison is accurate now. Milliseconds would be welcome, too. :-D

So, comparing hashes of CompiledMethods provides too many false positives (samples only ~20 bytes). Comparing the full source strings is too slow... :-) ...and not necessary because the timestamps are there anyway.

Best,
Marcel

Nicolas Cellier

Re: The Trunk: System-mt.771.mcz

Personnally, I'm with Eliot, accuracy of timestamp doesn't really matter for me...

If it's from my own computer, I'll use the change log for chronology, and my immediate memory.

If it's to retrieve versions, I'll check the source code, and I do not see why the price of comparing source would be so high... Marcel do you compare thousands of versions ?

If it's from another computer, well, the chances that the clock are synchronized...

Nicolas

2015-10-19 17:16 GMT+02:00 marcel.taeumel <[hidden email]>:

Hi Eliot,

actually, I would like to store the timestamp in all its details. ;-) Just
like Monticello does.

In my case, I wanted to quickly find out, which version is actually loaded
in the image. In my environment, I filter-out all those duplicate entries in
the changes file that occur when loading an older version:

<http://forum.world.st/file/n4856499/method-versions-3.png>

And show them like this:

<http://forum.world.st/file/n4856499/method-versions-2.png>

Yes, you don't see seconds there, but at least the comparison is accurate
now. Milliseconds would be welcome, too. :-D

So, comparing hashes of CompiledMethods provides too many false positives
(samples only ~20 bytes). Comparing the full source strings is too slow...
:-) ...and not necessary because the timestamps are there anyway.

Best,
Marcel

--
View this message in context: http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4856499.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.

timrowledge

Re: The Trunk: System-mt.771.mcz

> On 19-10-2015, at 10:27 AM, Nicolas Cellier <[hidden email]> wrote:
>
> Personnally, I'm with Eliot, accuracy of timestamp doesn't really matter for me…

I kind of agree but then I also can’t see what the actual cost of having more detailed timestamps is; just a few more characters in the method description chunk.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IBLU: Ignore Basic Laws of Universe

Chris Muller-3

Re: The Trunk: System-mt.771.mcz

In reply to this post by Eliot Miranda-2

> I quite like being able to make several changes within the same minute because I can tell that they were related
> changes. With second granularity I have no chance.

Just truncate the timeStamps to whatever granularity you want to group by..

DateAndTime now asDuration truncateTo: 1 minute

> Do you have a programmatic reason for wanting second granularity?

I thought his case sounds compelling. Is there any harm to have finer
granularity?

> What to others think? Are there workflow implications to the granularity of time stamps?

marcel.taeumel

Re: The Trunk: System-mt.771.mcz

What about saving timezone information, too? Taking on Eliot's thought about code from different packages, what about someone that makes a change at PST and one at UTC? ... How to merge those at the moment?

Accurate timestamps are kind of important... :-/

Best,
Marcel

David T. Lewis

Re: The Trunk: System-mt.771.mcz

An ISO 8601 format would make sense, as long as it could be done it a way
that does not break compatibility.

Dave

> What about saving timezone information, too? Taking on Eliot's thought
> about
> code from different packages, what about someone that makes a change at
> PST
> and one at UTC? ... How to merge those at the moment?
>
> Accurate timestamps are kind of important... :-/
>
> Best,
> Marcel
>

Bert Freudenberg

Re: The Trunk: System-mt.771.mcz

In reply to this post by commits-2

On 18.10.2015, at 01:39, [hidden email] wrote:

>
> Marcel Taeumel uploaded a new version of System to project The Trunk:
> http://source.squeak.org/trunk/System-mt.771.mcz
>
> ==================== Summary ====================
>
> Name: System-mt.771
> Author: mt
> Time: 17 October 2015, 6:38:55.72 pm
> UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
> Ancestors: System-cmm.770
>
> Log change stamps at the granularity of seconds not only minutes.
>
> Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.

Why does the time stamp have to be unique? And it’s still not certain to be unique. IMHO minutes resolution is good enough and reads nicer.

> =============== Diff against System-cmm.770 ===============
>
> Item was changed:
> ----- Method: Utilities class>>changeStamp (in category 'identification') -----
> changeStamp
> "Answer a string to be pasted into source code to mark who changed it and when."
> ^ self authorInitials , ' ' , Date today mmddyyyy, ' ',
> + ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 8)!
> - ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)!

Btw we do have #print24 nowadays.

- Bert -

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: The Trunk: System-mt.771.mcz

_,,,^..^,,,_ (phone)

> On Oct 20, 2015, at 8:38 AM, Bert Freudenberg <[hidden email]> wrote:
>
>> On 18.10.2015, at 01:39, [hidden email] wrote:
>>
>> Marcel Taeumel uploaded a new version of System to project The Trunk:
>> http://source.squeak.org/trunk/System-mt.771.mcz
>>
>> ==================== Summary ====================
>>
>> Name: System-mt.771
>> Author: mt
>> Time: 17 October 2015, 6:38:55.72 pm
>> UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
>> Ancestors: System-cmm.770
>>
>> Log change stamps at the granularity of seconds not only minutes.
>>
>> Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.
>
> Why does the time stamp have to be unique? And it’s still not certain to be unique. IMHO minutes resolution is good enough and reads nicer.

+1. Marcel, if you really need this why not make it a preference, off by default.

>
>> =============== Diff against System-cmm.770 ===============
>>
>> Item was changed:
>> ----- Method: Utilities class>>changeStamp (in category 'identification') -----
>> changeStamp
>> "Answer a string to be pasted into source code to mark who changed it and when."
>> ^ self authorInitials , ' ' , Date today mmddyyyy, ' ',
>> + ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 8)!
>> - ((String streamContents: [:s | Time now print24: true on: s]) copyFrom: 1 to: 5)!
>
> Btw we do have #print24 nowadays.
>
> - Bert -
>
>
>

Chris Muller-3

Re: The Trunk: System-mt.771.mcz

On Tue, Oct 20, 2015 at 10:50 AM, Eliot Miranda <[hidden email]> wrote:

>
>
> _,,,^..^,,,_ (phone)
>
>> On Oct 20, 2015, at 8:38 AM, Bert Freudenberg <[hidden email]> wrote:
>>
>>> On 18.10.2015, at 01:39, [hidden email] wrote:
>>>
>>> Marcel Taeumel uploaded a new version of System to project The Trunk:
>>> http://source.squeak.org/trunk/System-mt.771.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: System-mt.771
>>> Author: mt
>>> Time: 17 October 2015, 6:38:55.72 pm
>>> UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
>>> Ancestors: System-cmm.770
>>>
>>> Log change stamps at the granularity of seconds not only minutes.
>>>
>>> Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.
>>
>> Why does the time stamp have to be unique? And it’s still not certain to be unique. IMHO minutes resolution is good enough and reads nicer.
>
> +1. Marcel, if you really need this why not make it a preference, off by default.

Marcel already gave compelling use-cases for why he wants
finer-grained timestamps. But that doesn't mean we have to print the
fine resolution in the browsers -- printing is independent of internal
representation, so "reads nicer" does not need to be an issue, we can
keep the same print format.

I'm failing to understand why anyone would be against more precision
internally.. You don't have to use it, it doesn't hurt anything if
its there, does it?

Bert Freudenberg

Re: The Trunk: System-mt.771.mcz

> On 20.10.2015, at 20:07, Chris Muller <[hidden email]> wrote:
>
> On Tue, Oct 20, 2015 at 10:50 AM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>> _,,,^..^,,,_ (phone)
>>
>>> On Oct 20, 2015, at 8:38 AM, Bert Freudenberg <[hidden email]> wrote:
>>>
>>>> On 18.10.2015, at 01:39, [hidden email] wrote:
>>>>
>>>> Marcel Taeumel uploaded a new version of System to project The Trunk:
>>>> http://source.squeak.org/trunk/System-mt.771.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: System-mt.771
>>>> Author: mt
>>>> Time: 17 October 2015, 6:38:55.72 pm
>>>> UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
>>>> Ancestors: System-cmm.770
>>>>
>>>> Log change stamps at the granularity of seconds not only minutes.
>>>>
>>>> Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.
>>>
>>> Why does the time stamp have to be unique? And it’s still not certain to be unique. IMHO minutes resolution is good enough and reads nicer.
>>
>> +1. Marcel, if you really need this why not make it a preference, off by default.
>
> Marcel already gave compelling use-cases for why he wants
> finer-grained timestamps.

I had missed that discussion. But I read it now and the only use case Marcel mentioned was comparing method versions, and claiming comparing time stamps was faster than comparing the source code. But AFICT both timestamps and source code are retrieved from the source file each time so the difference should not be huge. Even if it was faster then you could still compare the timestamps first and compare the source only if the times are the same.

> I'm failing to understand why anyone would be against more precision
> internally.. You don't have to use it, it doesn't hurt anything if
> its there, does it?

It makes source files even more verbose than they are now. MC’s timestamps are overkill IMHO. So without a compelling reason I would not change it. I could see good arguments for adding a timezone, but that would still not necessitate higher resolution. And after all, you cannot compare timestamps across images anyway, because you cannot rely on the clock being globally synchronized. And within a system, seconds plus order in the changes files are sufficient.

- Bert -

smime.p7s (5K) Download Attachment

Eliot Miranda-2

Re: The Trunk: System-mt.771.mcz

In reply to this post by marcel.taeumel

Hi Marcel,

On Tue, Oct 20, 2015 at 1:15 AM, marcel.taeumel <[hidden email]> wrote:

What about saving timezone information, too? Taking on Eliot's thought about
code from different packages, what about someone that makes a change at PST
and one at UTC? ... How to merge those at the moment?

This seems much more useful. I would like to see minute granularity UTC timestamps. And that reminds me I need to replace the time stuff in 5.0 with the microsecond clock support.

Accurate timestamps are kind of important... :-/

Yes, agreed. But method timestamps to second granularity? Why do you need that kind of granularity?

Best,
Marcel

--
View this message in context: http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4856686.html

Sent from the Squeak - Dev mailing list archive at Nabble.com.

_,,,^..^,,,_

best, Eliot

Eliot Miranda-2

Re: The Trunk: System-mt.771.mcz

In reply to this post by Bert Freudenberg

On Tue, Oct 20, 2015 at 12:46 PM, Bert Freudenberg <[hidden email]> wrote:

> On 20.10.2015, at 20:07, Chris Muller <[hidden email]> wrote:
>
> On Tue, Oct 20, 2015 at 10:50 AM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>> _,,,^..^,,,_ (phone)
>>
>>> On Oct 20, 2015, at 8:38 AM, Bert Freudenberg <[hidden email]> wrote:
>>>
>>>> On 18.10.2015, at 01:39, [hidden email] wrote:
>>>>
>>>> Marcel Taeumel uploaded a new version of System to project The Trunk:
>>>> http://source.squeak.org/trunk/System-mt.771.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: System-mt.771
>>>> Author: mt
>>>> Time: 17 October 2015, 6:38:55.72 pm
>>>> UUID: 4aee8d76-cfcf-ad48-ae3e-6d971ce6fea9
>>>> Ancestors: System-cmm.770
>>>>
>>>> Log change stamps at the granularity of seconds not only minutes.
>>>>
>>>> Why? A minute is quite long and it is likely to have two method (versions) with the same timestamp.
>>>
>>> Why does the time stamp have to be unique? And it’s still not certain to be unique. IMHO minutes resolution is good enough and reads nicer.
>>
>> +1. Marcel, if you really need this why not make it a preference, off by default.
>
> Marcel already gave compelling use-cases for why he wants
> finer-grained timestamps.

I had missed that discussion. But I read it now and the only use case Marcel mentioned was comparing method versions, and claiming comparing time stamps was faster than comparing the source code. But AFICT both timestamps and source code are retrieved from the source file each time so the difference should not be huge. Even if it was faster then you could still compare the timestamps first and compare the source only if the times are the same.

+1. Bert is right. One has to go to the file for either.

> I'm failing to understand why anyone would be against more precision
> internally.. You don't have to use it, it doesn't hurt anything if
> its there, does it?

It makes source files even more verbose than they are now. MC’s timestamps are overkill IMHO. So without a compelling reason I would not change it. I could see good arguments for adding a timezone, but that would still not necessitate higher resolution. And after all, you cannot compare timestamps across images anyway, because you cannot rely on the clock being globally synchronized. And within a system, seconds plus order in the changes files are sufficient.

- Bert -

_,,,^..^,,,_

best, Eliot

Chris Muller-3

Re: The Trunk: System-mt.771.mcz

In reply to this post by Eliot Miranda-2

>> What about saving timezone information, too? Taking on Eliot's thought
>> about
>> code from different packages, what about someone that makes a change at
>> PST
>> and one at UTC? ... How to merge those at the moment?

I see no problem merging those at the moment..? Merging does not
account for timestamps, only differences. With a method conflict,
timezone would not be useful to resolve a method level conflict..

> This seems much more useful. I would like to see minute granularity UTC
> timestamps.

Why useful? I'm not opposed, just curious if, by the end of the day,
would we really ever consume it?

Just an opportunity to have a more precise model at very little cost?

Bert Freudenberg

Re: The Trunk: System-mt.771.mcz

On 21.10.2015, at 02:46, Chris Muller <[hidden email]> wrote:
>
>> This seems much more useful. I would like to see minute granularity UTC
>> timestamps.
>
> Why useful? I'm not opposed, just curious if, by the end of the day,
> would we really ever consume it?
>
> Just an opportunity to have a more precise model at very little cost?

IMHO having the timezone information is interesting. (I’d store local+tz, and derive UTC from that if needed)

Having second-precision information about when exactly someone accepted a method is not interesting.

- Bert -

smime.p7s (5K) Download Attachment

marcel.taeumel

Re: The Trunk: System-mt.771.mcz

In my system, comparing stamp strings is about 100 times faster than comparing sources to detect the current version of code in the image. (~6,000,000 vs. ~60,000 per second)

Considering the fact that stamps may be duplicate requires just 1 additional LOC:

versions detect: [:v | v stamp = current stamp
and: [v source = current source].

...or none if you format differently. ;)

I have 80,000 methods in my system. Adding 3 bytes/characters to each stamp would require an additional ~235 kB in the changes/sources file, which is about 0.007% of our 5.0 sources file. For example, adding 10 versions to *each* method would require additional 2 megs. However, 800,000 method changes are quite a lot.

Hmm... printing the full timestamp would make that #copyFrom:to: call in Utilities >> #changeStamp obsolete. :-D

*~*~*~*~*

Whatever. I like to avoid that 1 LOC. I like to speed-up such detection/sorting algorithm if the actual problem size will be somewhat unknown in the (near) future.

But time zones would be nice. :)

Best,
Marcel

Ben Coman

Re: The Trunk: System-mt.771.mcz

In reply to this post by Eliot Miranda-2

On Wed, Oct 21, 2015 at 5:38 AM, Eliot Miranda <[hidden email]> wrote:

> Hi Marcel,
>
> On Tue, Oct 20, 2015 at 1:15 AM, marcel.taeumel <[hidden email]>
> wrote:
>>
>> What about saving timezone information, too? Taking on Eliot's thought
>> about
>> code from different packages, what about someone that makes a change at
>> PST
>> and one at UTC? ... How to merge those at the moment?
>
>
> This seems much more useful. I would like to see minute granularity UTC
> timestamps. And that reminds me I need to replace the time stuff in 5.0
> with the microsecond clock support.

Are you talking about Delay? Would you like me to push my microsecond
DelayScheduler introduced in Pharo? (but I still had a bit more I
wanted to clean in Pharo.)
cheers -ben

>> Accurate timestamps are kind of important... :-/
>
>
> Yes, agreed. But method timestamps to second granularity? Why do you need
> that kind of granularity?
>
>>
>>
>> Best,
>> Marcel
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4856686.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>

Eliot Miranda-2

Re: The Trunk: System-mt.771.mcz

Hi Ben,

On Wed, Oct 21, 2015 at 7:19 AM, Ben Coman <[hidden email]> wrote:

On Wed, Oct 21, 2015 at 5:38 AM, Eliot Miranda <[hidden email]> wrote:
> Hi Marcel,
>
> On Tue, Oct 20, 2015 at 1:15 AM, marcel.taeumel <[hidden email]>
> wrote:
>>
>> What about saving timezone information, too? Taking on Eliot's thought
>> about
>> code from different packages, what about someone that makes a change at
>> PST
>> and one at UTC? ... How to merge those at the moment?
>
>
> This seems much more useful. I would like to see minute granularity UTC
> timestamps. And that reminds me I need to replace the time stuff in 5.0
> with the microsecond clock support.

Are you talking about Delay? Would you like me to push my microsecond
DelayScheduler introduced in Pharo? (but I still had a bit more I
wanted to clean in Pharo.)

Not juest Delay, but deriving all time from the microsecond clock primitives, and eliminating the code for the now unnecessary overflow/wraparound of the millisecond clock. So yes please. I also made changes at Cadence that mean one can profile across a snapshot and hence profile start-up and shut-down activities. I'll integrate this after you integrate the microsecond clock basis.

cheers -ben

>> Accurate timestamps are kind of important... :-/
>
>
> Yes, agreed. But method timestamps to second granularity? Why do you need
> that kind of granularity?
>
>>
>>
>> Best,
>> Marcel
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4856686.html
>> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>
>

_,,,^..^,,,_

best, Eliot

Levente Uzonyi-2

Re: The Trunk: System-mt.771.mcz

The primitive names are different in Squeak and Pharo, so care must be
taken to not break stuff during the integration.
Also, some methods, like #millisecondClockValue, have some special
semantics which should be preserved.

Levente

On Wed, 21 Oct 2015, Eliot Miranda wrote:

> Hi Ben,
> On Wed, Oct 21, 2015 at 7:19 AM, Ben Coman <[hidden email]> wrote:
> On Wed, Oct 21, 2015 at 5:38 AM, Eliot Miranda <[hidden email]> wrote:
> > Hi Marcel,
> >
> > On Tue, Oct 20, 2015 at 1:15 AM, marcel.taeumel <[hidden email]>
> > wrote:
> >>
> >> What about saving timezone information, too? Taking on Eliot's thought
> >> about
> >> code from different packages, what about someone that makes a change at
> >> PST
> >> and one at UTC? ... How to merge those at the moment?
> >
> >
> > This seems much more useful. I would like to see minute granularity UTC
> > timestamps. And that reminds me I need to replace the time stuff in 5.0
> > with the microsecond clock support.
>
> Are you talking about Delay? Would you like me to push my microsecond
> DelayScheduler introduced in Pharo? (but I still had a bit more I
> wanted to clean in Pharo.)
>
>
> Not juest Delay, but deriving all time from the microsecond clock primitives, and eliminating the code for the now unnecessary overflow/wraparound
> of the millisecond clock. So yes please. I also made changes at Cadence that mean one can profile across a snapshot and hence profile start-up
> and shut-down activities. I'll integrate this after you integrate the microsecond clock basis.
>
> cheers -ben
>
> >> Accurate timestamps are kind of important... :-/
> >
> >
> > Yes, agreed. But method timestamps to second granularity? Why do you need
> > that kind of granularity?
> >
> >>
> >>
> >> Best,
> >> Marcel
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >> http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4856686.html
> >> Sent from the Squeak - Dev mailing list archive at Nabble.com.
> >>
> >
> >
> >
> > --
> > _,,,^..^,,,_
> > best, Eliot
> >
> >
> >
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
>