Squeak-dev May 2004

squeak-dev@lists.squeakfoundation.org

152 participants
288 discussions

The Magic Book - a design draft
by goran.hultgren＠bluefish.se 30 Jun '04

30 Jun '04

The idea of a "Magic Book" inside Squeak acting as both an introductory documentation for Squeak and as a reference manual is quite intriguing. A few basic ideas that got this started: - Tying unit tests to documentation in order to detect stale documentation - Not bloating the image - Easily maintain the book cooperatively (like swiki) Ok, what would be the STTCPW? (For all you non XP aware: "Simplest Thing That Could Possibly Work"). By applying reuse - what do we already have? We already have: - Projects: A very good format for "active content". I am not sure how easily they are backwardscompatible though. Could anyone post some insight in that matter? - StarBrowser: A universal UI kindof thing. We could easily let StarBrowser be the main UI of the Magic Book! It lends itself easily for the task - a treeview on the left, a dynamic area to the left etc. If we somehow find a good way to integrate a little search form then it would be quite perfect. - SqueakMap: In whichever form we choose to have the Chapters of the book (Projects) we could register them on SM (a few new categories would be nice) and thus get a distributed always up to date model of chapters for free. And when SM1.1 gets completed it will track versions of the chapters for us, etc. And in SM1.1 it will have a sensible smart diskcache for the packages (read Chapters) so we get that too. - Free text engine: Scott Crosby wrote a neat little engine for maintaining keyword indices that the book obviously should use. I have also been intending to integrate that into SM. We should be able to add it to SM in such a way that the Magic Book can simple get that "for free". So... we already have a bunch of cool technology to implement the Magic Book IMHO. We just need to knit it all together in a smart way. If we split the book in the following pieces: 1. The TOC. This is essentially a list of chapters organized in a hierarchy with names and a link to the corresponding SM package that is the chapter content - a Project. 2. The chapters themselves. These are simply Projects published as packages on SM. Perhaps we need to follow a few conventions for these Projects so that we easily can "jump into" them in a proper manner, extract keywords for indices etc. 3. The search indices and the index (as books have last). If 1 and 2 above also are packages on SM (in whichever suitable form, doesn't matter) it will be even more simplified. So the book *contents* are then managed as packages on SM. We get the possibility of having different owners for different chapters, release/version tracking etc. It is obvious when you think about it - why shouldn't they be packages? The StarBrowser is the obvious choice of a UI - it already has navigation mechanisms and it can also show contents from the book along with other things in a highly dynamic fashion. Why reinvent that? And SqueakMap gives us a lot of stuff like efficiently always updated content, a smart cache etc. And there will be no image bloat whatsoever. Well, ok, what do you all think? Darn, this sounds like real fun... I need to get cranking at my SM1.1 ... :-) regards, Göran

2 1

[ENH] reposted: new String modifier: String>>asPlural
by David T. Lewis 30 Jun '04

30 Jun '04

This is a nice little enhancement by Chris Norton that helps Squeak to speak gooder English. It was timed out on the BFAV list, so I am posting with a different subject line. The attached change set is the original one, and works fine in a 3.7 image. Here is the original message posted by Chris in January 2000: > Hi Folks. > > Here's the preamble from my changeset: > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "OK. You could say that this is a silly crusade, but I like my Squeak > messages to be in proper English (at least when the language you're using is > English). > > I was messing around with the HangMan file-in and I got a walkback that had > the following title: 'Error: HangManPhrases classs are not indexable'. I > just couldn't stand the extra 's' on 'class', so I created a nifty new > String method called asPlural and I modified the sender of the odd string to > use the new String modifier. Take it or leave it, but I think this makes > auto-generated text just a little easier to read." > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > I hope you find this new String modifier useful too. > > Cheers! > > ---==> Chris >

11 17

[ENH][FIX] StringMorphFromTextFix-nk
by ned＠squeakland.org 25 Jun '04

25 Jun '04

"Change Set: StringMorphFromTextFix-nk Date: 26 February 2004 Author: Ned Konz Does these things: - lets StringMorph absorb text color, font size, and font style from Text instances passed to #contents: (in addition to emphasis). - makes Text>>asMorph return an unwrapped TextMorph instead of a StringMorph. - adds asStringMorph and asTextMorph for when you want to be more specific about what you get. " <This post brought to you by BFAV2>

2 1

[FIX] decompFixes-ls
by Lex Spoon 25 Jun '04

25 Jun '04

from preamble: "Change Set: decompFixes-ls Date: 30 January 2004 Author: Lex Spoon Fixes the decompiler bug posted by Ned Konz on 11 February 2003. The issue is that if the last case in a case statement returns from the method, the decompiler gets confused trying to parse the otherwise: branch. This changeset has the decompiler track all non-return exits from the case statement, so that it has enough information to do a right thing. The changeset also adds a couple of methods that the decompiler is relying on. After loading this changeset, Ned's example decompiles correctly. Also, decompiling and recompiling everything leaves a running system. The test is included for future use as [Decompiler recompileAllTest]. s0: evt evt caseOf: { [ #Entry ] -> [ self log: 's0-ENTRY;'. ^nil ]. [ #Exit ] -> [ self log: 's0-EXIT;'. ^nil ]. [ #Init ] -> [ self log: 's0-INIT;'. self initProtected: #s1:. ^nil ]. [ #e ] -> [ self log: 's0-E;'. self tran: #s211:. ^nil ]. } otherwise: [ ^#top: ]"!

2 1

[FIX] RefStrmObsolCls-tk
by ducasse＠iam.unibe.ch 25 Jun '04

25 Jun '04

"Change Set: RefStrmObsolCls-tk Date: 19 September 2003 Author: Ted Kaehler V2: stef: Changed Smalltalk by SystemNavigation default at the right place please check. It is really too late. SmartReferenceStrm is in charge of converting reading in old .pr files and taking care of instances of classes that have changed shape. It also handles obsolete classes. It gives the user a chance to name a new class that old instances will be converted to. In 2000 Bob Arning made major changes, but these were never extended to converting the instances of obsolete classes. This changeSet fixes that."

1 1

[OT] Insight on distributed computing wanted
by Martin Drautzburg 16 Jun '04

16 Jun '04

I've been pondering over the question: "information is no much easier to transport than material objects, so why is distributed computing so difficult". It is haunting me. I wrote down some thoughts and I'd be happy to receive some pointers or feedback. I am only posting it here, because I know there are some thoughtful people on this list. * THE OBJECT AND ITS WORLD Moving an object from one place to another means to detach it from its original world and attach it to a new world. As Einstein would say: you can always see the object as motionless and the world around it as moving. This means that there has to be a well-defined boundary between the object and its world. This is "obvious" for material objects (quantum physics ignored) but non obvious for Smalltalk objects. Objects ultimatively reference their worlds. A Canvas object eventually references my graphics card, my monitor and the eyes and the brain of me, the user. None of these objects can be transported easily, so the boundary between a Canvas object and its world is definitely above the graphics card. The graphics card and all other material objects are "immobile". Maybe even the Canvas object itself is immobile. In any case there are mobile and immobile Objects. When the world of an object is replaced the object needs to attach itself to a new world. If the object should expose a "similar" behaviour in the new world, then the two worlds must be reasonably alike. The same is true for material objects. * RPC AND PROXIES You can use objects from a distance by remote-controlling them. In that case, the objects itself does not move, but it sends and receives objects. A TV remote control sends IR pulses to the the remote object (the TV set) and the TV set sends light to the spectator. Both the IR pulses and the light are objects that are known to be very mobile. This is why this works. In an RPC scenario you typically send simple objects (integers, strings) across the wire. Again these kind of objects usually behave well when their worlds change as long as they do not reference their world. A string ":0" meaning my DISPLAY can be sent easily but it actually has a reference to my monitor. Sending such an object will sometimes work (it will reference the DISPLAY of the receiver) and sometimes not. If you however send more interesting objects like Canvases across the wire, then things aren't that simple anymore. * HIDING INFORMATION You typically don't want to expose too much information. An object on the sender side may "know more" than is relevant for the receiver. Likewise the object on the receiver side may know more about the receiver than is relevant for the sender. This means that objects have to "mutate". They can be in one of three states: - objects attached to the sender's world - object detached - object attachted to the receiver's world The detached object carries a minimal common subset of the information that is present in the attached objects.

2 1

Re: [ANN] Chuck type inferencer
by Lex Spoon 08 Jun '04

08 Jun '04

Here are two short repliees condensed into one, to try and save a bit of mailing list traffic. Peter van Rooijen <peter(a)vanrooijen.com> wrote: > Of course I'm curious how Chuck got its name :-). > Mostly, it is just a humble name a la Smalltalk itself. Also, though, it works by "chucking" ideas at a wall and seeing what sticks. > I have just a suggestion : could this AutoChuck feature be turned > on only on certain packages, such as Kernel and not Morphic for example > ? > This could spare some time and quit a bit of space ... > I'm working on the space requirements, but wanted to go ahead and post the system as is for the diehards. Memory usage is not the only area that is lacking I'm afraid! The major memory requirement, it turns out, is that AutoChuck is keeping around parse trees for every method. So I'm trying to eithre get rid of that requirement or make the parse trees take less memory. The particular idea of caching part of the system seems difficult to implement. If you ask what the type of Morph>>width is, it will end up tracing into methods in Rectangle, which will in turn trace into methods in the numeric hierarchy. So what parts do you *really* need if you just want to analyze morphic stuff? It's hard to tell. Romain Robbes <rrobbes(a)info.unicaen.fr> wrote: > A while ago I started (I mean, played 3 hours ;-)) a little program to > store type > information which could then be used by several tools, such as a type > inferencer, > an the toy I was doing, which was collecting run-time types, so they > could "collaborate". This could then be used by a code completion > system, > or various navigation systems (how about clicking on a variable and > being > automagically teleported to it's class ?). Oh yes, this is a great tool too, and it complements what Chuck does. Chuck examines the program and gives you an upper bound on what the types might ever be; your tool examines executions and thus finds a *lower* bound on the types. Your tool is, I'm sure, consistently fast; on the other hand, Chuck will find a good many answers even in code that has yet to be executed. This is nice if you have not yet figured out how to run the code you are studying! Also, upper bounds on the types have different applications in downstream tools such as compilers and dead code removers; a lower bound can inform the compiler that a case is worth optimizing (e.g. this method really does get run with FloatArray's), and an upper bound can let the compiler *avoid* dealing with certain cases (e.g., this message send can only ever invoke one particular method, so inline it). Lex

10 23

Macintosh VM plugin building
by Joshua 'Schwa' Gargus 07 Jun '04

07 Jun '04

Hello, I'm running into some trouble with building VMs on MacOS (v10.3.4, XCode 1.1) I successfully followed the instructions in the sourceforge platforms/ directory to build a vanilla VM, but ran into difficulties building both internal and external plugins. I tried external plugins first, but quickly found myself over my head; I'm a new Mac developer and don't yet grok Bundles and such. Seeking an easier way to get my feet wet, I decided to build Andrew Greenberg's RePlugin as an internal plugin. I loaded the package from SqueakMap, added RePlugin to the list of internal plugins in VMMaker, and followed the VM building instructions as before. The VM successfully built, but didn't include the plugin, as verified via 'Smalltalk listBuiltinModules'. I figured that this was because the XCode project file didn't include the appropriate files in the build target. So, I added the files to the project manually. Specifically, I added them to the 'Squeak VM Opt' target. The VM built OK, but again didn't include the plugin. I have a few questions: Do I have to manually adjust the XCode project settings each time I change the VMMaker configuration? If so, how should I do this? Do people always use XCode to build MacOS vms? What about command line tools? What are the benefits of using the MacOS vs. the unix branch of the Sourceforge code? Is there any documentation about building external plugins on MacOS? Thanks, Joshua

2 4

[BUG][FIX] LargeIntegersPluginBugfix1-3
by Stephan Rudlof 05 Jun '04

05 Jun '04

"Change Set: LargeIntegersPluginBugfix1-3 Date: 28 May 2004 Author: Stephan Rudlof Requires: LargeIntegersPlugin v1.2 This changeset incrementally *upgrades* the LargeIntegers plugin to v1.3: v1.3 - fix: >>primDigitDiv:negative: now checks if its Integer args are normalized; without this change the plugin crashes, if a division by zero through a non normalized - filled with zero bytes - arg occurs. This can happen through printing by the inspector windows after changing the bytes of a LargeInteger manually. Furthermore I've added some tests. This fix should go quickly into the update stream." -- Stephan Rudlof (sr(a)evolgo.de) "Genius doesn't work on an assembly line basis. You can't simply say, 'Today I will be brilliant.'" -- Kirk, "The Ultimate Computer", stardate 4731.3

2 2

[BUG][FIX] PostscriptCharacterScanner DNU #setAlignment:
by Richard Staehli 04 Jun '04

04 Jun '04

This bug has been around a while, but I just discovered the workaround someone posted on the swiki. The problem can be reproduced simply: - in 3.6 image, open a new StackMorph - add a TextMorph to the first page - set text alignment to centered - from the Stack's red "menu" halo button, select "copy & print" -> "print Postscript to file" and accept defaults. - a walkback appears: "PostscriptCharacterScanner doesNotUnderstand: #setAlignment:?" This problem can be fixed by the suggestion posted on the swiki's "Postscript support" page. The fix is to modify the class 'PostscriptCharacterScanner' to be a subclass of 'CharacterScanner' and remove from the former the instance variable 'font'. I do not know if this fix causes other problems. Here is the change to PostscriptCharacterScanner: CharacterScanner subclass: #PostscriptCharacterScanner instanceVariableNames: 'canvas paragraph bounds curPos foregroundColor emphasis ' classVariableNames: '' poolDictionaries: '' category: 'Morphic-Postscript Canvases'

3 3

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

Jump to page: