Squeak-dev January 2000

squeak-dev@lists.squeakfoundation.org

131 participants
468 discussions

Re: SqueakV2.sources
by Bob Arning 30 Jan '00

30 Jan '00

On Sun, 30 Jan 2000 18:57:20 +0530 "Mayuresh A Kathe" <mayuresh(a)vsnl.com> wrote: >Everytime I start Squeak or save any changes I get a message specifying that >Squeak is unable to find SqueakV2.sources file. I have downloaded the .sea >file and not as seperate files. > >What to do, where can I get the file from?? Mayuresh, Since the .sources file is the same from one minor release to the next, it is not usually included in the bundle of files that comprise that release. You can probably find it lots of places. Here's one: ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/2.0/SqueakV2.sources.sea.bin Cheers, Bob

1 0

SqueakV2.sources
by Mayuresh A Kathe 30 Jan '00

30 Jan '00

Hi, Everytime I start Squeak or save any changes I get a message specifying that Squeak is unable to find SqueakV2.sources file. I have downloaded the .sea file and not as seperate files. What to do, where can I get the file from?? Thanks. -- Mayuresh A Kathe Think Different. Think Better. mayuresh(a)vsnl.com

1 0

Re: woohoo! It's my first squeak/morphic alpha code!
by Stan Heckman 30 Jan '00

30 Jan '00

Robert Withers <withers(a)vnet.net> writes: This is very nice. I like it already. I modified it to work on all system windows, not just the browser. In the process, I rearranged your code more than is probably polite. I'll describe I did, so you can decide "Nah, I don't want any of those changes in my code." :-) First some really indefensible changes. There is a long history in Smalltalk of storing useful Singletons in global variables, just as you have done with WindowRaiserEventRegister. So really, I have no business messing with this. But my personal biases are that this is appropriate for the classes everyone will use, but less appropriate for classes that only a few of us will use. So I prefer putting the EventRegister in a class variable of class WindowRaiser, a class that those of us who use this enhancement will have on our systems and those who don't will not have. So I added a class variable named #EventRegister to WindowRaiser. Object subclass: #WindowRaiser instanceVariableNames: 'view timer ' classVariableNames: 'EventRegister ' poolDictionaries: '' category: 'Slosher-Tools-Extensions' Then I added class methods "initialize" and "eventRaiser" to initialize and access this variable. This is also indefensible; there is no reason that my explicit initialization is any better than your lazy initialization. initialize EventRegister := Dictionary new. eventRegister ^ EventRegister Next I add an #autoRiseOnMouseEntry method to Morph. I wasn't sure where best to put this; I've stuffed it into "event handling" for now. This may be no more defensible than my previous changes. I find my rewrite easier for me to read, but these things are vary from person to person, and you probably like your own version better. In any case, you should recognize that this is exactly your #openBrowserView:label: code, just rearranged a little. !Morph methodsFor: 'event handling' stamp: 'sjh 1/28/2000 16:08'! autoRiseOnMouseEntry self on: #mouseEnter send: #value to: [WindowRaiser eventRegister at: self put: ((WindowRaiser newOn: self) waitFor: 500)]. self on: #mouseLeave send: #value to: [(WindowRaiser eventRegister removeKey: self ifAbsent: [^ self]) stop] Now any morph that receives the method "autoRiseOnMouseEntry" will begin exhibiting your autorise behavior. Let's arrange to have this message sent to all system windows when they are started up. We change the openInWorld and openInWorld: messages of SystemWindow. !SystemWindow methodsFor: 'open/close' stamp: 'sjh 1/28/2000 16:10'! openInWorld self autoRiseOnMouseEntry. super openInWorld! ! !SystemWindow methodsFor: 'open/close' stamp: 'sjh 1/28/2000 16:16'! openInWorld: aWorld "This msg and its callees result in the window being activeOnlyOnTop" self autoRiseOnMouseEntry. self bounds: (RealEstateAgent initialFrameFor: self). aWorld addMorph: self. self activate. aWorld startSteppingSubmorphsOf: self! ! Thats all I did. With these changes, all system windows (or at least those I tested) exhibit your autorise behavior. Thanks again for your useful change set; I'm already enjoying how much less clicking I have to do this way. I hope it is popular with more squeakers than just the two of us. I despair of it ever being popular with the majority; my coworkers think my workstation is cursed because whenever they move the mouse "out of the way", some window comes up from behind and obscures what they were reading, sort of like a cat that wants attention so sits on the newspaper you are reading. :-) Auto rise is an acquired taste. I'm interested in any questions or comments you may have. -- Stan

3 3

Re: Full Closures - when do they close?
by Robert Withers 30 Jan '00

30 Jan '00

This raises a question, Jan. What is the full set of variable bindings in Smalltalk (VW). Global, makes some sense, but what about semi-global and local. Would this be the difference between external bindings in a closure versus argument bindings to the closure? The next step from here seems to be the impact of namespaces on these concepts. Or rather, do these concepts help in the structuring of a namespace? cheers, Rob "demiourgos(a)smalltalk.org" wrote: > > On Thu, 27 January 2000, Robert Withers wrote: > > > > > I was looking at Lisp Lambdas and at BlockContext and BlockClosure. It > > seems that lexical closures ala Lisp and BlockClosures do this closing > > over the variables. It looks like a BlockCLosure makes copies of all of > > the referenced variables in the block. I don't understand a few things > > about this. > > > > - At what point in the lifecycle are the copies of bound variables made? > > > > and > > > > - Are they deep copies? It seems that you could navigate to an internal > > Object of a bound object and that may have changed in the meantime. > > Robert, > > I can't speak for Squeak, since I'm not that familiar with its innards, > nor, really, for Common LISP, but I am familiar with what used to be > called MacLisp and an IBM Research (Yorktown) LISP once known as > LISP/VM. The former had the machinery to build these "contexts" but > AFAIK didn't have them built-in. In LISP/VM, however, there was a > function called "context" which returned a pointer to a complete set of > variable bindings: local, semi-global, global, and if one did > > (setq x (context)) > > then later > > (eval <expr> x) > > the evaluation was done in the context "frozen" by the call to "context". > The idea here was to provide a cheap way for "backing up" in the > exploration of a problem and forgetting about everything touched since. > > There was one exception that prevented endless looping, I believe. > (And I apologize in advance, because I'm a little fuzzy on this.) If > one evaluated > > (context x) > > in the context specified by the value of x, it would return NIL. > > --jtg > > [snip] > > ______________________________________________________ > Jan Theodore Galkowski www.smalltalk.org/ > http://www.scguild.com/usr/1707I.html > demiourgos(a)smalltalk.org www.marssociety.org/ > ********************************************** > PGP Key Fingerprint: 2757 F86D AA51 677D 38D7 > 964B 9A8D 7852 A494 3790 > ********************************************** > Get my Public Key from my home page at: > http://home.stny.rr.com/algebraist/ > ********************************************** > > ______________________________________________ > > Get free e-mail at http://www.britannica.com -- -------------------------------------------------- Smalltalking by choice. Isn't it nice to have one!

1 0

Re: Type Safety (was Re: fun and empowerment)
by garau＠ar.ibm.com 30 Jan '00

30 Jan '00

> reason I mention it here is the idea that you can run Dylan in two modes: > a dynamic, interactive, prototyping mode for development, and an > efficiently compiled, static mode for delivery. Now for the $400,000 > question: how difficult would it be to add that sort of capability to > Squeak? :) I forgot to tell than a requirement for an efficient, compact and safe (meaning that every message will be understood) application is to work under a 'closed world' assumption. This means that you have to fix the classes and methods to be analyzed. This is a trade-off... If you want flexibility use late-binding, if you want efficiency use static-binding. I don't know how Squeak applications will be distributed in the future. If we take the current approach of 'closed' programs, then we are in the right direction. If we think that distributed applications could be opened and extended, then we will have to live with late-binding and think of some other way to gain efficiency (Type Feedback perhaphs...). Regards, Francisco (Pancho) Garau Ph: (5411) 4319-6213. Fax: (5411) 4319-6422 garau(a)ar.ibm.com (work) - - - fgarau(a)bigfoot.com (home)

2 1

Re: [BUG] BitBlt crash
by Bob Arning 30 Jan '00

30 Jan '00

