Squeak-dev January 2003

squeak-dev@lists.squeakfoundation.org

148 participants
312 discussions

Questions - RE: Dynamic scoping
by Swan, Dean 29 Jan '03

29 Jan '03

Please pardon my interruption, but 90% of this thread just makes my head spin, so I have some questions: 1) Is it correct that this whole dynamic scoping thing is limited to resolving references to named objects within the context of an executing method? 2) If the answer to 1) is "yes", then couldn't the dynamic scoping be accomplished by using accessor methods instead of direct references to named objects? If I'm understanding what is desired here, I'm not sure why we need another mechanism for runtime binding of names. It seems like you could accomplish the dynamic scoping with just accessors and thisContext to trace sender chains. 3) Is the idea here related to namespaces, except with a runtime context dependency? Could someone please "set me straight" on this? Thanks... -Dean

2 1

Re: Proposal: Squeak-E = Squeak x Kernel-E
by Anthony Hannan 28 Jan '03

28 Jan '03

Hi Mark, "Mark S. Miller" <markm(a)caplet.com> wrote: > >inform us on scoping of names in E? > > Strictly absolutely only lexical scoping according to lexical nesting, just > as Scheme without fluid variables. > > Scheme's fluid variables are much like Common Lisp's dynamic variables -- > both are dynamically scoped. Fluid variables are a bit better from a > capability perspective, but not better enough. When designing Joule > http://www.agorics.com/Library/joule.html , E's most important and direct > ancestor, Dean and I both thought we had a few cases that justified > genuinely justified dynamic scoping. Although, as I recall it took Norm > months to pry our fingers loose from this idea, he did prod us to go through > each of these cases and see that the lexically-scoped answer was simply > better on all dimensions we cared about -- security, convenience, > understandability -- then the dynamically scoped answer. What about exception handlers? Don't these require dynamic scope? > Some of these better answers involved Joule's Type Extension feature, which > is very similar to Anthony's Class Extensions. Joule's Type Extensions, like > the selectors of Jonathan Rees' T language which preceded it, was itself a > purely lexically-scoped notion. In order to solve these problems in a > similar manner, Anthony's Class Extensions will need to be made lexically > scoped as well. Fortunately, I think is should be straightforward. I believe my class extension design (no implementation yet) is already lexically scoped. A class extension is just like any other class. A client class can only use another class if it is in the client's pool (lexical scope). (My class extension paper is at http://minnow.cc.gatech.edu/squeak/SharedSmalltalk). Cheers, Anthony

1 0

SmallNic the 15 february at Bern
by Stephane Ducasse 28 Jan '03

28 Jan '03

Hi all The Swiss Smalltalk User Group would like to organize a SmallNic (a kind of SqueakNic but not exclusively centered around Squeak), but Smalltalk in general. We plan to organize this event the saturday 15th of February at the IAM: Instituet fuer Mathematik und Informatik University Bern, IAM-SCG Neubrueckstrasse 10 CH-3012 Bern, Switzerland Tel: +41 31 631 49 03 Please contact Alex (bergel(a)iam.unibe.ch) if you are planning to come so that we prepare a small schedule. We are planning to start around 11h and eat something together, bring your lunch! We hope to show the first version of SmallWiki an open wiki developed for now in VisualWorks, and much more.... Tell us what you want to show and discuss about. Stef and Alex Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

2 1

Cryptography 0.2
by David Faught 28 Jan '03

28 Jan '03

Hi, Have you considered adding something to this package to play with steganography? I just recently started looking at this, and it seems like Squeak might be a good place to play with it. I'm thinking of an application which would, for example, encode some text (maybe already encrypted) into a JPEG of my choice, and allow it to be decoded again. Steganography seems like a pretty cool thing to play with, and I have found some Java programs that deal with it, but I think it would be more fun in Squeak. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

4 5

[BUG] Recorded sound is lost in published projects
by Markus Gaelli 28 Jan '03

28 Jan '03

Hi, some teachers in Germany want to use squeak to make their pupils document their design-decisions in a paper-boat-competition. They like to use swikis with projects inside and face the problem, that recorded sound in the projects is not automatically published. - What is the current suggested workaround? - Could we make a patch which just repairs that? Best, Markus

1 0

RE: Dynamic scoping
by Anthony Hannan 28 Jan '03

28 Jan '03

