March 2019 - Pharo-dev - lists.pharo.org

[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

Re: [Pharo-dev] Pharo Downloads are sluggish

by Marcus Denker

Hello, We moved the download from Inria to OVH because Inria was unreliable. (They found some very arcane issue with the backbone infrastructure some month later after constantly telling us that we were wrongâ¦) Now the OVH server offer is not good enough, they seem to throttle us. We are in the process of getting better infrastructure, againâ¦ one problem is always that there is just no time to do all these things so fast as they should be doneâ¦ Marcus > On 13 Mar 2019, at 12:30, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > More to this issue that might affect only those living below the latitude 38Â° S... > > I was having download interruptions when using the launcher to fetch templates, so I changed the ZnNetworkUtils defaultSocketStreamTimeout to 120 (default is 30) and in the last two templates I downloaded I had no issues, it was slow, but at least without interruptions. Maybe the download manager I mentioned in the previous email had a highter timeout as well. > > Given that the INRIA file server hasn't the fastest upload link, I think that rising the timeout from 30 to something at least the double is a reasonable workaround. > > Regards, > > Esteban A. Maringolo > > > El vie., 1 feb. 2019 a las 14:48, Esteban Maringolo (<emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>>) escribiÃ³: > I'm bumping this, just in case it helps somebody. > > I tried to download the latest Pharo Launcher 1.6, and I had the same issues as the ones stated in this thread (slow download, timeouts, etc.). > > But I downloaded it with a download manager [1], and by means of ten simultaneous connections the download speed was fast enough as to download the 50 MB in a minute or so. > > So I don't know if there is a restriction from the file server or somewhere in the way out, but you can work around it by means of a Download Manager. > > Regards! > > [1] FreeDownloadManager.org > > Esteban A. Maringolo > > > El miÃ©., 3 oct. 2018 a las 5:04, Marcus Denker (<marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>) escribiÃ³: > Ok, so the upgrade of the server contract did not help. > > There is a CDN included, I will try to enable that next (but CDNs cache by name, so we need to make sure we invalidate the cacheâ¦) > > I will do a calculation what S3 would cost, too. > > Marcus > >> On 3 Oct 2018, at 00:59, Esteban Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: >> >> I'm reviving this because I can't finish the download of an image using the latest Pharo launcher. >> >> I'm timeout errors when attempting to download it. Tried 5 times at different intervals. >> >> >> <image.png> >> >> Any idea of what could be happening? >> >> Esteban A. Maringolo >> >> >> El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo (<emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>>) escribiÃ³: >> Is there a reason why the latest version of the builds linked from the website are not hosted in some CDN, Amazon S3 or similar? >> >> Maybe in Europe the speed is fast, but where I am (Argentina) it is really slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks of 40KB/s. >> >> This is an pitiful boarding experience, that will make many cancel it even before getting to open the downloaded launcher. >> >> <node-pharo.png> >> >> The screenshot shows that is not a problem with my home connection, which isn't the fastest but is "normal" for my use cases. >> >> Regards, >> >> Esteban A. Maringolo >> >> ps: When I finished writing this email, this was the progress... >> <image.png> >

March 13, 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? So far I've only loaded it. I'll let yo know when I've run some tests. > >> 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 13, 2019

Re: [Pharo-dev] Pharo Downloads are sluggish

by Esteban Maringolo

More to this issue that might affect only those living below the latitude 38Â° S... I was having download interruptions when using the launcher to fetch templates, so I changed the ZnNetworkUtils defaultSocketStreamTimeout to 120 (default is 30) and in the last two templates I downloaded I had no issues, it was slow, but at least without interruptions. Maybe the download manager I mentioned in the previous email had a highter timeout as well. Given that the INRIA file server hasn't the fastest upload link, I think that rising the timeout from 30 to something at least the double is a reasonable workaround. Regards, Esteban A. Maringolo El vie., 1 feb. 2019 a las 14:48, Esteban Maringolo (<emaringolo(a)gmail.com>) escribiÃ³: > I'm bumping this, just in case it helps somebody. > > I tried to download the latest Pharo Launcher 1.6, and I had the same > issues as the ones stated in this thread (slow download, timeouts, etc.). > > But I downloaded it with a download manager [1], and by means of ten > simultaneous connections the download speed was fast enough as to download > the 50 MB in a minute or so. > > So I don't know if there is a restriction from the file server or > somewhere in the way out, but you can work around it by means of a Download > Manager. > > Regards! > > [1] FreeDownloadManager.org > > Esteban A. Maringolo > > > El miÃ©., 3 oct. 2018 a las 5:04, Marcus Denker (<marcus.denker(a)inria.fr>) > escribiÃ³: > >> Ok, so the upgrade of the server contract did not help. >> >> There is a CDN included, I will try to enable that next (but CDNs cache >> by name, so we need to make sure we invalidate the cacheâ¦) >> >> I will do a calculation what S3 would cost, too. >> >> Marcus >> >> On 3 Oct 2018, at 00:59, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> I'm reviving this because I can't finish the download of an image using >> the latest Pharo launcher. >> >> I'm timeout errors when attempting to download it. Tried 5 times at >> different intervals. >> >> >> <image.png> >> >> Any idea of what could be happening? >> >> Esteban A. Maringolo >> >> >> El mar., 18 sept. 2018 a las 21:03, Esteban Maringolo (< >> emaringolo(a)gmail.com>) escribiÃ³: >> >>> Is there a reason why the latest version of the builds linked from the >>> website are not hosted in some CDN, Amazon S3 or similar? >>> >>> Maybe in Europe the speed is fast, but where I am (Argentina) it is >>> really slow, the screenshot shows 3.5KB/s, it averages 10KB/s, with peaks >>> of 40KB/s. >>> >>> This is an pitiful boarding experience, that will make many cancel it >>> even before getting to open the downloaded launcher. >>> >>> <node-pharo.png> >>> >>> The screenshot shows that is not a problem with my home connection, >>> which isn't the fastest but is "normal" for my use cases. >>> >>> Regards, >>> >>> Esteban A. Maringolo >>> >>> ps: When I finished writing this email, this was the progress... >>> <image.png> >>> >> >>

March 13, 2019

Re: [Pharo-dev] OSProcess for Pharo 7

by ducasse

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? > 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 13, 2019

Re: [Pharo-dev] MIMEDocument and MailMessage

by Marcus Denker

Hi, The code is barely usable, I am sure it is not complete and wrong in many places. > 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