[Pharo-dev] [Pharo 7.0] Build #147: Add scrollSelectionIntoView

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #147 was: SUCCESS.

The Pull Request #2428 was integrated: "Add scrollSelectionIntoView"
Pull request url: https://github.com/pharo-project/pharo/pull/2428

Issue Url: https://pharo.fogbugz.com/f/cases/patch
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/147/

Re: [Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

[Ben Coman]

On Tue, 5 Feb 2019 at 01:19, Andrei Chis  wrote:

> Hi,
>
> Currently in Iceberg to merge a branch into another, we need to checkout
> the branch into which we want to merge and then do the merge.
> Checking out a branch also updates the code in the image, which when
> needing to perform automatic releases on a branch can cause issues.
>
> Is there already a way in Iceberg to switch to a branch (for example
> `release`) and then merge another branch (for example `master`) into it
> without updating any code in the image?
> The use-case is that the user is on the `master` branch and needs to merge
> `master` into `release` without changing any code in the image.
>

Another use case for this might be where I recently wanted to resurrect an
old PR
to contribute to Pharo 8 and loading the old code broke the image.  I'd to
update the PR
by merging master into it without loading it.  Rebasing the old PR onto
master would be even better.

Perhaps the existing  button becomes a  button
and the  button presents a dialog for any any-to-any disc-only merge
(default would be "selected" commit into the image's "current" commit)

cheers -ben

Re: [Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?

[ducasse]

Thomas I asked Gina to rewrite it in Spec (but it can be too complex because 
the code
does not have a clear model) so if you want to help her, go ahead. 

Stef

> On 4 Feb 2019, at 11:47, Thomas Dupriez  wrote:
> 
> Hello,
> 
> The Process Browser does not auto-updates itself by default to show new 
> processes and hide processes that stopped.
> 
> Is there a specific reason for that? The first time I opened it I kind of 
> expected it would auto-update itself, and I think this may be a more 
> "intuitive" behaviour that no auto-updates by default. What do you think?
> 
> Getting auto-updates is "easy" (there is no button in the UI (something to 
> improve?), but one can call the "toggleAutoUpdate" method to get this 
> behaviour). My question is about it not being default.
> 
> Thomas
> 
> 

[Pharo-dev] iceberg: merging branches just at the git level without changing code in the image

[Andrei Chis]

Hi,

Currently in Iceberg to merge a branch into another, we need to checkout
the branch into which we want to merge and then do the merge.
Checking out a branch also updates the code in the image, which when
needing to perform automatic releases on a branch can cause issues.

Is there already a way in Iceberg to switch to a branch (for example
`release`) and then merge another branch (for example `master`) into it
without updating any code in the image?
The use-case is that the user is on the `master` branch and needs to merge
`master` into `release` without changing any code in the image.

I found LGitRepository>>#merge:, but it seems not to be used anywhere in
the image.

Another way would be to implement something like the method below. This:
  - calculates what changes need to be merged
  - always takes what is on the left branch (in this case what is on master
overrides what is on release)
  - does not call loadChangesInWorkingCopy: to update the working copy as
the code is already in the image
  - refreshes the dirty packages in case there are changes between what is
on the image and what is on disk

```
IceMerge>>#executeWithAcceptingLeftOnConflictAndWithoutImageUpdate
| commitToAdvance |
mergeCommit validateCanMerge.
self isAlreadyMerged ifTrue: [ ^ self ].

self calculateChanges.
self conflictsDo: [ :operation |
operation selectLeft.
].
commitToAdvance := self updateHead.
"Do not update the working copy"
"repository workingCopy loadChangesInWorkingCopy: self
changesToWorkingCopyTree."
repository workingCopy refreshDirtyPackages.
^ commitToAdvance
```

Could something like the above solution work? Or are there other issues to
take into account?

Cheers,
Andrei

Re: [Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?

[Alistair Grant]

On Mon, 4 Feb 2019 at 11:55, Sven Van Caekenberghe  wrote:
>
> I believe the reason not to make auto updating the default, is because 
> #updateProcessList is a bit heavy (it calls a GC, does an #allSubInstances, 
> and it is a thread itself). Maybe that is no longer the case ?
>
> But adding a button to make auto updating easier to start would probably help.
>
> Maybe a button bar for more common actions (like terminate) ?
>
> > On 4 Feb 2019, at 11:47, Thomas Dupriez  
> > wrote:
> >
> > Hello,
> >
> > The Process Browser does not auto-updates itself by default to show new 
> > processes and hide processes that stopped.
> >
> > Is there a specific reason for that? The first time I opened it I kind of 
> > expected it would auto-update itself, and I think this may be a more 
> > "intuitive" behaviour that no auto-updates by default. What do you think?
> >
> > Getting auto-updates is "easy" (there is no button in the UI (something to 
> > improve?), but one can call the "toggleAutoUpdate" method to get this 
> > behaviour). My question is about it not being default.

You can right click on a process and "Turn on auto-update", which is
Ctrl-A (on linux).

A button bar would be more friendly.

Cheers,
Alistair

Re: [Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?

[Sven Van Caekenberghe]

I believe the reason not to make auto updating the default, is because 
#updateProcessList is a bit heavy (it calls a GC, does an #allSubInstances, and 
it is a thread itself). Maybe that is no longer the case ?

But adding a button to make auto updating easier to start would probably help.

Maybe a button bar for more common actions (like terminate) ?

> On 4 Feb 2019, at 11:47, Thomas Dupriez  wrote:
> 
> Hello,
> 
> The Process Browser does not auto-updates itself by default to show new 
> processes and hide processes that stopped.
> 
> Is there a specific reason for that? The first time I opened it I kind of 
> expected it would auto-update itself, and I think this may be a more 
> "intuitive" behaviour that no auto-updates by default. What do you think?
> 
> Getting auto-updates is "easy" (there is no button in the UI (something to 
> improve?), but one can call the "toggleAutoUpdate" method to get this 
> behaviour). My question is about it not being default.
> 
> Thomas
> 
> 

[Pharo-dev] ProcessBrowser does not auto-update itself by default? Should it?

[Thomas Dupriez]

Hello,

The Process Browser does not auto-updates itself by default to show new 
processes and hide processes that stopped.


Is there a specific reason for that? The first time I opened it I kind 
of expected it would auto-update itself, and I think this may be a more 
"intuitive" behaviour that no auto-updates by default. What do you think?


Getting auto-updates is "easy" (there is no button in the UI (something 
to improve?), but one can call the "toggleAutoUpdate" method to get this 
behaviour). My question is about it not being default.


Thomas

[Pharo-dev] [Pharo 8.0] Build #51: OpalCompiler-Core spelling in class comment

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #51 was: SUCCESS.

The Pull Request #2436 was integrated: "OpalCompiler-Core spelling in class 
comment"
Pull request url: https://github.com/pharo-project/pharo/pull/2436

Issue Url: https://pharo.fogbugz.com/f/cases/patch
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/51/

Re: [Pharo-dev] ConfigurationOfGrease for Pharo8

[Guillermo Polito]

On Mon, Feb 4, 2019 at 9:28 AM Alistair Grant  wrote:

> Hi Stef,
> On Mon, 4 Feb 2019 at 09:20, ducasse  wrote:
> >
> > Hi alistair
> >
> > >> HI alistair
> > >>
> > >> you should use the latest pillar. Was dev-7 and now it is 70
> > >> because this is around six months that we removed the dependency to
> grease.
> > >
> > > I can see the dev-7 branch (which is what I'm using in Pharo 8).
> >
> >
> > And this is the one that broke? Strange.
> > Now we did not try Pillar in Pharo 80.
> > Could you try in Pharo70?
>
> No, the smalltalkhub version was "broken", but that's to be expected
> since it was out of date.
>
> The dev-7 branch loads fine in Pharo 8.
>
> > > But what do you mean by "now it is 70”?
> >
> > I thought that guillermo changed the dev-7 branch.
>

Nope, I think that name is good, and then we manage releases using tags. We
have the following branches:

[image: image.png]


> > Ok I checked and this is a tag. 7.4.1
>
> And that answers my question.
>
> Thanks,
> Alistair
>
>

-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] ConfigurationOfGrease for Pharo8

[Alistair Grant]

Hi Stef,
On Mon, 4 Feb 2019 at 09:20, ducasse  wrote:
>
> Hi alistair
>
> >> HI alistair
> >>
> >> you should use the latest pillar. Was dev-7 and now it is 70
> >> because this is around six months that we removed the dependency to grease.
> >
> > I can see the dev-7 branch (which is what I'm using in Pharo 8).
>
>
> And this is the one that broke? Strange.
> Now we did not try Pillar in Pharo 80.
> Could you try in Pharo70?

No, the smalltalkhub version was "broken", but that's to be expected
since it was out of date.

The dev-7 branch loads fine in Pharo 8.

> > But what do you mean by "now it is 70”?
>
> I thought that guillermo changed the dev-7 branch.
> Ok I checked and this is a tag. 7.4.1

And that answers my question.

Thanks,
Alistair

Re: [Pharo-dev] ConfigurationOfGrease for Pharo8

[ducasse]

Hi alistair

>> HI alistair
>> 
>> you should use the latest pillar. Was dev-7 and now it is 70
>> because this is around six months that we removed the dependency to grease.
> 
> I can see the dev-7 branch (which is what I'm using in Pharo 8).


And this is the one that broke? Strange. 
Now we did not try Pillar in Pharo 80. 
Could you try in Pharo70?

> But what do you mean by "now it is 70”?

I thought that guillermo changed the dev-7 branch.
Ok I checked and this is a tag. 7.4.1


> 
> Thanks,
> Alistair
> 

Re: [Pharo-dev] Esteban's ChangeLog week of 28 January 2019

[ducasse]

Great ChangeLog
Thanks esteban!



> On 4 Feb 2019, at 08:00, esteba...@gmail.com wrote:
> 
> Hello!
> 
> This is my weekly ChangeLog, from 28 January 2019 to 3 February 2019.
> You can see it in a better format by going here: 
> http://log.smallworks.eu/web/search?from=28/1/2019=3/2/2019
> 
> ChangeLog
> =
> 
> 30 January 2019:
> 
> 
> *Still more work for the 
> [PR](https://github.com/pharo-spec/Spec/pull/208) I submited yesterday. 
> 
>It is now ready to merge!
> 
> 
> 29 January 2019:
> 
> 
> *I made a [PR](https://github.com/pharo-spec/Spec/pull/208) that adds two 
> new elements to Spec 2:
> 
>1) SpecPanedLayout is a new layout that complements SpecBoxLayout:
> 
>A paned layout is like a Box Layout (it places childen in vertical or 
> horizontal fashion), but it will add a splitter in between, that user can 
> drag to resize the panel.
>In exchange, a paned layout can have just two children.
> 
>2) NotebookPresenter is a new implementation of a tab manager. Needed 
> because old one was not lazy, bad layouted 
>and too attached to Morphic (while we attempt to be more backend agnostic).
> 
>All of this is still WIP (there are missing functionality still), but what 
> is there is working fine :)
> 
> *I merged this 
> [PR](https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/362) from Pavel 
> to 
>improve keyboard handling on Windows VMs.
> 
> *Now that Pharo 7.0 is out, I started work on the Pharo 8.0 roadmap (that 
> I need to 
>send to the list, btw). 
> 
>Since some weeks I've been working on Spec2 (because we will need it 
> sooner than 
>expected and I wanted to make some progress on its general design and 
> needs). In Spec2, 
>some things will be enhanced, some others replaced and some other more 
> added from 
>scratch. 
> 
>I wanted to know mor more or less were we stand to do the job. 
> 
>Some work I've made (along with Cyril): 
> 
>1) Layouts will be revamped. Right now there is just one layout which is 
> overpowerful but hard 
>to use and too attached to morphic (and our goal is to be able to replace 
> the Morphic backend 
>with a Bloc backend). We decided to go for a different approach: instead 
> one layout that does
>all, having different layouts to fulfil different needs: 
>   - +SpecBoxLayout+ (rigid panes)
>   - +SpecPanedLayout+ (non rigid panes)
>   - +SpecGridLayout+ (form kind layout)
>   - +SpecFlowLayout+ (flowing components)
>   - +SpecXYLayout+ (rigid coordinates)
>   - And of course there will be need of a kasowary based layout. 
>   - ... ?
>   
>I already implemented +SpecBoxLayout+, +SpecPanesLayout+ and a preliminary 
> version od +SpecGridLayout+ :). 
>   
>2) Interpreter will be removed. Just the old layout makes it necessary 
> today, and it adds a 
>complexity we do not need.
> 
>3) We will add a +TablePresenter+ (a good one) and a +TreeTablePresenter+ 
> (again, a good one). 
>Old versions that try to fullfil same function will be deprecated. There 
> is already a functional 
>preliminary version of them :) 
> 
>4) We will add components for Numbers, Dates, etc. 
> (+NumberInputFieldPresenter+ is already implemented)
> 
>5) We will revisit all other components. 
> 
>As a roadmap, is pretty ambicious but is looking good so far :)
> 
> 
> cheers! 
> Esteban
>