Squeak-dev August 1998

squeak-dev@lists.squeakfoundation.org

99 participants
188 discussions

Re: nil or #nil?
by JArchibald＠aol.com 26 Aug '98

26 Aug '98

What is a literal? Well .... A literal is an sequence of characters in the source language which denotes a constant in the target. (somehow an always should be in there somewhere) I think we can think of nil, true and false as literals, if we just didn't have the combined forms #nil, etc. It would just mean nil, false, and true become reserved words, and then the previously mentioned problem with defining array literals. Jerry.

3 2

Re: nil or #nil?
by Bob Arning 26 Aug '98

26 Aug '98

On Tue, 25 Aug 1998 23:35:08 -0500 m3rabb(a)stono.com (Maurice Rabb) wrote: >In my mind this should also work: >#((65+2) $A (65 asCharacter) ('aString' size) (nil isNil)) >==> #(67 $A $A 7 true) > >because everything there is knowable at compile time. More radically: > >#((Dictionary) (Set new: 20) (Integer class)) >==> #(Dictionary aSet Integer-class) > While I sympathize with the desire to be able to include true, false and nil (the objects, not the symbols) in a literal array and while I do not object to putting #'s before things I want as symbols, the above examples go too far. Who is to say that "Set new: 20" is knowable at compile time? Are we to be prevented from changing the implementation of Set class>>new:? Will this literal array tucked away in some CompiledMethod's literal frame now contain mutable objects? To those examples you thought safer, you did pick some rather fundamental messages to send - will there be somewhere a list of such "knowable" methods whose implementation will never change? At some point, I think it time to leave #() as it is and move to {} (which I happen to like) or direct construction via message sends. Cheers, Bob

1 0

Re: Sending WinSqueak Code: Dumb but Critical Question
by guzdial＠cc.gatech.edu 26 Aug '98

26 Aug '98

>You may try the attached CrLfFileStream which automatically detects the >actual line end convention of a file. To install it for permanent use >change FileStream class>>concreteStream to return CrLfFileStream rather >than StandardFileStream. > >Hope this helps, > Andreas Works great, Andreas! Thank you! My students are filing it in as a I type... 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

4 3

Re: nil or #nil?
by Tim Olson 26 Aug '98

26 Aug '98

Maurice Rabb writes: >I agree with this. I find it "least astonishing" for a literal array to >mean an array that can be built with things that are known at compiler >time. > >In my mind this should also work: >#((65+2) $A (65 asCharacter) ('aString' size) (nil isNil)) >==> #(67 $A $A 7 true) > >because everything there is knowable at compile time. The problem with this is that "knowable at compile time" is a slippery concept in Smalltalk. Is (5 class superclass superclass) known at compile time? If the compiler replaces this expression with Number, then later on when I change my image to add a super new whiz-bang class between Number and Integer, this code breaks. (1 to: 5) could possibly be evaluated at compile-time to be the Interval(1 to: 5), but what about the expression "(1 to: 5) atRandom". How does the compiler know what messages have side-effects and what messages do not? Smalltalk is so malleable that very little can be considered fixed at compile time -- that's one of its major strengths. -- tim

1 0

Porting troubles
by Georg Gollmann 26 Aug '98

26 Aug '98

As a learning experience I have tried porting Squeak to Linux/m68k (Debian 2.0beta). While the make process ran without a problem (thanks Ian!) I quickly faced a segmentation fault when running Squeak (in the incrementalGC when the lowSpaceWatcher is installed, to be precise). Inspecting the variables I found following: (gdb) print memory $22 = (unsigned char *) 0xc0151008 "À\026\030I\r\"" (gdb) print endOfMemory $11 = -1068549284 As I read it the memory has been malloced high up and all those ints that represent addresses have become negative, breaking the pointer arithmetic. So...shouldn´t all variables that hold addresses (OOPs) be declared as unsigned instead of int (or am I barking up the wrong tree) ? Georg ---- Dipl.Ing. Georg Gollmann TU-Wien, EDV-Zentrum phon:(+43-1) 58801 - 5848 fax: (+43-1) 587 42 11 mail:gollmann@edvz.tuwien.ac.at http://macos.tuwien.ac.at/Gollmann.html

3 4

Re: No subscribe
by tf11111＠snetsu.cpg.com.au 26 Aug '98

26 Aug '98

