On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
What is NextVariableCheckTime used for? Is it that there is no active use of it anymore?
--Hannes
On 10/26/13, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
On Sat, Oct 26, 2013 at 07:55:25AM +0000, H. Hirzel wrote:
What is NextVariableCheckTime used for? Is it that there is no active use of it anymore?
--Hannes
It was used a long time ago to schedule periodic checks of something. I'm not sure what it was, but it may have been related to handling the state of variables during copies to or from image segments.
The class DeepCopier is of course an object, and that object has been in the image for a long time. By looking at that object, you could see that it pointed to a value that happened to represent a time stamp, and since that time stamp represented a time in 2001, it was a pretty good clue as to when the variable had last been updated.
I was only pointing this out because it reminded me once again of how different Squeak is from environments that think of everything as file based source code, rather than as objects.
Dave
On 10/26/13, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
There are two sides to this coin, and I didn't see that before reading this. I only saw the downside.
"Rogue objects" are generally something that freaks me out and makes me nervous. Are they still sending messages? Will they? Are they still receiving messages? I don't like that they're hard to find, mainly.
I've had some long nights realizing that there were stored procedures hidden away in databases at work, and this is a bit like that except... the database isn't disjoint from the running "application" and...
This is what I've really enjoyed, reading this post: since we never blanket-discard runtime state as in other systems, what would there be "useless dangerous dead state-process" is still useful here because it can contain forensic/historical information.
Or, maybe more clearly: some of the design goals underlying this system were specified by people who were interested in anthropology, people who wouldn't be interested in throwing the mummy out with the bath water. To abuse a phrase.
Fascinating. I have a new perspective.
On Oct 26, 2013, at 7:35 AM, "David T. Lewis" lewis@mail.msen.com wrote:
On Sat, Oct 26, 2013 at 07:55:25AM +0000, H. Hirzel wrote:
What is NextVariableCheckTime used for? Is it that there is no active use of it anymore?
--Hannes
It was used a long time ago to schedule periodic checks of something. I'm not sure what it was, but it may have been related to handling the state of variables during copies to or from image segments.
The class DeepCopier is of course an object, and that object has been in the image for a long time. By looking at that object, you could see that it pointed to a value that happened to represent a time stamp, and since that time stamp represented a time in 2001, it was a pretty good clue as to when the variable had last been updated.
I was only pointing this out because it reminded me once again of how different Squeak is from environments that think of everything as file based source code, rather than as objects.
Dave
On 10/26/13, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
This phenomenon is not all that unknown to people who have maintained a db system with application programs accessing it for many years. There is data which once was entered and is no longer used and updated. Often people are not aware of it and if they are they mostly do not dare to delete it.
Any complex system needs to be reviewed from time to time if you want to maintain service quality.
--Hannes
On 10/26/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
There are two sides to this coin, and I didn't see that before reading this. I only saw the downside.
"Rogue objects" are generally something that freaks me out and makes me nervous. Are they still sending messages? Will they? Are they still receiving messages? I don't like that they're hard to find, mainly.
I've had some long nights realizing that there were stored procedures hidden away in databases at work, and this is a bit like that except... the database isn't disjoint from the running "application" and...
This is what I've really enjoyed, reading this post: since we never blanket-discard runtime state as in other systems, what would there be "useless dangerous dead state-process" is still useful here because it can contain forensic/historical information.
Or, maybe more clearly: some of the design goals underlying this system were specified by people who were interested in anthropology, people who wouldn't be interested in throwing the mummy out with the bath water. To abuse a phrase.
Fascinating. I have a new perspective.
On Oct 26, 2013, at 7:35 AM, "David T. Lewis" lewis@mail.msen.com wrote:
On Sat, Oct 26, 2013 at 07:55:25AM +0000, H. Hirzel wrote:
What is NextVariableCheckTime used for? Is it that there is no active use of it anymore?
--Hannes
It was used a long time ago to schedule periodic checks of something. I'm not sure what it was, but it may have been related to handling the state of variables during copies to or from image segments.
The class DeepCopier is of course an object, and that object has been in the image for a long time. By looking at that object, you could see that it pointed to a value that happened to represent a time stamp, and since that time stamp represented a time in 2001, it was a pretty good clue as to when the variable had last been updated.
I was only pointing this out because it reminded me once again of how different Squeak is from environments that think of everything as file based source code, rather than as objects.
Dave
On 10/26/13, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
Hannes: yes, only in this case the "data" has behavior too:)
On Sat, Oct 26, 2013 at 12:11 PM, H. Hirzel hannes.hirzel@gmail.com wrote:
This phenomenon is not all that unknown to people who have maintained a db system with application programs accessing it for many years. There is data which once was entered and is no longer used and updated. Often people are not aware of it and if they are they mostly do not dare to delete it.
Any complex system needs to be reviewed from time to time if you want to maintain service quality.
--Hannes
On 10/26/13, Casey Ransberger casey.obrien.r@gmail.com wrote:
There are two sides to this coin, and I didn't see that before reading
this.
I only saw the downside.
"Rogue objects" are generally something that freaks me out and makes me nervous. Are they still sending messages? Will they? Are they still receiving messages? I don't like that they're hard to find, mainly.
I've had some long nights realizing that there were stored procedures
hidden
away in databases at work, and this is a bit like that except... the database isn't disjoint from the running "application" and...
This is what I've really enjoyed, reading this post: since we never blanket-discard runtime state as in other systems, what would there be "useless dangerous dead state-process" is still useful here because it
can
contain forensic/historical information.
Or, maybe more clearly: some of the design goals underlying this system
were
specified by people who were interested in anthropology, people who
wouldn't
be interested in throwing the mummy out with the bath water. To abuse a phrase.
Fascinating. I have a new perspective.
On Oct 26, 2013, at 7:35 AM, "David T. Lewis" lewis@mail.msen.com
wrote:
On Sat, Oct 26, 2013 at 07:55:25AM +0000, H. Hirzel wrote:
What is NextVariableCheckTime used for? Is it that there is no active use of it anymore?
--Hannes
It was used a long time ago to schedule periodic checks of something. I'm not sure what it was, but it may have been related to handling the state of variables during copies to or from image segments.
The class DeepCopier is of course an object, and that object has been in the image for a long time. By looking at that object, you could see that it pointed to a value that happened to represent a time stamp, and since that time stamp represented a time in 2001, it was a pretty good clue as to when the variable had last been updated.
I was only pointing this out because it reminded me once again of how different Squeak is from environments that think of everything as file based source code, rather than as objects.
Dave
On 10/26/13, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew
of
living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds).
Some
time in an earlier millenium, a primeval user of the class had set
this
variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became
curious
about whether this class variable was being used, I was able to look
at
its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
On 26 October 2013 04:10, David T. Lewis lewis@mail.msen.com wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
classVariableNames: ''
classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
It's a pity this here hammer doesn't work well driving in screws :) Or, more Zen-like, "mu".
Except, maybe not, actually. I mean, I stand by the above if by "version control system" you mean Git or Monticello. Those only track definitions, anyway, not state. (Look at the contortions you have when writing database migrations: yes, they're under version control. No, they won't Just Work all by themselves.)
But a version control system just tracks changes in things, at its root. The problem with DeepCopier's NextVariableCheckTime here is that you only have the most recent version of the thing. A proper version control system would allow you to say "this thing that you call 'DeepCopier's NextVariableCheckTime' has had several states, the most recent being this one". (I'm hinting very strongly at Clojure's separation of state and identity.)
frank
Dave
http://69.251.218.6:9116/ can give you a pretty good picture of the evolution in this area.
Cheers, Bob
On 10/25/13 11:10 PM, David T. Lewis wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
On Sat, Oct 26, 2013 at 05:32:25AM -0400, Bob Arning wrote:
http://69.251.218.6:9116/ can give you a pretty good picture of the evolution in this area.
Cheers, Bob
Yes, this is really quite useful. Using it to search for isItTimeToCheckVariables immediately brings up three change sets that show Henrik Gedenryd and Ted Kaehler working on things related to copying to image segments and Etoys. If I had thought to check http://69.251.218.6:9116/ I would have known that I should look at the Etoys image to make sure isItTimeToCheckVariables is not being used there. I just checked it now, and lucky for me it is not used in Etoys either.
Dave
On 10/25/13 11:10 PM, David T. Lewis wrote:
On Fri, Oct 25, 2013 at 10:58:49PM +0000, commits@source.squeak.org wrote:
Item was changed: Object subclass: #DeepCopier instanceVariableNames: 'references uniClasses newUniClasses'
- classVariableNames: ''
- classVariableNames: 'NextVariableCheckTime' poolDictionaries: '' category: 'System-Object Storage'!
One thing that I find rather appealing about Squeak is that its stew of living objects contains things that have existed since before my time. Even if the so-called "code" changes, the objects still can survive.
Every once in a while this turns out to have some practical benefit. For example, the class DeepCopier had a class variable that kept track of some sort of time stamp (in the form of NextVariableCheckTime seconds). Some time in an earlier millenium, a primeval user of the class had set this variable, then wandered off into a tar pit. We do not really know who that may have been, but the original object (class DeepCopier) has survived in the image, and the last updated value of its NextVariableCheckTime has remained undisturbed since those early days. Thus when I became curious about whether this class variable was being used, I was able to look at its value and convert it to a DateAndTime to see that it had not been updated in the last dozen years or so.
It's a small thing, but just try keeping track of that with a version control system.
Dave
At Sat, 26 Oct 2013 05:32:25 -0400, Bob Arning wrote:
http://69.251.218.6:9116/ can give you a pretty good picture of the evolution in this area.
Cool.
I once had a history browser going for the Etoys V 4.0 image:
http://tinlizzie.org:8080/seaside/examples/authorship2
You can select the class and method and view all changes to the method.
It does not answer the question that what version Morphic was introduced, but I can check Morph>>addMorphFront: or Morph>>delete and get some intersting history...
-- Yoshiki
squeak-dev@lists.squeakfoundation.org
-
Bob Arning -
Casey Ransberger -
David T. Lewis -
Frank Shearar -
H. Hirzel -
Yoshiki Ohshima