Squeak-dev February 2002

squeak-dev@lists.squeakfoundation.org

202 participants
665 discussions

Re: Problem with sockets listening with ip address of 0.0.0.0
by Lex Spoon 26 Feb '02

26 Feb '02

> I'm trying to get swiki running on nt, but it listens > on port 80 with an ip of 0.0.0.0 which means it works fine > in IE on localhost but is not so good over the web :). This is actually a good setting: it lets the socket accept connections targetted to any IP on the local machine. So, 127.0.0.1 will work as well as whatever address(es) your network card(s) have. Perhaps you are behind a firewall that blocks port 80? Or perhaps there is a security setting that isn't letting you listen on port 80? -Lex

1 0

[FIX] Directory Entries for Unix VM in Secure Mode (repost)
by Bert Freudenberg 26 Feb '02

26 Feb '02

This didn't make it into the updates, yet: "Change Set: UnixDirSec-bf Date: 5 November 2001 Author: Bert Freudenberg Fake directory entries above the default directory when Unix VM is in secure mode. Might be useful for other systems, too?" Explanation: I just stumbled over that bug again when I downloaded a fresh image. I always run Squeak in secure (file sandbox) mode so it cannot access the directories above. This makes Directory>>assureExistance perform an indefinite loop. My fix makes sure that even for directories above the sandbox one directory entry is generated so the existence test succeeds. This is the right place for the fix, other features start working again, like the FileList listing that was broken when one happened to klick outside the sandbox: now you can at least go back where you belong ... -- Bert

1 0

Re: serialization and rematerialization of CompiledMethods, assistance needed!
by Bob Arning 26 Feb '02

26 Feb '02

On Mon, 25 Feb 2002 22:27:06 -0800 (PST) Chris Muller <afunkyobject(a)yahoo.com> wrote: >> That number should be the number of bytecodes plus the number of trailer >> bytes. This should get the right sized method: >> >> copy _ (CompiledMethod newMethod: m endPC - m initialPC + 1 + 4 header: m >> header) >> > >Hi Bob, I finally got to where I could get back into this and now realize that >I need to know how to "populate" the method after I've created it. For >example, can I simply replaceFrom: 1 to: m size? Or perhaps after the position >(m endPC - m initialPC + 1 + 4)? Chris, It's not quite that easy, as Tim mentioned. CompiledMethods are unusual mixtures of pointers and bytes. Code like your example is on the right track to copy the bytes part, but is not much help for the pointer part. When you are serializing the cm in the first place, you would need to step through the literals (the pointer part) and recognize these as objects that also need to be serialized. Additional care will be needed to handle references to globals (such as a class reference). In this case, the literal sotred in the cm is the Association from Smalltalk (or elsewhere) that points to the global value. Simply exporting this association would not be enough (or even right) - you really need to export something along the lines of "when I am rematerialized, replace me with a reference to String in the receiving image". Otherwise you might bring your own definition of String along and all sorts of strange things could start to happen. It is for this reason that I suggested using source code as the transfer format and simply compiling it in the receiving system. Cheers, Bob

1 0

RE: Getting rid of metaclasses (Was: Behaviors vs Modules)
by Jerry Bell 26 Feb '02

26 Feb '02

Hi all, I have a couple of PIE documents which the folks at PARC were nice enough to copy and send me. They are scanned and I've just made them available: A Layered Approach to Software Design (Ira P. Goldstein and Daniel G.Bobrow, CSL-80-5 December 1980) 1.9 MB http://www.dolphinharbor.org/docs/PIE%20Layered%20Approach.pdf and: An Experimental Description-Based Programming Environment: Four Reports (Ira Goldstein and Daniel Bobrow, CSL-81-3 March 1981) 3.18MB http://www.dolphinharbor.org/docs/PIE%20four%20reports.pdf Both are (c) Xerox. I hope there is no problem posting them. Hope these are useful, Jerry Bell > -----Original Message----- > From: squeak-dev-admin(a)lists.squeakfoundation.org > [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf Of Jim > Benson > Sent: Sunday, February 24, 2002 10:47 PM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Re: Getting rid of metaclasses (Was: Behaviors vs Modules) > > > Nathanael, > > > The ideas of having multiple roles/views/perspectives > associated to an > > object sounds very interesting and promising. I'd really > like to know more > > about these PIE system and its implementation. If you have > any pointers to > > some information, please let me know. > > > > The only place I've seen any of this written up was in the > book Interactive > Programming Environments [1984] edited by Barstow, Shrobe, > Sandewall, ISBN > 0-07-003885-6. PIE is written up as "A Layered Approach to > Software Design" > by Goldstein and Bobrow. pp 387-413. This paper was > originally published as > Xerox Parc CSL-80-5. > > Whenever I want to be depressed, I just pick that book up and > start reading. > It represented the state of the art in '84, and it's amazing > how little > things have advanced since then. > > I haven't found anything online, but I hoped that this > information might > help. > > Jim > > >

4 3

Re: Modules and class... [ a off-topic question ?]
by goran.hultgren＠bluefish.se 26 Feb '02

26 Feb '02

I read your thread and even though you both are much, MUCH more experienced in these areas I need to speak up. :-) David certainly might have a point in that you CAN (perhaps with some mindbending IMHO) unify classes and modules - obviously he has done it. :-) But just because you CAN do it... ;-) To me it feels rather "contrived" (is that the right word?). As Les points out there are numerous differences and it doesn't feel obvious at all (to me). The most naive view of a module is that it is a collection of classes more or less self contained - it is a grouping of classes. So... following my naive reasoning (which I think is a great way of testing if these conceptual things feels natural) - if a module is a class, and a module is a collection of classes, then a class is a collection of classes. BEEP. That doesn't sound right to me. Ok, perhaps I did that wrong. Perhaps a module is "a kind of" class, and I can not draw the conclusion that all classes are modules. I still think this smells like "over unification" or something. No offense intended. :-) :-) regards, Göran PS. The Module system in Squeak OTOH feels nice to me - "A module is an instance of the class Module and it holds classes and submodules etc." :-) :-) DS

6 6

Re: RolePlayers and Roles (was: PIE)
by Sam Adams 26 Feb '02

26 Feb '02

I haven't read the PIE papers in a very long time, but I have done lots of thinking about roles and object modeling over the years, especially wrt CRC modeling. This thread prompted a design thought that I'll throw into the soup: The basic object was a RolePlayer and contained a collection of Roles, where each Role instance would have the state and behavior appropriate to its role (and know its player). The issues that arise are how to deal with shared state between roles (e.g. annualSalary in EmployeeRole could also be annualIncome in TaxPayerRole), and how to deal with message handling priority (aka, which role dominates in a particular scenario, eg takeSickChildToDoctor in FatherRole vs attendImportantBusinessMeeting in AmbitiousEmployeeRole). The shared state problem seems to call for valueholder-like reference objects that would be constructed and installed in each Role with overlapping state when the roles are installed in the RolePlayer. The switching issue could be handled as it is with persons, namely, if you have a request for someone where you assume no particular role bindings or conflicts, you simply send the message to the object. If you want to make sure that a particular role behavior is invoked, then call out the role as in "as the father of my children I expect you to..." or "as an employee of this company you need to ...". This could be implemented using a mix of composite and facade behavior where both RolePlayer and Role had a common interface for handling roleplayer-style messages (ala composite) but where at anytime from the perspective of a sender, one Role instance or another was acting as a facade for the RolePlayer. So if the RolePlayer recieved a message, it would delegate handling to the first understanding Role in its collection using a default priority order. If a Role recieved the message that it understood, it would simply do it. But if it did not understand, it would delegate to the RolePlayer. Of course, a guard against infinite regress would be in order. If a sender wanted a particular Role facade or perspective on an object, it could use something like the old conversion protocols (asString asForm asByteArray) except the returned object would be the appropriate Role facade (playingFather or playingAmbitiousEmployee). The result would be a system where each object could present multiple faces to its collaborators, and new roles (or subsets of responsibilities/interfaces) could be added and removed dynamically. Lots of details to work out, but there's the basic idea. I'll leave the meta-roles, geno-roles, and pheno-roles for another time. ;-) Regards, Sam Sam S. Adams, IBM Distinguished Engineer, IBM Research tie line 444-0736, outside 919-254-0736, email: ssadams(a)us.ibm.com <<Hebrews 11:6, Proverbs 3:5-6, Romans 1:16-17, I Corinthians 1:10>> Jecel Assumpcao Jr <jecel(a)merlintec.com> To: squeak-dev(a)lists.squeakfoundation.org Sent by: cc: squeak-dev-admin(a)lists.squeakfou Subject: PIE (was: Getting rid of metaclasses) ndation.org 02/24/02 01:53 PM Please respond to squeak-dev On Sunday 24 February 2002 19:18, Alan Kay wrote: > Goldstein and Bobrow eventually found a very interesting way to > implement these enriched objects: they used Smalltalk instances for > each role/perspective. So a PIE object could be made from many > Smalltalk objects. I suppose they used a flat "perspective space", right? Some other proposals allow role inheritance, but that easily becomes a big mess. How do you know which perspective to use at any given time? How do you switch between them? Sorry about the questions, but there is essentially nothing online about PIE. I am trying (http://www.merlintec.com:8080/software/8) to come up with something similar. -- Jecel

4 3

RE: Modules and class... [ a off-topic question ?]
by goran.hultgren＠bluefish.se 26 Feb '02

26 Feb '02

"David Simmons" <David.Simmons(a)smallscript.com> wrote: [SNIP] > I think that it is mostly lack of experience in this space that is doing > the talking here amongst Squeak folks. Consider what happens when you It may very well be. On the other hand we do have some experienced guys too! :-) Like Les for example. So I don't think that is the only reason for our reactions to your view. Nevertheless I find your view very interesting and I am arguing because I want to understand it better. And I do, as many others have testified, very much value your input here - be sure of that. > need to define a new type of module. How will you package and deploy it > when nothing will understand it in base systems. It is very likely to > result in some kind of non-OO kludge mechanism... Ok, so your argument being that if a "module" can be defined using the same freedom as we define classes AND we also make sure our architecture for modules handles all that freedom then there will be much less limits to what future module "types" can be/do. Ok, I see what you mean. But... is it practical to give modules that much freedom? And just being a dumb average Smalltalker here: How do you compose your modules in Smallscript? How does a class "contain" other classes? Just curious - I could of course download and dissect but I have no time right now. > > But clearly, from David's examples, Smallscript is *not* a pure OO > > environment. Smallscript looks very cannibalized. > > Functions vs. methods vs. > > There is no versus. It sounds like you've not really understand what > classes are and how the MOP and behavior facilities support objects and > messaging. And, as a result, you do not understand the mechanisms by > which functions can be unified with an OO architecture. A function *is* > a class-method. Well. Trying to define "function" is kindof tricky. I always think of "functions" as having no state. On the other hand you could just view any state it does have access to as "parameters" and then, voila (hmmm, how do I get accents in Squeak on Linux? Strange. I just get Ž) it's a function! But given that a class method does have access to the state in the class object it is IMHO not a function. It's a class method. It can be inherited on the class side for example. Functions don't normally participate in inheritance, do they? And given all this, in Smallscript (I am guessing here), since a module is a class (and vice versa I guess) - a function in a module becomes just a class method (or vice versa). And you can of course have inheritance between modules since they are nothing else than classes. Now... what mechanisms have you added to the "class" concept to make it work as a "module concept" too? > Classes have shared/pool variables in classic Smalltalk. Therefore, > classes are already namespaces. Why retain SystemDictionary, or > non-class Pools, or introduce yet another namespace facility to confuse > everyone The Module system in 3.3alpha actually removed Pools. In the light of the Modules system they got redundant. > I agree completely. That is why it pains me to see some of the ideas > that have been implemented for namespaces in various Smalltalks. It is > also, what pains me as I see the work being done on modules, as I > project/foresee where it will put Squeak evolution a bit further down > the road. Could you state your prediction? Is it that the current system will not be able to handle more diversified "module" concepts? But honestly, do we really need so many different kind of modules? We have two different beasts today - Module and DeltaModule (the names of the classes in question). They together capture quite a lot of interesting functionality IMHO. And If we will need one or two more - fine, we should be able to squeeze that in without too much trouble. In short, in my opinion, which may be feebleminded since I am not even close to David Simmons in grasping all the meta-level questions here (and that was not meant as irony), I want a modules system which is understandable by everyone and still powerful ENOUGH. Emphasis on enough. The idea to give "module" the same freedom that "class" has feels weird to me. It would ALSO mean - and this is biggie - if we want to change the modules system we would ALSO change the class system and vice versa. I personally do not want them to be that tightly coupled. [SNIP] > > Let's not confuse Squeak. > > I am not trying to confuse or change Squeak -- to be honest it is > probably not even in my best interest to assist Squeak's evolution. It :-) :-) > is already changing, evolving, and maturing. I'm just trying to provide > some advice for the "child" (as you've characterized it) as it grows. > And, apparently, I'm doing a poor job of it. No, you are doing just fine I think. But you need to be prepared for some fire when you are so bold to say we are all doing it totally wrong. That hurts! :-) ;-) regards, Göran

1 0

Re: RolePlayers and Roles (was: PIE)
by Gilles Vanwormhoudt 26 Feb '02

26 Feb '02

Oops, >I put two papers about perspectives in object-oriented langages including the one > requested by Alan (http://www.lifl.fr/~vanwormh/povpapers/index.hmtl) The correct address is : http://www.lifl.fr/~vanwormh/povpapers/index.html Sorry. Gilles

1 0

Re: RolePlayers and Roles (was: PIE)
by Gilles Vanwormhoudt 26 Feb '02

26 Feb '02

Hi, > It seemed to me that perspectives provided a good way of getting away from > the problems of multiple inheritance. There is an Oopsla paper that makes a > similar argument. ("The Point of View notion for Multiple Inheritance", > 1990) > By the way, there has been a fair bit of work done on perspectives after > PIE. The work on "roles" is also related, and of course, all that on > subjects and aspects, too, sometimes it is more relevant, sometimes less. > Henrik >>It would be great if you could make some of the postPIE work >> available (like the paper you mention below). >>P.S. Actually there is a way to make this work for every object ... >> Cheers, >> Alan I put two papers about perspectives in object-oriented langages including the one requested by Alan (http://www.lifl.fr/~vanwormh/povpapers/index.hmtl) : - The Point of View notion for Multiple Inheritance Bernard Carré and Jean-Marc Geib ECOOP/OOPSLA'90 [This paper was written by my PHD supervisor. It introduces the "point of view" notion provided by the ROME language which limits the lookup for an object to a sub-graph of its classes (where some classes describe perspectives on objects). During my thesis, i pursued this work to apply and systematize the previous notion to a system of objects. It gives the CROME extension (Context in ROME). The idea is to increment modularly the description of a structured set of classes according to different contexts (where a context corresponds to a functional view upon the system). The description of objects particuliar to a context is defined by a new abstraction which preserve the identity and can be written independly of other context (specially, homonymous instance variables and methods are authorized). Then, objects created from the augmented classes are able to behave and communicate according to each context. In particular, it is possible to send the same message to an object in different context and get different behavior from the receiver. Concerning the implementation of point of view and context, we did not follow the PIE approach which consist in representing each perspective by a different object. This is because we consider that perspectives should not introduce new identity of objects (or you must preciously manage these identities) So, we adopt an approach based upon new kind of links between objects and classes which is somewhat similar to multiple inheritance but is more flexible (the instance-of link between a object and its class is conserved). More generally, we consider that representation of perspectives should be treated at the meta-level (that's what I done when i implement context into the ROME language which is based upon the ObjVlisp kernel)] - Representation of Complex Objects: Multiple Facets with Part-Whole Hierarchies Francis Wolinski and Jean François Perrot ECOOP'91 [This paper is an attempt to apply the PIE approach to composite objects. The system is implemented in Smalltalk]. I have a large bibliography about perspectives in object-oriented languages (citing more recent papers such as those about subject-oriented programming). Let me know if you are interested in. Cheers, Gilles.

1 0

RE: Modules and class... [ a off-topic question ?]
by Torsten.Bergmann＠phaidros.com 26 Feb '02

26 Feb '02

I completely agree with Jim. We should thank David for sharing his knowledge. Smallscript is a cool system and definitely the way for Smalltalk to go. Especially David's work on modularization, namespaces, mixins and language integration. Download it and take a closer look: www.smallscript.net The Syntactic-sugar may be a little bit confusing first - but after a while you will notice that it is pure Smalltalk. Squeak can profit a lot from Davids work. Bye Torsten -----Original Message----- From: Jim Benson To: squeak-dev(a)lists.squeakfoundation.org Sent: 26.02.02 04:57 Subject: Re: Modules and class... [ a off-topic question ?] Dave, > > I am not trying to confuse or change Squeak -- to be honest it is > probably not even in my best interest to assist Squeak's evolution. It > is already changing, evolving, and maturing. I'm just trying to provide > some advice for the "child" (as you've characterized it) as it grows. > And, apparently, I'm doing a poor job of it. > I, for one, appreciate you sharing with us your experience. To me, this is a difficult subject with lots of ramifications that aren't immediately obvious, and you have been more than generous in sharing your (working) solution and time. Thanks, Jim Benson

2 1

← Newer
1
...
4
5
6
7
8
9
10
...
67
Older →

Jump to page: