December 2013 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] f9874f: 30640

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: f9874f20e39b4c7b91bb409d052753d24981e798 https://github.com/pharo-project/pharo-core/commit/f9874f20e39b4c7b91bb409d… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-13 (Fri, 13 Dec 2013) Changed paths: A Deprecated30.package/extension/TBehavior/instance/methodDictionary.st A Deprecated30.package/extension/TBehavior/instance/methodDictionary_.st M KernelTests.package/AdditionalMethodStateTest.class/instance/running/setUp.st M Nautilus.package/AbstractNautilusUI.class/instance/buttons behavior/instanceButtonLabel.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script295.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30640.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st A System-Platforms.package/MacOSPlatform.class/instance/accessing/lineEnding.st A System-Platforms.package/OSPlatform.class/instance/accessing/lineEnding.st A System-Platforms.package/UnixPlatform.class/instance/accessing/lineEnding.st A System-Platforms.package/Win32Platform.class/instance/accessing/lineEnding.st R Traits.package/TBehavior.class/instance/accessing method dictionary/methodDictionary.st R Traits.package/TBehavior.class/instance/accessing method dictionary/methodDictionary_.st Log Message: ----------- 30640 12417 Introduce lineEnding on OSPlatform https://pharo.fogbugz.com/f/cases/12417 12371 Deprecated #methodDictionary and #methodDictionary: https://pharo.fogbugz.com/f/cases/12371 http://files.pharo.org/image/30/30640.zip

Dec. 13, 2013

Re: [Pharo-dev] Are all SLICEs self-contained?

by Marcus Denker

On 13 Dec 2013, at 08:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> On 13 Dec 2013, at 05:32, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >> >>> If not, how do I know if a SLICE depends on other SLICEs? >>> >>> For example loading https://pharo.fogbugz.com/f/cases/edit/11282/Removal-DependentFields-refere… using Monticello hangs the image and cannot interrupt with Alt+. Do I need to load another SLICE before? >>> This is a change with quite some impact, it is likely out of date. (when I tried to integrate this or a related I got *a lot* of failing tests and just put it back to âwork neededâ) Marcus

Dec. 13, 2013

Re: [Pharo-dev] Are all SLICEs self-contained?

by Sven Van Caekenberghe

On 13 Dec 2013, at 08:19, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > As far as I know all mcz(s) are self contained. But slices for me are still a big magic, so maybe there is something different. Any mcz can have required packages, dependencies that need to be loaded with it, outside its own contents. A slice is an empty mcz, it has no contents of its own, but it does have a set of required packages. So loading the slice loads the required packages. When you make a slice, you select which dirty packages you want to add. This explain why sometimes a slice is empty: its required packages are missing, either in specification, or in the repository. Sven > Uko > > > On 13 Dec 2013, at 05:32, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > >> If not, how do I know if a SLICE depends on other SLICEs? >> >> For example loading https://pharo.fogbugz.com/f/cases/edit/11282/Removal-DependentFields-refere… using Monticello hangs the image and cannot interrupt with Alt+. Do I need to load another SLICE before? >> >> Cheers, >> >> HernÃ¡n >> >> > > -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Dec. 13, 2013

Re: [Pharo-dev] Is variable shadowing a feature or a bug?

by Marcus Denker

On 12 Dec 2013, at 20:22, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 12 December 2013 19:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> On Thu, Dec 12, 2013 at 7:03 AM, Marcus Denker <marcus.denker(a)inria.fr> >> wrote: >>> >>> >>> On 12 Dec 2013, at 15:44, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >>> wrote: >>> >>>> I just discovered that in Pharo 3 you can do: >>>> >>>> [ :bool | >>>> self logCr: bool. >>>> bool := false. >>>> self logCr: bool. >>>> ] value: true >>>> >>>> Is this a bug or a feature ? >>> >>> >>> https://pharo.fogbugz.com/f/cases/12419/block-arguments-should-be-read-only >> >> >> except that it didn't used to be a bug pre closures, so *if* its important >> to be able to load old code this should be made a preference which is by >> default on. i.e. by default assigning to any argument is an error, but the >> preference can be set to allow assignments to block args. At least IIRC >> that's how it is in Squeak right now. > > It is: "Allow block argument assignment", or Scanner >> > #allowBlockArgumentAssignment, depending on where you look. > Ok, I will do it with the Preference But in the long run, one can get rid of these thingsâ¦ e,g, Step one: code critic rule to detect these cases two: deprecate the code three: remove. Marcus

Dec. 13, 2013

Re: [Pharo-dev] Are all SLICEs self-contained?

by Yuriy Tymchuk

As far as I know all mcz(s) are self contained. But slices for me are still a big magic, so maybe there is something different. Uko On 13 Dec 2013, at 05:32, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > If not, how do I know if a SLICE depends on other SLICEs? > > For example loading https://pharo.fogbugz.com/f/cases/edit/11282/Removal-DependentFields-refere… using Monticello hangs the image and cannot interrupt with Alt+. Do I need to load another SLICE before? > > Cheers, > > HernÃ¡n > >

Dec. 13, 2013

Are all SLICEs self-contained?

by HernÃ¡n Morales Durand

