Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Esteban Maringolo]

Isn't working with "core projects" in the Pharo repository an actual fork
of each project?
One thing is "Kernel" (which is seldom committed outside of the context of
the Pharo repo) and another one is Calypso/Iceberg/Zinc, etc.

What's the practical difference (in terms of code) between such a fork and
depending on a particular commit/tag of the referenced project?

ps: These are honest, maybe naive, questions, so please answer accordingly.

Esteban A. Maringolo

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Stephane Ducasse]

> It is not so easy.
>
> A huge project as Pharo would profit to be split in order to manage its parts 
> correctly. For example, we recently released iceberg 1.3.0. And there were 
> some problems around and we evaluate the possibility of revert that release 
> until we fix the problems. At the end, problems were not so important and the 
> fix was made with a 1.3.1 release and almost immediately an 1.4.0.

This is because you want to see it like that.
Now issuing a new version of iceberg would just be integrated a branch
into Pharo. So I do not see why you could not commit to a branch and
work there
for Iceberg. Sorry but I do not buy your argument.
Why you want to have all the plugin of the VM at the same place and
not the core Pharo tool?

The message is clear to me: I will not work on Pharo because I cannot.
You will show me how you do that trivially stupid bug fix without
several PR AND synchronisation point!!
Because if you do not see that the synchronisation point between a PR
in project and a PR in Pharo will kill us.
What can I say. Nothing I will shut up but do not ask my support for
anything in the future.
Sorry to be aggressive but this week I could have fixed several
totally totally stupid glitches and I could not
You will have to prove me that I'm wrong:
https://pharo.fogbugz.com/f/cases/22626/Should-not-hardcode-CmdCommandAborted

And at the end, you will win and I will let you play with your process.
And I will not work on Pharo.


> Now, imagine If iceberg would be integrated in pharo.
>
> 1. The nature of “iceberg” would be lost in other parts. We cannot talk 
> anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way 
> to know what changed in Iceberg without digging in the full list of changes.
> 2. If we need to revert. How do we do it? There is no release so what do we 
> revert? A commit? How many commits? How do we revert if development tree 
> continued growing and iceberg commit are now mixed with others?
> Of course, we could maintain a branch. But then I'd argüe is more or less the 
> same as having a separated project.
>
> Situation is not ideal (even if it is a lot better as before).

How better? We cannot fix simple crosscutting things in subparts of Pharo?


> But I’m envisioning this solution: add multiple source directories capability.

This does not resolve the synchronisation point.
And I do not see how it helps other projects like Moose with multiple
repo so we lose on two sides.
1 Too complex for Pharo core and 2 not helping projects build out of
external projects.

I think that we should work on more important things instead of
building our own new problems. (cleaning, better tools, Cargo,
headless, better VM, Modules?)
Merging the Pharo core projects would solved the first (1) problem above.

But you are right let us look smart and increase the entropy for the
sake of it.
It will be without me. I started and I will not read bug entries and
PR anymore.
If doing nothing is the way to get heard then I will do nothing
because I'm hurt each time I want to do something and I have enough.


> Then we can have:
>
> src/kernel
> src/system
> src/spec
> src/iceberg
> src/calypso
> etc.
>
> This will not just help to improve modularisation but we’ll gives a “free” 
> feature : using git subtree to manage those directories.

I do not believe you. If that would be so easy why Pablo and Guille
would tell me that this is around 8 months of work?
Seriously.



> For those who do not know: subtree allow us to merge different project trees 
> into one. But the important part is how it will behave in Pharo (or other 
> projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one 
> single commit will spread to all repositories.
> Now, the “price to pay” later is that time to time we need to push subtree 
> from Pharo to their external projects (but this can be automated easily), and 
> of course, doing “an iceberg release” means to do a pull subtree from 
> external repository to Pharo (also very easy).
>
> Esteban
>
> Ps: remember: programming is an iterative improving process. “Process" is 
> part of programming so iterations applies to it too.
>
> > On 7 Nov 2018, at 07:02, Tim Mackinnon  wrote:
> >
> > It’s a tricky trade off as Norbert alludes too - in my recent example I 
> > needed some underlying base pieces in place (for the compiler’s ast) and 
> > those needed reviewing to then be committed - then there were two parts to 
> > Calypso that relied on those changes) that also needed reviewing and I 
> > wasn’t sure if Denis waited for the core approval or loaded up my PR - but 
> > anyway it took him a bit of time to process that and he came back with some 
> > better suggestions that I also needed to implement (which I had to find 
> > time to do as well).
> >
> > When I noticed that the core Pharo pieces were merged, I then had to chase 
> > Denis to see if he was now happy and could merge my changes.
> >
> > I guess it would be helpful if 

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

[Alistair Grant]

Hi Marcus,

On Wed, 7 Nov 2018 at 14:27, Marcus Denker  wrote:
>
>
>
> > On 7 Nov 2018, at 13:56, Alistair Grant  wrote:
>
> ...
>
> > Good point.  How to get a list of all the methods that have MetaLinks?
> > The following seems to work, but probably isn't the most efficient:
> >
> > Object allSubclasses flatCollect: [ :each | each methods select: [
> > :method | method ast links isNotNil ] ]
> >
>
> you can ask the method directly
>
> Object allSubclasses flatCollect: [ :each | each methods select: [
> :method | method hasLinks ] ]
>
> this is much faster as it returns immediately nil for methods without links  
> (without AST reification).

Thanks!

Cheers,
Alistair

[Pharo-dev] [Pharo 7.0-dev] Build #1372: 22638-usage-of-readlink-f-breaks-macOS-bootstrap

[ci-pharo-ci-jenkins2]

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

The Pull Request #1958 was integrated: 
"22638-usage-of-readlink-f-breaks-macOS-bootstrap"
Pull request url: https://github.com/pharo-project/pharo/pull/1958

Issue Url: https://pharo.fogbugz.com/f/cases/22638
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1372/

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

[Eliot Miranda]

On Wed, Nov 7, 2018 at 6:28 AM Eliot Miranda 
wrote:
[snip]

> Forgive me, but may I beg you to post the text of stack back traces in
> future not screenshots?  The screenshots have two major disadvantages; a)
> they're huge and b) one cannot search email messages for the text they
> contain.  You can use e.g. shell level tools to copy the text, eg from the
> terminal or from the console.
>

i.e.:

Your mail to 'Pharo-dev' with the subject

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

Is being held until the list moderator can review it for approval.

The reason it is being held:

Message body is too big: 1522650 bytes with a limit of 1000 KB

[snip]

_,,,^..^,,,_
best, Eliot

[Pharo-dev] [Pharo 7.0-dev] Build #1371: 22641-Semantic-analysis-needs-to-take-instead-preambles-into-account

[ci-pharo-ci-jenkins2]

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

The Pull Request #1960 was integrated: 
"22641-Semantic-analysis-needs-to-take-instead-preambles-into-account"
Pull request url: https://github.com/pharo-project/pharo/pull/1960

Issue Url: https://pharo.fogbugz.com/f/cases/22641
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1371/

Re: [Pharo-dev] [ANN] Iceberg v1.4.0

[Ben Coman via Pharo-dev]

