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.

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.

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.h... 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... another two months passed by. Would it be possible? Thx T.

Gesendet: Donnerstag, 22. März 2018 um 23:07 Uhr Von: "Torsten Bergmann" <astares@gmx.de> An: pharo-dev@lists.pharo.org, seaside-dev@lists.squeakfoundation.org 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.

I am making a new #stable release ...

On 18 May 2018, at 14:46, Johan Brichau <johan@inceptive.be> 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 <astares@gmx.de> 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.h... 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... another two months passed by.

Would it be possible?

Thx T.

...

Gesendet: Donnerstag, 22. März 2018 um 23:07 Uhr Von: "Torsten Bergmann" <astares@gmx.de> An: pharo-dev@lists.pharo.org, seaside-dev@lists.squeakfoundation.org 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 seaside-dev@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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" <sven@stfx.eu> An: "Johan Brichau" <johan@inceptive.be> Cc: pharo-dev@lists.pharo.org, "Seaside - developer list" <seaside-dev@lists.squeakfoundation.org> 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 <sven@stfx.eu> wrote:

I am making a new #stable release ...

...

On 18 May 2018, at 14:46, Johan Brichau <johan@inceptive.be> 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 <astares@gmx.de> 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.h... 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... another two months passed by.

Would it be possible?

Thx T.

...

Gesendet: Donnerstag, 22. März 2018 um 23:07 Uhr Von: "Torsten Bergmann" <astares@gmx.de> An: pharo-dev@lists.pharo.org, seaside-dev@lists.squeakfoundation.org 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 seaside-dev@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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." <cyril.ferlicot@gmail.com> An: pharo-dev@lists.pharo.org Cc: "Seaside - developer list" <seaside-dev@lists.squeakfoundation.org> 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

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

On Sat, May 19, 2018 at 2:59 AM, Cyril Ferlicot D. <cyril.ferlicot@gmail.com

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: https://github.com/pharo-vcs/iceberg/issues/168 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 <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

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 <astares@gmx.de> 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 seaside-dev@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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 <tim@testit.works> 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 <sven@stfx.eu> 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 <astares@gmx.de> 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 seaside-dev@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

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 <stephan@stack.nl> wrote:

Sean P. DeNigris <sean@clipperadams.com> 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