August 2017 - Pharo-dev - lists.pharo.org

[ Pharo 70 ] PR log

by Stephane Ducasse

Aug. 29, 2017

[ Pharo 70 ] Build 61 - 64

by Marcus Denker

[ Pharo 70 ] Build 64 PR 196 Add validation step for binary loaded tests https://github.com/pharo-project/pharo/pull/195 https://pharo.fogbugz.com/f/cases/20332 [ Pharo 70 ] Build 62 PR 222 20346-Update-Iceberg-to-057 https://pharo.fogbugz.com/f/cases/20346 https://github.com/pharo-project/pharo/pull/222 [ Pharo 70 ] Build 61 PR 218 Dead code: #destinationBuffer: and #digitBuffer: https://github.com/pharo-project/pharo/pull/218 https://pharo.fogbugz.com/f/cases/20234

Aug. 29, 2017

Re: [Pharo-dev] poor state of fuel

by Tim Mackinnon

As a small data point, a fuel file written out on AWS Lambda Linux (not sure what version - I think it's an ubuntu, but they don't really say), is readable on OS X 64bit . So it seems like you must have found something unusual. Tim Sent from my iPhone > On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: > > Hi Norbert, > > We still maintain Fuel. > > I was not aware of the problem you describe. Could you open an issue on github (https://github.com/theseion/Fuel/issues) with a detailed explanation and, if possible, steps to reproduce the problem? > > Cheers, > Max > >> On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: >> >> I'm migrating most of my projects to pharo 6.1 at the moment. I come from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that does not need to be installed and makes deployment better. That really feels much better. >> >> I use jenkins and there if a test fails a fuel dump is written to disk. The jenkins server is ubuntu linux with the vm of the opensuse build. My laptop has Mac OS and cannot read back those fuel dumps. I use the same image version on jenkins and my laptop. Both are 64bit. >> >> I asked that on discord and there was a mentioning that not only the 64 bit fuel has problems. So I wanted to ask what is the state of fuel right now. I consider fuel one of the core technologies in pharo and it is sad if it just stops working. >> >> Any feedback is highly appreciated, >> >> Norbert >>

Aug. 29, 2017

Current VM build problems. (was: Fwd: Errored: OpenSmalltalk/opensmalltalk-vm#835 (Cog - 7dff211))

by Tobias Pape

Hi all, currently the vm fails to build properly due to two main problems: a) #testBecomeIdentityHash fails on Squeak5.1 for linux32x86 squeak.cog.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505448#L3172 linux32x86 squeak.sista.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505458#L3208 linux32x86 squeak.stack.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505461#L1842 macos32x86 squeak.cog.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505499#L8455 macos32x86 squeak.sista.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505503#L8517 macos32x86 squeak.stack.spur https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505505#L7383 (Or said differently: on 32x86 for squeak.*.spur) I recall we had problems there but I thought those were fixed 2..3 years ago? Someone can comment? b) the pharo deployment seems to not work correctly: https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505445#L1900 https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505471#L8223 https://travis-ci.org/OpenSmalltalk/opensmalltalk-vm/jobs/269505444#L1900 for 64x64 pharo.cog.spur. If it is correct that those 3 vms cannot be deployed, please fix the deploy script to not try to. IF incorrect, pleas fix on your side/site. Best regards -Tobias > Begin forwarded message: > > From: Travis CI <builds(a)travis-ci.org> > Subject: Errored: OpenSmalltalk/opensmalltalk-vm#835 (Cog - 7dff211) > Date: 29. August 2017 um 13:02:09 MESZ > > OpenSmalltalk / opensmalltalk-vm (Cog) > > Build #835 has errored. 48 minutes and 25 seconds > Tobias Pape 7dff211 Changeset â > [squeakssl] follow suit with the unix hostname validation things > Want to know about upcoming build environment updates? > Would you like to stay up-to-date with the upcoming Travis CI build environment updates? We set up a mailing list for you! Sign up here. > Documentation about Travis CI > Need help? Mail support! > Choose who receives these build notification emails in your configuration file. > > Would you like to test your private code? > Travis CI for Private Projects could be your new best friend!

Aug. 29, 2017

Re: [Pharo-dev] poor state of fuel

by Max Leske

Hi Norbert, We still maintain Fuel. I was not aware of the problem you describe. Could you open an issue on github (https://github.com/theseion/Fuel/issues) with a detailed explanation and, if possible, steps to reproduce the problem? Cheers, Max On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: I'm migrating most of my projects to pharo 6.1 at the moment. I come from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that does not need to be installed and makes deployment better. That really feels much better. I use jenkins and there if a test fails a fuel dump is written to disk. The jenkins server is ubuntu linux with the vm of the opensuse build. My laptop has Mac OS and cannot read back those fuel dumps. I use the same image version on jenkins and my laptop. Both are 64bit. I asked that on discord and there was a mentioning that not only the 64 bit fuel has problems. So I wanted to ask what is the state of fuel right now. I consider fuel one of the core technologies in pharo and it is sad if it just stops working. Any feedback is highly appreciated, Norbert

Aug. 29, 2017

poor state of fuel

by Norbert Hartl

I'm migrating most of my projects to pharo 6.1 at the moment. I come from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that does not need to be installed and makes deployment better. That really feels much better. I use jenkins and there if a test fails a fuel dump is written to disk. The jenkins server is ubuntu linux with the vm of the opensuse build. My laptop has Mac OS and cannot read back those fuel dumps. I use the same image version on jenkins and my laptop. Both are 64bit. I asked that on discord and there was a mentioning that not only the 64 bit fuel has problems. So I wanted to ask what is the state of fuel right now. I consider fuel one of the core technologies in pharo and it is sad if it just stops working. Any feedback is highly appreciated, Norbert

Aug. 29, 2017

Re: [Pharo-dev] Pinning Objects in Pharo

by Esteban Lorenzano

> On 29 Aug 2017, at 09:59, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Eliot, > > this test is part of UnifiedFFI (which is Pharo only so far) - not FFI. This was just > a side note. yes, and itâs purpose is to test callbacks in the UFFI context, not callbacks itself :) Esteban > > I would rather be interested if we would like to have a common #pinDuring: > in Squeak, Pharo, Cuis, ... > > Thanks > Torsten > > >> Gesendet: Montag, 28. August 2017 um 22:08 Uhr >> Von: "Eliot Miranda" <eliot.miranda(a)gmail.com> >> An: "Torsten Bergmann" <astares(a)gmx.de>, "Esteban Lorenzano" <estebanlm(a)gmail.com> >> Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, vm-dev(a)lists.squeakfoundation.org >> Betreff: Re: Pinning Objects in Pharo >> >> Hi Torsten, Hi Esteban, >> >>> On Aug 28, 2017, at 9:17 AM, Torsten Bergmann <astares(a)gmx.de> wrote: >>> >>> As some of you are aware of Spur added memory pinning and in Pharo 6.1 (#60510) as well as Pharo 7 >>> we currently have >>> >>> Object>>pin >>> Object>>unpin >>> Object>>isPinned >>> >>> and also Object>>setPinned:. >>> >>> Object pinning is explained by Eliot here [1]. >>> >>> I would propose two changes (at least for Pharo but ideally also for Squeak): >>> >>> 1. IMHO #setPinned: should be moved to a private protocol >>> 2. Provide a #pinDuring: aBlock method like: >>> >>> pinDuring: aBlock >>> [ self pin. >>> aBlock value ] ensure: [ self unpin ] >>> >>> so we can ensure that a pinned object is unpinned after an operation. >>> >>> What do you think? >>> >>> Also I wonder why FFICallbackTests>>#testCqsortWithByteArray is sending #pin but not >>> #unpin afterwards. Maybe that is the reason why there is a flag in this method that it >>> is crashing on Windows. >> >> This test is news to me. Neither the test nor the class is in FFI-Tests at source.squeak.org, which is where the package lives. Why is it missing? >> >>> >>> Bye >>> T. >>> >>> [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-August/195129.h… >>

Aug. 29, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 21 August 2017

by Dimitris Chloupis

Yeah I agree with Phil , VM bugs are kinda big deal. Plus we should not forget that the huge news for Pharo 6 was 64 bit support and there was ton of glory in that one. Pretty much in any language VM enhancement are kinda of big deal , especially stability and performance. Hey Esteban I hope you had a very nice holiday and your charged your batteries, great to have you back , keep rocking :) On Tue, Aug 29, 2017 at 11:35 AM philippe.back(a)highoctane.be < philippe.back(a)gmail.com> wrote: > > > On Aug 28, 2017 6:11 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: > > EstebanLM wrote > > This is my weekly ChangeLog, from 21 August 2017 to 27 August 2017. > > Thank you for all the work you consistently do, especially the stuff deep > down in the system which brings no personal glory but provides the > foundation for the creations of our entire community! > > > I beg to differ as what is done there is actually glorious and deeply > appreciated from where I do stand. > > Esteban, Master of Code (level: 10K). > > Phil > > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Esteban-s-ChangeLog-week-of-21-August-2017-tp4964905p… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > >

Aug. 29, 2017

Re: [Pharo-dev] Esteban's ChangeLog week of 21 August 2017

by philippe.back＠highoctane.be

On Aug 28, 2017 6:11 PM, "Sean P. DeNigris" <sean(a)clipperadams.com> wrote: EstebanLM wrote > This is my weekly ChangeLog, from 21 August 2017 to 27 August 2017. Thank you for all the work you consistently do, especially the stuff deep down in the system which brings no personal glory but provides the foundation for the creations of our entire community! I beg to differ as what is done there is actually glorious and deeply appreciated from where I do stand. Esteban, Master of Code (level: 10K). Phil ----- Cheers, Sean -- View this message in context: http://forum.world.st/Esteban- s-ChangeLog-week-of-21-August-2017-tp4964905p4965162.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 29, 2017

Re: [Pharo-dev] Pinning Objects in Pharo

by Torsten Bergmann

Hi Eliot, this test is part of UnifiedFFI (which is Pharo only so far) - not FFI. This was just a side note. I would rather be interested if we would like to have a common #pinDuring: in Squeak, Pharo, Cuis, ... Thanks Torsten > Gesendet: Montag, 28. August 2017 um 22:08 Uhr > Von: "Eliot Miranda" <eliot.miranda(a)gmail.com> > An: "Torsten Bergmann" <astares(a)gmx.de>, "Esteban Lorenzano" <estebanlm(a)gmail.com> > Cc: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, vm-dev(a)lists.squeakfoundation.org > Betreff: Re: Pinning Objects in Pharo > > Hi Torsten, Hi Esteban, > > > On Aug 28, 2017, at 9:17 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > As some of you are aware of Spur added memory pinning and in Pharo 6.1 (#60510) as well as Pharo 7 > > we currently have > > > > Object>>pin > > Object>>unpin > > Object>>isPinned > > > > and also Object>>setPinned:. > > > > Object pinning is explained by Eliot here [1]. > > > > I would propose two changes (at least for Pharo but ideally also for Squeak): > > > > 1. IMHO #setPinned: should be moved to a private protocol > > 2. Provide a #pinDuring: aBlock method like: > > > > pinDuring: aBlock > > [ self pin. > > aBlock value ] ensure: [ self unpin ] > > > > so we can ensure that a pinned object is unpinned after an operation. > > > > What do you think? > > > > Also I wonder why FFICallbackTests>>#testCqsortWithByteArray is sending #pin but not > > #unpin afterwards. Maybe that is the reason why there is a flag in this method that it > > is crashing on Windows. > > This test is news to me. Neither the test nor the class is in FFI-Tests at source.squeak.org, which is where the package lives. Why is it missing? > > > > > Bye > > T. > > > > [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2017-August/195129.h… >

Aug. 29, 2017