Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
Locked
Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
 
|
On Fri, Oct 25, 2013 at 10:58:49PM +0000, [hidden email] 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 |
Re: Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
|
|
What is NextVariableCheckTime used for? Is it that there is no active
use of it anymore? --Hannes On 10/26/13, David T. Lewis <[hidden email]> wrote: > On Fri, Oct 25, 2013 at 10:58:49PM +0000, [hidden email] 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 > > > |
Re: Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
|
|
In reply to this post by David T. Lewis
On 26 October 2013 04:10, David T. Lewis <[hidden email]> wrote:
> On Fri, Oct 25, 2013 at 10:58:49PM +0000, [hidden email] 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 > > |
Re: Evolution from the primordial stew
|
|
In reply to this post by David T. Lewis
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, [hidden email] 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 |
Re: Evolution from the primordial stew
|
|
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, [hidden email] 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 > > |
Re: Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
|
|
In reply to this post by Hannes Hirzel
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 <[hidden email]> wrote: > > On Fri, Oct 25, 2013 at 10:58:49PM +0000, [hidden email] 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 > > > > > > |
Re: Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
|
|
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" <[hidden email]> 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 <[hidden email]> wrote: >>> On Fri, Oct 25, 2013 at 10:58:49PM +0000, [hidden email] 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 >>> >>> >>> > |
Re: Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
|
|
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> wrote: >>>> On Fri, Oct 25, 2013 at 10:58:49PM +0000, [hidden email] >>>> 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 >>>> >>>> >>>> >> > > |
Re: Evolution from the primordial stew
|
|
In reply to this post by Bob Arning-2
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 |
Re: Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)
|
|
In reply to this post by Hannes Hirzel
Hannes: yes, only in this case the "data" has behavior too:) On Sat, Oct 26, 2013 at 12:11 PM, H. Hirzel <[hidden email]> wrote: This phenomenon is not all that unknown to people who have maintained |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |