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. |
On mar. 13 mars 2018 at 21:11, Torsten Bergmann <[hidden email]> wrote: Hi Pharo-dev (CC Seaside-dev) Hi! This is because of a really recent change and Sven is working on it.
Cyril Ferlicot
https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France |
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) Hi! This is because of a really recent change and Sven is working on it.
Cyril Ferlicot
https://ferlicot.fr http://www.synectique.eu 2 rue Jacques Prévert 01, 59650 Villeneuve d'ascq France |
> 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 |
> 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. |
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. > > > |
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 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. > > |
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. > > > > |
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 |
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 > > |
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 > |
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 |
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 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 |
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 |
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 > > |
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 : 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.
|
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.
|
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 > > |
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 >> >> > > |
Free forum by Nabble | Edit this page |