December 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Pharo+Git cons?

by Luc Fabresse

I will digest that amount of info now ;-) I am still unclear on some parts for example nowadays I load a ConfigOf and then I open the repositories of the dependencies in MC to check if there are updates to be merged in. It seems that it will not be that simple with this new setup. I will give it a try. Thank you all! #Luc 2014-12-02 18:00 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > > On Tue, Dec 2, 2014 at 8:00 AM, Luc Fabresse <luc.fabresse(a)gmail.com> > wrote: > >> Hi, >> >> I continue the discussion here because I really would like to know the >> cons of using Git + Pharo. >> From kilon's video (thx) and the discussion that followed, I have the >> following questions about possible drawbacks of Git+Pharo: >> >> - The most important point to me is: does ConfigurationOf work correctly >> with a repo on GitHub for example? any example somewhere? >> > > When using git, you do not need to use a ConfigurationOf as all of the > packages are versioned together so it isn't necessary to track individual > mcz package versions ... you only really need a baseline to specify > package/project dependencies. > Instead of a ConfigurationOf you use a BaselineOf which has a single > baseline: method[1]. The baseline: method is like any other baseline, > except it isn't necessary to explicitly specify a repo - the repo used for > the packages is the same one as the BaselineOf was loaded from. > > To load a baseline from a github repo you use an expression like the > following: > > Metacello new > baseline: 'Cryptography'; > repository: 'github://GsDevKit/Cryptography:master/repository'; > load: #('Cryptography') > > The :master in the repo specification can the name of a branch (master > branch in this case), a SHA, a tag, or a tag pattern (1.1.? will load tags > 1.1.0, 1.1.1, 1.1.2, etc.). > > To load from a local git clone (filetree repo) you use something like the > following: > > Metacello new > baseline: 'Cryptography'; > repository: 'filetree:///opt/git/Cryptography/repository'; > load: #('Cryptography') > > [1] > https://github.com/GsDevKit/Cryptography/blob/master/repository/BaselineOfC… > >> >> - we should go to command line to commit/update but that could be saved >> with what has been done by Dale in tODE (shell integration, UI to commit, >> push/pull) IIUC. right? >> > > In tODE I've wrapped a large chunk of the shell command line git api with > Smalltalk ... tODE has it's own command line, so git commands can be run > from within tODE on the command line. Other tools make calls to he > Smalltalk api. > > >> >> - Merging could be harder because it would rely on git tools? >> > > When merging with git, you may be merging multiple packages plus doc > files, etc., at once, so the tool required for merge must be built to work > with git merge meta data ... there are external merge tools, but I built a > merge tool in tODE that I actually prefer over the other available merge > tools ... > > >> - opening a filetree repo in MC does not show the latest content since it >> is the local git repo that may not be in sync with the remote one => you >> should first pull the repo >> >> This is actually an advantage ... when you have a local git clone, you > control when and how projects are updated ... how many times have > previously working build procedures suddenly stop working because someone > has made a change to a configuration of a project? With local clones your > environment is static and stable until you are ready to upgrade to a new > version and then you do so in a controlled manner. > > If you use a spec like > 'github://GsDevKit/Cryptography:master/repository', you are really using > the latest version of master branch (bleeding edge for a remote repo)...In > theory you can "require" that all tests pass before a change is merged into > the master branch (using pull requests and travis-ci). so using the latest > master branch should always be "safe". > > Dale >

Dec. 2, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Andreas Wacknitz

> Am 02.12.2014 um 19:51 schrieb Torsten Bergmann <astares(a)gmx.de>: > > Denis wrote: >>> Kilon wrote: >>> Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages. >>> >> Just for few cents. >> If you group this million tools by logical functionality I'm sure it will be much less then smalltalk systems have. Most tools just repeat each other. And you >know most smalltalk development tools are absent in other systems. And every year when I read ESUG presentations I see another batch of new tools. I'm not see >such progress in another languages. > > +1 > > I tried several of the git tools and basically they all do the same, some > at a different level or different representations. There are a few > differences in features. > > Smalltalk has a long history in good tools. Also for versioning (ENVY comes to mind). > > I like that we can use git - but in the end I fear we somehow will come > to a point where it does not fit our needs or provide enough flexibility. That does > not mean that we should not use it. But we should be prepared with own tools as well. > > Bye > T. > +1

