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

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Esteban Lorenzano

> On 29 Jul 2017, at 10:07, Volkert <volkert(a)nivoba.de> wrote: > > Cool. How do i figure out, if i have installed 6.1? The Welcome Page shows 6.0? > > i used ... > wget -O- get.pharo.org/stable+vm | bash > Ubuntu 16.10 > LG, > > Volkert > yes, you have 6.1 believe it or not, the cost of doing a âproper releaseâ (changing all numbers. etc.) is too big to do it frequently. Thatâs why we do not do this more often (also this is one of the many reasons why we are changing our process: with PR system + bootstrap, produce correct version numbers will be a lot easier). Esteban > > On 24.07.2017 13:56, Esteban Lorenzano wrote: >> Hi, >> >> We are releasing Pharo 6.1. >> Usually, between each major version we just apply bugfixes changing the build number and not announcing new versions but this time is different since the fixes applied required a new VM. >> The principal reason for the new version is to update Iceberg support, bringing it to macOS 64bits version. >> >> So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: >> >> - running on macOS 64bits >> - adds cherry pick >> - adds major improvements on performance for big repositories >> - adds pull request review plugin >> - repositories browser: group branches by remote >> - adds bitbucket and gitlab to recognised providers on metacello integration >> - uses libgit v0.25.1 as backend >> - several bugfixes >> >> Other important change: >> >> - linux vm by default is now vm threaded heartbeat. >> >> We still miss 64bits Windows (sorry for that), but we are getting there. I hope to have it running right after ESUG. >> >> To download 6.1 version, you can go to http://pharo.org/download <http://pharo.org/download> page, or with zeroconf: >> >> wget -O- get.pharo.org <http://get.pharo.org/> | bash >> >> Enjoy! >> Esteban >

July 29, 2017

Re: [Pharo-dev] [ANN] Pharo 6.1 (summer) released!

by Volkert

Cool. How do i figure out, if i have installed 6.1? The Welcome Page shows 6.0? i used ... wget -O- get.pharo.org/stable+vm | bash Ubuntu 16.10 LG, Volkert On 24.07.2017 13:56, Esteban Lorenzano wrote: > Hi, > > We are releasing Pharo 6.1. > Usually, between each major version we just apply bugfixes changing > the build number and not announcing new versions but this time is > different since the fixes applied required a new VM. > The principal reason for the new version is to update Iceberg support, > bringing it to macOS 64bits version. > > So, now Pharo 6.1 comes with Iceberg 0.5.5, which includes: > > - running on macOS 64bits > - adds cherry pick > - adds major improvements on performance for big repositories > - adds pull request review plugin > - repositories browser: group branches by remote > - adds bitbucket and gitlab to recognised providers on metacello > integration > - uses libgit v0.25.1 as backend > - several bugfixes > > Other important change: > > - linux vm by default is now vm threaded heartbeat. > > We still miss 64bits Windows (sorry for that), but we are getting > there. I hope to have it running right after ESUG. > > To download 6.1 version, you can go to http://pharo.org/download page, > or with zeroconf: > > wget -O- get.pharo.org <http://get.pharo.org> | bash > > Enjoy! > Esteban

July 29, 2017

Re: [Pharo-dev] [ANN] Mustache moved to github

by Torsten Bergmann

