Squeak-dev July 1999

squeak-dev@lists.squeakfoundation.org

139 participants
367 discussions

Re: [ENH] OS-level events
by Lex Spoon 01 Jul '99

01 Jul '99

"Peter William Lount" <peter(a)smalltalk.org> wrote: > One of my questions is "what will happen to the Controller loop" with an > event based Smalltalk"? I guess that it goes away and gets replaced by > something like the NSApplication loop. I'll have to explore some event > based Smalltalks to find out... What are you guys planning to do with the > controller loops? > In Morphic, they're actually already gone. That's why you can scroll a text pane and have your BouncingAtomsMorph keep bouncing around while you do it. Of course, the logic for menus and for text highlighting and things like that, which take a long time to execute, are made more complicated because they have to store intermediate states in instance variables--the extra interactivity is not for free. Lex

1 0

Re: ScrollPane design question was: Speaking of the latest version...
by Bob Arning 01 Jul '99

01 Jul '99

On Sat, 26 Jun 1999 17:37:19 -0600 David Farber <dfarber(a)numenor.com> wrote: >so, i "fixed" both of these problems by rewriting addMorph: in ScrollPane to >add new morphs to the scroller and then update itself. (i also had to make >changes to initialize.) > >and it was Good. > >until, in the course... David, I wonder if it might be better not to rely on #addMorph: and its variants for the purpose of putting morphs into some sort of scrolling container. Perhaps a different protocol would make the intention clearer and avoid changing behavior that may be needed elsewhere. Enclosed is a small sample. File it in and evaluate "GenericScrollPane test". Cheers, Bob 'From Squeak 2.3 of January 14, 1999 on 1 July 1999 at 11:21:48 am'! ScrollPane subclass: #GenericScrollPane instanceVariableNames: 'scrollingMorphHolder ' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Windows'! !GenericScrollPane methodsFor: 'as yet unclassified' stamp: 'RAA 7/1/1999 11:14'! addScrollingMorph: aMorph scrollingMorphHolder addMorphBack: ( AlignmentMorph newRow color: Color transparent; addMorph: aMorph ). ! ! !GenericScrollPane methodsFor: 'as yet unclassified' stamp: 'RAA 7/1/1999 11:14'! initialize super initialize. scroller addMorph: ( scrollingMorphHolder _ AlignmentMorph newColumn color: Color transparent ). ! ! !GenericScrollPane methodsFor: 'as yet unclassified' stamp: 'RAA 7/1/1999 11:01'! layoutChanged super layoutChanged. self resizeScrollBar; resizeScroller; setScrollDeltas ! ! !GenericScrollPane class methodsFor: 'as yet unclassified' stamp: 'RAA 7/1/1999 11:21'! test "GenericScrollPane test" | pane window | window _ (SystemWindow labelled: 'GenericScrollPane test') model: self. pane _ GenericScrollPane new. pane color: Color white. pane addScrollingMorph: (EllipseMorph new extent: 50@90). pane addScrollingMorph: (RectangleMorph new extent: 50@90). pane addScrollingMorph: (StringMorph contents: 'Hello world'). pane addScrollingMorph: (TextMorph new). pane addScrollingMorph: (EllipseMorph new extent: 300@300; color: Color blue). window addMorph: pane frame: (0@0 extent: 1@1). window openInWorld ! !

1 0

Re: On Reuse
by Marcel Weiher 01 Jul '99

01 Jul '99

The image "melting pot" approach is one of the problems with reuse. One part of reusing a component is to know what *requirements* the component makes on its environment. Because of the image model, the environment of any piece of code is the entire image used by the code's author, so the only safe assumption is that everything needs to be exactly the same. The actual requirements will usually be less, but figuring this out is not an easy task (right Les?). The other part of reuse is actually *using* the component. One essential aspect of this is the "packaging" of the functionality, an aspect that is often neglected. The Trampoline is an (extremely simple!) example of packaging. It doesn't add any new capability, it just provides packaging to existing functionality that makes it that much easier to use. In short, component encapsulation instead of (or rather in addition to) class encpasulation. There is no need to lose the efficiency of image-based development on the way: an image references various components, changes are made to the image, leaving the components "as is". The changes are pushed out to the components in batches, with each such batch-change incrementing at least a minor version number. The result is two-tiered code evolution model: quick image based class/object evolution, and slower component evolution. Marcel > From: Peter Crowther <Peter.Crowther(a)IT-IQ.com> > > I contend that Smalltalks aren't like that. One Smalltalk image is a > melting pot containing a large number of smaller products. Code duplication > that would be acceptable in two different products that would never see each > other is now less acceptable as the two products may well co-exist in the > same image, with different (and occasionally highly incompatible) > implementations of the same idea. What happens if I have built a product > based on one set of event code, you have built a product based on another > set of event code, and a third party wishes to use both our whizzy products > in the same image? Do the two event models end up fighting for keyboard and > mouse events from the OS? Or are the code changes for the two event models > are so incompatible that they cannot even be compiled into the same VM? > Lack of re-use isn't always harmless.

1 0

Re: Mail archive problems
by bobh＠agents.com 01 Jul '99

01 Jul '99

>To anyone-- > >There seem to be some problems (or oddities, at least) with the Mail archive >at > >http://squeak.cs.uiuc.edu/mail/ I've begun using the Squeak archive at eGroups. It has a pretty good keyword search capability, and the archive is current. The URL is: http://www.egroups.com/group/squeak/

1 0

RE: Is sqeak 2.3 beta ready for Y2K?
by Steven Salter 01 Jul '99

01 Jul '99

-----Original Message----- From: Stephen Pair [mailto:spair@advantive.com] Sent: Thursday, July 01, 1999 8:51 AM To: squeak(a)cs.uiuc.edu Subject: RE: Is sqeak 2.3 beta ready for Y2K? ....and Y3K, Y4K, Y5K, etc... Date today -> "31 July 1999" Date today addDays: 400 -> "4 August 2000" Date today addDays: 4000 -> "13 June 2010" Date today addDays: 40000 -> "5 January 2109" Date today addDays: 400000 -> "29 August 3094" Ummmm... July 31st? Steven "Rip van Winkle" Salter, MCSD Chronicle Technologies Inc. http://www.chrontech.com

2 1

RE: Is sqeak 2.3 beta ready for Y2K?
by ohshima＠is.titech.ac.jp 01 Jul '99

01 Jul '99

Hi, > ...which doesn't mean that people couldn't write their own > bad (non-Y2K safe) code in Squeak, but at least the Date > class in Squeak (which most reasonable people use) can > handle it with no problem. But on some platform the OS and/or OS interface functions might cause the problem. I'm not so confident that my implementation of ioSeconds() and convertToSqueakTime() is 100% safe especially when I think of the leap seconds :-<. OHSHIMA Yoshiki Dept. of Mathematical and Computing Sciences Tokyo Institute of Technology

1 0

Is sqeak 2.3 beta ready for Y2K?
by Harold Miles 01 Jul '99

01 Jul '99

I am sending this email from the University of Central Florida. Can you please send me a Y2K statement or direct me to your url with Y2K information. Thank you. Harold R. Miles Specialist, Computer Applications Academic Computer Support (407)823-5520 FAX (407)823-3238 harold(a)mail.ucf.edu

1 0

Smalltalk Style Resources
by Peter William Lount 01 Jul '99

01 Jul '99

Hi, Since this topic neads some humour I've included this style web site that contains a warning from Batman. http://cs.loyno.edu/cosc216/serules.htm ;--) I'm attempting to collect a list of Smalltalk Style Rules and Guidelines for a www.smalltalk.org web page. Please contribute if you know of any web pages. Also, I came across this interesting statement "The Smalltalk archives at UIUC will soon contain a 'Style Checker' tool that detects classic Smalltalk bugs and points out possible errors according to some rules about error-prone coding styles." on the ByteSmiths web page. Does anyone know if this code exists somewhere? All the best, Peter William Lount peter(a)smalltalk.org http://www.smalltalk.org The list so far: Smalltalk Style Guides http://cs.loyno.edu/cosc216/serules.htm http://www.bytesmiths.com/Publications/9511SmalltalkStyle.ssi Mentions of Smalltalk is other Style Guides http://hepunx.rl.ac.uk/atlas/oo/languages/C++/style-may13.html http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser/LintChecks.html http://www.chimu.com/publications/javaStandards/part0003.html

2 1

Re: [ENH] OS-level events
by Peter Smet 01 Jul '99

01 Jul '99

>> Why can't low and high level events share the same abstractions, >> and even be placed on the same event queue? I also think exception-handling >> has much in common with event handling (on: exception do: aBlock). The >> exception looks to me very much like an 'event' that the block is told >> about. Is it possible to fuse these three mechanisms into a common >> abstraction and reuse a lot of the code, or is this just wishful thinking on >> my part? David M. Siegel wrote: > >I'm afraid it's wishful thinking. > >Events are delivered asynchronously. The event generating process is normally >not the one that receives the event. > >Exceptions should be delivered synchronously, to the same process that raised >the exception, with access to the context at the point where the exception was >raised. > >Updates (subscriptions) could be delivered asynchronously, but that's not the >Smalltalk tradition. Quite a bit of Smalltalk code assumes that updates are >handled immediately after they're generated, before the generator executes >the next line of code. > Thanks for pointing that out. Now that you have, I'm curious about the last part. Since an object makes such minimal assumptions about dependents, why is update synchronizing so important?. A model shouldn't even really know whether it has 0, 1 or more views, so why does it care about their update times? I can see from an extreme viewpoint that a 2 hour update delay could cause problems with views not representing their models correctly. However, if the view contents had the same (asynchronous) timing as mouse and keyboard events, I don't see a problem. You could get situations where the view did not represent the model quite accurately, but since they are meant to be 'loosely coupled' (whatever that means) this should not (in theory) cause devastating effects. When I get a bit of time I might get Stephen's asynchronous messaging stuff, attempt to plug it into my PostOffice, and see which things stuff up. With the exceptions, there doesn't seem any way this could be done asynchronously (without serious effects on program reliability), but I will go away and have a think about that too. Maybe if exceptions were given the right priority in the event and thread queue things could hang together??? Peter

2 1

Mail archive problems
by JArchibald＠aol.com 01 Jul '99

01 Jul '99

To anyone-- There seem to be some problems (or oddities, at least) with the Mail archive at http://squeak.cs.uiuc.edu/mail/ These have been going on for about six weeks. Can anyone tell me who is the administrator of that resource? Jerry Archibald

1 0

Jump to page: