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 |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |