[Vm-dev] Re: VM Maker: VMMaker-oscog-dtl.63.mcz

Igor Stasenko siguctua at gmail.com
Thu Apr 21 16:06:18 UTC 2011


On 21 April 2011 06:17, David T. Lewis <lewis at mail.msen.com> wrote:
>
> On Thu, Apr 21, 2011 at 04:59:26AM +0000, squeak-dev-noreply at lists.squeakfoundation.org 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.
>

Welcome to club, Dave! :)
Calm down and endure the pain.  :)
Just commit and then go make tea/cofee.. play chess in garden. Just
don't be nervous and don't lose patience! :)
It uploads stuff correctly (or just throws a timeout error, but that
is not indicating an error on server side).
Wait till it finish (usually on timeout, because it takes like 5
minutes to commit a new snapshot) , but in the end it seems to work
without errors.
So, just don't get confused with your local view in your image
(including package-cache dir).
What i found, that my local MC thinks that operation failed, while on
server is everything ok. Wiping out image & cache dir seems heals the
issue :)

> Dave
>
>



-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list