Self-interest February 1991

self-interest@lists.selflanguage.org

10 participants
24 discussions

Re: simple line graphics
by vme131!jecel＠uunet.UU.NET 08 Feb '91

08 Feb '91

Thanks for the hint. It's not as hard as I thought it would be. Here is a simple test I came up with after browsing the bitmap.self, draw.self and screenBitmap.self files : ( | g. | g: heightLimitedScreenBitmap copy. g initialize. g fillRectangle: 1 @ 1 To: 400 @ 400 Color: colors white. g changeFont: 'screen.b.14'. g text: ( paragraph copyLines: ' triangle ' ) At: 50 @ 50. g xorLine: 10 @ 10 To: 5 @ 200. g xorLine: 5 @ 200 To: 300 @ 100. g xorLine: 300 @ 100 To: 10 @ 10. g release. ) Adding waveforms to my simulator should be a snap ( once it starts working again - I'm "cleaning it up" and it caught some nasty bugs ). Jecel - University of Sao Paulo - Brazil

1 0

bug fix
by Urs Hoelzle 06 Feb '91

06 Feb '91

I published an updated version of Self which fixes a bug discovered by kjx(a)comp.vuw.ac.nz. As an additional goodie, the new version also contains the option _SnapshotCode. If you set _SnapshotCode:true, snapshots will include compiled code. This is a minor update; no other features of Self have changed. -Urs

1 0

Re: postProgrammingAction
by Urs Hoelzle 06 Feb '91

06 Feb '91

> We no longer see any documentation on postProgrammingAction, and it > seems to have disappeared from the image also. Until the programming > primitives return normally, is there any way to use them from within a > program? > Yes, we cut postProgrammingActionfrom 1.1 because it was such a hack and we didn't think anybody would use it ;-) Plus it didn't really work in all situations, and real "programming" is close. I suggest you live with either of the following workarounds: 1) Use Self 1.0 and wait for the next version which includes programming. 2) Use _RunScript to do the job, i.e. write the string to be evaled to a file, followed by a line like "myUI restart". This will work because Self keeps reading from the script file until EOF (or until some error occurs). Hope that helps, -Urs

1 0

postProgrammingAction
by dje＠scs.carleton.ca 05 Feb '91

05 Feb '91

We have just started using SELF 1.1, after doing some work in SELF 1.0. We have created a simple environment that allows me to type in expressions and evaulate them while in the ui. The plan is to expand this to allow editing of code from within the ui. We no longer see any documentation on postProgrammingAction, and it seems to have disappeared from the image also. Until the programming primitives return normally, is there any way to use them from within a program? If not, could you release a version of SELF that has returning programming primitives as soon as possible. Thanks, Danny Epstein = dje(a)scs.carleton.ca Eric Arseneau = eat(a)scs.carleton.ca

1 0

Re: a digital simulator in Self
by ungar＠Eng.Sun.COM 02 Feb '91

02 Feb '91

A circuit simulator--neat! I would be very interested in hearing about the ways you found to use the features in Self to model circuits. (For example, do you use dynamic inheritance to model the two states of a flip-flop (if this is a gate-level simulator)? Also, I would be very interested in any performance results you can measure. How does it seem? Are the floats working OK for you, or is their limited range a problem? David

1 0

simple line graphics (re: a digital simulator in Self)
by bay＠amuck 02 Feb '91

02 Feb '91

The Self release supports much of Sun's Pixrect package. These should be adequate for the type of drawing you want to do. And you don't really have to wade through all of the ui to figure out how to use it; but granted, it's the only example of how to use the graphics objects that are included in the release. Look at the files bitmap.self draw.self screenBitmap.self Or, you can build your own objects based on the pixrect primitives; see pixrect.self and prPrims.self. This might be easier. Bay

1 0

Re: inheriting data slots
by bay＠amuck 02 Feb '91

02 Feb '91

> 3) use _AddSlots: and _RemoveSlots: like this (this is using the old > conventions): > prototypes _DefineSlots: (| > TDpoint = (| > parent* = traits TDpoint. > z > |) > |) > "inheriting is a global variable" > inheriting: prototypes point copy > inheriting _RemoveSlots: 'parent' > prototypes TDpoint _AddSlots: inheriting You can achieve this without the "evil global" in this way (using the new programming primitives--note that _Define: makes the receiver 'look just like' the argument object by removing all slots in receiver and adding slots found in the argument to the receiver): prototypes _AddSlotsIfAbsent: ( | TDpoint = () | ) TDpoint _Define: point "now TDpoint looks just like a (2d) point" TDpoint _AddSlots: ( | parent* = traits TDpoint. "overwrites the parent slot" z <- 0. "adds new data slot" | ) This, like method #3 above, relies on the convention that the parent slot is named "parent". (This is the one piece of information that TDpoint needs to know about the prototype point.) New programming primitive note: ------------------------------- It may be tempting to fold the first two lines into one, thus: prototypes _AddSlotsIfAbsent: ( | TDpoint = point copy | ) But this should not be done: if the prototype point object is changed (say you add a slot for its color) and you re-read in the script file that defines this TDpoint, _AddSlotsIfAbsent: will see a slot called "TDpoint" already in prototypes, and have no effect. Then the TDpoint prototype won't have a chance to get a copy of the new color slot. In general, the slots in _AddSlotsIfAbsent: should always be initialized to () (an empty object), and all useful programming should be done outside of it, via _Define: and _AddSlots:. This is to avoid situations like the one above. (The one exception is for objects that want to have a byteVector or objVector part--these need to be initialized to a copy of [byte]vector in _AddSlotsIfAbsent:, since _Define: only affects slots.) Bay

