Re: [Pharo-dev] [Pharo70 alpha] Store settings raise a DNU primFlush

[Stephane Ducasse]

Thanks guy.
I was dead tired. Did not have the energy to look went to sleep.


On Fri, Apr 13, 2018 at 10:44 PM, Sven Van Caekenberghe  wrote:
>
>
>> On 13 Apr 2018, at 22:26, Alistair Grant  wrote:
>>
>> Hi Stef & Sven,
>>
>> On 13 April 2018 at 20:38, Stephane Ducasse  wrote:
>>> Hi
>>>
>>> I do not know if this is related to the OldStreamCleaningEffort but
>>> when I press store settings in the Settings browser I get a primitive
>>> failed.
>>>
>>> https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush
>>
>>
>> This is because the stream created in
>> SystemSettingsPersistence>>storeExactStoredSettings: is closed twice,
>> first in SettingsStonWriter>>store and then in
>> SystemSettingsPersistence>>storeExactStoredSettings:.
>>
>> Previous versions of file streams have allowed the stream #close to be
>> called multiple times, however ZnBufferedReadWriteStream doesn't allow
>> this.
>>
>> I think that since an already open stream is handed to
>> SettingsStonWriter, it shouldn't be closing the stream.  That will
>> resolve this particular problem.
>>
>> It can also be argued that ZnBufferedReadWriteStream and co. should
>> allow streams to be closed multiple times for backward compatibility.
>> Sven?
>
> Yes, OK, making #close idempotent is good. If we add #closed to 
> ZnBufferedReadStream we can add a
>
>   self closed ifFalse: [ .. ]
>
> guard in #close.
>
>> Cheers,
>> Alistair
>>
>
>

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Ben Coman]

On 14 April 2018 at 01:55, Guillermo Polito 
wrote:

>
>
> On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman  wrote:
>
>>
>>
>> On 14 April 2018 at 01:10, Guillermo Polito 
>> wrote:
>>
>>>
>>>
>>> On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman  wrote:
>>>


 On 13 April 2018 at 23:15, Alistair Grant 
 wrote:

> On 13 April 2018 at 17:07, Cyril Ferlicot 
> wrote:
> >
> >
> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
> >>
> >>
> >> The thing is that the best way to do it is to clone your own
> fork... And each one has her/his one.
>

 I know, but momentarily forgot while trying to work on my first Issue
 with the new UI.
 However I discovered something cool...

 I had directly cloned "g...@github.com:pharo-project/pharo.git"
 successfully brought that "Up to date"
 then in the "Working copy of pharo" window, clicked  and
 filled in details,
 made my code change,
 then clicked 
 then clicked  bringing me to a window titled "Push
 pharo/21686-.../21686..."
 where the only option to "Push to remote: " was  "origin
 (g...@github.com:pharo-project/pharo.git)"
 and clicking  of course produced an error "LGit_GIT_EEOF: ERROR:
 Permission to pharo-project/pharo.git denied to bencoman."
 Fair enough!

>>>
>>> Have to gracefully manage that error. Could you open an issue?
>>>
>>>

 But then...!!!
 Back in the "Repositories" window,
 "pharo" > right-click > Repository > Add Remote
Remote name = bencoman
Remote URL = g...@github.com:pharo-project/pharo.git
 And back in the "Working copy of pharo" window
 clicked   bringing again me to a window titled "Push
 pharo/21686-.../21686..."
 but now I had an extra option "bencoman "
 and selecting that and clicking   worked

 https://github.com/bencoman/pharo/tree/21686-Setting-backgro
 und-images-doesnt-work-on-Pharo-70

>>>
>>> Esteban is working on adding the add remote to the pull/push windows
>>>
>>> https://github.com/pharo-vcs/iceberg/issues/624
>>>
>>> so you will have less clicks to do there ;)
>>>
>>>


 Now the key thing here is that I **didn't** have to first
 synchronise  github.com:bencoman/pharo.git  with  github.com:
 pharo-project/pharo.git
 and remember to clone  github.com: bencoman/pharo.git .
 I just pushed to my repo **after-the-fact**.

 I haven't submitted many fixes lately to get familiar with Iceberg,
 and maybe I missed something in the old workflow,
 but previously it seemed that my pharo github repo needed to be up to
 date,
 and I must clone from there.

>>>
>>> Well, it depends.
>>>
>>> Scenario 1) If you're not planning to reuse your clone, you don't need
>>> to care about synchronize.
>>>  - just reclone pharo from pharo
>>>  - add your fork as remote
>>>  - you're set
>>>
>>> Scenario 2) If you want to reuse your clone you may not synchronize them.
>>>  - pull from pharo from time to time
>>>  - start a new branch from the current commit
>>>  - you're set
>>>
>>> But then, there is people that may want/need to have some other
>>> workflow. For example:
>>>  - I start from scenario 1
>>>  - make a branch
>>>  - commit some work
>>>  - tomorrow I come back and I download a new image
>>> * a couple of integrations may have happened in between!!
>>> * but I want to continue working in my branch
>>>
>>> Then the scenario could be solved as:
>>>  - fetch from pharo
>>>  - if you're in detached mode, just use the merge image into branch
>>> action and select your branch
>>>  - or if you want to do it manually:
>>>- checkout your branch in your image without loading packages
>>>- merge pharo/development into your branch
>>>  - continue working
>>>
>>> Now, what I would like is that we detect such "common rough scenarios"
>>> and discuss how we could have a better UI support for them.
>>> Maybe we need as a part of the Pharo plugin a wizard that takes you
>>> through the "synchronize my image again please"?
>>> Or could it be solved with some strategy that is general enough to be
>>> reused in any repository?
>>>
>>>

 The new UI is intuitive and made it east to clone from pharo-project,
 make fix the push to bencoman.
 I worked this out from just a small bit of trial & error.


 One request...
 In attached snapshot where the remotes show "origin",
 please consider showing that as "pharo-project"
 The term "origin" is useful for generic documentation and for examples,
 but there is *nothing* special about that label from a git perspective.
 A remote is a remote is a remote.

>>>
>>> Well that's mostly a 

Re: [Pharo-dev] [Pharo70 alpha] Store settings raise a DNU primFlush

[Sven Van Caekenberghe]

> On 13 Apr 2018, at 22:26, Alistair Grant  wrote:
> 
> Hi Stef & Sven,
> 
> On 13 April 2018 at 20:38, Stephane Ducasse  wrote:
>> Hi
>> 
>> I do not know if this is related to the OldStreamCleaningEffort but
>> when I press store settings in the Settings browser I get a primitive
>> failed.
>> 
>> https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush
> 
> 
> This is because the stream created in
> SystemSettingsPersistence>>storeExactStoredSettings: is closed twice,
> first in SettingsStonWriter>>store and then in
> SystemSettingsPersistence>>storeExactStoredSettings:.
> 
> Previous versions of file streams have allowed the stream #close to be
> called multiple times, however ZnBufferedReadWriteStream doesn't allow
> this.
> 
> I think that since an already open stream is handed to
> SettingsStonWriter, it shouldn't be closing the stream.  That will
> resolve this particular problem.
> 
> It can also be argued that ZnBufferedReadWriteStream and co. should
> allow streams to be closed multiple times for backward compatibility.
> Sven?

Yes, OK, making #close idempotent is good. If we add #closed to 
ZnBufferedReadStream we can add a 

  self closed ifFalse: [ .. ]

guard in #close.

> Cheers,
> Alistair
> 

Re: [Pharo-dev] [Pharo70 alpha] Store settings raise a DNU primFlush

[Alistair Grant]

Hi Stef & Sven,

On 13 April 2018 at 20:38, Stephane Ducasse  wrote:
> Hi
>
> I do not know if this is related to the OldStreamCleaningEffort but
> when I press store settings in the Settings browser I get a primitive
> failed.
>
> https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush


This is because the stream created in
SystemSettingsPersistence>>storeExactStoredSettings: is closed twice,
first in SettingsStonWriter>>store and then in
SystemSettingsPersistence>>storeExactStoredSettings:.

Previous versions of file streams have allowed the stream #close to be
called multiple times, however ZnBufferedReadWriteStream doesn't allow
this.

I think that since an already open stream is handed to
SettingsStonWriter, it shouldn't be closing the stream.  That will
resolve this particular problem.

It can also be argued that ZnBufferedReadWriteStream and co. should
allow streams to be closed multiple times for backward compatibility.
Sven?

Cheers,
Alistair

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

[Serge Stinckwich]

On Fri, Apr 13, 2018 at 8:54 PM, Esteban Lorenzano 
wrote:

>
>
> On 13 Apr 2018, at 21:43, Serge Stinckwich 
> wrote:
>
> Yes I was able to commit also.
> Very slick interface :-)
>
>
> But now, every time I want to commit, my image crash and I have:
>
> Assertion failed: (git_atomic_get(__n_inits) > 0), function
> git__global_state, file /Users/travis/build/OpenSmalltalk/opensmalltalk-
> vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c,
> line 322.
>
>
> there is a current bug on initialisation (no idea why, still
> investigating).
>
> this is fixed by executing:
>
> LGitLibrary initialize.
>
>
​Thank you Esteban, you save my time :-)
​

​Apparently this crash happens after I relaunch my image with Iceberg
running.​

-- 
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

[Esteban Lorenzano]

> On 13 Apr 2018, at 21:43, Serge Stinckwich  wrote:
> 
> Yes I was able to commit also.
> Very slick interface :-)
> 
> 
> But now, every time I want to commit, my image crash and I have:
> 
> Assertion failed: (git_atomic_get(__n_inits) > 0), function 
> git__global_state, file 
> /Users/travis/build/OpenSmalltalk/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c,
>  line 322.

there is a current bug on initialisation (no idea why, still investigating).

this is fixed by executing: 

LGitLibrary initialize.

cheers!
Esteban

> 
> 
> On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse  > wrote:
> I could commit my first commit with iceberg 2.0
> Well done
> 
> It feels nicer :).
> 
> Stef
> 
> 
> 
> 
> -- 
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for 
> machines to execute."
> http://www.doesnotunderstand.org/ 

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

[Serge Stinckwich]

Yes Pharo 7.0, latest VM 64 bits

On Fri, Apr 13, 2018 at 8:46 PM, Guillermo Polito  wrote:

> Is that Pharo 7?
>
> On Fri, Apr 13, 2018 at 9:43 PM, Serge Stinckwich <
> serge.stinckw...@gmail.com> wrote:
>
>> Yes I was able to commit also.
>> Very slick interface :-)
>>
>>
>> But now, every time I want to commit, my image crash and I have:
>>
>> Assertion failed: (git_atomic_get(__n_inits) > 0), function
>> git__global_state, file /Users/travis/build/OpenSmallt
>> alk/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/
>> build/third-party/libgit2-0.25.1/src/global.c, line 322.
>>
>>
>> On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> I could commit my first commit with iceberg 2.0
>>> Well done
>>>
>>> It feels nicer :).
>>>
>>> Stef
>>>
>>>
>>
>>
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (SU/IRD/UY1)
>> "Programs must be written for people to read, and only incidentally for
>> machines to execute."http://www.doesnotunderstand.org/
>>
>
>
>
> --
>
>
>
> 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
>



-- 
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

[Guillermo Polito]

Is that Pharo 7?

On Fri, Apr 13, 2018 at 9:43 PM, Serge Stinckwich <
serge.stinckw...@gmail.com> wrote:

> Yes I was able to commit also.
> Very slick interface :-)
>
>
> But now, every time I want to commit, my image crash and I have:
>
> Assertion failed: (git_atomic_get(__n_inits) > 0), function
> git__global_state, file /Users/travis/build/OpenSmalltalk/opensmalltalk-
> vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c,
> line 322.
>
>
> On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse  > wrote:
>
>> I could commit my first commit with iceberg 2.0
>> Well done
>>
>> It feels nicer :).
>>
>> Stef
>>
>>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."http://www.doesnotunderstand.org/
>



-- 



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] Iceberg2.0 crash test passed :)

[Serge Stinckwich]

Yes I was able to commit also.
Very slick interface :-)


But now, every time I want to commit, my image crash and I have:

Assertion failed: (git_atomic_get(__n_inits) > 0), function
git__global_state, file
/Users/travis/build/OpenSmalltalk/opensmalltalk-vm/build.macos64x64/pharo.cog.spur/build/third-party/libgit2-0.25.1/src/global.c,
line 322.


On Fri, Apr 13, 2018 at 8:02 PM, Stephane Ducasse 
wrote:

> I could commit my first commit with iceberg 2.0
> Well done
>
> It feels nicer :).
>
> Stef
>
>


-- 
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-dev] Iceberg2.0 crash test passed :)

[Guillermo Polito]

I want your bug reports!

Le ven. 13 avr. 2018 à 21:09, Stephane Ducasse  a
écrit :

> I could commit my first commit with iceberg 2.0
> Well done
>
> It feels nicer :).
>
> Stef
>
> --



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

[Pharo-dev] Iceberg2.0 crash test passed :)

[Stephane Ducasse]

I could commit my first commit with iceberg 2.0
Well done

It feels nicer :).

Stef

[Pharo-dev] [Pharo70 alpha] Store settings raise a DNU primFlush

[Stephane Ducasse]

Hi

I do not know if this is related to the OldStreamCleaningEffort but
when I press store settings in the Settings browser I get a primitive
failed.

https://pharo.fogbugz.com/f/cases/21699/Store-settings-raise-a-DNU-primFlush

Stef

Re: [Pharo-dev] updating preference to iceberg2 help needed :)

[Cyril Ferlicot]

On ven. 13 avr. 2018 at 20:32, Stephane Ducasse 
wrote:

> Any idea for this one?
>
> IceRepository
> shareRepositoriesBetweenImages: true;
> sharedRepositoriesLocationString:
> '/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/'.
>
> Hi!

See my startup script update:

https://github.com/jecisc/pharo-scripts/commit/4eedd32ad9c321af320b08a48cbc03e057194918

(Fast answer from my phone)
-- 
Cyril Ferlicot
https://ferlicot.fr

[Pharo-dev] updating preference to iceberg2 help needed :)

[Stephane Ducasse]

Any idea for this one?

IceRepository
shareRepositoriesBetweenImages: true;
sharedRepositoriesLocationString:
'/Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/PharoCodeBase/'.

[Pharo-dev] [OT] Reminder about quoting/top-posting

[Esteban A. Maringolo]

Hi,

Please apologize the digression, but these days there were a lot of
interesting threads with LOTS of replies from different members.

Can I ask for more trimming of the quoted text and/or emails replied to?

The follow up of some replies was hard because they were nested deep
into a chain of previous quotes, or in the case of top-posters, they
keep the replied emails accumulating in the bottom, causing a scroll
down to find nothing else was there.

Thanks!


-- 
Esteban A. Maringolo



signature.asc
Description: OpenPGP digital signature

[Pharo-dev] [Pharo 7.0-dev] Build #765: 21692-StdioStream-incorrectly-delegates-atEnd-and-position-to-file

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #765 was: SUCCESS.

The Pull Request #1193 was integrated: 
"21692-StdioStream-incorrectly-delegates-atEnd-and-position-to-file"
Pull request url: https://github.com/pharo-project/pharo/pull/1193

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

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 7:34 PM, Ben Coman  wrote:

>
>
> On 14 April 2018 at 01:10, Guillermo Polito 
> wrote:
>
>>
>>
>> On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman  wrote:
>>
>>>
>>>
>>> On 13 April 2018 at 23:15, Alistair Grant  wrote:
>>>
 On 13 April 2018 at 17:07, Cyril Ferlicot 
 wrote:
 >
 >
 > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
 guillermopol...@gmail.com> wrote:
 >>
 >>
 >> The thing is that the best way to do it is to clone your own fork...
 And each one has her/his one.

>>>
>>> I know, but momentarily forgot while trying to work on my first Issue
>>> with the new UI.
>>> However I discovered something cool...
>>>
>>> I had directly cloned "g...@github.com:pharo-project/pharo.git"
>>> successfully brought that "Up to date"
>>> then in the "Working copy of pharo" window, clicked  and
>>> filled in details,
>>> made my code change,
>>> then clicked 
>>> then clicked  bringing me to a window titled "Push
>>> pharo/21686-.../21686..."
>>> where the only option to "Push to remote: " was  "origin (g...@github.com:
>>> pharo-project/pharo.git)"
>>> and clicking  of course produced an error "LGit_GIT_EEOF: ERROR:
>>> Permission to pharo-project/pharo.git denied to bencoman."
>>> Fair enough!
>>>
>>
>> Have to gracefully manage that error. Could you open an issue?
>>
>>
>>>
>>> But then...!!!
>>> Back in the "Repositories" window,
>>> "pharo" > right-click > Repository > Add Remote
>>>Remote name = bencoman
>>>Remote URL = g...@github.com:pharo-project/pharo.git
>>> And back in the "Working copy of pharo" window
>>> clicked   bringing again me to a window titled "Push
>>> pharo/21686-.../21686..."
>>> but now I had an extra option "bencoman >> .git>"
>>> and selecting that and clicking   worked
>>>
>>> https://github.com/bencoman/pharo/tree/21686-Setting-backgro
>>> und-images-doesnt-work-on-Pharo-70
>>>
>>
>> Esteban is working on adding the add remote to the pull/push windows
>>
>> https://github.com/pharo-vcs/iceberg/issues/624
>>
>> so you will have less clicks to do there ;)
>>
>>
>>>
>>>
>>> Now the key thing here is that I **didn't** have to first
>>> synchronise  github.com:bencoman/pharo.git  with  github.com:
>>> pharo-project/pharo.git
>>> and remember to clone  github.com: bencoman/pharo.git .
>>> I just pushed to my repo **after-the-fact**.
>>>
>>> I haven't submitted many fixes lately to get familiar with Iceberg,
>>> and maybe I missed something in the old workflow,
>>> but previously it seemed that my pharo github repo needed to be up to
>>> date,
>>> and I must clone from there.
>>>
>>
>> Well, it depends.
>>
>> Scenario 1) If you're not planning to reuse your clone, you don't need to
>> care about synchronize.
>>  - just reclone pharo from pharo
>>  - add your fork as remote
>>  - you're set
>>
>> Scenario 2) If you want to reuse your clone you may not synchronize them.
>>  - pull from pharo from time to time
>>  - start a new branch from the current commit
>>  - you're set
>>
>> But then, there is people that may want/need to have some other workflow.
>> For example:
>>  - I start from scenario 1
>>  - make a branch
>>  - commit some work
>>  - tomorrow I come back and I download a new image
>> * a couple of integrations may have happened in between!!
>> * but I want to continue working in my branch
>>
>> Then the scenario could be solved as:
>>  - fetch from pharo
>>  - if you're in detached mode, just use the merge image into branch
>> action and select your branch
>>  - or if you want to do it manually:
>>- checkout your branch in your image without loading packages
>>- merge pharo/development into your branch
>>  - continue working
>>
>> Now, what I would like is that we detect such "common rough scenarios"
>> and discuss how we could have a better UI support for them.
>> Maybe we need as a part of the Pharo plugin a wizard that takes you
>> through the "synchronize my image again please"?
>> Or could it be solved with some strategy that is general enough to be
>> reused in any repository?
>>
>>
>>>
>>> The new UI is intuitive and made it east to clone from pharo-project,
>>> make fix the push to bencoman.
>>> I worked this out from just a small bit of trial & error.
>>>
>>>
>>> One request...
>>> In attached snapshot where the remotes show "origin",
>>> please consider showing that as "pharo-project"
>>> The term "origin" is useful for generic documentation and for examples,
>>> but there is *nothing* special about that label from a git perspective.
>>> A remote is a remote is a remote.
>>>
>>
>> Well that's mostly a libgit thing. It does it by default I think when you
>> clone, and I'm pretty sure that a lot of people would be against breaking
>> such default because that's how git works also.
>>
>
> Its not "the" way git works.  Its just the 

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Ben Coman]

On 14 April 2018 at 01:10, Guillermo Polito 
wrote:

>
>
> On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman  wrote:
>
>>
>>
>> On 13 April 2018 at 23:15, Alistair Grant  wrote:
>>
>>> On 13 April 2018 at 17:07, Cyril Ferlicot 
>>> wrote:
>>> >
>>> >
>>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
>>> guillermopol...@gmail.com> wrote:
>>> >>
>>> >>
>>> >> The thing is that the best way to do it is to clone your own fork...
>>> And each one has her/his one.
>>>
>>
>> I know, but momentarily forgot while trying to work on my first Issue
>> with the new UI.
>> However I discovered something cool...
>>
>> I had directly cloned "g...@github.com:pharo-project/pharo.git"
>> successfully brought that "Up to date"
>> then in the "Working copy of pharo" window, clicked  and
>> filled in details,
>> made my code change,
>> then clicked 
>> then clicked  bringing me to a window titled "Push
>> pharo/21686-.../21686..."
>> where the only option to "Push to remote: " was  "origin (g...@github.com:
>> pharo-project/pharo.git)"
>> and clicking  of course produced an error "LGit_GIT_EEOF: ERROR:
>> Permission to pharo-project/pharo.git denied to bencoman."
>> Fair enough!
>>
>
> Have to gracefully manage that error. Could you open an issue?
>
>
>>
>> But then...!!!
>> Back in the "Repositories" window,
>> "pharo" > right-click > Repository > Add Remote
>>Remote name = bencoman
>>Remote URL = g...@github.com:pharo-project/pharo.git
>> And back in the "Working copy of pharo" window
>> clicked   bringing again me to a window titled "Push
>> pharo/21686-.../21686..."
>> but now I had an extra option "bencoman > .git>"
>> and selecting that and clicking   worked
>>
>> https://github.com/bencoman/pharo/tree/21686-Setting-backgro
>> und-images-doesnt-work-on-Pharo-70
>>
>
> Esteban is working on adding the add remote to the pull/push windows
>
> https://github.com/pharo-vcs/iceberg/issues/624
>
> so you will have less clicks to do there ;)
>
>
>>
>>
>> Now the key thing here is that I **didn't** have to first
>> synchronise  github.com:bencoman/pharo.git  with  github.com:
>> pharo-project/pharo.git
>> and remember to clone  github.com: bencoman/pharo.git .
>> I just pushed to my repo **after-the-fact**.
>>
>> I haven't submitted many fixes lately to get familiar with Iceberg,
>> and maybe I missed something in the old workflow,
>> but previously it seemed that my pharo github repo needed to be up to
>> date,
>> and I must clone from there.
>>
>
> Well, it depends.
>
> Scenario 1) If you're not planning to reuse your clone, you don't need to
> care about synchronize.
>  - just reclone pharo from pharo
>  - add your fork as remote
>  - you're set
>
> Scenario 2) If you want to reuse your clone you may not synchronize them.
>  - pull from pharo from time to time
>  - start a new branch from the current commit
>  - you're set
>
> But then, there is people that may want/need to have some other workflow.
> For example:
>  - I start from scenario 1
>  - make a branch
>  - commit some work
>  - tomorrow I come back and I download a new image
> * a couple of integrations may have happened in between!!
> * but I want to continue working in my branch
>
> Then the scenario could be solved as:
>  - fetch from pharo
>  - if you're in detached mode, just use the merge image into branch action
> and select your branch
>  - or if you want to do it manually:
>- checkout your branch in your image without loading packages
>- merge pharo/development into your branch
>  - continue working
>
> Now, what I would like is that we detect such "common rough scenarios"
> and discuss how we could have a better UI support for them.
> Maybe we need as a part of the Pharo plugin a wizard that takes you
> through the "synchronize my image again please"?
> Or could it be solved with some strategy that is general enough to be
> reused in any repository?
>
>
>>
>> The new UI is intuitive and made it east to clone from pharo-project,
>> make fix the push to bencoman.
>> I worked this out from just a small bit of trial & error.
>>
>>
>> One request...
>> In attached snapshot where the remotes show "origin",
>> please consider showing that as "pharo-project"
>> The term "origin" is useful for generic documentation and for examples,
>> but there is *nothing* special about that label from a git perspective.
>> A remote is a remote is a remote.
>>
>
> Well that's mostly a libgit thing. It does it by default I think when you
> clone, and I'm pretty sure that a lot of people would be against breaking
> such default because that's how git works also.
>

Its not "the" way git works.  Its just the "default".
Any name can be used to refer to the upstream repo.
i.e...
  --origin 
   Instead of using the remote name origin to keep track of the
upstream repository, use .
https://git-scm.com/docs/git-clone

but 

[Pharo-dev] [Pharo 7.0-dev] Build #764: Fix Case 21686 Setting background images doesn't work on Pharo 7.0

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #764 was: SUCCESS.

The Pull Request #1197 was integrated: "Fix Case 21686 Setting background 
images doesn't work on Pharo 7.0"
Pull request url: https://github.com/pharo-project/pharo/pull/1197

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

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 5:57 PM, Ben Coman  wrote:

>
>
> On 13 April 2018 at 23:15, Alistair Grant  wrote:
>
>> On 13 April 2018 at 17:07, Cyril Ferlicot 
>> wrote:
>> >
>> >
>> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
>> guillermopol...@gmail.com> wrote:
>> >>
>> >>
>> >> The thing is that the best way to do it is to clone your own fork...
>> And each one has her/his one.
>>
>
> I know, but momentarily forgot while trying to work on my first Issue with
> the new UI.
> However I discovered something cool...
>
> I had directly cloned "g...@github.com:pharo-project/pharo.git"
> successfully brought that "Up to date"
> then in the "Working copy of pharo" window, clicked  and filled
> in details,
> made my code change,
> then clicked 
> then clicked  bringing me to a window titled "Push
> pharo/21686-.../21686..."
> where the only option to "Push to remote: " was  "origin (g...@github.com:
> pharo-project/pharo.git)"
> and clicking  of course produced an error "LGit_GIT_EEOF: ERROR:
> Permission to pharo-project/pharo.git denied to bencoman."
> Fair enough!
>

Have to gracefully manage that error. Could you open an issue?


>
> But then...!!!
> Back in the "Repositories" window,
> "pharo" > right-click > Repository > Add Remote
>Remote name = bencoman
>Remote URL = g...@github.com:pharo-project/pharo.git
> And back in the "Working copy of pharo" window
> clicked   bringing again me to a window titled "Push
> pharo/21686-.../21686..."
> but now I had an extra option "bencoman  pharo.git>"
> and selecting that and clicking   worked
>
> https://github.com/bencoman/pharo/tree/21686-Setting-
> background-images-doesnt-work-on-Pharo-70
>

Esteban is working on adding the add remote to the pull/push windows

https://github.com/pharo-vcs/iceberg/issues/624

so you will have less clicks to do there ;)


>
>
> Now the key thing here is that I **didn't** have to first
> synchronise  github.com:bencoman/pharo.git  with  github.com:
> pharo-project/pharo.git
> and remember to clone  github.com: bencoman/pharo.git .
> I just pushed to my repo **after-the-fact**.
>
> I haven't submitted many fixes lately to get familiar with Iceberg,
> and maybe I missed something in the old workflow,
> but previously it seemed that my pharo github repo needed to be up to
> date,
> and I must clone from there.
>

Well, it depends.

Scenario 1) If you're not planning to reuse your clone, you don't need to
care about synchronize.
 - just reclone pharo from pharo
 - add your fork as remote
 - you're set

Scenario 2) If you want to reuse your clone you may not synchronize them.
 - pull from pharo from time to time
 - start a new branch from the current commit
 - you're set

But then, there is people that may want/need to have some other workflow.
For example:
 - I start from scenario 1
 - make a branch
 - commit some work
 - tomorrow I come back and I download a new image
* a couple of integrations may have happened in between!!
* but I want to continue working in my branch

Then the scenario could be solved as:
 - fetch from pharo
 - if you're in detached mode, just use the merge image into branch action
and select your branch
 - or if you want to do it manually:
   - checkout your branch in your image without loading packages
   - merge pharo/development into your branch
 - continue working

Now, what I would like is that we detect such "common rough scenarios" and
discuss how we could have a better UI support for them.
Maybe we need as a part of the Pharo plugin a wizard that takes you through
the "synchronize my image again please"?
Or could it be solved with some strategy that is general enough to be
reused in any repository?


>
> The new UI is intuitive and made it east to clone from pharo-project, make
> fix the push to bencoman.
> I worked this out from just a small bit of trial & error.
>
>
> One request...
> In attached snapshot where the remotes show "origin",
> please consider showing that as "pharo-project"
> The term "origin" is useful for generic documentation and for examples,
> but there is *nothing* special about that label from a git perspective.
> A remote is a remote is a remote.
>

Well that's mostly a libgit thing. It does it by default I think when you
clone, and I'm pretty sure that a lot of people would be against breaking
such default because that's how git works also.
What could maybe be done is to enhance the "New repository" dialog to be
able to provide a remote name using origin by default?
Like that people could be able to override it to their convenience?


>
> Since mostly pharo development workflow will follow a triangle,
> from remote pharo-project repo, to remote personal repo, PR to remote
> pharo-project repo,
> it would be more useful conceptually
> to have the pharo-project remote labelled "pharo-project" rather than
> labelled "origin".
>
> cheers -ben
>
>
>
>> >>
>> >
>> >

Re: [Pharo-dev] request Calypso added as a "project" in Fogbugz

[Ben Coman]

On 13 April 2018 at 21:24, Sean P. DeNigris  wrote:

> Ben Coman wrote
> > However I have some concerns about scattering Issues away from Fogbugz
> > since this makes it harder to get an overview of outstanding issues
>
> Point taken, but:
> - IIUC we will be soon moving to *all* github issues anyway
> - duplication has it's own negative consequences
> - There are significant benefits to GH issues for GH code like all the
> auto-references (issues, commits, etc)


What is lacking from the Git/Fogbugz integration?
Is it just that it hasn't been used/promoted much?  (Is it enabled?)

cheers -ben

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 5:38 PM, Alistair Grant 
wrote:

> Hi Guille,
>
> On 13 April 2018 at 17:29, Guillermo Polito 
> wrote:
> >
> >
> > On Fri, Apr 13, 2018 at 5:15 PM, Alistair Grant 
> > wrote:
> >>
> >> On 13 April 2018 at 17:07, Cyril Ferlicot 
> >> wrote:
> >> >
> >> >
> >> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito
> >> >  wrote:
> >> >>
> >> >>
> >> >> The thing is that the best way to do it is to clone your own fork...
> >> >> And each one has her/his one.
> >> >>
> >> >
> >> >
> >> > What your can do is display the list of forks and ask to select the
> >> > right one. Then it will create the Pharo repo with the two remotes.
> >>
> >
> > This would be strange. Pharo has 75 forks...
> >
> >>
> >>
> >> I was going to suggest prompting for the git username.  You can
> >> substitute it in to:
> >>
> >> g...@github.com:{username}/pharo.git
> >>
> >> and add upstream (pharo-project).
> >
> >
> > Yes, and if it does not exist we have to use github's API to create the
> > fork...
>
> I hadn't even thought of this, I was assuming that the fork had
> already been created.
>
> I still think this would be useful, especially for regular
> contributors who like to start with a clean image when development a
> PR.
>
>
> > It's doable... But doing it well will take time:
> >  - I would like a UI where I explain users what I will do with their git
> > credentials
> >  - I would like to prevent them that I'm doing a fork before doing it
> >  - I want to show a good progress bar
> >  - I want to wait until github's finished with the fork (it's an async
> > operation) before continuing with the process
> >  - And then, I want that if possible iceberg is well (automatically)
> tested
> > because there are so many corner cases that it starts to be really
> > complicated to do it manually.
> >
> > But also our plate is full with other things, and we have to
> prioritize...
> >
> > If someone wants to give it a try, I can give a hand, review, test,
> > advice...
>
> Fair enough.
>
> Would you be willing to accept a patch that requires an existing fork?
>

Of course good is better than perfect :)

https://github.com/pharo-vcs/iceberg

I've worked yesterday and this morning to have iceberg's ci green and
working for PRs also. I've enhanced included a couple of new tests.


>
> Cheers,
> 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] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 5:15 PM, Alistair Grant 
wrote:

> On 13 April 2018 at 17:07, Cyril Ferlicot 
> wrote:
> >
> >
> > On ven. 13 avr. 2018 at 17:03, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
> >>
> >>
> >> The thing is that the best way to do it is to clone your own fork...
> And each one has her/his one.
> >>
> >
> >
> > What your can do is display the list of forks and ask to select the
> right one. Then it will create the Pharo repo with the two remotes.
>
>
This would be strange. Pharo has 75 forks...


>
> I was going to suggest prompting for the git username.  You can
> substitute it in to:
>
> g...@github.com:{username}/pharo.git
>
> and add upstream (pharo-project).


Yes, and if it does not exist we have to use github's API to create the
fork...

It's doable... But doing it well will take time:
 - I would like a UI where I explain users what I will do with their git
credentials
 - I would like to prevent them that I'm doing a fork before doing it
 - I want to show a good progress bar
 - I want to wait until github's finished with the fork (it's an async
operation) before continuing with the process
 - And then, I want that if possible iceberg is well (automatically) tested
because there are so many corner cases that it starts to be really
complicated to do it manually.

But also our plate is full with other things, and we have to prioritize...

If someone wants to give it a try, I can give a hand, review, test,
advice...


>
>
> Cheers,
> 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] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Alistair Grant]

On 13 April 2018 at 17:07, Cyril Ferlicot  wrote:
>
>
> On ven. 13 avr. 2018 at 17:03, Guillermo Polito  
> wrote:
>>
>>
>> The thing is that the best way to do it is to clone your own fork... And 
>> each one has her/his one.
>>
>
>
> What your can do is display the list of forks and ask to select the right 
> one. Then it will create the Pharo repo with the two remotes.


I was going to suggest prompting for the git username.  You can
substitute it in to:

g...@github.com:{username}/pharo.git

and add upstream (pharo-project).


Cheers,
Alistair

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Cyril Ferlicot]

On ven. 13 avr. 2018 at 17:03, Guillermo Polito 
wrote:

>
> The thing is that the best way to do it is to clone your own fork... And
> each one has her/his one.
>
>

What your can do is display the list of forks and ask to select the right
one. Then it will create the Pharo repo with the two remotes.



> That's already there
>
>
>
>
> --
>
>
>
> 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
>
-- 
Cyril Ferlicot
https://ferlicot.fr

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Guillermo Polito]

On Fri, Apr 13, 2018 at 4:26 PM, Ben Coman  wrote:

>
>
> On 13 April 2018 at 21:14, Marcus Denker  wrote:
>
>>
>>
>> On 13 Apr 2018, at 15:04, Andrei Stebakov  wrote:
>>
>> Can you make the video available online?
>>
>>
>> https://youtu.be/A9H8jsSnBKM
>>
>
> I like the new "New Repo", particularly additional of GitHub alternative
> (not that I use them, but options is good)
> Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo"
> entry or similar
> which presets *everything* required to clone the Pharo repo.
>

The thing is that the best way to do it is to clone your own fork... And
each one has her/his one.


>
> Later, here you might even go as far as letting uses entry an Issue and
> pre-create the branch
> that a fix will be submitted on.  But for now... one step at a time.
>

That's already there


>
> cheers -ben
>
>


-- 



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] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Ben Coman]

On 13 April 2018 at 21:14, Marcus Denker  wrote:

>
>
> On 13 Apr 2018, at 15:04, Andrei Stebakov  wrote:
>
> Can you make the video available online?
>
>
> https://youtu.be/A9H8jsSnBKM
>

I like the new "New Repo", particularly additional of GitHub alternative
(not that I use them, but options is good)
Could you consider adding here a "Pharo Dev Repo" or "Contribute to Pharo"
entry or similar
which presets *everything* required to clone the Pharo repo.

Later, here you might even go as far as letting uses entry an Issue and
pre-create the branch
that a fix will be submitted on.  But for now... one step at a time.

cheers -ben

Re: [Pharo-dev] request Calypso added as a "project" in Fogbugz

[Sean P. DeNigris]

Ben Coman wrote
> However I have some concerns about scattering Issues away from Fogbugz
> since this makes it harder to get an overview of outstanding issues

Point taken, but:
- IIUC we will be soon moving to *all* github issues anyway
- duplication has it's own negative consequences
- There are significant benefits to GH issues for GH code like all the
auto-references (issues, commits, etc)



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [Pharo-users] [TechTalk] April 12: GIT with Iceberg

[Marcus Denker]

> On 13 Apr 2018, at 15:04, Andrei Stebakov  wrote:
> 
> Can you make the video available online?

https://youtu.be/A9H8jsSnBKM

> Another question, is there a tutorial on Iceberg?

For the updated UI not yet. From the “how do I commit a PR to Pharo” 
perspective, I will do next week:
-> an update to the description on the website how to commit to PR
-> Do a short video of how to do contribute to Paro7 (as a replacement 
of the video tutorial I did).


Marcus
> 
> On Thu, Apr 12, 2018, 03:10 Marcus Denker  > wrote:
> This is today 
> 
> 5:00 PM - 7:00 PM (UTC+02:00)
> 
> There is a calendar entry to download at: 
> https://association.pharo.org/event-2797068 
> 
> 
> > On 10 Apr 2018, at 16:34, Marcus Denker  > > wrote:
> > 
> > Hi,
> > 
> > There next TechTalk will be April 12: GIT with Iceberg
> > 
> >   https://association.pharo.org/event-2797068 
> > 
> > 
> > 
> > A regular chat about Pharo. Happens on Discord.
> > 
> > The Tech talks are open to both members and non-members! 
> > 
> > Topic:  GIT with Iceberg. Demo of improved UI
> > 
> > We will send an information to all subscribers some hours before the talk 
> > starts.
> > 
> > 
> 
> 

[Pharo-dev] [ANN] Pharo Sprint Apr 20

[Marcus Denker]

Pharo Sprint Apr 20

https://association.pharo.org/event-2789579

We will organize a Pharo sprint / Moose dojo Apr 20 , starting at
10:00am. (Local Time Paris).

Goals of this sprint:

• Pharo 7 issues

Remote Sprint
Remotely, you can join us on Discord. During the sprint, we synchronize 
local and remote Pharo sprinters:


Known Local Sprint meetings

Lille/France:
It will be at the Inria Lille, Building B, third floor (RMoD offices). 
As the building is not open to the public, please contact us before if you plan 
to come

[Pharo-dev] [Pharo 7.0-dev] Build #763: 21691-update-iceberg-to-072

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #763 was: SUCCESS.

The Pull Request #1192 was integrated: "21691-update-iceberg-to-072"
Pull request url: https://github.com/pharo-project/pharo/pull/1192

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

Re: [Pharo-dev] [ANN] New VM stables promoted

[Tudor Girba]

Sounds good. Thanks for the explanation and for all the effort!

Doru

> On Apr 13, 2018, at 12:40 PM, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 13 Apr 2018, at 12:35, Tudor Girba  wrote:
>> 
>> Hi,
>> 
>> A question: do we need to revert all VMs if only the Linux 32 is not 
>> working? Do we prefer to release all together because it is easier to manage?
> 
> yes, is because otherwise is a mess to manage.
> but you can always use vmLatest instead stable, if you want to use a better 
> version on your platform.
> 
> cheers,
> Esteban
> 
>> 
>> Cheers,
>> Doru
>> 
>>> On Apr 13, 2018, at 12:28 PM, Esteban Lorenzano  wrote:
>>> 
>>> 
>>> 
 On 13 Apr 2018, at 12:12, Alistair Grant  wrote:
 
 On 13 April 2018 at 12:02, Esteban Lorenzano  wrote:
> 
> 
>> On 13 Apr 2018, at 11:57, Alistair Grant  wrote:
>> 
>> Hi Esteban,
>> 
>> I don't know whether you also updated the 6.1 VMs, but for the Pharo 7
>> VMs could you consider only reverting the linux 32 bit VM?
> 
> I reverted all.
> And I started to check the linux problem.
 
 OK.  Just for reference, linux 64 bits on Ubuntu 16.04 is fine so far. :-)
>>> 
>>> yes I knew it :P
>>> 
>>> Esteban
>>> 
 
 Cheers,
 Alistair
 
 
 
> cheers!
> Esteban
> 
> ps: I think I will separate dependency build from vm build, as I talked 
> with Nico and Eliot before… this is too much and no reason to keep having 
> problems just because a dependency breaks (dependencies should not be 
> built all the time anyway).
> 
>> 
>> Pharo 7 is alpha, so anyone (well, most people :-)) using it are
>> prepared for a few hiccups, and it will provide better confidence when
>> you do the next update.
>> 
>> Thanks,
>> Alistair
>> 
>> 
>> On 13 April 2018 at 11:53, Esteban Lorenzano  wrote:
>>> 
>>> 
>>> On 13 Apr 2018, at 11:50, Esteban Lorenzano  wrote:
>>> 
>>> meh… and I will be to revert again.
>>> 
>>> I will *need* to revert, I meant.
>>> 
>>> Esteban
>>> 
>>> 
>>> linux 32 VM libgit2 is not working, it seems.
>>> 
>>> I will revert.
>>> And I will do an stop the world to fix the VM dependency problems 
>>> because
>>> this is too much.
>>> 
>>> Next week, updates of iceberg will come from Guille’s hand, I will be
>>> working on VM-side.
>>> 
>>> cheers,
>>> Esteban
>>> 
>>> On 13 Apr 2018, at 10:42, Esteban Lorenzano  wrote:
>>> 
>>> 
>>> 
>>> On 13 Apr 2018, at 10:31, Serge Stinckwich 
>>> wrote:
>>> 
>>> Thank you Esteban. Including 7.0 64 bits ?
>>> 
>>> 
>>> All VMs.
>>> (Still not 64bit windows, sorry)
>>> 
>>> Esteban
>>> 
>>> 
>>> On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano 
>>> wrote:
 
 Hi,
 
 I just promoted new VMs as stable.
 
 This are the builds corresponding to:
 
 20180416 (07c6dc3)
 
 this passed the build tests so *it should* be ok.
 
 can you people test?
 
 thanks!
 
 Esteban
 
>>> 
>>> 
>>> 
>>> --
>>> Serge Stinckwich
>>> UMI UMMISCO 209 (SU/IRD/UY1)
>>> "Programs must be written for people to read, and only incidentally for
>>> machines to execute."
>>> http://www.doesnotunderstand.org/
>> 
>> --
>> www.tudorgirba.com
>> www.feenk.com
>> 
>> "To utilize feedback, you first have to acquire it."
>> 
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Quality cannot be an afterthought."

Re: [Pharo-dev] [ANN] New VM stables promoted

[Esteban Lorenzano]

> On 13 Apr 2018, at 12:35, Tudor Girba  wrote:
> 
> Hi,
> 
> A question: do we need to revert all VMs if only the Linux 32 is not working? 
> Do we prefer to release all together because it is easier to manage?

yes, is because otherwise is a mess to manage.
but you can always use vmLatest instead stable, if you want to use a better 
version on your platform.

cheers,
Esteban

> 
> Cheers,
> Doru
> 
>> On Apr 13, 2018, at 12:28 PM, Esteban Lorenzano  wrote:
>> 
>> 
>> 
>>> On 13 Apr 2018, at 12:12, Alistair Grant  wrote:
>>> 
>>> On 13 April 2018 at 12:02, Esteban Lorenzano  wrote:
 
 
> On 13 Apr 2018, at 11:57, Alistair Grant  wrote:
> 
> Hi Esteban,
> 
> I don't know whether you also updated the 6.1 VMs, but for the Pharo 7
> VMs could you consider only reverting the linux 32 bit VM?
 
 I reverted all.
 And I started to check the linux problem.
>>> 
>>> OK.  Just for reference, linux 64 bits on Ubuntu 16.04 is fine so far. :-)
>> 
>> yes I knew it :P
>> 
>> Esteban
>> 
>>> 
>>> Cheers,
>>> Alistair
>>> 
>>> 
>>> 
 cheers!
 Esteban
 
 ps: I think I will separate dependency build from vm build, as I talked 
 with Nico and Eliot before… this is too much and no reason to keep having 
 problems just because a dependency breaks (dependencies should not be 
 built all the time anyway).
 
> 
> Pharo 7 is alpha, so anyone (well, most people :-)) using it are
> prepared for a few hiccups, and it will provide better confidence when
> you do the next update.
> 
> Thanks,
> Alistair
> 
> 
> On 13 April 2018 at 11:53, Esteban Lorenzano  wrote:
>> 
>> 
>> On 13 Apr 2018, at 11:50, Esteban Lorenzano  wrote:
>> 
>> meh… and I will be to revert again.
>> 
>> I will *need* to revert, I meant.
>> 
>> Esteban
>> 
>> 
>> linux 32 VM libgit2 is not working, it seems.
>> 
>> I will revert.
>> And I will do an stop the world to fix the VM dependency problems because
>> this is too much.
>> 
>> Next week, updates of iceberg will come from Guille’s hand, I will be
>> working on VM-side.
>> 
>> cheers,
>> Esteban
>> 
>> On 13 Apr 2018, at 10:42, Esteban Lorenzano  wrote:
>> 
>> 
>> 
>> On 13 Apr 2018, at 10:31, Serge Stinckwich 
>> wrote:
>> 
>> Thank you Esteban. Including 7.0 64 bits ?
>> 
>> 
>> All VMs.
>> (Still not 64bit windows, sorry)
>> 
>> Esteban
>> 
>> 
>> On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I just promoted new VMs as stable.
>>> 
>>> This are the builds corresponding to:
>>> 
>>> 20180416 (07c6dc3)
>>> 
>>> this passed the build tests so *it should* be ok.
>>> 
>>> can you people test?
>>> 
>>> thanks!
>>> 
>>> Esteban
>>> 
>> 
>> 
>> 
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (SU/IRD/UY1)
>> "Programs must be written for people to read, and only incidentally for
>> machines to execute."
>> http://www.doesnotunderstand.org/
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "To utilize feedback, you first have to acquire it."
> 
> 

Re: [Pharo-dev] [ANN] New VM stables promoted

[Esteban Lorenzano]

> On 13 Apr 2018, at 11:57, Alistair Grant  wrote:
> 
> Hi Esteban,
> 
> I don't know whether you also updated the 6.1 VMs, but for the Pharo 7
> VMs could you consider only reverting the linux 32 bit VM?

I reverted all.
And I started to check the linux problem.

cheers!
Esteban

ps: I think I will separate dependency build from vm build, as I talked with 
Nico and Eliot before… this is too much and no reason to keep having problems 
just because a dependency breaks (dependencies should not be built all the time 
anyway).

> 
> Pharo 7 is alpha, so anyone (well, most people :-)) using it are
> prepared for a few hiccups, and it will provide better confidence when
> you do the next update.
> 
> Thanks,
> Alistair
> 
> 
> On 13 April 2018 at 11:53, Esteban Lorenzano  wrote:
>> 
>> 
>> On 13 Apr 2018, at 11:50, Esteban Lorenzano  wrote:
>> 
>> meh… and I will be to revert again.
>> 
>> I will *need* to revert, I meant.
>> 
>> Esteban
>> 
>> 
>> linux 32 VM libgit2 is not working, it seems.
>> 
>> I will revert.
>> And I will do an stop the world to fix the VM dependency problems because
>> this is too much.
>> 
>> Next week, updates of iceberg will come from Guille’s hand, I will be
>> working on VM-side.
>> 
>> cheers,
>> Esteban
>> 
>> On 13 Apr 2018, at 10:42, Esteban Lorenzano  wrote:
>> 
>> 
>> 
>> On 13 Apr 2018, at 10:31, Serge Stinckwich 
>> wrote:
>> 
>> Thank you Esteban. Including 7.0 64 bits ?
>> 
>> 
>> All VMs.
>> (Still not 64bit windows, sorry)
>> 
>> Esteban
>> 
>> 
>> On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano 
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I just promoted new VMs as stable.
>>> 
>>> This are the builds corresponding to:
>>> 
>>> 20180416 (07c6dc3)
>>> 
>>> this passed the build tests so *it should* be ok.
>>> 
>>> can you people test?
>>> 
>>> thanks!
>>> 
>>> Esteban
>>> 
>> 
>> 
>> 
>> --
>> Serge Stinckwich
>> UMI UMMISCO 209 (SU/IRD/UY1)
>> "Programs must be written for people to read, and only incidentally for
>> machines to execute."
>> http://www.doesnotunderstand.org/
>> 
>> 
>> 
>> 
> 

Re: [Pharo-dev] [ANN] New VM stables promoted

[Alistair Grant]

Hi Esteban,

I don't know whether you also updated the 6.1 VMs, but for the Pharo 7
VMs could you consider only reverting the linux 32 bit VM?

Pharo 7 is alpha, so anyone (well, most people :-)) using it are
prepared for a few hiccups, and it will provide better confidence when
you do the next update.

Thanks,
Alistair


On 13 April 2018 at 11:53, Esteban Lorenzano  wrote:
>
>
> On 13 Apr 2018, at 11:50, Esteban Lorenzano  wrote:
>
> meh… and I will be to revert again.
>
> I will *need* to revert, I meant.
>
> Esteban
>
>
> linux 32 VM libgit2 is not working, it seems.
>
> I will revert.
> And I will do an stop the world to fix the VM dependency problems because
> this is too much.
>
> Next week, updates of iceberg will come from Guille’s hand, I will be
> working on VM-side.
>
> cheers,
> Esteban
>
> On 13 Apr 2018, at 10:42, Esteban Lorenzano  wrote:
>
>
>
> On 13 Apr 2018, at 10:31, Serge Stinckwich 
> wrote:
>
> Thank you Esteban. Including 7.0 64 bits ?
>
>
> All VMs.
> (Still not 64bit windows, sorry)
>
> Esteban
>
>
> On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano 
> wrote:
>>
>> Hi,
>>
>> I just promoted new VMs as stable.
>>
>> This are the builds corresponding to:
>>
>> 20180416 (07c6dc3)
>>
>> this passed the build tests so *it should* be ok.
>>
>> can you people test?
>>
>> thanks!
>>
>> Esteban
>>
>
>
>
> --
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for
> machines to execute."
> http://www.doesnotunderstand.org/
>
>
>
>

Re: [Pharo-dev] [ANN] New VM stables promoted

[Esteban Lorenzano]

> On 13 Apr 2018, at 11:50, Esteban Lorenzano  wrote:
> 
> meh… and I will be to revert again.
I will *need* to revert, I meant.

Esteban

> 
> linux 32 VM libgit2 is not working, it seems.
> 
> I will revert.
> And I will do an stop the world to fix the VM dependency problems because 
> this is too much.
> 
> Next week, updates of iceberg will come from Guille’s hand, I will be working 
> on VM-side.
> 
> cheers,
> Esteban
> 
>> On 13 Apr 2018, at 10:42, Esteban Lorenzano > > wrote:
>> 
>> 
>> 
>>> On 13 Apr 2018, at 10:31, Serge Stinckwich >> > wrote:
>>> 
>>> Thank you Esteban. Including 7.0 64 bits ?
>> 
>> All VMs. 
>> (Still not 64bit windows, sorry)
>> 
>> Esteban
>> 
>>> 
>>> On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano >> > wrote:
>>> Hi, 
>>> 
>>> I just promoted new VMs as stable.
>>> 
>>> This are the builds corresponding to: 
>>> 
>>> 20180416 (07c6dc3)
>>> 
>>> this passed the build tests so *it should* be ok. 
>>> 
>>> can you people test?
>>> 
>>> thanks!
>>> 
>>> Esteban
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Serge Stinckwich
>>> UMI UMMISCO 209 (SU/IRD/UY1)
>>> "Programs must be written for people to read, and only incidentally for 
>>> machines to execute."
>>> http://www.doesnotunderstand.org/ 
> 

Re: [Pharo-dev] [ANN] New VM stables promoted

[Esteban Lorenzano]

meh… and I will be to revert again.

linux 32 VM libgit2 is not working, it seems.

I will revert.
And I will do an stop the world to fix the VM dependency problems because this 
is too much.

Next week, updates of iceberg will come from Guille’s hand, I will be working 
on VM-side.

cheers,
Esteban

> On 13 Apr 2018, at 10:42, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 13 Apr 2018, at 10:31, Serge Stinckwich > > wrote:
>> 
>> Thank you Esteban. Including 7.0 64 bits ?
> 
> All VMs. 
> (Still not 64bit windows, sorry)
> 
> Esteban
> 
>> 
>> On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano > > wrote:
>> Hi, 
>> 
>> I just promoted new VMs as stable.
>> 
>> This are the builds corresponding to: 
>> 
>> 20180416 (07c6dc3)
>> 
>> this passed the build tests so *it should* be ok. 
>> 
>> can you people test?
>> 
>> thanks!
>> 
>> Esteban
>> 
>> 
>> 
>> 
>> -- 
>> Serge Stinckwich
>> UMI UMMISCO 209 (SU/IRD/UY1)
>> "Programs must be written for people to read, and only incidentally for 
>> machines to execute."
>> http://www.doesnotunderstand.org/ 

Re: [Pharo-dev] request Calypso added as a "project" in Fogbugz

[Marcus Denker]

> On 13 Apr 2018, at 11:28, Ben Coman  wrote:
> 
> Can Calypso be added as a "project" in Fogbugz?
> I went to create an issue but could not find an appropriate place to file it 
> under.
> 
I added it.


> As a backup I add an issue to the github tracker...
> https://github.com/dionisiydk/Calypso/issues/235 
> 
> 
> However I have some concerns about scattering Issues away from Fogbugz
> since this makes it harder to get an overview of outstanding issues
> (particularly leading up to a Release),  and also the github tracker
> doesn't have priorities.
> 
> fyi, here is the report...
> In Pharo 60540, using Nautilus to view the Delay class definition,
> selecting class variable 'Scheduler' > right-click > Code search > references 
> to it
> produces 13 results.
> 
> In Pharo-7.0+alpha.build.762.sha.0e0fe47c5 doing the same with Calypso
> produces 0 results. It still works with Nautilus.
> 
> cheers -ben

[Pharo-dev] request Calypso added as a "project" in Fogbugz

[Ben Coman]

Can Calypso be added as a "project" in Fogbugz?
I went to create an issue but could not find an appropriate place to file
it under.

As a backup I add an issue to the github tracker...
https://github.com/dionisiydk/Calypso/issues/235

However I have some concerns about scattering Issues away from Fogbugz
since this makes it harder to get an overview of outstanding issues
(particularly leading up to a Release),  and also the github tracker
doesn't have priorities.

fyi, here is the report...
In Pharo 60540, using Nautilus to view the Delay class definition,
selecting class variable 'Scheduler' > right-click > Code search >
references to it
produces 13 results.

In Pharo-7.0+alpha.build.762.sha.0e0fe47c5 doing the same with Calypso
produces 0 results. It still works with Nautilus.

cheers -ben

Re: [Pharo-dev] [ANN] New VM stables promoted

[Esteban Lorenzano]

> On 13 Apr 2018, at 10:31, Serge Stinckwich  wrote:
> 
> Thank you Esteban. Including 7.0 64 bits ?

All VMs. 
(Still not 64bit windows, sorry)

Esteban

> 
> On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano  > wrote:
> Hi, 
> 
> I just promoted new VMs as stable.
> 
> This are the builds corresponding to: 
> 
> 20180416 (07c6dc3)
> 
> this passed the build tests so *it should* be ok. 
> 
> can you people test?
> 
> thanks!
> 
> Esteban
> 
> 
> 
> 
> -- 
> Serge Stinckwich
> UMI UMMISCO 209 (SU/IRD/UY1)
> "Programs must be written for people to read, and only incidentally for 
> machines to execute."
> http://www.doesnotunderstand.org/ 

Re: [Pharo-dev] [ANN] New VM stables promoted

[Serge Stinckwich]

Thank you Esteban. Including 7.0 64 bits ?

On Fri, Apr 13, 2018 at 8:55 AM, Esteban Lorenzano 
wrote:

> Hi,
>
> I just promoted new VMs as stable.
>
> This are the builds corresponding to:
>
> 20180416 (07c6dc3)
>
> this passed the build tests so *it should* be ok.
>
> can you people test?
>
> thanks!
>
> Esteban
>
>


-- 
Serge Stinckwich
UMI UMMISCO 209 (SU/IRD/UY1)
"Programs must be written for people to read, and only incidentally for
machines to execute."http://www.doesnotunderstand.org/

Re: [Pharo-dev] [ANN] New VM stables promoted

[Tudor Girba]

Yuuppeee!

I will test the 64bit right away.

Thanks,
Doru

> On Apr 13, 2018, at 9:55 AM, Esteban Lorenzano  wrote:
> 
> Hi, 
> 
> I just promoted new VMs as stable.
> 
> This are the builds corresponding to: 
> 
> 20180416 (07c6dc3)
> 
> this passed the build tests so *it should* be ok. 
> 
> can you people test?
> 
> thanks!
> 
> Esteban
> 

--
www.tudorgirba.com
www.feenk.com

"Beauty is where we see it."

[Pharo-dev] [ANN] New VM stables promoted

[Esteban Lorenzano]

Hi, 

I just promoted new VMs as stable.

This are the builds corresponding to: 

20180416 (07c6dc3)

this passed the build tests so *it should* be ok. 

can you people test?

thanks!

Esteban