Hi Norbert, I manage some of my projects already in GitHub. For example Tealight which is also in catalog. Anything you have to do is 1) to create a "tag" in git (see https://stackoverflow.com/questions/18216991/create-a-tag-in-github-reposit…) I name the tags with the according version number like 0.0.2 following semantic versioning (http://semver.org) 2) provide a ConfigurationOf (as you had in the past) where the "version" references the "git tag" with the same name a) also #stable has to point to the "version" as it was in the past optional: b) the #development should point to the Baseline in the git branch that you typically use for development (this allows for loading of bleeding edge as before) 3) upload the Configuration to a MetaRepo as before to appear in catalog Example: ======= 1) I have two tagged versions for Tealight on Git (0.0.1 and 0.0.2) https://github.com/astares/Tealight/releases 2) In my ConfigurationOfTealight (which I also manage in git) I reference the tag, for example in version 0.0.2 I reference the tag with the same name "github://astares/Tealight:0.0.2/repository": See https://github.com/astares/Tealight/blob/master/repository/ConfigurationOfT… Side note: a) now you can use your #stable definition in the ConfigurationOf as before https://github.com/astares/Tealight/blob/master/repository/ConfigurationOfT… b) Your #development definition should point to the master branch (or whatever the development branch is) https://github.com/astares/Tealight/blob/master/repository/ConfigurationOfT… https://github.com/astares/Tealight/blob/master/repository/ConfigurationOfT… 3) http://smalltalkhub.com/#!/~Pharo/MetaRepoForPharo60/packages/Configuration… Iceberg is managed in a similar way (but is now included in the image and the catalog part is only for compatibility). Hope this helps. Thanks Torsten > Gesendet: Freitag, 28. Juli 2017 um 14:13 Uhr > Von: "Norbert Hartl" <norbert(a)hartl.name> > An: "Pharo Dev" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] [ANN] Mustache moved to github > > I don't know how. I must say that it is not clear to me what to do. Do I need a configuration? Do I still need to put it in Metarepo? > > Norbert > > > > Am 28.07.2017 um 14:06 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > > > Hi norbert > > > > did you update the catalog entry? > > > > Stef > > > > On Fri, Jul 28, 2017 at 12:40 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> In the spirit of git notificationâ¦I moved mustache to github. > >> > >> https://github.com/noha/mustache > >> > >> Enjoy! > >> > >> Norbert > >> > >> > >

July 29, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-07-28 23:13 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >>> >>> 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>> >>>> >>>> >>>> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>>> >>>>> What is the system you use? >>>>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work >>>>> on Windows... >>>>> >>>>> -- Pavel >>>>> >>>> >>>> windows 10 32 bit >>>> >>> >>> and on another windows 10 64 bit system >>> >>> on both, it crashes on working with libgit/iceberg >>> >> >> >> Any news ? >> Anyone got a working libgit/iceberg for windows 32 or windows 64 ? >> >> Or is there any other way to be up to date with fixes, doing reviews and >> bug fixes (without using github in the web browser) ? >> > > Now, I tried again with the latest vm/image version and I get this error > > LGit_GIT_ERROR: username does not match previous request' > > Any idea ? > > I used my git username in the ssh settings. If I use "git" as username for the ssh setting, it complains about failed to authenticate SSH session How do other windows users use all this for pharo 7, any windows user how can write a little howto ?

July 28, 2017

Re: [Pharo-dev] Pharo 7 provisional HOWTO

by Nicolai Hess

2017-07-24 9:45 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > > > 2017-07-11 12:46 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2017-07-11 12:44 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >> >>> >>> >>> 2017-07-11 12:28 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> >>>> What is the system you use? >>>> AFAIK Esteban is fixing the latest Iceberg because it stopped to work >>>> on Windows... >>>> >>>> -- Pavel >>>> >>> >>> windows 10 32 bit >>> >> >> and on another windows 10 64 bit system >> >> on both, it crashes on working with libgit/iceberg >> > > > Any news ? > Anyone got a working libgit/iceberg for windows 32 or windows 64 ? > > Or is there any other way to be up to date with fixes, doing reviews and > bug fixes (without using github in the web browser) ? > Now, I tried again with the latest vm/image version and I get this error LGit_GIT_ERROR: username does not match previous request' Any idea ? > > >> >> >>> >>> >>>> >>>> 2017-07-10 22:01 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>> >>>>> >>>>> >>>>> 2017-07-03 23:17 GMT+02:00 Nicolai Hess <nicolaihess(a)gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> 2017-06-28 18:25 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> >>>>>>> >>>>>>> On 28 Jun 2017, at 18:21, Nicolai Hess <nicolaihess(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> And if I only want to contribute by reviewing a fix. Do I have to go >>>>>>> the git-path ? >>>>>>> Or is there a way to just start up an image and load and review the >>>>>>> change? >>>>>>> >>>>>>> >>>>>>> right now, you can review by going to github and seeing. >>>>>>> I will add a âPR toolâ to view/load PRs into an image, but thatâs >>>>>>> not ready. If someone wants to take a hit on itâ¦ the idea is to extend the >>>>>>> github plugin with it :) >>>>>>> >>>>>>> cheers! >>>>>>> Esteban >>>>>>> >>>>>> >>>>>> Anyone got this working on windows (32) ? >>>>>> I followed this guide, enabled the ssh key setting for iceberg. >>>>>> But I still got the error : >>>>>> >>>>>> Image: Pharo7.0SNAPSHOT [Latest update: #0] >>>>>> >>>>>> LGitReturnCodeEnum>>handleLGitReturnCode >>>>>> Receiver: a LGitReturnCodeEnum(#git_error [-1]) >>>>>> Arguments and temporary variables: >>>>>> handler: LGit_GIT_ERROR >>>>>> Receiver's instance variables: >>>>>> value: -1 >>>>>> >>>>>> >>>>>> LGitRepository(LGitExternalObject)>>withReturnHandlerDo: >>>>>> Receiver: a LGitRepository (<not initialized>) >>>>>> Arguments and temporary variables: >>>>>> callBlock: [ self >>>>>> clone: self >>>>>> url: aString >>>>>> local_path: aFileReference pathSt...etc... >>>>>> Receiver's instance variables: >>>>>> handle: @ 16r00000000 >>>>>> repositoryPath: File @ pharo-core >>>>>> isOpen: nil >>>>>> workingDirectory: nil >>>>>> >>>>>> >>>>>> LGitRepository>>clone:options:to: >>>>>> Receiver: a LGitRepository (<not initialized>) >>>>>> Arguments and temporary variables: >>>>>> aString: 'git@github.com:pharo-project/pharo.git' >>>>>> cloneOptions: a LGitCloneOptions () >>>>>> aFileReference: File @ pharo-core >>>>>> Receiver's instance variables: >>>>>> handle: @ 16r00000000 >>>>>> repositoryPath: File @ pharo-core >>>>>> isOpen: nil >>>>>> workingDirectory: nil >>>>>> >>>>>> >>>>>> And finally after some more tries, the vm crashed >>>>>> (crash.dmp attached). >>>>>> >>>>>> If this only happens on windows, what else would be an option to >>>>>> start with contributing for pharo 7 ? >>>>>> >>>>> >>>>> maybe I am doing something wrong ? I thought this should work now with >>>>> the latest vm (and libgit)? >>>>> It is still crashing for me. >>>>> >>>>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class >>>>> failed >>>>> [0mExternalAddress class(Object)>>primitiveFailed: >>>>> ExternalAddress class(Object)>>primitiveFailed >>>>> ExternalAddress class>>allocate: >>>>> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >>>>> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >>>>> LGitRemoteCallbacks class>>defaults >>>>> LGitRemoteCallbacks class>>withProvider: >>>>> LGitCloneOptions class>>withCredentialsProvider: >>>>> [ | repo cloneOptions | >>>>> repo := LGitRepository on: self location. >>>>> cloneOptions := LGitCloneOptions >>>>> withCredentialsProvider: IceCredentialsProvider default. >>>>> repo clone: url options: cloneOptions. >>>>> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >>>>> (LGitRemote of: repo named: 'origin') >>>>> lookup; >>>>> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >>>>> in Block: [ | repo cloneOptions |... >>>>> [ self checkInitialized. >>>>> [31mPrimitiveFailed: primitive #allocate: in ExternalAddress class >>>>> failed >>>>> [0mExternalAddress class(Object)>>primitiveFailed: >>>>> ExternalAddress class(Object)>>primitiveFailed >>>>> ExternalAddress class>>allocate: >>>>> LGitRemoteCallbacks class(FFIExternalStructure class)>>externalNew >>>>> LGitRemoteCallbacks class(LGitStructWithDefaults class)>>defaults >>>>> LGitRemoteCallbacks class>>defaults >>>>> LGitRemoteCallbacks class>>withProvider: >>>>> LGitCloneOptions class>>withCredentialsProvider: >>>>> [ | repo cloneOptions | >>>>> repo := LGitRepository on: self location. >>>>> cloneOptions := LGitCloneOptions >>>>> withCredentialsProvider: IceCredentialsProvider default. >>>>> repo clone: url options: cloneOptions. >>>>> aBranchName ifNotNil: [ repo checkout: aBranchName ]. >>>>> (LGitRemote of: repo named: 'origin') >>>>> lookup; >>>>> setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >>>>> in Block: [ | repo cloneOptions |... >>>>> [ self checkInitialized. >>>>> aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self >>>>> checkInitialized.... >>>>> [ activeProcess psValueAt: index put: anObject. >>>>> aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: >>>>> in Block: [ activeProcess psValueAt: index put: anObject.... >>>>> BlockClosure>>ensure: >>>>> LGitActionSequence(DynamicVariable)>>value:during: >>>>> LGitActionSequence class(DynamicVariable class)>>value:during: >>>>> LGitGlobal class>>runSequence: >>>>> IceLibgitLocalRepository>>cloneRepositoryFrom:branch: >>>>> IceRepositoryCreator>>createRepository >>>>> UndefinedObject>>DoIt >>>>> >>>>> VM windows 32 bit: >>>>> CoInterpreter VMMaker.oscog-eem.2252 uuid: >>>>> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 >>>>> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >>>>> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 10 2017 >>>>> VM: 201707101916 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >>>>> $ Date: Mon Jul 10 12:16:58 2017 -0700 $ Plugins: 201707101916 >>>>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> Am 28.06.2017 5:26 nachm. schrieb "Pavel Krivanek" < >>>>>>> pavel.krivanek(a)gmail.com>: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-06-28 17:06 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Just to be clear, in Pharo 7, if I want to get some code integrated: >>>>>>>> - I *have to* use the pull request process described by Pavel >>>>>>>> OR >>>>>>>> - I *can* use the pull request process, but I can also use the old >>>>>>>> slice monticello process >>>>>>>> ? >>>>>>>> >>>>>>>> What is the answer to the first question now, and what will be the >>>>>>>> answer of this question in 6 months from now ? >>>>>>>> >>>>>>> >>>>>>> You should use the pull request process. >>>>>>> >>>>>>> It is possible to create a standard slice BUT it must be done from >>>>>>> Pharo 6 and then sent into Pharo60Inbox. And then you need to wait until >>>>>>> somebody converts this slice to pull request. That means that it will be >>>>>>> harder and harder to contribute this way because the code-base is moving. >>>>>>> >>>>>>> No slice will be integrated into Pharo 7 with the old process >>>>>>> directly. >>>>>>> >>>>>>> Cheers, >>>>>>> -- Pavel >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 28, 2017 at 3:42 PM, Ben Coman <btc(a)openinworld.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Jun 28, 2017 at 3:46 PM, Juraj Kubelka < >>>>>>>>> juraj.kubelka(a)icloud.com> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> El 28-06-2017, a las 02:57, Ben Coman <btc(a)openinworld.com> >>>>>>>>>> escribiÃ³: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jun 27, 2017 at 10:35 PM, Pavel Krivanek < >>>>>>>>>> pavel.krivanek(a)gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2017-06-27 16:17 GMT+02:00 Serge Stinckwich < >>>>>>>>>>> serge.stinckwich(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 27, 2017 at 3:10 PM, Pavel Krivanek >>>>>>>>>>>> <pavel.krivanek(a)gmail.com> wrote: >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > 2017-06-27 15:57 GMT+02:00 Serge Stinckwich < >>>>>>>>>>>> serge.stinckwich(a)gmail.com>: >>>>>>>>>>>> >> >>>>>>>>>>>> >> On Mon, Jun 26, 2017 at 12:14 PM, Pavel Krivanek >>>>>>>>>>>> >> <pavel.krivanek(a)gmail.com> wrote: >>>>>>>>>>>> >> > Hi, >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > this mail describes how to start to send pull requests to >>>>>>>>>>>> Pharo 7 Github >>>>>>>>>>>> >> > repository from Pharo 7. >>>>>>>>>>>> >> >>>>>>>>>>>> >> Thank you for the great explanation Pavel. >>>>>>>>>>>> >> >>>>>>>>>>>> >> > Preparations >>>>>>>>>>>> >> > ===================== >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > - you need to have a Github account and set SSH keys. See >>>>>>>>>>>> >> > https://help.github.com/articl >>>>>>>>>>>> es/connecting-to-github-with-ssh/ >>>>>>>>>>>> >> > - create own pharo-project/pharo repository fork. Go to >>>>>>>>>>>> >> > https://github.com/pharo-project/pharo, click on "Fork" >>>>>>>>>>>> button and >>>>>>>>>>>> >> > follow >>>>>>>>>>>> >> > the instructions >>>>>>>>>>>> >> >>>>>>>>>>>> >> [ ... ] >>>>>>>>>>>> >> >>>>>>>>>>>> >> > Issue processing >>>>>>>>>>>> >> > ===================== >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > - create new case on FogBugz to get the issue number >>>>>>>>>>>> >> > - open Iceberg and from the context menu on the 'pharo' >>>>>>>>>>>> repository do: >>>>>>>>>>>> >> > Pharo >>>>>>>>>>>> >> > - Create new branch from FogBugz issue, enter the issue ID >>>>>>>>>>>> and it will >>>>>>>>>>>> >> > fill >>>>>>>>>>>> >> > the full branch name for you >>>>>>>>>>>> >> > - create your changes (you can do it before the creation >>>>>>>>>>>> of the branch >>>>>>>>>>>> >> > too) >>>>>>>>>>>> >> > - commit and push your changes in Iceberg, this way you >>>>>>>>>>>> will commit your >>>>>>>>>>>> >> > branch to your fork repository. Remember that the Iceberg >>>>>>>>>>>> commit window >>>>>>>>>>>> >> > has >>>>>>>>>>>> >> > two buttons, one for local commit, the second for commit >>>>>>>>>>>> with immediate >>>>>>>>>>>> >> > push. They can be very long because they contain the full >>>>>>>>>>>> branch (issue) >>>>>>>>>>>> >> > name >>>>>>>>>>>> >> > - in Iceberg in the 'pharo' repository context menu do: >>>>>>>>>>>> Pharo - Create >>>>>>>>>>>> >> > pull >>>>>>>>>>>> >> > request, fill your >>>>>>>>>>>> >> > - fill your Github credentials >>>>>>>>>>>> >> > - leave the PR title, comment is not required, check the >>>>>>>>>>>> pull request >>>>>>>>>>>> >> > head >>>>>>>>>>>> >> > and base. The base MUST be pharo-project/pharo >>>>>>>>>>>> development. Create the >>>>>>>>>>>> >> > pull >>>>>>>>>>>> >> > requests >>>>>>>>>>>> >> > - go to https://github.com/pharo-project/pharo/pulls, >>>>>>>>>>>> check your pull >>>>>>>>>>>> >> > requests and put URL of it into the issue record on >>>>>>>>>>>> FogBugz (as a >>>>>>>>>>>> >> > comment). >>>>>>>>>>>> >> > Resolve the issue as Fix review needed >>>>>>>>>>>> >> >>>>>>>>>>>> >> It means, there is no PR without a corresponding FogBugz >>>>>>>>>>>> issue ? >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > Yes, at least for code changes we would like to keep this >>>>>>>>>>>> relation. If it is >>>>>>>>>>>> > a really trivial change in readme or something like that, we >>>>>>>>>>>> can accept no >>>>>>>>>>>> > related issue record. >>>>>>>>>>>> > Please prefer to comment the issues instead of PRs directly >>>>>>>>>>>> to have all >>>>>>>>>>>> > information at one place. >>>>>>>>>>>> >>>>>>>>>>>> Thank you Pavel for the explanation. >>>>>>>>>>>> >>>>>>>>>>>> Maybe in the future, it will make sense to put everything in >>>>>>>>>>>> the PR >>>>>>>>>>>> and use github issues. >>>>>>>>>>>> You will use CI travis builds for all PR ? >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> For now we will use FogBugz because it has a lot of nice >>>>>>>>>>> features and good API. Maybe we will switch it in future but now we should >>>>>>>>>>> not change too many things at once :-) >>>>>>>>>>> For several reasons we now prefer to use own infrastructure for >>>>>>>>>>> checking of PRs (mainly because of MacOS issues on Travis). But again, it >>>>>>>>>>> can be changed in future. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> It would be interesting to see how this might fit in with our >>>>>>>>>> workflow... >>>>>>>>>> https://blog.fogcreek.com/fogbugz-github-integration/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What is the benefit of the integration? I do not understand it >>>>>>>>>> from the given link. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> When you submit a PR on github, Fogbugz is automatically updated >>>>>>>>> with a link to the PR. >>>>>>>>> Presumably this makes it easier for people reviewing cases in >>>>>>>>> Fogbugz to identify the slice to test. >>>>>>>>> This is a better link... >>>>>>>>> https://blog.fogcreek.com/improved-github-integration-automa >>>>>>>>> tically-create-bug-events-with-commits/ >>>>>>>>> >>>>>>>>> cheers -ben >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >

July 28, 2017

Re: [Pharo-dev] [ANN] Mustache moved to github

by Tim Mackinnon

If I've understood correctly, this means you can rage master with a version number like v1.1 and then put that in the URL > https://github.com/peteruhnak/IconFactory/tree/master:v1.1/ Tim Sent from my iPhone > On 28 Jul 2017, at 14:59, Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > ConfigurationOf still remains (for the time-being), however now you don't have to specify what packages and their commits to load for each version. > > Instead you point to a Baseline with a specific version. > > E.g. > > https://github.com/peteruhnak/IconFactory/tree/master/repository/Configurat… > > > the syntax for the repo is 'github://<user>/<project>:<branch name or commit id or tag id>/<optional subfolder where the packages are>' > > (the branch is optional, and if ommitted the latest commit of the master branch will be used) > > > Peter > > > >> On Fri, Jul 28, 2017 at 02:48:08PM +0200, Denis Kudriashov wrote: >> In my projects I defined configuration with single stable which points to >> baseline master: >> >> stable: spec >> <symbolicVersion: #stable>. >> spec for: #'pharo' version: 'master' >> >> master: spec >> <version: 'master'> >> spec for: #pharo do: [ >> spec >> baseline: 'Mustache' >> with: [ spec repository: 'github://noha/mustache' ]; >> import: 'Mustache' ] >> >> And I am supposed that master will be always stable. >> >> 2017-07-28 14:13 GMT+02:00 Norbert Hartl <norbert(a)hartl.name>: >> >>> I don't know how. I must say that it is not clear to me what to do. Do I >>> need a configuration? Do I still need to put it in Metarepo? >>> >>> Norbert >>> >>> >>>> Am 28.07.2017 um 14:06 schrieb Stephane Ducasse <stepharo.self(a)gmail.com >>>> : >>>> >>>> Hi norbert >>>> >>>> did you update the catalog entry? >>>> >>>> Stef >>>> >>>> On Fri, Jul 28, 2017 at 12:40 PM, Norbert Hartl <norbert(a)hartl.name> >>> wrote: >>>>> In the spirit of git notificationâ¦I moved mustache to github. >>>>> >>>>> https://github.com/noha/mustache >>>>> >>>>> Enjoy! >>>>> >>>>> Norbert >>>>> >>>>> >>> >>> >

July 28, 2017

Re: [Pharo-dev] WorkingSession log

by Christophe Demarey

> Le 28 juil. 2017 Ã 10:14, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > >> >> On 28 Jul 2017, at 09:56, Christophe Demarey <christophe.demarey(a)inria.fr> wrote: >> >> Hi Sven, >> >>> Le 27 juil. 2017 Ã 14:49, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : >>> >>> Hi, >>> >>> I instrumented WorkingSession with a log collection that holds timing info for each #startUp: executed. In a clean Pharo 6 image, 62 were run. Most of them resulted in a 0ms execution time (#millisecondsToRun: i.e. they were faster than 1ms). Here is the list of the non zero ones: >>> >>> 1ms startup:true a ClassSessionHandler(ProcessorScheduler) >>> 1ms startup:true a ClassSessionHandler(OSPlatform) >>> 6ms startup:true a ClassSessionHandler(ExternalObject) >>> 1ms startup:true a ClassSessionHandler(DiskStore) >>> 5ms startup:true a ClassSessionHandler(SmalltalkImage) >>> 9ms startup:true a ClassSessionHandler(DisplayScreen) >>> 1ms startup:true a ClassSessionHandler(Cursor) >>> 41ms startup:true a ClassSessionHandler(FT2Handle) >>> 238ms startup:true a ClassSessionHandler(FreeTypeSettings) >>> 1ms startup:true a ClassSessionHandler(WorldMorph) >>> 14ms startup:true a ClassSessionHandler(OmSessionStore) >>> >>> For a total of 318ms >>> >>> I think being able to inspect the WorkingSession and see this list (ordered, with timing info) would be generally useful (and low cost). Even headless, we could access the list using eval. >> >> Yes, it is a nice feature. > > I basically did something similar to what Phil/Clement seem to have done: > > - added a local instance variable #log to WorkingSession holding an OrderedCollection > - instrument #runStartup: and #executeDeferredStartupActions: like this > > runStartup: isImageStarting > self > runList: manager startupList > do: [ :each | | ms | > ms := Time millisecondsToRun: [ each startup: isImageStarting ]. > log add: { ms. #startup:. isImageStarting. each } ]. > self executeDeferredStartupActions: isImageStarting > > but if we do this for real, we better use a real object (like a log event, like SessionActionExecuted) > >> Do you have the same thing for #shutdown: ? > > I considered that, but if the session shuts down, it will disappear, hence the log will be lost, no ? Yes, an option could be to keep an history of sessions (or just the last one?) > Unless we also write it (optionally) to a file. That is difficult because while the shutdown list is processed, you loose functionalities and FileSystem is one of them. > >>> Sven >>> >>> PS: The code of SessionManager/WorkingSession was very readable, well done Christophe ! >> >> Thanks but then you should also thanks Guille and Pablo as it was a joint work ;) > > Thank you Guille and Pablo !!

July 28, 2017

Epicea: Revert the removal of a class

by Cyril Ferlicot D.

Hi, Today I tried to remove a class, go in Epicea and revert the removal of the class. At the end the class was here but with no methods. Is that the normal behaviour? I think it is a bug but since I don't really use Epicea a lot for know I am not sure. Have a nice day. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Thierry Goubier

2017-07-28 16:11 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > >> But I understand what you are talking about. So it will be >>> pre-refactoring on current scope (full image by default). >>> And change browser will allow choose different scope which will >>> reevaluate refactoring again and update shown changes. >> >> > Understood. Will enlarging the original scope be possible? > > > Yes. > When new method browser is spawned it includes all scopes of original > browser. > If you spawn senders from class references which are restricted by package > then new browser will show senders in scope of this package. But it will > also include all scopes of original browser in scopes list. So you are > always able switch to full image or other scope which you are used in other > "parent windows". > I'll be interested by first impressions (first few times trying it) / expert impressions (once comfortable working with it) with this feature. Who has already switched to Calypso as it's main / only system browser? Regards, Thierry

July 28, 2017

Re: [Pharo-dev] [Ann] Calypso is moved to github

by Denis Kudriashov

> But I understand what you are talking about. So it will be pre-refactoring >> on current scope (full image by default). >> And change browser will allow choose different scope which will >> reevaluate refactoring again and update shown changes. > > Understood. Will enlarging the original scope be possible? Yes. When new method browser is spawned it includes all scopes of original browser. If you spawn senders from class references which are restricted by package then new browser will show senders in scope of this package. But it will also include all scopes of original browser in scopes list. So you are always able switch to full image or other scope which you are used in other "parent windows".

July 28, 2017