Hey guys, Attached is my version of dynamic scoping. Read the README and class comments for further details. Here is an example again of how it is used: foo [self bar] in: (WorldHandler newWithWorld: x) bar thisContext outer world addMorph: y WorldHandler>>world ^ myWorld WorldHander is a subclass of ContextHandler which is given its #in: context and forwards message it does not understand to the next handler in the context's sender chain (inContext outer). If no handler understand the message then a DefaultContextHandler is sent the message which may raise a MessageNotUnderstood. Exceptions have been refactored to use ContextHandlers. #on:do: calls "self in: ExceptionHandler new", and #signal calls "thisContext outer handleSignal: self". If the first handler can't handleSignal: then it is forwarded to the next and so on. DefaultContextHandler calls #defaultAction on the exception. The Exception code is much cleaner using ContextHandlers and it allows us to remove the context pointers from the exception itself, which allows contexts to be copied even with exceptions in them and still work. I know requiring new a new ContextHandler subclass for each case is a bit of a pain, but I like the idea of executing messages instead of looking up variables (handling exceptions using just variables would have been awkward). We could have used arrays of named blocks instead of classes, but classes are more efficient, more manageable, and more capability-secure. If you are lazy and want to use free variables you can create a ContextHandlerDictionary (not implemented) that would respond to at:, and forward to the outer handler if it does not have a value for the given key. Check out ContextHandler and its subclasses. I hope you like it. It is basically the same as exceptions except each class can respond to multiple message instead of just one (#signal). Cheers, Anthony

1 0

Dumb Linux question and a test
by Bill Schwab 28 Jan '03

28 Jan '03

Hello all, First, I want to see if my newly changed email address will allow me to post w/o bothering the moderator (for which I appologize). Second, I'm having a little trouble getting the latest Linux VM to install. Google quickly turned "Squeak libX11.so" into links to download some rpms which look like they would fix the problem. That doesn't necessarily make the ftp server responsive though :( The machine that is easiest to use (at home, RH 7.0 IIRC) is not at all critical, so I would be open to upgrading or even starting over with a newer distribution. Is there one that's preferred? Or, will waiting until the rpms are accessible take care of it? Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bills(a)anest4.anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029

1 0

New page for the information related to my books
by Stephane Ducasse 27 Jan '03

27 Jan '03

Hi all, I'm slowly getting where I want to arrive ;). I started a new web page with the latest version of the environment I used for the book. Now I have a bot a la Karel. In the book I show how to program it so that it can follow a path or a wall, escape a maze. Quite fun. Soon I will add all the code of the second book (break out....) http://scgwiki.iam.unibe.ch:8080/StephaneDucasseWiki/ I have a problem with the methods turnRight: anAngle radius: aRadius and turnLeft: anAngle radius: aRadius. Their rendering is ugly but I do not know what to do with them. Any suggestion is welcome... Stef Prof. Dr. Stéphane DUCASSE (ducasse(a)iam.unibe.ch) http://www.iam.unibe.ch/~ducasse/ "if you knew today was your last day on earth, what would you do different? ... especially if, by doing something different, today might not be your last day on earth" Calvin&Hobbes

1 0

RE: Dynamic scoping (was: Proposal: Squeak-E = Squeak x Kernel-E)
by Anthony Hannan 27 Jan '03

27 Jan '03

"Stephen Pair" <spair(a)acm.org> wrote: > Is your stuff available? Will it work on a stock VM? Yes, I am releasing it tonight. Cheers, Anthony

1 0

RE: Dynamic scoping (was: Proposal: Squeak-E = Squeak x Kernel-E)
by Stephen Pair 27 Jan '03

27 Jan '03

Anthony wrote: > Sorry, Stephen, I forgot to mention your work. Our two > implementations are basically equivalent. I think mine is a > little faster since it reuses the context sender chain > (hierarchy) instead of creating a new parallel environment > hierarchy. Is your stuff available? Will it work on a stock VM? You mentioned using resumable exceptions directly. I consider that to be a poor way to getting a runtime environment (mainly because you'd need a separate class for getting each variable). But, I guess you were speaking of how to do it in the absence of a dynamic context mechanism. Actually, I've been considering enhancing RuntimeEnvironments use the context stack as well (it is redundant to manage the parallel hierarchy). I didn't do that initially because of some legacy code that I wasn't sure would map well to a context stack based approach...as it turns out, it does. But, the usage above would remain the same. > This allows me to re-implement Exceptions to use > my general context handlers/environments, without loss of > efficiency. Your point about environments being inherited by > forked processes is a nice option, but I wouldn't leave out > exception handlers from being inherited also. I believe > exception handlers and dynamic variables should be treated > the same, not differently. Agreed. The exception handlers should be maintained as runtime environment values. And runtime environment lookup should be using the VMs handler context lookup machinery. - Stephen

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
32
Older →

Jump to page: