- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Sven Van Caekenberghe

<< Sport is a Smalltalk portability layer. Sport presents a consistent interface and implemented in a number of Smalltalk dialects. Smalltalk code written to the Sport interfaces can be run in any Smalltalk dialect without alteration. >> Anyway, that was the idea some years ago. It is somewhat comparable to Grease (used by Seaside). > On 10 Nov 2015, at 21:27, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > anyone care to explain what Sport is , the project description does not help. > > On Tue, Nov 10, 2015 at 8:33 PM stepharo <stepharo(a)free.fr> wrote: > thanks! > > > Le 10/11/15 10:03, Stephan Eggermont a Ã©crit : > > On 10-11-15 08:00, stepharo wrote: > >> Thanks > > > > I assume you want it working in Pharo5? > > There was no #'pharo5.x' > > > > Name: ConfigurationOfSPort2-StephanEggermont.16 > > Author: StephanEggermont > > Time: 10 November 2015, 10:01:56.039515 am > > UUID: 0c712020-3d22-405b-9842-3106b6b9721f > > Ancestors: ConfigurationOfSPort2-StephanEggermont.15 > > > > In-place pharo5 version added > > > > > > > > > >

Nov. 10, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by Dimitris Chloupis

anyone care to explain what Sport is , the project description does not help. On Tue, Nov 10, 2015 at 8:33 PM stepharo <stepharo(a)free.fr> wrote: > thanks! > > > Le 10/11/15 10:03, Stephan Eggermont a Ã©crit : > > On 10-11-15 08:00, stepharo wrote: > >> Thanks > > > > I assume you want it working in Pharo5? > > There was no #'pharo5.x' > > > > Name: ConfigurationOfSPort2-StephanEggermont.16 > > Author: StephanEggermont > > Time: 10 November 2015, 10:01:56.039515 am > > UUID: 0c712020-3d22-405b-9842-3106b6b9721f > > Ancestors: ConfigurationOfSPort2-StephanEggermont.15 > > > > In-place pharo5 version added > > > > > > > > > > >

Nov. 10, 2015

[pharo-project/pharo-core]

by GitHub

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

Nov. 10, 2015

[pharo-project/pharo-core] 268e30: 50431

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 268e3014abc774b59d1e385ca3fc5ef1adbe5ed5 https://github.com/pharo-project/pharo-core/commit/268e3014abc774b59d1e385c… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-11-10 (Tue, 10 Nov 2015) Changed paths: A Graphics-Shapes.package/PathShape.class/instance/adding/addVertex_.st R Graphics-Shapes.package/PathShape.class/instance/as yet unclassified/addVertex_.st R Graphics-Shapes.package/PathShape.class/instance/as yet unclassified/calculatedBounds.st R Graphics-Shapes.package/PathShape.class/instance/as yet unclassified/containsPoint_.st R Graphics-Shapes.package/PathShape.class/instance/as yet unclassified/segmentsDo_.st A Graphics-Shapes.package/PathShape.class/instance/compute/calculatedBounds.st A Graphics-Shapes.package/PathShape.class/instance/enumerating/segmentsDo_.st A Graphics-Shapes.package/PathShape.class/instance/testing/containsPoint_.st R Graphics-Shapes.package/Polygon.class/instance/as yet unclassified/containsPoint_.st R Graphics-Shapes.package/Polygon.class/instance/as yet unclassified/segmentsDo_.st A Graphics-Shapes.package/Polygon.class/instance/enumerating/segmentsDo_.st A Graphics-Shapes.package/Polygon.class/instance/testing/containsPoint_.st A Graphics-Shapes.package/Shape.class/instance/accessing/bounds.st R Graphics-Shapes.package/Shape.class/instance/as yet unclassified/basicContainsPoint_.st R Graphics-Shapes.package/Shape.class/instance/as yet unclassified/bounds.st R Graphics-Shapes.package/Shape.class/instance/as yet unclassified/containsPoint_.st A Graphics-Shapes.package/Shape.class/instance/testing/basicContainsPoint_.st A Graphics-Shapes.package/Shape.class/instance/testing/containsPoint_.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/results/bytecodes.st M OpalCompiler-Core.package/extension/Object/instance/mustBeBooleanInMagic_.st A OpalCompiler-Tests.package/MustBeBooleanTests.class/instance/tests/testDNU.st M Reflectivity.package/ReflectiveMethod.class/instance/evaluation/generatePrimitiveWrapper.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50430.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50431.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50430.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50431.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A Spec-Core.package/TreeModel.class/class/examples/exampleOfAutoRefreshOnExpand.st M Spec-Core.package/TreeModel.class/definition.st A Spec-Core.package/TreeModel.class/instance/api/autoRefreshOnExpand.st A Spec-Core.package/TreeModel.class/instance/api/autoRefreshOnExpand_.st M Spec-Core.package/TreeModel.class/instance/initialization/initialize.st M Spec-MorphicAdapters.package/SpecTreeNodeModel.class/definition.st M Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/accessing/childrenItems.st A Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/accessing/childrenItemsBlock.st A Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/accessing/childrenItemsBlock_.st M Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/accessing/childrenItems_.st M Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/accessing/contents.st M Spec-MorphicAdapters.package/SpecTreeNodeModel.class/instance/accessing/setChildren_.st Log Message: ----------- 50431 16971 fix: support primitive methods wit arguments https://pharo.fogbugz.com/f/cases/16971 16918 Cant configure a tree to auto refresh when a node is folded and then unfolded https://pharo.fogbugz.com/f/cases/16918 16908 wrong source node for pc in mustBeBooleanInMagic https://pharo.fogbugz.com/f/cases/16908 16970 Cleaning Graphics-Shapes categorisation https://pharo.fogbugz.com/f/cases/16970 http://files.pharo.org/image/50/50431.zip

Nov. 10, 2015

Re: [Pharo-dev] Does anybody know if Sport is available in Pharo?

by stepharo

thanks! Le 10/11/15 10:03, Stephan Eggermont a Ã©crit : > On 10-11-15 08:00, stepharo wrote: >> Thanks > > I assume you want it working in Pharo5? > There was no #'pharo5.x' > > Name: ConfigurationOfSPort2-StephanEggermont.16 > Author: StephanEggermont > Time: 10 November 2015, 10:01:56.039515 am > UUID: 0c712020-3d22-405b-9842-3106b6b9721f > Ancestors: ConfigurationOfSPort2-StephanEggermont.15 > > In-place pharo5 version added > > > >

Nov. 10, 2015

Re: [Pharo-dev] Removing Object >> #name

by stepharo

Thanks guille I created two bug entries! https://pharo.fogbugz.com/f/cases/16974/GT-Object-name https://pharo.fogbugz.com/f/cases/16975/versionner-Object-name Stef Le 10/11/15 17:41, Guillermo Polito a Ã©crit : > Ok, so now I repeated what Sven did some time ago, logging each time #name was accessed. > As soon as I found some sender to #name, I removed it. Except from GT and versionner, as they are external projects that I could not add in my slice. > > So I prepared and committed a slice for issue 7241. This slice removes the method #name from object and fixes several senders. > > The ones that I did not fix are the following: > > ====== GT and Glamour ========= > > > gtDisplaySummaryOn: aStream. > self label isEmptyOrNil > ifFalse: [ ^ aStream nextPutAll: self label ]. > self description isEmptyOrNil > ifFalse: [ ^ aStream nextPutAll: self description ]. > aStream nextPutAll: self method name > > > > > configurationBlockForProcessorsCreatedBy: aMethod > > ^ configurationBlocks at: aMethod name ifAbsent: [ self nullConfigurationBlock ] > > > > allowProcessorsFrom: aMethod configuredWith: aBlock > > self allowProcessorsFrom: aMethod. > configurationBlocks at: aMethod name put: aBlock. > > portName > > ^self port name > > > > ====== Versionner ======= > > remove > "search if I am present in other groups and remove myself from these groups, > then remove myself from project dependencies" > (self project groups select: [ :aGroup | aGroup dependencies includes: name ]) > do: [ :aGroup | aGroup removeDependency: name]. > self project dependencies: (self project dependencies reject: [ :dep | dep = self]). > self project announcer announce: (MTProjectModelChanged project: self) > > > MBGroupInfo>>name > ^ self spec name > > > Guille > >> On 10 nov 2015, at 4:05 p.m., stepharo <stepharo(a)free.fr> wrote: >> >> Thanks you both. >> I love your attitude :) >> >> Stef >> >> >> Le 10/11/15 11:35, Sven Van Caekenberghe a Ã©crit : >>> Hi Guillermo et al, >>> >>>> On 10 Nov 2015, at 11:31, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>>> >>>> Hey, >>>> >>>> I was following the discussion about Class>>#name and Object>>#name so I checked what happened if I removed #name from Object. >>>> >>>> 1) The system did not blew up. I could open a browser and a test runner. >>>> >>>> 2) I could use spotter, look for a class, dive in, look for methodsâ¦ Same for the inspector. >>>> >>>> 3) I ran all the tests in the image. >>>> - I saw some failures in GT* and Glamour. I ran them in a new image and they are not failing so maybe they are broken because of the change or some side effect of the tests? >>>> - Then I saw some failures of OpenToolTest and MBGroupInfoTest that *do look related* >>>> >>>> 4) I created a Package and it worked >>>> >>>> 5) I tried to create a class and it exploded with RBBrowserEnvironment DNU #includesKey:. >>>> This however explodes also in a clean image so I do not think it is related. >>>> >>>> 6) I could however create new methods... >>>> >>>> Of course integrating such a little change is still scary :). But I can propose a sliceâ¦ Votes in favor? :) >>>> >>>> Guille >>> Some months ago I did some more experiments, like you, please see this old thread (at the end): >>> >>> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >>> >>> I am certainly willing to help. >>> >>> Sven >>> >> > >