If not, how do I know if a SLICE depends on other SLICEs? For example loading https://pharo.fogbugz.com/f/cases/edit/11282/Removal-DependentFields-refere… using Monticello hangs the image and cannot interrupt with Alt+. Do I need to load another SLICE before? Cheers, HernÃ¡n

Dec. 13, 2013

Re: [Pharo-dev] Is variable shadowing a feature or a bug?

by Frank Shearar

On 12 December 2013 19:04, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Thu, Dec 12, 2013 at 7:03 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: >> >> >> On 12 Dec 2013, at 15:44, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> wrote: >> >> > I just discovered that in Pharo 3 you can do: >> > >> > [ :bool | >> > self logCr: bool. >> > bool := false. >> > self logCr: bool. >> > ] value: true >> > >> > Is this a bug or a feature ? >> >> >> https://pharo.fogbugz.com/f/cases/12419/block-arguments-should-be-read-only > > > except that it didn't used to be a bug pre closures, so *if* its important > to be able to load old code this should be made a preference which is by > default on. i.e. by default assigning to any argument is an error, but the > preference can be set to allow assignments to block args. At least IIRC > that's how it is in Squeak right now. It is: "Allow block argument assignment", or Scanner >> #allowBlockArgumentAssignment, depending on where you look. frank > -- > best, > Eliot

Dec. 12, 2013

Re: [Pharo-dev] about the Pharo Catalog

by Guillermo Polito

I'm now adding it for OpenDBX and glorp. We should create lint rules for it ;) On Thu, Dec 12, 2013 at 10:57 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Yes :) > In the output of the catalog itself > > > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/? > > There is probably a typo in the generator catalogkeyClassesAndExample => > catalogKeyClassesAndExample > 1. Aconcagua > > Please define a class method named catalogDescription returning a > paragraph of description in the configuration class. > 1.1. Keywords > > Please define a class method named catalogKeywords returning an array of > symbols in the configuration class. > 1.2. Key classes and Implementations Notes > > Please define a class method named catalogkeyClassesAndExample returning > a paragraph describing the most important classes of the project and > relevant information such as an example. > 1.3. Key change logs > > Please define a class method named catalogChangeLog returning a paragraph > describing the most important changes in the configuration class. We > suggest to use the following format: > > - Version number - Date - topics > > > ConfigurationOfXXX project version: 'xx' ) load > > or simply > > > - Version number - Date - topics > - Version number - Date - topics > - Version number - Date - topics > > > > On Dec 12, 2013, at 10:49 AM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > is there a place where I can see the metadata methods I need to implement? > > Esteban > > > On Thu, Dec 12, 2013 at 9:59 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> I really want to have an official catalog soon, so please add the missing >> metadata in your configurations. >> In addition I was discussing with robert pergl from Prague and he told me >> that >> when he has a problem with a package he does not know to whom he should >> report so >> I would like to add a catalogContact section. >> Any idea for improvement. >> >> Stef >> > > >

Dec. 12, 2013

Re: [Pharo-dev] Is variable shadowing a feature or a bug?

by Eliot Miranda

On Thu, Dec 12, 2013 at 7:03 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On 12 Dec 2013, at 15:44, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > > > I just discovered that in Pharo 3 you can do: > > > > [ :bool | > > self logCr: bool. > > bool := false. > > self logCr: bool. > > ] value: true > > > > Is this a bug or a feature ? > > https://pharo.fogbugz.com/f/cases/12419/block-arguments-should-be-read-only except that it didn't used to be a bug pre closures, so *if* its important to be able to load old code this should be made a preference which is by default on. i.e. by default assigning to any argument is an error, but the preference can be set to allow assignments to block args. At least IIRC that's how it is in Squeak right now. -- best, Eliot

Dec. 12, 2013

Re: [Pharo-dev] Which tests should be run in CI?

by Eliot Miranda

On Thu, Dec 12, 2013 at 10:21 AM, Chris Cunningham <cunningham.cb(a)gmail.com>wrote: > If it is a compatibility layer, then now that Pharo has it's own #package, > shouldn't the Pharo version of Grease just not include it anymore? Once > the various Smalltalks start to implement what it is claiming it wants, the > compatibility layer for that dialect should change, I would think. So, > Seaside should still use #packages, but on Pharo, it gets the native > #packages results. > > This assumes that what Grease wants out of package is what Pharo provides > - and it is possible that Grease will need different compatibility > artifacts to make the Pharo results match what Grease expects. > > I would think from a Grease perspective, the ideal world is to have > nothing left in Grease at all because all of the dialects have implemented > everything they want, in at least the minimal way they wanted. As a step > towards that, having one dialect removing the need for Grease would also be > a big, happy step forward. > +1. > -cbc > > > On Thu, Dec 12, 2013 at 9:07 AM, Stephan Eggermont <stephan(a)stack.nl>wrote: > >> Doru wrote: >> >This is clearly an issue of Grease. And it is not essential either as >> there are no senders to it. >> >> There are senders in Seaside. They look not so difficult to change. >> >> >So, I see no reason not to rename it in Grease. >> >> It is a compatibility layer, so you wouldn't be able to know looking only >> from Pharo. >> >> Stephan >> >> >> > -- best, Eliot

Dec. 12, 2013