Discussion:
The Trunk: System-mt.771.mcz
(too old to reply)
c***@source.squeak.org
0000-10-21 22:29:36 UTC
Permalink
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
2015-10-19 13:07:25 UTC
Permalink
Hi Marcel,
Post by c***@source.squeak.org
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
2015-10-19 15:16:39 UTC
Permalink
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:

<Loading Image...>

And show them like this:

<Loading Image...>

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.
Nicolas Cellier
2015-10-19 17:27:11 UTC
Permalink
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
Post by marcel.taeumel
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
<http://forum.world.st/file/n4856499/method-versions-3.png>
<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
--
http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4856499.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
tim Rowledge
2015-10-19 17:34:45 UTC
Permalink
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; ***@rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: IBLU: Ignore Basic Laws of Universe
Chris Muller
2015-10-19 18:34:46 UTC
Permalink
Post by Eliot Miranda
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
Post by Eliot Miranda
Do you have a programmatic reason for wanting second granularity?
I thought his case sounds compelling. Is there any harm to have finer
granularity?
Post by Eliot Miranda
What to others think? Are there workflow implications to the granularity of time stamps?
marcel.taeumel
2015-10-20 08:15:19 UTC
Permalink
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



--
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.
David T. Lewis
2015-10-20 15:03:05 UTC
Permalink
An ISO 8601 format would make sense, as long as it could be done it a way
that does not break compatibility.

Dave
Post by marcel.taeumel
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
Eliot Miranda
2015-10-20 21:38:25 UTC
Permalink
Hi Marcel,
Post by marcel.taeumel
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.
Post by marcel.taeumel
Accurate timestamps are kind of important... :-/
Yes, agreed. But method timestamps to second granularity? Why do you need
that kind of granularity?
Post by marcel.taeumel
Best,
Marcel
--
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
Chris Muller
2015-10-21 00:46:55 UTC
Permalink
Post by Eliot Miranda
Post by marcel.taeumel
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..
Post by Eliot Miranda
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
2015-10-21 11:09:20 UTC
Permalink
Post by Chris Muller
Post by Eliot Miranda
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 -
marcel.taeumel
2015-10-21 12:47:33 UTC
Permalink
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



--
View this message in context: http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4857077.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.
Ben Coman
2015-10-21 14:19:52 UTC
Permalink
Post by Eliot Miranda
Hi Marcel,
Post by marcel.taeumel
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
Post by Eliot Miranda
Post by marcel.taeumel
Accurate timestamps are kind of important... :-/
Yes, agreed. But method timestamps to second granularity? Why do you need
that kind of granularity?
Post by marcel.taeumel
Best,
Marcel
--
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
2015-10-21 18:19:54 UTC
Permalink
Hi Ben,
Post by Ben Coman
Post by Eliot Miranda
Hi Marcel,
Post by marcel.taeumel
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.
Post by Ben Coman
cheers -ben
Post by Eliot Miranda
Post by marcel.taeumel
Accurate timestamps are kind of important... :-/
Yes, agreed. But method timestamps to second granularity? Why do you
need
Post by Eliot Miranda
that kind of granularity?
Post by marcel.taeumel
Best,
Marcel
--
http://forum.world.st/The-Trunk-System-mt-771-mcz-tp4856201p4856686.html
Post by Eliot Miranda
Post by marcel.taeumel
Sent from the Squeak - Dev mailing list archive at Nabble.com.
--
_,,,^..^,,,_
best, Eliot
--
_,,,^..^,,,_
best, Eliot
Levente Uzonyi
2015-10-22 00:00:14 UTC
Permalink
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
Post by Eliot Miranda
Hi Ben,
Post by Eliot Miranda
Hi Marcel,
Post by marcel.taeumel
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
Post by Eliot Miranda
Post by marcel.taeumel
Accurate timestamps are kind of important... :-/
Yes, agreed.  But method timestamps to second granularity?  Why do you need
that kind of granularity?
Post by marcel.taeumel
Best,
Marcel
--
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
marcel.taeumel
2015-10-22 09:01:59 UTC
Permalink
It's minutes again:
http://forum.world.st/The-Trunk-System-mt-772-mcz-td4857260.html

Best,
Marcel



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

Bert Freudenberg
2015-10-20 15:38:55 UTC
Permalink
Post by c***@source.squeak.org
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.
Post by c***@source.squeak.org
=============== Diff against System-cmm.770 ===============
----- 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 -
Eliot Miranda
2015-10-20 15:50:11 UTC
Permalink
_,,,^..^,,,_ (phone)
Post by c***@source.squeak.org
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.
Post by c***@source.squeak.org
=============== Diff against System-cmm.770 ===============
----- 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
2015-10-20 18:07:47 UTC
Permalink
Post by Eliot Miranda
_,,,^..^,,,_ (phone)
Post by c***@source.squeak.org
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
2015-10-20 19:46:51 UTC
Permalink
Post by Chris Muller
Post by Eliot Miranda
_,,,^..^,,,_ (phone)
Post by Bert Freudenberg
Post by c***@source.squeak.org
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.
Post by Chris Muller
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 -
Eliot Miranda
2015-10-20 21:40:10 UTC
Permalink
Post by c***@source.squeak.org
Post by Chris Muller
Post by Eliot Miranda
_,,,^..^,,,_ (phone)
Post by Bert Freudenberg
Post by c***@source.squeak.org
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.
Post by Chris Muller
Post by Eliot Miranda
Post by Bert Freudenberg
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.
Post by Chris Muller
Post by Eliot Miranda
+1. Marcel, if you really need this why not make it a preference, off
by default.
Post by Chris Muller
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.
Post by c***@source.squeak.org
Post by Chris Muller
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
Loading...