Self-interest August 1999

self-interest@lists.selflanguage.org

11 participants
9 discussions

Re: Grammar changes - comments?
by Randall.Smith＠Eng.Sun.COM 17 Nov '99

17 Nov '99

I must also say that even after programming in Smalltalk for years, I never missed not having cascades in Self. Maybe they just don't happen that often? At any rate, though they are a (possibly rare) convenience, having cascades would further distance Self from the Java/C programmer. (I have become of the opinion that some sort of pretty obvious syntax is almost a necessity for a language's acceptance. Java passed this hurdle by essentially re-using C/C++ syntax.) --Randy > From self-interest-return-287-Randall.Smith=Eng.Sun.COM(a)returns.egroups.com Mon Aug 30 12:47 PDT 1999 > Mailing-List: contact self-interest-owner(a)egroups.com > X-Mailing-List: self-interest(a)egroups.com > X-URL: http://www.egroups.com/list/self-interest/ > Delivered-To: listsaver-egroups-self-interest(a)egroups.com > Date: Mon, 30 Aug 1999 16:45:17 -0300 > From: Jecel Assumpcao Jr <jecel(a)lsi.usp.br> > MIME-Version: 1.0 > To: self-interest(a)egroups.com > Subject: [self-interest] Re: Grammar changes - comments? > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > > Using the "." for resends was a very unfortunate decision, and > your idea to replace it with "$" is a good one. I had suggested > using "::" since several other languages already use that for > similar purposes and Java (and Beta, in a negative way) showed > how important it is to have familiar elements in the syntax. > > About the cascades, you would need a "dup" bytecode (but since > you already were going to add it anyway this is no big deal). > I have never missed it when programming in Self, however. > > -- Jecel > > ------------------------------------------------------------------------ > Get help getting gigs! Guru.com will make your freelance work more > lucrative and more fun. Join us as we create the Internet's best resource > for independent professionals. http://clickhere.egroups.com/click/804 > > > eGroups.com home: http://www.egroups.com/group/self-interest > http://www.egroups.com - Simplifying group communications > > > > >

9 11

Re: Self on Linux
by Gordon Cichon 10 Sep '99

10 Sep '99

Hi, my vacation is over, I have to continue working on something else. Therfore I have less time now to continue with the Self port. I think that there is not missing too much to finally get a running system (with all the applications :-)). It all comes down to the stack walking code. In order to give others the chance to participate, too, I have put the stuff on the web server. Everybody who likes to see Self on Linux as soon as possible, and knows how to use a debugger is invited to help fixing the remaining problems. I will continue, too, of course. Maybe, I also made some mistakes... http://www.cichon.de/self/ -gordon -- ---------------------------------------------------- Gordon Cichon email: Gordon(a)Cichon.de ------------------------------------------------------------------------ eGroup home: http://www.eGroups.com/list/self-interest Free Web-based e-mail groups by eGroups.com

6 9

Caching method lookup smalltalk
by Stefan Matthias Aust 02 Sep '99

02 Sep '99

Hi! Currently, my interpreter lookup all methods every time they are called. I'd like to cache this somehow, but I'm unsure whether this works as lined out below. My approach is to assume a static inheritance hierarchy and then flush caches in all cases were this assumption was wrong. So far so easy. It's a well known optimization for Smalltalk systems, to cache <class, selector> -> <method> mappings. Class is the receiver's class, not the method's implementation class. This means, more than one key could reference to the same method. This kind of cache can remove about 80%-95% of all method lookups, depending on its size, the quality of the hashing algorithm used and of course the application. Can I simply replace "class" with "map object" in Self and use the same caching with the same results? Map objects are used to share common slot layout and behavior of objects. They're transparent to the user. Now, using #doesNotUnderstand in Smalltalk is not that uncommon and using DNU should be cachable, too. I'm not sure how to extend the mechanism, but I think, mapping <myclass, #foobar> -> <Object>>doesNotUnderstand:> after you noticed that #foobar doesn't exists, should be sufficient. Am I wrong? I recently read in comp.lang.smalltalk, that DNUs aren't slower than normal method calls anymore in most Smalltalk system so it can be optimized. But how? By the way, how does Self notify the user? Are 'doesNotUnderstand:' and 'ambiguousMessage:' (to make up two names, I don't know the right names at the moment) part of "defaultBehavior"? What if an object doesn't implement or inherit these messages? Are these messages sent to another object? Let's assume it would work so far. What if the inheritance graph changes? Flushing all caches would be a solution (of course) but can we find some better way please? If a map gets or loses a parent slot or a parent slot's value is modified, we have to flush all cache entries for that map and all maps which inherit from that map (further complicated because of the fact that inheritance isn't a nice tree but directed graph, not even anti-cyclic). To find them, we must either enumerate all maps and search or we must store back links, a list of direct submaps for each map. This seems to be difficult especially for dynamic parent slots, to which you could assign new values at any time. Are there better ways to cache slot lookup? Polymorphic inline caches are said to give even better caching results but there are more difficult to flush I think, because they are distributed over the whole code. You'd probably have to maintain a linked list of these caches. BTW, what's the best way to handle slots? The original Self paper describes map objects as sequential lists (or vectors) of slots. Searching for a slot means to compare selector addresses in sequental order. A very fast operation but unfortunately, but with a complexity of O(n/2). Smallalk traditionally uses hash tables (IdentityDictionaries actually). While it took some time to compute the hash code, it should be faster as typically a (good) hashing needs about 2 tries (it's O(2)). On the other hand, hash tables need more space (about twice as much, but minimal 25%-33% overhead). For some 25000 methods, this means about 100k. We've also to keep in mind, that if the lookup caching works, lookup is only performed in 10%-5% of all cases. So lookup speed isn't that critical perhaps. bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

