Seaside loading broken in Pharo 7

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Seaside loading broken in Pharo 7

Torsten Bergmann
Hi Pharo-dev (CC Seaside-dev)

the Seaside PR on discussions for Pharo 7 supprt on

https://github.com/SeasideSt/Seaside/pull/979 

says one should use

Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load.

to load Seaside in Pharo 7 (which was from around 7th of February)

I today tried with latest 70694 fresh Pharo image but after a while I get many
walkback debuggers with #setToEnd, isReadOnly and #closed not implemented
on ZnCharacterReadWriteStream

while it is loading "Zinc-Character-Encoding-Core-SvenVanCaekenberghe.56"

If I remember correctly I was able to load it in P7 two weeks ago - so something
broke it meanwhile.

Any ideas?

Bye
T.

Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

CyrilFerlicot

On mar. 13 mars 2018 at 21:11, Torsten Bergmann <[hidden email]> wrote:
Hi Pharo-dev (CC Seaside-dev)

the Seaside PR on discussions for Pharo 7 supprt on

https://github.com/SeasideSt/Seaside/pull/979

says one should use

Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load.

to load Seaside in Pharo 7 (which was from around 7th of February)

I today tried with latest 70694 fresh Pharo image but after a while I get many
walkback debuggers with #setToEnd, isReadOnly and #closed not implemented
on ZnCharacterReadWriteStream

while it is loading "Zinc-Character-Encoding-Core-SvenVanCaekenberghe.56"

If I remember correctly I was able to load it in P7 two weeks ago - so something
broke it meanwhile.

Any ideas?

Hi! This is because of a really recent change and Sven is working on it. 



Bye
T.

--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

Torsten Bergmann
Is there already a fix available, any reference issue?
@Sven: can you tell us about the status/steps?

 
 
Gesendet: Dienstag, 13. März 2018 um 21:26 Uhr
Von: "Cyril Ferlicot" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
Betreff: Re: [Pharo-dev] Seaside loading broken in Pharo 7
 
On mar. 13 mars 2018 at 21:11, Torsten Bergmann <[hidden email]> wrote:
Hi Pharo-dev (CC Seaside-dev)

the Seaside PR on discussions for Pharo 7 supprt on

https://github.com/SeasideSt/Seaside/pull/979

says one should use

Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load.

to load Seaside in Pharo 7 (which was from around 7th of February)

I today tried with latest 70694 fresh Pharo image but after a while I get many
walkback debuggers with #setToEnd, isReadOnly and #closed not implemented
on ZnCharacterReadWriteStream

while it is loading "Zinc-Character-Encoding-Core-SvenVanCaekenberghe.56"

If I remember correctly I was able to load it in P7 two weeks ago - so something
broke it meanwhile.

Any ideas?
 
Hi! This is because of a really recent change and Sven is working on it. 
 


Bye
T.
 
--
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France
Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

Sven Van Caekenberghe-2


> On 21 Mar 2018, at 12:49, Torsten Bergmann <[hidden email]> wrote:
>
> Is there already a fix available, any reference issue?
> @Sven: can you tell us about the status/steps?

Normally loading #bleedingEdge of Zn, but I have to see if the very, very latest changes are in.

You need Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58 or newer.

> Gesendet: Dienstag, 13. März 2018 um 21:26 Uhr
> Von: "Cyril Ferlicot" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Betreff: Re: [Pharo-dev] Seaside loading broken in Pharo 7
>  
> On mar. 13 mars 2018 at 21:11, Torsten Bergmann <[hidden email]> wrote:
> Hi Pharo-dev (CC Seaside-dev)
>
> the Seaside PR on discussions for Pharo 7 supprt on
>
> https://github.com/SeasideSt/Seaside/pull/979
>
> says one should use
>
> Metacello new
>  baseline:'Seaside3';
>  repository: 'github://SeasideSt/Seaside:master/repository';
>  load.
>
> to load Seaside in Pharo 7 (which was from around 7th of February)
>
> I today tried with latest 70694 fresh Pharo image but after a while I get many
> walkback debuggers with #setToEnd, isReadOnly and #closed not implemented
> on ZnCharacterReadWriteStream
>
> while it is loading "Zinc-Character-Encoding-Core-SvenVanCaekenberghe.56"
>
> If I remember correctly I was able to load it in P7 two weeks ago - so something
> broke it meanwhile.
>
> Any ideas?
>  
> Hi! This is because of a really recent change and Sven is working on it.
>  
>
>
> Bye
> T.
>  
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
> http://www.synectique.eu
> 2 rue Jacques Prévert 01,
> 59650 Villeneuve d'ascq France


Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

Torsten Bergmann
> Normally loading #bleedingEdge of Zn, but I have to see if the very, very latest changes are in.
>
> You need Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58 or newer.

Already trapped in Git/Monticello problems:

1. In latest Pharo 7 Build 70715 I open Monticello browser and then I add

    MCHttpRepository
        location: 'http://mc.stfx.eu/ZincHTTPComponents'
        user: ''
        password: ''

   Now try to browse the contents of the repo I already get a DNU because
   IceProxyMCVersionInfo returns nil when asked for a #versionNumber leading
   to other trouble.


2. Now I try to load what you suggested with a script:

      Gofer it
          url: 'http://mc.stfx.eu/ZincHTTPComponents';
          package: 'Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58';
         load

   which fails as this version of the package is not there

   Currently http://mc.stfx.eu/ZincHTTPComponents only goes up to

   Zinc-Character-Encoding-Core-SvenVanCaekenberghe.39

and the 39 up to 58 are missing.

So where is Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58 or newer versions hosted???

Thanks
T.

 

Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

Sven Van Caekenberghe-2
You must be looking somewhere else,

http://mc.stfx.eu/ZincHTTPComponents/

find 'Character-Encoding-Core', they are all there.

> On 21 Mar 2018, at 20:41, Torsten Bergmann <[hidden email]> wrote:
>
>> Normally loading #bleedingEdge of Zn, but I have to see if the very, very latest changes are in.
>>
>> You need Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58 or newer.
>
> Already trapped in Git/Monticello problems:
>
> 1. In latest Pharo 7 Build 70715 I open Monticello browser and then I add
>
>    MCHttpRepository
> location: 'http://mc.stfx.eu/ZincHTTPComponents'
> user: ''
> password: ''
>
>   Now try to browse the contents of the repo I already get a DNU because
>   IceProxyMCVersionInfo returns nil when asked for a #versionNumber leading
>   to other trouble.
>
>
> 2. Now I try to load what you suggested with a script:
>
>      Gofer it
>          url: 'http://mc.stfx.eu/ZincHTTPComponents';
>          package: 'Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58';
>         load
>
>   which fails as this version of the package is not there
>
>   Currently http://mc.stfx.eu/ZincHTTPComponents only goes up to
>
>   Zinc-Character-Encoding-Core-SvenVanCaekenberghe.39
>
> and the 39 up to 58 are missing.
>
> So where is Zinc-Character-Encoding-Core-SvenVanCaekenberghe.58 or newer versions hosted???
>
> Thanks
> T.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

Torsten Bergmann
Sven wrote:
>You must be looking somewhere else,
>http://mc.stfx.eu/ZincHTTPComponents/
>find 'Character-Encoding-Core', they are all there.



Hmmm ... mysterious ... I checked two times yesterday using a web browser after the
loading trouble in Pharo and it was not there.


Works now using:


Gofer it
          url: 'http://mc.stfx.eu/ZincHTTPComponents';
           package: 'Zinc-Character-Encoding-Core';
          load.

Metacello new
  baseline:'Seaside3';
   repository: 'github://SeasideSt/Seaside:master/repository';
   load.


Thanks
T.

Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

Torsten Bergmann
Seaside is working ... but it is not possible to develop as by patching Zinc
the Iceberg tool in P7 is broken then and one can not commit anymore.

So be warned when you follow and use the script below.

