Squeak-e

squeak-e@lists.squeakfoundation.org

54 discussions

Re: [Squeak-e] Programming the VM
by cg＠cdegroot.com 05 Feb '03

05 Feb '03

Andreas Raab <squeak-e(a)lists.squeakfoundation.org> said: >I don't know where you heard that the object format is going to be changed >in 3.5 but adding a pointer to every object is unlikely to be done unless >you have a Very Good Reason(tm). It will instantly break all plugins and the >added space and GC overhead is not to be taken lightly. > Last thing I heard was that there were some changes necessary for various things, and that 3.5 would be the version where this would, as far as possible, would all be collected so that we'd have a break in image file format only once. But that was last October, before I went into a long dive involving directory services and other ugly business matters :-) I've already been thinking about the implications GC-wise and space wise. Probably some compression is possible and necessary. 90% of all objects, certainly in the beginning, will point to a default environment. A bit indicating whether there's additional environment info could save a lot of space and time. A second bit might indicate whether a short or long environment pointer is used (6-8 bit index in a table vs. 32 bit pointer). Immutables probably wouldn't need to have it at all. Anyway, the discussion *might* be premature; however, before diving into options it would be nice to know how feasible they are. So I fear that we need to discuss ways *how* to make this happen more-or-less in parallel with the discussion *what* exactly we want to make happen (e.g., what do we want to point to). In other words, even though it's premature from a technical viewpoint, as none of use here wants to fork Squeak (I hope) it is probably prudent to inventory the options for doing things like this as early as possible and see how/whether support can be raised. Politics, again... -- Cees de Groot http://www.cdegroot.com <cg(a)cdegroot.com> GnuPG 1024D/E0989E8B 0016 F679 F38D 5946 4ECD 1986 F303 937F E098 9E8B Cogito ergo evigilo

4 4

Comments on Anthony's "...Shared Smalltalk"
by Anthony Hannan 05 Feb '03

05 Feb '03

Hi Mark, Thank you for critiquing my Shared Smalltalk paper. It is greatly appreciated especially from the one who enlightened me to capabilities in the first place. I will respond to your questions/points tomorrow in another email. For now I thought I would answer some quick questions you had in another email under the subject "Re: Comments on Lex's "Object as Capabilities in Squeak" "Mark S. Miller" <markm(a)caplet.com> wrote: > At 12:26 AM 1/31/2003 Friday, Lex Spoon wrote: > >There is a big engineering effort to get away from dynamic binding of > >class names yet still have limited access to classes. Happily, though, > >the independent modules efforts for Squeak seem to be solving this exact > >issue along with their other goals. > > Where can I read about this? There has been long discussions on how to separate the image, or at least its code, into modules. Some incomplete solutions have been developed (see http://minnow.cc.gatech.edu/squeak/Modules). The current solution is changeset packages catalogued in SqueakMap (http://minnow.cc.gatech.edu/squeak/SqueakMap). Lex is refering to modules that provide restricted namespaces, unlike SqueakMap packages, but more like Pools described in my Shared Smalltalk paper. > >Code uses World all over the place: there are 98 direct accesses to the > >variable, and 119 senders of #currentWorld. > > How do I make such queries in my image? Highlight "World" and hit Alt-Shift-N. Highlight "currentWorld" and hit Alt-n. For a complete list of options, select 'help...' -> 'command-key help' off of the World menu which comes up when you click on the background. Cheers, Anthony

1 0

Another Nested VM Proposal
by Mark S. Miller 05 Feb '03

05 Feb '03

At http://www.erights.org/javadoc/org/erights/e/elang/evm/Evaluator.html you'll find a strange old unimplemented proposal for handing E sub-expressions off to a reified evaluator while maintaining their lexical context. This proposal is strange because it enables one to introduce virtualization boundaries at expression granularity. This causes a complexity for E absent from Squeak-E: An E expression not only uses bindings introduced to its left, it also produces bindings that can be used by expressions on its right. As I recall, there's no corresponding issue in Smalltalk. In any case, an actual API for introducing lexically scoped virtualization should probably be limited to object-definition-granularity. Also, the above proposal doesn't take account of any of the subtle techniques that can make a big difference in the efficiency of virtualization. It may not preclude any of them either, but I haven't thought about it. ******************************* To build a safe and high-functionality system, one should start by building a safe and low functionality system, and then incrementally add functionality while preserving safety. The other way around doesn't work. As fascinating as these issues are, I believe we should make Squeak-E safe and coherent (to something like the level E is). Once we have that, we'll be in a much better position to making it highly self-malleable. But during the whole process, let's keep talking about the ambitious things we'd like to do, so we don't paint ourselves into a corner. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

Are Handlers Dynamically Scoped? (was: Comments on Lex's "Object as Capabilities in Squeak")
by Mark S. Miller 04 Feb '03

04 Feb '03

At 11:16 AM 1/31/2003 Friday, Anthony Hannan wrote: >Yes, exception handling needs dynamic scope, doesn't it? Do you propose >handling exceptions differently? Exception handing was an aspect of PPS2.5 that I never did learn real well. Where is Squeak's exception handling documented? As I recall, PPS2.5 had both terminating and resumable exception handlers. Let's take these separately. Terminating Exceptions E uses only terminating exceptions, on the same model (for present purposes) as C++ and Java. Since I don't remember PPS2.5's terminating exceptions being any different from this, I'll just assume they're the same until I hear otherwise. I will use Java as the reference for this model, as it's probably the most mutually well known. Java try-catch and try-finally blocks do have some semantics in common with dynamic scoping. They push and pop on the stack according to nested dynamic extents, just as dynamic variable bindings do. When one is needed, the dynamically closest applicable one is looked up, presumably by looking back on the stack, corresponding to a deeply-bound implementation of dynamic scoping. However, I claim this isn't dynamic scoping. The "throw" is not directly invoking the corresponding "catch". Rather, the stack is being unwound and "finally {..}" clauses are getting run on the way out. If one of these finally clauses itself throws, we proceed to unwind with the new Exception *instead of* the old one. These effects fit poorly into the dynamic scoping model. Instead, what fits well is a simple extension of the continuation passing model of call-return computation (CPS). When writing in a call-return language, there's always one unstated additional parameter on all calls -- the continuation -- representing the rest of the computation the caller will perform once the callee returns. In denotational semantics, Actors, or Scheme, where CPS originated, the continuation was simply a function of one argument, where this argument was the value to be returned. (It's a separate matter as to whether the language allows the continuation to be reified, or treats it only as an explanatory device. Smalltalk, Scheme, and Actors do the first. C++, Java, and E do the second. For various reasons http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html I recommend the second, but we can leave this argument to another time.) As explained in section ii of http://erights.org/elib/concurrency/msg-passing.html , to account for terminating exceptions, we model the implicitly passed continuation as an object with two methods resolve: result and smash: exception A throw just calls the smash method of its continuation. The peculiar behavior of a try-finally is just the peculiar behavior of the continuation it creates. (Note: to model E we need three methods in the continuation, but I think we can ignore that for present purposes.) So, clever implementations aside, the computational model is explained purely in terms of local message sending without any magic reaching up the stack (deep binding) or stateful variables being magically shared (shallow binding). I claim it's not dynamic scoping at all. Resumable Exceptions Although I may have programmed in languages that happened to support resumable exceptions, I myself have never used them in any language. So if this is where the "Are Handlers Dynamically Scoped?" issue is, I'll wait until someone explains their semantics, or points me at documentation. If these are indeed dynamically scoped, then we need to ask whether they are a good idea. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

8 28

RE: [Squeak-e] Programming the VM
by Stephen Pair 03 Feb '03

03 Feb '03

>> SqueakVM specialists: how hard is it to add an extra > reference to all >> objects? On Squeak level? On VM level? > > I would like to hear a little more about what this 'machine' actually > is. Is it a lexical closure? Would all objects need to have this > 'machine' reference? > > Squeak object headers are of variable size. there are 3 different > sizes so it uses 2 bits in the baseHeader to define the > header size. 1 > word, 2 words, or 3 words are the possibilities, and the fourth value > is for dead objects, I believe. Stephen added an extra word for his > LOOM impl, and basically all the code that reads or writes > the headers > would need to be changed to deal with it. You are correct about header sizes and bit usages. Coaxing squeak into having extra headers is straightforward, but time consuming. You'll have an additional challenge by adding a pointer field (because you'll need GC to trace it). I'd also recommend that you bone up on the InterpreterSimulator and use SystemTracer2 (on SqueakMap) for making your new images and testing your new interpreter. The InterpreterSimulator is an invaluable debugging tool. Since it is a pointer field, I'd probably explore adding the word *below* the base header because that will be the least impact on GC...however, it's also something that I've never attempted. I have added non-pointer headers to every object above the base header and I've added the ability to insert a "state manager" between an object and its class (path of least resistance). If you added a pointer field above the base header, you're going to have to do some very tricky things with GC to get it to traverse that field (similar to the way GC currently deals with the class header). In an ideal world, I'd move the class header below the base header, but this probably wasn't done because not every object has a class header and testing that fact on every inst var access would probably be expensive. If you eliminated compact classes, then it would make sense to move the class header below the base header (note, I have not done that in my Chango VM even though I did eliminate compact classes). If absolutely every object is going to have this pointer and it is a pointer, I would start with a design that puts this pointer after the base header. If only some of the objects in the image will have this pointer, you might try a similar hack that I did which inserts your object between an object and its class. Finally, you can put a pointer above the header, but it's going to make for some ugly looking code in GC. - Stephen

1 0

Re: [Squeak-e] Programming the VM
by Mark S. Miller 03 Feb '03

03 Feb '03

At 01:03 AM 2/3/2003 Monday, Avi Bryant wrote: >Seaside requires access to the entire context stack, but opaquely - it >just needs to copy it, not to look at or change it. To put it another >way, it needs access not to its caller's frame but to its own >continuation, which seems reasonable to me from a security point of view >(there was a brief mention earlier of a secured Scheme - did this still >have call/cc?). It's called W7 and is documented at http://mumble.net/jar/pubs/secureos/ . It's great. I strongly recommend reading it. It did have call/cc with indefinite extent continuations, which isn't technically incompatible with capability security. But indefinite extent continuations make it too hard to program defensively. Every caller has to worry that any callee may return to it multiple times. Jonathan Rees, who did W7, now agrees that default indefinite extent continuations are a disaster in the context of general caller/callee mutual suspicion. See http://www.eros-os.org/pipermail/e-lang/2001-July/005418.html for some related points. Btw, call/cc with dynamic extent continuations are fine, as with Smalltalk's traditional "[:result | ^result]" . It sounds like there's a genuine conflict here with Seaside, which we need to understand better. ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

2 1

[goodie] SqueakElib released to squeak map
by Robert Withers 03 Feb '03

03 Feb '03

http://swiki.squeakfoundation.org/squeak-e/3 sorry, no docs. enjoy! ps. you have to have the asn-encoding-dsa.cs changeset, loaded

1 1

Comments on Anthony's "...Shared Smalltalk"
by Mark S. Miller 03 Feb '03

03 Feb '03

Hi Anthony, I just reread your paper, and enjoyed it tremendously once again. Sorry for the delay on the comments. All unattributed ">"-style quotes are taken from Anthony Hannan's "Capabilities and Class Extensions for Secure but Extensible, Shared Smalltalk", version dated January 2003, at http://housechk.com/~tony/SharedSmalltalk.htm . At the beginning of 2.1, typo: >allows you to associated resources 2.2: >If you have to give out stronger capability objects, make sure the client is >trustworthy, since it may pass the capability along to other objects. It is >possible to create smart capabilities that confirm the sender at runtime, >but this requires maintaining an access control list that is usually more >trouble than handing the capabilities out correctly in the first place. [likewise, but out of order] >In extreme cases, where you need to give a stronger capability to an >untrusted client, you can have the capability check who the sender or user >is as mentioned earlier. You can have it wrap all results in new >capabilities that also check who the sender/user is, and so on. This >provides end-to-end security without trusting client objects, albeit with >extra overhead. What problem do these "smart capabilities" solve that isn't better solved using pure capabilities? What do you mean by "confirm the sender"? What information would you examine, and what notion of sender would you compare it against? These "smart capabilities" looks to me like a mixture of capability and ACL notions. Among other things, it means that a sender effectively has extra authority because of his identity, rather than just the authority he chooses to use. This leads to confused deputy problems. In terms of Figures 3 and 4 of Capability Myths Demolished http://zesty.ca/capmyths/usenix.pdf , you have arrows pointed both ways. I think this may be approximately what Li Gong's ICAP http://citeseer.nj.nec.com/gong89secure.html tried to do. The next paragraph beginning with >A fundamental difference is just great. I don't remember seeing it explained this way before. 2.4: >We can automatically determine if an object's instance variables can be >transferred with the object or if a proxy should be transferred instead. If >one of the object's instance variables is truly private, i.e. no methods >give it out, then only a proxy to the object should be given out. Otherwise, >it is ok to transfer the object and its instance variable, since it is >willing to give out its instance variables anyway. This corresponds in E to the distinction between PassByCopy and PassByProxy. E objects are by default PassByProxy. Since your paper mostly avoids distribution issues, the following is probably a digression: <digression> In E, to declare an object PassByCopy it must satisfy three conditions: * OpenState -- all its instance variables must be accessible through its interface in a standard way. I think this maps exactly to what you're saying. * OpenSource -- the object must make its source available through a standard request on its interface. * Frozen -- the instance variables must be immutable. (It would be adequate to check that they aren't assigned to.) OpenState and OpenSource together are called Transparent. It ensures that all the information needed to instantiate a copy is available through the public interface. An effect of declaring an object PassByCopy is to make it Selfless. Objects are Selfish by default. "x == y" between two Selfish objects in E means what it means in Squeak: compare the object's creation identity, ie, their selfs. Selfless objects have no self. "x == y" among two PassByCopy objects recursively compares (with cycle breaking) their source and state. Frozen and Selfless together means that PassByCopy objects can be copied freely, and not coordinated afterwards, and nevertheless they are all still manifestations of the same object. All the copies are still ==. If your copied objects aren't Selfless, you probably need some kind of per-connection interning table for each object copied over that connection, in order to make sure that a second passing looks up the already constructed copy on the other side. If your copied objects aren't Frozen, then you'll need to coordinate distribute state, which is tricky http://www.eros-os.org/pipermail/e-lang/2001-September/005728.html http://www.eros-os.org/pipermail/e-lang/2002-April/006357.html . </digression> 3: >Since common classes are the same across users we will model them as >actually being identical objects that are replicated but kept in sync [2]. >This allows them to be changed together if need be by an authorized user. Aren't the common classes common across the universe? Who would have enough authority to change these? I think I'm missing something. 3.1: I love your description of users and portals. I think it's exactly right. typo: >he may create an chat 3.2: Are you proposing that each pool dictionary be replicated across all users? If so, then these must contain no authority as you've heard me harp on. If you're not replicating them, but instead allowing each machine to have its own name->variable bindings for each pool, then a shared class + separate pool bindings = a new level of instantiation. I think I'd be happy with either direction as long as they're taken to their logical extreme. 3.4: Really really cool. But, since you wish to prevent the class extension from overriding the common class it's extending, what happens if the common class later defines a method for one of the messages defined by some extension? The common class doesn't know enough to refuse to do that. Once it's done, then the extension in effect defines an override. I don't know what to do about that, as I also think that overrides by extensions should be disallowed. 3.5: >A user may also add a subclass to any class. If the superclass is read-only >then the subclass can not access the superclass's instance variables or >pool, only its own instance variables and pool. If the superclass sends a message to self, does the subclass receive it, as one would naively expect? 3.6: >Finally, if the message name is found in more than one class interface, >then those classes are presented to the user for him to choose. In this case, the choice should be represented by making the selector in the source explicit (eg, your later "collection.do"). Otherwise, the source text is not the complete source. >It also makes detached class extensions possible. Intriguing. How do you mean? I think this one's important to understand. ********************** I'm holding off on some further comments while I see if I can nag Dean (cc'ed above) into finding and posting the Joule Type Extension paper he wrote many moons ago. Dean, nag nag. ;) ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 0

reply-to addressing is going to the sender rather than the list
by Robert Withers 02 Feb '03

02 Feb '03

Cees, Could you modify the way the list sets the reply-to field? or is it something I need to setup in my mail client? thanks, rob

2 1

Re: Comments on Lex's "Object as Capabilities in Squeak"
by Mark S. Miller 02 Feb '03

02 Feb '03

Answering out of order. At 12:26 AM 1/31/2003 Friday, Lex Spoon wrote: >Your notion of 4 levels of effort is a great basis of discussion. In >fact, I believe Islands works at level 4, though it is more awkward for >such thigns than E. I'll attach my solution to the little-money problem >at the end of the message. Still, as you guessed, the goal of the >project was more for level 1 or maybe level 2 (eg, retracting sound >access from annoying squeaklets), with hopes of making a basis for level >4. As I count it, everyone would like to reach for level 4. So let's proceed with that as a shared goal, being willing to pay the incompatibility price along the way, so that we can see how big that price is at the end of the day, and how we feel about it. >There is a big engineering effort to get away from dynamic binding of >class names yet still have limited access to classes. Happily, though, >the independent modules efforts for Squeak seem to be solving this exact >issue along with their other goals. Where can I read about this? >The more general dynamic global variables are annoying, but the one case >of World is hard to do away with in Squeak. World refers to the current >morphic rendering unit. Currently it is an entire desktop, though in a >Squeaklet it would be more like one page or one subwindow. This demonstrates already that it was a mistake to make it global -- it needs to be bound to a different object when it appears in a Squeaklet. >Plus, there is a tricky >*conceptual* issue with getting rid of the variable. It's just really >convenient to have the world floating in the ether, and it would suck if >Squeak code became significantly harder to write. I think the real problem is that Squeak currently has a very rigid notion of lexically nested levels of instantiation: Global Class/Factory Instance Method (activation frame) Block Block ... At the bottom of the hierarchy, one can add more levels freely. What is needed to address many of the problems that are coming up is the ability to add more levels between Global and Class/Factory. I suspect "World" should appear in one of these. The Java ClassLoader mechanism adds exactly one additional level, which postpones the pain but doesn't cure the disease. Let's call this the "loader scope". E and W7 have arbitrary and uniform lexical nesting to whatever depth or height is desired. What would it mean for Squeak-E if a full class definition could appear in a method, just as a block-closure definition does now? Hell, even Java does proper lexically nested class definitions. Imagine perhaps a single-class-browser embedded in the method text, making the method editor pane into a compound document editor. >Code uses World all over the place: there are 98 direct accesses to the >variable, and 119 senders of #currentWorld. How do I make such queries in my image? >On another topic, you say that level-1 success, where you have >completely isolated applets, is useless. That is not actually true in >Squeak. The most important goal of Squeak is to allow a new way of >composing electronic documents. Level-1 success means Squeak documents >can be exchanged safely, which is a huge step forward for Squeak. "Useless" was harsh. Applets are certainly useless compared to their billing. But for interactive diagrams in documents, they should be great. I've been puzzled that there are so few even of these. >Then, instead of writing >> >> x := ObjectInspector instVatOf: obj at: i >> >> you'd write: >> >> x := (ObjectInspector new: obj) at: i Oops, my second line should have said "instVarAt:" rather than "at:". >I believe this is implemented. However, the instance methods just call >the class methods. :) I guess you'd actually want to use something >other than this exact message sequence to *create* an ObjectInspector >instance, though, in order to defeat using "myObjectInspector class" to >create arbitrary new ObjectInspectors. Yes. Which brings up the question, should Squeak-E objects respond to #class at all? #class is a query about an object's implementation, which is none of its client's business. In E, objects instead respond to __getAllegedType, which returns an immutable object (should only be read-only) which describes the API the original object responds to. In other words, the query-only interface-information-only abstraction of messages like "allMethodsInCategory:" -- enumerating not the methods, but the names or signatures or something of the methods. In any case, if Squeak-E classes are factories that may themselves have authority (having gotten it from an enclosing lexical scope perhaps), then it's important that one not be able to access an object's factory by default from the object. See http://zesty.ca/e-archive/ . >Anyway, I never made a serious pass at secure debugging, and it seems >like a low priority. It seems very complicated -- e.g., the debugger >itself may have to worry about being corrupted by the code it is >debugging! While I think it's important long term, I've postponed it for E as well. When the time comes, KeyKOS and EROS are the places to look for a full reconciliation of the tensions between security and debugging. But transposing their solution to a language context may require some research. >Currently, literals in Squeak change all too often; >specifically, I have a literal change about once a year, and it sucks >when it happens. :) Making literals immutable along with read-only is >a terrific thing. The only time they are mutated in Islands, is when >they are instantiated by the compiler when a method is compiled. The literal itself is changed? I think I'm confused. This would seem to be very bad. I'm reminded of those old Fortran stories where an assignment could make all literal "5"s in a program have the value 3. >(Implementation note: I never made an island-creating capability for >Islands, and I never implemented a thisIsland facility for grabbing the >island you are running in. It seems like these would be very easy, >however.) What's the API of an island? If I hold a capability to an island, do I thereby have any authority beyond querying? If so, you should not provide a thisIsland that anyone can say. >> This section refers to "methods that are marked as privileged". Even after >> reading the later section that explains this, I didn't feel like I >> understood how this marking happens, or how the authority to do this marking >> is controlled. > >You mark it by sending messages to the real, low-level class object, the >same class object that the VM uses. Thus it is as privilaged as it can >be. Cool. >I really hope that Islands reaches the 4th level of success that you >talk about, in which case normal users never need to write privilaged >methods. Who needs to define primitives, or access variables from the >system's most privilaged island, or touch thisContext? Logically no >one, and hopefully this works out in practice. Actually, thisContext or something like it may be fine, as open access to *this* stack frame, so long as the parent pointer is no longer open access to the parent frame, but instead at most an opaque continuation. >> Can the same dynamic-variable-using instance be invoked from different >> processes (causing different bindings of the same use-occurrence of the same >> variable), or are dynamic-variable-using instance partitioned among the >> processes that can invoke them. Unfortunately, I suspect it's the first, but >> I'll wait to find out before arguing against it. > >It's possible for it to be the first. For example, if a squeaklet forks >a thread, then the thread will surely be given the same island and thus >the same bindings. I think I'm concerned about the opposite problem. If you have per-process variables, and objects are disjointly partitioned among processes, so that each object "lives" in only one process, and only gets invoked by that process, then the process scope becomes like an outer lexical scope. On object creation, the process scope is determined according to which process the object is created "in". OTOH, if the same object can be reached by multiple processes, then per-process-scoped variables must be disqualified for many of the same reasons that dynamic scoping is a bad idea. More later... ---------------------------------------- Text by me above is hereby placed in the public domain Cheers, --MarkM

1 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Squeak-e