Dec. 2, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by Torsten Bergmann

Denis wrote: >>Kilon wrote: >>Smalltalk cannot even begin to compete with the tools and library support of these two behemoths programming languages. >>Â >Just for few cents. >If you group this million tools by logical functionality I'm sure it will be much less then smalltalk systems have. Most tools just repeat each other. And you >know most smalltalk development tools are absent in other systems. And every year when I read ESUG presentations I see another batch of new tools. I'm not see >such progress in another languages. Â +1 I tried several of the git tools and basically they all do the same, some at a different level or different representations. There are a few differences in features. Smalltalk has a long history in good tools. Also for versioning (ENVY comes to mind). I like that we can use git - but in the end I fear we somehow will come to a point where it does not fit our needs or provide enough flexibility. That does not mean that we should not use it. But we should be prepared with own tools as well. Bye T.

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

Le 02/12/2014 17:13, Yuriy Tymchuk a Ã©crit : > Hi Luc, > > most of these problems are solved by gitfiletree by Goubier Thierry. > It automatically commits the thing that you commit with Monticello, > it allows you to push, and it shows you the history (sometimes a bit > screwed, but good enough). ConfigurationOf works with GitHub > projects, but I think there is also something in a new Metacello that > I donât know about. If you find a strange history, can you share? It seems it happens, but I'm never sure. It handles fairly complicated cases (like the FileTree repository where, in some commits, you can't load the packages with filetree because they are broken: merge conflicts usually). > Big con is that you essentially communicate with git through > Monticello. And to doing advanced stuff, like a lot of branching, > pull requests and so on, gives an impression that you are always > hacking something. I think this is the git philosophy anyway. You need to go on expensive, entreprise versionning systems (ClearCase?) to have a very powerfull, yet still handholding system. Git is a hacker's tool. And git users are supposed (encouraged?) to hack it. > If you want to really work with git, you want to be able to have only > git versions of your code, stage and commit certain changes, > communicate with remote repos, and if something goes wrong talk to > command line and deal with file-based pharo representation. But > instead of this you have one more screen of Monticello + nasty > metadata which complicates merging. You need to use the merge driver for that, really. Ok, it requires a lot more polish than it has, but this is a larger, Pharo wide effort we need to plan for. The GitFileTree-MergeDriver was really a proof-of-concept which worked surprisingly well for the time I spent on it. Thierry > Uko > >> On 02 Dec 2014, at 17:00, Luc Fabresse <luc.fabresse(a)gmail.com> >> wrote: >> >> Hi, >> >> I continue the discussion here because I really would like to know >> the cons of using Git + Pharo. From kilon's video (thx) and the >> discussion that followed, I have the following questions about >> possible drawbacks of Git+Pharo: >> >> - The most important point to me is: does ConfigurationOf work >> correctly with a repo on GitHub for example? any example >> somewhere? >> >> - we should go to command line to commit/update but that could be >> saved with what has been done by Dale in tODE (shell integration, >> UI to commit, push/pull) IIUC. right? >> >> - Merging could be harder because it would rely on git tools? >> >> - opening a filetree repo in MC does not show the latest content >> since it is the local git repo that may not be in sync with the >> remote one => you should first pull the repo >> >> Thx for enlightening me, >> >> #Luc > > >

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Thierry Goubier

Le 02/12/2014 17:00, Luc Fabresse a Ã©crit : > Hi, > > I continue the discussion here because I really would like to know the > cons of using Git + Pharo. > From kilon's video (thx) and the discussion that followed, I have the > following questions about possible drawbacks of Git+Pharo: > > - The most important point to me is: does ConfigurationOf work correctly > with a repo on GitHub for example? any example somewhere? ConfigurationOfAltBrowser, ConfigurationOfSmaCC show how to load directly from a GitHub repository (or, in the case of SmaCC, load some versions from smalltalkhub, other from github, depending on the version you choose). But the best is the BaselineOf as explained by Dale, especially given that it can works with git tags (and github:// urls). gitfiletree:// urls are designed for development and to couple you with the github repository. > - we should go to command line to commit/update but that could be saved > with what has been done by Dale in tODE (shell integration, UI to > commit, push/pull) IIUC. right? Yes. Part of it has been automated via gitfiletree, but more should be done to automate. Still, it is reasonable to assume that you'll need access to git command line in real life, and integrating it as an embedded shell inside Smalltalk is a very nice way of handling it. > - Merging could be harder because it would rely on git tools? Not really if you use the merge driver. For a large merge, git-based tools are a lot faster than Monticello, except for the merge driver which slows done the process a bit (it's written in Pharo, Pharo startup time is significant, and it is called often by git during a merge). > - opening a filetree repo in MC does not show the latest content since > it is the local git repo that may not be in sync with the remote one => > you should first pull the repo Yes, you should be ready to pull (or pull often). But pull does a merge, so you have to know what you're doing: conflicts may appear on a pull. In a well organized multi-developper project, you'll work on a personal branch and conflicts won't happen. But git is designed in such a way that a git user can easily shot himself in the foot and create conflicts for his co-workers. git rebase is a good example of how to do that. > Thx for enlightening me, > > #Luc You're welcome, Thierry

Dec. 2, 2014

Re: [Pharo-dev] Pharo-dev Digest, Vol 19, Issue 151

by sheridan＠sheridan-mahoney.com

To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] contributing to Pharo testing effort Message-ID: <547332E2.4080107(a)openInWorld.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed sheridan(a)sheridan-mahoney.com wrote: >> Hi there, I am interested in helping out with writing tests in Pharo, >> and was wondering where would be a good place to start. I am familiar >> with Smalltalk from working at GemStone Systems in their QA department >> some years ago, but am somewhat new to Pharo. Any advice would be very >> appreciated. Best regards, Sheridan Mahoney > > I can't direct you to a particular area, but (not that I've used it) > maybe you can try out Hapao to see if it helps you pick where the gaps > are. > > http://www.pharocasts.com/2011/04/test-coverage-with-hapao.html [1] > > http://hapao.dcc.uchile.cl/ [2] > > http://objectprofile.com/Hapao.html [3] > > cheers -ben > > P.S. I wonder if it would be practical to generate some Hapao reports > on > each Pharo build as a CI job - to be available as a ready reference for > such questions? > > *************************** Links: ------ [1] http://www.pharocasts.com/2011/04/test-coverage-with-hapao.html [2] http://hapao.dcc.uchile.cl/ [3] http://objectprofile.com/Hapao.html Hi Ben, Thanks for the pointers. I'll take a look at Hapeo as you suggest. It seems like a great idea to get an overall sense of what's going on where before I start. Cheers, Sheri

Dec. 2, 2014