2 3

Objects with dynamic slots
by Stefan Matthias Aust 01 Sep '99

01 Sep '99

Hi! In Smalltalk, you'd overwrite #doesNotUnderstand, if you want an object which understands messages to access something like slots you could define at runtime. (Assume you can't use a compiler) Object subclass: #Cluster instVarNames: 'values' etc. doesNotUnderstand: aMessage | sel | sel := aMessage selector. ^values at: sel ifAbsent: [ (sel argumentCount = 1 and: [sel first isLetter]) ifTrue: [value at: (sel copyWithout: $:) asSymbol put: aMessage arguments first] ifFalse: [super doesNotUnderstand: aMessage]] In Self, you could probably do the same, but is there a better way to do this? Why should the VM bother looking up methods which we already know don't exist. I think, Ian Upright sugested something similar on comp.lang.smalltalk. I'd like to customize method lookup, perhaps similar to this: cluster _setLookupAgent: ( | :mirror. :selector. slot | slot: mirror slotAt: selector IfAbsent: [mirror parents "etc"] ). The VM would then call the provided (anonymous) method object instead of using its default algorithm. You could even continue this idea and also allow hooks for method and primitive execution. A simpler way would be to have a special method, let's say cluster _setGate: ( | :selector. :arguments. | "..." ) which is called for every message that is directly sent to the cluster object (which is also the receiver of that method). While the gate method is executed, it's disabled to omit recusions. This could be implemented with a simple flag for every object (a hidden slot to store that method (or a well known slotname that's called from inside the VM)) and a counter to temporary disable the mechanism. Or is the SELF (actually mySelf, as I haven't looked up whether these messages and primitives really exist in Self ;-) solution as simple as cluster = (| parent = defaultBehavior. "note, no parent slot!" values. "where to store the values" clone = (_clone values: dictionary clone). " doesNotUnderstand: aMessage = ( values at: aMessage selector IfAbsent: [ "etc". "otherwise..." aMessage delegateTo: parent] "forward message to parent" ) |) This allows us to intercept even inherited messages - something which isn't possible in Smalltalk. The only problem is to hide "parent" and "value", perhaps by renanming them to "hidden_parent" or "my_values". Thank you for listening, I think I found the answer :-) bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

2 2

Grammar changes - comments?
by Stefan Matthias Aust 30 Aug '99

30 Aug '99

Hi! For mySelf, I want to slightly change the Self grammar as follows... expression = keywordMessage. keywordMessage= binaryMessage {keywordSend} | resend keywordSend. keywordSend = smallKeyword keywordMessage {capKeyword keywordMessage}. binaryMessage = unaryMessage {binarySend} | resend binarySend. binarySend = operator unaryMessage. unaryMessage = receiver {unarySend} | resend unarySend. unarySend = identifier. [...] resend = [identifier] '$'. In contrast to Self, I use '$' to define delegation. Instead of "resend.x" you'd write "$x" now which is similiar to implicit self sends. What do you all think about this? It's much easier to parse and removes the special treatment of the "." which had to be followed by no whitespace. While you'd typically use no whitespaces with "$", you could do this if you want. Furthermore, I'm thinking about adding the ";" cascade operator from Smalltalk to mySelf. I'm pretty new to actually code in Self, but newPair: key Value: value = ( | pair | pair: (| parent* = defaultBehavior. key. value |) clone. pair key: key. pair value: value. pair ) looks ugly IMHO. I'd prefer newPair: key Value: value = ( | pair = (| parent* = defaultBehavior. key. value |) | pair clone key: key; value: value ) Comments? bye -- Stefan Matthias Aust // Bevor wir fallen, fallen wir lieber auf.

3 3

compact encoding
by Jecel Assumpcao Jr 29 Aug '99

29 Aug '99

I decided to check out if the compact encoding I proposed a while ago (with two bits per instruction mixed in the the literals) was a good idea or not. So first I got me a list of all the methods in the system (actually, their mirrors): enumerating all enumerate asList copyFilteredBy: [|:e| e isReflecteeMethod] This yields a list of 26320 elements in the normal Snapshot. Then, in this list, I evaluated the following expression to see how the coding would effect each method: | d <- dictionay copyRemoveAll | do: [ | :m. delta <- -4 | "delta starts out with -4 since we will no longer need a bytecode object for each method, and each bytevector object has 4 words of overhead" delta: delta - (m codes size /+ 4). "here we also discount the bytes themselves, coverting them to a rounded up number of words" delta: delta + (m codes size /+ 15). "on the other hand, the instructions now add words to the literal vector. But now we pack them 15 to a word" m byteCodesDo: [ | :bci. :op. :lit | delta: delta + 1. "we suppose that every single instruction will need exactly one literal. Note that in the case of pushSelf that originally didn't need a literal, now we have changed it to implicitSend 'self' which does need a literal" op = bytecodeFormat opcodes resendOp ifTrue: [delta: delta+1]. "by converting resends to use primitives, we will need an extra literal for them" op = bytecodeFormat opcodes return ifTrue: [delta: delta-1]. "return instructions don't need a literal, so we correct our mistake here" ]. delta: delta - m literals size. "since we want to know how many words are added to the literal vector, we have to discount how many were in there before" d at: delta Put: (d at: delta IfAbsent: 0) + 1. "count yet another method with delta amount of memory words added" ]. d So now we have a 70 element dictionary that has as keys the number of words that my enconding scheme would add to Self and as values the number of methods that will increase by that amount. Some simple expressions will reveal that: number of methods that increase or stay the same: 959 memory increase due to these methods: 8200 words number of methods that decrease in size: 25361 memory decrease due to these methods: 102380 words total memory gain due to new encoding: 94180 words Since that is almost half a megabyte, it might turn out to be a good idea after all. Another space saving measure (I haven't tested this one to see if it is any good) would be to allow singleton objects to be their own maps. Only when a new object is copied for the first time would we bother to separate it from the map. That might save some memory for all these methods. -- Jecel

2 2

resends
by Jecel Assumpcao Jr 29 Aug '99

29 Aug '99

I have been thinking about resends, lately. I don't like them as they are. Here is the statistics for the bytecodes for the 26339 methods in the standard snapshot: implicitSend 81590 send 62233 literal 27795 pushSelf 4639 return 4158 index 3233 resendOp 598 delegatee 17 This means we have 581 undirected resends and 17 directed ones. Given the small number of directed resends and their awkwardness (two bytecodes), I had worried the most about them. But now I am thinking if we really need the undirected resends? They were certainly important when we had parent priorities in early Selfs and complex tie breaker rules. But in modern Self it would be no big deal to always specify in which parent the lookup should proceed. Moving slots around so that this parent would change is much less likely to happen now. The reason I am thinking about this is that I would like to replace resends with a more general explicit delegation mechanism. Where we now have comparisonParent.isLessThan: arg we could do (helpers at: i).isLessThan: arg Hmm... I remember that it was possible to do this with primitives in early Selfs, but can find nothing like it in either Self 3 or Self 4. Anyway, the use of the "." for the resend syntax was a needless complication. Maybe the more popular "::" would be easier to parse? Anyway, directed resends fit in perfectly with the semantics of delegation (lookup in another object but use me as "self") while undirected resends do not (lookup in me bu skipping any slots with the same name). -- Jecel

2 1

(print objects)
by maria 28 Aug '99

28 Aug '99

Hello everybody, I am Maryah and I have finished an aplication on self, now I want to write some documentation about my work and I have a question: - How can I print the objects of my aplication?. I read this document: " Prototype-Based Application Construction Usuing Self 4.0" by Mario Wolczko and Randall B Smih and I would like to do something similar. Thanks for your help: Maryah

2 3

Self hardware
by Jecel Assumpcao Jr 10 Aug '99

10 Aug '99

Hi, friends! I've been without internet access for the past couple of weeks and am only now catching up with my email, including the discussions on this list. I thought you might be interested to know that I am typing this from the offices of "Merlin Computer Technology", the first company dedicated to producing hardware implementations of Self. We hope to be selling our first product (Merlin 6) by the Christmas season - I can post some details about it if there is interest. That doesn't mean that I have forgotten about software implemetantions for PCs and such! They'll be coming along. This new company will soon have its own web site, and there will also be a special web server written in Self called "Self Projects". The pages for this site will be editable and there will be space for all Self related projects. -- Jecel

8 12

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