1 0

Re: inheriting data slots
by ungar＠Eng.Sun.COM 02 Feb '91

02 Feb '91

That's neat! I never thought of that. This is another good reason why we need to make _AddSlots: etc, work without cutting back the stack. We will release a system with this feature as soon as we can. In fact, Urs has done a lot of work towards achieving this goal! David

1 0

Mailing list
by eat＠hans.scs.carleton.ca 01 Feb '91

01 Feb '91

I would like to be included on your mailing list, as I am currently using Self at Carleton University, Ottawa Canada, along with Danny Epstein, also of the same school. Thank you, Eric

1 0

inheriting data slots
by burdick＠mentor.cc.purdue.edu 01 Feb '91

01 Feb '91

[I accidentally sent this before my $.02 was spent, so here's the full version] Write once slots would do it, but I don't see why adding the slots of data parents of prototypes would slow things down. Maybe my first letter wasn't clear... You don't need to add the slots of data-parents at 'run-time,' that is, you only need to do this in order to construct the prototypes, not to construct the clones. Once you have all the slots in the right places, you can just clone the prototype and everything is fine. For instance, if you have a 2-d point (with slots: parent*, x, and y) where parent holds traits point, and you want to make a 3-d point (with slots parent*, x, y, and z), where parent holds traits TDpoint, you can construct the prototype in these three ways (there are more, but here are 3): 1) make it by hand; just define it as (| parent* = traits TDpoint. x = 0. y = 0. z = 0 |). This will work, but it makes for unmaintainable code -- you'd probably end upwriting a script to propogate changes in data parents to the children prototypes. 2) use a data parent and redefine copy: (| parent* = traits TDpoint. dataParent** <- prototypes point. cloning*** = traits deepClonable. z = 0 |) where deepClonable contains rules for copying through data parent slots. The problem here is that dataParent is assignable and so it will slow down access to data in slots inherited from the dataparent. 3) use _AddSlots: and _RemoveSlots: like this (this is using the old conventions): prototypes _DefineSlots: (| TDpoint = (| parent* = traits TDpoint. z |) |) "inheriting is a global variable" inheriting: prototypes point copy inheriting _RemoveSlots: 'parent' prototypes TDpoint _AddSlots: inheriting Using method #3, you get a prototype with all the slots it 'inherits' from its data parent, and you can use it with good performance. This is possible right now, but it's a little clumsy -- it would be easier to maintain (and prettier) if we could use _AddSlots: and _RomoveSlots: from within methods so that the inheritance code could be one message instead of three (and you wouldn't need an evil global). This method of data inheritance may even become as robust as Smalltalk's, if the right primitives are there to do updateInstances. I still have to look throught the list of primitives -- I need one that will give me a list of everyone who is pointing to me (or let me step through them), which sounds possible, from what I've read. Once I have that, I can propogate changes through the inheritance hierarchy. Until then, I can get by with loading the file and reinitializing my data space. -- Bill

1 0

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 February 1991