- Pharo-users - lists.pharo.org

rewrite question

by werner kassens

Hi, where do i find the 'rewrite tool' described in the paper 'Code Transformation by Direct Transformation of ASTs' by Rizun et al? werner

June 7, 2017

Re: [Pharo-users] Some Metacello issue

by Holger Freyther

> On 7. Jun 2017, at 14:09, Stephan Eggermont <stephan(a)stack.nl> wrote: > > Never refer to fixed versions unless you know why (you need to avoid a > specific bug fix). When wanting to have repeatable builds (e.g. for bugfixes) and in the absence of other means to lock/define versions externally, I think using a fixed version is the way to go. > What is most likely is that there is some overconstrained configuration. > Does your ConfigurationOfVoyageMongo or one of the configurations it > pulls in refer to different versions of grease or magritte? Another > issue can be that there are older configurations already loaded that > conflict with the newest ones. Indeed, the ConfigurationOfMongoTalk > is broken, refering to a fixed and older version of Grease. > ConfigurationOfVoyageMongo should probably be using #'release3' of > Magritte, but that doesn't break it. Right. So we have a "OsmocomUniverse" build job that pulls in all the apps into a single image. This helps to make API modifications and not forget any of the client code. The configuration has such dependencies: ConfigurationOfOsmocomUniverse -> ConfigurationOfHLR -> ConfigurationOfVoyageMongo -> Mongotalk -> Grease A -> Magritte3 -> Grease B -> ConfigurationOfSMPPRouter -> ConfigurationOfVoyageMongo -> Mongotalk -> Grease A -> Magritte3 -> Grease B What happens is that somehow "Grease A" gets loaded, then "Grease B" and when it is time for "Grease A" again.. the system kind of explodes and this is for Pharo3 and Pharo6. Now the question to me is.. why is this coming up right now? Did MongoTalk change or Magritte3 or something else? Is there an easy way for Metacello to try a mirror instead of the original, e.g. to inject an older ConfigurationOfMagritte3? holger

June 7, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by phil＠highoctane.be

Use Iceberg with Pharo6.0 There are techtalks videos about it. https://www.youtube.com/watch?v=AuZAFfWS34w&t=29s Phil On Wed, Jun 7, 2017 at 11:29 AM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Hi Phil, > > that's great. I do have a GitHub account (merkste) but none at > SmalltalkHub. Is there a recommendable doc on how to use Git from Pharo? > > Best, Steffen > > > > Am .06.2017, 14:09 Uhr, schrieb phil(a)highoctane.be <phil(a)highoctane.be>: > > Hi Steffen, >> >> I am willing to help you create the package in SmalltalkHub or Github >> based >> on your files/changeset. >> >> Do you have a github and/or SmalltalkHub account? >> >> Best, >> Phil >> >> >> On Tue, Jun 6, 2017 at 1:08 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >> >> Hi! >>> >>> If the need arises, we could of course factor the compact notation out >>> into >>> >>>> a separate package. >>>>> >>>>> Good idea >>>> [...] I do not want to help promoting a syntax that alienates me (and >>>> others because other people reported the saem to me). >>>> >>>> >>> I understand. Btw, I'd really, really appreciate if others post their >>> thoughts and feedback here as well. Discussion helps moving things >>> forward. >>> =) >>> >>> >>> (collection transduce map: #squared) take: 1000. >>> >>>> >>>>> >>>> To me this is much more readable. >>>> >>>> >>> Well, I'll provide that extension once it is finished. >>> >>> I cannot and do not want to use the other forms. >>> >>>> >>>> >>> >>> collection transduce >>> >>>> map: #squared; >>>>> take: 1000. >>>>> >>>>> But as the message chain has to modify the underlying object >>>>> (an eduction), very snaky side effects my occur. E.g., consider >>>>> >>>>> eduction := collection transduce. >>>>> squared := eduction map: #squared. >>>>> take := squared take: 1000. >>>>> >>>>> Now, all three variables hold onto the same object, which first squares >>>>> all elements and than takes the first 1000. >>>>> >>>>> >>>> This is because the programmer did not understand what he did. No? >>>> >>>> >>> Sure. ;-) Nevertheless, it would be very hard to debug. All of which are >>> the reasons I wouldn't implement that variant. ;-) >>> >>> >>> PS: I played with infinite stream and iteration back in 1993 in CLOS. >>> >>>> Now I do not like to mix things because it breaks my flow of thinking. >>>> >>>> >>> >>> I am not sure whether I understand what your mean by mixing. Concerning >>> transducers, the ability to handle infinite sources in only a (natural) >>> side-effect of the ability to finish reductions before all elements are >>> processed, e.g., like #detect: and such. >>> >>> Best, Steffen >>> >>> >>> >>> >>> >>> > >

June 7, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Damien Pollet

I wouldn't bother with SmalltalkHub at this point. Check Iceberg, it's the future: https://github.com/pharo-vcs/iceberg/ On 7 June 2017 at 11:29, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > Hi Phil, > > that's great. I do have a GitHub account (merkste) but none at > SmalltalkHub. Is there a recommendable doc on how to use Git from Pharo? > > Best, Steffen > > > > > Am .06.2017, 14:09 Uhr, schrieb phil(a)highoctane.be <phil(a)highoctane.be>: > > Hi Steffen, >> >> I am willing to help you create the package in SmalltalkHub or Github >> based >> on your files/changeset. >> >> Do you have a github and/or SmalltalkHub account? >> >> Best, >> Phil >> >> >> On Tue, Jun 6, 2017 at 1:08 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: >> >> Hi! >>> >>> If the need arises, we could of course factor the compact notation out >>> into >>> >>>> a separate package. >>>>> >>>>> Good idea >>>> [...] I do not want to help promoting a syntax that alienates me (and >>>> others because other people reported the saem to me). >>>> >>>> >>> I understand. Btw, I'd really, really appreciate if others post their >>> thoughts and feedback here as well. Discussion helps moving things >>> forward. >>> =) >>> >>> >>> (collection transduce map: #squared) take: 1000. >>> >>>> >>>>> >>>> To me this is much more readable. >>>> >>>> >>> Well, I'll provide that extension once it is finished. >>> >>> I cannot and do not want to use the other forms. >>> >>>> >>>> >>> >>> collection transduce >>> >>>> map: #squared; >>>>> take: 1000. >>>>> >>>>> But as the message chain has to modify the underlying object >>>>> (an eduction), very snaky side effects my occur. E.g., consider >>>>> >>>>> eduction := collection transduce. >>>>> squared := eduction map: #squared. >>>>> take := squared take: 1000. >>>>> >>>>> Now, all three variables hold onto the same object, which first squares >>>>> all elements and than takes the first 1000. >>>>> >>>>> >>>> This is because the programmer did not understand what he did. No? >>>> >>>> >>> Sure. ;-) Nevertheless, it would be very hard to debug. All of which are >>> the reasons I wouldn't implement that variant. ;-) >>> >>> >>> PS: I played with infinite stream and iteration back in 1993 in CLOS. >>> >>>> Now I do not like to mix things because it breaks my flow of thinking. >>>> >>>> >>> >>> I am not sure whether I understand what your mean by mixing. Concerning >>> transducers, the ability to handle infinite sources in only a (natural) >>> side-effect of the ability to finish reductions before all elements are >>> processed, e.g., like #detect: and such. >>> >>> Best, Steffen >>> >>> >>> >>> >>> >>> >

June 7, 2017

Re: [Pharo-users] Porting Transducers to Pharo

by Steffen MÃ¤rcker

Hi Phil, that's great. I do have a GitHub account (merkste) but none at SmalltalkHub. Is there a recommendable doc on how to use Git from Pharo? Best, Steffen Am .06.2017, 14:09 Uhr, schrieb phil(a)highoctane.be <phil(a)highoctane.be>: > Hi Steffen, > > I am willing to help you create the package in SmalltalkHub or Github > based > on your files/changeset. > > Do you have a github and/or SmalltalkHub account? > > Best, > Phil > > > On Tue, Jun 6, 2017 at 1:08 PM, Steffen MÃ¤rcker <merkste(a)web.de> wrote: > >> Hi! >> >> If the need arises, we could of course factor the compact notation out >> into >>>> a separate package. >>>> >>> Good idea >>> [...] I do not want to help promoting a syntax that alienates me (and >>> others because other people reported the saem to me). >>> >> >> I understand. Btw, I'd really, really appreciate if others post their >> thoughts and feedback here as well. Discussion helps moving things >> forward. >> =) >> >> >> (collection transduce map: #squared) take: 1000. >>>> >>> >>> To me this is much more readable. >>> >> >> Well, I'll provide that extension once it is finished. >> >> I cannot and do not want to use the other forms. >>> >> >> >> collection transduce >>>> map: #squared; >>>> take: 1000. >>>> >>>> But as the message chain has to modify the underlying object >>>> (an eduction), very snaky side effects my occur. E.g., consider >>>> >>>> eduction := collection transduce. >>>> squared := eduction map: #squared. >>>> take := squared take: 1000. >>>> >>>> Now, all three variables hold onto the same object, which first >>>> squares >>>> all elements and than takes the first 1000. >>>> >>> >>> This is because the programmer did not understand what he did. No? >>> >> >> Sure. ;-) Nevertheless, it would be very hard to debug. All of which are >> the reasons I wouldn't implement that variant. ;-) >> >> >> PS: I played with infinite stream and iteration back in 1993 in CLOS. >>> Now I do not like to mix things because it breaks my flow of thinking. >>> >> >> >> I am not sure whether I understand what your mean by mixing. Concerning >> transducers, the ability to handle infinite sources in only a (natural) >> side-effect of the ability to finish reductions before all elements are >> processed, e.g., like #detect: and such. >> >> Best, Steffen >> >> >> >> >>

June 7, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Sven Van Caekenberghe

> On 7 Jun 2017, at 09:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I think that could/would work (the code in System-Sources was refactored quite well). I added an issue and a slice (in the Pharo 6 inbox): https://pharo.fogbugz.com/f/cases/20126/Running-Without-Changes-and-Sources Make it possible to Run without changes and sources Add two new classes: - NoChangesLog as subclass of ChangesLog - NoPharoFilesOpener as subclass of PharoFilesOpener Both are do nothing variants of their superclass. To run without changes or sources, execute NoChangesLog install. NoPharoFilesOpener install. And save your image. You now no longer need the changes file nor the sources file and you can safely move or remove them. To restore the initial situation, execute ChangesLog reset. PharoFilesOpener reset. Note: it might be possible that some code fails due to missing method sources, YMMV. Warning: of course you should no longer develop in such an image. Sven

June 7, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Sven Van Caekenberghe

You could also subclass PharoFilesOpener with NoPharoFilesOpener, override #sourcesFileOrNil and #changesFileOrNil to just return nil, and #install it as Default. And hope that the callers can deal with the nils. > On 7 Jun 2017, at 09:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Andreas, > > What if you subclassed ChangesLog, say with something called NoChangesLog and installed that as its DefaultInstance (as accessed by #default), with an #install class side message. > > Then override #logChange: and #logSnapshot:andQuit: to do nothing. > > No need to subscribe to system announcements. > > To install, you do > > NoChangesLog install. > > To get back, you do > > ChangesLog reset. > > I think that could/would work (the code in System-Sources was refactored quite well). > > HTH, > > Sven > >> On 7 Jun 2017, at 04:19, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >> >> For now, in my 'deployed' image, I have: >> 1. Disabled SourceFilesArray >> forceChangesToDisk >> I did not find any code branch that would avoid this, so for now I just made it do nothing. Maybe I should disable ChangesLog >> logChange: instead. >> >> 2. Disabled PharoFilesOpener >> changesFileOrNil >> Same story. But this only causes warning get printed out, not error. Disabling it removes the warning message. >> >> 3. Set changesFileStream to nil (SourceFiles changesFileStream: nil). >> Some code does have guard against nil value for this changes stream. >> >> This works for me if I do not have the changes file with the image. If I have the changes file and it's read-only, that's a different problem. >> >> It seems that this was possible before, judging from the older links I found in my original email and the existence of some guards against non-existence changes file. >> >> I'll check those links and perhaps see if I can be helpful there, but I right now have delivery to make. And I can't wait to try Pharo 6 too. >> >> -- >> Andreas >> >> >> On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >> Hi Stef, >> >> I can't have changes file bundled with the tool because the tool is installed in a centralized location in my network and multiple users will run it. So the image is in a central location and read-only and so is the changes file (if I must have a changes file). The tool is only a processor. It does not need to keep/save its state. >> >> Hence, I cannot have multiple users writing to that one and the same changes file. >> >> I'm trying to dissect the call chain to ChangesLog and try to cut it so Pharo won't write to the changes file. I'm sure I should not do this. There must be a better way. >> >> I guess this use case just hasn't been critical for other people (there are lots of competing priorities) and they've found ways of working around it, like making your network located tool a script that copies itself itself to a use folder and run from there. But of course it would be better for Pharo to work cleanly without a changes file. To make it better, someone has to do it, so feel free to propose some code changes (with discussion of such on pharo-dev list). >> >> Here is one hint (something related I worked on recently)... >> https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-when-sources-file… >> To view the changes, open image 60494 (easiest using PharoLauncher) >> and load the slice. >> >> Filtering the issue tracker on "changes file" pops up a few other possibilities (I haven't reviewed them, and you might find others) >> https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-file-is-not-writab… >> https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-that-opens-the-so… >> >> cheers -ben >> >> >> >> On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> We started to work on making the system ready to stop using these files. >> There are two things. >> - the changes are a tape that logs what you are doing and right now >> the system is not done to accept not to log >> So I imagine that you can remove the changes file but then do not compile code. >> - I do not get the "so I can't have changes file bundled with the tool." >> you do not have a bat or script that launches the application that is >> somewhere in a folder where you have the vm and the image? you could >> have the changes file there. >> >> We are interested in your scenario because last year I got a guy >> working on making pharo silent. I do not know if its changes got >> integrated into pharo. >> This is really something that we want to have. >> - having sources and changes in a specific location >> - having no source and no changes (even if it means lose your code). >> - ... >> >> Stef >> >> On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >>> Sorry to bring this up again. But it turns out that I had the image >>> directory writable by myself, so it created a new changes file. That's why >>> Pharo didn't complain about missing changes file. When I removed write >>> permission in the tool installation, Pharo gives error for not having or not >>> able to write to changes file. >>> >>> I guess I'm back to the problem how to deploy a tool without changes file. I >>> have multiple users that will be running this tool, which is installed in a >>> centralized site, so I can't have changes file bundled with the tool. >>> >>> On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: >>>> >>>> I had my changes and sources files in the bundle but has their write >>>> permission removed, and that causes the error. Simply deploying the tool >>>> without the changes file seems to fix it. Pharo5 doesn't complain if the >>>> changes file isn't there. >>>> >>>> However, without the sources file, I get this warning that pharo cannot >>>> locate the sources file. Including the sources file in the deployed tool is >>>> fine with me. >>>> >>>> So, I think that's my solution. Thanks! >>>> >>>> >>>> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> >>>> wrote: >>>>> >>>>> I found this StackOverflow question: >>>>> >>>>> https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pha… >>>>> >>>>> and this older forum thread: >>>>> >>>>> https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.h… >>>>> >>>>> I'm using Pharo5.0 and neither of these options is available anymore. >>>>> What is the new way to do this? >>>>> >>>>> -- >>>>> Andreas Sunardi >>>> >>>> >>> >> >> >> >> >

June 7, 2017

Re: [Pharo-users] How to deploy headless app without changes and source files?

by Sven Van Caekenberghe

Andreas, What if you subclassed ChangesLog, say with something called NoChangesLog and installed that as its DefaultInstance (as accessed by #default), with an #install class side message. Then override #logChange: and #logSnapshot:andQuit: to do nothing. No need to subscribe to system announcements. To install, you do NoChangesLog install. To get back, you do ChangesLog reset. I think that could/would work (the code in System-Sources was refactored quite well). HTH, Sven > On 7 Jun 2017, at 04:19, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > > For now, in my 'deployed' image, I have: > 1. Disabled SourceFilesArray >> forceChangesToDisk > I did not find any code branch that would avoid this, so for now I just made it do nothing. Maybe I should disable ChangesLog >> logChange: instead. > > 2. Disabled PharoFilesOpener >> changesFileOrNil > Same story. But this only causes warning get printed out, not error. Disabling it removes the warning message. > > 3. Set changesFileStream to nil (SourceFiles changesFileStream: nil). > Some code does have guard against nil value for this changes stream. > > This works for me if I do not have the changes file with the image. If I have the changes file and it's read-only, that's a different problem. > > It seems that this was possible before, judging from the older links I found in my original email and the existence of some guards against non-existence changes file. > > I'll check those links and perhaps see if I can be helpful there, but I right now have delivery to make. And I can't wait to try Pharo 6 too. > > -- > Andreas > > > On Tue, Jun 6, 2017 at 6:37 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Wed, Jun 7, 2017 at 3:23 AM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > Hi Stef, > > I can't have changes file bundled with the tool because the tool is installed in a centralized location in my network and multiple users will run it. So the image is in a central location and read-only and so is the changes file (if I must have a changes file). The tool is only a processor. It does not need to keep/save its state. > > Hence, I cannot have multiple users writing to that one and the same changes file. > > I'm trying to dissect the call chain to ChangesLog and try to cut it so Pharo won't write to the changes file. I'm sure I should not do this. There must be a better way. > > I guess this use case just hasn't been critical for other people (there are lots of competing priorities) and they've found ways of working around it, like making your network located tool a script that copies itself itself to a use folder and run from there. But of course it would be better for Pharo to work cleanly without a changes file. To make it better, someone has to do it, so feel free to propose some code changes (with discussion of such on pharo-dev list). > > Here is one hint (something related I worked on recently)... > https://pharo.fogbugz.com/f/cases/20074/Red-pane-of-death-when-sources-file… > To view the changes, open image 60494 (easiest using PharoLauncher) > and load the slice. > > Filtering the issue tracker on "changes file" pops up a few other possibilities (I haven't reviewed them, and you might find others) > https://pharo.fogbugz.com/f/cases/11204/Crash-if-changes-file-is-not-writab… > https://pharo.fogbugz.com/f/cases/11426/Extract-the-logic-that-opens-the-so… > > cheers -ben > > > > On Tue, Jun 6, 2017 at 11:55 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > We started to work on making the system ready to stop using these files. > There are two things. > - the changes are a tape that logs what you are doing and right now > the system is not done to accept not to log > So I imagine that you can remove the changes file but then do not compile code. > - I do not get the "so I can't have changes file bundled with the tool." > you do not have a bat or script that launches the application that is > somewhere in a folder where you have the vm and the image? you could > have the changes file there. > > We are interested in your scenario because last year I got a guy > working on making pharo silent. I do not know if its changes got > integrated into pharo. > This is really something that we want to have. > - having sources and changes in a specific location > - having no source and no changes (even if it means lose your code). > - ... > > Stef > > On Tue, Jun 6, 2017 at 8:14 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > > Sorry to bring this up again. But it turns out that I had the image > > directory writable by myself, so it created a new changes file. That's why > > Pharo didn't complain about missing changes file. When I removed write > > permission in the tool installation, Pharo gives error for not having or not > > able to write to changes file. > > > > I guess I'm back to the problem how to deploy a tool without changes file. I > > have multiple users that will be running this tool, which is installed in a > > centralized site, so I can't have changes file bundled with the tool. > > > > On Mon, Jun 5, 2017 at 5:47 PM, Andreas Sunardi <a.sunardi(a)gmail.com> wrote: > >> > >> I had my changes and sources files in the bundle but has their write > >> permission removed, and that causes the error. Simply deploying the tool > >> without the changes file seems to fix it. Pharo5 doesn't complain if the > >> changes file isn't there. > >> > >> However, without the sources file, I get this warning that pharo cannot > >> locate the sources file. Including the sources file in the deployed tool is > >> fine with me. > >> > >> So, I think that's my solution. Thanks! > >> > >> > >> On Mon, Jun 5, 2017 at 5:07 PM, Andreas Sunardi <a.sunardi(a)gmail.com> > >> wrote: > >>> > >>> I found this StackOverflow question: > >>> > >>> https://stackoverflow.com/questions/14737695/is-it-possible-to-deploy-a-pha… > >>> > >>> and this older forum thread: > >>> > >>> https://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg21170.h… > >>> > >>> I'm using Pharo5.0 and neither of these options is available anymore. > >>> What is the new way to do this? > >>> > >>> -- > >>> Andreas Sunardi > >> > >> > > > > > >

June 7, 2017

Re: [Pharo-users] [ANN] Pharo 6.0 released!

by Alistair Grant

Great news! Thanks to Esteban and the 80+ contributors. I have multiple patches waiting for the 7.0 dev cycle to begin. Can't wait... :-) Cheers, Alistair On 6 June 2017 at 17:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Dear World, > > The time has come for Pharo 6.0! > > Pharo is a pure object-oriented programming language and a powerful > environment, focused on simplicity and immediate feedback. > > This is our most significant release yet. Here are some highlights: > > - Pharo is now provided in 64-bit version in Linux and OSX and brings even > better performance and stability (beware, 64bits version is a new technology > and a small amount of tests is still failing) > - A new code changes management system named Epicea for easier reviewing and > recovering of your code easily > - Integrated support for Git through an easy-to-use tool for repositories > and commits management named Iceberg (as a preview for Pharo 6, it will be > the default in Pharo 7) > - The unified foreign function interface (UnifiedFFI) for interfacing with > the outside world is significantly improved > - The PharoVM is now part of OpenSmalltalk initiative > - Introduction of object immutability, alternative bytecode sets and block > closures independent of outer context > - Pharo can now be bootstrapped from source code managed by Git > - Pharo modularity is improved > - Pharo is faster > - The Dark Theme was improved and set as default color theme of Pharo > > > These are just the more prominent highlights, but the details are just as > important. We have closed 1474 issues in Pharo 6.0 (a more complete > changelog can be found at > https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60Change…) > > While the technical improvements are significant (starting the transition to > 64bits is a remarkable achievement), still the most impressive fact is that > the new code that got in the main Pharo 6.0 image was contributed by more > than 80 people. > > Pharo is more than code. It is an exciting project involving energetic > people. We thank all the contributors of this release: > > Alberto Bacchelli, Alejandro Infante, Alexandre Bergel, Aliaksei Syrel, > Alistair Grant, Andrei Chis, Ben Coman, Bernardo Contreras, Bernhard Pieber, > Boris Spasojevic, Christophe Demarey, Clement Bera, Cyril Ferlicot, Dale > Henrichs, Damien Cassou, Damien Pollet, Dave Lewis, Denis Kudriashov, Dirk > Roeleveld, Eliot Miranda, Esteban Lorenzano, Esteban Maringolo, Evan > Donahue, Federico Balaguer, Franck Warlouzet, Glenn Cavarle, Guillermo > Polito, Gustavo Santos, Henrik Johansen, Henrik Nergaard, Hilaire Fernandes, > Holger Hans, Jan Kurs, Jan van de Sandt, Johan Fabry, Juraj Kubelka, K. K. > Subramaniam, Ken Causey, Kris Gybels, Lionel Akue, Luc Fabresse, Lucas > Godoy, Marcus Denker, Mariano Martinez Peck, Marion Noirbent, Martin Dias, > Max Leske, Maxime Roelandt, Merwan Ouddane, Matteo Bellotto, Miguel > Campusano, Milton Mamani, Myroslava Romaniuk, Nicolai Hess, Nicolas Cellier, > Nicolas Passerini, Norbert Hartl, Offray Luna, Pablo Tesone, Paul De > Bruicker, Pavel Krivanek, Peter Uhnak, Philippe Back, Roger Stebler, Ronie > Salgado, Sean DeNigris, Serge Stinckwich, Skip Lentz, Sophie Kaleba, Stefan > Reichhart, Stephan Eggermont, Stephane Ducasse, Sven Van Caekenberghe, > Thibault Arloing, Thibault Arloing, Thibault Raffaillac, Thierry Goubier, > Thomas Heniart, Tommaso Dal Sasso, Torsten Bergmann, Tudor Girba, Udo > Schneider, Valentin Ryckewaert, Vincent Blondeau, Werner Kassens, Yuriy > Tymchuk > > (If you contributed with Pharo 6.0 development in any way and we missed your > name, please send us a mail and we will add you). > > Enjoy! > > The Pharo Team > > Try Pharo: http://pharo.org/download > Learn Pharo: http://pharo.org/documentation

June 7, 2017

Re: [Pharo-users] Some Metacello issue

by Stephan Eggermont

I would like to repeat here again: don't refer to fixed version numbers of packages out of your control in configurations. Refer to #'release' versions that can be patched by the maintainers of your dependencies. That is only appropriate when having to patch around a problem, and couples your configuration hard to the development schedule of your dependency, making it your responsibility to update your configuration whenever that of your dependency is updated. Stephan

June 7, 2017