Packages October 2005

packages@lists.squeakfoundation.org

10 participants
16 discussions

problem loading Kernel-CdG.45 in 6695
by stéphane ducasse 31 Oct '05

31 Oct '05

Hi I started to integrate the changes of Cees for ToolPlus. Now I have the following problem - take a 6695 - open the squeakfoundation/inbox - merge Kernel-CdG.45.mcz The system gets blocked on reloading.... I do not know what reloading is but I can't do anything. Cees did you try to load your changes in an image? Did you get the same problem? Stef

1 0

I integrating the ToolPlus...
by stéphane ducasse 31 Oct '05

31 Oct '05

hi guys I'm trying to integrate the ToolPlus of Cees. What should I do with the changes made by cees to graphics, Balloon, Compression, Files Will you pay attention to them, or should I go ahead and then you merge after. Stef

1 0

Strange behavior
by stéphane ducasse 28 Oct '05

28 Oct '05

Hi all I have encountered a really strange problem. With adrian we took the same image 6693 - loaded the same scripts (I did the scripts to update the image) I always ended up with conflicts. He never :) I did that removing all the packages in the package cache, adrian too. I tried a lot of tests and I cannot understand. Next week I will do a controlled experience with adrian next week. Marcus took the same scripts and succeeded :) argh..... I really do not understand. I do not see why this is different. I will try to see if the difference come from the vm but we are all on mac. Now I understand why I was saying that I get errors and that avi and adrian could not see it. Does any of you experienced somehting like that? Stef

1 1

Re: Upgrade scripts?
by Andreas Raab 26 Oct '05

26 Oct '05

Nope, it does not work. Try it for yourself - Point MC to http://source.squeakfoundation.org/Graphics and try: * loading GraphicsCheckpointTest-ar.3.mcz will correctly complain (this is what *should* happen) * loading Graphics-ar.22.mcz will just hose your machine (this is what *does* happen) If you load things in the correct order, first Graphics-ar.21.mcz *and then* Graphics-ar.22.mcz everything shows up fine - including the (now loaded) dependency of GraphicsCheckpoint-1-ar.4.mcz. Any ideas? Could this be related to the new "simu-load" feature? Cheers, - Andreas Cees De Groot wrote: > On 10/25/05, Andreas Raab <andreas.raab(a)gmx.de> wrote: > >>and the question here is simply: Is there *any* way of achieving this? > > > Make the dangerous version depend on a DangerousSituationChecker > package and have a DangerousSituationChecker class>>initialize that > does the check? > >

6 12

Re: Upgrade scripts?
by Andreas Raab 25 Oct '05

25 Oct '05

That's an idea. Thanks - I'll try it. Cheers, - Andreas Cees De Groot wrote: > On 10/25/05, Andreas Raab <andreas.raab(a)gmx.de> wrote: > >>and the question here is simply: Is there *any* way of achieving this? > > > Make the dangerous version depend on a DangerousSituationChecker > package and have a DangerousSituationChecker class>>initialize that > does the check? > >

1 0

Upgrade scripts?
by Andreas Raab 25 Oct '05

25 Oct '05

Hi Folks - I'm making a few changes which are potentially *really* dangerous if you don't load them in the right (incremental) order and I would like to be able to add a script which allows me to test whether a (compatible) version of prerequisite changes are installed. This would be a trivial script, something like: (Foo canUnderstand: #bar) ifFalse:[ self error: 'You must first load Foo-bar.42.mcz'. ]. and the question here is simply: Is there *any* way of achieving this? I'd be fine, for example, with a preamble script if that were executed even during upgrades but I don't think they do. Any other ideas? All I want to make sure is to not just crash the system because a poor user inadvertantly loads the "latest version" of package X. Note that this may also be an "internal" dependency, e.g., in order to be able to upgrade to version Y of some package you must at least have version X installed. I'm mentioning this merely to point out that the available dependency mechanism cannot handle this (since you cannot have a package to depend on itself, ey? :-) Cheers, - Andreas

1 0

strange....
by stéphane ducasse 23 Oct '05

23 Oct '05

I'm doing a lot of tests by trying to reload the packages using the scripts that worked before and from the same image and I get always conflicts. I will report more when I will get more advanced investigation with adrian. Stef

3 4

Does not work.
by stéphane ducasse 21 Oct '05

21 Oct '05

I do not understand why the scripts do not work.I redrew them from the stream and I'm checking. When I load them manually from I get a new image and when I do

1 0

about flushing the caches of MC
by stéphane ducasse 21 Oct '05

21 Oct '05

Hi I have been pushing in the stream a new update (since marcus believe that this is important that we can build the image from the stream). Now the two cs just load the patched MC and load the script loader and execute the script. Apparently there is a bug and the caches are not flushed so we end up in an image that is 30 Mb. So Avi or daniel can you have a look? I will continue to harvest since we can build from 6693 without problem now. Of course, any improvement in MC is welcome - why Object>>isRectangle was not installed before the insetBy: method (you can try to load script7 alone). Stef

1 0

Updated packages list for 3.9a?
by Cees De Groot 19 Oct '05

19 Oct '05

Hi, I noticed that http://minnow.cc.gatech.edu/squeak/5641 has a list that's both a bit outdated and a bit hard to find (being in a large page with lots of other info). I therefore split the page, and reworked the list into a table. http://minnow.cc.gatech.edu/squeak/5774 I'll also spend a bit of time comparing the table with current 3.9a work - lots of renaming is taking place, and it is probably a good idea to assign maintainership on 3.9a name basis, not? Hth - I had some spare time on my hands, Cees

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Packages October 2005