Squeak-dev February 2002

squeak-dev@lists.squeakfoundation.org

202 participants
665 discussions

Re: Serialization
by jescoto＠objective.com.br 28 Feb '02

28 Feb '02

Ok, Squeak does. Is there any example, tutorial, paper or swiki page about how to serialize instance objects in Squeak ? If the answer is "yes", could you, please, say where ? Thank you Bert Freudenberg <bert(a)isg.cs.uni-magdeburg.de> To: squeak-dev(a)lists.squeakfoundation.org Sent by: cc: squeak-dev-admin(a)lists.squeakfoun Subject: Re: Serialization dation.org 28/02/2002 11:44 Please respond to squeak-dev On Wed, 27 Feb 2002 jescoto(a)objective.com.br wrote: > Does Squeak have serialization ? Yes. SCNR -- Bert

3 2

Serialization
by jescoto＠objective.com.br 28 Feb '02

28 Feb '02

Does Squeak have serialization ?

2 1

Re: "zombie" question (was: [newbie]Does Model + Morphic = MVC?)
by Lex Spoon 28 Feb '02

28 Feb '02

> The term "zombie" has a very specific, if somewhat whimsical, meaning > for a Unix operating system. On Unix, every process is created ("forked") > by a parent process. The parent process is expected to wait for its > child to exit, after which the parent collects certain statistics about > the completed child process. When a child process has executed the exit() > system call, but its parent has not yet collected those statistics, the > child process is said to be in the "zombie" state. Think of it as a > process which as died but has not yet left this world. Zombies are also a general idea. I think if you told any computer science person that there were zombie objects in your system, they would understand what you mean: you have dead objects (of whatever kind) floating around, but for consistency's sake they can't yet take the final step into the abyss. Granted, I can't think of a specific example.... (Of course, if the objects are still being used, it means the objects aren't *really* dead after all, doesn't it? But then, are zombies really dead? Hmmmm. :)) -Lex

3 2

Re: mac os-x -> Need multiple button mice with scroll wheel
by Brian Keefer 28 Feb '02

28 Feb '02

> > As squeak stands now, the keyboard hack sends mouse events to a window the > > mouse may no longer be pointing at, which is a bad inconsistency. > > What do you mean? X won't send the X mouse events to any window but the one > that the mouse is over (depending on the Window Manager's focus policy, I > guess). I should have said Morph instead of window. The keyboard hack sends mouse events to a MORPH that the mouse may not be pointing at. Focus on a Workspace, and scroll it around with your mousewheel. Now, move your mouse out of the workspace window (still inside the squeak world), and continue scrolling the workspace. > The keyboard hack actually just takes X mouse events (which come into a > window the same way that mouse motion, etc. events do) and sends the image > keystrokes. It steals controls from a pointing device and gives them to a non-pointing device. A "pointing device" is able to specify which window/widget its event is meant for. Non-pointers, like the keyboard, depend upon a fantasy pointer (focus) to send their events to a window. > Is there a case in X where a window would get mouse events but not keyboard > events? An X window manager can allow any mouse event through to an unfocused window. On certain events (say, a button 1 click), it could finally decide to change the application(and keyboard) focus.

1 0

Re: mac os-x -> Need multiple button mice with scroll wheel
by Brian Keefer 28 Feb '02

28 Feb '02

1 0

RE: Modules and class... [ a off-topic question ?]
by Lex Spoon 28 Feb '02

28 Feb '02

> > I think my intuitive decomposition of classes and modules may be > similar > > to others', so let me toss it out. > > > > A class primarily declares a number of instance variables, and holds a > > number of methods, and can be instantiated. It can also define > > variables in a local scope, but that's secondary and not even > necessary > > if we have modules. > > You've described a constructor, not a class. Does a constructor include a specific definition of instance variable layouts, and a specific set of methods? > > A module primarily defines variables in a local scope. Theoretically, > > it could have instance variables, could have methods, and could even > > allow instantiation. These abilities are not only secondary, but > might > > not be necessary at all. > > You've described a namespace, not a module. A namespace is one of the most important parts of a module. Another important part is dependency information, which normally wouldn't be included in an individual class (you could, but it would seem like quite a burden!). What aspect of modules have I left out, that you consider important? Overall, these descriptions seemed pretty obvious to me. If you are using different terminology, that would probably explain a lot of the apparent disagreement in the modules discussions here. -Lex

3 4

RE: Any dual processor os-x mac users out there?
by Jerry Bell 27 Feb '02

27 Feb '02

Hi, My wife works at an Apple Store, so she has access to nifty things like dual 1Ghz G4 boxes. She'd be happy to run some tests for you there if you'd like and if you can give her instructions. Jerry > -----Original Message----- > From: squeak-dev-admin(a)lists.squeakfoundation.org > [mailto:squeak-dev-admin@lists.squeakfoundation.org]On Behalf > Of John M > McIntosh > Sent: Wednesday, February 27, 2002 3:11 PM > To: squeak-dev(a)lists.squeakfoundation.org > Subject: Any dual processor os-x mac users out there? > > > I'm going to need a mac user that has a dual processor machine that > is running OS-X so I can confirm the correct usage of pthread mutex > semaphores to prevent race conditions between the UI input thread, > and the VM thread. > > This is hard to test, other than by reading the code, when you've > only one processor. Mind even with a two processor box it's hard to > confirm it's correct, but if I can say it doesn't lock up in the > first 30 seconds then I'm happier. > > Unless of course someone wants to spring for a dual processor mac for > me... (I'm quite willing to listen to offers)... > -- > -- > ============================================================== > ============= > John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 > Corporate Smalltalk Consulting Ltd. > http://www.smalltalkconsulting.com > ============================================================== > ============= > >

1 0

Any dual processor os-x mac users out there?
by John M McIntosh 27 Feb '02

27 Feb '02

I'm going to need a mac user that has a dual processor machine that is running OS-X so I can confirm the correct usage of pthread mutex semaphores to prevent race conditions between the UI input thread, and the VM thread. This is hard to test, other than by reading the code, when you've only one processor. Mind even with a two processor box it's hard to confirm it's correct, but if I can say it doesn't lock up in the first 30 seconds then I'm happier. Unless of course someone wants to spring for a dual processor mac for me... (I'm quite willing to listen to offers)... -- -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> 1-800-477-2659 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

RE: Behavior design options (was: Behaviors vs Modules)
by Nathanael Schärli 27 Feb '02

27 Feb '02

> On Wednesday 27 February 2002 05:20 am, Nathanael Schärli wrote: > > > a) Whenever someone wants to use two mixins with the same > selector x, the > > browser shows this selector in a special category "-- conflicts --" and > > defines it as "self error: 'Mixin conflict!'" per default. This > means that > > the programmer has to resolve the conflict himself. > > > > b) When two mixin define the same selector, they cannot be used > in the same > > class > > Given that one can add or change methods at any time, when would > the mixin > conflicts be detected? Would you require an analysis of the entire system > every time a class or method changed? A new conflict can only occur if we add a new method to a mixin. However, since mixins are typically only used in a very limited number of classes, the only thing we have to do is to check whether there is a conflict in one of these classes. (Because every mixins knows which classes it is used in, that's a matter of milliseconds). If there is a conflict in a class, we make sure that the conflicting selector also appears in the "conflict category" of this class. In addition, we should probably inform the user with a popup message. And as I said before, if mixins are designed and used in a proper way, I don't think that there are going to be many conflicts anyway. I'm just about to finish my first prototype implementation and then I'll be able to see how well it works and what problems I am running into. Nathanael BTW: In my first implementation, I'm going to deal with conflicts as described in a). I have described it in more detail in an earlier message of the thread "Behaviors vs Modules"

1 0

RE: Behavior design options (was: Behaviors vs Modules)
by Anthony Hannan 27 Feb '02

27 Feb '02

Nathanael <n.schaerli(a)gmx.net> wrote: > > > Well, lets look at different designs from simple to complex: > > > > A := Just single-inheritance classes. (today's Squeak) > > B := A + default methods (each selector has a default method that will > > execute if the receiver's hierarchy does not define a method for that > > selector. Default methods cannot access instance variables, they only > > can send messages). > > C := A + protocols (a protocol is a group of selectors, providing > > selector namespace. Each selector belongs to one and only protocol. > > Selectors in different protocols can have the same name, but they are > > considered different selectors, meaning the sender has to choose which > > one he means if its not obvious). > > D := A + mixins (a mixin is a set of methods that may be shared among > > different classes. Like default methods, mixin methods cannot access > > instance variables). > > E := B + C. > > F := C + D. > > G := B + D. > > H := B + C + D. > > I := Object roles/perspectives (ie. PIE). > > J := Multiple-inheritance classes. > > > > I encourage people to vote for one they like the best (with an > > explanation of course) and/or add new designs to this list. > > I have been thinking about these design decisions a lot recently, and the > more I think about them, the more I like having a concept that supports > explicit grouping and sharing of a related methods. I agree, but I think the group should include all related methods not just ones for a particular receiver type, this is too fragmented. For example the "rectangle" group (lets call it a module) would contain all the methods that would be in a RectangleMixin plus all methods in Point that create rectangles (#corner: #extent: #rect:). When browsing the rectangle module, methods could be grouped by receiver variable name (ie. informal receiver type). In other words, I favor a single module per aspect versus multiple mixins per aspect. And I don't favor both (a single module containing many mixins) because I think it is overkill, too many standard names (module names and mixin names). Informal receiver variable names would be sufficient for sub grouping by receiver type. > Building a class from different mixins makes a design much cleaner, because > it explicitely shows: > - What kind of aspects a class consists of > - What's the protocol that is supported by each individual aspect > - How these aspects are glued together > This makes a design much easier to understand. If you want to > look at a class very briefly, you get a good idea of what it does by just > knowing what mixins it implements. I agree, but modules can serve the same grouping purpose. Just like methods in an module can be grouped by receiver variable, methods in a class can be grouped by the module of the default method they are overriding. For example, if the Point class overrode #corner: it would sit in the "rectangle" module protocol. If Point did not need to override any of its "rectangle" methods, the browser could still figure out which messages are available to Point by tracing senders of the selectors it overrides and using type inference to figure out which default methods palce its receiver in a position where it is sent any of the Point's overriding selectors. I know this is difficult but I think it is important to infer as much information as possible before we require the programmer to add more structure. We should strive to keep Smalltalk as flexible and decoupled as possible. That is why I like default methods in the first place, it removes class/mixin coupling from potentially 80% of the methods. In the interim, before we get a good type inferencer, the browsers can compare receiver variable names to class names and show those default methods whose receiver variable names are close to the class name. > So, why do I prefer having explicit mixins over just having default methods, > which also allow sharing behavior (without inheritance)? > Default methods only allow to provide *one* sharable implementation per > selector. For some selectors, this is all that is needed (e.g. 'select: > aBlock' or 'collect: aBlock' are (nearly) always implemented the same way), > but there are other selectors which may be implemented in many different > ways. This is particularly the case if a programmer wants to create and > share different implementations of one protocol. As an example, a programmer > might want to create different policies for 'instance variable management', > 'class variable management', 'method dictionary management' and would then > like to combine them freely in order to create one (or more) very specific > Class. Mixins do provide this extra benifit that default methods don't, but I don't think they are worth the extra structure and standard names. If you want to define different behaviors for the same protocol, you can just use classes and delegation instead of mixins. > In my eyes, the biggest limitation of just having default methods is the > fact that there is no way of grouping them together and create first class > "behaviors". Such an explicit grouping of > methods raises the level of abstraction when we build classes, because it > allows us to compose classes from *a few* mixins (and some glue code) > instead of building them from *many* individual methods. > As a simple example, imagine that we would like to write several classes > that contain a rectangle aspect. Having mixins, we would first write a > RectangleMixin that provides all the necessary methods (such as area, > extent, etc.). (Of course, we could also generate such a mixin from the > class Rectangle). Looking at this mixin in the browser, we see that it > requires only four selectors (namely origin, origin:, corner, corner:) to > make it complete. Thus, when we import such a mixin into a class, the > browser immediatly shows that these 4 selectors are the ones that are > necessary to glue the mixin and the class together. Once these selectors are > properly defined (in case of the class Morph, we would use 'position' and > 'extent' to do so), we can be sure that all the other methods of > RectangleMorph are working properly (since we already use them in other > classes). Later, when another programmer looks at our class, the browser > shows him that it contains of the mixin RectangleMixin and it also shows him > the glue code that is used to put the mixin into the class. This means that > this programmer immediatly knows that the class understand the mixin > protocol (in Squeak, these are 88 selectors) and he can see how it is glued > into the class by looking at 4 selectors. In addition, he sees that the 88 > selectors from RecatngleMixin belong together and that he does not have to > consider them for debugging if there is anything wrong. (Instead, he should > focus on the glue methods). Modules can provide the same information as mixins, but for more than just one receiver type. Required methods would be those who default method is "self subclassResponsibility" Anyway, I totally see your way (mixins) and how Squeak would benefit. I am just leaning towards default methods since it decouples potentially 80% of the methods from any class or mixin. It allows reuse on unforeseen classes like those coming from another image, without requiring the unforeseen class to associate itself with the local behavior first. Also, not having mixins saves us from dealing with another set of standard names that will have to be coordinated across images. Cheers, Anthony

1 0

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

Jump to page: