Squeak-dev August 2008

squeak-dev@lists.squeakfoundation.org

103 participants
139 discussions

[ANN] MC Converter 1.1.31
by Colin Putney 15 Sep '08

15 Sep '08

Hi all, MC Converter is a simple utility for converting MC 1.x repositories into MC 2.0 repositories. It's the tool I used to take MC 2.0 self hosting, and I've successfully used it to convert some large-ish projects like OmniBrowser. With all the versions of MC 1.x floating around out there, however, I do expect that there will be some issues and incompatibilities. If you do run into problems converting repositories, please let me know so I can help sort them out. Download it from here: http://www.wiresong.ca/static/releases/MCConverter-current.st To convert a repository, do the following: - build an image that contains both your preferred version of MC 1.x and MC 2.0 - create directory repository containing all the MC1 versions you want to convert - file in MCConverter - write a conversion script - see MDIncrementalConverter>>convertMC2 for an example - run the script to convert the repository - open the new repository in an MC2 repository browser to examine the results Colin

2 2

[ANN] Monticello 2.0.20
by Colin Putney 13 Sep '08

13 Sep '08

Hi all, Monticello 2.0.20 is now available for download. From the release notes: 2.0.20 - Improved the window title on repository browsers. 2.0.19 - The parsing of method timestamps now handles older formats from earlier versions of Squeak. 2.0.18 - Snapshot fileout now includes method timestamps. Thanks for the bug reports! Colin

11 28

Fwd: Problem with fonts on Linux with compositing activated
by laurent laffont 11 Sep '08

11 Sep '08

Hi, I've switched to KDE4 and played with composite rendering. With last squeak dev images some fonts are not rendered: it seems to be interpreted as a transparent region by the composite manager (see screenshot). I've tested this on my two debian boxes. This problem is not present in sq3.9.1-7075dev08.07.1 image, so I suppose it's due to NiceFont integration ? Regards, -- Laurent Laffont -- Laurent Laffont <l.laffont(a)temis-france.com> TEMIS 48, Avenue Jean Jaurès 74800 La Roche sur Foron Tél. : 04 50 97 49 91 Fax : 04 50 97 49 94 http://www.temis-france.com

7 14

3.10 is done
by Ralph Johnson 08 Sep '08

08 Sep '08

3.10 is done. It has been stable for a long time, and Edgar was just waiting for me to write a welcome screen. I've done that, so he can make a final image. The thing that we did that I like the best is making Package Universe prominent. While not perfect, it has worked well. The thing that disappoints me the most is that there are still a few tests that are not green. It looks like a committee has formed to work on the next release, and I wish them the best. I want to thank Edgar for all the hard work he did on 3.10. He did almost all the work, and did an excellent job. -Ralph Johnson

4 4

Making a better Compiler for all
by Igor Stasenko 08 Sep '08

08 Sep '08

Hello folks, during my visit at ESUG i had a conversation with Stephane, about different things, one of them is to make a better and cleaner compiler implementation. Current compiler code contains a lot of hacks and to be fair, is not a best example of good smalltalk code. What i'm proposing, is to establish a comittee for designing a better smalltalk compiler , which will replace old one on all existing Squeak forks. I think comittee should collect & discuss all feature requests, which new compiler should have, and then we can implement it and include in every and all forks. It is also, IMO, would be a good to make compiler modular - put it as separate package and maintain it as separate fork-independent entity. This will ensure that all existing forks in future will use the same compiler as the rest. Which will make people's life much easier :) I hope with support of atomic loading (btw a new compiler is a good test-bed for atomic loading) we should be able to load it at will :) -- Best regards, Igor Stasenko AKA sig.

10 22

Using class indexes instead of reference in oop header (in COG)
by Igor Stasenko 07 Sep '08

07 Sep '08

Hi all, I wanted to ask Eliot about some details how he planning to use new object format in Cog. I think it may be interesting to others, so i posted it here. At ESUG, Eliot mentioned that new object format will be 64 bit (regadless of platform), and he will use a class indexes (pointing to entry in a global classes table) in header instead of direct class oop. Currently, in Squeak VM same principle is used for so-called compact classes, where in oop header is stored an index of compact classes array entry, which allowing to have a smallest possible oop header (32 bits). So, in Cog, to determine an oop class, first it reads an index from its header, and then reads a class oop from classes global table. But you need a reverse operation as well - translating class oop into index. Every time you doing #basicNew , or #primitiveChangeClass , you need to determine a class index by its oop value. So, the question is how this will be done? Also, some classes may die, and obviously VM needs to do a compaction of global classes table at some point, to prevent maintaining a big table where only few of entries is used. Suppose i created 1000+1 classes => each class gets own index in table. Then first 1000 classes is gone (when user uninstalling something). Now you having 1000 free entries in table. But last one is still in use, and if you want to make table more compact it would require to visit each instance of that class and set a new index value. -- Best regards, Igor Stasenko AKA sig.

4 3

BabyUML has reached its goal
by Trygve Reenskaug 06 Sep '08

06 Sep '08

The goal of the BabyUML project was to bridge the chasm between the code we write at compile time and the networks of communicating objects that do the work at runtime. The BabyIDE interactive development environment bridges this chasm . Its foundation is the new DCI paradigm, its key stone is a variant of the Traits stateless methods. Read the report and download the programs. You find all about it in the BabyIDE home page http://heim.ifi.uio.no/~trygver/themes/babyide/babyide-index.html <http://heim.ifi.uio.no/%7Etrygver/themes/babyide/babyide-index.html> Enjoy yourself while I'm relaxing in the mountains for the next seven days. --Trygve -- Trygve Reenskaug mailto: trygver(a)ifi.uio.no Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver N-0378 Oslo Tel: (+47) 22 49 57 27 Norway

9 15

Number readFrom: can we remove some "accidental" features
by nicolas cellier 02 Sep '08

02 Sep '08

Strangely, Squeak Number class>>#readfrom: used to accept non Smalltalk syntax like: (Number readFrom: '.2') -> 0.2 . (Number readFrom: '2.e3') -> 2000.0 . (See http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-April/103137.ht…) Don't know if accidental or on purpose, but to me, this is wrong and I did not implement this behavior in SqNumberParser because there is no such official Smalltalk syntax to my knowledge. Up to any one to accept an alternate number syntax by subclassing SqNumberParser. Now I see that Dave Lewis (dtl) asserted this feature: testAsNumberWithSuperfluousDecimalPoint | sd | sd _ '123.s2' asNumber. self assert: ScaledDecimal == sd class. self assert: sd scale == 2. self assert: '123.00s2' = sd printString. I'd like to remove this feature. Is it ok?

10 13

SqNumberParser refactoring
by nicolas cellier 01 Sep '08

01 Sep '08

SqNumberParser speed up has been introduced a little prematurely in 3.10.1 image. I uploaded correction for a detail at http://bugs.squeak.org/view.php?id=6976 Now all the tests parsing gradual underflow Float should pass again (round to the nearest Float as was the case before the speed up). That's quite some time i spent correcting my own bugs with this SqNumberParser! - http://bugs.squeak.org/view.php?id=6976 speed up (harvested in 3.10.1) introduced the bug described above - http://bugs.squeak.org/view.php?id=6982 (not harvested) had a typo - http://bugs.squeak.org/view.php?id=3512 (harvested in 3.9) introduced a bug in ScaledDecimal parsing (see http://bugs.squeak.org/view.php?id=7169) - http://bugs.squeak.org/view.php?id=6779 (in minor fix unstable 3.10) duplicated this bug in another method so did http://bugs.squeak.org/view.php?id=6982 Sorry for inconvenience (don't think any user but me bumped into these problems however, given that Number readFrom: is far worse w.r.t. nearest Float, and is still the official Number reader in the image). Sorry for flooding maintainers too (I think the impact is bigger). Looking at my own code i saw code duplications, not enough comment, typos in comments. Some will find that using inst var to save some of the parser state is tricky, but that's another subject (Scanner and parser do the same). This is the cost of efficiency. And that's why comments are necessary. Anyway, i refactored a bit, cleaned duplications, added comments, and added more speed again for LargeInteger using same kind of divide and conquer trick as http://bugs.squeak.org/view.php?id=6887 (more in another post) All my tests are green. Now, i have a problem for publishing in mantis. Since the refactoring does interfere with a lot of already published patches some harvested, some not, some on the way to be harvested, It might create some problems for harvesters (load order of Installer mantis ensureFix:). I like the small change sets for they can be adopted independantly in several distributions, but there Monticello might be more appropriated. What do you suggest?

7 12

Bytecode not in sync with source?
by nicolas cellier 31 Aug '08

31 Aug '08

While debugging FloatTest>>#testNaNCompare (From http://bugs.squeak.org/view.php?id=6719 FloatNaNCompare-M6719-Test.2.cs), I had a very strange behavior: Executing in Debugger: theNaN := Float nan. anotherNaN := Float infinity - Float infinity. comparand := {1. 2.3. Float infinity. 2/3. 1.25s2. 2 raisedTo: 50}. comparand := comparand , (comparand collect: [:e | e negated]). comparand := comparand , {theNaN. anotherNaN}. I ended up with a comparand filled with some nils. The problem vanished when I did recompile. Unfortunately I saved the image before I had the idea to inspect the Bytecode and then could not reproduce the problem. I suspect it is related to http://bugs.squeak.org/view.php?id=6720 . Does anyone experiment this kind of problem? Nicolas

2 2

Jump to page: