Self-interest August 2002

self-interest@lists.selflanguage.org

18 participants
15 discussions

new to self OSX
by christian.hresko 14 Aug '02

14 Aug '02

trying to get the self (MacOSX) VM to launch properly. encountered the following problem(s); using the droplet to launch a Demo: Welcome to Darwin! "${SELF_WORKING_DIR}"/vm/mac_osx/vm_project/build/Self.app/Contents/MacOS/ Self -s "/Self/objects/Demo.snap" [localhost:~] chresko% "${SELF_WORKING_DIR}"/vm/mac_osx/vm_project/build/Self.app/Contents/MacOS/ Self -s "/Self/objects/Demo.snap" SELF_WORKING_DIR: Undefined variable. [localhost:~] chresko% if i launch from the command line: VM# VM# 'smallUI2.self' _RunScript A lookup error happened while sending the message primitiveFailedError:Name: to 'smallUI2.self'. Subsequently, the lookup error message undefinedSelector:Receiver:Type:Delegatee:MethodHolder:Arguments: was sent to <2>, and was also not understood, causing the process to be aborted by the Self VM. #0 (<error>:1): primitiveFailedError:Name: = ( | self* = 'smallUI2.self '. :arg1 = 'ENOENT'. :arg2 = '_RunScript'. delegatee = nil. | "undefined selector error; this method was automatically generated by the VM." ) #1 (<stdin>:1): <top level expr> = ( | self* = lobby. | 'smallUI2.self' _RunScript) VM# also, do i need XWindows? thanks, christian

3 2

Re: Simpler Self RFC
by Josh Flowers 10 Aug '02

10 Aug '02

>Message: 2 > Date: Tue, 6 Aug 2002 18:51:08 -0300 > From: Jecel Assumpcao Jr <jecel(a)merlintec.com> >Subject: Re: Simpler Self RFC > >Josh, > >thank you for your comments! > >> 1. simpler method/block story >> I don't know enough about how self currently works to properly >> comment. Are there any cons to this change? > >Yes, the current complicated scheme (five different objects) is needed >to get different behaviors in different situations. With my >simplification you would have objects answering messages they aren't >supposed to answer. Of course, you aren't supposed to send them these >messages, right? So the practical result is that sometimes you will get >a hard to find error where now you get a "message not understood". > >> 2. simpler non local return >> Wouldn't this require that all objects have a default slot (^)? > >All activation objects would need such a slot (and methods and blocks >when combined with proposal 1, which is needed for this to work). >Normal objects wouldn't have this slot. > Of course, that makes sense now. >> From >> what I can tell an object in self does not normally contain any slots >> by default. Am I wrong about this? > >The empty object, ( ), has no slots at all. It can receive a set of >primitive messages even so, which is a bit disturbing to some of us. > >> 5. removing inheritance from the base-level >> I'm not sure what you gain from this one. Personally I'd probably >> leave it out. > >I am also not sure about this one and the assignment one (4) either. >This can even be considered a complication instead of simplification. >Parent slots were Alan Kay's main objection to Self and that got me >thinking about them. > Did he have any specific objections to parent slots? I find them a bit odd myself, but I think it's more because they're named 'parent slots' then because of how they're implemented. Unlike parents in a class based language they cannot contain data that should be shared between their children, only behavior. This makes their usage feel strange when your more accustomed to a classic OO language. I'm not sure Self's inheritence is a bad thing (I know it's been stated that inheritance is actually harmfull because it breaks encapsulation), but it does seem odd at first. Maybe name them behaviour slots, or delegate slots (although they do more then just delegate messages)? It also seems like there are a couple of different uses for these special slots - 1) simple message forwarding - your simply sending the message to another object i.e a parent reference to globals. 2) behavior sharing - not only do you need to forward the message to another object, but that object needs to reference the object that is forwarding the message (as 'self' none the less). 3) inheritance - everything that #2 does, plus copying the "child" object must also cause the parent to be copied. As far as I know this doesn't exist in Self, but I haven't looked into it. Of course I haven't used Self that much, and these comments are somewhat off the cuff, so I may be speaking in error. josh

2 1

Fileout problem
by Thorsten Dittmar 09 Aug '02

09 Aug '02

Hi, as you may know I try to implement selfUnit. I'm ready to distribute a beta version, but I have some problems to create the files. For necessary error handling I made a clone of the prototype process. I made a slot in globals called selfUnitProcess and I initialize it to process _Clone. So far it works fine. This slot is assigned to a module named selfUnitProcessing. I add three slot to that prototype and all of them are assigned to the module selfUnitProcessing. All slots are initialized to false. When I fileOut the module and look into the generated code, then there is no code generated for these slots. I checked the annotations and the module is correctly displayed. When you move the slots to another module, like tmp, then the tmp module will recognise that change, but also in that fileOut the code is still missing. I tried out several circumstances and it seams to me that _Clone message is the root of my problems. Unfortunately I have no chance to use the normal copy mechanism. Can anybody give me a hint? Thorsten

2 3

Simpler Self RFC
by Josh Flowers 06 Aug '02

06 Aug '02

Jecel, I finally got a chance to read your RFC, and have just a few comments... 1. simpler method/block story I don't know enough about how self currently works to properly comment. Are there any cons to this change? 2. simpler non local return Wouldn't this require that all objects have a default slot (^)? From what I can tell an object in self does not normally contain any slots by default. Am I wrong about this? 3. simpler syntax - no literals I really like this one - it seems like it could create a lot of currently unthought of possibilities. 4. simpler assignment story I'm sitting on the fence with this one. No comment for now. 5. removing inheritance from the base-level I'm not sure what you gain from this one. Personally I'd probably leave it out.

2 1

which ports of Self exist?
by Bjoern Winkler 03 Aug '02

03 Aug '02

Hi, I found a lot messages in the archive of this group about different ports of self to other platforms (Mac, Linux/386, Linux/PPC, JSelf, ...) - but it's quite hard to get the complete picture of all ports and where to download them out of the archive. Is there a web page listing all the ports? (If not, I would be very pleased if you send me any port you know so I could collect them and put a complete list on a public web page.) Regards, - Bjoern Winkler

2 1

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 August 2002