Squeak-dev November 2006

squeak-dev@lists.squeakfoundation.org

157 participants
223 discussions

[ANN] stable package universe for 3.9
by Thomas A Petersen 04 Dec '06

04 Dec '06

Lex, et. al, I regularly use Connectors 2.3-187 and Diagram Browser 25-Jul-2004 work with 3.9 7061. I have not had any trouble with them. I use them to draw database, class, state, and network diagrams for my day job. I am really greatful to have real tools that I can mold to my needs. I still think that Squeak Rocks! tap

11 28

New iCalendar version
by Yann Monclair 04 Dec '06

04 Dec '06

Hello, I have been working on my SummerTalk iCalendar project. I just put a new version online, thanks to seasidehosting.st http://icalendar.seasidehosting.st/seaside/icalendar There are some bugs, I can't figure out why the edition of the calendar works and the edition of the events doesn't. If you could play with the app and try breaking it (I hope you will not succeed, but I am being a little too optimistic I think). So far I have put only 2 user accounts, I will add account creation once I have figured out the edition bug. The accounts are : Yann Monclair (that's me :p) login: yann password: yann Arthur Dent (cf H2G2) login: arthur password: arthur You can also download the code at http://www.squeaksource.com/iCalSummerTalk.html I would appreciate any feedback, comments and tips :) Thanks in advance, Yann Monclair http://yann.monclair.fr/summertalk

3 3

Skylark Theme and Squeak 3.9
by Pavel Krivanek 04 Dec '06

04 Dec '06

Hi all, LookEnhancements have very negative impact on speed of Squeak. So I have tried to update my Skylark Theme for Squeak 3.9. It's only testing version and it's not perfect but if you want to have faster interface, try it. The test (without TTF and gradient background) with opening of 30 browsers shows that it needs about 60% of time for this operation. And it was about two times faster than Squeak 3.7 during opening of 100 empty windows. Download and here: http://www.comtalk.net/Squeak/87 -- Pavel

3 2

MinimalMorphic report
by Pavel Krivanek 03 Dec '06

03 Dec '06

Hi all, I'm slowly working on MinimalMorphic cleanup. The latest version (MinimalMorphicLoader-pk.17.mcz) has now 48 unimplemented methods. I've got an experimental image that has 24 unimplemented methods it needs some cleanup in the KernelImage code. How to build the image: 1) load http://www.comtalk.net/Squeak/uploads/98/KernelImage-MC-7067.zip 2) maximize the window evaluate code ((MCHttpRepository location: 'http://squeaksource.com/KernelImage' user: '' password: '') loadVersionFromFileNamed: 'MinimalMorphicLoader-pk.17.mcz') load. 3) evaluate MinimalMorphicLoader load You may report bugs on Mantis in project Squeak Packages, category MinimalMorpnic. In the beginning some DNUs are common because of missing last events etc. -- Pavel

3 2

[ANN] SqueakMap Package Loader new release
by Brian Rice 02 Dec '06

02 Dec '06

This release (1.1) puts together a number of small improvements to the SqueakMap package loader UI and is available now on SqueakMap. Improvements: - Installed packages and releases are now marked in bold. - Searching now also uses the description field. - All of the main features of the app are now in a visible button bar. - ToolBuilder support is used if available. This means two mostly- identical UIs, but that it will retain compatibility with Squeak versions pre-3.9. - The search bar is more obviously labeled. - Menu entries are now shorter and more readable. Known Issues: - Searching does not update the package list selection in the ToolBuilder UI. - On updating to this version, the non-ToolBuilder UI will be (re-) opened even though the ToolBuilder UI will be installed in the menu. These should be fixed in a release soon. Enjoy! -- -Brian http://briantrice.com

1 3

instance side
by Julian Daly 01 Dec '06

01 Dec '06

Hello all, Could some one explain what "instance side" means? And please keep this as basic as you can, thanks, Julian

2 3

[0.987*OT] The Problem With Programming
by Klaus D. Witzel 01 Dec '06

01 Dec '06

quote "Bjarne Stroustrup, who invented C++, explains in this interview that he still stands by the language he built, and thinks that most programming being done now is below par. While there is quality software out there, like Google, he says, "looking at the 'average' piece of code can make me cry. The structure is appalling, and the programmers clearly didn't think deeply about correctness, algorithms, data structures, or maintainability." Rather than being sure of a system's quality and why it works so well, Stroustrup says programmers are "in a constant state of grasping at straws to get our work done. The snag is we often do not know how we did it: a system just 'sort of evolved' into something minimally acceptable." In order to remedy this situation, he thinks that education must be improved, using "more-appropriate design methods, and design for flexibility and for the long haul." However, this fix is difficult to achieve because computer users do not want to be inconvenienced by abrupt changes; only a gradual, wide-ranging effort toward change will be effective. "Software developers have neutralized the astounding performance of modern computer hardware by adding layer upon layer of over-elaborate [software] abstractions," says Stroustrup, whose solution is that more experts should be trained to use C++, as it as fallen out of the mainstream, rather than simply "dumb[ing] down" programming languages. He says the generality built into C++ was the result of his "view that to do higher-level stuff, to build complete applications, you first needed to buy, build, or borrow libraries providing appropriate abstractions." Stroustrup believes that "======>" the large amount of criticism that has been aimed at C++ is a testament to how useful it really is "<======"." unquote. Bjarne Stroustrup, the inventor of the C++ programming language, defends his legacy and examines what's wrong with most software code [here:] - http://www.techreview.com/InfoTech/17831/ /Klaus

2 1

strange hash behavior
by Ralph Boland 30 Nov '06

30 Nov '06

> > Hi list, > > I just stumbled upon this: > > Object new hash 3698 > OrderedCollection new hash 183475190 > > Hashes for collections seems to be much bigger than other hashes. Is > there a reason for that? > > Cheers, > Romain > In my application this causes major problems. In the case of class Character I created two arrays on the class side of Character. The first array stored 30 bit hash values, one or for each character. The second array stores the the Xor of the first k character hash values in position k. This allows me to compute a hash value for a range of characters quickly. Using these arrays to determine hash values for characters solved my hash value problems, as least for Character class objects. Ralph

1 0

Strange hash behaviour
by Romain Robbes 30 Nov '06

30 Nov '06

Hi list, I just stumbled upon this: Object new hash 3698 OrderedCollection new hash 183475190 Hashes for collections seems to be much bigger than other hashes. Is there a reason for that? Cheers, Romain

3 2

abstract variables proposalQQ
by Ralph Boland 29 Nov '06

29 Nov '06

One of my fustrations in using Smalltalk is that I may have a subclass B with a number of subclasses, say C,D,E,F and such that some of the subclasses, say C and D, need to access an instance variable, say b, but the remainding classes, say E and F, do not need to access variable b. In this situation I have two basic options: 1) Declare variable b in class B. The problem then is space is allocated for variable b in classes D and E as well. 2) Declare variable b in classes C and D. A minor problem here is that I need to declare b for each class which uses b rather than just once. The major problem is that methods that access b must be written in each class that uses b, while if option 1) is used, the methods need be declared only in class B. (Admitted this causes the methods to be accessible by classes D and E as well which is not desirable but is usually acceptable.) I propose that Smalltalk (Squeak) allow the declaration of abstract variables as follows: A line of the form abstractInstanceVariableNames: 'b c' in the definition of the variables of the class B would declare b (and c) as abstract instance variables. (The same approach would be applied for class variables.) No space is allocated for variable b so instances of B could not access them. Nevertheless it would then be possible to write methods of class B that accessed variable b. Let M be method of B that accesses b (but not c). Alas, instances of B cannot use method M since M is an abstract method. (Abstract methods are methods that access abstract instance variables) Now, in subclasses of B, it is allowable to define instance variable b. Once this is done method M becomes accessible to the instances of the subclasses of B for which b has been declared. For example if classes C and D declare instance variable b while classes E and F do not then instances of classes C and D can use method M but instances of classes E and F cannot use method M. In terms of implementation it should be noted that the byte codes for M are not connected to class B but instead two copies of the byte codes for M are created with one placed with class C and the other placed with class D. The bad side of this is obviously the duplication of code. This is no worse than Option 2) however, and is in fact better since only one copy of the source is created. Option 1) remains in circumstances where it is warranted. It is noteworthy, also, that access to method M is faster than with Option 1) because less searching of the inheritance chain is needed to find M. This presents a problem: Users wanting fast access to a method N of B that is not abstract by subclasses of B could artificially make N abstract by having it access b as in 'true ifFalse: [b <- b].'. This is ugly of course. What is needed is a way to define a method, say Q, of B as abstract even though it does not access any abstract variables. Subclasses of B that want to access Q would need to state that they want a concrete versions of Q installed in their list of methods. One approach would be to write the method Q in these subclasses as: 'Q super Q' In order to make it clear that a method is abstract I think the abstract variables of the method would need to be made more visible such as by making them bold or red or both. Clearly I haven't worked out all of the syntax needed for my proposal but it seems not so difficult. More difficult of course is the determining the ramifications of implementing this proposal. I am interested in hearing comments on whether this proposal is good or bad and why. I would also like to have pointed out some of the more significant ramifications of implementing this proposal. Thanks for listening. Ralph

5 4

Jump to page: