- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OSProcess for Pharo 7

by ducasse

> On 14 Mar 2019, at 17:33, Max Leske <maxleske(a)gmail.com> wrote: > > On 13 Mar 2019, at 11:55, ducasse wrote: > >> Ok now one of these days we will have to have all the important libraries hosted in the same place. >> It is not sure that we will maintain MC forever. >> For example SmalltalkHub should get readonly by the end of the year (for lack of maintenance reason). >> BTW is OSSubProcess working for you? > > Yes, it works. There appear to be some methods that need to be updated but general functionality is there. Let us know because Guille did a pass on Marianoâs version and we are ready to improve it. > > Max > >> >>> 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 14, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by Max Leske

On 13 Mar 2019, at 11:55, ducasse wrote: > Ok now one of these days we will have to have all the important > libraries hosted in the same place. > It is not sure that we will maintain MC forever. > For example SmalltalkHub should get readonly by the end of the year > (for lack of maintenance reason). > BTW is OSSubProcess working for you? Yes, it works. There appear to be some methods that need to be updated but general functionality is there. Max > >> 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 14, 2019

[Pharo 8.0] Build #138: 2822-remove-WPDummy

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

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

March 14, 2019

[Pharo 8.0] Build #137: 2802-2801-Refactor-Reflectivity-Tools-

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

There is a new Pharo build available! The status of the build #137 was: SUCCESS. The Pull Request #2816 was integrated: "2802-2801-Refactor-Reflectivity-Tools-" Pull request url: https://github.com/pharo-project/pharo/pull/2816 Issue Url: https://pharo.fogbugz.com/f/cases/2802 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 14, 2019

Re: [Pharo-dev] MIMEDocument and MailMessage

by ducasse

Thanks. Indeed we should improve one step at a time. And this is great to see Pharo getting improved so much. I once discussed with K. Beck and he told me that indeed we often forget how powerful it is to do one little improvement at a time. So let us continue and this is cool that you got that Pharo is yours :) Stef > On 13 Mar 2019, at 18:28, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Marcus, > > On Wed, 13 Mar 2019 at 11:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> The code is barely usable, I am sure it is not complete and wrong in many places. > > Hopefully it will be a bit more usable and a little less wrong when > I'm finished :-) > > I've been able to use it to parse and load mail headers (about 23,000 > messages), so it isn't all bad. :-) > > Thanks, > Alistair > > > >>> On 13 Mar 2019, at 11:09, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Everyone, >>> >>> I'm playing with parsing and searching mail messages at the moment and >>> am wondering about the interaction of MailMessage and MIMEDocument. >>> >>> A MailMessage contains a body which is a MIMEDocument, but if I request >>> the parts of the body I get back multiple MailMessages, i.e. the parts >>> of a MIMEDocument are a collection of MailMesssages. >>> >>> MIME documents are used outside of mail messages, e.g. HTTP, so the >>> parts of a MIMEDocument should also be MIMEDocument's and not >>> MailMessage's. This is also implied by the MIME description at >>> wikipedia: https://en.wikipedia.org/wiki/MIME >>> >>> Some of the method comments seem to suggest that this was put together >>> quickly, so it is possible that the intention was to do it properly at a >>> later date (which never happened :-)). >>> >>> Am I missing something, or is it OK for me to modify MIMEDocument to >>> return MIMEDocuments as the parts? >>> >>> >>> Thanks, >>> Alistair >>> >> >> >

March 13, 2019

[Pharo 8.0] Build #136: 2809-Small-test-cleanup-in-Slots

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

There is a new Pharo build available! The status of the build #136 was: FAILURE. The Pull Request #2810 was integrated: "2809-Small-test-cleanup-in-Slots" Pull request url: https://github.com/pharo-project/pharo/pull/2810 Issue Url: https://pharo.fogbugz.com/f/cases/2809 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 13, 2019

Re: [Pharo-dev] MIMEDocument and MailMessage

by Alistair Grant

Hi Marcus, On Wed, 13 Mar 2019 at 11:21, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > The code is barely usable, I am sure it is not complete and wrong in many places. Hopefully it will be a bit more usable and a little less wrong when I'm finished :-) I've been able to use it to parse and load mail headers (about 23,000 messages), so it isn't all bad. :-) Thanks, Alistair > > On 13 Mar 2019, at 11:09, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Everyone, > > > > I'm playing with parsing and searching mail messages at the moment and > > am wondering about the interaction of MailMessage and MIMEDocument. > > > > A MailMessage contains a body which is a MIMEDocument, but if I request > > the parts of the body I get back multiple MailMessages, i.e. the parts > > of a MIMEDocument are a collection of MailMesssages. > > > > MIME documents are used outside of mail messages, e.g. HTTP, so the > > parts of a MIMEDocument should also be MIMEDocument's and not > > MailMessage's. This is also implied by the MIME description at > > wikipedia: https://en.wikipedia.org/wiki/MIME > > > > Some of the method comments seem to suggest that this was put together > > quickly, so it is possible that the intention was to do it properly at a > > later date (which never happened :-)). > > > > Am I missing something, or is it OK for me to modify MIMEDocument to > > return MIMEDocuments as the parts? > > > > > > Thanks, > > Alistair > > > >

March 13, 2019

[Pharo 8.0] Build #135: 2811-Test-for-metalink-on-slot-that-gets-assigned-

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

There is a new Pharo build available! The status of the build #135 was: FAILURE. The Pull Request #2812 was integrated: "2811-Test-for-metalink-on-slot-that-gets-assigned-" Pull request url: https://github.com/pharo-project/pharo/pull/2812 Issue Url: https://pharo.fogbugz.com/f/cases/2811 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 13, 2019

[Pharo 8.0] Build #134: 2806-test-and-fix-for-PropertySlot-remove-propertySlot-when-instances-are-present

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

There is a new Pharo build available! The status of the build #134 was: FAILURE. The Pull Request #2807 was integrated: "2806-test-and-fix-for-PropertySlot-remove-propertySlot-when-instances-are-present" Pull request url: https://github.com/pharo-project/pharo/pull/2807 Issue Url: https://pharo.fogbugz.com/f/cases/2806 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 13, 2019

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Stephan Eggermont

Albrecht Baur via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: I started trying to do the same migration process for ... http://www.smalltalkhub.com/#!/~Pier/Pier3 ... but I failed on errors loading older mcz files: "instance of ByteString did not understand #peek" on: MCMczReader >> contentsForMember: (ZnInvalidUTF8: Illegal leading byte for utf-8 encoding) That needs a bugfix, old mczs might not be utf8. You can probably retry with latin1 or macroman. Beware of issues like https://lists.gforge.inria.fr/pipermail/pharo-project/2009-May/008990.html You might find WideString there, different encodings, or a dropped leading character, and code where the method contents are changed but the timestamp didnât and the other way around Stephan

March 13, 2019