[Pharo-users] Re: Loading from a git repository with Metacello on a running seaside image

[Emilio Oca]

Hey,

Breaking the ice, by following the logic behind 'Pull' button at 'Working
copy of..." from iceberg repo UI, I found I can put this:

aRemote := IceGitRemote name: 'origin' url: '
https://github.com/User/MyProject.git'.
aRemote localRepository: (IceRepository registry detect: [ :each | each
includesPackageNamed: 'MyProject' ]).
localBranch := IceGitLocalBranch named: 'refs/heads/main' inRepository:
aRemote localRepository.
aRemote fetchBranch: localBranch.
remoteBranch := aRemote remoteBranchNamed: localBranch name ifAbsent: [ ].
aRemote localRepository workingCopy mergeCommit: remoteBranch commit.

under a seaside anchor callback and get the running image self update.

I still have to make it work within docker, but it is a start.

Thanks all
Best

Emilio

On Fri, Apr 29, 2022 at 8:01 PM Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> Emilio,
>
> Okay ... we're peeling the onion :) ...
>
> At this point it sounds like you need to do a flushCache on your filetree
> repository in order to force Metacello to re-download from the github into
> the local package-cache.
>
> But if Iceberg is involved, I am not the person to ask ... I am not
> familiar with the changes that have been made to Metacello to get it to
> work with Iceberg ...
>
> Dale
>
>
>
> On Fri, Apr 29, 2022 at 3:16 PM Emilio Oca  wrote:
>
>> Hi Dale
>>
>> Thanks again, still not working.
>> After updating github I am unable to pull the changes into the image.
>> So far the only way is to hit Pull button at the "Working copy of
>> MyProyect" repo window.
>> I wish I could reproduce what that button does.
>>
>> Even this:
>> Metacello new
>> repository: 'github://...';
>> baseline: 'MyProyect';
>> get
>> does not update my file system at iceberg/
>>
>> Best
>>
>> Emilio
>>
>> On Thu, Apr 28, 2022 at 3:29 PM Dale Henrichs <
>> dale.henri...@gemtalksystems.com> wrote:
>>
>>> Emilio,
>>>
>>> I wasn't quite sure whether or not you were concerned about having the
>>> BaselineOf refreshed or a reload of the packages managed by the BaselineOf
>>> and as Gabriel mentions, the missing #projectClass method is the most
>>> common problem ...
>>>
>>> By default Metacello does not refresh a BaselieOf in your image if it is
>>> already present, however, you can force a refresh of a BaselineOf by using
>>> the the Metcello #get command:
>>>
 Metacello new baseline:'MyProject';
   repository: 'github://myUser/MyProject:main/myProject';
   get;
   load.
>>>
>>> This would be a good pattern to follow when reloading projects after
>>> updating from github ... and I am a bit surprised that this question is not
>>> asked more often :)
>>>
>>> Dale
>>>
>>> On Mon, Apr 25, 2022 at 6:06 PM Emilio Oca  wrote:
>>>
 Hi Gabriel, Dale!

 My BaselineOf had only #baseline:
 Added #projectClass
 But is still not working.
 It seems to be doing the load, but not the pull before the load.

 I had implemented no more than #baseLine: and now projectClass.

 If I go through the UI and do the pull it works perfectly.
 Can I replicate that with a script?

 Best

 Emilio

 On Mon, Apr 25, 2022 at 6:49 PM Dale Henrichs <
 dale.henri...@gemtalksystems.com> wrote:

> Emilio,
>
> Are you using a repository without Monticello meta data? If so, then
> you need to change the #projectClass of you your baseline to:
>
>> projectClass
>>   Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl |
>> ^ cl ].
>>   ^ super projectClass
>
>
> unless the #projectClass is MetacelloCypressBaselineProject, Metacello
> will think that your package versions are 'cypress.1' and Metacello will
> not load packages with the same version  when the #projectClass is
> MetacelloCypressBaselineProject, Metacello will always load the package 
> and
> let Monticello filter out the changes ...
>
> Dale
>
> On Mon, Apr 25, 2022 at 2:39 PM Esteban Lorenzano 
> wrote:
>
>> mmm, you may be having another problem elsewhere, because what I
>> typed should be working (is how we enforce the load of new versions to 
>> run
>> the tests, for example).
>>
>> Esteban
>>
>> On Apr 25 2022, at 11:30 pm, Emilio Oca  wrote:
>>
>> Hi Esteban
>>
>> Thanks for the hint.
>> It is still not working.
>> Even if I remove BaselineOfMyProject and MyProject.
>> When it reloads, it doesn't loads the last version of head at github
>> but the one that was already at the image.
>>
>> I just want to update up to what is at gibhub head. Is there another
>> way?
>>
>> Best
>>
>> Emilio
>>
>> On Sat, Apr 23, 2022 at 1:56 AM Esteban Lorenzano 
>> wrote:
>>
>> Hi Emilio,
>>
>> You need something like this:
>>
>>   Metacello new
>> repository: 'github://pharo-spec/Spec:Pharo10';

[Pharo-users] Re: [Pharo-dev] [ANN] Pharo Launcher 3.0.1 released!

[Shaping]

PL 3.0.1 is still failing to open on Windows.   The VM instance appears in
TaskMan.

 

Shaping

 

From: Christophe Demarey  
Sent: Friday, 29 April, 2022 03:50
To: Pharo Development List ; Pharo-users

Subject: [Pharo-dev] [ANN] Pharo Launcher 3.0.1 released!

 

Hi all,

Pharo Launcher 3.0.1 has just been released! It is available from
http://pharo.org/download.

It fixes some issues reported on Pharo Launcher 3.0.


Here is the changelog:
Pharo Launcher v3.0.1

Bug fixes:

*   #554 
UI does not show up on Windows
*   #551 
Show folder button is broken in Windows 10
*   #550 
About Box shows "untitled Window"
*   #549 
Better display of download error messages.
*   #358 
Restore proxy authentication settings.


Regards,
The Pharo team.

[Pharo-users] Re: Loading from a git repository with Metacello on a running seaside image

[Dale Henrichs]

Emilio,

Okay ... we're peeling the onion :) ...

At this point it sounds like you need to do a flushCache on your filetree
repository in order to force Metacello to re-download from the github into
the local package-cache.

But if Iceberg is involved, I am not the person to ask ... I am not
familiar with the changes that have been made to Metacello to get it to
work with Iceberg ...

Dale



On Fri, Apr 29, 2022 at 3:16 PM Emilio Oca  wrote:

> Hi Dale
>
> Thanks again, still not working.
> After updating github I am unable to pull the changes into the image.
> So far the only way is to hit Pull button at the "Working copy of
> MyProyect" repo window.
> I wish I could reproduce what that button does.
>
> Even this:
> Metacello new
> repository: 'github://...';
> baseline: 'MyProyect';
> get
> does not update my file system at iceberg/
>
> Best
>
> Emilio
>
> On Thu, Apr 28, 2022 at 3:29 PM Dale Henrichs <
> dale.henri...@gemtalksystems.com> wrote:
>
>> Emilio,
>>
>> I wasn't quite sure whether or not you were concerned about having the
>> BaselineOf refreshed or a reload of the packages managed by the BaselineOf
>> and as Gabriel mentions, the missing #projectClass method is the most
>> common problem ...
>>
>> By default Metacello does not refresh a BaselieOf in your image if it is
>> already present, however, you can force a refresh of a BaselineOf by using
>> the the Metcello #get command:
>>
>>> Metacello new baseline:'MyProject';
>>>   repository: 'github://myUser/MyProject:main/myProject';
>>>   get;
>>>   load.
>>
>> This would be a good pattern to follow when reloading projects after
>> updating from github ... and I am a bit surprised that this question is not
>> asked more often :)
>>
>> Dale
>>
>> On Mon, Apr 25, 2022 at 6:06 PM Emilio Oca  wrote:
>>
>>> Hi Gabriel, Dale!
>>>
>>> My BaselineOf had only #baseline:
>>> Added #projectClass
>>> But is still not working.
>>> It seems to be doing the load, but not the pull before the load.
>>>
>>> I had implemented no more than #baseLine: and now projectClass.
>>>
>>> If I go through the UI and do the pull it works perfectly.
>>> Can I replicate that with a script?
>>>
>>> Best
>>>
>>> Emilio
>>>
>>> On Mon, Apr 25, 2022 at 6:49 PM Dale Henrichs <
>>> dale.henri...@gemtalksystems.com> wrote:
>>>
 Emilio,

 Are you using a repository without Monticello meta data? If so, then
 you need to change the #projectClass of you your baseline to:

> projectClass
>   Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl |
> ^ cl ].
>   ^ super projectClass


 unless the #projectClass is MetacelloCypressBaselineProject, Metacello
 will think that your package versions are 'cypress.1' and Metacello will
 not load packages with the same version  when the #projectClass is
 MetacelloCypressBaselineProject, Metacello will always load the package and
 let Monticello filter out the changes ...

 Dale

 On Mon, Apr 25, 2022 at 2:39 PM Esteban Lorenzano 
 wrote:

> mmm, you may be having another problem elsewhere, because what I typed
> should be working (is how we enforce the load of new versions to run the
> tests, for example).
>
> Esteban
>
> On Apr 25 2022, at 11:30 pm, Emilio Oca  wrote:
>
> Hi Esteban
>
> Thanks for the hint.
> It is still not working.
> Even if I remove BaselineOfMyProject and MyProject.
> When it reloads, it doesn't loads the last version of head at github
> but the one that was already at the image.
>
> I just want to update up to what is at gibhub head. Is there another
> way?
>
> Best
>
> Emilio
>
> On Sat, Apr 23, 2022 at 1:56 AM Esteban Lorenzano 
> wrote:
>
> Hi Emilio,
>
> You need something like this:
>
>   Metacello new
> repository: 'github://pharo-spec/Spec:Pharo10';
> baseline: 'Spec2';
> onConflict: [ :e | e useIncoming ];
> onUpgrade: [ :e | e useIncoming ];
> ignoreImage;
> load
>
> ignoreImage, onConflict, onUpgrade.
>
> BUT if your image already has a baseline for your project then
> Metacello will not reload it (hence your project may not be loaded
> correctly, since baseline may have changed).
>
> In that case, I always execute before something like:
>
> #( 'BaselineOfSpec2' 'BaselineOfSpecCore' ) do: [ :each |
>   (RPackageOrganizer default packageNamed: each ifAbsent: [ nil ])
>   ifNotNil: [ :aPackage | aPackage removeFromSystem ] ]
>
>
> I ack this is hacky, but it works :)
>
> Esteban
>
> On Apr 23 2022, at 3:21 am, Emilio Oca  wrote:
>
> Hi List
>
> I need some help with Metacello, and may be git too
>
> I would like to be able to, in a running headless image, load the last
> commit of a git re

[Pharo-users] Re: Loading from a git repository with Metacello on a running seaside image

[Emilio Oca]

Hi Dale

Thanks again, still not working.
After updating github I am unable to pull the changes into the image.
So far the only way is to hit Pull button at the "Working copy of
MyProyect" repo window.
I wish I could reproduce what that button does.

Even this:
Metacello new
repository: 'github://...';
baseline: 'MyProyect';
get
does not update my file system at iceberg/

Best

Emilio

On Thu, Apr 28, 2022 at 3:29 PM Dale Henrichs <
dale.henri...@gemtalksystems.com> wrote:

> Emilio,
>
> I wasn't quite sure whether or not you were concerned about having the
> BaselineOf refreshed or a reload of the packages managed by the BaselineOf
> and as Gabriel mentions, the missing #projectClass method is the most
> common problem ...
>
> By default Metacello does not refresh a BaselieOf in your image if it is
> already present, however, you can force a refresh of a BaselineOf by using
> the the Metcello #get command:
>
>> Metacello new baseline:'MyProject';
>>   repository: 'github://myUser/MyProject:main/myProject';
>>   get;
>>   load.
>
> This would be a good pattern to follow when reloading projects after
> updating from github ... and I am a bit surprised that this question is not
> asked more often :)
>
> Dale
>
> On Mon, Apr 25, 2022 at 6:06 PM Emilio Oca  wrote:
>
>> Hi Gabriel, Dale!
>>
>> My BaselineOf had only #baseline:
>> Added #projectClass
>> But is still not working.
>> It seems to be doing the load, but not the pull before the load.
>>
>> I had implemented no more than #baseLine: and now projectClass.
>>
>> If I go through the UI and do the pull it works perfectly.
>> Can I replicate that with a script?
>>
>> Best
>>
>> Emilio
>>
>> On Mon, Apr 25, 2022 at 6:49 PM Dale Henrichs <
>> dale.henri...@gemtalksystems.com> wrote:
>>
>>> Emilio,
>>>
>>> Are you using a repository without Monticello meta data? If so, then you
>>> need to change the #projectClass of you your baseline to:
>>>
 projectClass
   Smalltalk at: #'MetacelloCypressBaselineProject' ifPresent: [ :cl | ^
 cl ].
   ^ super projectClass
>>>
>>>
>>> unless the #projectClass is MetacelloCypressBaselineProject, Metacello
>>> will think that your package versions are 'cypress.1' and Metacello will
>>> not load packages with the same version  when the #projectClass is
>>> MetacelloCypressBaselineProject, Metacello will always load the package and
>>> let Monticello filter out the changes ...
>>>
>>> Dale
>>>
>>> On Mon, Apr 25, 2022 at 2:39 PM Esteban Lorenzano 
>>> wrote:
>>>
 mmm, you may be having another problem elsewhere, because what I typed
 should be working (is how we enforce the load of new versions to run the
 tests, for example).

 Esteban

 On Apr 25 2022, at 11:30 pm, Emilio Oca  wrote:

 Hi Esteban

 Thanks for the hint.
 It is still not working.
 Even if I remove BaselineOfMyProject and MyProject.
 When it reloads, it doesn't loads the last version of head at github
 but the one that was already at the image.

 I just want to update up to what is at gibhub head. Is there another
 way?

 Best

 Emilio

 On Sat, Apr 23, 2022 at 1:56 AM Esteban Lorenzano 
 wrote:

 Hi Emilio,

 You need something like this:

   Metacello new
 repository: 'github://pharo-spec/Spec:Pharo10';
 baseline: 'Spec2';
 onConflict: [ :e | e useIncoming ];
 onUpgrade: [ :e | e useIncoming ];
 ignoreImage;
 load

 ignoreImage, onConflict, onUpgrade.

 BUT if your image already has a baseline for your project then
 Metacello will not reload it (hence your project may not be loaded
 correctly, since baseline may have changed).

 In that case, I always execute before something like:

 #( 'BaselineOfSpec2' 'BaselineOfSpecCore' ) do: [ :each |
(RPackageOrganizer default packageNamed: each ifAbsent: [ nil ])
ifNotNil: [ :aPackage | aPackage removeFromSystem ] ]


 I ack this is hacky, but it works :)

 Esteban

 On Apr 23 2022, at 3:21 am, Emilio Oca  wrote:

 Hi List

 I need some help with Metacello, and may be git too

 I would like to be able to, in a running headless image, load the last
 commit of a git repo

 Something like
 Metacello new baseline:'MyProject';
 repository: 'github://myUser/MyProject:main/myProject';
 load.
 works just once and may open some dialogs

 Something like this
 [
 [
 Metacello new baseline:'MyProject';
 repository: 'github://myUser/MyProject:main/myProject';
 onConflictUseIncoming;
 load.
 ] on: MetacelloSkipDirtyPackageLoad do: [ :ex | ex resume: false ].
 ] on: MCMergeOrLoadWarning do: [ :ex | ex load ].
 Avoids the dialogs and alerts but the code is still not updated.

 My intention is to be able to '

[Pharo-users] Re: A question about #beginsWith: and #endsWith:

[Kasper Osterbye]

The two methods are changed to do the right thing.
We are still waiting for the CI server to check if that broke anything.

During the change, 4 places was identified which was simplified by doing it 
right (aka empty prefix always true).

Best,

Kasper

[Pharo-users] Re: A question about #beginsWith: and #endsWith:

[Richard Sargent]

Making the code correct is "untwisting the rope".
Keeping the code wrong and adding a bizarre workaround is "twisting the
rope tighter".

The former is the right direction.

On Fri, Apr 29, 2022 at 12:15 AM Steffen Märcker  wrote:

> Hi Kasper,
>
> I've thought about that approach too. But then asked myself whether it is
> more likely that there is code that relies on this bug than code where this
> went unnoticed and is therefore broken. What do the other think about that
> matter and the fix in Squeak?
>
> Best, Steffen
>
>
>
>
> Kasper Osterbye schrieb am Donnerstag, 28. April 2022 19:03:07 (+02:00):
>
> Kasper Osterbye schrieb am Dienstag, 26. April 2022 14:50:51 (+02:00):
>
> I have now raised it as an issue on the issue tracker
>
> Issue #11165  in
> https://github.com/pharo-project/pharo/issues/11165
>
>
> If I may suggest a solution it will be to:
>
>- add two new methods - *prefixedBy: * and *suffixedBy:* to handle the
>empty prefix/suffix correctly
>- add comments to *beginsWith: * and *endsWith: * referring to the two
>new methods
>
>
> The problem is that there is client code which depend on the (wrong)
> implementation of the beginsWith and endsWith methods.
>
>
>

[Pharo-users] Re: [Pharo-dev] [ANN] Pharo Launcher 3.0 released!

[Christophe Demarey]

Hi Jimmie,

Thank you for your feedback.
Could you open a feature request on 
https://github.com/pharo-project/pharo-launcher/issues 
 ?

Regards,
Christophe

> Le 29 avr. 2022 à 11:23, Jimmie Houchin  a écrit :
> 
> Hello,
> 
> Thanks for all your work. I have only recently started using Pharo Launcher. 
> I have been using Pharo a long time and was very accustomed to managing my 
> own images. So I am still learning. It is nice to work with and it is nice to 
> easily have whichever vm or image you are wanting to start with.
> 
> However I would like one thing if possible. The advantage I had when managing 
> my own and I can do a combination. Is that I always started a new terminal 
> and then opened up Pharo and whichever image I wanted. This makes it neat and 
> clean when running multiple images like I do, to have clean messaging and 
> clean stdio when I write to stdio. With Pharo Launcher all stdio goes to its 
> terminal and from whichever image has been started. I don't know how 
> difficult this would be. But it would be nice if they were an option for 
> Pharo Launcher to startup the new image from its own new terminal. Just an 
> idea.
> 
> Again. Thanks for all the work you do.
> 
> Jimmie
> 
> 
> 
> On 4/14/22 07:26, Christophe Demarey wrote:
>> Hi all,
>> 
>> Pharo Launcher 3.0 has just been released! It is available from 
>> http://pharo.org/download .
>> It is based on latest Spec2 and Pharo 10 image.
>> It now comes with a native Apple Silicon version and Mac OS packages are 
>> notarized.
>> Big thanks to all contributors, including issue reports. 
>> 
>> Here is the changelog:
>> Pharo Launcher v3.0
>> New features:
>> 
>> Full rewrite of the UI using Spec 2 and Pharo 10
>> Pharo Launcher can now run natively on Apple Silicon #544 
>> 
>> Pharo Launcher is now signed with a Mac Os developper account and notarized 
>> #529 
>> Windows "portable" package (only an archive without installer) #534 
>> 
>> Improvements:
>> 
>> While importing image .sources and .version are not moved #543 
>> 
>> recreate the image does not re apply the script if one is provided #536 
>>  (thanks to 
>> @hogoww )
>> Save keybind for scripts #545 
>>  (thanks to 
>> @hogoww  and @Inao0 )
>> Bug fixes:
>> 
>> GitHub releases artefacts download were not always working #535 
>> 
>> "Basic launch" does not do its job in Pharo 10 #540 
>> 
>> Proxy settings not applied through settings screen #541 
>> 
>> 
>> Regards,
>> The Pharo team.

[Pharo-users] [ANN] Pharo Launcher 3.0.1 released!

[Christophe Demarey]

Hi all,

Pharo Launcher 3.0.1 has just been released! It is available from 
http://pharo.org/download .
It fixes some issues reported on Pharo Launcher 3.0.

Here is the changelog:
Pharo Launcher v3.0.1
Bug fixes:

#554  UI does not 
show up on Windows
#551  Show folder 
button is broken in Windows 10
#550  About Box 
shows "untitled Window"
#549  Better 
display of download error messages.
#358  Restore proxy 
authentication settings.

Regards,
The Pharo team.

[Pharo-users] Re: A question about #beginsWith: and #endsWith:

[Steffen Märcker]

Hi Kasper,


I've thought about that approach too. But then asked myself whether it is
more likely that there is code that relies on this bug than code where this
went unnoticed and is therefore broken. What do the other think about that
matter and the fix in Squeak?


Best, Steffen







Kasper Osterbye schrieb am Donnerstag, 28. April 2022 19:03:07 (+02:00):


Kasper Osterbye schrieb am Dienstag, 26. April 2022 14:50:51 (+02:00):


I have now raised it as an issue on the issue tracker


Issue #11165 in https://github.com/pharo-project/pharo/issues/11165


If I may suggest a solution it will be to:
add two new methods - prefixedBy:  and suffixedBy: to handle the empty
prefix/suffix correctly
add comments to beginsWith:  and endsWith:  referring to the two new
methods


The problem is that there is client code which depend on the (wrong)
implementation of the beginsWith and endsWith methods.