:(




> Sven wrote:
> >You must be looking somewhere else,
> >http://mc.stfx.eu/ZincHTTPComponents/
> >find 'Character-Encoding-Core', they are all there.
>
>
>
> Hmmm ... mysterious ... I checked two times yesterday using a web browser after the
> loading trouble in Pharo and it was not there.
>
>
> Works now using:
>
>
> Gofer it
>           url: 'http://mc.stfx.eu/ZincHTTPComponents';
>            package: 'Zinc-Character-Encoding-Core';
>           load.
>
> Metacello new
>   baseline:'Seaside3';
>    repository: 'github://SeasideSt/Seaside:master/repository';
>    load.
>
>
> Thanks
> T.
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Seaside loading broken in Pharo 7

Torsten Bergmann
Hi Sven,

it would be good to have a new #stable for Zinc (at least for recent Pharo 7).

Pharo 7 now has  http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-May/271651.html
integrated - but loading Seaside loads the current (old) stable definition and with that
an outdated Zinc breaking things.

So one is still not able to use Seaside with the recent image and since
http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-March/270564.html
another two months passed by.

Would it be possible?

Thx
T.



> Gesendet: Donnerstag, 22. März 2018 um 23:07 Uhr
> Von: "Torsten Bergmann" <[hidden email]>
> An: [hidden email], [hidden email]
> Betreff: Re: [Pharo-dev] Seaside loading broken in Pharo 7
>
> Seaside is working ... but it is not possible to develop as by patching Zinc
> the Iceberg tool in P7 is broken then and one can not commit anymore.
>
> So be warned when you follow and use the script below.
>
> :(
>
>
>
>
> > Sven wrote:
> > >You must be looking somewhere else,
> > >http://mc.stfx.eu/ZincHTTPComponents/
> > >find 'Character-Encoding-Core', they are all there.
> >
> >
> >
> > Hmmm ... mysterious ... I checked two times yesterday using a web browser after the
> > loading trouble in Pharo and it was not there.
> >
> >
> > Works now using:
> >
> >
> > Gofer it
> >           url: 'http://mc.stfx.eu/ZincHTTPComponents';
> >            package: 'Zinc-Character-Encoding-Core';
> >           load.
> >
> > Metacello new
> >   baseline:'Seaside3';
> >    repository: 'github://SeasideSt/Seaside:master/repository';
> >    load.
> >
> >
> > Thanks
> > T.
> >
> >

Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Torsten Bergmann
Thanks Sven for the #stable definition.

That seems to solve the Zinc issue ... but now I run into a problem with #greaseInteger sent to a character
in WAUrlEncoder class when loading Seaside-Core-Johan-Brichau.875.

Screenshot attached.

But #greaseInteger is not defined for Character, only for Number, Integer and String.

To reproduce: I loaded Seaside from STHub using

  Metacello new
    baseline:'Seaside3';
    repository: 'github://SeasideSt/Seaside:master/repository';
    load

on latest Pharo-7.0+alpha.build.917.

Thanks
Torsten

> Gesendet: Freitag, 18. Mai 2018 um 14:52 Uhr
> Von: "Sven Van Caekenberghe" <[hidden email]>
> An: "Johan Brichau" <[hidden email]>
> Cc: [hidden email], "Seaside - developer list" <[hidden email]>
> Betreff: Re: [Pharo-dev] [Seaside-dev]  Seaside loading broken in Pharo 7
>
> Name: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.115
> Author: SvenVanCaekenberghe
> Time: 18 May 2018, 2:50:59.292817 pm
> UUID: a4690224-dc28-0d00-84dc-69110656fb9a
> Ancestors: ConfigurationOfZincHTTPComponents-SvenVanCaekenberghe.114
>
> new stable v 2.9.2 (as synced May 2018 to Pharo 7 dev)
>
> > On 18 May 2018, at 14:48, Sven Van Caekenberghe <[hidden email]> wrote:
> >
> > I am making a new #stable release ...
> >
> >> On 18 May 2018, at 14:46, Johan Brichau <[hidden email]> wrote:
> >>
> >> Would it help to depend on Zinc bleedingEdge (does it exist) in Pharo 7?
> >>
> >> Johan
> >>
> >>> On 18 May 2018, at 14:08, Torsten Bergmann <[hidden email]> wrote:
> >>>
> >>> Hi Sven,
> >>>
> >>> it would be good to have a new #stable for Zinc (at least for recent Pharo 7).
> >>>
> >>> Pharo 7 now has  http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-May/271651.html
> >>> integrated - but loading Seaside loads the current (old) stable definition and with that
> >>> an outdated Zinc breaking things.
> >>>
> >>> So one is still not able to use Seaside with the recent image and since
> >>> http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2018-March/270564.html
> >>> another two months passed by.
> >>>
> >>> Would it be possible?
> >>>
> >>> Thx
> >>> T.
> >>>
> >>>
> >>>
> >>>> Gesendet: Donnerstag, 22. März 2018 um 23:07 Uhr
> >>>> Von: "Torsten Bergmann" <[hidden email]>
> >>>> An: [hidden email], [hidden email]
> >>>> Betreff: Re: [Pharo-dev] Seaside loading broken in Pharo 7
> >>>>
> >>>> Seaside is working ... but it is not possible to develop as by patching Zinc
> >>>> the Iceberg tool in P7 is broken then and one can not commit anymore.
> >>>>
> >>>> So be warned when you follow and use the script below.
> >>>>
> >>>> :(
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> Sven wrote:
> >>>>>> You must be looking somewhere else,
> >>>>>> http://mc.stfx.eu/ZincHTTPComponents/
> >>>>>> find 'Character-Encoding-Core', they are all there.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hmmm ... mysterious ... I checked two times yesterday using a web browser after the
> >>>>> loading trouble in Pharo and it was not there.
> >>>>>
> >>>>>
> >>>>> Works now using:
> >>>>>
> >>>>>
> >>>>> Gofer it
> >>>>>        url: 'http://mc.stfx.eu/ZincHTTPComponents';
> >>>>>         package: 'Zinc-Character-Encoding-Core';
> >>>>>        load.
> >>>>>
> >>>>> Metacello new
> >>>>> baseline:'Seaside3';
> >>>>> repository: 'github://SeasideSt/Seaside:master/repository';
> >>>>> load.
> >>>>>
> >>>>>
> >>>>> Thanks
> >>>>> T.
> >>>>>
> >>>>>
> >>> _______________________________________________
> >>> seaside-dev mailing list
> >>> [hidden email]
> >>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> >>
> >
>
>
>

screen.png (240K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Torsten Bergmann
I downloaded from STHub as I wrote (so no clones involved).

Sorry the script mentioned in the mail was wrong, I used

Metacello new
  configuration:'Seaside3';
  repository: 'http://www.smalltalkhub.com/mc/Seaside/MetacelloConfigurations/main';
  version: #stable;
  load

to install from GitHub as it is mentioned directly on https://github.com/SeasideSt/Seaside

Should I try the loading of Seaside directly from the Github repository using

Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load

as given on the same page?

Do the versions on GitHub and STHub differ already? Are they in synch?

According to the page it looks like loading from GitHub is just a second way
of loading.

I will try ...

Thx
T.


> Gesendet: Freitag, 18. Mai 2018 um 15:24 Uhr
> Von: "Cyril Ferlicot D." <[hidden email]>
> An: [hidden email]
> Cc: "Seaside - developer list" <[hidden email]>
> Betreff: Re: [Pharo-dev] [Seaside-dev] Seaside loading broken in Pharo 7
>
> Le 18/05/2018 à 15:21, Torsten Bergmann a écrit :
> > Thanks Sven for the #stable definition.
> >
> > That seems to solve the Zinc issue ... but now I run into a problem with #greaseInteger sent to a character
> > in WAUrlEncoder class when loading Seaside-Core-Johan-Brichau.875.
> >
> > Screenshot attached.
> >
> > But #greaseInteger is not defined for Character, only for Number, Integer and String.
> >
> > To reproduce: I loaded Seaside from STHub using
> >
> >   Metacello new
> >     baseline:'Seaside3';
> >     repository: 'github://SeasideSt/Seaside:master/repository';
> >     load
> >
> > on latest Pharo-7.0+alpha.build.917.
> >
>
> I did not get the problem (yet).
>
> Can you check that your local Seaside and Grease clones are up to date?
> Iceberg does not manage yet upgrade of the local clones :(
>
> > Thanks
> > Torsten
> >
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Tim Mackinnon
In reply to this post by Torsten Bergmann
Hi what does it mean “Iceberg does not manage yet upgrade of the local clones”
As I noticed funny load characteristics when trying different library versions of things and not getting versions I thought I was getting.

Is it that?

Tim

Sent from my iPhone

> On 18 May 2018, at 15:24, Cyril Ferlicot D. <[hidden email]> wrote:
>
>> Le 18/05/2018 à 15:21, Torsten Bergmann a écrit :
>> Thanks Sven for the #stable definition.
>>
>> That seems to solve the Zinc issue ... but now I run into a problem with #greaseInteger sent to a character
>> in WAUrlEncoder class when loading Seaside-Core-Johan-Brichau.875.
>>
>> Screenshot attached.
>>
>> But #greaseInteger is not defined for Character, only for Number, Integer and String.
>>
>> To reproduce: I loaded Seaside from STHub using
>>
>>  Metacello new
>>    baseline:'Seaside3';
>>    repository: 'github://SeasideSt/Seaside:master/repository';
>>    load
>>
>> on latest Pharo-7.0+alpha.build.917.
>>
>
> I did not get the problem (yet).
>
> Can you check that your local Seaside and Grease clones are up to date?
> Iceberg does not manage yet upgrade of the local clones :(
>
>> Thanks
>> Torsten
>>
>
>
> --
> Cyril Ferlicot
> https://ferlicot.fr
>


Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Sean P. DeNigris
Administrator
Tim Mackinnon wrote
> Hi what does it mean “Iceberg does not manage yet upgrade of the local
> clones”

This is most commonly encountered when one enables shared repository
location in Iceberg. Say you already have a local clone of Zinc in the
shared root folder, but it's out of date. Then you try to load a project
which has Zinc as a dependency, but requires the current stable version.
Iceberg will just load from the outdated clone without trying to update from
the origin remote.



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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

CyrilFerlicot
Le 18/05/2018 à 21:42, Sean P. DeNigris a écrit :

> Tim Mackinnon wrote
>> Hi what does it mean “Iceberg does not manage yet upgrade of the local
>> clones”
>
> This is most commonly encountered when one enables shared repository
> location in Iceberg. Say you already have a local clone of Zinc in the
> shared root folder, but it's out of date. Then you try to load a project
> which has Zinc as a dependency, but requires the current stable version.
> Iceberg will just load from the outdated clone without trying to update from
> the origin remote.
>
>
This is exactly the problem!

This is something I already described here:
https://github.com/pharo-vcs/iceberg/issues/723

Here is what I wrote in that thread:

With a project on Monticello managed via a ConfigurationOf, when you
install it it will download the .mcz in the package cache and install
the project with the version/baseline you asked.

If you ask for development, you'll get the latest packages described in
the "development" baseline.

Now, with a project hosted on github and managed via a baseline, if the
Iceberg Metacello integration is enabled, when I ask to load the branch
"development", I'm not sure I'll get the latest version of the packages.

If there is no local clone of the project it will clone the project and
checkout the latest version of the branch. But, if I already have a
local clone with the branch (not in sync with the remote branch), it
will install the version present locally. This version might be 5
commits behind the remote branch.

That's why, maybe Iceberg can check the remote branch before installing
the repository and if the local branch is behind the remote branch, it
can ask the user what to do. Either install the local version or pull
the install.

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


--
Cyril Ferlicot
https://ferlicot.fr


signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Stephan Eggermont-3
In reply to this post by Sean P. DeNigris
Sean P. DeNigris <[hidden email]> wrote:
> Tim Mackinnon wrote
>> Hi what does it mean “Iceberg does not manage yet upgrade of the local
>> clones”
>
> This is most commonly encountered when one enables shared repository
> location in Iceberg.

And that also breaks when you need to work on different branches, so a
shared repository location is at the moment not a recommended setting?

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Tim Mackinnon
Should we document this stuff on the iceberg reader.md - that’s where I would tend to look. The doc got paired back - but maybe we should build them up again?

Tim

Sent from my iPhone

> On 19 May 2018, at 22:10, Stephan Eggermont <[hidden email]> wrote:
>
> Sean P. DeNigris <[hidden email]> wrote:
>> Tim Mackinnon wrote
>>> Hi what does it mean “Iceberg does not manage yet upgrade of the local
>>> clones”
>>
>> This is most commonly encountered when one enables shared repository
>> location in Iceberg.
>
> And that also breaks when you need to work on different branches, so a
> shared repository location is at the moment not a recommended setting?
>
> Stephan
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Guillermo Polito
In reply to this post by CyrilFerlicot


On Sat, May 19, 2018 at 2:59 AM, Cyril Ferlicot D. <[hidden email]> wrote:
Le 18/05/2018 à 21:42, Sean P. DeNigris a écrit :
> Tim Mackinnon wrote
>> Hi what does it mean “Iceberg does not manage yet upgrade of the local
>> clones”
>
> This is most commonly encountered when one enables shared repository
> location in Iceberg. Say you already have a local clone of Zinc in the
> shared root folder, but it's out of date. Then you try to load a project
> which has Zinc as a dependency, but requires the current stable version.
> Iceberg will just load from the outdated clone without trying to update from
> the origin remote.
>
>

This is exactly the problem!

This is something I already described here:
https://github.com/pharo-vcs/iceberg/issues/723

Here is what I wrote in that thread:

With a project on Monticello managed via a ConfigurationOf, when you
install it it will download the .mcz in the package cache and install
the project with the version/baseline you asked.

If you ask for development, you'll get the latest packages described in
the "development" baseline.

Now, with a project hosted on github and managed via a baseline, if the
Iceberg Metacello integration is enabled, when I ask to load the branch
"development", I'm not sure I'll get the latest version of the packages.

If there is no local clone of the project it will clone the project and
checkout the latest version of the branch. But, if I already have a
local clone with the branch (not in sync with the remote branch), it
will install the version present locally. This version might be 5
commits behind the remote branch.

That's why, maybe Iceberg can check the remote branch before installing
the repository and if the local branch is behind the remote branch, it
can ask the user what to do. Either install the local version or pull
the install.

Well, there is the original discussion between Nico and Dale also from some time ago:

 
I think asking the user is good, the thing is there are many different scenarios to think about:
  - the branch can already exist and be behing
  - the branch can already exist but diverged (merge is required!)
  - the repository can already exist but on another branch. Should we checkout the asked branch? With shared repositories *on* this seems weird

And then, 
- what should happen in headless mode? Should we just cancel?
- what should happen if the loading is being done by a Metacello expression

Metacello new
  ...
  ...
  load

?

Because any *new* option we introduce will introduce problems with backwards compatibility. So far the #onConflict: and #onUpgrade: allow one to do #useIncoming, #useLoaded only options.

Currently iceberg works definitely better without shared repositories.


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


--
Cyril Ferlicot
https://ferlicot.fr




--

   

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

Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Torsten Bergmann
Just as an info: after fixing the #mimeDecodeToBytes: issue with recent image 70934 and later it is possible
to load Seaside again from GitHub using 
 
Metacello new
 baseline:'Seaside3';
 repository: 'github://SeasideSt/Seaside:master/repository';
 load
 
into a recent Pharo 7.0 (load instruction as recommended on https://github.com/SeasideSt/Seaside).

For the deprecated warnings you either "Proceed" or disable them for the time being.
 
799 of 806 Seaside tests passes 
470 of 457 Grease  tests passes
 
primarily failing to to non-compatible streams. Seaside and Grease tests seem to test
some ANSI related things - who fail now.
 
Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Tim Mackinnon
Hi guys - how did you load Seaside into Pharo 7 as part of a baseline? I’ve hit a similar same problem and am getting a walkback error when trying to load a baseline for a project I wanted to try on P7 which uses seaside.

I get: MetacelloNameNotDefinedError: project group, or package named: 'Seaside-Pharo-Development' not found when used in requires: or includes: field of package: 'Seaside-Tests-Pharo-Development' for version: baseline of BaselineOfSeaside3.

My baseline has the following:

setUpDependencies: spec

        spec
                baseline: 'Seaside3'
                        with: [ spec
                                repository: 'github://SeasideSt/Seaside:master/repository';
                                loads: #('Seaside-Environment') ].


If did have (copied from a Willow example) - and I’m wondering if something is getting cached and that its not actually using the above - but I’m not clear on how to ensure any caches are cleared?

spec
                baseline: 'Seaside3'
                        with: [ spec
                                repository: 'github://SeasideSt/Seaside:v3.2.4/repository';
                                loads: #('Seaside-Environment' 'JQuery' 'Zinc') ];
                project: 'Seaside3-Tests' copyFrom: 'Seaside3' with: [ spec loads: #('Seaside-Tests-Core') ].

Any tips gratefully received.

Tim

> On 24 May 2018, at 16:02, Sven Van Caekenberghe <[hidden email]> wrote:
>
> Hi Torsten,
>
> Thanks for taking care.
>
> I can confirm, from a quick test, that Seaside loads/works fine in the latest Pharo 7.
>
> I had trouble opening the Seaside Control Panel, 10s of deprecation warnings opening for the icon base64 decoding, I had to comment out the #deprecated: message send in #mimeDecodeToBytes:
>
> I don't understand why the Grease stream tests are failing since they seem to be testing ReadWriteStream, a class that was not changed, at all.
>
> Sven
>
>> On 22 May 2018, at 22:01, Torsten Bergmann <[hidden email]> wrote:
>>
>> Just as an info: after fixing the #mimeDecodeToBytes: issue with recent image 70934 and later it is possible
>> to load Seaside again from GitHub using
>>
>> Metacello new
>> baseline:'Seaside3';
>> repository: 'github://SeasideSt/Seaside:master/repository';
>> load
>>
>>
>> into a recent Pharo 7.0 (load instruction as recommended on https://github.com/SeasideSt/Seaside).
>>
>> For the deprecated warnings you either "Proceed" or disable them for the time being.
>>
>> 799 of 806 Seaside tests passes
>> 470 of 457 Grease  tests passes
>>
>> primarily failing to to non-compatible streams. Seaside and Grease tests seem to test
>> some ANSI related things - who fail now.
>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Seaside loading broken in Pharo 7

Tim Mackinnon
Actually - it looks like a caching thing - as in a clean image, if I use my reduced baseline (without the Tests) it loads (albeit with a deprecation warning).

Does anyone know what you have to clear to get it to honour the baseline code you actually have in your image - as its a faff to have to use a clean image?

(This is a constant frustration in Smalltalk - caches are useful and all, but there isn’t a consistent way to reset frameworks - I really long for a pragma for reset, and a menu item somewhere that shows you a reset menu for all the frameworks you have loaded, so its easy to clear things and get to a consistent state…)

Tim

> On 21 Jun 2018, at 14:58, Tim Mackinnon <[hidden email]> wrote:
>
> Hi guys - how did you load Seaside into Pharo 7 as part of a baseline? I’ve hit a similar same problem and am getting a walkback error when trying to load a baseline for a project I wanted to try on P7 which uses seaside.
>
> I get: MetacelloNameNotDefinedError: project group, or package named: 'Seaside-Pharo-Development' not found when used in requires: or includes: field of package: 'Seaside-Tests-Pharo-Development' for version: baseline of BaselineOfSeaside3.
>
> My baseline has the following:
>
> setUpDependencies: spec
>
> spec
> baseline: 'Seaside3'
> with: [ spec
> repository: 'github://SeasideSt/Seaside:master/repository';
> loads: #('Seaside-Environment') ].
>
>
> If did have (copied from a Willow example) - and I’m wondering if something is getting cached and that its not actually using the above - but I’m not clear on how to ensure any caches are cleared?
>
> spec
> baseline: 'Seaside3'
> with: [ spec
> repository: 'github://SeasideSt/Seaside:v3.2.4/repository';
> loads: #('Seaside-Environment' 'JQuery' 'Zinc') ];
> project: 'Seaside3-Tests' copyFrom: 'Seaside3' with: [ spec loads: #('Seaside-Tests-Core') ].
>
> Any tips gratefully received.
>
> Tim
>
>> On 24 May 2018, at 16:02, Sven Van Caekenberghe <[hidden email]> wrote:
>>
>> Hi Torsten,
>>
>> Thanks for taking care.
>>
>> I can confirm, from a quick test, that Seaside loads/works fine in the latest Pharo 7.
>>
>> I had trouble opening the Seaside Control Panel, 10s of deprecation warnings opening for the icon base64 decoding, I had to comment out the #deprecated: message send in #mimeDecodeToBytes:
>>
>> I don't understand why the Grease stream tests are failing since they seem to be testing ReadWriteStream, a class that was not changed, at all.
>>
>> Sven
>>
>>> On 22 May 2018, at 22:01, Torsten Bergmann <[hidden email]> wrote:
>>>
>>> Just as an info: after fixing the #mimeDecodeToBytes: issue with recent image 70934 and later it is possible
>>> to load Seaside again from GitHub using
>>>
>>> Metacello new
>>> baseline:'Seaside3';
>>> repository: 'github://SeasideSt/Seaside:master/repository';
>>> load
>>>
>>>
>>> into a recent Pharo 7.0 (load instruction as recommended on https://github.com/SeasideSt/Seaside).
>>>
>>> For the deprecated warnings you either "Proceed" or disable them for the time being.
>>>
>>> 799 of 806 Seaside tests passes
>>> 470 of 457 Grease  tests passes
>>>
>>> primarily failing to to non-compatible streams. Seaside and Grease tests seem to test
>>> some ANSI related things - who fail now.
>>>
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>>
>
>