May 2015 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50067 Home: https://github.com/pharo-project/pharo-core

May 26, 2015

[pharo-project/pharo-core] d6a5f6: 50067

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d6a5f6e4931908ba03194a4b87f14b7c3da95746 https://github.com/pharo-project/pharo-core/commit/d6a5f6e4931908ba03194a4b… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-05-26 (Tue, 26 May 2015) Changed paths: A OpalCompiler-Core.package/OCASTTranslator.class/instance/inline messages factored/emitCaseOf_otherwiseBlock_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/inline messages/emitCaseOfOtherwise_.st M OpalCompiler-Core.package/OCASTTranslator.class/instance/inline messages/emitCaseOf_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50066.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50067.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50066.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50067.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50067 15570 CaseOf: pattern from Opal is different from old compiler and breaks the JIT compiler https://pharo.fogbugz.com/f/cases/15570 http://files.pharo.org/image/50/50067.zip

May 26, 2015

Re: [Pharo-dev] Gofer upgrade error

by Ben Coman

Thanks Leo. Indeed I see the commands you tried are suggested in those references. On Tue, May 26, 2015 at 3:26 AM, Leo <lpaniceres(a)gmail.com> wrote: > Ben, > the documentation for "Gofer upgrade" is > http://file-pharo.inria.fr/doc/4.0/class/Gofer.html Doing this is 50064 I gives... 'MNU receiver of "default" is nil' in... GoferUnload>>unregisterPackageInfo: aWorkingCopy PackageOrganizer default unregisterPackage: aWorkingCopy packageInfo where PackageOrganizer is an unknown class. I've logged an issue... https://pharo.fogbugz.com/default.asp?15615 (whoops, I didn't notice Stef already created 15602) > and for "Gofer gofer update" > http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Gofer.pdf Doing this gives... 'MNU: MCWorkingCopy>>packageInfo' in... GoferCleanup>>cleanupCategories: aWorkingCopy aWorkingCopy packageInfo systemCategories do: [ :category | (SystemOrganization goferClassesInCategory: category) isEmpty ifTrue: [ SystemOrganization removeSystemCategory: category ] ] Doing this again but in 20628 gives... "The method MCPackageManager>>packageInfo has been deprecated. Use #packageSet" So there remain 9 senders of packageInfo in 50064. I wasn't sure what issue to log here. But the bigger question is how might we guard against this sort of thing slipping through when we remove deprecations from the Image? cheers -ben > afectuosamente > Leo > > Message: 5 > Date: Mon, 25 May 2015 23:59:38 +0800 > From: Ben Coman <btc(a)openinworld.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Gofer upgrade error > Message-ID: > <CAProBT=B2yzdjUWveea8w2c4PY_NH2ZuGk-TW-ZWhHC3iv9KzA(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > > > Hi Leo, > > I'm probably not the one able to provide a useful answer, but I'm > curious which documentation describes that procedure :) ? It looks > like something you might do in another different application. > > btw, which third party packages are you trying to update? > > cheers -ben > > > > P.S. Ideally all mail-list posts would be "plain text" (e.g. [1] for > gmail), but please at least refrain from using garish fonts :) > > [1] https://mathiasbynens.be/notes/gmail-plain-text > > > On Mon, May 25, 2015 at 9:54 PM, Leo Paniceres <lpaniceres(a)gmail.com> wrote: > > > Hi Stephan > I'm trying to have my image updated to the last version of each package > that I'm using. > I'm trying first: > Gofer upgrade (to update Gofer) > and then to update: > Gofer gofer update (also have an error) > > Any advice to have all my third party packages updated? > > Thanks > > > > ------------------------------ > > Message: 4 > Date: Mon, 25 May 2015 08:53:26 +0200 > From: stepharo <stepharo(a)free.fr> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] Gofer upgrade error > Message-ID: <5562C6E6.901(a)free.fr> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Hello leo > > Thanks for your feedback. We will fix this > > unregisterPackageInfo: aWorkingCopy > PackageOrganizer default > unregisterPackage: aWorkingCopy packageInfo > https://pharo.fogbugz.com/default.asp?15602 > > > I do not think that anybody ever used upgrade. :) > What do you want to do exactly? > have a look at the deep into pharo book, there is a chapter on Gofer. > > > Le 25/5/15 08:02, Leo a ?crit : > > I have a fresh image of Pharo 4 -just downloaded-. > > When I try > Gofer upgrade > > I receive a MessageNotUnderstood: receiver of default is nil. > > What is happening? > > thanks

May 26, 2015

[Update][Pharo4] 40614

by Marcus Denker

40614 15284 [Backport 4.0]: 15384 kommiter throws DNU when browsing remotes https://pharo.fogbugz.com/f/cases/15284 http://files.pharo.org/image/40/40614.zip

May 26, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/40614 Home: https://github.com/pharo-project/pharo-core

May 26, 2015

Re: [Pharo-dev] String>>#adaptToNumber:andSend:

by Marcus Denker

> On 26 May 2015, at 15:51, Florin Mateoc <fmateoc(a)gmail.com> wrote: > > On 5/26/2015 9:38 AM, Marcus Denker wrote: >> >>> On 26 May 2015, at 14:51, Florin Mateoc <fmateoc(a)gmail.com <mailto:fmateoc@gmail.com>> wrote: >>> >>> Hi Stef, >>> >>> I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the >>> strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus >>> the adaptTo...:andSend: methods) should simply be removed from String. >>> While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break. >> >> I committed a slice: >> >> >> https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend <https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend> >> >> >> >> Marcus > > > Hi Markus, > > Thank you. > I forgot to mention, the non-String implementations of adaptToString:andSend: are part of the same bunch and they can now also go, nobody sends them anymore > Ah, yes. I have updated the fix. Marcus

May 26, 2015

Re: [Pharo-dev] String>>#adaptToNumber:andSend:

by Florin Mateoc

On 5/26/2015 9:38 AM, Marcus Denker wrote: > >> On 26 May 2015, at 14:51, Florin Mateoc <fmateoc(a)gmail.com <mailto:fmateoc@gmail.com>> wrote: >> >> Hi Stef, >> >> I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the >> strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus >> the adaptTo...:andSend: methods) should simply be removed from String. >> While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break. > > I committed a slice: > > https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend > > > Marcus Hi Markus, Thank you. I forgot to mention, the non-String implementations of adaptToString:andSend: are part of the same bunch and they can now also go, nobody sends them anymore Florin

May 26, 2015

Re: [Pharo-dev] translateBy: vs translatedBy:

by Peter UhnÃ¡k

> > I vote for renaming to Rectangle>>translatedBy:, because it returns a new > translated rectangle instance. > -1 There is no benefit in renaming a single method, apart from creating more confusion. If anything, the whole Rectangle API would have to be changed, as there is plethora of similar methods (expandBy:, extendBy:, merge:, etc.) Pretty much all Rectangle messages are immutable and create new Rectangle, thus I feel it is unnecessary to state it explicitly. In VW there is plenty of methods (e.g. left:) that mutates it, thus unlike Pharo a clear distinction is required. Peter

May 26, 2015

Re: [Pharo-dev] String>>#adaptToNumber:andSend:

by Marcus Denker

> On 26 May 2015, at 14:51, Florin Mateoc <fmateoc(a)gmail.com> wrote: > > Hi Stef, > > I think this one's easy, especially for Pharo. Since apparently it was Etoys, not Morphic, that was or is using the > strings and numbers mixed arithmetic, and Pharo does not care about Etoys, the arithmetic protocol (the operators plus > the adaptTo...:andSend: methods) should simply be removed from String. > While I did not perform any extensive testing, I did remove them in a Squeak (Morphic) image and nothing seemed to break. I committed a slice: https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend <https://pharo.fogbugz.com/f/cases/2906/Analyze-adaptToNumber-andSend> Marcus

May 26, 2015

Re: [Pharo-dev] translateBy: vs translatedBy:

by Aliaksei Syrel

Hi Serge, I vote for renaming to Rectangle>>translatedBy:, because it returns a new translated rectangle instance. For example in bloc there is BlUserInputEvent and it has two methods: translateBy: and translatedBy:. First one actually modifies position (mutates object) the second one creates a translated copy of the event. Hence Rectangle is suppose to be immutable I think translatedBy: is better name. Cheers, Alex On Tue, May 26, 2015 at 2:41 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > In Pharo 4.0, there is a Rectangle>>translateBy: aFactor method. > The same method in VW is called translatedBy: > > In Pharo, there is also a translatedToBeWithin: and > translatedAndSquishedToBeWithin: > and scaledBy: > > Just to be consistent, this is maybe better to use translatedBy: > instead of translateBy: ? > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > >

May 26, 2015