July 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] merging in a filetree repository

by Alexandre Bergel

> Our âcodingâ atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class. That I understand. > Nowâ¦ you are complaining in the wrong problem. Wellâ¦ Having one file per method seems to be very problematic after all. > FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. > Thatâs what is plain wrong and should be at least optional :) > > I would happily integrate a âPlainFileTreeâ protocol (without monticello information) as an option, if someone provides such extension. > Crap, I could make it myself if I have the time!â¦ maybe next insomnia night :P We can work on this next week. I am fed up to hear âwhy you guys are not using github?" Alexandre > >> On 08 Jul 2015, at 14:51, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >> >> This is frustratingâ¦. >> >> I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver >> And I got: >> >> ~/HackathonSattose2015> git merge master >> pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory >> fatal: Failed to execute internal merge >> >> Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missingâ¦. >> >> Maybe I will go back to Smalltalkhub afterallâ¦ >> >> Alexandre >> >> >>> On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto(a)finworks.biz> wrote: >>> >>> We have a .gitignore file that contains: >>> version >>> methodProperties.json >>> >>> So, we don't bother. >>> >>> The side effects of this are: >>> Without methodProperties.json, you have the default author and >>> meaningless timestamp. >>> Without the version file, loading does not work properly. So we have a >>> script that generates version files for each package before we load >>> into the image. At first, this script counted versions for the package >>> and got all the info from the git repository. But this was too >>> expensive (because the file system became slow when traversing the git >>> repo to find the meta data). So now, we just generate a version file >>> with a fixed author, date & time now and a UUID & version number >>> derived from the SHA1 of the .package directory. >>> >>> We get all the meta-information directly from the git repo, using git >>> tools. This can be better with GitFileTree. >>> >>> So we really just use basics of Monticello & Metacello and do the rest >>> externally from the image. We need to explore the available tools >>> more. >>> >>> On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel >>> <alexandre.bergel(a)me.com> wrote: >>>> Hi! >>>> >>>> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? >>>> I understand that no since the merging has to be done by Git, and not by monticello. >>>> >>>> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: >>>> >>>> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version >>>> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json >>>> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json >>>> >>>> Why do we need this methodProperties.json and version files? Shouldnât git handle this? >>>> >>>> How should I merge these files? Any experience? >>>> >>>> Cheers, >>>> Alexandre >>>> >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Stephan Eggermont

On 08-07-15 14:51, Alexandre Bergel wrote: > This is frustratingâ¦. > > Maybe I will go back to Smalltalkhub afterallâ¦ Git support is still bleeding edge. Why did you want to move away from smalltalkhub before we have libgit2 integrated? Stephan

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Thierry Goubier

2015-07-08 14:51 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > This is frustratingâ¦. > > I have followed the instruction given on > https://github.com/ThierryGoubier/GitFileTree-MergeDriver > And I got: > > ~/HackathonSattose2015> git merge master > pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh > .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: > No such file or directory > fatal: Failed to execute internal merge > Looks like a problem when installing the merge driver. pathToGitFileTree-MergeDriver shoudl not appear like that, so it seems the make used to install wasn't successful. Can you show the result of $ git config --get merge.mcVersion.driver > > Why do we need file tree? The simple fileout is not enough? Most of > languages have one file per class. I do not see why we need to be different > on that. Or maybe there is something obvious I am missingâ¦. > FileTree is a standardised format, cross-smalltalk compatible, browsable on github, with a nice set of tests to make sure it keeps working across many revisions of Squeak, Gemstone and Pharo. > > Maybe I will go back to Smalltalkhub afterallâ¦ > Up to you ;) Thierry > > Alexandre > > > > On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto(a)finworks.biz> wrote: > > > > We have a .gitignore file that contains: > > version > > methodProperties.json > > > > So, we don't bother. > > > > The side effects of this are: > > Without methodProperties.json, you have the default author and > > meaningless timestamp. > > Without the version file, loading does not work properly. So we have a > > script that generates version files for each package before we load > > into the image. At first, this script counted versions for the package > > and got all the info from the git repository. But this was too > > expensive (because the file system became slow when traversing the git > > repo to find the meta data). So now, we just generate a version file > > with a fixed author, date & time now and a UUID & version number > > derived from the SHA1 of the .package directory. > > > > We get all the meta-information directly from the git repo, using git > > tools. This can be better with GitFileTree. > > > > So we really just use basics of Monticello & Metacello and do the rest > > externally from the image. We need to explore the available tools > > more. > > > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel > > <alexandre.bergel(a)me.com> wrote: > >> Hi! > >> > >> Do I still need to press the merge button in Monticello when I am > working on a filtree git repository? > >> I understand that no since the merging has to be done by Git, and not > by monticello. > >> > >> I tried to not do the merge in monticello, but I get some conflicts > when doing the git merge. For example: > >> > >> CONFLICT (content): Merge conflict in > Hackathon.package/monticello.meta/version > >> CONFLICT (content): Merge conflict in > Hackathon.package/HProject.class/methodProperties.json > >> CONFLICT (content): Merge conflict in > Hackathon.package/HClass.class/methodProperties.json > >> > >> Why do we need this methodProperties.json and version files? Shouldnât > git handle this? > >> > >> How should I merge these files? Any experience? > >> > >> Cheers, > >> Alexandre > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Esteban Lorenzano

Our âcodingâ atoms are methods, not classes. Having method per file we can trace the history of changes with method detail, not class. Nowâ¦ you are complaining in the wrong problem. FileTree meta information (who causes your merge problems) is needed *just* to keep monticello compatibility. Thatâs what is plain wrong and should be at least optional :) I would happily integrate a âPlainFileTreeâ protocol (without monticello information) as an option, if someone provides such extension. Crap, I could make it myself if I have the time!â¦ maybe next insomnia night :P Esteban > On 08 Jul 2015, at 14:51, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > This is frustratingâ¦. > > I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver > And I got: > > ~/HackathonSattose2015> git merge master > pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory > fatal: Failed to execute internal merge > > Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missingâ¦. > > Maybe I will go back to Smalltalkhub afterallâ¦ > > Alexandre > > >> On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto(a)finworks.biz> wrote: >> >> We have a .gitignore file that contains: >> version >> methodProperties.json >> >> So, we don't bother. >> >> The side effects of this are: >> Without methodProperties.json, you have the default author and >> meaningless timestamp. >> Without the version file, loading does not work properly. So we have a >> script that generates version files for each package before we load >> into the image. At first, this script counted versions for the package >> and got all the info from the git repository. But this was too >> expensive (because the file system became slow when traversing the git >> repo to find the meta data). So now, we just generate a version file >> with a fixed author, date & time now and a UUID & version number >> derived from the SHA1 of the .package directory. >> >> We get all the meta-information directly from the git repo, using git >> tools. This can be better with GitFileTree. >> >> So we really just use basics of Monticello & Metacello and do the rest >> externally from the image. We need to explore the available tools >> more. >> >> On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel >> <alexandre.bergel(a)me.com> wrote: >>> Hi! >>> >>> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? >>> I understand that no since the merging has to be done by Git, and not by monticello. >>> >>> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: >>> >>> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version >>> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json >>> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json >>> >>> Why do we need this methodProperties.json and version files? Shouldnât git handle this? >>> >>> How should I merge these files? Any experience? >>> >>> Cheers, >>> Alexandre >>> >>> -- >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>> Alexandre Bergel http://www.bergel.eu >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>> >>> >>> >>> >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Alexandre Bergel

