Squeak-dev June 1999

squeak-dev@lists.squeakfoundation.org

139 participants
408 discussions

Re: Obsolete classes question
by Bob Arning 09 Jun '99

09 Jun '99

On Wed, 9 Jun 1999 19:00:06 +0200 (METDST) Juan Cires Martinez <jcm(a)mat.upm.es> wrote: >I'd like to know what is the standard way of dealing with the following >situation: I renamed a class a couple of times and now methods that >used to reference it reference AnObsolete... I know I should recompile >those methods, but is there a standard way of hunting them down and >recompiling them? Juan, Smalltalk browseObsoleteReferences I didn't know this existed and the power of Squeak is evident in the ease with which I found it. There are several ways actually: 1. Select "Obsolete". Press cmd-shift-E and up pops a list of methods containing that string. 2. In a selector browser enter "obsolete" and hit return. Several selectors appear and these lead you to all you ever wanted to know about obsolete classes. Cheers, Bob

1 0

[ENH] Constraint Framework
by Stephen Pair 09 Jun '99

09 Jun '99

I've put a little constraint framework at http://www.advantive.com/squeak and attached it as well. The following is clipped from the tutorial: ------- Constraint Framework for Squeak by Stephen Pair I. Introduction This work represents something that I've desired to try for a long time. I hope that this first iteration provides the Squeak community with a useful QA utility and serves as a launching point for many new enhancements to the constraint framework. The constraint framework provides a mechanism by which a developer in Squeak can specify constraints for arguments passed into a method. As such, a new item (called 'constraints') has been added to the method menu of the browser and the context menu of the debugger. At the present, selecting this item will open a workspace that allows you to edit the constraints of the method in question. It is envisioned that a better user interface will be developed in the future. Currently, the only type of constraint that is supported is a BlockConstraint. A BlockConstraint specifies a monadic block, into which a method argument is passed, and out of which a Boolean is expected. A typical BlockConstraint might have a validation block that looks something like: [ :arg | arg isKindOf: String ] This block would check whether or not it's argument is a String. It is envisioned that additional types of constraints will be added to the framework. For example, one might want a ValueConstraint that checked whether an argument was included a set of values. Also, even more ambitious, one might create an interface (protocol) system that would test whether or not an argument supported a certain interface. Of course, all of these constraints can be expressed using a BlockConstraint, however, for the purposes of inferring relationships, BlockConstraints would be much less useful. Currently, constraints are only employed for validating method arguments. In the future, a nice enhancement would be to allow slot variables to be constrained. For now, there are two scenarios where constraints are employed. The first scenario is in the debugger. When debugging a context stack, any contexts where a constraint was violated will be shown in bold face. This is useful in correctly problems further up the stack, instead of correcting symptoms at the top of the stack. The second scenario where constraints are employed is in BlockContext>>validateConstraints. This method will step through the block of code (much as the Debugger does) and checks each context to see if it is in violation of a constraint, if it is, execution halts, allowing one to see and correct the ill mannered code. Constraints are cached in a class variable of AbstractConstraint, but actually stored as generated methods in the class in which the method appears (instance or class side). The generated methods are called #instanceMethodConstraints and #classMethodConstraints. These methods can be modified by hand as long as you following the instructions in the generated method to update the cache. This is kind of an ugly way to get method constraints saved with the sources (but it works). Also, when you delete a method, any corresponding constraints do not get removed, so you'll need to remove these by hand. To remove the demo classes from the system, evaluate the following: AbstractConstraint removeDemoCode. My hope is that this framework will help lead to higher quality software in Squeak. II. Class Overview The following new classes are provided: AbstractConstraint Abstract class for constraints BlockConstraint Constraint that support test blocks DemoPerson A class for demonstration purposes DemoAddress A class for demonstration purposes And, the following classes are modified: Behavior BlockContext Browser ContextPart Debugger MethodContext StringHolder III. Tutorial A. A simple intro to the debugger modifications A mentioned before, the debugger has been modified such that contexts which violate a methods constraints are shown in bold. To illustrate, evaluate the following expression and then enter the debugger: DemoPerson new street: 123; yourself Notice that the context 'DemoPerson>>street: is shown in bold. That is because a block constraint exists for that method which validates whether or not the argument is a kind of String. To view the constraint, select that context in the debugger, open the popup menu, and select 'constraints' (note: follow the instructions in the resulting workspace to modify the constraints...don't modify them at this point, the other demo depends on the current constraints). B. Checking for constraint violations during execution Another bug exist in our demo. To see the bug, evaluate the following and open the debugger: DemoPerson new prettyString Notice that no contexts show up in bold. That does not mean that no constraints were violated, it just means that no contexts on the stack violated their constraint. Another useful feature is evaluation while validating constraints. To illustrate, evaluate the following: [ DemoPerson new prettyString ] validateConstraints Notice that as soon as any constraint is violated, execution stops, allowing you to inspect the stack at the point where a constraint was first violated. That's it for now...have fun! - Stephen Content-Type: application/octet-stream; name="Constraints.8June538pm.cs" Content-Disposition: attachment; filename="Constraints.8June538pm.cs" Attachment converted: Anon:Constraints.8June538pm.cs (????/----) (0000AB35)

3 4

Re: Squeak for Mac
by Tim Rowledge 09 Jun '99

09 Jun '99

On Wed 09 Jun, Torsten.Bergmann(a)phaidros.com wrote: > Hi, > > I'm creating a Smalltalk CD-ROM with all test/full/non commercial > Smalltalk systems (only for educational use and to promote Smalltalk). > (see http://swiki.gsug.org:8080/GSUG.207 and > http://swiki.gsug.org:8080/GSUG.209 for a contents list) > I have included different Squeak versions for instance Win, WinCE, Unix, > > OS/2, BeOS. You weren't going to miss out Acorn I hope :-) After all, it is the standard UK school machine... What's your timetable? I haven't got around to releasing a 2.4 system yet but I can assemble one for you reasonably quickly. tim -- It said, "Insert disk #3," but only two will fit! Tim Rowledge: rowledge(a)interval.com (w) +1 (650) 842-6110 (w) tim(a)sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>

1 0

Re: Hosted Swiki
by Marc Nijdam 09 Jun '99

09 Jun '99

David Farber <dfarber(a)numenor.com> writes: > has anyone built a squeak-CGI interface? this would be incredibly > useful. Or how about mod_squeak. An Apache module that runs an image "in-memory". Marc

1 0

RE: Documentation (my last word for a while)
by agree＠carltonfields.com 09 Jun '99

09 Jun '99

> -----Original Message----- > From: MIME :eluwish@uswest.com > Sent: Tuesday, June 08, 1999 7:25 PM > To: squeak(a)cs.uiuc.edu > Subject: Re: Documentation (my last word for a while) > > > I do not want this to become something like the discussion of > "a message is just a subroutine". > Not only is Smalltalk different from everything else, but the > different way one needs to think is the essence of its > expressiveness. Delving through the corpus of code not only > suggests how to solve a given problem, it suggests new > problems to solve. > > The question is how do we best communicate this, so that our > community grows larger and more influential in the world at > large. We have a terrific opportunity, since this project is > not only at the forefront of object technology, but also of > open source. > > There are experts out there who have some answers. They have > documented why some practices may be better than others, and > have discovered some effective educational methods. I will > step back while they offer some suggestions, and as a > community we should expand on them, debate them, and come up > with a plan for a documentation project. I will help in any > way I can. I embrace these remarks completely.

1 0

RE: Documentation
by agree＠carltonfields.com 09 Jun '99

09 Jun '99

> >and the like, or worse, in a piece of straight-line > top-level code >requiring no optimization: > > > > /* Divide C by 2 */ > > c << 1; > > That's a great example of where the comment doesn't even > match what the code does! My point precisely -- the comment added little, but further provided a cognitive dissonance than made many overlook even an obvious, isolated bug.

1 0

Re: Documentation
by Ralph Johnson 09 Jun '99

09 Jun '99

My experience is that API-level documentation is not as important for Smalltalk as it is for other languages, because it is so easy to read the source. The kinds of things that need to be documented in Smalltalk are the kinds of things that you can't get easily by reading the source, such as the big picture and how to do a particular task. Part of the motivation of patterns is to be a way to describe the big picture a piece at the time, and also a way to describe how to do a particular task. However, tasks might be better described by the class "cookbook". The VisualWorks cookbook is a very good example of how to do this for Smalltalk. A wiki is a very good way to capture documentation like this. It is nice for both patterns and cookbooks to point at examples in the code. So, the swiki might eventually be enhanced to point into the codebase. But in the meantime, people can just add things as they realize they are important. A good way to start is just to answer questions as they are asked, and then to organize the answers. There seem to be a lot of questions about Morphic, so that might be a good place to start. -Ralph Johnson

3 2

More about documentation
by Pablo (Kafka) 09 Jun '99

09 Jun '99

Hi, Squeakers. I'm quite a beginner with Smalltalk and Squeak. I was at once very impressed at by the wonderfulness of these ambients; however, I must say that without the help provided by a member of this list, Leandro Caniglia, may be I could have been frustrated in my learning process because, among other things, the lack of convenient documentation. This is specially true for the Morphic interface, which, I see, plays an increasingly important role at the heart of the Squeak project. So I think that documentation is *VERY* important, not only for confused Wired readers, but for all kind of potential squeakers. But, what does the term "documentation" mean? To many of us, it remind us of a bunch of explanations added to large, confuse code. But it would be a mistake conclude that because Squeak code isn't confuse (shouldn't be, in any case) documentation isn't necessary. Moreover, I think we must redefine the very nature of documentation according to the Squeak philosophy. This was pointed out along this thread, but I think it wasn't remarked enough. What am I talking about? Let's see: 1) We have BookMorphs. The power of BookMorphs for documentation purposes is limited only by our imagination. 2) We have EventRecorders. They let us show a beginner how to accomplish a given task (e.g., working with halos). Show, not describe. There is no better method of "documenting" the basic work within the Squeak ambient. 3) We have Swikis, SqueakPages, Squeak plugins, etc. So we can make collaborative documentation work via the Internet while remaingin within the Squeak spirit (or even within the Squeak system!). Moreover, these examples show by themselves the power (and magic) of Squeak. I'm not telling that method and class comments aren't important; they are. But: Object withAllSubclasses size 1942 Morph allSelectors size 635 (Object withAllSubclasses collect: [ :each | each selectors size]) sum 7278 My 2 cents, Pablo.

1 0

Re: Hosted Swiki
by "Gran" Hultgren 09 Jun '99

09 Jun '99

---Edward P Luwish <eluwish(a)uswest.com> wrote: > I'm not sure even what to call this thing. > > I would like to have my own Swiki, but my network (and all potential > candidates for a server) only has dialup access to the internet. [SNIP] While you are looking for that ISP I can give you a time limited offer just because you are a fellow squeaker(!): 1. An account on our Linux machine where you can run your own Swiki. We are already running two Swikis there so I have all the "installation" hassles figured out. 2. VNC access and SSH access to your account. SSH gives you a secure "telnet" and VNC actually gives you a remote X desktop! We could of course run the Swikis headless but sofar I haven't bothered to - it is quite nice to be able to control the Squeak environment remotely and to be able to tweak the code while it is running! :-) 3. Let's say up to 50Mb space. We have a couple of gigs available so... No problemas. 4. Let's say 2 months? As long as your account does'nt hog the machine or anything... :-) And when you find another home it is quite easy to just tar it up and move it somewhere else! This server (195.22.65.4) is located in Sweden (but sitting on a FAT connection) so you would perhaps want to check your bandwidth - I pinged www.luwish.com from the server and it said around 200ms (not too shabby I think, I have around almost the same from my work) - email me if you are interested. regards, Gran PS. This offer is of course also available to other responsible fellow Squeakers as long as it is WELL UNDERSTOOD that it is a "no-guarantee-thingy"! The server is a "private" server that our small company use and we are not an ISP. And we can only host Z number of people where Z probably is a small prime number below 5 or something... :-) DS === Gran Hultgren, gohu(a)rocketmail.com, icq#:6136722 GSM: +46 709 472152, http://195.22.65.4 "First they ignore you. Then they laugh at you. Than they fight you. Then you win." -- Gandhi _________________________________________________________ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0

Re: Documentation
by Stephen Pope 09 Jun '99

09 Jun '99

Hello all, It might be a help to outsiders if we put the entire source of Squeak on-line in a Web-friendly format. To this end, I wrote a cheap HTML manual writer that takes a list of class categories and dumps them in rough HTML for browsing. This would let more people see what Squeak's about. For an example, see http://www.create.ucsb.edu/Siren/Siren.Reference.html. (Click on a category to go to the class list, click on a class to see its definition, hierarchy, comment, methods, etc.) The source code for this is in ftp://ftp.create.ucsb.edu/pub/Squeak/goodies/STP12/STP12/System/Utilities-h…. -- stp Stephen Travis Pope | stp(a)create.ucsb.edu | http://www.create.ucsb.edu/~stp

4 3

← Newer
1
...
32
33
34
35
36
37
38
...
41
Older →

Jump to page: