- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Boolean

by Camillo Bruni

why not, let's "forbid" them with an error message! => maybe you can and error to #become: on nil / true / false as well? On 2013-06-26, at 14:20, Torsten Bergmann <astares(a)gmx.de> wrote: > Boolean new -> error > Boolean basicNew -> is possible > > should we care? >

June 26, 2013

HandMorph startup is fun

by StÃ©phane Ducasse

startUp self clearCompositionWindowManager and guess what :) clearCompositionWindowManager is not implementedâ¦. Alain is just disturbing me with all kinds of bogus morphic code :) Stef

June 26, 2013

Boolean

by Torsten Bergmann

Boolean new -> error Boolean basicNew -> is possible should we care?

June 26, 2013

[update 3.0] #30223

by Marcus Denker

June 26, 2013

Re: [Pharo-dev] Help wanted! Test new class organizer.

by Camille Teruel

On 26 juin 2013, at 13:34, Esteban Lorenzano wrote: > > On Jun 26, 2013, at 1:22 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 26 juin 2013, at 12:54, Esteban Lorenzano wrote: >> >>> Hi >>> >>> I finished the integration of the new class organizer, and I need people who can test it before integration. >>> Please, merge the SLICE 6757 >> >> Tested and approved seÃ±or! > > cool :) > >> Only one question why the AllProtocol is a subclass of Protocol? > > no idea.... I just integrated it into the system (a lot of work by itself)... but there is always room for improvements in future steps... I would like to integrate it soon because I need to keep it loading and that means constant refactors... :) > >> As I understand it, AllProtocol shouldn't respond to addMethod: removeMethod: ... and it shouldn't even have a methods instance variable. >> Why don't make an AbstractProtocol with two subclass Protocol and VirtualProtocol and make AllProtocol a subclass of VirtualProtocol. >> Like this, in the future we could for example add a new SmartProtocol (subclass of VirtualProtocol) that automagically categorize methods given some predicate. > > the idea is to add at least an "ExtensionProtocol" who points directly to the owner rpackage. Also we could star to have "composite protocols" in the future. > but yeah, as I said... there is a lot of room for improvement, now that we will have "first class protocols", not just plain strings. So appart this small design point, since everything works fine, I vote for integration. > >> >>> >>> https://pharo.fogbugz.com/f/cases/6757/ >>> >>> and after that execute this script: >>> >>> Smalltalk allClassesAndTraitsDo: [:c || org proOrg | >>> org := c theNonMetaClass organization. >>> proOrg := ClassOrganization importFrom: org. >>> c theNonMetaClass organization: proOrg. >>> >>> org := c theMetaClass organization. >>> proOrg := ClassOrganization importFrom: org. >>> c theMetaClass organization: proOrg ]. >>> >>> This is an important step not just to have a better class organizer (current is pre-existance of dictionaries... so... :P) >> >> Ah ok this is why it doesn't use Dictionary! I was wondering about the rationale behind the old organizer ;). >> >>> It is important also for the next step in RPackage stuff. >>> >>> Esteban >>> >>> >> >> > >

June 26, 2013

Re: [Pharo-dev] Nautilus category filter

by Benjamin

It should still be available since it's implemented on PluggaleListMorph Ben On Jun 26, 2013, at 12:54 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Back in the days the Nautilus Browser had a "filter" text field > directly above the category pane. One just had to click and > enter the name and the list got filtered. > > With more and more packages coming into an image this was very > usefull in Nautilus since it allowed to filter the displayed. > > The Test runner now provides such a filter to easily find a > category. > > > I know there are groups, I know there is "Find Package" in the > menu. But the filter was really helpful and avoided endless > scrolling to initially search a category. > > Is it still available? Maybe as a Nautilus plugin? > > Thx > T. >

June 26, 2013

Re: [Pharo-dev] Help wanted! Test new class organizer.

by Esteban Lorenzano

On Jun 26, 2013, at 1:22 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 juin 2013, at 12:54, Esteban Lorenzano wrote: > >> Hi >> >> I finished the integration of the new class organizer, and I need people who can test it before integration. >> Please, merge the SLICE 6757 > > Tested and approved seÃ±or! cool :) > Only one question why the AllProtocol is a subclass of Protocol? no idea.... I just integrated it into the system (a lot of work by itself)... but there is always room for improvements in future steps... I would like to integrate it soon because I need to keep it loading and that means constant refactors... :) > As I understand it, AllProtocol shouldn't respond to addMethod: removeMethod: ... and it shouldn't even have a methods instance variable. > Why don't make an AbstractProtocol with two subclass Protocol and VirtualProtocol and make AllProtocol a subclass of VirtualProtocol. > Like this, in the future we could for example add a new SmartProtocol (subclass of VirtualProtocol) that automagically categorize methods given some predicate. the idea is to add at least an "ExtensionProtocol" who points directly to the owner rpackage. Also we could star to have "composite protocols" in the future. but yeah, as I said... there is a lot of room for improvement, now that we will have "first class protocols", not just plain strings. > >> >> https://pharo.fogbugz.com/f/cases/6757/ >> >> and after that execute this script: >> >> Smalltalk allClassesAndTraitsDo: [:c || org proOrg | >> org := c theNonMetaClass organization. >> proOrg := ClassOrganization importFrom: org. >> c theNonMetaClass organization: proOrg. >> >> org := c theMetaClass organization. >> proOrg := ClassOrganization importFrom: org. >> c theMetaClass organization: proOrg ]. >> >> This is an important step not just to have a better class organizer (current is pre-existance of dictionaries... so... :P) > > Ah ok this is why it doesn't use Dictionary! I was wondering about the rationale behind the old organizer ;). > >> It is important also for the next step in RPackage stuff. >> >> Esteban >> >> > >

June 26, 2013

Re: [Pharo-dev] [update 3.0] #30222

by Camille Teruel

On 26 juin 2013, at 13:30, Marcus Denker wrote: > > On Jun 26, 2013, at 1:26 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > >> >> On 26 juin 2013, at 13:18, Marcus Denker wrote: >> >>> 11012 Object>>isComplex is related to complex number >>> https://pharo.fogbugz.com/f/cases/11012 >> >> This one is a duplicate of issue 10971. >> 10971 also remove Number>>#arg that is a nonsense in the absence of complex numbers. > > Why was 10971 closed? Because I'm a fool I guess :) It was an error. > > Marcus

June 26, 2013

Re: [Pharo-dev] [update 3.0] #30222

by Marcus Denker

On Jun 26, 2013, at 1:26 PM, Camille Teruel <camille.teruel(a)gmail.com> wrote: > > On 26 juin 2013, at 13:18, Marcus Denker wrote: > >> 11012 Object>>isComplex is related to complex number >> https://pharo.fogbugz.com/f/cases/11012 > > This one is a duplicate of issue 10971. > 10971 also remove Number>>#arg that is a nonsense in the absence of complex numbers. Why was 10971 closed? Marcus

June 26, 2013

Re: [Pharo-dev] [update 3.0] #30222

by Camille Teruel

On 26 juin 2013, at 13:18, Marcus Denker wrote: > 11012 Object>>isComplex is related to complex number > https://pharo.fogbugz.com/f/cases/11012 This one is a duplicate of issue 10971. 10971 also remove Number>>#arg that is a nonsense in the absence of complex numbers.

June 26, 2013