Squeak-dev January 2003

squeak-dev@lists.squeakfoundation.org

148 participants
312 discussions

[Q] TCP/IP Stack
by Chris Burkert 31 Jan '03

31 Jan '03

Hi Is there a BSD-like TCP/IP Stack in Squeak ? I wanted to run a swiki on only one networkinterface. thanks Chris Burkert -- ------------------------------------------------------------------------ Student of applied Computer Science at Chemnitz University of Technology http://www.chrisburkert.de/ chbu(a)hrz.tu-chemnitz.de ------------------------------------------------------------------------ "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." - Alan Kay --> http://www.squeak.org/

3 2

Proposal: Squeak-E = Squeak x Kernel-E
by Lex Spoon 31 Jan '03

31 Jan '03

As Andreas said, I didn't make much of a point. Let me try again. My attempt was twofold: to focus the issue on what is important, and to remind everyone of how far my "Islands" got. I will try to clear those up, and also reply to the subject line. To be blunt, I don't see the big advantage of segments of memory in the VM, even though you might want conceptual segments of memory within the image. It is unclear what kind of VM support would be useful. The extremes are useless: one extreme is the same as multiple Squeak processes, and the other extreme is the same as not having segments at all. We need to know what semantics we want from the image segments before we implement them, and no one seems to know. My Islands project doesn't use VM memory segments. Guys, Islands is pretty far along. It has true capabilities, and it allows non-graphical computations to run on its own island without harming the rest of the system. The VM changes for Islands are pretty small; the vast bulk in image-level things like the following: - supporting symbols with ==, even between islands - immutable literals (so you can't change the value of pi) - immutable blocks (so you can't write your own bytecodes) - safer exceptions (though I'm still worried in this area) - safely limited access to class methods (so you can't modify class Object arbitrarily) - dynamically-scoped variables, so that the "global" variables aren't shared I even had a prototype of Morphic in a box, though it was pretty slow. Islands has been stalled for a few years, but not because of any technical difficulties. I am busy doing PhD work at a college where no one wanted to sponsor me with the Islands work, plus being a teaching assistant to pay the way. I'm happy for anyone else to plug away on Islands, but people seem to be running into trouble getting it loaded at all (if anyone has gotten it loaded, PLEASE post your image and VM :) Mine got left on a Disney network drive). It takes several hours, and many people don't seem to perservere. Writing this email is already taking more hours than I really have. I'd guess that, working full time, I could get secure and efficient morphic-in-a-box within a month. It's a fairly wild guess. The main copmonents would be careful consideration of the box-to-world protocol, and work on the efficiency of the dynamically-bound variables. Now let's consider E, and what we can take advantage of. The E VM itself would give us efficiency from the get-go. However, all the image-level work remains. Additionally, the image-level work from Islands would have to be duplicated. Switching to E *might* help with development support for dealing with capabilities, depending on how closely Squeak matches E and how well we can reuse their tools. Then again, we could also port E tools to Smalltalk.... Overall, I don't see a huge advantage of switching to the E VM from the point of view of security. We *might* want to do it just to combine development efforts. But unless the merge could happen within a month or so, there doesn't seem like much advantage from the point of view of security. All the difficulty with secure Squeak is in the libraries, at this point. We either have to modify the Squeak libraries to be capability-like, or we have to start from scratch with a new library, or we have to switch over to the library of some other language like E. This is work we can't avoid; there doesn't seem to be any magic bullet in the VM, including image segments, that will help significantly. I ask everyone, especially Mark, to reread the list of things above that I said Islands does. How much of that has to do with the VM ? Unless I'm overlooking something, the main work to do is to tweak various bits of library code so that they work inside a sandbox. To me, it seems like we *can* modify our library successfully. The vast bulk of Smalltalk code does not matter for csecurity. This was a design goal of Islands and I think it succeeds. When someone writes "OrderedCollectien new: 10", they don't care that OrderedCollection gives you an object that doesn't respond to #superclass. When an app passes messages around to itself, the rest of the image is completely unafraid of the security implications. It's only primitives that you have to watch for, and user code rarely defines primitives. The vast bulk of Morphic, not counting Balloon, should run without modification. What E is definitely helpful with, is image-level *design* ideas. How do you deal, in practice, with a language that uses objects-as-capabilities? While capabilities are convenient for designing security policies, objects-as-capabilities aren't as convenient to use as they at first seemed. It's hard to write code where most of the objects you see might be lying to you on fundamental things like #name or #asInteger, and my solutions are surely very mundane compared to what Mark Miller would come up with. After all, he's the one who clued me in on capabilities, and that was two years before Islands was started, which in turn was a few year before today. Lex

7 16

Re: Dynamic scoping
by Anthony Hannan 31 Jan '03

31 Jan '03

Hi Allen, thanks for responding, and thanks for the language design principles. Allen Wirfs-Brock <Allen_Wirfs-Brock(a)Instantiations.com> wrote: > The topic at hand is dynamic "variable" scoping. I prefer messages to variables because they are more powerful and general. It allows more sophisticated queries, instead of just returning a fixed value. I guess I'm just proposing another form of exception handling, where exceptions are distinguished by selector instead of class, that is why I reused #on:do:. I even like to think of global variables as messages sent to Smalltalk or the class's environment/pool. Like Self, no variables just objects and messages. To satisfy your design principles, we could change the syntax to: foo Context bind: #world toDo: [myWorld] during: [self bar]. bar Context world. Context would be an object that only understands #bind:toDo:during: and #doesNotUnderstand:. #doesNotUnderstand: would search the sender chain for the first #bind:toDo:during: context for the message's selector and execute its toDo: block. I believe this syntax satisfies the design principles you mention below. > 1) It should be easy to explain the feature to a new or relatively > unsophisticated Squeak programmer. > 2) A single, specific implementation technique should not be assumed > or required. > 3) Usage should not require deep knowledge of low level system > implementation details. > 4) Protocol vocabulary should be simple and reflect the intended usage > model. > 5) Protocol vocabulary should not expose the user to the vocabulary of > the low level system implementation. > 6) Protocol vocabulary should not imply or require a particular > implementation strategy for the feature. > 7) A distinct feature should use a distinct vocabulary that is > different from that of other, unrelated features. > 8) Don't design in "bugs waiting to happen" > 9) Put the most important things first. So the real issue is variables versus messages. What do you think? Cheers, Anthony

1 0

Re: Dynamic scoping
by Allen Wirfs-Brock 31 Jan '03

31 Jan '03

At 06:38 PM 1/30/2003 -0500, Anthony Hannan wrote: >Attached is another version of my dynamic scoping and replaces the >previous one I sent out a couple of days ago. It now looks like: > >foo > [self bar] on: #world do: [myWorld]. > >bar > thisContext outer world. Anthony, I've been watching the dynamic scoping threads with some interest as it involves a subject that I have some experience with. Also as the inventor of the on:do:/ensure:/ifCurtailed: vocabulary I may feel a little protective about its use (or misuse). Unfortunately, I really don't like your above proposal so let me try to convince you to also dislike it. The topic at hand is dynamic "variable" scoping. Let's assume that dynamic scoping indeed would be useful to have in Squeak. Let's also assume that dynamically scoped bindings are not intended to be a replacement for conventional Smalltalk global "variables" (I know that such a replacement has been suggest but it doesn't appear to be part of your proposal and hopefully Mark Miller will finish convincing everyone that this is a bad idea.) Given this assumption, we can talk about how we want this new feature to appear to its users (Squeak programmers). Here are some principles I would apply in designing such a feature: 1) It should be easy to explain the feature to a new or relatively unsophisticated Squeak programmer. 2) A single, specific implementation technique should not be assumed or required. 3) Usage should not require deep knowledge of low level system implementation details. 4) Protocol vocabulary should be simple and reflect the intended usage model. 5) Protocol vocabulary should not expose the user to the vocabulary of the low level system implementation. 6) Protocol vocabulary should not imply or require a particular implementation strategy for the feature. 7) A distinct feature should use a distinct vocabulary that is different from that of other, unrelated features. 8) Don't design in "bugs waiting to happen" 9) Put the most important things first. So let's first look at your example for establishing a dynamically scoped binding: >foo > [self bar] on: #world do: [myWorld]. and examine it in light of these principles: 1) You are going to have to explain that while it looks just like establishing an exception handler it actually means something else. 2) At the very least you require a change to the implementation of #on:do:. 3) You're maybe ok on this one but wait until we get to bar! 4)The on:do: vocabulary suggests nothing about dynamic binding, it's scoping, etc. 5) see 3 above 6) Some sort of strong connection to exception handling is clearly implied. 7) It looks like an exception handler! If you see: [ ] on: a do: b (where a and b are variables) there is no clue to tell the reader the programmer's intent. 8) The goal is to bind a particular value over some scope. However, you aren't binding a value, you are binding a lexically scoped "function" that computes a potentially new value each time the binding is accessed. Pitty the poor programmer who doesn't realize that "myWorld" is assigned to somewhere within a "bar" 9) Imagine if the receiver is a several line block. A reader won't see that a new binding has been established until having read the entire block. In this case, I think the establishment of the scoped binding is the most important aspect of the feature. (I know, exception handling #on:do seems to violate this but I would argue that when establishing an exception context that the block to be evaluated is most important thing to the user and should come first while the exception and its handler are "exceptional" and hence should come second. Now for: >bar > thisContext outer world. 1) I wouldn't even know where to start!!! 2) Must be implemented using contexts. Must use #messageNotUnderstood: in its implementation. 3) Anything that references thisContext fails this criteria 4) It doesn't say anything about dynamic scoping. It's just a sequence of messages that imply nothing. 5) see 3 above 6) see 2 7) It really doesn't have a vocabulary. It's an idiomatic usage of this context outer and undefined messages 8) What if the name you want to find is already the name of a method in whatever outer returns! 9) thisContext?? Hopefully, by now you are convinced. I think that some of the other ideas for dynamic variable "syntax" probably come closer to my principles (remember I'm only talking about the surface "syntax" of the proposals, I reserve judgment about some of the implementation ideas). However, I can't resist throwing out some other possibilities: foo Binding for:#world is: myWorld during: [self bar] bar Binding for: #world Programmers with a Scheme background might perfer: foo (Fluid named: #world value: myWorld) do: [self bar] "or just #named:value:do" bar Fluid named: world If you want to get radical with a core system class consider: foo #world is: myWorld during: [self bar] bar #world is etc., etc... Anthony, keep up the good work but remember that language design and language implementation are different tasks. When you are designing a new language feature first think like a user and then validate it as an implementor. Alle_Wirfs-Brock(a)instantiations.com

1 0

[GOODIE] Time Objects
by Chris Muller 31 Jan '03

31 Jan '03

FYI, My preferred way of working with Gregorian time is now auto-installable from SqueakMap. http://marvin.bluefish.se:8000/sm/package/5570b593-0ca3-462b-827c-4b3a746e3… >From the readmeText: ---------- I can help you deal with aspects of time using a pleasant API. The core domain class is MaCalendarTime, which can represent either a point on the Gregorian calendar, or a duration of Gregorian time (e.g., seconds, days, etc.). MaCalendarTime is storage efficient, wrapping only a single Integer, and is precise to the millisecond. To get the current time: MaCalendarTime now To obtain a duration: 3 minutes A variety of arithmetic is supported: 3 minutes + 2 seconds 8 hours // 2 (1 hour + 27 minutes) roundTo: 30 minutes MaCalendarTime now - 30 days MaCalendarTime now - (MaCalendarTime fromString: '1969/12/31 23:52:59:999') MaStopwatch is the other cool domain class. This is, literally, a stopwach just like you would use in real life. I use it to time things, such as how long it has been since I last signaled a ProgressNotification, that way I can do them only ever five seconds or so. Inspect this and play with it, it's simple: MaStopwatch new start __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

2 1

Dynamic scoping
by Anthony Hannan 31 Jan '03

31 Jan '03

Attached is another version of my dynamic scoping and replaces the previous one I sent out a couple of days ago. It now looks like: foo [self bar] on: #world do: [myWorld]. bar thisContext outer world. No more separate handler class and no multi-method handler. To handle mutliple messages, you must nest mulitple on:do: blocks. I have found that most of the time only one handler method is needed per protected block. I have overloaded the on:do: method for efficiency with exception handling and because of its like semantics (so its really not overloading). "on: exceptionClass do: block" still works as before. In either case a message is sent to the #outer of a context, which is the closest #on:do: context sender wrapped in a ContextHandler. The message is an arbitrary message like #world above, or it is #handleSignal: if an exception is signaled. The contextHandler responds to #handleSignal: (or the arbitrary message) by executing the do: block if the on: arg handles the exception (or equals the message selector), otherwise it forward the message to its outer #on:do: context. If no more #on:do: contexts exist in the sender chain then a DefaultContextHandler is created and sent the message. It calls #defaultAction on the exception (or signals MessageNotUnderstood on the general message). I will be including these changes with my closures-for-stock-vm package coming soon. Cheers, Anthony

1 0

[SqueakMap][WishList] Traits
by Brent Vukmer 30 Jan '03

30 Jan '03

Nathanael, Stephane -- how's Traits development going?

3 2

Bounding up morphs
by Eric Scharff 30 Jan '03

30 Jan '03

I have a task where I create a fairly large (hundreds) number of related morphs and position them in such a way that is not suitable for a layout manager. I want to move / delete these morphs together, so I want to group them, doing something like this groupMorph _ Morph new. "for each object I create" myMorph _ MyMorph doTheRightThing. groupMorph add: myMorph. What is the easiest way to set the extent of groupMorph so that it encloses all of the sub-morphs? Right now it uses its default bounds, which has all sorts of problems with halos and redrawing. Thanks, -Eric

4 4

World Morph (was: Comments on Lex's "Object as Capabilities in Squeak")
by Anthony Hannan 30 Jan '03

30 Jan '03

Hi Mark, "Mark S. Miller" <markm(a)caplet.com> wrote: > At 02:51 AM 1/30/2003 Thursday, cg(a)cdegroot.com wrote: > >Every object that wants to do something with the UI needs to go directly > >or indirectly to World. > > When would an object do this without being passed or holding some other ui > object that gives it context? A button doesn't draw on the screen, it draws > within some containing thing, etc, recursively. At least this is how it > works in every ui toolkit I'm familiar with (including AWT, Swing, SWT). > Could you give an example that I could understand without learning Morphic? > Thanks. World is the top Morph in the tree of morphs that automatically gets displayed and refreshed on the Screen. A button would have a parent morph, such as a window; the window would have a parent morph, such as the World. You add a morph by creating it with all its submorphs, then adding it to the world. For example: "World addMorph: (SystemWindow new addMorph: (RectangleMorph new position: 100@100))" (go ahead execute it). Cheers, Anthony

1 0

RE: Dynamic Scoping & Context Based Behavior (was: Dynamic scoping)
by Stephen Pair 30 Jan '03

30 Jan '03

Ah...thanks! - Stephen > -----Original Message----- > From: squeak-dev-bounces(a)lists.squeakfoundation.org > [mailto:squeak-dev-bounces@lists.squeakfoundation.org] On > Behalf Of Anthony Hannan > Sent: Thursday, January 30, 2003 12:56 PM > To: The general-purpose Squeak developers list > Subject: Re: Dynamic Scoping & Context Based Behavior (was: > Dynamic scoping) > > > Hi Stephen, > > Your describing perspectives/layers/subject-orientation. See: > > [Us] Randall B. Smith and David Ungar. A Simple and Unifying > Approach to Subjective Objects. Theory and Practice of Object > Systems 2(3):161-178, 1996. > http://citeseer.nj.nec.com/smith96simple.html > > [PerspectiveS] Robert Hirschfeld and Matthias Wagner. > PerspectiveS - AspectS with Context. 2002. > http://www-ia.tu-ilmenau.de/~hirsch/Projects/Squeak/Perspectiv > eS/Perspec > tiveS.html > > Cheers, > Anthony > > "Stephen Pair" <spair(a)acm.org> wrote: > > One of the interesting possibilities that dynamic scoping might > > present is that it could be used to set a "behavioral context." > > Currently Squeak has only one global "behavioral > context"...which is > > to say that all objects exhibit the same behavior (roughly > speaking) > > under all runtime situations in which any given may find itself. > > > > With some modification to the message binding algorithm and the > > structure of object memory, I think you could construct a > system where > > objects could exhibit different behaviors when being utilized in > > different runtime "behavioral contexts." > > > > Every object would have some behavior that it exhibits in the global > > (default) behavioral context. Additionally, you could add behavior > > (and corresponding state) that an object would only exhibit > when it is > > being utilized from within a specific runtime behavioral context. > > > > A real world analogy is that people, when in different > contexts, often > > exhibit different behavior. > > > > A good example is a domain object that exhibits GUI > rendering behavior > > when utilized in the "Morphic" behavioral context. Upon first > > utilization in the Morphic context, the object would adopt the > > rendering behavior and state that you had previously > defined for all > > objects of its class. This would eliminate the need to have two > > separate objects for the model and the view, yet still have > all of the > > benefits of model-view separation. Furthermore, if you had > different > > morphic applications for which different renderings were > required for > > the same domain object, each application could define its own > > behavioral context (which would each inherit from the Morphic > > context). Method lookup would first look for methods in > the specific > > behavioral context, and then follow an inheritance chain of > behavioral > > contexts, with the global default behavioral context being > the root of > > this heirarchy. > > > > - Stephen > >

1 0

← Newer
1
2
3
4
5
6
7
8
...
32
Older →

Jump to page: