Self-interest November 1999

self-interest@lists.selflanguage.org

23 participants
21 discussions

The Effort on Self
by Gordon Cichon 09 Jan '00

09 Jan '00

Hi all, I would like to suggest that we should get a more precisely defined focus on what our effort with Self is heading to. I would like to publicly ask the following question: What is our vision on Self? And: Can we do it together? Smalltalk started off with very similar goals than Self. It had the reputation of a very powerful but authistic platform. In Smalltalk, very litte have been done over the time to relieve this major disadvantage, while its advantages have been constantly adpoted into other systems like Java, C++ or Visual Basic. The result is that as the good ideas of Smalltalk got absorbed, and it did hardly evolve any further since 1980, it became virtually obsolete, IMHO. So, let's learn something from the past, and let's not make the same mistakes with Self again. We have to work more closely together. Let's not reinvent the wheel over and over again. We have currently nearly ten different implementation projects on Self, some of them are already running for more than five years, and we still do not have any tangible result besides the work of the Self group at Sunlabs. Let's get more focus, folks. Of course, everybody of us has a strong ego and wants to be the first one who rolls out the ultimate Self solution. What do we gain from that? If we are so good that we dare to implement Self on our own, would we not be much more successful if we join and work together? Gordon.

12 33

self.sunlabs.com already updated, in fact
by richard.emerson＠wdr.com 30 Nov '99

30 Nov '99

Yes, sorry about that. It was me after all. _______ Richard

1 0

self.sunlabs update? (newbie q.)
by richard.emerson＠wdr.com 30 Nov '99

30 Nov '99

Hi - quick question... I know this was discussed a little while ago, but on self.sunlabs.com I still see the Self 4.0 pages from '96... is it just me? Do they need updating? _______________ Richard Emerson

1 0

Self language applications
by anup_dargar＠ndsu.nodak.edu 30 Nov '99

30 Nov '99

Hi, I am intrested in knowing the application of self language and also of kevo. can anybody help me. Also what benefits it has over other ool using class inheritance related to the application. Thanks Looking for an early reply. Anup Dargar Anup_Dargar(a)ndsu.nodak.edu

2 1

Self 4.1.1
by Bharat Bedia 29 Nov '99

29 Nov '99

Hi, I downloaded Self for SPARC from http://self.sunlabs.com/release_4.1/release.html page. After succesful unpacking and untar'ing, I made the Self and *.snap files executables. When I run the "Self -s Demo.snap" I get the following messages:- Welcome to the Self system! (Version 4.0.2) Copyright 1992-9 Sun Microsystems, Inc. and Stanford University. See the LICENSE file for license information. Type _Credits for full credits. VM version: 4.1.10 "Self 54" connect: Connection refused connect: Connection refused No 'asSmallInteger' slot found in a paint. UI step failed twice in Self 1(type: worldMorph) -- starting debugger in new world connect: Connection refused connect: Connection refused No 'asSmallInteger' slot found in a paint. Can't start debugger in new world -- the UI is really broken! You'll have to fix it outside the UI -- then type "desktop go". This is the first time I'm trying out Self so I would really appreciate any help. cheers, Bharat

3 2

Re: Self 4.1.1
by Bharat Bedia 26 Nov '99

26 Nov '99

Coolness! Its working. I'm going through the demo. I'm still getting a "connect: Connection refused" message but so far it seems to be ok. Hopefully, I can now participate in this list instead of lurking. Thanks, Bharat > From: Jecel Assumpcao Jr [mailto:jecel@merlintec.com] > Bharat Bedia wrote: > > Indeed, running the Demo.snap, creates two blank X windows > with the title > > "Self 1" and "Self 8". > > I've seen this before :-( > > Try switching your Dell to 256 colors before starting up Exceed > and it should work. I did half of the job to make Self run on > screens with more than 256 colors, but then got stuck in the > mask generation code. > > Your reference to "connect: Connection refused" made me think > the same thing as Reinout Heeck (that you had not run xhost), but > since you do get blank windows, the number of colors is likely > to be the problem. > > We need to fix this... >

1 0

Re: Self 4.1.1
by Bharat Bedia 26 Nov '99

26 Nov '99

> From: Reinout Heeck [mailto:reinz@Desk.org] > Bharat Bedia wrote: > > > > "Self 54" connect: Connection refused > > connect: Connection refused > > I didn't try Self on unix, but to me this suggests it > cannot connect to your X terminal. > > Are you running self as another user than your X session? > > Are you running it on another machine? > (if so use unix command 'xhost') > > Is the shell environment variable $DISPLAY set? > (check with 'echo $DISPLAY', it should probably be set to ':0.0') Ooops, I'm sorry, I forgot to mention the environment: The unix machine is a Sun Ultra60 running Solaris 2.6 My client machine is a Dell NT4.0 running Exceed. All unix apps display themselves correctly on my PC (eg. xterm etc). Indeed, running the Demo.snap, creates two blank X windows with the title "Self 1" and "Self 8". thanks, Bharat

3 2

3 Button Mouse on MacSelf
by Thorsten Dittmar 23 Nov '99

23 Nov '99

Hi, does anybody know how I must install my three button mouse on the mac in a way that Self can use it?? Thorsten

2 1

self in self - plan B
by Jecel Assumpcao Jr 22 Nov '99

22 Nov '99

I already wrote one Self in Self and liked the experience very much. The problem was that I never did finish debugging tinySelf 1, so it only handles very trivial expressions. But if it were fixed, it should be able to run any Self program since it included everything Self has and then added some (a model for parallel execution). Most of the added complexity isn't needed for just running Self and is the reason why debugging it was so complicated (it had stuff like tail message elimination which made things hard to understand). But tinySelf 1 can never run standalone. First of all, it is an interpreter and what we need is a compiler. It also uses these features from Self 4.0 (I already wrote about this in a message called "desnarfing tinySelf"): 1) the parser 2) the memory system/garbage collector 3) the primitives There are several options for the parser (fix the one in 'tests.self', use Mango, translate the one in C++ or the one I wrote in C, do a new one), none of them very complicated. The memory manager is a little complicated by the fact that Self uses 30 bit integers and the CPU 32 bit ones, but Self 4.1 has a a solution for this (from the PEP Java-in-Self effort, I suppose?) and the Squeak implementation is a good example. We can divide the primitives into these groups: A) simple primitives, like _IntegerAdd:, which should be directly generated by the compiler B) access to the memory system - these should be taken care of automatically when creating the memory manager C) access to the host OS, glue routines to proxy functions and data types - they could stay as they are, initially D) others - I can't remember which others there are, right now So the really big deal is to write the Self compiler (bytecodes to X86 machine language) in Self. There is nothing in Self that would make this harder than in any other language. Quite the contrary - I can't think of a better alternative for dealing with very complex and dynamic data structures. We could: - write a program that would read a description of the CPU and generate a code generator for it Self automatically. This would be a kind of "mango for the back end". or - write the back end in a very abstract style, suitable for any CPU. Then we would create a child object for a specific CPU and implement the abstract methods ('generateJump:') manually. The inlining compiler would optimize most of the implied indirections, so the final code would be similar to that of the first option (I am talking about how fast the code generator runs, not the quality of the code it generates) or - write the back end to generate a very primitive and abstract machine code. A patttern matcher in the final pass would translate that into the actual machine language for each CPU I would say that the GCC is mostly the first option, with some of the second one mixed in. For a long time, I have mostly considered the second option. It is a classic example of an "object oriented framework" and I think several people would find it easy enough to understand to do ports to the various CPUs. The first two alternatives generate very fast code generators (important for both the NIC and the SIC) but they have very limited code transformation capabilities. In the second option, most of the compiler state would be in the arguments of the various method calls instead of in an explicit data structure. So I am seriously looking into the third option since I think high quality code scheduling should be a very high priority when dealing with modern CPUs. Are there any issues that I am forgetting, or neat alternatives that I am not aware of? -- Jecel

1 0

Self 4.1
by diegogomezdeck＠consultar.com 19 Nov '99

19 Nov '99

I'm too happy to see Dave working on Self...... But I'm not to happy becouse I have not a SPARC, I have not a MAC.... :-( Somebody is thinking in port Self 4.1 to Linux/i386 or Windows??? TIA, (|diego. gomez. deck|)

10 30

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 November 1999