Dear Sir, Could you please take me off your list as I never asked to be put on it. I think I am the victim of a practical joke. Can you please reply and tell me that this has been done. Thank You Toni. >>At 07:02 AM 24/08/98 -0000, you wrote: >>>You have added to the subscriber list of: >>> >>> squeak(a)cs.uiuc.edu >>> >>>the following mail address: >>> >>> tf11111(a)snetsu.cpg.com.au >>> >>>By default, copies of your own submissions will be returned. >>> >>>This is an automated subscription mechanism. For your verification, a >>>transcript of the original subscription request is included below. >>> >>>If the wrong address has been subscribed and you seem to be unable to fix it >>>yourself, reply to this message now (quoting it entirely (for diagnostic >>>purposes), and of course adding any comments you see fit). >>>-- >>>>From tf11111(a)snetsu.cpg.com.au Mon Aug 24 02:02:56 1998 >>>>Received: (qmail 22416 invoked from network); 24 Aug 1998 07:02:55 -0000 >>>>Received: from a.cs.uiuc.edu (root(a)128.174.252.1) >>>> by jerry.cs.uiuc.edu with SMTP; 24 Aug 1998 07:02:55 -0000 >>>>Received: from chip.cs.uiuc.edu (chip.cs.uiuc.edu [128.174.246.79]) >>>> by a.cs.uiuc.edu (8.9.1/8.9.1) with ESMTP id CAA04742 >>>> for <squeak-request(a)cs.uiuc.edu>; Mon, 24 Aug 1998 02:02:54 -0500 (CDT) >>>>Received: (from www@localhost) >>>> by chip.cs.uiuc.edu (8.8.5/8.8.5) id CAA29967 >>>> for squeak-request(a)cs.uiuc.edu; Mon, 24 Aug 1998 02:02:20 -0500 (CDT) >>>>Date: Mon, 24 Aug 1998 02:02:20 -0500 (CDT) >>>>Message-Id: <199808240702.CAA29967(a)chip.cs.uiuc.edu> >>>>Reply-to: tf11111(a)snetsu.cpg.com.au >>>>From: tf11111(a)snetsu.cpg.com.au >>>>To: squeak-request(a)chip.cs.uiuc.edu >>>>Subject: subscribe >>>>X-Comments: This was automatically sent from >>http://st-www.cs.uiuc.edu/users/brant/subscribe.html >>>> >>>> >>> >> >

3 2

Re: Polymorphism without protocol dilution
by m3rabb＠stono.com 26 Aug '98

26 Aug '98

At 9:49 PM 8/25/98, Travis Griggs wrote: >Maurice Rabb wrote: > >> <snip> >> For this to work would require that I add Object>>#value which I remember >> is a no-no, because it dilutes the BlockContext protocol as Object>>#do: >> diluted the Collection protocol. We replaced Object>>#do: with #in:, so >> with what do we replace Object>>#value? >> <snip> > >Just out of curiousity and because it's late and I'm in a devil's advocate >mood... What's wrong with diluting protocols? I have vaguely seen threads >about this, but I've never really seen (or paid attention long enough), a good >reason not to dilute protocols. It's just kind of one of those unexplained >commandments (too me). I have personally thought many times that it would be >cool to totally blur the lines between collections and single objects in >Smalltalk for quite some time. Isn't that one of the things Lisp kind of does? >Why does enumeration have to be bound to a storage strategy? Travis-- Well lets review what the wise ones have said: At 7:46 AM 5/29/98, Ralph E. Johnson wrote RE: Pluggability >I looked at Actions, and liked what I saw. I've seen and done things >like that before. My main complaint is that the method should be >#value and #value:, not #evaluate and #evaluate: A block is a >built-in Action, and it already defines a protocol, so we should >use it. > >One of the interesting things is that Actions define both #value >and #evaluate. So, you can use an Action instead of a block, but >you can't use a block instead of an Action. Why? A block is just >a built-in Action. Now, the fileIn defines #evaluate and #evaluate: >for blocks, but that does not passify me! We should not proliferate >protocols, and #value and #value: are well defined and short. >They are not particular logical, but that is not so important for >the most common messages. #at:put: is not particularly logical, either. > >It is a mistake to put #evaluate and #evaluate: in Object. >ParcPlace did this with #value and #value: for awhile, and the >problem is that you lose useful information because errors don't >get caught right away but the system keeps on running for awhile >before finally noticing some error. It is so easy to convert >an object into an Action (just send #asAction to it) that you don't >need these helper methods in Object. Further, using #asAction >provides helpful information to the reader that an object is >going to be used as an action, so it gives hints that can prevent >the reader from having to keep on reading. > >BlockContext should define asAction to return self, not to make >a new action that returns itself. A block is just a built-in action. > >(I'm hoping that if I say it enough, people will believe me!) > At 4:08 PM 5/29/98, Andreas Raab continued: >> It is a mistake to put #evaluate and #evaluate: in Object. >> ParcPlace did this with #value and #value: for awhile, and the >> problem is that you lose useful information because errors don't >> get caught right away but the system keeps on running for awhile >> before finally noticing some error. > >I absolutely agree. One thing I don't like at the moment is that Object >implements #do: It's easy enough to define either asCollection or to >implement #do: in classes where this is really needed. > >> (I'm hoping that if I say it enough, people will believe me!) > >I do ;-) > > Andreas Turning to the "Way Back Machine" even further back, a _very_ wise Smalltalker wrote Re: Proposal: Object>>valueIn: At 2:44 PM 11/3/97, Travis Griggs wrote: >Ah yes, you are right. Having now thought about it, I think they should >both exist. They accomplish different things semantically. I still like the >presence of do: in Object for the purpose of "iterating" over single >objects as if they were indeed aggregations. > >-- If you think about it you could argue that this is the same argument as #valueIn: (i.e. #in: as it is now) vs. #do: The semantics of a Collection iterating over itself, and 0-1-Many iterating over itself _as_ a Collection are subtly different enough to make a separate protocol a "safe" ideal. In practice, the gurus say that it tends to hide normal Collection use errors. Likewise, the potential of not catching error of using any old Object instead of an intended BlockContext. Personally Travis, I waffle back and forth toward your position. There is a simple elegance in a unilateral #do: and a unilateral #value. --Maurice --------------------------------------------------------------------------- Maurice Rabb 773.281.6003 Stono Technologies, LLC Chicago, USA

