Squeak-dev November 2001

squeak-dev@lists.squeakfoundation.org

174 participants
374 discussions

[M206] how to do M206 diagrams in Squeak
by John Hinsley 11 Jan '02

11 Jan '02

Just posted for fellow M206 sufferers a short HOWTO do M206 diagrams in Squeak. "It's CRC, Jim, but not as we know it". It's at http://www.penguin-home.telinco.co.uk/M206_diagrams Does anyone happen to have the URL for Mark and Lex's CRCCardMorph to hand? Cheers John -- ****************************************************************************** Marx: "Why do Anarchists only drink herbal tea?" Proudhon: "Because all proper tea is theft." ******************************************************************************

3 5

SUnit for XML?
by Michael Rueger 08 Jan '02

08 Jan '02

Hi all, are there any (SUnit) test cases for XML out there? I used to test Yax with a bunch of test files from James Clark's test suite (http://www.squeaklet.com/Yax/xmltest.zip), but never got around to create a real test suite out of it. As far as I can tell Yax handles a lot of the semi-validating stuff (extending entities, namespaces, system and public ids and such) but this impression is more based on "anecdotal" testing ;-) A test suite would give as an objective measure of what works with which parser and would provide a list of points to work on. Oh, and benchmarks would be great, although Shakespeare (http://www.ibiblio.org/xml/examples/shakespeare/) provides nice lengthy files :-) Michael

3 3

Query: moving stuff between projects to hide from publication
by Ross Boylan 30 Dec '01

30 Dec '01

I have a project I'm working on that I intermittently publish to BSS (see the Activity project if you're curious, but it's sparsely documented). It's a priority planning tool, and I now have a fair amount of data in it. I want to publish it without the data to keep a little privacy, and also to save space. How can I do that? I figure if I temporarily move things to another project I can avoid publishing them. I have a number of morphs I'd like to move. Is there a reasonable way to move them? I looked quickly in the Project and Morph protocols, and didn't see anything obvious. Perhaps I somehow get the Project's world and put the morph in there? There is data separate from the Morphs. I've put my data in the Smalltalk dictionary, and one of my classes accesses it. Is that enough to keep it out of being published? I assume if I just left it as a class variable it would get published (since the class itself is published).

3 6

¡Ooops! A survey of OSs used by Squeakers
by John Hinsley 24 Dec '01

24 Dec '01

Kevin Fisher wrote: > > Hi John: > > Err...you've got C and D mentioned twice in your list down there! > Put me down for Linux and Windows... Well spotted, Kevin! My only excuse is brain fade caused by trying to get the latest (stable) version of Kde to compile: after a day of upgrading stuff, telling the ./configure script that yes, openssl is in the default location (!) and sitting patiently while my poor little 333 chip struggles to build its vast hugeness, I've come to the conclusion that something is terminally buggered and that I'll let SuSE sort it. The list should have read: a. Mac b. OSX c. BSD d. Linux e. Other *nix f. Acorn (hi Tim!) g. Windows h. OS2 i. PS2 Apologies. Lots of people spotted this and sent me the OS they had as well as the letter. If you didn't spot it and use something after BSD, please re-send to me off list. Cheers & more apologies (and thanks, Kevin!) John -- Reputed to be the reason Windows 2000 was nearly a year late, (paid in shares M$Ds needed the cash and kudos) Netproject's Eddie Bleasdale has renewed his challenge to virus writers. The first person to infect his Linux box wins 10,000 pounds. http://www.silicon.com/bin/bladerunner?30REQEVENT=&REQAUTH=21046&14001REQSU…

2 1

[updates] 4 more with some fixes
by Dan Ingalls 19 Dec '01

19 Dec '01

Folks - If you got the last batch, you should get these too. - Dan ----------------------- 4539furtherToFlaps-sw -- Scott Wallace -- 22 November 2001 Fixes proportional relayout of flap tabs upon resize of squeak-app window. Offers a preference that governs whether flaps along the bottom of the screen should have their positions automatically be positioned, and two other preferences relating to flaps and navigators. Hopefully users will be happy with the settings provided by default. The intent is to allow the undiluted use of the old non-flap-based navigator for those who have bonded to it, while offering a completely flap-based alternative to it." 4540FasterWakeText-di -- Dan Ingalls -- 21 November 2001 When you enter a text pane, it opens the scroll bar and highlights the text. When you leave a text pane, if closes the scroll bar and clears the highlight. However entering invalidates the entire text pane, thus causing a complete repaint. This should not be necessary... And it isn't. This changeSet fixes the problem by only repainting the selection, leading to considerably faster window and scrollbar response in textually oriented windows. 4541FlapsTweak-di -- Dan Ingalls -- 22 November 2001 Fixes RealEstateAgent>>reduceByFlaps: so it works properly -- ie it uses full width screen if all shared flaps (other than 'Painting') are along the bottom. Also includes a rewrite of Flaps sharedFlapsAlongBottom so that it is more robust with respect to future changes in the set of flaps that are shared. 4542UncollapseFix-di -- Dan Ingalls -- 22 November 2001 The recent improvement to uncollapsing of SystemWindows had the side-effect of not unlocking the panes of a window if it was collapsed when not active. This changeSet fixes that problem.

