- Pharo-dev - lists.pharo.org

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

by Guillermo Polito

On Sat, May 19, 2018 at 2:59 AM, Cyril Ferlicot D. <cyril.ferlicot(a)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

May 20, 2018

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

by 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 <stephan(a)stack.nl> wrote: > > Sean P. DeNigris <sean(a)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 > >

May 20, 2018

Re: [Pharo-dev] Soup Bug? Pre Tags Should Be Nestable

by Sean P. DeNigris

Bump :) Sean P. DeNigris wrote > I did some research and don't see any restriction on nested pre tags, yet > Soup includes > <pre> > in "NonNestableBlockTagsForHtml". This causes the > following to be parsed as two sibling > <pre> > tags: > <pre> > Hi there > > <pre> > This act shall take effect immediately. > > </pre> > </pre> > Moving > <pre> > from NonNestableBlockTagsForHtml to NestableBlockTagsForHtml > seems to be The Right Thing To Do. Any objection (I'm certainly not an > HTML > expert). If not, I'll commit to my GH fork and feel free to merge back to > StHub or wherever. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 19, 2018

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

by Stephan Eggermont

Sean P. DeNigris <sean(a)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

May 19, 2018

[Pharo 7.0-dev] Build #925: 21932-Cleanup-in-Athens-Examples

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #925 was: SUCCESS. The Pull Request #1387 was integrated: "21932-Cleanup-in-Athens-Examples" Pull request url: https://github.com/pharo-project/pharo/pull/1387 Issue Url: https://pharo.fogbugz.com/f/cases/21932 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018

[Pharo 7.0-dev] Build #924: 15230-DNU-Open-Debugger-on-Call-Site-not-doesNotUnderstand

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #924 was: FAILURE. The Pull Request #1383 was integrated: "15230-DNU-Open-Debugger-on-Call-Site-not-doesNotUnderstand" Pull request url: https://github.com/pharo-project/pharo/pull/1383 Issue Url: https://pharo.fogbugz.com/f/cases/15230 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018

Pharo 7 Launch Failure - Freetype Problem?

by Sean P. DeNigris

Following the contribution instructions on the website [1] to review the PR for issue 15230 [2], I downloaded the build artifact [3] from the validation [4]. When I tried to launch it a few times (Mac 10.13.2), it showed in the app list, but never opened a window. I did a force quit and found a debug log [5], which shows a few errors from different startup attempts which all seem to trace back to Freetype. The latest was "Could not find accessor for variable named "'dest'"" from "FFICallout>>loaderForArgNamed:", and further down I found "FreeTypeExternalMemory>>primCopyToExternalMemory:" 1. https://pharo.org/review-fix 2. https://github.com/pharo-project/pharo/pull/1383 3. https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… 4. https://ci.inria.fr/pharo-ci-jenkins2/blue/organizations/jenkins/Test%20pen… 5. https://gist.github.com/seandenigris/d153ff4757f681c5169a29cf832ca31a ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

May 19, 2018

[Pharo 7.0-dev] Build #923: 21929-Metacello-has-problem-with-archive-deletion-on-windows

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #923 was: SUCCESS. The Pull Request #1385 was integrated: "21929-Metacello-has-problem-with-archive-deletion-on-windows" Pull request url: https://github.com/pharo-project/pharo/pull/1385 Issue Url: https://pharo.fogbugz.com/f/cases/21929 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018

LibFFI/NB Cairo External Module Not Found debugging

by Peter UhnÃ¡k

Hi, some Windows users are repeatedly running into Pharo failing to load Cairo library on Windows (see stack screenshot at the bottom). The problem is that I have no idea how to even start debugging this. Is there some documentation on how Pharo loads libraries via FFI on Windows that I can start digging into? Note that the library is definitely present, as this happens only occasionally -- it can be fixed by restarting PC. But I cannot reasonably ask users to restart just because Pharo decided it doesn't feel like loading a library. Any pointers / docs / ideas appreciated. Thanks, Peter

May 19, 2018

[Pharo 7.0-dev] Build #922: 21926-PluggableButtonMorph-instance-valiable-lastColor-is-not-written

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #922 was: SUCCESS. The Pull Request #1382 was integrated: "21926-PluggableButtonMorph-instance-valiable-lastColor-is-not-written" Pull request url: https://github.com/pharo-project/pharo/pull/1382 Issue Url: https://pharo.fogbugz.com/f/cases/21926 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

May 19, 2018