2 1

Re: Squeak on Apple Rhapsody/Mac OS Server
by Dicky T 26 Aug '98

26 Aug '98

i don't know how i got on your list, but i wish all you geeks would quit sending me this geeky shit about some obscure computer questions. Turn the damn thing on and use it and quit trying to make love to it. >From squeak-request(a)cs.uiuc.edu Tue Aug 25 14:38:53 1998 >Received: (qmail 27303 invoked by uid 95); 25 Aug 1998 21:38:25 -0000 >Resent-Date: 25 Aug 1998 21:38:25 -0000 >Resent-Cc: recipient list not shown: ; >X-Mailer: PopOver 2.0.126b (Rhapsody; i386) >From: "Philip Mtteli" <moetteli(a)monster.citeu.unige.ch> >To: squeak(a)cs.uiuc.edu >Date: Tue, 25 Aug 1998 23:35:30 +0200 >Subject: Squeak on Apple Rhapsody/Mac OS Server >Message-Id: <9808252335.AA301557@hermes> >Resent-Message-ID: <"eupGd.A.6mG.G7y41"@jerry> >Resent-From: squeak(a)cs.uiuc.edu >Reply-To: squeak(a)cs.uiuc.edu >X-Mailing-List: <squeak(a)cs.uiuc.edu> archive/latest/3068 >X-Loop: squeak(a)cs.uiuc.edu >Precedence: list >Resent-Sender: squeak-request(a)cs.uiuc.edu > >Hi > > >Has anybody ported Squeak to Apple Rhapsody/Mac OS Server? > > >Re >Phil > > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

2 1

Re: nil or #nil?
by Tim Olson 26 Aug '98

26 Aug '98

An editorial note here: I've been using Scheme as an example of another language in which quoting works the way it currently does in Squeak. However, Scheme has conveniently avoided the main problem we are discussing, because it defines "true", "false", and "nil" as literals with unique external representations which are not symbols, i.e. #t #f '() Whereas in Squeak, true, false, and nil are reserved identifiers (not literals). -- tim

1 0

Squeak on NEXTSTEP 3.3 [0.2d14]
by Pascal Bourguignon 26 Aug '98

26 Aug '98

I've published the version 0.2d14 of the Squeak User Interface for NeXTSTEP 3.3 (it may run on OPENSTEP 4.2 too, you'll tell me) in: ftp://ftp.afaa.asso.fr/users/pascal/squeak-2.0-0.2d14.NI.bs.tar.gz (982880 bytes). It's compiled for Motorola and for Intel, and the sources are now compilable "out-of-the-box". Right now it's a NEXTSTEP source, so it won't compile on OPENSTEP systems such as Rhapsody. I should upgrade to OPENSTEP 4.2 in the next couple of months, so interested people should be able to compile it on Rhapsody soon. __Pascal Bourguignon__

1 0

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

Jump to page: