Self-interest December 1999

self-interest@lists.selflanguage.org

14 participants
13 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

Sparc 2 with Solaris 2.6
by John Ars 05 Jan '00

05 Jan '00

Does anyone know if Self will run appropiately on a Sparc 2, 64 MB RAM, Solaris 2.6? Thanks, John

3 7

cichon.de goes offline temporarily
by Gordon Cichon 31 Dec '99

31 Dec '99

Hi all, I am sorry to have to tell you that my web server www.cichon.de, as well as my e-mail address gordon(a)cichon.de is going to go offline today - hopefully for a short period of time only. The reason is that the German ISP which I used to have (camelot.de) is so tremendously expensive so that I can not afford to leave my stuff there for any longer time. He charges me DM 1,25 per Mega-Byte (abt. 70 cent) plus taxes, and he wrote bills of more than DM 5000,- (abt. $3000) to me. This is incredible. I am trying to change to an US-ISP for more than 3 month already, but denic, the German version of internic simply refuses to enter a new name server record because of some pedantic technical requirements which they are not even able to tell me in advance. It is unbelievable. denic charges DM 230,- per year (abt. $150) just for a name server they don't even run by themselves. You can still reach me at cichon.com, so please send any urgent e-mail to gordon(a)cichon.com in the meantime. See you, happy new year :-) Gordon.

1 0

Re: Minimum Requirements for Self on Mac
by vincent.coetzee＠rmb.co.za 28 Dec '99

28 Dec '99

Hi I have been following this discussion on Self performance on the Mac with some interest. I also first found the performance on my G3 somewhat slow (400MHz G3, 256MB RAM), but that was after having used Self on a 400MHZ UltraSPARC, with ~512MB of RAM. Perhaps people are comparing the two. I do find that the graphics performance (ie dragging Morphs around) somewhat more sluggish than on the SPARC, but considering what Self is doing just to give that sort of performance in Morphic makes it clear that Self is not slow. To put things into perspective, try running Morphic in a commercial type Smalltalk, and see what that performance is like (baaad). I have to admit though that Squeak, is not sluggish on a 400MHz Mac. Vincent

2 2

Re: Happy Holidays!
by Randy Smith 24 Dec '99

24 Dec '99

Thanks John! To you too, Happy Holidays to you and yours... --Randy > X-eGroups-Return: self-interest-return-494-Randall.Smith=Eng.Sun.COM(a)returns.egroups.com > Delivered-To: listsaver-egroups-self-interest(a)eGroups.com > X-eGroups-Return: dolphinuser(a)hotmail.com > Date: Fri, 24 Dec 1999 07:19:37 -0800 > From: "John Ars" <dolphinuser(a)hotmail.com> > To: self-interest(a)eGroups.com > User-Agent: eGroups-EW/0.82 > Mailing-List: contact self-interest-owner(a)egroups.com > X-Mailing-List: self-interest(a)egroups.com > List-Help: <http://www.egroups.com/group/self-interest/info.html>, <mailto:self-interest-help@egroups.com> > List-Unsubscribe: <mailto:self-interest-unsubscribe@egroups.com> > List-Archive: <http://www.egroups.com/group/self-interest/> > Subject: [self-interest] Happy Holidays! > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > > allListParticipants do: [| :each | each iWishYouHappyHolidays] > > Take care, > > John > > > ------------------------------------------------------------------------ > The only fruitcake at overstock.com is our manager. > Hes giving away a $20 coupon, plus our everyday Free Shipping. > Take advantage of the savings and selection now. > http://click.egroups.com/1/342/5/_/8257/_/946048789 > > -- Easily schedule meetings and events using the group calendar! > -- http://www.egroups.com/cal?listname=self-interest&m=1 > >

1 0

Happy Holidays!
by John Ars 24 Dec '99

24 Dec '99

allListParticipants do: [| :each | each iWishYouHappyHolidays] Take care, John

1 0

Minimum Requirements for Self on Mac
by John Ars 23 Dec '99

23 Dec '99

Hi, Where may I find the minimum requirements to run Self on a Mac? A friend is selling me his IMac (G3, 32 MB RAM, 500 MB HDD), and I was wondering how it would run Self. Thanks, John

3 3

License?
by John Ars 18 Dec '99

18 Dec '99

If you port Self to Windows, for example, can you legally sell it? In other words, could you charge for a Self IDE? John

3 4

Re: self in self - plan B
by Jecel Assumpcao Jr. 17 Dec '99

17 Dec '99

In a message with this subject on November 22, I mentioned some alternatives for the code generation part of the Self compiler: > 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 commented that the first two options (gcc-style) would generate the fastest code generator, but the third option would allow the best scheduling (which is critical for high performance in modern processors). I would recomend that anyone interested in scheduling look at the various papers by Steve Novack (http://www.ics.uci.edu/~snovack/) and also this paper by Urs Hölzle and his students: http://www.cs.ucsb.edu/oocsb/papers/dispatch.html Just a little background: when David Ungar and Randy Smith first defined the Self language, most people thought that it would be impossible to make it perform as well as Smalltalk since they hadn't compromised the language model to make it more efficient. Well, Craig Chambers and friends proved them wrong by inventing sophisticated type inference systems. They got 50% of C speed on highly numerical code (the kind that brings Smalltalk to its knees) which is simply amazing when you consider that C is fast by ignoring numerical errors, addressing errors and so on that are carefully handled in Self. The problem was that the compiler was slow, which was bad since it was running in parallel with your applications. So Urs Hölzle used two compilers in order to replace type analysis (slow but precise) with type feedback (much faster and a little less precise) to make the system both more responsive and simpler. It was also better in highly object-oriented code, though not as good with numerical code. Now both Craig and Urs were interested in their new ideas, and so didn't put as much effort into the register allocation and code generation as commercial compilers (or even gcc). This makes the 50% of C above even more impressive, but has made Self have a performance penalty on more advanced processors. This is how I remember it, but I welcome corrections. In the other thread, John Ars wrote: > Hmm, intriguing. How would you go about that?? Could you write the VM > in Self (a la Squeak)? and José Baltasar García Perez-Schofield wrote: > I will be pleased to study your next mail, in order to know what > means to implement self on self. I am very intrigued about it. The Squeak model is very interesting. There is a normal Squeak program that implements the whole Squeak Virtual Machine. So you can run Squeak inside of Squeak (it works perfectly, though 600 times slower than normal). You can make changes and generate the next version of Squeak this way. When it is working the way you want it to, you can translate this Squeak program to C (it must be written in a very restricted, non object oriented style for you to be able to do this) and then compile this C program to get a new executable VM. The problem with this is that it doesn't help your own Squeak programs (you have to write parts of your application in the restricted style and then generate C as new primitives to be integrated into the virtual machine, hardly easy stuff to do!). Also, the write Smalltalk -> simulate -> translate to C -> compile -> restart virtual machine development cycle is not very direct. But what if we did what the Squeak people did but replaced the bytecode interpreter in the virtual machine with a compiler (or two)? The virtual machine could now be written in the normal Self style (no restrictions) and it would include a part that would take bytecodes and generate (for example) X86 machine language code. If the current machine can't execute this X86 code (which will be the case, since I am using a Sun Utra 5 as the development plartform), the code can be sent over a network to a machine that can. Since I explained this in the VM99 workshop position paper, I won't repeat how this is done here. See http://www.squeak.org/oopsla99_vmworkshop/jecel.txt Note that at some point, this Self program will be capable of generating X86 code for any Self program, including itself! It will be used by the whole system, including all user applications (no more translating to primitives to make things fast). Ok, so back to plan B and how to make a good code generator for Self. My current idea is to combine the three options that I described at the very begining: - (option 2) the compiler will be written in a very abstract way, with more specific compilers inheriting from it - (option 1) the more specific compilers will override data structures, not methods, so a procesesor description will be declarational instead of functional - (option 3) the compiler will work with very simple instructions (just moves between functional units) until the very end, and then translate these to the actual machine language Note that this will favor a move-based CPU (such as I designed for the Merlin 6) even though the first port will be for the X86. Since I am doing the work, I guess I am entitled to show my biases :-) The data structures that are used by the compilers are a description of each CPU in terms of functional units and scheduling. While I have been speaking of a X86 code generator, the descriptions for the 386, 486, Pentium, Pentium II and so on could be very different (though the other data structure, the translation table, would be mostly the same for all of them). What is the problem with this? The way Self compilers are now, this particular Self program won't be very efficient. But this program takes away processing time from all the applications, so the system will not be very responsive if the compiler is slow (the problem we had in Self 2.0). So here is a simple idea to fix this: optimize immutable data structures. I'll give an example in Smalltalk, since it has a syntax for declaring constant vectors while Self does not. Look at this code: #('first text is' 'and the second one is' 'finally, this one is') do: [ :s | s print. ' ' print. s size printString print] Now imagine that the compiler was smart enough to notice that the receiver of the #do: message is a constant collection and could pre-evaulate some things to generate the same code as: 'first text is' print. ' ' print. 13 print. 'and the second one is' print. ' ' print. 21 print. 'finally, this one is' print. ' ' print. 20 print Yes - this is what is called "partial evaluation". No - this particular case is not hard to implement or require a Lisp derived language. If the Self compiler in Self can do this (and we have a richer selection of constant collections than just immutableString!) and it is implemented as described above, then it would generate efficient code generators when it compiled itself. So this is what I am working on. Though it will take longer than a simple port of the Sun VM I think the result will be worth it (specially when porting to a second processor). I don't know if anyone made it this far, but if so I would love to have some comments or questions on this. -- Jecel

2 3

Re: Self on Intel running Solaris?
by Thorsten Dittmar 17 Dec '99

17 Dec '99

Hi, in the next millenium (8-9th January) some people will come to Germany to try to port Self 4.1 to Linux. So if you want you can join us (personally or maybe via web conference) to help us or you can participate on our results later. Thorsten Dittmar Daedalos Consulting > jecel assumpcao jr. <jece-(a)merlintec.com> wrote: > original article:http://www.egroups.com/group/self-interest/?start=489 > >> My own idea is to create a new implementation in Self (more about > this in the >> next email). > > Hmm, intriguing. How would you go about that?? Could you write the VM > in Self (a la Squeak)? > > John > > > ------------------------------------------------------------------------ > Need a cure for the used car blues? iMotors pre-owned cars > are: priced below Blue Book; fully tested & certified; & > carry a 7 day/700 mile money back guarantee. Look no further > iMotors.com is here! http://clickhere.egroups.com/click/1721 > > -- Talk to your group with your own voice! > -- http://www.egroups.com/VoiceChatPage?listName=self-interest&m=1 > >

3 2

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