5 12

cache in a VM
by tjazul＠uni.edu 19 Dec '01

19 Dec '01

The vm I'm working with has a stack, using 16 bits to encode an integer or pointer to an object. I'm adding a cache. Addresses on the stack will now be 1/2 as small in bit size, and point to a location in cache. The cache address will then contain the integer or object pointers. The VM I'm working with now does not implement this, and I would appreciate any pointers to relevant articles. Thanks, tom

15 25

Sharp Zaurus SL-5000D Linux (Squeak?) PDA
by Mike Rutenberg 09 Dec '01

09 Dec '01

I just noticed a new PDA with a built in keyboard and might make an interesting Squeak platform. Sharp Zaurus SL-5000D is a handheld PDA that runs Linux on a 200 MHz StrongARM, and has a tiny built in QWERTY keyboard, as well as a touch screen and stylus. The keyboard looks a bit like the curved Blackberry keyboard. The screen is 1/4 VGA in size, 65,536 Color Reflective TFT touch panel, 3.5" with front lighting. (I assume front lighting because it is reflective?). It costs USD 500 for the prerelease developer version. Mike http://www.sharpplace.com/product.asp?sku=1865193

17 29

RE: An Ideal System Browser
by Peter Crowther 07 Dec '01

07 Dec '01

> From: Lex Spoon [mailto:lex@cc.gatech.edu] [...] > Overall, Multiple-Windows seems like a safer default. I agree, but maybe it should be exactly that --- a default, with navigation buttons appearing on browsers if a developer decides to change that default? A more interesting question is: what should the interface do to support *both* behaviours? For example, sometimes I know how to get where I'm going and want to navigate through several layers quickly and without retaining intermediate context (senders and implementors are typical). I'd be quite happy to shift-click to have the system present the next layer in the same window (or, for simplicity, to throw away the existing window and replace it). At other times I'm exploring, and really appreciate the ability to retain context in the windows. Just my Friday evening £0.02... - Peter

8 12

SUnit Testing merged with Examples for Methods
by Ted Kaehler 05 Dec '01

05 Dec '01

Folks, SUnits are a style of testing that verify the operation of a list of specific methods. The structure for SUnits has been in Squeak for a while, but only forty (40) out of 44,000 methods actually have a validating test. I have embarked on a radical program to improve that. Here is how I have changed things: [ ] To test a method, you needs to make up a receiver, arguments, and a known answer. Scott Wallace is introducing an "Instance Browser" to Squeak that shows you an example receiver and arguments for each method. It lets you run the example. But, where are we going to get the example receivers and arguments for a method shown in an Instance Browser? They can be the same as for a test of the method. I have written code that generates objects that can be used for *either* an SUnit test, or an example method call. [ ] Another thing that should be associated with each method is some "type information". This is the protocol that each argument object needs to respond to. The same mechanism that produces a test case can store this info also. [ ] In classic SUnits, there is a separate 'testing class' for each class in Squeak. This would double the number of classes, and is too much overhead. I have created a new subclass of TestCase that owns a Verifier. Verifier is a subclass MessageSend that holds the answer that the method is supposed to produce. Object #() MessageSend #('receiver' 'selector' 'arguments') MethodCall #('lastValue' 'methodInterface' 'timeStamp') Verifier #('desiredAnswer' 'passed') VerifierOfProperty #('theTest') I have made a subclass of TestCase that holds a Verifier. A TestSuite of these behaves like a normal test suite, and does not do too much violence to the careful design of SUnits. [ ] A Verifier can only test (a) whether a method returns the correct value and (b) whether it gets an error while running. A VerifierOfProperty tests for a specific state change after a method has run. Classic SUnits allow other kinds of assertions and tests. Except for verifying that a method produces a certain kind of error in a certain case, a series of VerifierOfProperty can test everything that a classic TestCase can. [ ] To collect the test cases, I simply enumerate the implementors of #exampleFor:, and call each one with 'all'. That returns a list of Verifiers, which are run as test cases. [ ] The SUnit code comes with a TestRunner user interface. Say TestRunner open and click on Run All. After you have my update, the TestCase called TestViaMethodCall collects and runs all tests that are created with #exampleFor:. (One drawback is that when a method has more than one test, the individual subtests are not named. We could give them names in the future.) These changes will be in the next batch of external updates. If you can't wait, ask me for the file now. I invite you to supply an example for any method by implementing #exampleFor: in some class. (In the future, we'd like to have the kind of TestCases that SUnit has now, but not have the overhead of doubling the number of classes. One way to do this is to make Metaclass do everything that TestCase does. The individual testing methods would begin with a standard prefix like 'textSU'. Any class that has a method whose name begins with 'textSU' would be found by TestRunner, and entered into its list. Any comments on this?) --Ted. -- Ted Kaehler http://www.squeakland.org/~ted/ When we were young, we were told that "everybody else is doing it" was a really stupid reason to do something. Now it's the standard reason for picking a particular software package. -- Barry Gehm

6 6

RBSqueak - what's next
by danielv＠netvision.net.il 04 Dec '01

04 Dec '01

First of all, I've seen no bug reports. Is it perfect? is it unusable? Anyway - I've been looking at the RBPort as it stands, thinking about what's needed to move it to the next state - from Beta code to something that could be folded into the base image. As an aside - Eventually putting the RB in the base image is not my call, and it's not fair to ask people to make that call before I've made the changes that are neccesary. OTOH, if they (changes review team/SqC) should pitch in with advice/guidelines, I'd be inclined to take them into consideration... Back to track. First, what we have now - The port currently has four files - * my trivial, insignificant ClassBuilder fix(?) * The RBModel changeset (including mostly new classes, and some small and not so small changes to base classes) * The RBUI changeset (including lots of empty VW classes that have either been replaced with the morphic equivalents or are simply not being used now) * and the CS3 work changeset, addin and modifying to the classes defined in the above. There are already some contributions sent on the list and to me privately that are mostly further modification of the package's classes. Stephen B. Wessels aesthetic updates are among those, but include a dependence on the variables pane (which, btw, I like, and could itself make better use of the RB...). These make it more important to clean up this package, in order to stave off chaos... As I see it, the main requirements to being able to add the RB to the main and SWT images (or for the package to stay live if it isn't) are- * Changes to base classes are minimised and separated out to changesets. Preferably, for the ones that are positive to be accepted into the image, separate each change to make it easier for the review team to decide on each. * Classes that are not being used should be discarded. This raises questions about the functionality they represent, but that's a worry for later. * New classes should be packaged as modules, that is, no class/method additions/removals, just definitions of code that's being used. I'm going through this sorting process now. What I'm discarding (with class comments/my comments)- * Navigator (plus subclasses and collaborators) Navigator is an abstract class that defines the interface that displays the classes/methods of an BrowserEnvironment. Its subclasses define what actions can be taken for the different selections. * CodeTool (plus subclasses and collaborators) CodeTool is an abstact class represents the tools that can appear when a user has selected an item (e.g., a class) using the navigator. These tools are dynamically switched depending on current selection. * OMT-Diagram (a whole category) A graphical way of viewing a class in a hierarchy diagram. CodeTool and its subclasses factor out the multiple uses and meanings of the bottom pane of the browser, splitting the functionality into separate classes. Would make it easier, for example, to add a new tool for viewing the new XML UI Spec in a hierarchy widget. It could be used to factor out showing the code in alternative ways, like SyntaxMorphs, and so forth. So this is a pretty useful concept to have, eventually, in all our browsers. Navigator allows one to isolate the state of the Browser (what are we browsing, what's selected). It's subclasses give the shape of the browser - some look at one class, or one protocol, and so forth. The different types of Environments know what navigator should be used to look at them. Right now our poor Browser and RefactoringBrowser take on all these responsibilities, making them, well, slightly obese? Another recurring theme in doing the glue code for the RB UI to call the RB model, was that this requires some additional responsibilities which the UI might not be best suited to carry. Right now the UI has to know that after doing an Extract Method,it should refresh the code pane and the messages list, and refocus on the method with the same name as before (not the same index..). Assuming someday we'll want to integrate the RB into alternative browsers like Whisker, there's no real reason why that should hard coded in yet another UI... So that's another refactoring that needs doing at some point. I'd like your thoughts on how the RB work should proceed and specifically about it's link with other Browsers... Daniel

3 2

Jump to page: