Squeak-dev November 2004

squeak-dev@lists.squeakfoundation.org

164 participants
373 discussions

XML parser and friends no documented at all....;(
by stéphane ducasse 14 Dec '04

14 Dec '04

hi all As usual no comment and no example for the XML-Parser classes. Does someone has some tests/examples for this package? Because I never output xml.... XMLDOMParser addressBookXMLWithDTD leads to an error. I think it is the time for this wonderful community to wake up....We need at least comments and example which can be done using tests. Stef

3 2

Embedded Image
by Noury Bouraqadi 09 Dec '04

09 Dec '04

Hi, I tried to embed an image into an executable (with the VM) under winXP, but I encountred two problems: -The first (simple) one is that it rejects the original VM with '.exe' extent. So, I had to rename it... -The most important problem is that I could not run the resulting executable. Any hint? Thanks -- Noury ------------------------------------------ Dr. Noury Bouraqadi - Enseignant/Chercheur Ecole des Mines de Douai - Dept. G.I.P http://csl.ensm-douai.fr/noury European Smalltalk Users Group Board http://www.esug.org Squeak: an Open Source Smalltalk http://www.squeak.org ------------------------------------------

9 10

Refactoring Associations
by Andrew P. Black 08 Dec '04

08 Dec '04

I've been engaged (in my spare time) for about a year in refactoring associations so that they and their subclasses work a bit more rationally. And I almost have a change set that works! The tricky bit was to get a change set that files in. This I now have, but it took a lot of hand work, because there are various checks to make sure that Association is NOT recompiled. OK, so it files in. And most things seem to work. But the WeakIdentityKeyDictionary "ObsoleteSubclasses" (a class variable of Behavior) is messed up after the file in. It should, I think, hold a mapping between "Association" (that is, the class) and an array of its now obsolete subclasses #(WeakKeyAssocation). It actually holds a mapping between a weak "#(Association)" and that array. Very strange. I think that it's my fault. WeakKeyAssociations used to be implemented by putting a weak one-element array in the key slot of an association. With my refactoring, they are now implemented by using the weak slot of a new subclass, HalfWeakAssociation, for the key and the strong slot for the value, which means that the relative positions of the slots have been switched. Now, here is my question. Does something in the VM or the GC know about WeakKeyAssociations? That is, does something (think) that it knows about this hidden one-element array. Is that how the one element array is appearing in ObsoleteSubclasses? I've done the obvious stuff: the only value that Behavior uses as a key in ObsoleteSubclasses is "self". If it is not something in the VM or GC magic, I can't see where this broken key is coming from. I'm attaching my changeset, and my tests for Association. (This requires the dictionary = fix that I just mailed out.) Inspect ObsoleteSubclasses before and after you file AssociationRefact.Hand in. Andrew

4 4

[BUG][FIX] two methods in MultiCharacter search a class in the metaclass hierarchy
by Boris Gaertner 07 Dec '04

07 Dec '04

This bug report is for Squeak 3.8 gamma latest update: #6485 First of all my apologies for the difficult subject title. The matter itself is quite simple. In MultiCharacter>>asUnicode we read: asUnicode | table charset v | charset _ EncodedCharSet charsetAt: self leadingChar. " ==> " (charset isKindOf: Unicode class) ifTrue: [^ self charCode]. table _ charset ucsTable. table isNil ifTrue: [^ 16rFFFD]. v _ table at: self charCode + 1. v = -1 ifTrue: [^ 16rFFFD]. ^ v. EncodedCharSet>>charSetAt: answers a class. Unicode is also a class, to find out whether charset is located in the class tree that starts with Unicode, we have to write: (charset isKindOf: Unicdoe) The added 'class' is badly wrong; it takes us into the metaclass hierarchy where the check answers false. Same for MultiCharacter>>asUnicodeChar. Greetings, Boris

3 8

[FIX][KCP] KCP-0112-FixCanUnderstand
by n.schaerli＠gmx.net 06 Dec '04

06 Dec '04

from preamble: "Change Set: KCP-0112-FixCanUnderstand Date: 12 December 2003 Author: Nathanael Schaerli Fixes canUnderstand so that it deals with abstract methods (i.e., subclassResponsibility and shouldNotImplement) in the right way."!

12 17

[UPDATES] 3.8 gamma and 1 update
by Michael Rueger 03 Dec '04

03 Dec '04

Hi all, 3.8 has now been moved to gamma and one more fix. If there are fixes out there that are still missing or urgent bugs that you think should be fixed before final, now is the time to speak up. Michael ------------ Change Set: startUp-bf Date: 23 November 2004 Author: Bert Freudenberg Fix auto start if more than one launcher is active

7 11

A version of 3.9alpha with full changeset history
by Marcus Denker 02 Dec '04

02 Dec '04

Hi, I made a version of 3.9alpha that was updated from the last "full history" version of 3.8alpha. http://www.iam.unibe.ch/~denker/temp/Squeak3.9a-6474h.zip This is very helpfull for checking older changesets for conflicts. Marcus

2 1

[UPDATES] 10 more for 3.8 (and 3.9)
by Marcus Denker 02 Dec '04

02 Dec '04

Some more fixes/tests for 3.8. The same changesets are in 3.9, too. 6476asMutatorEnh-st -- Samuel Tardieu -- 22 November 2004 It is common to use the expression (aSymbol, '':'') asSymbol to build the setter from a getter message. For example, Seaside uses it internally for building callbacks. This changeset adds the #asMutator message to the Symbol class. Test included. 6477ttcFix -- Yoshiki Ohshima -- 22 November 2004 Add Symbol font support to the later versions that uses Unicode. Since the characters in the Symbol font now has legitimated character code point, we should use them." 6478StringMorphEditorSelectionFix-nk -- Ned Konz -- 22 November 2004 Ensures that you can select just after the last character in a TextMorph that is set to autoFit with autoWrap off (that is, with no space to the right of the last character). v2 avoids selecting to the right of a CR at the end of a text line. v3 adds same fixes to MultiCharacterBlockScanner. 6479FileCttBrowsServicesFix-md -- Marcus Denker -- 23 November 2004 When trying to open the meny (for ''get'' to read a big file) with Filelist2, there was a walkback because FileContentsBrowser did not implement #services" 6480AtomMorphEnh-tbn -- Torsten Bergmann -- 25 November 2004 This adds a class comment and an example to AtomMorph. It also fixes the broken AtomMorphTest which failed due to the missing class comment." 6481NumberParsingTest-dtl -- David T. Lewis -- 24 November 2004 Test cases for numbers parsed from strings or streams. This test case is a companion to ScaledDecimalTest, which has already been added to the Squeak 3.9 release stream. These tests demonstrate three failures in the current 3.9 image. See NumberReadFromFixes-2-dtl for patches that correct these failures as well as those demonstrated by ScaledDecimalTest." 6482NumberReadFromFixes-2-dtl -- David T. Lewis -- 24 November 2004 These changes correct several problems with parsing of numbers from strings and streams. The problems are demonstrated by NumberParsingTest and ScaledDecimalTest (provided in separate change sets; the latter is already included in the Squeak 3.9 image). The original bug report was for the following problem, which is corrected by this change set: ''1.40s2'' asNumber => 1.39s2 This change set replaces NumberReadFromFixes-dtl, which introduced a serious bug that prevented recompilation of the system. 6483BecomeSelfImagefix -- tim(a)sumeru.stanford.edu -- 2 November 2004 Companion to BecomeSelfVMfix to trap the error of a become: a correctly" 6484haltIf-Fix-md -- Marcus Denker -- 24 November 2004 small refactoring for Object>>haltIf:" 6485MSecFix-ar -- Andreas Raab -- 25 November 2004 Time>>millisecondsToRun: can - if executed across image saves - result in a negative number. This fixes it to answer a very large number by replacing the simple subtraction with Time>>millisecondsSince: wich compensates for overflow."

2 1

Re: FIX: Making Set/Dictionary etc. loops more robust
by Richard A. O'Keefe 02 Dec '04

02 Dec '04

"Joshua Scholar" <jscholar(a)access4less.net> wrote: Changes Set>>do: from do: aBlock tally = 0 ifTrue: [^ self]. 1 to: array size do: [:index | | each | (each _ array at: index) ifNotNil: [aBlock value: each]] to do: aBlock tally = 0 ifTrue: [^ self]. array do: [:each | each ifNotNil: [aBlock value: each]]. There's one fairly major problem with Set>>do: which this change does nothing about: the fact that iterating over a Set of n elements is not O(n). This seems rather like polishing the brass on the Titanic. The difference is that adding to a Set or Dictionary can put a new rehashed hashed hash table into "array" Yes, but it has always been strictly forbidden to make any kind of change to a Set or Dictionary while iterating over it. There are a number of ways to deal with this: - Java actually maintains a change count and Set/Dictionary iterators watch out for changes, so If You Do Bad Things You Get Told - AWK (at least the 'mawk' implementation with which I'm familiar) actually goes to the trouble of making a copy of the key set of an array when you do 'for (key in array) ...' so If You Do Bad Things It Works Like You Should Have Expected'. - Smalltalk has traditionally gone a little bit crazy; If You Do Bad Things You Get What's Coming To You And Why Didn't You Read The Sources? - Verification tools like ESC/M3, ESC/Java, SPARK, and so on verify at 'compile' time that You Didn't Do Anything Bad You Good Little Programmer You (it's just not what the customer wanted). In the original version, if any block inside of a "do:" or any of the many loops that depend on "do:" called code that added to that Set then there was a chance the set would grow and rehash - and some element would be visited more than once and some not at all. Indeed. Break the contract and you lose your rights. The way it is with this change, adding to a Set in a loop adds an element that might not be visited, and deleting an element doesn't necessarily mean the element won't be visited but the meltdown scenario can't happen. Add an element to a Set, and the following things can happen: (1) The element is already present; nothing bad happens. (2) The element is not already present and there is room in the array; (2a) the new element is inserted after the current iteration point=> it will be seen (2b) the new element is inserted before the current iteration point=> it will not be seen. We are already in Very Bad News territory. It's darned near impossible to give this a coherent abstract semantics. A "live view" should ensure that when you finish the loop you have seen _everything_ that is still in the set. The proposed change does not ensure that. A "snapshot" should ensure that when you finish the loop you have seen all and only the things that _were_ in the set at the start; the proposed change does not ensure that either. (3) The element is not already present and there is not enough room left (as defined by #fullCheck) The old code will switch over to the new array, but not scan all of it. The new code will continue scanning the old array, so will not see the addition or any other changes. This is at least as much of a "meltdown" as what the old code did, and is arguably worse, in that it will hold onto a dead data structure that ought to be GC-meat. Remove an element from a Set, and the following things can happen: (1) The element is already absent; nothing bad happens. (2) The element is present. It's replaced by nil, then #fixCollisionsFrom: is called. This can make fairly large scale rearrangements of the array. As far as I can see, this can results in elements being missed or seen twice, WHICHEVER of the #do: versions is used. In short, the only effective change is that the new Set>>do: will, in some rare circumstances, visit more elements because it is scanning the wrong array. I don't really understand why this is useful, when we STILL have the problem that additions may or may not be seen and removals can STILL scramble a #do:. And of course the new version is at least as fast as the old one. I benchmarked it, and the new code is slower. s := (1 to: 60000) asSet. [s do: [:each |]] timeToRun => 42 msec (old version) [s do2: [:each |]] timeToRun => 63 msec (new version) These times with Squeak 3.6-5429-full, MacOS 10.3.3 on a 1GHz G4 PPC.

11 26

DB-oreinted application
by Blake 01 Dec '04

01 Dec '04

OK, Squeakers, I'm in a situation where I can see myself being poised to suggest a language tool for an upcoming iteration of a retail product. It's a ways off, but it is, I think, inevitable. We are currently using an Access-like tool to develop the application, which has around 200 different tables and screens. It also has many variants. From a design standpoint, it cries out for object-orientation, but of course, we have bupkus as far as genuine OO tools at hand. I'm considering suggesting Squeak (or any Smalltalk) as the platform but there are a few issues, some more easily resolvable than others. I'd like to hear some ideas on this: -> The lure of the Access-like tools is the fact that any moron can design a table or set and then create a form or grid based on said table. Forms generally need a lot of massaging and re-formatting so they're not a huge deal, but I've seen no grids. Having built a few grids in my day I'm not keen on building more. -> We'll have at least 4-5 people working on the same application. One of the nightmares of the current environment is that it was not designed for collaborative work. (I confess also that STers disdain for files is not one I understand. Working in an image makes some things very convenient and other things very inconvenient.) I've read a lot of caveats regarding Monticello and I'm not quite sure how well it would work. Anyone with experience here? How will Croquet factor in, given that it's all about collaboration? (I can see certain elements of Croquet being very useful for working out bugs and brainstorming, but I don't know about source control.) -> Right now the bosses are concerned with the fact that the app doesn't look like a "normal Windows app" that people are used to. I'm aware of the problems and solutions to this in Squeak, but I also suspect this will be a non-issue shortly. MS seems to have abandoned Win32. -> The web-based squeak stuff--not Seaside, but the plug-in--makes it appear as though any squeak application can be put on the web with a flick of a switch (I suppose especially if the data storage is handled correctly). I am somewhat concerned about interoperability between Squeak and .NET/J2EE Thoughts? Thank you, kind folk, in advance. ===Blake===

6 8

Jump to page: