Self-interest November 1995

self-interest@lists.selflanguage.org

21 participants
34 discussions

undo (was: wish list)
by Jecel Mattos de Assumpcao Jr. 01 Nov '95

01 Nov '95

[ David Bruce wrote a lot of neat things about versioning ] Thanks for finding the Wilson&Moher reference - I just found a reference in another paper: "Demonic memory for process histories" Wilson, Paul R. and Moher, Thomas G. Proceedings of the ACM SIGPLAN 89 Conference on Programming Language Design and Implementation Portland, Oregon, June 21-23, 1989, pp.330-343 I'll look into the other references you mentioned. I have thought a little more about this subject - a system that would only let you back up the whole world to some point in the past (it might even make this past read-only) would be enough for what I want as long as you could use the transporter (or something like it) to bring a clone of selected objects into the present! This wouldn't help your simulator at all, of course, since you aren't interested in a mostly linear time but in a "branching" time. Anyway, for my application the past must be stored in a highly compressed form. Having the last N versions of objects hanging around would increase memory requirements - hardly what Self needs to be more popular :-) -- Jecel

1 0

Re: wish list
by dib＠signal.dra.hmg.gb 01 Nov '95

01 Nov '95

( > > [ I claimed undo needed VM support ] ) > ( > Would like to hear your ideas on this one in particular. What are you ) > thinking? A redo of the assignment primitive to keep a reference to the ( > last N old values ?? ) ( That would be a bit better than using something like "rawColor" slots ) to save old versions, but would not be too efficient - versions, like ( wrappers, tend to spread and contaminate the whole system. ) ( Actually, I am not sure what should be done, but I feel it must be ) integrated with the garbage collector and the persistent store ( system. The best idea I have seen so far is Paul Wilson's "Deamonic ) Memory", but he seems to have gone in other directions now. I can ( try to get a reference, if there is interest. Anyway, his system ) would let you back up the whole system to any point in the past. ( That is not what I want. I want to be able to back up a certain set ) of objects to any point in the past (and even have some of them ( coexist with their current versions!). ) ( Of course there must be a high-level "hook" to all this so the user ) can control this from the user interface, but I don't think a good ( solution can be made only at the programming environment level (though ) a cumbersome one could - a kind of copy-down in time :-) Wilson&Moher's paper was in PLDI'89. Greg Johnson and Dominic Duggan had a language called GL that allowed one to revert to previous states, intended for exploring various debugging techniques. They had a POPL'88 paper; the journal version (Computer Languages, 1994) has a little more about the implementation. Using a caching strategy they found only a modest slow down (~30%), though I don't know how what their benchmarks involved. Greg Morrisett at CMU has also done related work: see his paper "Generalizing First-Class Stores" in the 1993 State in Programming Languages workshop; some of the Venari work follows similar lines. Morrisett's work allows the state to be partitioned as you want, and gives an explicit handle on the different states to which one might wish to revert to. Blowing my own trumpet, I am investigating the use of versioning like this for parallel simulation, where undoing is an intrinsic part of the (optimistic) protocols. (Here "time" delimits the consistent states.) Most systems expect the user to write the state saving code; I have an "automatic" technique. [As Randy suggests, I start by patching the assignment operator; there's a bit more machinery needed so that one can control what's going on.] My results so far show that the performance penalty is not totally punishing, despite (for my sins) working in C++ where allocating memory is more expensive than I'd like. For more details, see my paper "The treatment of state in optimistic systems" in the 9th Workshop on Parallel and Distributed Simulation (1995), or ask. David Bruce ---- post: DRA Malvern, St Andrews Road, Malvern, Worcestershire WR14 3PS, ENGLAND email: (internet) dib(a)dra.hmg.gb or dib%hermes.mod.uk(a)relay.mod.uk phone: +44 1684 895112 ** fax: +44 1684 894389 or 894540 ** telex: 339747

1 0

The name of LISTSERV
by Mehdi.Alipour＠ki.ericsson.se 01 Nov '95

01 Nov '95

Hi May some kind soul send the LISTSERVs mail address of the self-interest(a)self.sunlabs.com mailings list. Thanx in advance. /erameal

1 0

Re: wish list
by Jecel Mattos de Assumpcao Jr. 01 Nov '95

01 Nov '95

Sorry if there is line noise - my connection is getting worse each day... Tue, 31 Oct 1995 09:08:38 +0800, Randall.Smith(a)Eng.Sun.COM (Randy Smith) wrote: > > [ my HotSelf idea ] > > > Dave and I sat down and added this in about 15 minutes! Press a > button and end up with some new self object in your hand. That's great!! Does this mean I get two more wishes ;-) ? I assume this happens when the broswer find a line like <a href=xxx.self>click me </a>, right? How about having <app=xxx.self> show the resulting object inside the page? Better yet - make <img src=xxx.gif app=xxx.self> show the object in the page, and an image of the object in a dumb browser. > > [ I claimed undo needed VM support ] > > > Would like to hear your ideas on this one in particular. What are you > thinking? A redo of the assignment primitive to keep a reference to the > last N old values ?? That would be a bit better than using something like "rawColor" slots to save old versions, but would not be too efficient - versions, like wrappers, tend to spread and contaminate the whole system. Actually, I am not sure what should be done, but I feel it must be integrated with the garbage collector and the persistent store system. The best idea I have seen so far is Paul Wilson's "Deamonic Memory", but he seems to have gone in other directions now. I can try to get a reference, if there is interest. Anyway, his system would let you back up the whole system to any point in the past. That is not what I want. I want to be able to back up a certain set of objects to any point in the past (and even have some of them coexist with their current versions!). Of course there must be a high-level "hook" to all this so the user can control this from the user interface, but I don't think a good solution can be made only at the programming environment level (though a cumbersome one could - a kind of copy-down in time :-) This is *the* major missing piece for Merlin. If I can't solve this, then the system will be too dangerous for normal use (at least Self 4.0 has snapshots...) --- Jecel

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 November 1995