Self-interest September 1991

self-interest@lists.selflanguage.org

5 participants
8 discussions

Start a nNew thread

just testing
by scott＠Thinkage.On.CA 28 Sep '91

28 Sep '91

just testing, sorry

1 0

Re: unknown model code in hostID, in ui
by Bay.Chang＠Eng.Sun.COM 18 Sep '91

18 Sep '91

> Something else I noticed, which may or may not have something to > do with it, is related to the UI. The UI started up and ran fairly > well, but I got multiple copies of this message as it was starting: > > warning: unknown model code in hostID, assuming sun4_260 > > My 'hostid' command prints '5200804d' if this helps... In the current release (1.1) the ui uses the hostDB (defined in hosts.self) to look for certain default information, such as the framebuffer to run on. These warning messages can be ignored; they just indicate that the hostDB is incomplete, not having entries for your kind of machine. In this case, I believe that the first two bytes, 0x52, indicate a Sparcstation IPC, which we hadn't put into the hostDB. You can eliminate the warning message if you wish by adding entries for the IPC into the hostDB. The file hosts.self is pretty long, but you can probably figure out what to add (after a while) by patterning after other entries. Bay

1 0

Re: _AddSlots: in programs
by Urs Hoelzle 18 Sep '91

18 Sep '91

> > > > The system keeps dependency information to keep track of the fact that > > the machine code for bar depends on b being a data slot. During the > > _Define:, bar's code is marked as "outdated", and it's stack frame is > > marked. When control returns to bar (after the change), a trap > > handler is invoked which recompiles bar before continuing execution. > > It seems to me that depending on what the compiler has inlined, and how > it moved code around and optimized some of it away, that it isn't easy to > continue execution after recompiling a method. I haven't had time to > think this through, but the new compilation of the method might organize > its stack/registers differently. Just remapping the instruction pointer > >From the old method to the new seems quite complicated. This is true; a local variable which was in a register in the old version of the compiled method might now reside in another register or on the stack; stack frames may grow or shrink, and a single stack frame might be split into several stack frames (because less inlining is done in the newer version of the code). The system uses the same debugging information that is used to display the stack to find out about the old and new locations of things. We'll try to write a paper soon about these questions; our current solution is actually quite simple. > the compiler might play. The OOPSLA'89 paper mentions scope description > and bytecode mappings as the solution. How much overhead do you get for > keeping all that information. Would it be too costly to throw it away > and, when you need it, to recompile the old version of the method to > regenerate all this? The space overhead does indeed exist, and we've been thinking about reducing it. The current implementation doesn't try to save space - a relatively simple change to a denser encoding would probably halve the space requirements, but we just haven't gotten around to doing it. Generating the information "on demand" a la Smalltalk is possible. However, things get tricky after programming changes - how do you recompile (and re-inline) a method if its receiver looks entirely different now? So, in the general case, some information has to be generated always. Note that you need the debugging info precisely after programming changes to recompile methods on the stack as mentioned above. -Urs

1 0

Re: possible bug with _WriteSnapshot
by Urs Hoelzle 18 Sep '91

18 Sep '91

> I grabbed the Self binaries and scripts a couple of days ago. I'm > running it on a Sun SPARC IPC under SunOS 4.1.1. The very first > problem I had is with getting _WriteSnapshot to write a complete > snapshot (the system seems to work fairly well other than this). When > I try to write the snapshot, it goes away for about 5 seconds, and > then comes back with the fatal error message below. This sounds more > > 'snap' _WriteSnapshot > cannot write to file: Interrupted system call > fatal error: write error This is the infamous "SunOS 4.1.1 write bug"; basically, the write() system call violates its contract by returning with EINTR before it has written everything. This bug occurs in SunOS 4.1.1 only (not in 4.1). It doesn't always appear; writes over NFS normally seem to work, and writes to /tmp also work if you're running tmpfs. We got the bug only when writing to a local disk if I remember correctly. A kernel patch to fix the write problem is available from Sun (bug ID 1052649). I forgot their 800 number, but your sysadmin should know. Hope that helps, -Urs

1 0

Re: _AddSlots: in programs
by jecel＠lsi.usp.br 17 Sep '91

17 Sep '91

> The system keeps dependency information to keep track of the fact that > the machine code for bar depends on b being a data slot. During the > _Define:, bar's code is marked as "outdated", and it's stack frame is > marked. When control returns to bar (after the change), a trap > handler is invoked which recompiles bar before continuing execution. It seems to me that depending on what the compiler has inlined, and how it moved code around and optimized some of it away, that it isn't easy to continue execution after recompiling a method. I haven't had time to think this through, but the new compilation of the method might organize its stack/registers differently. Just remapping the instruction pointer from the old method to the new seems quite complicated. I realize that you must have all this worked out already on the old Self just to be able to dump the stack correctly considering all the tricks the compiler might play. The OOPSLA'89 paper mentions scope description and bytecode mappings as the solution. How much overhead do you get for keeping all that information. Would it be too costly to throw it away and, when you need it, to recompile the old version of the method to regenerate all this? -- Jecel P.S.: I hope my last message didn't cause any confusion - I copied the date to try to make it clear I was referring to an old message.

1 0

Re: _AddSlots: in programs
by Urs Hoelzle 17 Sep '91

17 Sep '91

> > Subject: Re: primitives > > In-Reply-To: Your message of Wed, 30 Jan 91 19:41:05 -0500 > > Reply-To: Urs Hoelzle <hoelzle(a)cs.stanford.edu> > > Message-Id: <CMM.0.88.665431692.urs@> > > Status: RO > > > >> Are primitives like _RemoveSlots: and _AddSlots: going to be useable > >> within methods in the next release?? This would be cool, because it > >> would help with data inheritance. > >> > > > > No (see the release message). They do work in our current system > > (i.e. you can change objects while the program is running), but we > > want thing to stabilize a bit before putting them into a release. > > I have been thinking about this as it seems to me that not being > able to modify objects at runtime makes it impossible to develop > a complete programming environment ( like Smalltalk's ) for Self. > Note that I sent this mail last January...so, just to avoid any confusion: yes, the upcoming release will absolutely definitively have the ability to modify objects at runtime. > There seems to be a language definition problem and a implementation > problem. What happens if modifying the object alters the lookup of > methods that are already on the stack? You could say that they > should not be affected and that only messages sent from now on must > reflect the altered object. Suppose that foo = (| bar = ( a. b. ). a = ( 'a' print ). b <- nil |) and foo and a are on the stack (e.g. the process is suspended just before the send of 'print'). Now suppose some other process does foo _Define: (| a = ( 'A' print). b = ( 'b' print ) ). What should happen when the suspended process continues? Well, bar and a are already on the stack, i.e. their activation objects have been created by cloning the (old definition of) their respective method. Thus, the _Define won't affect them directly because the clones are independent of the original just like for every other Self object. So a will send the print message and return, and then bar will send the 'b' message. This will invoke the new (current) definition, of course, just as you would expect from an interpreter. The system keeps dependency information to keep track of the fact that the machine code for bar depends on b being a data slot. During the _Define:, bar's code is marked as "outdated", and it's stack frame is marked. When control returns to bar (after the change), a trap handler is invoked which recompiles bar before continuing execution. -Urs

1 0

_AddSlots: in programs
by jecel＠lsi.usp.br 16 Sep '91

16 Sep '91

> Subject: Re: primitives > In-Reply-To: Your message of Wed, 30 Jan 91 19:41:05 -0500 > Reply-To: Urs Hoelzle <hoelzle(a)cs.stanford.edu> > Message-Id: <CMM.0.88.665431692.urs@> > Status: RO > >> Are primitives like _RemoveSlots: and _AddSlots: going to be useable >> within methods in the next release?? This would be cool, because it >> would help with data inheritance. >> > > No (see the release message). They do work in our current system > (i.e. you can change objects while the program is running), but we > want thing to stabilize a bit before putting them into a release. I have been thinking about this as it seems to me that not being able to modify objects at runtime makes it impossible to develop a complete programming environment ( like Smalltalk's ) for Self. There seems to be a language definition problem and a implementation problem. What happens if modifying the object alters the lookup of methods that are already on the stack? You could say that they should not be affected and that only messages sent from now on must reflect the altered object. If Self were interpreted that would be enough ( although multitasking complicates things ) but the problem is that the compiler effectively caches lookups - code in methods on the stack might have to be recompiled. Obviously, from the message above, you have found a way around this problem but I can't guess what the solution is. A less general solution that would help me quite a bit would be _CopyWithNewSlots: and _CopyWithoutSlots: primitives that would create new objects modified as specified. Since these are new objects, they cannot have any influence on already compiled methods ( and in particular, those on the stack(s) ). I believe these primitives could be safely called from within any method. --- Jecel ----

1 0

Re: "data objects" vs "method objects"
by David.Ungar＠Eng.Sun.COM 16 Sep '91

16 Sep '91

I agree, and the original language paper by Randy & me takes this view. The problem is that this is a hard story to maintain when pushed. For example, data objects return themselves but methods clone themselves when they run. How do you account for the cloning? Or if everything clones, how does a data-object refer to the clone-father? Also, the implementation falls a bit short in hiding the differences. But, this unification is a wonderful platonic ideal that we do strive for. Dave > From owner-self(a)self.stanford.edu Sun Sep 15 20:44:09 1991 > Return-Path: <thinkage!Thinkage.On.CA!scott(a)watmath.waterloo.edu> > Date: Sun, 15 Sep 91 23:39:10 EDT > To: self-interest(a)self.stanford.edu > Subject: "data objects" vs "method objects" > Content-Length: 1071 > X-Lines: 23 > > > Just a thought on how the papers and manuals explain how objects > are evaluated w.r.t "data objects" vs "method objects". It seems to > me that no distinction is necessary or desirable between these two > "types" of objects. > > An object should simply be viewed as something containing a bunch > of slots, and a method. An object that is supposed to behave like > data (i.e., no explicit method) should implicitly be given a method > which is simply "self". > > Describing objects this way would make things seem even more > uniform -- the manuals would no longer have to state that "Data > objects are objects without code" or that "A data object returns > itself when evaluated"; all objects simply execute their method when > they are evaluated, and return the result. Since the method for "data > objects" is "self", everything falls out in the wash. > > [Eg: (|x.y|) should be described as an abbreviation for (|x.y| self).] > > -- > Scott M. King Thinkage Ltd. Kitchener, Ontario, Canada > smking(a)Thinkage.On.CA smking(a)Thinkage.com uunet!thinkage!smking >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest September 1991