[squeak-dev] [ANN] Monticello 2.0.25

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

[squeak-dev] [ANN] Monticello 2.0.25

Colin Putney
Hi all,

This release makes several fixes:

- a repository containing the versioning history of MC2 is included in  
the archive
- fixed a bug that would prevent detection of dictionary-based shared  
pool imports
- fixed a bug that would prevent declarative shared pools from being  
filed out correctly

Download it here:

http://www.wiresong.ca/static/releases/Monticello-current.zip

Colin

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [ANN] Monticello 2.0.25

Lukas Renggli
Hi Colin

Some problems with the latest version:

- I am following the "Bootstrapping" instructions in the
documentation: After loading Release-cwp.25 all the packages MC2-* and
Release are marked as dirty. In fact there are no changes.

- I have some instances of MDFileRepository that have all inst-vars
nil. On system startup I get a couple of debuggers because the system
tries to rescan these files. Doing MDFileRepository allInstances on
startup seems to be dangerous if there are thousands of instances, and
this won't work well on GemStone.

Some other thoughts:

- I wonder, if you thought about using MC2 as a replacement for the
changes-file? So every accept would commit the particular method to
the repository, and the versions view would connect to the server and
display all the versions of a particular element. When submitting the
package, a slice would be created of the already existing elements. I
think such a model would beautifully with MC2.

- I wonder how I can calculate the diff between two arbitrary
versions? This doesn't seem to be possible in the current GUI.

- I am confused about "Project Config Slice" and "Union Slice". Is it
correct that the "Project Config Slices" is like an "Union Slice", but
automatically includes all the slices of the project? Are there other
differences?

- And please, please, please ... get rid of those cryptic labels for
the elements. Nobody will ever even consider using it like that.

Cheers,
Lukas

PS: An early beta version of the Sourcetalk server will soon be put
online, so that people can give a try.

On 10/14/08, Colin Putney <[hidden email]> wrote:

> Hi all,
>
>  This release makes several fixes:
>
>  - a repository containing the versioning history of MC2 is included in the
> archive
>  - fixed a bug that would prevent detection of dictionary-based shared pool
> imports
>  - fixed a bug that would prevent declarative shared pools from being filed
> out correctly
>
>  Download it here:
>
> http://www.wiresong.ca/static/releases/Monticello-current.zip
>
>  Colin
>
>


--
Lukas Renggli
http://www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [ANN] Monticello 2.0.25

Lukas Renggli
When trying to save a "Project Config Slice" I get the following error:

16 October 2008 12:49:39 pm

VM: Mac OS - a SmalltalkImage
Image: Squeak3.9.1 [latest update: #7075]

UndefinedObject(Object)>>error:
        Receiver: nil
        Arguments and temporary variables:
                aString: 'Instances of UndefinedObject are not indexable'
        Receiver's instance variables:
nil

UndefinedObject(Object)>>errorNotIndexable
        Receiver: nil
        Arguments and temporary variables:

        Receiver's instance variables:
nil

UndefinedObject(Object)>>size
        Receiver: nil
        Arguments and temporary variables:

        Receiver's instance variables:
nil

ByteArray class>>hashBytes:startingWith:
        Receiver: ByteArray
        Arguments and temporary variables:
                aByteArray: nil
                speciesHash: 47285843
                byteArraySize: nil
                hash: nil
                low: nil
                pos: nil
        Receiver's instance variables:
                superclass: ArrayedCollection
                methodDict: a MethodDictionary(#asByteArray->a CompiledMethod
(2767) #asByteArr...etc...
                format: 1026
                instanceVariables: nil
                organization: ('accessing' asWideString atAllPut: byteAt:
byteAt:put: byteSize ...etc...
                subclasses: {CompiledMethod . UUID . WAExternalID}
                name: #ByteArray
                classPool: a Dictionary()
                sharedPools: nil
                environment: nil
                category: #'Collections-Arrayed'
                traitComposition: nil
                localSelectors: nil


--- The full stack ---
UndefinedObject(Object)>>error:
UndefinedObject(Object)>>errorNotIndexable
UndefinedObject(Object)>>size
ByteArray class>>hashBytes:startingWith:
 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
MDRepositoryElement>>hash
Dictionary>>scanFor:
Dictionary(Set)>>findElementOrNil:
Dictionary>>at:ifAbsent:
MDWorkingCopy>>versionForElement:
[] in MDProjectConfigSlice(MDSlice)>>basicSaveFrom:to:memo: {[:ea |
objects   add: (aWorkingCopy versionForElement: ea)]}
[] in MDProjectConfigSlice>>elementsDo: {[:ea | aBlock   value:
(MDRepositoryElement projectId: project id repository...]}
OrderedCollection>>do:
MDProjectConfigSlice>>elementsDo:
MDProjectConfigSlice(MDSlice)>>do:
MDProjectConfigSlice(MDSlice)>>basicSaveFrom:to:memo:
[] in MDProjectConfigSlice(MDSlice)>>saveFrom:to:memo: {[self
basicSaveFrom: aWorkingCopy   to: aRepository   memo: aMemo]}
BlockContext>>ensure:
MDPlatform>>withCursor:do:
MDProjectConfigSlice(MDSlice)>>saveFrom:to:memo:
MDProject>>save:
[] in MDSliceNode>>save {[project save: slice]}
BlockContext>>on:do:
MDSliceNode>>save
MDCmdSaveSlice>>execute
MDCmdSaveSlice(OBCommand)>>perform:orSendTo:
[] in MenuItemMorph>>invokeWithEvent: {[(selArgCount := selector
numArgs) = 0   ifTrue: [target perform: selector] ...]}
BlockContext>>ensure:
CursorWithMask(Cursor)>>showWhile:
MenuItemMorph>>invokeWithEvent:
MenuItemMorph>>mouseUp:
MenuItemMorph>>handleMouseUp:
MouseButtonEvent>>sentTo:
MenuItemMorph(Morph)>>handleEvent:
MorphicEventDispatcher>>dispatchDefault:with:
MorphicEventDispatcher>>dispatchEvent:with:
MenuItemMorph(Morph)>>processEvent:using:
MorphicEventDispatcher>>dispatchDefault:with:
MorphicEventDispatcher>>dispatchEvent:with:
MenuMorph(Morph)>>processEvent:using:
MenuMorph(Morph)>>processEvent:
MenuMorph>>handleFocusEvent:
[] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self.
ActiveEvent := anEvent.  result := focusHolder     han...]}
[] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]}
BlockContext>>on:do:
PasteUpMorph>>becomeActiveDuring:
HandMorph>>sendFocusEvent:to:clear:
HandMorph>>sendEvent:focus:clear:
HandMorph>>sendMouseEvent:
HandMorph>>handleEvent:
HandMorph>>processEvents
[] in WorldState>>doOneCycleNowFor: {[:h |  ActiveHand := h.  h
processEvents.  capturingGesture := capturingGest...]}
Array(SequenceableCollection)>>do:
WorldState>>handsDo:
WorldState>>doOneCycleNowFor:
WorldState>>doOneCycleFor:
PasteUpMorph>>doOneCycle
[] in Project class>>spawnNewProcess {[[World doOneCycle.  Processor
yield.  false] whileFalse.  nil]}
[] in BlockContext>>newProcess {[self value.  Processor terminateActive]}


On 10/16/08, Lukas Renggli <[hidden email]> wrote:

> Hi Colin
>
>  Some problems with the latest version:
>
>  - I am following the "Bootstrapping" instructions in the
>  documentation: After loading Release-cwp.25 all the packages MC2-* and
>  Release are marked as dirty. In fact there are no changes.
>
>  - I have some instances of MDFileRepository that have all inst-vars
>  nil. On system startup I get a couple of debuggers because the system
>  tries to rescan these files. Doing MDFileRepository allInstances on
>  startup seems to be dangerous if there are thousands of instances, and
>  this won't work well on GemStone.
>
>  Some other thoughts:
>
>  - I wonder, if you thought about using MC2 as a replacement for the
>  changes-file? So every accept would commit the particular method to
>  the repository, and the versions view would connect to the server and
>  display all the versions of a particular element. When submitting the
>  package, a slice would be created of the already existing elements. I
>  think such a model would beautifully with MC2.
>
>  - I wonder how I can calculate the diff between two arbitrary
>  versions? This doesn't seem to be possible in the current GUI.
>
>  - I am confused about "Project Config Slice" and "Union Slice". Is it
>  correct that the "Project Config Slices" is like an "Union Slice", but
>  automatically includes all the slices of the project? Are there other
>  differences?
>
>  - And please, please, please ... get rid of those cryptic labels for
>  the elements. Nobody will ever even consider using it like that.
>
>  Cheers,
>  Lukas
>
>  PS: An early beta version of the Sourcetalk server will soon be put
>  online, so that people can give a try.
>
>
>  On 10/14/08, Colin Putney <[hidden email]> wrote:
>  > Hi all,
>  >
>  >  This release makes several fixes:
>  >
>  >  - a repository containing the versioning history of MC2 is included in the
>  > archive
>  >  - fixed a bug that would prevent detection of dictionary-based shared pool
>  > imports
>  >  - fixed a bug that would prevent declarative shared pools from being filed
>  > out correctly
>  >
>  >  Download it here:
>  >
>  > http://www.wiresong.ca/static/releases/Monticello-current.zip
>  >
>  >  Colin
>  >
>  >
>
>
>
> --
>  Lukas Renggli
>  http://www.lukas-renggli.ch
>


--
Lukas Renggli
http://www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [ANN] Monticello 2.0.25

Lukas Renggli
Yet another question: When I load a version from a repository, why
isn't it added to the slices of the current project?

--
Lukas Renggli
http://www.lukas-renggli.ch

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [ANN] Monticello 2.0.25

Colin Putney
In reply to this post by Lukas Renggli

On 16-Oct-08, at 3:32 AM, Lukas Renggli wrote:

> - I am following the "Bootstrapping" instructions in the
> documentation: After loading Release-cwp.25 all the packages MC2-* and
> Release are marked as dirty. In fact there are no changes.

Yes, I noticed this as well. I don't *think* it's a serious problem,  
but it definitely a bug.

> - I have some instances of MDFileRepository that have all inst-vars
> nil. On system startup I get a couple of debuggers because the system
> tries to rescan these files. Doing MDFileRepository allInstances on
> startup seems to be dangerous if there are thousands of instances, and
> this won't work well on GemStone.

FileRepositories should probably re-open their filestreams lazily  
rather than at startup. Do you have thousands of instances with nil  
variables? That really shouldn't happen.

> Some other thoughts:
>
> - I wonder, if you thought about using MC2 as a replacement for the
> changes-file? So every accept would commit the particular method to
> the repository, and the versions view would connect to the server and
> display all the versions of a particular element. When submitting the
> package, a slice would be created of the already existing elements. I
> think such a model would beautifully with MC2.

I have thought about that a little bit - kind of like ENVY. The  
original idea I had was to store source code in MC2, and us the  
changes file strictly for journaling. The changes file would be  
deleted when the image was saved, and you'd only use it to recover  
from crashes. But it would be pretty easy to hook a repository up to  
the SystemChangesNotifier as well, and have a versioned journal. Gotta  
sort out all the immediate issues first.

> - I wonder how I can calculate the diff between two arbitrary
> versions? This doesn't seem to be possible in the current GUI.

You're right, it's not yet possible. I've run into the need for this  
myself lately, so it's on my short-term todo list.

> - I am confused about "Project Config Slice" and "Union Slice". Is it
> correct that the "Project Config Slices" is like an "Union Slice", but
> automatically includes all the slices of the project? Are there other
> differences?

Project Config Slice and Union Slice are two quite different things. A  
union slice is the mathematical union of two other slices. The union  
of SliceA and SliceB includes all the code that is in either slice.  
The Release slice in the Monticello project is an example of that. For  
development, I have the code divided up into different packages, with  
dependencies between them. But a casual user of MC2 doesn't need all  
that structure, I created a Release slice that is the union of all the  
packages that are part of the release. To make a release, I take a  
snapshot of all the Release package and file it out. That way I get  
all the code in a single file, and the user doesn't have to do  
multiple file-ins in the correct order.

A Project Config slice is a meta-level slice. It's used for versioning  
Monticello Projects, not Smalltalk code. If you take a snapshot of a  
project, then load that snapshot into another image, you'll find that  
project now appears in the Project Browser, with all the same slices  
and repositories that were in the first image. This is how the boot  
strapping works:

- first load the basic code to Monticello
- then load the Monticello Project
- then reload all the code, using the project, so that our metadata is  
set up correctly

That last step is kind of tedious right now, but it'll get easier.

> - And please, please, please ... get rid of those cryptic labels for
> the elements. Nobody will ever even consider using it like that.

*sigh*

Okay.


> PS: An early beta version of the Sourcetalk server will soon be put
> online, so that people can give a try.

Awesome!

Colin


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [ANN] Monticello 2.0.25

Colin Putney
In reply to this post by Lukas Renggli

On 16-Oct-08, at 3:52 AM, Lukas Renggli wrote:

> When trying to save a "Project Config Slice" I get the following  
> error:

Thanks, I'll look into it.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] [ANN] Monticello 2.0.25

Colin Putney
In reply to this post by Lukas Renggli

On 16-Oct-08, at 3:54 AM, Lukas Renggli wrote:

> Yet another question: When I load a version from a repository, why
> isn't it added to the slices of the current project?

Good question.

MC2 makes a distinction between versioning Smalltalk code and  
versioning Monticello projects. Loading a snapshot of Smalltalk code  
doesn't alter the Project - that's a separate operation. Loading a  
snapshot of your project (using a project config slice) affects the  
project but not the Smalltalk code in the image.

Does that make sense?

Colin