Self-interest September 1993

self-interest@lists.selflanguage.org

8 participants
6 discussions

SignalBlocker sb(true)
by mcr＠ccs.carleton.ca 16 Sep '93

16 Sep '93

Okay... I finally got around to rebuilding my Self VM. I found the definition of SignalBlocker (not SignalBlock) in abort.h. But now it complains about initialisers. It appears that SignalBlocker doesn't do much, and definitely doesn't declare anything that starts with a bool. This is 2.0.1 code. I take it the patch was based on current code...

1 0

Porting Self -> OS/2
by bjoern＠ifki50.informatik.fh-muenchen.de 03 Sep '93

03 Sep '93

Hello, we think about porting Self to OS/2 2.1. Could anybody give us a hint what the best "entry point" would be to start porting? We miss all the .c.incl-files (which I think just include all needed .h-files). Where can I get them? Anybody out there who thinks about porting Self to e. g. IBM-AIX, HP-UX, ...? Thanks in advance, - Bjoern ----- Bjoern Winkler, FH-Munich, Germany EMail: bjoern(a)ifki50.informatik.fh-muenchen.de CompuServe: 100115,104 -----

1 0

Re: self on Solaris 2.x
by simont＠Aus.Sun.COM 03 Sep '93

03 Sep '93

Hi Lars, Can you tell us anything about what X support will be included? Any toolkit support included? Any further development on the UI that you could sketch out for us? TIA, Simon. } From urs(a)otis.Stanford.EDU Fri Sep 3 07:23 EST 1993 } Resent-Message-Id: <9309021951.AA04342(a)otis.Stanford.EDU> } From: Lars.Bak@Eng (Lars Bak) } To: timh@Aus } Cc: self-interest(a)self.stanford.edu } Subject: Re: self on Solaris 2.x } Resent-To: real-self-interest(a)otis.Stanford.EDU } Resent-Date: Thu, 2 Sep 93 12:51:00 PDT } Resent-From: Urs Hoelzle <urs(a)otis.stanford.edu> } } } Dear Tim, } } Self has been ported to Solaris 2.3 (beta release) and it is likely } a public release will be available in a few months. } } Sincerely } Lars Bak }

1 0

self on Solaris 2.x
by timh＠Aus.Sun.COM 03 Sep '93

03 Sep '93

Hi Any ideas on how far away self is from running on Solaris 2.x ;-) Tim Hoffman SE Sun Microsystems Australia Pty Ltd 130 Hay St Subiaco, Western Australia 6008 Ph +619 388 2161 Fax +619 388 2717 --------------------------------------------------------------------------- Mega big disclaimer :- Anything I say has nothing to do with my employer

3 2

Re: why push self bytecode?
by David.Ungar＠Eng.Sun.COM 03 Sep '93

03 Sep '93

Jecel, I like your idea of eliminating 'push self' in favor of 'self-send self'. It is more consistent with the rest of the story. I don't recall a good reason for doing it the way we did. As for the pop bytecode, I guess we did not worry enough about other kinds of implementations, and it does save a bit of space. Glad you like them--the main point is that they are simple and source-like instead of including things like branches, etc. Thanks for the ideas Dave

1 0

why push self bytecode?
by jecel%lsi.usp.br＠Forsythe.Stanford.EDU 01 Sep '93

01 Sep '93

Just a silly thought: Why is there a "push self" bytecode instead of "self send X" with literal X="self"? I can see it would make programs a little larger to have the extra literals, but would there be any other problems? The compiler would take care of the "self send X" with the rest of the argument slots, right? Another thing - I can see that the omission of "POP" bytecodes at the end of a statement ( at the "." ) will make code smaller and the instruction set simpler. The lost information is generated again by the compiler at data flow analysis time. It does make a Self interpreter or very simple compiler work harder. Actually, I really like the bytecodes the way they now. It's just that it is interesting to know why things were designed the way they were. - Jecel Assumpcao Jr University of Sao Paulo - Brazil

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 1993