Self-interest August 1992

self-interest@lists.selflanguage.org

26 participants
29 discussions

Re: Persistence and Transactions
by keith＠Uniteq.COM 01 Sep '92

01 Sep '92

> From Eng.Sun.COM!David.Ungar(a)netcomsv.netcom.com Fri Aug 28 11:42:19 1992 > Date: Fri, 28 Aug 92 11:16:14 PDT > From: Eng.Sun.COM!David.Ungar(a)netcomsv.netcom.com (Dave Ungar) > To: self-interest(a)self.stanford.edu, keith(a)Uniteq.COM > Subject: Re: Persistence and Transactions > Content-Length: 456 > > Nothing concrete, I'm afraid. We mull it over from time to time. > Why? > > Dave > > > > > Are there plans for providing object persistence and transactions? > > Snapshots are very limited in that the entire environment is saved. > > In order to be able to provide applications that have saveable state, > > are reliable, and that support multiple-user sharing of objects, persistence > > and transaction management should be an integral part of the Self environment. > > > > > Our company is doing object persistence and transactions for our system and I thought it would be nice to have a language that supports it more directly than the kludge-arounds that have to be done for C/C++.

2 1

Re: Persistence and Transactions
by David.Ungar＠Eng.Sun.COM 28 Aug '92

28 Aug '92

Nothing concrete, I'm afraid. We mull it over from time to time. Why? Dave > Are there plans for providing object persistence and transactions? > Snapshots are very limited in that the entire environment is saved. > In order to be able to provide applications that have saveable state, > are reliable, and that support multiple-user sharing of objects, persistence > and transaction management should be an integral part of the Self environment. > >

1 0

Persistence and Transactions
by keith＠Uniteq.COM 27 Aug '92

27 Aug '92

Are there plans for providing object persistence and transactions? Snapshots are very limited in that the entire environment is saved. In order to be able to provide applications that have saveable state, are reliable, and that support multiple-user sharing of objects, persistence and transaction management should be an integral part of the Self environment.

1 0

Re: Self Size
by Bay.Chang＠Eng.Sun.COM 27 Aug '92

27 Aug '92

> [... objects in the ui don't move to cursor right away ...] > If you click on an object and move off of it fast enough, nothing > happens until you move the mouse again, at which point the object > snaps to the mouse point. So click, move fast, and _stop_. Wait as > long as you like, and nothing will happen. Then jiggle the mouse, > just a bit, and the object jumps to the mouse position. You're right, this is buggy behavior. We have it fixed, but it wasn't included in the release. (It had to do with waiting for a separate Self process that was in charge of getting X events--that process blocks while waiting to receive the next X event, and wouldn't cede control over to the cursor until it woke up by receiving some X event; in this case, a cursor motion event generated by the extra mouse jiggle.) Bay

1 0

So, you think you've got ui problems.
by clayton＠cc.gatech.edu 25 Aug '92

25 Aug '92

While running on openwindows ver 2.0 (under olwm, under sunos 4.1.1), I tried to drag the lobby box from right to left got this: sy self ld.so: warning: /usr/lib/libpixrect.so.2.11 has older revision than expected 14 ld.so: warning: /usr/lib/libc.so.1.6 has older revision than expected 7 Self Virtual Machine Version 2.0, Aug 7 1992 15:40:33 Copyright 1989-92: The Self Group (type _Credits for credits) reading ~/.selfrc Self 1> spyOn false Self 2> ui start initializing ui...creating colormap series . . . . . . . . . . . . done. done. uiX Self 3> creating colormap series . . . . . . . . . . . . done. Saved ui colors to file: ui.colors. Internal error: signal 10 code 2 addr 0xf7750400 pc 0xf7750400. Do you want to: 1) Quit Self 2) Try to print the Self stack 3) Try to return to the Self prompt 4) Force a core dump 5) Loop forever Your choice: I got the same thing doing the same thing when running from the console. The problem, I guess, is obvious, but one never knows.

1 0

Requests for mailing list changes
by moss%ibis＠cs.umass.edu 25 Aug '92

25 Aug '92

It continues to amaze me how few people know that the standard Internet mailing list protocol for adminstrative changes to list foo@site is to send mail to foo-request@site. In this case, requests to be added to, removed from, etc., the self-interest list should go to: self-interest-request(a)self.stanford.edu. When you send requests for such actions to self-interest you are wasting resources by sending the message to everyone on the list, and annoying us in the bargain. Most of us cannot do anything about your request, either. Thanks, and I now return you to your regularly scheduled mail and news ..... EM J. Eliot B. Moss, Associate Professor Department of Computer Science Lederle Graduate Research Center University of Massachusetts Amherst, MA 01003 (413) 545-4206, 545-1249 (fax); Moss(a)cs.umass.edu

2 1

Delete my name please.
by cspw＠alpha.ru.ac.za 25 Aug '92

25 Aug '92

Hi - can you please delete my name from the group. Thanks -- EP Wentworth - Dept. of Computer Science - Rhodes University - Grahamstown. cspw(a)alpha.ru.ac.za

1 0

Name removal from mailing list
by Christopher J. Lewis 24 Aug '92

24 Aug '92

Please remove my name from your mailing list. Thank you. Chris Lewis (lewisc(a)ucsu.colorado.edu)

1 0

Re: Self Size
by David.Ungar＠Eng.Sun.COM 24 Aug '92

24 Aug '92

There are also other possibilities: Which framebuffer are you using? Is your machine thrashing? Just how slow is it? (It should seem OK on a 1+ -- I'm not sure what is going on here) Dave > From owner-self(a)self.stanford.edu Fri Aug 21 16:57:33 1992 > Date: Fri, 21 Aug 92 16:55:29 PDT > To: rwk(a)quark.sbi.com > Cc: self-interest(a)self.stanford.edu > In-Reply-To: <9208212133.AA18405(a)quark.sbi.com> (rwk(a)quark.sbi.com) > Subject: Self Size > > Richard> Why does Self require so much memory? > > 1. Because we trade space for speed in certain places ("memory is > cheap"). > 2. Because we have not optimized things for space. I.e. we know > how to reduce the size of the code space and the object heap > by around a factor of two, but we just haven't gotten around to > implementing this space engineering. > > Richard> The Self UI runs somewhat slowly. The performance benchmarks > Richard> quoted in the various Self documents would make me think the > Richard> UI would be quite snappy. > > Richard> Why isn't it? > > 1. Because the compiler(s) are sometimes slow (that's why things run > slower the first time you do them). > 2. Because the compilers aren't perfect (yet :-). Note that we do > not claim that *all* Self programs are x% of C - just the > benchmarks. Also, the default system does *not* use the optimizing > compiler for all compilations. Rather, it compiles unoptimized > code first (to reduce compile pauses) and reoptimizes later when > it sees that some code is frequently used. Unfortunately, the > system doesn't always recompile the right thing, so the resulting > code may be slower than if it had been compiled in optimizing mode > the first time. > > Richard> I am a fan of Scheme and its functional syntax. Could a > Richard> functional "front end" be written for Self? Not necessarily > Richard> Scheme compatible, just "lisp-ish". > > I guess it could...just try it! :-) > > -Urs > > PS: We're actively working on both the space and the speed problems! >

3 2

deleting name from the group
by stan＠iscs.nus.sg 22 Aug '92

22 Aug '92

Could you please delete me from the distribution list for this group. Thank you. stan@nusdiscs

2 1

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 1992