Nov. 10, 2015

Re: [Pharo-dev] Removing Object >> #name

by Guillermo Polito

Ok, so now I repeated what Sven did some time ago, logging each time #name was accessed. As soon as I found some sender to #name, I removed it. Except from GT and versionner, as they are external projects that I could not add in my slice. So I prepared and committed a slice for issue 7241. This slice removes the method #name from object and fixes several senders. The ones that I did not fix are the following: ====== GT and Glamour ========= gtDisplaySummaryOn: aStream. self label isEmptyOrNil ifFalse: [ ^ aStream nextPutAll: self label ]. self description isEmptyOrNil ifFalse: [ ^ aStream nextPutAll: self description ]. aStream nextPutAll: self method name configurationBlockForProcessorsCreatedBy: aMethod ^ configurationBlocks at: aMethod name ifAbsent: [ self nullConfigurationBlock ] allowProcessorsFrom: aMethod configuredWith: aBlock self allowProcessorsFrom: aMethod. configurationBlocks at: aMethod name put: aBlock. portName ^self port name ====== Versionner ======= remove "search if I am present in other groups and remove myself from these groups, then remove myself from project dependencies" (self project groups select: [ :aGroup | aGroup dependencies includes: name ]) do: [ :aGroup | aGroup removeDependency: name]. self project dependencies: (self project dependencies reject: [ :dep | dep = self]). self project announcer announce: (MTProjectModelChanged project: self) MBGroupInfo>>name ^ self spec name Guille > On 10 nov 2015, at 4:05 p.m., stepharo <stepharo(a)free.fr> wrote: > > Thanks you both. > I love your attitude :) > > Stef > > > Le 10/11/15 11:35, Sven Van Caekenberghe a Ã©crit : >> Hi Guillermo et al, >> >>> On 10 Nov 2015, at 11:31, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >>> >>> Hey, >>> >>> I was following the discussion about Class>>#name and Object>>#name so I checked what happened if I removed #name from Object. >>> >>> 1) The system did not blew up. I could open a browser and a test runner. >>> >>> 2) I could use spotter, look for a class, dive in, look for methodsâ¦ Same for the inspector. >>> >>> 3) I ran all the tests in the image. >>> - I saw some failures in GT* and Glamour. I ran them in a new image and they are not failing so maybe they are broken because of the change or some side effect of the tests? >>> - Then I saw some failures of OpenToolTest and MBGroupInfoTest that *do look related* >>> >>> 4) I created a Package and it worked >>> >>> 5) I tried to create a class and it exploded with RBBrowserEnvironment DNU #includesKey:. >>> This however explodes also in a clean image so I do not think it is related. >>> >>> 6) I could however create new methods... >>> >>> Of course integrating such a little change is still scary :). But I can propose a sliceâ¦ Votes in favor? :) >>> >>> Guille >> Some months ago I did some more experiments, like you, please see this old thread (at the end): >> >> https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed >> >> I am certainly willing to help. >> >> Sven >> > >

Nov. 10, 2015

Re: [Pharo-dev] Removing Object >> #name

by stepharo

Thanks you both. I love your attitude :) Stef Le 10/11/15 11:35, Sven Van Caekenberghe a Ã©crit : > Hi Guillermo et al, > >> On 10 Nov 2015, at 11:31, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >> Hey, >> >> I was following the discussion about Class>>#name and Object>>#name so I checked what happened if I removed #name from Object. >> >> 1) The system did not blew up. I could open a browser and a test runner. >> >> 2) I could use spotter, look for a class, dive in, look for methodsâ¦ Same for the inspector. >> >> 3) I ran all the tests in the image. >> - I saw some failures in GT* and Glamour. I ran them in a new image and they are not failing so maybe they are broken because of the change or some side effect of the tests? >> - Then I saw some failures of OpenToolTest and MBGroupInfoTest that *do look related* >> >> 4) I created a Package and it worked >> >> 5) I tried to create a class and it exploded with RBBrowserEnvironment DNU #includesKey:. >> This however explodes also in a clean image so I do not think it is related. >> >> 6) I could however create new methods... >> >> Of course integrating such a little change is still scary :). But I can propose a sliceâ¦ Votes in favor? :) >> >> Guille > Some months ago I did some more experiments, like you, please see this old thread (at the end): > > https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed > > I am certainly willing to help. > > Sven >

Nov. 10, 2015

Re: [Pharo-dev] Removing Object >> #name

by Sven Van Caekenberghe

Hi Guillermo et al, > On 10 Nov 2015, at 11:31, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hey, > > I was following the discussion about Class>>#name and Object>>#name so I checked what happened if I removed #name from Object. > > 1) The system did not blew up. I could open a browser and a test runner. > > 2) I could use spotter, look for a class, dive in, look for methodsâ¦ Same for the inspector. > > 3) I ran all the tests in the image. > - I saw some failures in GT* and Glamour. I ran them in a new image and they are not failing so maybe they are broken because of the change or some side effect of the tests? > - Then I saw some failures of OpenToolTest and MBGroupInfoTest that *do look related* > > 4) I created a Package and it worked > > 5) I tried to create a class and it exploded with RBBrowserEnvironment DNU #includesKey:. > This however explodes also in a clean image so I do not think it is related. > > 6) I could however create new methods... > > Of course integrating such a little change is still scary :). But I can propose a sliceâ¦ Votes in favor? :) > > Guille Some months ago I did some more experiments, like you, please see this old thread (at the end): https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed I am certainly willing to help. Sven

Nov. 10, 2015

Removing Object >> #name

by Guillermo Polito

Hey, I was following the discussion about Class>>#name and Object>>#name so I checked what happened if I removed #name from Object. 1) The system did not blew up. I could open a browser and a test runner. 2) I could use spotter, look for a class, dive in, look for methodsâ¦ Same for the inspector. 3) I ran all the tests in the image. - I saw some failures in GT* and Glamour. I ran them in a new image and they are not failing so maybe they are broken because of the change or some side effect of the tests? - Then I saw some failures of OpenToolTest and MBGroupInfoTest that *do look related* 4) I created a Package and it worked 5) I tried to create a class and it exploded with RBBrowserEnvironment DNU #includesKey:. This however explodes also in a clean image so I do not think it is related. 6) I could however create new methods... Of course integrating such a little change is still scary :). But I can propose a sliceâ¦ Votes in favor? :) Guille

Nov. 10, 2015