--- Begin Message ---
On Wed, 7 Nov 2018 at 17:09, Cyril Ferlicot  wrote:
>
> Hello!
>
> This week we are releasing the version v1.4.0 of Iceberg.
> (https://github.com/pharo-vcs/iceberg/releases/tag/v1.4.0)
>
> This version is available in the latest Pharo 7.
>
> This release fixes a bug introduced in v1.3. It also add new features
> in the repository view, add some cleaning and also re-introduce a
> feature that was lost.
>
> Thanks to all contributors.
>
> Enjoy!
>
> Full changelog:
>
> Bugfixes
>
> #1068 'There is no associated repository configured.' warning on right
> clicking missing repository
>
> Features
>
> #1077 Repository view: Allow to collapse branches/remotes/tags trees
> #847 Move tags under remotes in Repository view

Ohh, those two are very nice.   I'm meant to be working on something
else but needed to try those out.
That long list of tags had been mildly annoying me for a while, but
not enough for me to get around to complaining about it.
Glad its fixed already.


> #1070 set upstream if missing
>
> Cleanups
>
> #1066 Pharo 7: PackageManifest subclasses should be packaged with "Manifest"
> #1015 Replace usages of Glamour in the Github Plugin
> #1063 
> 1061-Introduce-iconNamed-in-IceDefinition-and-IceTipModel-and-remove-all-the-terrible-Smalltalk-ui-icons

Cool. I like the way the changes are reported and the semantic versioning.

cheers -ben

--- End Message ---

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Esteban Lorenzano]

> On 7 Nov 2018, at 14:19, Ben Coman  wrote:
> 
> On Wed, 7 Nov 2018 at 17:16, Esteban Lorenzano  > wrote:
>> 
>> It is not so easy.
>> 
>> A huge project as Pharo would profit to be split in order to manage its 
>> parts correctly. For example, we recently released iceberg 1.3.0. And there 
>> were some problems around and we evaluate the possibility of revert that 
>> release until we fix the problems. At the end, problems were not so 
>> important and the fix was made with a 1.3.1 release and almost immediately 
>> an 1.4.0.
>> 
>> Now, imagine If iceberg would be integrated in pharo.
>> 
>> 1. The nature of “iceberg” would be lost in other parts. We cannot talk 
>> anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way 
>> to know what changed in Iceberg without digging in the full list of changes.
>> 2. If we need to revert. How do we do it? There is no release so what do we 
>> revert? A commit? How many commits? How do we revert if development tree 
>> continued growing and iceberg commit are now mixed with others?
>> Of course, we could maintain a branch. But then I'd argüe is more or less 
>> the same as having a separated project.
>> 
>> Situation is not ideal (even if it is a lot better as before).
>> But I’m envisioning this solution: add multiple source directories 
>> capability.
>> 
>> Then we can have:
>> 
>> src/kernel
>> src/system
>> src/spec
>> src/iceberg
>> src/calypso
>> etc.
>> 
>> This will not just help to improve modularisation but we’ll gives a “free” 
>> feature : using git subtree to manage those directories.
>> For those who do not know: subtree allow us to merge different project trees 
>> into one. But the important part is how it will behave in Pharo (or other 
>> projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one 
>> single commit will spread to all repositories.
>> Now, the “price to pay” later is that time to time we need to push subtree 
>> from Pharo to their external projects (but this can be automated easily), 
>> and of course, doing “an iceberg release” means to do a pull subtree from 
>> external repository to Pharo (also very easy).
> 
> Why not a submodule approach?

Don’t know, don’t care for the moment :)
We need to add multiple subdirectories capability. Then we will be able to 
chose whatever we want: submodules, subtrees, nothing at all. 

>  I do vaguely remember you having some
> pain with it integrating the opensmalltalk-vm repo under the pharo-vm
> repo before Pharo started more directly using the opensmallk-vm CI
> products.

That was my own stupidity, not subtree problems ;)

> I thought I might have something useful to contribute to discussion by
> finding the good article [1] I remembered
> that compared subtree and submodule, the summary of which is...
> 
>   * Is the external repository something you own yourself and are
> likely to push code back to?
> Then use a submodule. This gives you the quickest and easiest way
> for you to push your changes back.
> 
>   * Is the external repository third party code that you are unlikely
> to push anything back to?
> Then use a subtree. This gives the advantage of not having to
> give people permissions to an extra repo when you are giving them
> access to the code base, and also reduces the chance that someone will
> forget to run a git submodule update. [But this could be automated in
> Pharo]
> 
> 
> But then I came across [2] which says...
>* Submodules [...] work well when you want to include a
> third-party library in your project that only occasionally needs to be
> updated.
> 
> so I don't know.
> [1] https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/ 
> 
> [2] http://www.mos6581.org/git_subtree_alternative 
> 
> 
> 
> I think main issues to consider between the two options are:
>A. the effect on history between Pharo repo and dependent repos,
> of commits to either repo
>B. how branching is handled between Pharo repo and dependent repos
> and I don't know really have my head around that, so for now I'll shut it. :)
> 
> 
> anyway, my understanding was that subtree was implemented in shell
> scripts and not libgit so does that make it more difficult?
>   https://stackoverflow.com/a/25474895 

Everything in git is implemented as shell scripts (that’s why libgit2 exists, 
in fact).

In any case, we will not handle the subtree (or submodule) pushing/pulling from 
iceberg. 
Doing a proper tooling on subtree will be complicated and time-effort consuming 
and sadly we do not have time to prioritise that now, then it will be an 
external task, at least for the moment.

Esteban

> 
> cheers -ben
> 
> 
>> 
>> Esteban
>> 
>> Ps: remember: programming is an iterative improving process. “Process" is 
>> part of programming so iterations 

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

[Marcus Denker]

> On 7 Nov 2018, at 13:56, Alistair Grant  wrote:
> 
> Hi Sven,
> 
> On Wed, 7 Nov 2018 at 10:37, Sven Van Caekenberghe  wrote:
>> 
>> 
>> 
>>> On 7 Nov 2018, at 10:27, Alistair Grant  wrote:
>>> 
>>> Hi Alex,
>>> 
>>> 
>>> On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel  wrote:
 
 Hello,
 
 When saving one of the latest pharo70 image I got an infinite recursion 
 loop due to message not understood. Force closing it probably lead to 
 image corruption and it became un-openable anymore. Any idea what is going 
 on? It does not look like a unique case because there are a few pharo70 
 images that already died in front of me...
>>> 
>>> This looks like your image changes the definition of
>>> Number>>raisedToInteger: somewhere along the line.  In the standard
>>> image it doesn't call #run:with:in:.
>> 
>> I don't think that definition got overwritten, check the implementers of 
>> #run:with:in: is seems to have to do with meta links or proxies or something 
>> like that ...
> 

Or it could be a bug where the VM ends up getting a SmallInteger instead of a 
CompiledMethod as the result of a method lookup. That would be bad...

> Good point.  How to get a list of all the methods that have MetaLinks?
> The following seems to work, but probably isn't the most efficient:
> 
> Object allSubclasses flatCollect: [ :each | each methods select: [
> :method | method ast links isNotNil ] ]
> 

you can ask the method directly 

Object allSubclasses flatCollect: [ :each | each methods select: [
:method | method hasLinks ] ]

this is much faster as it returns immediately nil for methods without links  
(without AST reification).

Marcus

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Ben Coman]