Re: [Pharo-dev] SmalltalkHub bugs & hangs :-(

by phil＠highoctane.be

On Tue, Dec 2, 2014 at 5:21 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2014-12-02 12:22 GMT+03:00 kilon alios <kilon.alios(a)gmail.com>: > >> True ? Smalltalk cannot even begin to compete with the tools and library >> support of these two behemoths programming languages. > > > > Just for few cents. > If you group this million tools by logical functionality I'm sure it will > be much less then smalltalk systems have. Most tools just repeat each > other. And you know most smalltalk development tools are absent in other > systems. And every year when I read ESUG presentations I see another batch > of new tools. I'm not see such progress in another languages. > Man, have had to debug some JavaScript of late, what I nightmarish experience... Phil

Dec. 2, 2014

Re: [Pharo-dev] Fwd: [squeak-dev] IdentitySet>>collect:

by Eliot Miranda

On Tue, Dec 2, 2014 at 1:20 AM, stepharo <stepharo(a)free.fr> wrote: > What is the old behavior? > These are from Smalltalk-80 v2 of April 1, 1983 on 31 May 1983 at 9:10:35 am Object methods for private species "Answer the preferred class for reconstructing the receiver. For example, collections create new collections whenever enumeration messages such as collect: or select: are invoked. The new kind of collection is determined by the species of the original collection. Species and class are not always the same. For example, the species of Interval is Array." ^self class Collection methods for enumerating collect: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect the resulting values into a collection that is like the receiver. Answer the new collection. " | newCollection | newCollection _ self species new. self do: [:each | newCollection add: (aBlock value: each)]. ^newCollection select: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect into a new collection like the receiver, only those elements for which aBlock evaluates to true. Answer the new collection." | newCollection | newCollection _ self species new. self do: [:each | (aBlock value: each) ifTrue: [newCollection add: each]]. ^newCollection Interval methods for private species ^Array But there are also already uses for comparing: CharacterBlock methods for comparing = aCharacterBlock self species = aCharacterBlock species ifTrue: [^stringIndex = aCharacterBlock stringIndex] ifFalse: [^false] Interval methods for comparing = anInterval "Answer true if my species and anInterval species are equal, and if our starts, steps and sizes are equal." self species == anInterval species ifTrue: [^start = anInterval first and: [step = anInterval increment and: [self size = anInterval size]]] ifFalse: [^false] However, the species comment clearly states the usage pattern, even though it fails to mention the intent (to provide a mutable container with which to derive a new collection from the original). > In addition it would be good to have tests for such core library. > + 1 Stef > > Le 1/12/14 11:44, Sven Van Caekenberghe a Ã©crit : > > > > Begin forwarded message: > > *From: *Bert Freudenberg <bert(a)freudenbergs.de> > *Subject: **Re: [squeak-dev] IdentitySet>>collect:* > *Date: *1 Dec 2014 11:35:00 CET > *To: *The general-purpose Squeak developers list < > squeak-dev(a)lists.squeakfoundation.org> > *Reply-To: *The general-purpose Squeak developers list < > squeak-dev(a)lists.squeakfoundation.org> > > On 01.12.2014, at 07:35, Colin Putney <colin(a)wiresong.com> wrote: > > > On Sun, Nov 30, 2014 at 6:20 AM, Bert Freudenberg <bert(a)freudenbergs.de> > wrote: > > >> How would you define âtypeâ here? Same class? >> > > Yes, same class. It might be reasonable to answer instances of analogous > classes for weak collections, and expect the caller to use #collect:as: if > they want to retain weakness. > > Colin > > > Thatâs certainly simple: > > âcollect: returns a collection of the same class as the receiver, > except for weak collections, which answer non-weak equivalents. To return a > collection of a different class, use collect:as:" > > - Bert - > > > The above definition makes perfect sense to me. The default should be > simple and predictable, the more complex and special cases can be handled > by a more convoluted API. > > And we should change callers that depend on the old behaviour. > > Sven > > > > > -- best, Eliot

Dec. 2, 2014

Re: [Pharo-dev] Fwd: [squeak-dev] IdentitySet>>collect:

by Eliot Miranda

On Tue, Dec 2, 2014 at 1:20 AM, stepharo <stepharo(a)free.fr> wrote: > What is the old behavior? > These are from Smalltalk-80 v2 of Object methods for private species "Answer the preferred class for reconstructing the receiver. For example, collections create new collections whenever enumeration messages such as collect: or select: are invoked. The new kind of collection is determined by the species of the original collection. Species and class are not always the same. For example, the species of Interval is Array." ^self class Collection methods for enumerating collect: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect the resulting values into a collection that is like the receiver. Answer the new collection. " | newCollection | newCollection _ self species new. self do: [:each | newCollection add: (aBlock value: each)]. ^newCollection select: aBlock "Evaluate aBlock with each of the receiver's elements as the argument. Collect into a new collection like the receiver, only those elements for which aBlock evaluates to true. Answer the new collection." | newCollection | newCollection _ self species new. self do: [:each | (aBlock value: each) ifTrue: [newCollection add: each]]. ^newCollection Interval methods for private species ^Array But there are also already uses for comparing: CharacterBlock methods for comparing = aCharacterBlock self species = aCharacterBlock species ifTrue: [^stringIndex = aCharacterBlock stringIndex] ifFalse: [^false] Interval methods for comparing = anInterval "Answer true if my species and anInterval species are equal, and if our starts, steps and sizes are equal." self species == anInterval species ifTrue: [^start = anInterval first and: [step = anInterval increment and: [self size = anInterval size]]] ifFalse: [^false] However, the species comment clearly states the usage pattern, even though it fails to mention the intent (to provide a mutable container with which to derive a new collection from the original). In addition it would be good to have tests for such core library. > +1 > > Stef > > Le 1/12/14 11:44, Sven Van Caekenberghe a Ã©crit : > > > > Begin forwarded message: > > *From: *Bert Freudenberg <bert(a)freudenbergs.de> > *Subject: **Re: [squeak-dev] IdentitySet>>collect:* > *Date: *1 Dec 2014 11:35:00 CET > *To: *The general-purpose Squeak developers list < > squeak-dev(a)lists.squeakfoundation.org> > *Reply-To: *The general-purpose Squeak developers list < > squeak-dev(a)lists.squeakfoundation.org> > > On 01.12.2014, at 07:35, Colin Putney <colin(a)wiresong.com> wrote: > > > On Sun, Nov 30, 2014 at 6:20 AM, Bert Freudenberg <bert(a)freudenbergs.de> > wrote: > > >> How would you define âtypeâ here? Same class? >> > > Yes, same class. It might be reasonable to answer instances of analogous > classes for weak collections, and expect the caller to use #collect:as: if > they want to retain weakness. > > Colin > > > Thatâs certainly simple: > > âcollect: returns a collection of the same class as the receiver, > except for weak collections, which answer non-weak equivalents. To return a > collection of a different class, use collect:as:" > > - Bert - > > > The above definition makes perfect sense to me. The default should be > simple and predictable, the more complex and special cases can be handled > by a more convoluted API. > > And we should change callers that depend on the old behaviour. > > Sven > > > > > -- best, Eliot

Dec. 2, 2014

Re: [Pharo-dev] Pharo+Git cons?

by Dale Henrichs

On Tue, Dec 2, 2014 at 8:00 AM, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi, > > I continue the discussion here because I really would like to know the > cons of using Git + Pharo. > From kilon's video (thx) and the discussion that followed, I have the > following questions about possible drawbacks of Git+Pharo: > > - The most important point to me is: does ConfigurationOf work correctly > with a repo on GitHub for example? any example somewhere? > When using git, you do not need to use a ConfigurationOf as all of the packages are versioned together so it isn't necessary to track individual mcz package versions ... you only really need a baseline to specify package/project dependencies. Instead of a ConfigurationOf you use a BaselineOf which has a single baseline: method[1]. The baseline: method is like any other baseline, except it isn't necessary to explicitly specify a repo - the repo used for the packages is the same one as the BaselineOf was loaded from. To load a baseline from a github repo you use an expression like the following: Metacello new baseline: 'Cryptography'; repository: 'github://GsDevKit/Cryptography:master/repository'; load: #('Cryptography') The :master in the repo specification can the name of a branch (master branch in this case), a SHA, a tag, or a tag pattern (1.1.? will load tags 1.1.0, 1.1.1, 1.1.2, etc.). To load from a local git clone (filetree repo) you use something like the following: Metacello new baseline: 'Cryptography'; repository: 'filetree:///opt/git/Cryptography/repository'; load: #('Cryptography') [1] https://github.com/GsDevKit/Cryptography/blob/master/repository/BaselineOfC… > > - we should go to command line to commit/update but that could be saved > with what has been done by Dale in tODE (shell integration, UI to commit, > push/pull) IIUC. right? > In tODE I've wrapped a large chunk of the shell command line git api with Smalltalk ... tODE has it's own command line, so git commands can be run from within tODE on the command line. Other tools make calls to he Smalltalk api. > > - Merging could be harder because it would rely on git tools? > When merging with git, you may be merging multiple packages plus doc files, etc., at once, so the tool required for merge must be built to work with git merge meta data ... there are external merge tools, but I built a merge tool in tODE that I actually prefer over the other available merge tools ... > - opening a filetree repo in MC does not show the latest content since it > is the local git repo that may not be in sync with the remote one => you > should first pull the repo > > This is actually an advantage ... when you have a local git clone, you control when and how projects are updated ... how many times have previously working build procedures suddenly stop working because someone has made a change to a configuration of a project? With local clones your environment is static and stable until you are ready to upgrade to a new version and then you do so in a controlled manner. If you use a spec like 'github://GsDevKit/Cryptography:master/repository', you are really using the latest version of master branch (bleeding edge for a remote repo)...In theory you can "require" that all tests pass before a change is merged into the master branch (using pull requests and travis-ci). so using the latest master branch should always be "safe". Dale

Dec. 2, 2014