Packages August 2005

packages@lists.squeakfoundation.org

8 participants
7 discussions

Starting new squeaksource image at sqf.org
by Doug Way 31 Aug '05

31 Aug '05

I tried starting my new squeaksource image (based on Bert's config) at sqf.org last night. It mostly worked, except there was an odd problem with the mcz file names in the projects. Instead of listing Balloon-md.3.mcz etc under the Filename column, it listed the commit-log description of the .mcz file in place of that. This caused filename-based retrieval to not work. I'm guessing this is an incompatibility in the data.obj (repository) file format between Bert's config and the original SS image that Avi setup... maybe an additional inst var is in there or something. I re-created the problem on my local machine by copying the data.obj from sqf.org, also. Anyway, for now I just switched sqf.org back to the old SS image to keep it running as it was. I played around with it some more on my machine, and I think what I will do is just start over with a new data.obj repository. I'll set up the new data.obj with 3 superadmins (me, Marcus and Avi), and the three re-created empty projects. (Everyone else will need to re-add their login, and then Marcus or I can add them as developers to projects.) I found there is a handy SSFileSystem>>recoverAllLostVersions method which will repopulate all of the .mcz files saved in the project directories, back into the data.obj repository. So we shouldn't lose any of the mcz versions. I'll run that once when I start it up, and we should be back where we were before, except for the users to be added. I'll give this a try this evening... don't want to keep people waiting on this any longer. (If something goes wrong, I'll just switch back to the old SS image for now again, but I think this should work.) Once this is set up, then we'll be able to set up the real update stream again. - Doug

3 4

How do we handle bootstraps under the MCConfiguration technology?
by Daniel Vainsencher 29 Aug '05

29 Aug '05

As often happens, the Traits upgrade requires a process, it is not sufficient to just load the post-Traits versions of the the image packages. What it will require, is for the image being upgraded, to load a specific sequence of versions, which slowly and safely bring it into the desired state. Exactly the same thing is required for other things, such as fixing the awful performance bug in Set+Behavior that causes a Set with 7000 classes to use almost exclusively linear search. This would require loading a version of the scanFor: that tries two different ways to use the hash, preferring the more efficient one, but tolerating the old one (that all Sets happen to be using at the moment), then doing rehash on all Sets, then dumping the old hashing code. So this is a general problem. Does the current update stream mechanism allow us to give the user a sequence of MCConfigs, instead of just the one config that has the appropriate delta? Daniel

2 1

restarting source.squeakfoundation.org ?
by Marcus Denker 27 Aug '05

27 Aug '05

Hi, It seems that source.squeakfoundation.org is down.. how can I restart it? Marcus

6 5

source.squeakfoundation.org down?
by Marcus Denker 17 Aug '05

17 Aug '05

I can not access source.squeakfoundation.org...

2 1

Upate 6680
by Marcus Denker 16 Aug '05

16 Aug '05

Hi, At ESUG's Camp Smalltalk we did an experiment with the loading the map via a changeset. We did: - make changeset (6679PachMC) that patches the MC Configurations to not load patches, but complete version (until the fixed squeaksource version is installed). - then we made a monticello configuration with the then current packages, put that into 6680Release-md changset. If you load updates, the packages will be loaded according to the map defined. Very nice. Two problems: 1) Afterwards,opening MCConfig Browser we get an empty configurarion. I would have thought that we want this to show the loaded config... 2) The update 6679 makes monticello believe that we have edited code, that will bring monticello to ask us to confirm that loading the package is ok. I think we should release a 6680 3.9a image, this way people can test it. And we have something to replace the old 3.9a that is used a lot by people (the one that is older then 3.8...) Marcus

5 5

3.9: Numbering?
by Marcus Denker 15 Aug '05

15 Aug '05

Hi, With 3.9 we now can not use the update number as a sub-numbering (e.g. 3.9updateXYZ). So it might be interesting to come up with a different way of numbering at least some snap-shots along the way to 3.9 final... 1) For putting out pre-loaded images. I think this is a god thing to have, as it makes testing easiert for people, thus growing the number of testers 2) As tags for "stable" points, so people can say "it worked in 3.9.15". The question is if we adopt the Linux Way of numbering: 3.8 is stable, 3.9 is unstable, both have minor revisions (3.8.1, 3.9.1), with 3.9 then be renamed 3.10 as soon as we decide to do a stabler release. What do you think? I would like to release a 3.9alpha image soon, so that people can test the changes that we added over the last week. There was a huge bag-log of small fixes on mantis. Marcus

4 8

Packaging the programming tools
by Andreas Raab 02 Aug '05

02 Aug '05

Folks - I've been working on detangling the current tool set from the rest of the system since I wanted to be able to replace the current tool set with something more appropriate for Tweak. It turns out that with a little restructuring of responsibilities this isn't all that hard and so I'm happy to announce the probably only Squeak image in the world which has no programming tools whatsoever (!): http://www.impara.de/~andreas/iSqueak/3.8/NoTools.zip [6.3MB] If you grab this image you will find that you won't be able to open a browser, a change sorter, workspace etc. not even a debugger[*1] simply because none of these tools are present. [*1] Try browsing the sender of some message or a class - you will very quickly notice why I don't like the usage of "AppRegistry default" since it raises completely needless errors when for example trying to browse a class -- compare this with the notifier you get when trying to browse a selector which uses ToolSet's interpretation of "proper" AppRegistry behavior. However, since this is not very interesting, you can just load the standard tools package from http://www.impara.de/~andreas/iSqueak/3.8/Tools-ar.17.mcz [450k] install and use it. And when you're tired of it, simply unload it from Monticello[*]. Needless to say, the tools package does not leave any obsolete classes or undeclared references behind, it comes and goes cleanly. [*] After unloading execute the code in the left hand panel - it turns out that #unload is not executed when unloading packages from Monticello (we *really* need to fix this!) probably because the #unload method is removed before the class. But wait, there is more! Since the current tools package is somewhat messy and depends directly on Morphic and MVC I decided to build an alternative which exclusively depends on ToolBuilder. It's called the "PlusTools" (all the names have a "Plus" in the name, e.g., FileListPlus, TestRunnerPlus, ClassBrowserPlus, DebuggerPlus...) and loadable from: http://www.impara.de/~andreas/iSqueak/3.8/PlusTools-ar.16.mcz [300k] And of course, you can load and unload both tool sets at the same time if you'd like to. Note that the point of this exercise is not only to be able to replace the tools for Tweak - it is equally to show that a Squeak system can easily come without *any* specific tool support, squeakmap, even monticello (I only left MC in the image because you'd have to load it anyway to get to the tool sets) just as long as you have a way of loading code (e.g., compiler and change management). Therefore there is really no need whatsoever to put all of the programming tools into a "basic" Squeak image. And finally, the PlusTools should be helpful for further detangling work as they depend on ToolBuilder and not on Morphic or MVC (there might still be a few remnants but that's easily fixable). For those of you interested, here are the major changes that I did to make the above possible: * Refactoring of ChangeSet and ChangeSorter - all of the actual change set related stuff had to be moved out of ChangeSorter and ChangeSet itself had to be moved over to the System package and out of Tools. * Moving of the breakpoint, tallying, file contents browser (diff etc) out of the Tools (right now all of these are in System) * Introduced FileServiceRegistry to avoid abuse of FileList * Introduced ToolSet AppRegistry to support various tool sets I also had to do some significant shuffling around between packages to get everything in order and (un-)loadable but most of these changes were non-invasive. If you are interested the full repository is also available at: http://www.impara.de/~andreas/iSqueak/3.8/NoToolsRepository.zip [32MB] and contains a few more (already unloaded) packages and fixes going back to the original 3.8 versions from SqF.org. Cheers, - Andreas

4 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Packages August 2005