VM Maker: VMMaker-oscog-dtl.63.mcz

> Dave Lewis uploaded a new version of VMMaker to project VM Maker:
> http://www.squeaksource.com/VMMaker/VMMaker-oscog-dtl.63.mcz
>
> ==================== Summary ====================
>
> Name: VMMaker-oscog-dtl.63
> Author: dtl
> Time: 20 April 2011, 10:18:02 am
> UUID: c1d30608-304c-52b7-20ca-32f7a46c1508
> Ancestors: VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61
>
> Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61

>
> Actual ancestry:
>  VMMaker-oscog-EstebanLorenzano.62
>  VMMaker-oscog-dtl.61
>  VMMaker-oscog-dtl.60
>  VMMaker-oscog-dtl.59
>
> Changes included here are from:
>
> Name: VMMaker-oscog-dtl.61
> A second batch of updates from VMM trunk, primarily cosmetic but also
> a class comment update and a couple of methods that had not previously
> been pragmatized in oscog.
>
> Name: VMMaker-oscog-dtl.60
> These changes are methods from the main VMM branch for which <#var:#type:>
> declarations have been formatted with proper spacing. By updating these
> in the oscog branch, all of these methods are identical in both branches.
> All changes are cosmetic (no functional changes to the methods).

>
> On Thu, Apr 21, 2011 at 04:59:26AM +0000, [hidden email] wrote:
>> Dave Lewis uploaded a new version of VMMaker to project VM Maker:
>> http://www.squeaksource.com/VMMaker/VMMaker-oscog-dtl.63.mcz
>>
>> ==================== Summary ====================
>>
>> Name: VMMaker-oscog-dtl.63
>> Author: dtl
>> Time: 20 April 2011, 10:18:02 am
>> UUID: c1d30608-304c-52b7-20ca-32f7a46c1508
>> Ancestors: VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61
>>
>> Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61
> and VMMaker-oscog-dtl.60 were saved without correct ancestry.
>>
>> Actual ancestry:
>> VMMaker-oscog-EstebanLorenzano.62
>> VMMaker-oscog-dtl.61
>> VMMaker-oscog-dtl.60
>> VMMaker-oscog-dtl.59
>>
>> Changes included here are from:
>>
>> Name: VMMaker-oscog-dtl.61
>> A second batch of updates from VMM trunk, primarily cosmetic but also
>> a class comment update and a couple of methods that had not previously
>> been pragmatized in oscog.
>>
>> Name: VMMaker-oscog-dtl.60
>> These changes are methods from the main VMM branch for which <#var:#type:>
>> declarations have been formatted with proper spacing. By updating these
>> in the oscog branch, all of these methods are identical in both branches.
>> All changes are cosmetic (no functional changes to the methods).
>
> I give up. I cannot commit oscog updates to SqueakSource because
> SqueakSource fails on the update every time (after a *long* wait for
> the upload). So I save locally and copy to SqueakSource, and just end
> up with a mess. The VMMaker-oscog-dtl.63 update was my attempt to
> fix the problems from the failed updates yesterday, which seems to
> have resulted in yet another broken update (failure on upload, no
> ancestor history showing in the archive now).

> I somehow managed to save VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60
> yesterday without ancestor history, which in turn leaves today's new
> upload VMMaker-oscog-EstebanLorenzano.62 without ancestor history.
> Tonight I saved a new version VMMaker-oscog-dtl.63 that is identical
> to VMMaker-oscog-EstebanLorenzano.62, but with the ancestor version
> history restored. But now the new update VMMaker-oscog-dtl.63 on
> SqueakSource shows no ancestor history, although is does show the
> ancestor history on my local archive.
>
> My apologies. I don't know how I broke this and I don't know how to
> fix it, but I'm out of time and out of patience so this will have to
> do for now.

>
> On 21.04.2011, at 06:17, David T. Lewis wrote:
> >
> > I give up. I cannot commit oscog updates to SqueakSource because
> > SqueakSource fails on the update every time (after a *long* wait for
> > the upload). So I save locally and copy to SqueakSource, and just end
> > up with a mess. The VMMaker-oscog-dtl.63 update was my attempt to
> > fix the problems from the failed updates yesterday, which seems to
> > have resulted in yet another broken update (failure on upload, no
> > ancestor history showing in the archive now).
>
> MC first saves to the local package cache. It pops up the tiny blue
> version window. If anything goes wrong with the upload, you should use
> that window's "copy" button to try again.

>
> > I somehow managed to save VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60
> > yesterday without ancestor history, which in turn leaves today's new
> > upload VMMaker-oscog-EstebanLorenzano.62 without ancestor history.
> > Tonight I saved a new version VMMaker-oscog-dtl.63 that is identical
> > to VMMaker-oscog-EstebanLorenzano.62, but with the ancestor version
> > history restored. But now the new update VMMaker-oscog-dtl.63 on
> > SqueakSource shows no ancestor history, although is does show the
> > ancestor history on my local archive.
> >
> > My apologies. I don't know how I broke this and I don't know how to
> > fix it, but I'm out of time and out of patience so this will have to
> > do for now.
>
> This is what the "adopt" button is for. To fix up the ancestry, delete
> your working copy (do not unload it), then adopt the real ancestor
> from the list of versions in the repository. Click "changes" to see
> if that worked and makes sense. Then save.
>

>
> On Thu, Apr 21, 2011 at 04:59:26AM +0000, [hidden email] wrote:
>> Dave Lewis uploaded a new version of VMMaker to project VM Maker:
>> http://www.squeaksource.com/VMMaker/VMMaker-oscog-dtl.63.mcz
>>
>> ==================== Summary ====================
>>
>> Name: VMMaker-oscog-dtl.63
>> Author: dtl
>> Time: 20 April 2011, 10:18:02 am
>> UUID: c1d30608-304c-52b7-20ca-32f7a46c1508
>> Ancestors: VMMaker-oscog-EstebanLorenzano.62, VMMaker-oscog-dtl.61
>>
>> Re-save from VMMaker-oscog-EstebanLorenzano.62 because VMMaker-oscog-dtl.61
> and VMMaker-oscog-dtl.60 were saved without correct ancestry.
>>
>> Actual ancestry:
>>  VMMaker-oscog-EstebanLorenzano.62
>>  VMMaker-oscog-dtl.61
>>  VMMaker-oscog-dtl.60
>>  VMMaker-oscog-dtl.59
>>
>> Changes included here are from:
>>
>> Name: VMMaker-oscog-dtl.61
>> A second batch of updates from VMM trunk, primarily cosmetic but also
>> a class comment update and a couple of methods that had not previously
>> been pragmatized in oscog.
>>
>> Name: VMMaker-oscog-dtl.60
>> These changes are methods from the main VMM branch for which <#var:#type:>
>> declarations have been formatted with proper spacing. By updating these
>> in the oscog branch, all of these methods are identical in both branches.
>> All changes are cosmetic (no functional changes to the methods).
>
> I give up. I cannot commit oscog updates to SqueakSource because
> SqueakSource fails on the update every time (after a *long* wait for
> the upload). So I save locally and copy to SqueakSource, and just end
> up with a mess. The VMMaker-oscog-dtl.63 update was my attempt to
> fix the problems from the failed updates yesterday, which seems to
> have resulted in yet another broken update (failure on upload, no
> ancestor history showing in the archive now).
>
> I somehow managed to save VMMaker-oscog-dtl.61 and VMMaker-oscog-dtl.60
> yesterday without ancestor history, which in turn leaves today's new
> upload VMMaker-oscog-EstebanLorenzano.62 without ancestor history.
> Tonight I saved a new version VMMaker-oscog-dtl.63 that is identical
> to VMMaker-oscog-EstebanLorenzano.62, but with the ancestor version
> history restored. But now the new update VMMaker-oscog-dtl.63 on
> SqueakSource shows no ancestor history, although is does show the
> ancestor history on my local archive.
>
> My apologies. I don't know how I broke this and I don't know how to
> fix it, but I'm out of time and out of patience so this will have to
> do for now.
>
> Speaking of out of patience, uploading a large update to SqueakSource
> (i.e. anything for oscog) is simply impossible. It looks like a memory
> resource problem to me (*). Double the memory allocated to whatever
> process the SqueakSource server is running on, and I'll bet it starts
> working fine.
>
> (*) Moderate sized MCZ updates upload without problems (e.g. VMMaker
> trunk) but large updates (from the oscog VMMaker branch) do not. A
> large update proceeds normally about half the way through the progress
> bar, then turns to molasses. That suggests that something is running
> out of memory and is starting to swap. D'oh.
>

>
> On Thu, 21 Apr 2011, stephane ducasse wrote:
>
>>
>> David
>>
>> would you mind trying to save on SmalltalkHub in a dummy project the file
>> that drives you mad?
>> Because like that we can make sure SmalltalkHub handles well such a
>> situation.
>
> As I noted here (and elsewhere) already, squeaksource.com is running slow
> code, on a slow VM, on a slow machine. I built a squeaksource image on my pc
> (2.4 GHz Core2), using Squeak 4.3 + the latest CogVM. Uploading is very
> fast, creating a diff (which is possibly responsible for the slow behavior
> of squeaksource.com) is a subsecond operation even for large packages
> (>=1MB).
>

>
> On 21 April 2011 18:29, Levente Uzonyi<[hidden email]>  wrote:
>> On Thu, 21 Apr 2011, stephane ducasse wrote:
>>
>>> David
>>>
>>> would you mind trying to save on SmalltalkHub in a dummy project the file
>>> that drives you mad?
>>> Because like that we can make sure SmalltalkHub handles well such a
>>> situation.
>> As I noted here (and elsewhere) already, squeaksource.com is running slow
>> code, on a slow VM, on a slow machine. I built a squeaksource image on my pc
>> (2.4 GHz Core2), using Squeak 4.3 + the latest CogVM. Uploading is very
>> fast, creating a diff (which is possibly responsible for the slow behavior
>> of squeaksource.com) is a subsecond operation even for large packages
>> (>=1MB).
>>
> Is there a way to migrate squeaksource data to updated image/VMs?
> It would be nice.

>
> On 4/21/2011 19:23, Igor Stasenko wrote:
>>
>> On 21 April 2011 18:29, Levente Uzonyi<[hidden email]>  wrote:
>>>
>>> On Thu, 21 Apr 2011, stephane ducasse wrote:
>>>
>>>> David
>>>>
>>>> would you mind trying to save on SmalltalkHub in a dummy project the
>>>> file
>>>> that drives you mad?
>>>> Because like that we can make sure SmalltalkHub handles well such a
>>>> situation.
>>>
>>> As I noted here (and elsewhere) already, squeaksource.com is running slow
>>> code, on a slow VM, on a slow machine. I built a squeaksource image on my
>>> pc
>>> (2.4 GHz Core2), using Squeak 4.3 + the latest CogVM. Uploading is very
>>> fast, creating a diff (which is possibly responsible for the slow
>>> behavior
>>> of squeaksource.com) is a subsecond operation even for large packages
>>> (>=1MB).
>>>
>> Is there a way to migrate squeaksource data to updated image/VMs?
>> It would be nice.
>
> IIRC, source.squeak.org currently runs on Squeak 4.1. The code is at
> http://source.squeak.org/ss.html
>

> On 21 April 2011 19:38, Andreas Raab <[hidden email]> wrote:
>>
>> On 4/21/2011 19:23, Igor Stasenko wrote:
>>>
>>> Is there a way to migrate squeaksource data to updated image/VMs?
>>> It would be nice.
>>
>> IIRC, source.squeak.org currently runs on Squeak 4.1. The code is at
>> http://source.squeak.org/ss.html
>>
>
> yes, but what about data contained in image? or there is no such? i am
> totally ignorant about squeaksource.