On Sun, 30 Jan 2000 00:27:54 +0100 Helge Horch <Helge.Horch(a)munich.netsurf.de> wrote: >1.) add a RectangleMorph to a World and open an Inspector on it, >2.) in the Inspector, change its bounds' extent to, say, (100/3) >3.) summon restoreDisplay (BitBlt complains, and recommends to proceed) >4.) proceed from the PreDebugWindow > >Repeat steps 3-4 until BitBlt gives up, and you get the error dump. Third >time should do it. > >I examined BitBlt's self-healing code, and can't find any fault. > >Can anyone else shed light on this? Or is this only bad karma on my machines? Helge, It's not you and it's not BitBlt. When you get an error while drawing a morph, the world (PasteUpMorph>>displayWorldSafely) tries to mark the morph in queation as having an error so that the drawing is not retried. This is where you will usually see the red rectangle with the yellow diagonals drawn. The problem here is that you messed up the morph's extent and so the attempted drawing of the red-and-yellow failed as well. At that point the world tries to widen the exclusion: "If the morph causing the problem has already the #drawError flag set, then search for the next morph above in the caller chain." sooner or later this will fail and a fatal error will be the result. Below is a fix to allow your example to proceed benignly, but more could be done, perhaps a more thorough check of <bounds> in case it's <nil> or has non-numeric components. Cheers, Bob ======= 'From Squeak2.7 of 5 January 2000 [latest update: #1789] on 29 January 2000 at 9:13:53 pm'! !Morph methodsFor: 'drawing' stamp: 'RAA 1/29/2000 21:13'! drawErrorOn: aCanvas "The morph (or one of its submorphs) had an error in its drawing method." bounds _ bounds truncated. "catch one cause of recursive errors" aCanvas frameAndFillRectangle: bounds fillColor: Color red borderWidth: 1 borderColor: Color yellow. aCanvas line: bounds topLeft to: bounds bottomRight width: 1 color: Color yellow. aCanvas line: bounds topRight to: bounds bottomLeft width: 1 color: Color yellow.! !

1 0

Re: Type Safety (was Re: fun and empowerment)
by Mark Guzdial 30 Jan '00

30 Jan '00

> > Does anyone know of any empirical evidence for the value > > of types? > > Or is it a myth that we invented to rationalize the typing > > needed to improve the compiler's performance? > >Peter Norvig's book "Paradigms of Artificial Intelligence Programming: Case >Studies in Common Lisp", 1992, Morgan Kaufman Publishers Inc. comes out >strongly in favour of type-declarations, citing a case on page 318 where >various hints to the compiler give a 40x speedup, so I see no need to >rationalize. I do believe that types lead to better compiler output -- I agree, no need to rationalize that. The "value" that I'm questioning is that types lead to more bug-free code, that types "catch errors at compile time." That claim seems untested yet, and I'm not even sure where it came from. Is it a rationalization, e.g., "Well, we have to have types to make the code better -- let's claim that it's good for the programmer to use types! Improves their thinking, let's say!" Well, maybe... Mark -------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 (404) 894-5618 : Fax (404) 894-0673 : guzdial(a)cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html

6 5

[BUG] BitBlt crash
by Helge Horch 30 Jan '00

30 Jan '00

Folks, I am having trouble diagnosing a hard crash. Happens both in 2.7 and 2.8a: BitBlt, after failing due to non-integer parameters, corrects them and proceeds to crash later. Yes, I know one shouldn't pass non-integral Rectangles, but it just so happened. (I had a Morph override >>extent: and left a stray "super extent: h/2 @ h" in. ;-) Here's the easiest way to reproduce it: 1.) add a RectangleMorph to a World and open an Inspector on it, 2.) in the Inspector, change its bounds' extent to, say, (100/3) 3.) summon restoreDisplay (BitBlt complains, and recommends to proceed) 4.) proceed from the PreDebugWindow Repeat steps 3-4 until BitBlt gives up, and you get the error dump. Third time should do it. I examined BitBlt's self-healing code, and can't find any fault. Can anyone else shed light on this? Or is this only bad karma on my machines? Puzzled, Helge P.S. SqueakDebug.log follows: 29 January 2000 11:54:04 pm Error: Error: Bad BitBlt arg (Fraction?); proceed to convert. GrafPort(Object)>>error: [] in PasteUpMorph>>displayWorldSafely [] in BlockContext>>ifError: Error(Exception)>>handlerAction Error(Exception)>>signal Error(Exception)>>signal: GrafPort(Object)>>error: GrafPort(BitBlt)>>copyBits GrafPort>>copyBits GrafPort>>fillRect:color:offset: FormCanvas>>frameAndFillRectangle:fillColor:borderWidth:borderColor: RectangleMorph(Morph)>>drawErrorOn: RectangleMorph(Morph)>>fullDrawOn: RectangleMorph(BorderedMorph)>>fullDrawOn: [] in PasteUpMorph>>drawInvalidAreasOn: Array(SequenceableCollection)>>do: PasteUpMorph>>drawInvalidAreasOn: PasteUpMorph>>displayWorld [] in PasteUpMorph>>displayWorldSafely BlockContext>>on:do: BlockContext>>ifError: PasteUpMorph>>displayWorldSafely PasteUpMorph>>doOneCycleNow PasteUpMorph>>doOneCycle [] in Project>>spawnNewProcess [] in BlockContext>>newProcess

1 0

Re: Type Safety (was Re: fun and empowerment)
by merlyn＠stonehenge.com 29 Jan '00

29 Jan '00

>>>>> "garau" == garau <garau(a)ar.ibm.com> writes: garau> In Squeak a message send doesn't tell you which method will be garau> invoked. You need to know the type of the receiver first. If garau> after analyzing the whole program (a starting expression) you garau> got only one particular receiver type, then you know the method garau> that will be invoked at run-time. You can inline the method or garau> replace the late binding with a static binding. Cool!! I had a student in my Object Oriented Perl course yesterday tell me that his employer won't let him use *any* "object oriented" languages, because they build embedded systems that have to be FAA certified, and FAA will only certify if you've done a complete call-flow analysis. So instead, he has to do all his work in C (!!!!). Gack. Like that's any better? Somehow, I think this company he was from was not up on the latest tools, or perhaps the FAA is being overly paranoid. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

2 1

Type Safety (was Re: fun and empowerment)
by Lex Spoon 29 Jan '00

29 Jan '00

Mark Guzdial <guzdial(a)cc.gatech.edu> wrote: > >In the one and only case in my experience in which I advocated using > >Smalltalk for a significant project, the "technical" folks on the > >project voted the idea down in favor of Java, which they believed to > >have advantages in performance, type safety, and market acceptance. > >Draw what conclusions you like from this, but don't a priori assume > >that "management" is the source of all difficulties. > > So, I've taken to asking students (in oral exams, office hours, and > the like) what evidence they have that "safe types" buys them > anything? > > "The types help the compiler catch errors in the program," they > respond. I ask them if the types really do. Do the warnings really > point to errors, or just type problems? Are they errors that you > would have found easily and quickly without the types? Then there's > the cost of types. Casting, declaring types, and fixing code to > address warnings takes a good bit of time. Is the cost worth the > benefit? > > But this is actually more than me being "pedagogues who look on their > profession as an opportunity for pederastic abuse" :-) I'm seriously > interested: Does anyone know of any empirical evidence for the value > of types? Or is it a myth that we invented to rationalize the typing > needed to improve the compiler's performance? > Let's leave aside for now the "types" assigned to the interface of a component, and talk about building monolithic software. First, most people, when pressed, will either back off of the type-for-safety argument or just become silly. (no types? what a silly idea). Sometimes they'll say they find errors more quickly, but this is a thin argument if your unit tests run as quickly as their compiles do. That leaves three arguments that actually are viable: 1. Types help with speed. 2. Types form a basis for formal proofs. 3. Types help programmer understanding. The first two are not very important to most people. That leaves understanding. So. How much information does a type annotation provide? How much does it matter if the annotations are checked by the compiler or by the runtime? (Dynamic checks have the advantage that one type anontation won't virally infect the rest of the system.) And how does all of this compare to the benefits of writing unit tests? Once a person can blow off safety, speed, and proofs, which is usually easy, understanding is the real question they should address. And when you think about it, a type system developped for understanding would probably *not* be the same as one designed for any of the other purposes (with the possible exception of proofs). Understanding seems to be the crux of the debate nowadays. Like Java, types were introduced for a specific purpose, but the true reason keeps morphing over time. Lex

1 0

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

Jump to page: