Self-interest December 1992

self-interest@lists.selflanguage.org

7 participants
10 discussions

Re: Unwind-Protect and Jumping into the Abyss
by R James Noble 19 Dec '92

19 Dec '92

Regarding _ContinueUnwind .. I haven't heard of anything like this either - tho' I'll poke around a bit. Another (baroque) feature - it may be useful to continue the unwind with a different return value. I think in most cases an implicit _ContinueUnwind should be performed, so I'd probably put one into the Self wrapper on _UnwindProtect and (if merited have some extra syntax for "dont unwind" ). However, I recall a article by someone from ParcPlace (L. Peter Deutsch) talking about the design of the new Smalltalk exception mechanism (I'm at home, references are at work). I think the main point was that although his design allowed things like restartable exceptions with fine control, this was unnecessary in pratice and ended up complicating matters, requiring extra housekeeping (comments from the more knowledgeable warmly invited). Also, non local returns that can end up anywhere are quite a significant addition to the programming model. Though they may turn out to be useful, I'm not sure how they fit in with the minimalist aesthetics of Self. Urs writes > Though less flexible than the first proposal, this solution seems > more intuitive and easier to understand. Comments? See above, but ultimately, I'd vote for whatever's easiest to do. I thought _ContinueUnwind was a bit strange at first, but the last time I raised this with the group, someone mentioned that there may be problems building unwindProtect with the current arrangement primitives in the compiler. So I figured that the _ContinueUnwind was just a way of getting around these problems :-) Merry Christmas James

1 0

Re: Unwind-Protect and Jumping into the Abyss
by ungar＠Eng.Sun.COM 18 Dec '92

18 Dec '92

I vote for trying the simplest thing first-- ANY unwind protect is scads better than none. Dave

1 0

Re: Unwind-Protect and Jumping into the Abyss
by urs＠cs.stanford.edu 18 Dec '92

18 Dec '92

> I'd never heard of ContinueUnwind - do any other languages support > it? I have no idea. It gives you somewhat more flexibility, but I'm not sure how useful it would be to *not* continue the original non-local return. A simplified proposal would be to always complete the original NLR after the protect block finishes executing. I.e. in the following code, foo1 and foo2 are identical to foo except that they print a message. caller = ( foo: [ ^nil ]. 'caller' print ). "or foo1 or foo2" foo: blk = ( blk value ). "no protection" foo1: blk = ( blk unwindProtect: [ 'foo1' print ]. 'bar' print ). "bar will never be printed because blk always does a NLR" foo2: blk = ( blk unwindProtect: [ ^ 'foo2' print ] ). "the NLR in the protect block is ignored, 'caller' will not print" Though less flexible than the first proposal, this solution seems more intuitive and easier to understand. Comments? > What about nested unwind protect blocks? If an outer unwind protect does > a continue unwind, do inner protected blocks get executed first? I guess > that would make sense, but perhaps not always. What if the inner protected The protect blocks "belong" to their enclosing scopes, and they are executed just before that scope would return. That is, the non-local return "unwinds" the stack and executes the protect blocks as it goes along. -Urs

1 0

no subject (file transmission)
by Charles Fiterman 18 Dec '92

18 Dec '92

>I'd never heard of ContinueUnwind - do any other languages support it? > >What about nested unwind protect blocks? If an outer unwind protect does >a continue unwind, do inner protected blocks get executed first? I guess Yes inner blocks run first. >that would make sense, but perhaps not always. What if the inner protected >block closed something that needs to remain open in order to continue >the execution? That would be a bug. The function of unwind protect blocks, also called always blocks because they always get to run when a function ends, is that each block gets to clean up after itself. If a block opens a file it gets to close that file even if something it calls does some form of exit. Unwind protect blocks are most usefull in languages that support backtracking and generators. A function opens a file and returns a record by suspending when backtracked it returns the next record. If control passes outside the range where the function can be backtracked the function's always block is called and the function gets to close its file. Unwind protect blocks can clearly be misused, so can anything. Their function is to improve modularity by allowing functions to do their own cleanup. A usefull friend of these blocks is the abort string. The abort string is normally null. Functions signal serious error by placing a messages on the abort string. When the abort string is non null control begins falling through unwind protect blocks. While in such a block control proceeds normally. The unwind protect block may clear or add to the abort string. If it becomes null again control passes normally. In terms of practical programming few error conditions can be expressed as an int, which is what most error flags are. Further if you call a system function such as open and fail 99% * of the time all you can do is give a message and die. Successfull languages like Pascal often do that with no recource. 1% of the time there is something intelligent to do if open fails, but that 1% occurs in system software. Having open put a message on the abort string gives the best of both worlds, you crash normally but with a little trouble you can recover. In general the function that detects an error can create the best error message, its caller may be able to add details. This strategy encourages exactly that. * 96.7 precent of statistics are made up on the spot.

1 0

Re: Unwind-Protect and Jumping into the Abyss
by liberte＠cs.uiuc.edu 17 Dec '92

17 Dec '92

I'd never heard of ContinueUnwind - do any other languages support it? What about nested unwind protect blocks? If an outer unwind protect does a continue unwind, do inner protected blocks get executed first? I guess that would make sense, but perhaps not always. What if the inner protected block closed something that needs to remain open in order to continue the execution? dan

1 0

Re: Unwind-Protect and Jumping into the Abyss
by R James Noble 17 Dec '92

17 Dec '92

description of proposed _UnwindProtect: and _ContinueUnwind > this primitive pair would probably cover > most cases and would be relatively simple to implement as long as > super-high performance is not the main goal. Performance - this is _research_ :-). Any performance is preferable to none, and I think these should do the trick. Presumably the _ContinueUnwind call could be hidden in the Self wrapper for unwindProtect: >> "NLRs across process cause the process to terminate" > Gee, I though nobody would ever discover this :-) It was only a matter of time :-). Actually, I think the current behaviour is quite sensible. It allows me to fake non-lifo blocks by creating them then permantly suspending the process. But an NLR causing another process to resume seems rather strange. > We've been planning to put unwinf protect into the system for a while As ever, this would make my life a lot easier. James

1 0

Unwind-Protect and Jumping into the Abyss
by R James Noble 17 Dec '92

17 Dec '92

[Apologies if some if this is obvious to many of you - kjx] As some of you may know, I'm trying to write a program visualisation system in Self for a doctoral thesis. This is based upon an mechanism for generating events whenever something interesting happens in a Self program (the events are fed to other Self objects to produce the visualisations - papers available on request :-). Events can be easily generated when messages are received by an object, when methods return normally. Currently, I can't handle non-local method completion, (that is the "^" operator) - these message completions are ignored. This has only been a theoretical problem so far, however, gradually scaling up the size of programs I'm trying to visualise, I seem to have reached a point where I need to be able to handle non-local returns in the event system. Now several other languages incorporating non-local exits (Smalltalk, Lisp and even VAX Pascal) include an "unwind protect" construct which would trap non-local returns, allowing some action to be taken "on the way up the stack" so to speak. Something like this would allow me to generate the appropriate events and hopefully visualise the programs currently giving me trouble. So while I try to find ways to avoid the non-local exits in the code in question, this is another plaintive cry asking if anyone has ideas about incorporating unwind-protect into Self. Given that the VM source code is now available, I suppose I could try that - does anyone have any idea how difficult it would be? (in passing - how have people outside the Self group found the VM code to work with). Another alternative would be to move the whole event mechanism inside the VM - but I'm sure that would be even more work. Another related question, (discovered when poking around these things) is what happens to blocks that perform a non-local return where the method returned to is not in the running process. (Yes, I was attempting a work-around where the protected code would be run in another Self process). However, a non-local return in this case seems to terminate the process without a return value. Some example code is appended below. Thanks James "what's happening here" lobby _AddSlots: (| foo = (| parent* = traits oddball. a = ( 'foo a called' printLine. 'foo a stores magic block' printLine. blk: [ 'blk called' printLine. ^'magic-return'.]. 'foo a stores process number' printLine. prc: process this. 'foo a suspends' printLine. process this suspend. 'foo a invokes block' printLine. blk value. 'foo a returns' printLine.). blk. "holds block" prc. "holds process" |) |) "Now, run these commands from the prompt" " foo a [foo blk value. ^'where does this go?'] value foo prc resume "

2 1

weird performance bug discovered
by ungar＠Eng.Sun.COM 06 Dec '92

06 Dec '92

If you have any programs that add slots to or redefine an empty object, try "_CanonicalizeMaps: false" Your program just might run a whole lot faster. Dave

1 0

Re: glue for libraries?
by Ole Agesen 02 Dec '92

02 Dec '92

Rob Reiss asks: > Is is possible to create glue for just a couple functions that are > part of a larger pre-compiled standard library. Yes - I've done this quite successfully for large bits of Xlib with the standard release Self compiler. > But when I try to call the function in Self the functions bomb because > they are not linked to the libcps.so file. Can I link the libcps.so > file into this one somehow? The trick is to _statically_ link the library into the .o file while making the .so file. Given your SmallFile.o ld -o SmallFile.so SmallFile.o -Bstatic -lcps Yes, this should be the safest bet. However, under SunOs 4.1.2 the Bstatic should not be needed since the 4.1.2 version of ld.so has been extended to do "transitive closure" of dynamic libraries. You'll still need the -lcps, just not the -Bstatic. No guarantees, though.... This worked for me under SunOS and gcc - of course, your mileage may vary. (At least we don't need sed on the assembler any more :-) James James Noble, Graduate Student, Computer Science Department Victoria University, Box 600, Wellington 1, New Zealand kjx(a)comp.vuw.ac.nz Ole

1 0

glue for libraries?
by R James Noble 02 Dec '92

02 Dec '92

Rob Reiss asks: > Is is possible to create glue for just a couple functions that are > part of a larger pre-compiled standard library. Yes - I've done this quite successfully for large bits of Xlib with the standard release Self compiler. > But when I try to call the function in Self the functions bomb because > they are not linked to the libcps.so file. Can I link the libcps.so > file into this one somehow? The trick is to _statically_ link the library into the .o file while making the .so file. Given your SmallFile.o ld -o SmallFile.so SmallFile.o -Bstatic -lcps This worked for me under SunOS and gcc - of course, your mileage may vary. (At least we don't need sed on the assembler any more :-) James James Noble, Graduate Student, Computer Science Department Victoria University, Box 600, Wellington 1, New Zealand kjx(a)comp.vuw.ac.nz

1 0

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 December 1992