On Wed, 7 Nov 2018 at 17:16, Esteban Lorenzano  wrote:
>
> It is not so easy.
>
> A huge project as Pharo would profit to be split in order to manage its parts 
> correctly. For example, we recently released iceberg 1.3.0. And there were 
> some problems around and we evaluate the possibility of revert that release 
> until we fix the problems. At the end, problems were not so important and the 
> fix was made with a 1.3.1 release and almost immediately an 1.4.0.
>
> Now, imagine If iceberg would be integrated in pharo.
>
> 1. The nature of “iceberg” would be lost in other parts. We cannot talk 
> anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way 
> to know what changed in Iceberg without digging in the full list of changes.
> 2. If we need to revert. How do we do it? There is no release so what do we 
> revert? A commit? How many commits? How do we revert if development tree 
> continued growing and iceberg commit are now mixed with others?
> Of course, we could maintain a branch. But then I'd argüe is more or less the 
> same as having a separated project.
>
> Situation is not ideal (even if it is a lot better as before).
> But I’m envisioning this solution: add multiple source directories capability.
>
> Then we can have:
>
> src/kernel
> src/system
> src/spec
> src/iceberg
> src/calypso
> etc.
>
> This will not just help to improve modularisation but we’ll gives a “free” 
> feature : using git subtree to manage those directories.
> For those who do not know: subtree allow us to merge different project trees 
> into one. But the important part is how it will behave in Pharo (or other 
> projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one 
> single commit will spread to all repositories.
> Now, the “price to pay” later is that time to time we need to push subtree 
> from Pharo to their external projects (but this can be automated easily), and 
> of course, doing “an iceberg release” means to do a pull subtree from 
> external repository to Pharo (also very easy).

Why not a submodule approach?  I do vaguely remember you having some
pain with it integrating the opensmalltalk-vm repo under the pharo-vm
repo before Pharo started more directly using the opensmallk-vm CI
products.


I thought I might have something useful to contribute to discussion by
finding the good article [1] I remembered
that compared subtree and submodule, the summary of which is...

   * Is the external repository something you own yourself and are
likely to push code back to?
 Then use a submodule. This gives you the quickest and easiest way
for you to push your changes back.

   * Is the external repository third party code that you are unlikely
to push anything back to?
 Then use a subtree. This gives the advantage of not having to
give people permissions to an extra repo when you are giving them
access to the code base, and also reduces the chance that someone will
forget to run a git submodule update. [But this could be automated in
Pharo]


But then I came across [2] which says...
* Submodules [...] work well when you want to include a
third-party library in your project that only occasionally needs to be
updated.

so I don't know.
[1] https://codewinsarguments.co/2016/05/01/git-submodules-vs-git-subtrees/
[2] http://www.mos6581.org/git_subtree_alternative


I think main issues to consider between the two options are:
A. the effect on history between Pharo repo and dependent repos,
of commits to either repo
B. how branching is handled between Pharo repo and dependent repos
and I don't know really have my head around that, so for now I'll shut it. :)


anyway, my understanding was that subtree was implemented in shell
scripts and not libgit so does that make it more difficult?
   https://stackoverflow.com/a/25474895

cheers -ben


>
> Esteban
>
> Ps: remember: programming is an iterative improving process. “Process" is 
> part of programming so iterations applies to it too.
>
> > On 7 Nov 2018, at 07:02, Tim Mackinnon  wrote:
> >
> > It’s a tricky trade off as Norbert alludes too - in my recent example I 
> > needed some underlying base pieces in place (for the compiler’s ast) and 
> > those needed reviewing to then be committed - then there were two parts to 
> > Calypso that relied on those changes) that also needed reviewing and I 
> > wasn’t sure if Denis waited for the core approval or loaded up my PR - but 
> > anyway it took him a bit of time to process that and he came back with some 
> > better suggestions that I also needed to implement (which I had to find 
> > time to do as well).
> >
> > When I noticed that the core Pharo pieces were merged, I then had to chase 
> > Denis to see if he was now happy and could merge my changes.
> >
> > I guess it would be helpful if there was a way to easily load up multiple 
> > project pr’s in one go (like the suggested slice concept) so maintainers 
> > can easily review.  Probably more importantly is an easy way to 

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

[Alistair Grant]

Hi Sven,

On Wed, 7 Nov 2018 at 10:37, Sven Van Caekenberghe  wrote:
>
>
>
> > On 7 Nov 2018, at 10:27, Alistair Grant  wrote:
> >
> > Hi Alex,
> >
> >
> > On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel  wrote:
> >>
> >> Hello,
> >>
> >> When saving one of the latest pharo70 image I got an infinite recursion 
> >> loop due to message not understood. Force closing it probably lead to 
> >> image corruption and it became un-openable anymore. Any idea what is going 
> >> on? It does not look like a unique case because there are a few pharo70 
> >> images that already died in front of me...
> >
> > This looks like your image changes the definition of
> > Number>>raisedToInteger: somewhere along the line.  In the standard
> > image it doesn't call #run:with:in:.
>
> I don't think that definition got overwritten, check the implementers of 
> #run:with:in: is seems to have to do with meta links or proxies or something 
> like that ...

Good point.  How to get a list of all the methods that have MetaLinks?
 The following seems to work, but probably isn't the most efficient:

Object allSubclasses flatCollect: [ :each | each methods select: [
:method | method ast links isNotNil ] ]

Cheers,
Alistair

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Stephan Eggermont]

Chris Muller  wrote:
>> Earlier, we’ve seen projects like Magma being overwhelmed by the number of
>> needed changes,
> 
> I'm curious what you meant by this.  I'm not aware of Magma ever
> having been overwhelmed.  Its design has made it easy to be one of the
> most-available and consumable pieces of software for every version of
> Squeak from 2007 to today.  Did you mean the Pharo port?  It doesn't
> really do any magic, I'd be surprised if it would be very difficult to
> port to Pharo, but I don't know.

Several people have been working on a Magma version for Pharo. At the time
(Pharo 1.0-1.2) the Pharo CI infrastructure was not giving enough feedback
to keep the port running. Once a year or so someone comes along who tries
fixing the port, and that appears to be too difficult or time consuming for
them. It needs pretty deep knowledge about internals. I agree that it would
probably not be very difficult for a long time pharo/squeak developer.
Finding out what exactly changed and why in the past 8 years is not so easy
for someone new. 

Without someone using it in production on Pharo, there is not enough
incentive to keep up with what changes in Pharo. There’s a chicken and egg
problem there

Stephan

[Pharo-dev] [Pharo 7.0-dev] Build #1370: 22629-Secondary-selection-is-too-bright-when-switching-to-the-dark-theme

[ci-pharo-ci-jenkins2]

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

The Pull Request #1953 was integrated: 
"22629-Secondary-selection-is-too-bright-when-switching-to-the-dark-theme"
Pull request url: https://github.com/pharo-project/pharo/pull/1953

Issue Url: https://pharo.fogbugz.com/f/cases/22629
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/1370/

[Pharo-dev] Slow writing to Transcript (stderr) in Windows 10 PharoConsole.exe -headless

[Christopher Fuhrman]

Hello,

I encountered a performance bug in Pharo 6 under Windows 10 with Moose,
starting from the Moose 6.1 (beta) image in Pharo Launcher.

I migrated my code from Pharo 5 and it uses a PharoCommandLineHandler to
load an MSE file, which sometimes has many (15K) warnings/errors. It was
taking over a minute to run something that in Moose takes only a few
seconds.

To debug and make a minimal example, I removed the Moose file part of my
CommandLineHandler and simulated the writing of errors (i/o) with a loop. I
believe the I/O to the stderr is why the performance is bad. In Windows 10
Task Manager, I can see that the process is not using much CPU. As I
recall, my code didn't have this performance problem in Pharo 5.

The command in windows to execute my minimal sample is something like:

C:\Users\me>Documents\Pharo\vms\61-x86\PharoConsole.exe -headless
"C:\Users\me\Documents\Pharo\images\Moose Suite 6.1 (beta)\CommandHandler
VM slow bug.image" mooseminer --msefile blah

The last part (--msefile blah) is needed because I didn't want to remove
the argument validation.

Here's a copy of the image:

https://www.dropbox.com/s/7cgt37lef2xh2ut/CommandHandler%20VM%20slow%20bug.image?dl=0

A workaround is to run without -headless (or to not have so many errors).

I hope this is useful to someone. For RMOD people I'm happy to demo this on
my machine. Cheers,

-- 
Christopher Fuhrman, P.Eng, PhD

*Professor in the Département of Software and IT EngineeringÉTS (École de
technologie supérieure)*
http://profs.etsmtl.ca/cfuhrman
+1 514 396 8638
*L'ÉTS est une constituante de l'Université du Québec*

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

[Sven Van Caekenberghe]

> On 7 Nov 2018, at 10:27, Alistair Grant  wrote:
> 
> Hi Alex,
> 
> 
> On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel  wrote:
>> 
>> Hello,
>> 
>> When saving one of the latest pharo70 image I got an infinite recursion loop 
>> due to message not understood. Force closing it probably lead to image 
>> corruption and it became un-openable anymore. Any idea what is going on? It 
>> does not look like a unique case because there are a few pharo70 images that 
>> already died in front of me...
> 
> This looks like your image changes the definition of
> Number>>raisedToInteger: somewhere along the line.  In the standard
> image it doesn't call #run:with:in:.

I don't think that definition got overwritten, check the implementers of 
#run:with:in: is seems to have to do with meta links or proxies or something 
like that ...

> HTH,
> Alistair
> 

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

[Alistair Grant]

Hi Alex,


On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel  wrote:
>
> Hello,
>
> When saving one of the latest pharo70 image I got an infinite recursion loop 
> due to message not understood. Force closing it probably lead to image 
> corruption and it became un-openable anymore. Any idea what is going on? It 
> does not look like a unique case because there are a few pharo70 images that 
> already died in front of me...

This looks like your image changes the definition of
Number>>raisedToInteger: somewhere along the line.  In the standard
image it doesn't call #run:with:in:.

HTH,
Alistair

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

[Esteban Lorenzano]

It is not so easy. 

A huge project as Pharo would profit to be split in order to manage its parts 
correctly. For example, we recently released iceberg 1.3.0. And there were some 
problems around and we evaluate the possibility of revert that release until we 
fix the problems. At the end, problems were not so important and the fix was 
made with a 1.3.1 release and almost immediately an 1.4.0.

Now, imagine If iceberg would be integrated in pharo.

1. The nature of “iceberg” would be lost in other parts. We cannot talk anymore 
of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know 
what changed in Iceberg without digging in the full list of changes.
2. If we need to revert. How do we do it? There is no release so what do we 
revert? A commit? How many commits? How do we revert if development tree 
continued growing and iceberg commit are now mixed with others? 
Of course, we could maintain a branch. But then I'd argüe is more or less the 
same as having a separated project.

Situation is not ideal (even if it is a lot better as before). 
But I’m envisioning this solution: add multiple source directories capability. 

Then we can have: 

src/kernel
src/system
src/spec
src/iceberg
src/calypso
etc.

This will not just help to improve modularisation but we’ll gives a “free” 
feature : using git subtree to manage those directories. 
For those who do not know: subtree allow us to merge different project trees 
into one. But the important part is how it will behave in Pharo (or other 
projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single 
commit will spread to all repositories. 
Now, the “price to pay” later is that time to time we need to push subtree from 
Pharo to their external projects (but this can be automated easily), and of 
course, doing “an iceberg release” means to do a pull subtree from external 
repository to Pharo (also very easy). 

Esteban

Ps: remember: programming is an iterative improving process. “Process" is part 
of programming so iterations applies to it too.

> On 7 Nov 2018, at 07:02, Tim Mackinnon  wrote:
> 
> It’s a tricky trade off as Norbert alludes too - in my recent example I 
> needed some underlying base pieces in place (for the compiler’s ast) and 
> those needed reviewing to then be committed - then there were two parts to 
> Calypso that relied on those changes) that also needed reviewing and I wasn’t 
> sure if Denis waited for the core approval or loaded up my PR - but anyway it 
> took him a bit of time to process that and he came back with some better 
> suggestions that I also needed to implement (which I had to find time to do 
> as well).
> 
> When I noticed that the core Pharo pieces were merged, I then had to chase 
> Denis to see if he was now happy and could merge my changes.
> 
> I guess it would be helpful if there was a way to easily load up multiple 
> project pr’s in one go (like the suggested slice concept) so maintainers can 
> easily review.  Probably more importantly is an easy way to track the status 
> of multiple submissions so you can follow up with relevant people and push 
> things along and also ensure things get committed in the right order (eg doc 
> the dependency chain a bit better).
> 
> For me, after a few days I forgot about my Calypso changes and realised a few 
> weeks later (by accident) and so could chase Denis.
> 
> I think it’s this latter case that Steph alludes to - you lose interest after 
> a few days without some useful prompts and easy status tracking. If we can 
> make that easier I think it would help.
> 
> Tim
> 
> Sent from my iPhone
> 
>> On 7 Nov 2018, at 05:48, Ben Coman  wrote:
>> 
>> I get the feeling what is needed is mirroring all dependent repos from
>> the canonical location under http://github.com/pharo-project
>> and a Slice-like tool (probably keeping the name "Slice") which...
>> 1. Pulls all dependent repos to the local machine
>> 2. Simultaneously commits to the local repos with the same commit message
>> 3. Updates a bootstrap-configuration file holding commit-hashes of all
>> the dependencies and commits with same commit message
>> 4. Pushes that bootstrap-configuration file and all changed dependent
>> repos to user's github account
>> 5. Issues a pull request for the bootstrap-configuration file
>> 6. Our CI then builds a test-image by commit-hash direct from each
>> user's repo and if it passes, pulls dependent repo commits under
>> pharo-project
>> 7. CI can then issue PRs to the dependency canonical repos
>> 
>> cheers -ben
>> 
>>> On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse  
>>> wrote:
>>> 
>>> Calypso is integral part of Pharo as Iceberg.
>>> We started to discuss the problem in the team. Right now this project
>>> spread kills us.
>>> 
>>> Stef
 On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont  wrote:
 
 Tim Mackinnon  wrote:
> 
 
> In retrospect,  I’m wondering if successful projects that have proved
> integration 

[Pharo-dev] [ANN] Iceberg v1.4.0

[Cyril Ferlicot]

Hello!

This week we are releasing the version v1.4.0 of Iceberg.
(https://github.com/pharo-vcs/iceberg/releases/tag/v1.4.0)

This version is available in the latest Pharo 7.

This release fixes a bug introduced in v1.3. It also add new features
in the repository view, add some cleaning and also re-introduce a
feature that was lost.

Thanks to all contributors.

Enjoy!

Full changelog:

Bugfixes

#1068 'There is no associated repository configured.' warning on right
clicking missing repository

Features

#1077 Repository view: Allow to collapse branches/remotes/tags trees
#847 Move tags under remotes in Repository view
#1070 set upstream if missing

Cleanups

#1066 Pharo 7: PackageManifest subclasses should be packaged with "Manifest"
#1015 Replace usages of Glamour in the Github Plugin
#1063 
1061-Introduce-iconNamed-in-IceDefinition-and-IceTipModel-and-remove-all-the-terrible-Smalltalk-ui-icons


-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] [ANN] Pharo v7.0.0-rc1 released!

[Tudor Girba]

Excellent!

Doru


> On Nov 5, 2018, at 4:11 PM, Esteban Lorenzano  wrote:
> 
> Greetings!
> 
> I’m announcing today we reach Pharo 7.0.0-rc1!
> 
> This is the first step to release a definitive version, and while we will 
> continue integrating bug fixes, API change Pull Requests will be delayed 
> until the open of Pharo 8.0.0 development. 
> Now, you would wonder what is the ChangeLog of this release… and answer is we 
> still do not have one (btw, we should find a way to automate this).
> 
> Anyway… we are very close to release now :)
> 
> Please download, test, report issues.
> 
> Esteban

--
www.feenk.com

"Speaking louder won't make the point worthier."