- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OSProcess for Pharo 7

by Max Leske

Hi Stef, On 11 Mar 2019, at 8:12, ducasse wrote: > Max > > ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit > normal that it got removed in P7. But we should check this. > I do not have the time today for this. > > normally ifNotNilDo: should be covered by a migrator automatic rewrite > rules (can you check?): Ducasse/Migrator > because in such case you load the migrator packages and execute the > tests of the OSProcess (if any) > then you execute OSProcess and the user of ifNotNilDo: will be > automatically rewritten and you are just left to check > the senders that are left and commit a new version. You have extensions defined for #ifNotNilDo: in your migration definition for 50 to 60. > > If IfNotNilDo: is not covered by a automated migration we should add > one. > It was deprecated before the automated migrations were introduced. > > > Now about your question: yes a new version of OSProcess should be > produced for P7. > The best would be to migrate it to github. I think Dave might disagree ;) If the maintainers are fine with moving to Github then that would be great. I assume that there will be some objections to that (e.g. because of loading in Squeak?) and we (I at least) don't want to maintain a fork / mirror on Github. Pulling from SqueakSource works fine for now. Max > > Let me know if it helps. > > Stef > >> On 11 Mar 2019, at 08:00, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi all, >> >> Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess >> loading fails. I volunteer to update OSProcess for Pharo 7 but I need >> someone to tell me what the expected workflow is. AFAICT, we've >> simply copied the current ConfigurationOf to the MetaRepoForXX in the >> past without making any changes specific to Pharo. That will not work >> this time. >> So, should I create a new version of OSProcess for all platforms, >> where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add >> a compatibility package for Pharo? Or something else? >> >> Cheers, >> Max >>

March 11, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by Max Leske

On 11 Mar 2019, at 9:38, Thierry Goubier wrote: > Hi Max, > > use the following to load OSProcess: > > Metacello new > configuration: 'OSProcess'; > repository: 'http://www.squeaksource.com/MetacelloRepository'; > load > > As I said a while ago, the ifNotNilDo: thing was corrected long ago > and that configuration updated; the one in the catalog is limited to > Pharo 6. Perfect, that worked. Thanks! > > Thierry > > Le lun. 11 mars 2019 Ã 08:00, Max Leske <maxleske(a)gmail.com> a Ã©crit : >> >> Hi all, >> >> Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading >> fails. I volunteer to update OSProcess for Pharo 7 but I need someone to >> tell me what the expected workflow is. AFAICT, we've simply copied the >> current ConfigurationOf to the MetaRepoForXX in the past without making >> any changes specific to Pharo. That will not work this time. >> So, should I create a new version of OSProcess for all platforms, where >> #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a >> compatibility package for Pharo? Or something else? >> >> Cheers, >> Max >>

March 11, 2019

Re: [Pharo-dev] [ANN] Pharo Consortium New Academic Member: CIRAD

by Esteban Lorenzano

Hi, > On 11 Mar 2019, at 04:24, askoh <askoh(a)askoh.com> wrote: > > It would be very interesting if there is a list showing what each consortium > member uses Pharo or Smalltalk for. Sadly, thatâs not really possible :( While many members have no problem on freely talk about what they do, others do not have same approach :) Esteban > > Thanks, > Aik-Siong Koh > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 11, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by Thierry Goubier

Hi Max, use the following to load OSProcess: Metacello new configuration: 'OSProcess'; repository: 'http://www.squeaksource.com/MetacelloRepository'; load As I said a while ago, the ifNotNilDo: thing was corrected long ago and that configuration updated; the one in the catalog is limited to Pharo 6. Thierry Le lun. 11 mars 2019 Ã 08:00, Max Leske <maxleske(a)gmail.com> a Ã©crit : > > Hi all, > > Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading > fails. I volunteer to update OSProcess for Pharo 7 but I need someone to > tell me what the expected workflow is. AFAICT, we've simply copied the > current ConfigurationOf to the MetaRepoForXX in the past without making > any changes specific to Pharo. That will not work this time. > So, should I create a new version of OSProcess for all platforms, where > #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a > compatibility package for Pharo? Or something else? > > Cheers, > Max >

March 11, 2019

[Pharo 8.0] Build #124: Revert "2759-Spec-Deprecated-should-be-removed-from-Pharo-8"

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

There is a new Pharo build available! The status of the build #124 was: SUCCESS. The Pull Request #2788 was integrated: "Revert "2759-Spec-Deprecated-should-be-removed-from-Pharo-8"" Pull request url: https://github.com/pharo-project/pharo/pull/2788 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 11, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by ducasse

Max ifNotNilDo: was probably deprecated in Pharo 50 so this is a bit normal that it got removed in P7. But we should check this. I do not have the time today for this. normally ifNotNilDo: should be covered by a migrator automatic rewrite rules (can you check?): Ducasse/Migrator because in such case you load the migrator packages and execute the tests of the OSProcess (if any) then you execute OSProcess and the user of ifNotNilDo: will be automatically rewritten and you are just left to check the senders that are left and commit a new version. If IfNotNilDo: is not covered by a automated migration we should add one. It was deprecated before the automated migrations were introduced. Now about your question: yes a new version of OSProcess should be produced for P7. The best would be to migrate it to github. Let me know if it helps. Stef > On 11 Mar 2019, at 08:00, Max Leske <maxleske(a)gmail.com> wrote: > > Hi all, > > Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. > So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else? > > Cheers, > Max >

March 11, 2019

OSProcess for Pharo 7

by Max Leske

Hi all, Pharo 7 no longer includes #ifNotNilDo:, meaning that OSProcess loading fails. I volunteer to update OSProcess for Pharo 7 but I need someone to tell me what the expected workflow is. AFAICT, we've simply copied the current ConfigurationOf to the MetaRepoForXX in the past without making any changes specific to Pharo. That will not work this time. So, should I create a new version of OSProcess for all platforms, where #ifNotNilDo: has been replaced with #ifNotNil:? Or should I add a compatibility package for Pharo? Or something else? Cheers, Max

March 11, 2019

Esteban's ChangeLog week of 4 March 2019

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 4 March 2019 to 10 March 2019. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=4/3/2019&to=10/3/2019 ChangeLog ========= 6 March 2019: ------------- * I spent last two days trying approaches to make the introduction of +Application+ concept less intrusive. Thing is, since several applications can be alive at the same time (in general at least two: Pharo and the application the user is developing, but there can be more), when you create a window, is mandatory to know the application it belongs to. And this is a problem. Why? Well, because there are two ways to do it: It can be: ---- MyWindowClass newApplication: myApplication. ---- or: ---- myApplication new: MyWindowClass. ---- And well... both approaches require that you are in possesion of an application when you create a window. In an application of certain complexity (not to talk about Pharo complexity itself), this can be a problem (hello, singletons!). I explored the approach of having one active application at a time... but what happens when you are running application A and you need to pop a debugger? How to choose the right application? After some consideration, I came to the conclusion that is not possible, and that decision needs to be binded to the development itself. So, how to solve this? Is a matter of each application. * It is possible for some applications to pass the application between components. One can arwe UI decisions need to be taken at UI level, and is fine to have the application available at that level. * Is possible to have *for your application* a "runningApplication"... a class variable in your SpecApplication override. This is a singleton, yes, but sometimes you need it... Maybe Pharo will go this way. 4 March 2019: ------------- * Today I completed the first step on the introduction of +Application+ for Spec2. As we have told, an application is the entry point of any Spec Application. It will handle the creation and flow of windows and the resources used by it (long term goal: no more UIManager, UITheme, ThemeIcons and other singletons that pollute the system). Anyway, for now I just managed to introduce a generic application and refactored the +ComposablePresenter+, extracting the window functionality from them and moving it to a default +Application+. It sounds simple, but it was a big change. A diagram of how this has changed: ---- Before: ComposablePresenter -> WindowPresenter \ ComposablePresenter* ---- ---- Now: Application -> WindowPresenter -> ComposablePresenter -> ComposablePresenter* ---- This way of handling windows allows a tight control of what is open and in what order, and a way to handle resources other tghan a singleton in the system. cheers! Esteban

March 11, 2019

Re: [Pharo-dev] [ANN] Pharo Consortium New Academic Member: CIRAD

by askoh

It would be very interesting if there is a list showing what each consortium member uses Pharo or Smalltalk for. Thanks, Aik-Siong Koh -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 11, 2019

[Pharo 8.0] Build #123: Revert "Adds a new exception for a missing class error (ClassNotUnderstood) andâ¦"

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

There is a new Pharo build available! The status of the build #123 was: FAILURE. The Pull Request #2784 was integrated: "Revert "Adds a new exception for a missing class error (ClassNotUnderstood) andâ¦"" Pull request url: https://github.com/pharo-project/pharo/pull/2784 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 10, 2019