This is frustratingâ¦. I have followed the instruction given on https://github.com/ThierryGoubier/GitFileTree-MergeDriver And I got: ~/HackathonSattose2015> git merge master pathToGitFileTree-MergeDriver/merge --version .merge_file_WAu4Yh .merge_file_WxznI2 .merge_file_ZmiIKE: pathToGitFileTree-MergeDriver/merge: No such file or directory fatal: Failed to execute internal merge Why do we need file tree? The simple fileout is not enough? Most of languages have one file per class. I do not see why we need to be different on that. Or maybe there is something obvious I am missingâ¦. Maybe I will go back to Smalltalkhub afterallâ¦ Alexandre > On Jul 8, 2015, at 2:21 PM, Otto Behrens <otto(a)finworks.biz> wrote: > > We have a .gitignore file that contains: > version > methodProperties.json > > So, we don't bother. > > The side effects of this are: > Without methodProperties.json, you have the default author and > meaningless timestamp. > Without the version file, loading does not work properly. So we have a > script that generates version files for each package before we load > into the image. At first, this script counted versions for the package > and got all the info from the git repository. But this was too > expensive (because the file system became slow when traversing the git > repo to find the meta data). So now, we just generate a version file > with a fixed author, date & time now and a UUID & version number > derived from the SHA1 of the .package directory. > > We get all the meta-information directly from the git repo, using git > tools. This can be better with GitFileTree. > > So we really just use basics of Monticello & Metacello and do the rest > externally from the image. We need to explore the available tools > more. > > On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel > <alexandre.bergel(a)me.com> wrote: >> Hi! >> >> Do I still need to press the merge button in Monticello when I am working on a filtree git repository? >> I understand that no since the merging has to be done by Git, and not by monticello. >> >> I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: >> >> CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version >> CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json >> CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json >> >> Why do we need this methodProperties.json and version files? Shouldnât git handle this? >> >> How should I merge these files? Any experience? >> >> Cheers, >> Alexandre >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 8, 2015

Re: [Pharo-dev] Strange Slice+Changes behavior

by Nicolai Hess

2015-07-08 12:45 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > Hi Nicolai, > > I had to also do this (this is ugly and I shouldn't query class types, but > maybe this should be fixed elsewhere anyway) > MCDefinitionIndex>>addAll: aCollection > aCollection > do: [ :ea | > (ea isKindOf: OrderedCollection) > ifTrue: [ self addAll: ea ] > ifFalse: [ self add: ea ] ] > > Because aCollection can now be also collection of collections. > Yes? > > But after both those changes it looks like a correct changeset. > > Peter > > > On Wed, Jul 8, 2015 at 11:59 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> There is a bug on how it collects all definitions from all dependencies. >> >> @Peter can you fix this please, it is a missing yourself in >> >> MCWorkingCopy>>#loadRemoteDependenciesIn: >> >> ... >> >> ^ dependencies >> inject: OrderedCollection new >> into: [ :all :deps| all addAll: deps;yourself ] >> >> >> >> >> >> 2015-07-07 14:19 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: >> >>> Hi, >>> >>> I'm encountering very strange slice+changes behavior and I am not sure >>> wtf is going on... >>> because it's showing that there are changes in untouched code... >>> >>> So imagine I've changed two packages "Spec-Core" and "Spec-Examples" >>> >>> If I create a slice for the package independently, then displaying >>> changes looks fine >>> >>> Spec-Core Changes >>> >>> â >>> or >>> >>> Spec-Examples Changes >>> >>> â >>> so far so good, but if I in the slice maker select both packages... and >>> then check the changes this shows up >>> >>> â >>> which is wtf... I didn't touch AbstractAdapter nor other classes. It's >>> almost like it's comparing "Spec-Examples" against "Spec-Core" >>> >>> If I (after creating slice for both packages) select "Spec-Core" it's >>> complaining about removed classes... which are from "Spec-Examples" >>> >>> â >>> âHowever "Spec-Examples" still looks just fine >>> >>> â >>> What is going on? What am I missing? >>> >>> This is not the first time I am making slices, but I've never >>> encountered this. >>> >>> Thanks, >>> Peter >>> >> >> >

July 8, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50160 Home: https://github.com/pharo-project/pharo-core

July 8, 2015

[pharo-project/pharo-core] 29586a: 50160

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 29586a92131d5343e3c7aca3ad6197b63a677c22 https://github.com/pharo-project/pharo-core/commit/29586a92131d5343e3c7aca3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-07-08 (Wed, 08 Jul 2015) Changed paths: A Collections-Abstract.package/CollectionsAssembly.class/README.md A Collections-Abstract.package/CollectionsAssembly.class/class/meta-data/description.st A Collections-Abstract.package/CollectionsAssembly.class/class/meta-data/packageName.st A Collections-Abstract.package/CollectionsAssembly.class/class/meta-data/parts.st A Collections-Abstract.package/CollectionsAssembly.class/class/meta-data/version.st A Collections-Abstract.package/CollectionsAssembly.class/definition.st A Collections-Abstract.package/ManifestCollectionsAbstract.class/README.md A Collections-Abstract.package/ManifestCollectionsAbstract.class/class/meta-data/dependencies.st A Collections-Abstract.package/ManifestCollectionsAbstract.class/class/meta-data/packageName.st A Collections-Abstract.package/ManifestCollectionsAbstract.class/definition.st R Collections-Arithmetic.package/CollectionsArithmeticReadme.class/README.md R Collections-Arithmetic.package/CollectionsArithmeticReadme.class/definition.st A Collections-Arithmetic.package/ManifestCollectionsArithmetic.class/README.md A Collections-Arithmetic.package/ManifestCollectionsArithmetic.class/class/meta-data/dependencies.st A Collections-Arithmetic.package/ManifestCollectionsArithmetic.class/class/meta-data/description.st A Collections-Arithmetic.package/ManifestCollectionsArithmetic.class/class/meta-data/packageName.st A Collections-Arithmetic.package/ManifestCollectionsArithmetic.class/definition.st A Collections-Atomic.package/ManifestCollectionsAtomic.class/README.md A Collections-Atomic.package/ManifestCollectionsAtomic.class/class/meta-data/dependencies.st A Collections-Atomic.package/ManifestCollectionsAtomic.class/class/meta-data/packageName.st A Collections-Atomic.package/ManifestCollectionsAtomic.class/definition.st A Collections-Native.package/ManifestCollectionsNative.class/README.md A Collections-Native.package/ManifestCollectionsNative.class/class/meta-data/dependencies.st A Collections-Native.package/ManifestCollectionsNative.class/class/meta-data/description.st A Collections-Native.package/ManifestCollectionsNative.class/class/meta-data/packageName.st A Collections-Native.package/ManifestCollectionsNative.class/definition.st A Collections-Sequenceable.package/ManifestCollectionsSequenceable.class/README.md A Collections-Sequenceable.package/ManifestCollectionsSequenceable.class/class/meta-data/dependencies.st A Collections-Sequenceable.package/ManifestCollectionsSequenceable.class/class/meta-data/description.st A Collections-Sequenceable.package/ManifestCollectionsSequenceable.class/class/meta-data/packageName.st A Collections-Sequenceable.package/ManifestCollectionsSequenceable.class/definition.st A Collections-Stack.package/ManifestCollectionsStack.class/README.md A Collections-Stack.package/ManifestCollectionsStack.class/class/meta-data/dependencies.st A Collections-Stack.package/ManifestCollectionsStack.class/class/meta-data/description.st A Collections-Stack.package/ManifestCollectionsStack.class/class/meta-data/packageName.st A Collections-Stack.package/ManifestCollectionsStack.class/definition.st A Collections-Streams.package/ManifestCollectionsStreams.class/README.md A Collections-Streams.package/ManifestCollectionsStreams.class/class/meta-data/dependencies.st A Collections-Streams.package/ManifestCollectionsStreams.class/class/meta-data/description.st A Collections-Streams.package/ManifestCollectionsStreams.class/class/meta-data/packageName.st A Collections-Streams.package/ManifestCollectionsStreams.class/definition.st A Collections-Strings.package/ManifestCollectionsStrings.class/README.md A Collections-Strings.package/ManifestCollectionsStrings.class/class/meta-data/dependencies.st A Collections-Strings.package/ManifestCollectionsStrings.class/class/meta-data/description.st A Collections-Strings.package/ManifestCollectionsStrings.class/class/meta-data/packageName.st A Collections-Strings.package/ManifestCollectionsStrings.class/definition.st A Collections-Support.package/ManifestCollectionsSupport.class/README.md A Collections-Support.package/ManifestCollectionsSupport.class/class/meta-data/dependencies.st A Collections-Support.package/ManifestCollectionsSupport.class/class/meta-data/description.st A Collections-Support.package/ManifestCollectionsSupport.class/class/meta-data/packageName.st A Collections-Support.package/ManifestCollectionsSupport.class/definition.st A Collections-Unordered.package/ManifestCollectionsUnordered.class/README.md A Collections-Unordered.package/ManifestCollectionsUnordered.class/class/meta-data/dependencies.st A Collections-Unordered.package/ManifestCollectionsUnordered.class/class/meta-data/description.st A Collections-Unordered.package/ManifestCollectionsUnordered.class/class/meta-data/packageName.st A Collections-Unordered.package/ManifestCollectionsUnordered.class/definition.st A Collections-Weak.package/ManifestCollectionsWeak.class/README.md A Collections-Weak.package/ManifestCollectionsWeak.class/class/meta-data/dependencies.st A Collections-Weak.package/ManifestCollectionsWeak.class/class/meta-data/description.st A Collections-Weak.package/ManifestCollectionsWeak.class/class/meta-data/packageName.st A Collections-Weak.package/ManifestCollectionsWeak.class/definition.st A CollectionsTests.package/ManifestCollectionsTests.class/README.md A CollectionsTests.package/ManifestCollectionsTests.class/class/meta-data/dependencies.st A CollectionsTests.package/ManifestCollectionsTests.class/class/meta-data/description.st A CollectionsTests.package/ManifestCollectionsTests.class/class/meta-data/packageName.st A CollectionsTests.package/ManifestCollectionsTests.class/definition.st A Jobs.package/Job.class/instance/accessing/owner.st A Jobs.package/JobTest.class/instance/tests/testOwner.st A Kernel.package/AssemblyManifest.class/README.md A Kernel.package/AssemblyManifest.class/class/accessing/description.st A Kernel.package/AssemblyManifest.class/class/accessing/packageName.st A Kernel.package/AssemblyManifest.class/class/accessing/parts.st A Kernel.package/AssemblyManifest.class/class/accessing/version.st A Kernel.package/AssemblyManifest.class/class/default/manifestClassComment.st A Kernel.package/AssemblyManifest.class/class/instance creation/newNamed_category_.st A Kernel.package/AssemblyManifest.class/definition.st M Kernel.package/ManifestKernel.class/README.md A Kernel.package/ManifestKernel.class/class/code-critics/ruleConsistencyCheckRuleV1FalsePositive.st A Kernel.package/ManifestKernel.class/class/code-critics/ruleEqualsTrueRuleV1FalsePositive.st A Kernel.package/ManifestKernel.class/class/code-critics/ruleLongMethodsRuleV1FalsePositive.st R Kernel.package/ManifestKernel.class/class/meta data/ruleConsistencyCheckRuleV1FalsePositive.st R Kernel.package/ManifestKernel.class/class/meta data/ruleEqualsTrueRuleV1FalsePositive.st R Kernel.package/ManifestKernel.class/class/meta data/ruleLongMethodsRuleV1FalsePositive.st A Kernel.package/ManifestKernel.class/class/meta-data/dependencies.st A Kernel.package/ManifestKernel.class/class/meta-data/description.st A Kernel.package/ManifestKernel.class/class/meta-data/packageName.st A Kernel.package/PharoKernelAssembly.class/README.md A Kernel.package/PharoKernelAssembly.class/class/meta-data/description.st A Kernel.package/PharoKernelAssembly.class/class/meta-data/packageName.st A Kernel.package/PharoKernelAssembly.class/class/meta-data/parts.st A Kernel.package/PharoKernelAssembly.class/class/meta-data/version.st A Kernel.package/PharoKernelAssembly.class/definition.st M KernelTests.package/ManifestKernelTests.class/README.md A KernelTests.package/ManifestKernelTests.class/class/meta-data/dependencies.st A KernelTests.package/ManifestKernelTests.class/class/meta-data/description.st A KernelTests.package/ManifestKernelTests.class/class/meta-data/packageName.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/noteNewOwner_.st M Nautilus.package/NautilusAnnotationDisplayer.class/instance/submorphs-accessing/toggleFormatAsYouRead.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50159.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50160.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50159.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50160.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50160 15914 Add Manifest for the Pharo kernel https://pharo.fogbugz.com/f/cases/15914 15919 Disable format as you read should put back the unformatted code https://pharo.fogbugz.com/f/cases/15919 15917 Job can answer who is the owner https://pharo.fogbugz.com/f/cases/15917 http://files.pharo.org/image/50/50160.zip

July 8, 2015

Re: [Pharo-dev] Probably Metacello sucksâ¦

by Merwan Ouddane

Hi, As i said earlier in the conversation, you have to unload the oswindow configuration first... Just execute this before loading the package: MCPackageLoader unloadPackage: (MCPackage named: 'ConfigurationOfOSWindow') Merwan On mar., 2015-07-07 at 17:13 +0200, Natalia Tymchuk wrote: > Hi. > > I tried to load Woden into pharo 4 and 5 images using script: > > Gofer new smalltalkhubUser: 'ronsaldoâ > project: 'Wodenâ; > package: 'ConfigurationOfWodenâ; > load. > (#ConfigurationOfWoden asClass project version: #jenkins) load > > And in both cases I got the error: 'Name not found: WithOpenGLAndExamplesâ. It looks like version #jenkins, created by JB, doesnât work. > > Best regards, > Natalia > > > > On 25 Jun 2015, at 20:14, stepharo <stepharo(a)free.fr> wrote: > > > > Yuriy > > > > can you check with JB because he told me that he wrote a configuration for Wooden. > > > > Stef > > > > Le 12/6/15 13:48, Yuriy Tymchuk a Ã©crit :Yuri > >> Just a quick side note: > >> > >> my initial email was kind of a troll. Because when you ask for something about roassal and 3D, you get a reply about Roassal-Woden i.e. Roassal3D is not supported anymore, you have to use Woden instead. Now when you have to load Woden, you canât so you have to use the uber-long script on the Woden project page instead of conf. Thatâs why Iâve joked about using scripts instead of Metacello. > >> > >> Uko > >> > >> > >> > >>> On 12 Jun 2015, at 12:25, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >>> > >>> > >>>> On 12 Jun 2015, at 10:40, Stephan Eggermont <stephan(a)stack.nl> wrote: > >>>> > >>>> On 12-06-15 10:24, Esteban Lorenzano wrote: > >>>>> it was just an example of why using #stable in project dependences is a bad idea :) > >>>>> you made #releaseN.N to fix precisely my point. > >>>>> there should exist something like I say â3.*â > >>>> #'release3' always refers to the latest stable 3.*.*.* > >>> I know :) > >>> Iâm just saying that I would like to have that as a standard mechanism, not a convention. > >>> > >>> Esteban > >>> > >>>>> Iâm sorry for being obvious here, I know this is knownâ¦ problem is that Iâve seen far too much the use of metacello not for doing releases but to handle commits. > >>>> I think it mostly has to do with the need to have exact reproducible builds (which is different from the need to have working software). > >>>> That would be better handled with a (separate) SnapshotOf class i.m.o. > >>>> > >>>> Stephan > >>>> > >>>> > >>>> > >>> > >> > >> > > > > > >

July 8, 2015

Re: [Pharo-dev] merging in a filetree repository

by Otto Behrens

We have a .gitignore file that contains: version methodProperties.json So, we don't bother. The side effects of this are: Without methodProperties.json, you have the default author and meaningless timestamp. Without the version file, loading does not work properly. So we have a script that generates version files for each package before we load into the image. At first, this script counted versions for the package and got all the info from the git repository. But this was too expensive (because the file system became slow when traversing the git repo to find the meta data). So now, we just generate a version file with a fixed author, date & time now and a UUID & version number derived from the SHA1 of the .package directory. We get all the meta-information directly from the git repo, using git tools. This can be better with GitFileTree. So we really just use basics of Monticello & Metacello and do the rest externally from the image. We need to explore the available tools more. On Wed, Jul 8, 2015 at 12:18 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > Do I still need to press the merge button in Monticello when I am working on a filtree git repository? > I understand that no since the merging has to be done by Git, and not by monticello. > > I tried to not do the merge in monticello, but I get some conflicts when doing the git merge. For example: > > CONFLICT (content): Merge conflict in Hackathon.package/monticello.meta/version > CONFLICT (content): Merge conflict in Hackathon.package/HProject.class/methodProperties.json > CONFLICT (content): Merge conflict in Hackathon.package/HClass.class/methodProperties.json > > Why do we need this methodProperties.json and version files? Shouldnât git handle this? > > How should I merge these files? Any experience? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

July 8, 2015