Packages September 2005

packages@lists.squeakfoundation.org

9 participants
12 discussions

MC working for managing the image
by stéphane ducasse 05 Oct '05

05 Oct '05

Hi all ok I created a ScriptLoader package which contains scripts.... and now each time I push something in 39 I update the script and test that I can load everything from the latest ***essential image*** = that could not be created with MC. This way we can accumulate changes and from time to time publish a new image. Script 1, 2, 3 loaded perfectly (modulo the merge making packages dirty) from 6693 + 274 MC So I will continue like that. Stef

4 6

source.squeakfoundation.org moved to box2, new look and cleanup
by Doug Way 29 Sep '05

29 Sep '05

Hi all. Ken & I worked this weekend and moved the squeaksource server (hosting the 3.9a code) from Cees' private machine over to box2. This should be a better setup in terms of more admins having access to maintain/restart the squeaksource image when necessary. While I was at it, I spiffed up the squeaksource image, so that it has a unique banner and color scheme, to distinguish it from the original squeaksource server at Berne. I also cleaned up the references to Impara leftover from Bert's code. Check it out at: http://source.squeakfoundation.org I also created a "SqueakSource-SqF" project there, which contains the complete SqueakSource package configuration running on that machine. I added some basic instructions on how to set up a working SqueakSource image on the Wiki page for the project. (These are the only instructions on how to set up SqueakSource that I know of.) Since the old setup was still running on Cees' machine, Ken & I decided to keep it there as a squeaksource test server, with its own domain name. You can use this site if you need to mess around testing something with squeaksource. (Yes, it has its own color scheme too...) That one is here: http://sourcetest.squeakfoundation.org - Doug

2 2

More load ordering for MC?
by Daniel Vainsencher 29 Sep '05

29 Sep '05

Hi everyone. While creating a bootstrap for Traits and 3.9a, I have with the following problem: Traits change the way methods are added. To do this, it adds some methods, lets say addMethod: and basicAddMethod: where the former calls the latter. Problem: when MC loads the former before loading the latter, it is then not able to load the latter, because method loading is now broken. (Such an image is a pretty frustrating place to find ones self, since doits are methods) So I can probably solve my little problem by loading a sequence of MC versions which slowly add things in the right order. OTOH, this could "just work" if the methods happened to load in the correct order. Of course the "right order" does not always exist, for example mutually recursive methods. Of course when it exists, it can often not be found (since we generally have no idea what method a message send resolves to). OTOH, most of the time the order doesn't matter that much. On the gripping hand (for me at least), when the load order does matter, it creates a lot of pain, and it seems like a simple heuristic would solve most such problems. So - how do people here feel about MC ordering method additions topologically, so that A>>sel1 comes no sooner than B>>sel2 if A>>sel1 sends the selector sel2, at least when such an order exists? Daniel

2 1

Re: confused by rest local rest remote
by Daniel Vainsencher 28 Sep '05

28 Sep '05

Ok, good to know this works for someone other than Avi and I... About the dialog: Actually, MCConfiguration>>upgrade shows the way. The relevant piece is: [ver merge] on: MCMergeResolutionRequest do: [:request | request merger conflicts isEmpty ifTrue: [request resume: true] ifFalse: [request pass]] We want ver to be the merger, instead of the version. So I started to change MCConfigs to use a combination of the script and this element, but I went down a wrong path somewhere in there, don't think its worth continuing from. Daniel Marcus Denker wrote: > > Am 27.09.2005 um 11:06 schrieb Avi Bryant: > >> >> On Sep 27, 2005, at 12:36 AM, stéphane ducasse wrote: >> >>> >>> I think that this is normal that you did not got any problem anymore >>> since everything was already loaded in the image I sent you. >>> Now take a 93 image and load the script you did or load the script I >>> did with all the packages (not only the modified ones) and you >>> should get conflicts as I did (normally you will obtain the same >>> image that the one I provided to you and this one report conflicts). >>> >> >> Nope. It worked just fine for me. Maybe it only works on this side >> of the Pacific. >> >> Here's what I did: >> >> - Start with the Squeak3.9a-6693.image >> - Load Monticello-avi.274.mcz >> - Run the script below >> >> Then wait a really long time, hit Merge, wait a really long time >> again... and you're done. >> > > Yes, worked for me, too. > > The new packages are marked dirty, I think this is related to the fact > that they don't have > the 39a repository defined (they only have the local cache). So we need > to somehow > fix that. > > How do we proceed? If we put a cs with Avi's code out into the update > stream, the > users would need to press the "merge" button. The question is if we > want that... > > Marcus > >

4 7

confused by rest local rest remote
by stéphane ducasse 26 Sep '05

26 Sep '05

I think that I will need some help because I start to get really not making progress at all. I took 93 loaded morphic splitter saved all the new packages took again a 93 run the script I gto an ancestor not found, copy it to my local cache then I got a lot of conflicts. now when SketchMorph subclass: #FatBitsPaint instanceVariableNames: 'formToEdit magnification brush brushSize brushColor lastMouse currentTools currentSelectionMorph selectionAnchor backgroundColor' classVariableNames: 'FormClipboard' poolDictionaries: '' category: 'MorphicExtras-AdditionalWidgets' @@in red@@ category: 'Morphic-Widgets' now if I press rest local or rest remote I get the same !!!! ie the changes are not taken into account SketchMorph subclass: #FatBitsPaint instanceVariableNames: 'formToEdit magnification brush brushSize brushColor lastMouse currentTools currentSelectionMorph selectionAnchor backgroundColor' classVariableNames: 'FormClipboard' poolDictionaries: '' category: 'Morphic-Widgets' So let us say it.... I spent the last three days trying and for now I stop. Stef | vm names | names _ '38Deprecated-sd.2.mcz 39Deprecated-sd.2.mcz Balloon-stephaneducasse.8.mcz BalloonMMFlash-stephaneducasse.1.mcz Collections-stephaneducasse.30.mcz CollectionsTests-md.8.mcz Compiler-stephaneducasse.13.mcz Compression-md.2.mcz EToys-stephaneducasse.1.mcz Exceptions-md.3.mcz FFI-tbn.3.mcz Files-stephaneducasse.9.mcz FlexibleVocabularies-stephaneducasse.1.mcz Graphics-stephaneducasse.14.mcz GraphicsTests-md.3.mcz Kernel-stephaneducasse.35.mcz KernelTests-md.9.mcz Morphic-stephaneducasse.48.mcz MorphicExtras-stephaneducasse.1.mcz MorphicTests-stephaneducasse.5.mcz Movies-stephaneducasse.2.mcz Multilingual-stephaneducasse.7.mcz Nebraska-stephaneducasse.3.mcz Network-stephaneducasse.18.mcz NetworkTests-md.7.mcz PackageInfo-md.3.mcz PreferenceBrowser-hpt.27.mcz Protocols-stephaneducasse.5.mcz SMBase-stephaneducasse.70.mcz SMLoader-md.26.mcz ST80-stephaneducasse.20.mcz SUnit-md.26.mcz SmaCC-md.5.mcz Sound-stephaneducasse.3.mcz Speech-stephaneducasse.4.mcz StarSqueak-stephaneducasse.3.mcz System-stephaneducasse.44.mcz ToolBuilder-Kernel-ar.13.mcz ToolBuilder-MVC-ar.8.mcz ToolBuilder-Morphic-md.15.mcz ToolBuilder-SUnit-ar.9.mcz Tools-stephaneducasse.33.mcz VersionNumber-dew.1.mcz ' findTokens: ' ', String cr. vm _ MCVersionMerger new. names do: [:fn | vm addVersion: (MCCacheRepository default loadVersionFromFileNamed: fn)]. vm merge

2 4

About MC for managing the image
by stéphane ducasse 22 Sep '05

22 Sep '05

Hi today I realized (I was idiot or totally into my envy/store practices) that we cannot manage the image like we do for an application with MC (or we do not understand anything) or Envy/Store. Here are the notes I took when going step by step over a releasing a new image with marcus. I guess that it summarises somehow our questions and problems. We (with marcus) are trying to understand how we can improve the way we harvest and produce new images with the new process. Now we are a bit stuck because I harvested too much. I always naively thought that we could take 3.8 and load only the latest version + some changes that where done via cs. But this is not possible for all the stuff - (1) that can only be done via cs, - (2) that one package may rely on another one that may rely on the other. (here I want to understand how MC can help see below) So if I understand correctly this means that to arrive to version x, we have to load all the configs (hence the MC deltas to speed up the process) until we load version x. I guess that this is the set up done at impara to manage iSqueak and Tweak. Bert is it correct? Now this means that this is really tedious to have to - define - validate - a load order for all the packages - publish a new cs on the update stream - publish a new image The implications with this setup is that we have to produce often an image (validate a configuration of changes working together) and this can be quite painful. At least they are a lot of try and error when there are a lot of dependencies between packages. Bert what is the process that you have? Do you have something like getMeTheLatestConfiguration that worked from MC (I guess that what you have is the cs script that are in the update stream and scripts a working configuration) Do you have automated scripts? We have problems to really understand the MCConfigurationBrowser Can we programmatically filled up the MCConfigurationBrowser? For the second problem (2) above Avi do you know if creating a package named Squeak with all the subpackages as required would help minimizing the manual conflicts resolution. I thought that MC was supporting an atomic load so I would like to use that as much as possible. Bert I have the impression that using package dependencies with a root package (ie havgin Squeak and all the image package as required) would help to minimize inter package dependencies, now why do you use your script (the explicit list of packages) instead of required package. Is it because you can push that in the update stream? What I like with required packages is that we version a configuration and the atomic load (if I was not dreaming) Now with the scripts at the end of the process we have an image and in the cs the configurations. Am'I correct? Stef and marcus

6 32

It does not work... :(
by stéphane ducasse 19 Sep '05

19 Sep '05

so apparently loading the squeak package once the morphic splitters cs is merged does not work.... It goes stuck in cleaning code. So now I really do not know what to do. So I guess that I will throw away Morphic splitters and redo all the harvesting I did. Stef

2 1

source.sqf.org down...
by Daniel Vainsencher 19 Sep '05

19 Sep '05

In a very dramatic moment in testing new configurations... :-) Cees (or other access able people), can you bring that back up? BTW, so what do we know about why SqS is so unstable? Daniel

2 2

Proposed Workflow
by Daniel Vainsencher 19 Sep '05

19 Sep '05

So from a quick look at MCConfigBrowser, I gather that Impara uses it to define, enlarge, and occasionally tweak the load order of the packages in its configuration. Do you guys have one overall configuration, or multiple disjoint configurations, or some other combination? I'm thinking about the desired workflow. So when someone wants to submit a change that crosses package boundaries, we want them to upload the relevant package versions somewhere public, then create a configuration (using MCC browser) including only those relevant packages versions (*), then upload the configuration to a public repository, maybe the inbox one. Then anyone wanting to integrate that change (for example, Harvesters) should be able to: 1. Load that configuration into his image, 2. Copy just the versions in the configuration into his repository (to add them to what people get implicitly when upgrading from that repository), and 3. Add the configuration as an update, to make it an explicit upgrade. This would handle the case where two or more configurations are sent as a bootstrap. Should at this point the configuration be expanded to include all the current versions of relevant packages? I'm not sure. Does this sound like a sane way to manage an image? Daniel (*) another option is for them to create a configuration including many other packages, but that seems to require remembering what packages are parts of what distributions, which seems wrong to me...

1 0

About blessing level for package versions?
by stéphane ducasse 10 Sep '05

10 Sep '05

Hi avi do you have any plans to add kind of blessing level to the package versions? Today I pushed a buggy changes on 3.9a and I do not know how to remove it and it take me ages to do anything. Around one hour for at the end just remove three files from a folder. But blessing levels could be better for other communication purposes. Stef

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Packages September 2005