Self-interest May 1994

self-interest@lists.selflanguage.org

8 participants
12 discussions

Self for other OSes/machines -- Linux?
by Robert.Brown＠Barra.COM 08 Jun '94

08 Jun '94

Is Self available for other OSes/machines besides Suns? I'm wondering if it's available for Linux running on x86 machines. Thanks. -- Robert Brown Work address: BARRA Internet: robertb(a)barra.com 1995 University Ave. Suite 400 * * * BARRA may or may not agree with Berkeley, CA 94704 this nonsense * * * (510) 548-5442

4 3

Re: traits
by davidg＠longview.com 29 May '94

29 May '94

A small twist/objection to Ivan Moore's question about why traits are centralized in a 'traits' object instead of accessed by a message to the prototype: Asking a prototype for its traits is a reflective operation (what if it doesn't have any traits? should that be revealed by its interface?). A better way of doing it would be to access the traits through a mirror on the prototype. At any rate, it shouldn't be done through the prototype interface itself- this sort of thing is exactly why Smalltalk's programming environment is so hard to disentange from programs written using it. - Dave

1 0

Re: traits
by Randall.Smith＠Eng.Sun.COM 29 May '94

29 May '94

> > Why not just get the traits from the appropriate prototype? > We've talked about doing this (eliminating the "traits" object.) So instead of "traits snortWidget" you'd just say "snortWidget parent," which of course you can do today. As long as the inheritance slot is actually named "parent." The only drawback I can see is requiring each prototype to have its inheritance link in a slot whose name you can count on. However, even though I understand and appreciate the minimalist motives, having the traits object somehow doesn't bother me that much.

1 0

Re: traits
by David.Ungar＠Eng.Sun.COM 28 May '94

28 May '94

I agree completely. It's a hysterical articfact. -- Dave At 1:11 PM 5/26/94 +0100, Ivan Moore wrote: >Hello, > >Why are all the traits objects in the 'traits' object? (that's not very clear, >is it. I'll try again) Why *is* there a 'traits' object? > >Why not just get the traits from the appropriate prototype? > >It seems un-object-oriented to put traits together just because they >are all traits. eg. 'traits window' doesn't have much to do with 'traits set', >so why should they be 'in' the same object? (Ignoring the objects used for >splitting them into sub-groupings). It seems like a 'functional' sort >of decomposition rather than an object-oriented one (if that makes sense). > >Surely 'window traits' (or 'window parent' or 'window class' (sorry about that >- only joking :-) or 'window sharedBehavior' or anything else that asks a >prototype for its traits is better. The prototypes are the 'important' objects >- aren't they? > >I realise that prototypes are going to have to be 'in' the same object (in some >sense - the lobby) in order to be able to use them - but this is inevitable. > >Ivan.

1 0

Re: parsing
by Ole.Agesen＠Eng.Sun.COM 27 May '94

27 May '94

Then there is the full LR(1) lexer/parser generator, Mango which you can give a grammer and it will return you a lexer/parser that produce parse trees... Just to clarify: Mango is not part of release 3.0 (for a moment I thought it was). Sorry for any confusion I may have caused. Ole

1 0

Re: parsing
by Ole.Agesen＠Eng.Sun.COM 27 May '94

27 May '94

Ivan, about the released system, I can say the following: It is correct that the parser is in the VM (and only there can you find a full definition of Self syntax). The closest you can get to a parser written in Self is the "parser test" in the test suite, but it is a parser for an old subset of Self, i.e. it does not parse today's Self. Also, I'm not sure how useful the output of it is. Then there is the full LR(1) lexer/parser generator, Mango which you can give a grammer and it will return you a lexer/parser that produce parse trees, but... I don't think you can write a context free grammar that describes Self syntax. You can get close and it is possible that the remaining problems can be hacked up. (I mean, I used Mango to write a full ANSI C parser and I'd hate to admit that it can handle C but not Self). If you try, I'd certainly be interested in hearing more about how it goes. I'm curious about what you need the parser for? Good luck Ole

1 0

parsing
by Ivan Moore 27 May '94

27 May '94

Is Self parsing done in the VM? I had a look to see if I could find how parsing was done and it looks as if it is done by a primitive - hence in the VM (?). Does anyone have a Self parser (written in Self) that they would let me use? thanks in advance, Ivan.

1 0

traits
by Ivan Moore 26 May '94

26 May '94

Hello, Why are all the traits objects in the 'traits' object? (that's not very clear, is it. I'll try again) Why *is* there a 'traits' object? Why not just get the traits from the appropriate prototype? It seems un-object-oriented to put traits together just because they are all traits. eg. 'traits window' doesn't have much to do with 'traits set', so why should they be 'in' the same object? (Ignoring the objects used for splitting them into sub-groupings). It seems like a 'functional' sort of decomposition rather than an object-oriented one (if that makes sense). Surely 'window traits' (or 'window parent' or 'window class' (sorry about that - only joking :-) or 'window sharedBehavior' or anything else that asks a prototype for its traits is better. The prototypes are the 'important' objects - aren't they? I realise that prototypes are going to have to be 'in' the same object (in some sense - the lobby) in order to be able to use them - but this is inevitable. Ivan.

1 0

Re: garbage collection
by urs＠cs.stanford.edu 19 May '94

19 May '94

> it appears that I have a huge amount of garbage in my old image. > > How does something qualify for garbage collection? I had assumed that if it > couldn't be reached from the lobby it would be garbage collected. Objects may be reachable from places other than the lobby: old processes, the history table, some caches in the UI or the transporter, etc. (If Self had "weak pointers", many of these problems would go away.) To release all these "hidden" references, run "memory releaseObjects"; "memory cleanup" does a release followed by a GC. Be warned that releaseObjects flushes the code cache (because compiled code may hold on to objects as well). So, if you run memory cleanup right after starting from a snapshot, you should be able to get rid of your garbage. IF not, you may have introduced your own "hidden" references that hold on to old objects (suspects are e.g. variables in shell, or other "convenience slots" you use while debugging. -Urs

1 0

garbage collection
by Ivan Moore 19 May '94

19 May '94

Hello, I've been writing some Self, and my image has been growing larger and larger. Having transported virtually everything out, and filed it in to a fresh image it appears that I have a huge amount of garbage in my old image. To give you some figures - the fresh image with everything filed-in is about 7M, but the old image is about 11M. How does something qualify for garbage collection? I had assumed that if it couldn't be reached from the lobby it would be garbage collected. Do you have any suggestions about what I might be doing to create uncollectable garbage, how to avoid creating such stuff and how to get it collected? Ivan.

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 May 1994