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

[pharo-project/pharo-core] c0600e: 30566

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: c0600e5f2c660098f6ad0cace7fdf97b690fe7ef https://github.com/pharo-project/pharo-core/commit/c0600e5f2c660098f6ad0cac… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-11-12 (Tue, 12 Nov 2013) Changed paths: M Morphic-Base.package/MenuMorph.class/instance/events/keyStroke_.st A Morphic-Base.package/MenuMorph.class/instance/events/recordFiltering_.st A Morphic-Base.package/MenuMorph.class/instance/filtering/getFiltering_.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script222.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30566.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Core.package/SpecAdapterBindings.class/instance/initialize/initializeBindings.st M Spec-Debugger.package/SpecDebugger.class/instance/updating/updateInspectorsFromContext_.st M Spec-MorphicAdapters.package/MorphicAdapterBindings.class/instance/initialize/initializeBindings.st Log Message: ----------- 30566 - Issue: 12139 Navigating in menus https://pharo.fogbugz.com/f/cases/12139/Navigating-in-menus - Issue 12135 Missing bindings https://pharo.fogbugz.com/f/cases/12135/Missing-bindings - 12055 The Spec Debugger should not require the registered inspector to be built on Spec https://pharo.fogbugz.com/f/cases/12055/The-Spec-Debugger-should-not-requir… http://files.pharo.org/image/30/30566.zip

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

Itâs this one: https://pharo.fogbugz.com/default.asp?12135 Ben On 12 Nov 2013, at 14:49, Martin Dias <tinchodias(a)gmail.com> wrote: > I forgot to specify: in latest Pharo (30565) > > On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> I think there is some issue with TreeColumnModel. For example: >> >> TreeModel exampleWithCustomColumnsAndNodes >> >> Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" >> >> Should I report in fogbugz? >> >> thanks, >> MartÃn >> >> On Tue, Nov 12, 2013 at 2:21 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> Yes this is what I did for the change sorter. I do not like this DSL like >>> way of passing block over block over block >>> over blocks. >>> >>> I love blocks but methods are named blocks and I prefer them. >>> >>> Stef >>> >>> biut that method can be written: >>> >>> aMenu addGroup: (MenuGroupModel new >>> addItem: (MenuItemModel new >>> name: 'Browse Full'; >>> action: [ self browseSelectedObject ]; >>> shortcut: $b command mac | $b alt win | $b alt unix); >>> addItem: (MenuItem new >>> name: 'Browse Class'; >>> action: [ self browseSelectedObjectClass ])). >>> >>> and you do not have to declare variables for that (and is a lot better than >>> using a block, IMO). >>> >>> >>> >>> On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> >>> wrote: >>> >>> One can just use an object too. >>> >>> Itâs just that otherwise, it pollutes a bit the method with tons of inst >>> vars >>> (and then you forget to use them :P) >>> >>> Ben >>> >>> On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>> >>> On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >>> wrote: >>> >>> It is not necessary better, but it saves you from having hundreds of temp >>> vars :) >>> >>> Ben >>> >>> On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> wrote: >>> >>> >>> Example: >>> aMenu addGroup: [ :aGroup | >>> aGroup addItem: [ :anItem | >>> anItem name: 'Browse Full'; >>> action: [ self browseSelectedObject ]; >>> shortcut: $b command mac | $b alt win | $b alt unix ]. >>> aGroup addItem: [ :anItem | >>> anItem name: 'Browse Class'; >>> action: [ self browseSelectedObjectClass ] ] ]. >>> >>> >>> I do not see the value of passing block to add element to groups >>> why not the normal way i.e. passing an object. I do not get why executing >>> a block with an object is better? >>> >>> >>> he, I thought the same :) >>> >>> >>> Stef >>> >>> >>> >>> >>> >>> >

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

Then foo it :) Both way are supported, so I do not really get the point of this discussion :) Ben On 12 Nov 2013, at 14:21, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes this is what I did for the change sorter. I do not like this DSL like way of passing block over block over block > over blocks. > > I love blocks but methods are named blocks and I prefer them. > > Stef > >> biut that method can be written: >> >> aMenu addGroup: (MenuGroupModel new >> addItem: (MenuItemModel new >> name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix); >> addItem: (MenuItem new >> name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ])). >> >> and you do not have to declare variables for that (and is a lot better than using a block, IMO). >> >> >> >> On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >> >>> One can just use an object too. >>> >>> Itâs just that otherwise, it pollutes a bit the method with tons of inst vars >>> (and then you forget to use them :P) >>> >>> Ben >>> >>> On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> >>>> >>>> On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>>> >>>>> It is not necessary better, but it saves you from having hundreds of temp vars :) >>>>> >>>>> Ben >>>>> >>>>> On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>>> >>>>>>> >>>>>>> Example: >>>>>>> aMenu addGroup: [ :aGroup | >>>>>>> aGroup addItem: [ :anItem | >>>>>>> anItem name: 'Browse Full'; >>>>>>> action: [ self browseSelectedObject ]; >>>>>>> shortcut: $b command mac | $b alt win | $b alt unix ]. >>>>>>> aGroup addItem: [ :anItem | >>>>>>> anItem name: 'Browse Class'; >>>>>>> action: [ self browseSelectedObjectClass ] ] ]. >>>>>>> >>>>>> >>>>>> I do not see the value of passing block to add element to groups >>>>>> why not the normal way i.e. passing an object. I do not get why executing >>>>>> a block with an object is better? >>>> >>>> he, I thought the same :) >>>> >>>>>> >>>>>> Stef >>>>>> >>>>> >>>> >>> >> >

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Benjamin

There is one reported since yesterday I think about missing morphic bindings ;) Thanks for your feedback :) Ben On 12 Nov 2013, at 14:48, Martin Dias <tinchodias(a)gmail.com> wrote: > I think there is some issue with TreeColumnModel. For example: > > TreeModel exampleWithCustomColumnsAndNodes > > Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" > > Should I report in fogbugz? > > thanks, > MartÃn > > On Tue, Nov 12, 2013 at 2:21 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes this is what I did for the change sorter. I do not like this DSL like >> way of passing block over block over block >> over blocks. >> >> I love blocks but methods are named blocks and I prefer them. >> >> Stef >> >> biut that method can be written: >> >> aMenu addGroup: (MenuGroupModel new >> addItem: (MenuItemModel new >> name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix); >> addItem: (MenuItem new >> name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ])). >> >> and you do not have to declare variables for that (and is a lot better than >> using a block, IMO). >> >> >> >> On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> >> wrote: >> >> One can just use an object too. >> >> Itâs just that otherwise, it pollutes a bit the method with tons of inst >> vars >> (and then you forget to use them :P) >> >> Ben >> >> On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> wrote: >> >> It is not necessary better, but it saves you from having hundreds of temp >> vars :) >> >> Ben >> >> On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> >> Example: >> aMenu addGroup: [ :aGroup | >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix ]. >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ] ] ]. >> >> >> I do not see the value of passing block to add element to groups >> why not the normal way i.e. passing an object. I do not get why executing >> a block with an object is better? >> >> >> he, I thought the same :) >> >> >> Stef >> >> >> >> >> >> >

Nov. 12, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Stephan Eggermont

How could we recognize the using of a deprecated stream? With a tool like DeprecationFinder it should be easy to walk the repositories and find out where they are used. Stephan

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Martin Dias

I forgot to specify: in latest Pharo (30565) On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > I think there is some issue with TreeColumnModel. For example: > > TreeModel exampleWithCustomColumnsAndNodes > > Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" > > Should I report in fogbugz? > > thanks, > MartÃn > > On Tue, Nov 12, 2013 at 2:21 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes this is what I did for the change sorter. I do not like this DSL like >> way of passing block over block over block >> over blocks. >> >> I love blocks but methods are named blocks and I prefer them. >> >> Stef >> >> biut that method can be written: >> >> aMenu addGroup: (MenuGroupModel new >> addItem: (MenuItemModel new >> name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix); >> addItem: (MenuItem new >> name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ])). >> >> and you do not have to declare variables for that (and is a lot better than >> using a block, IMO). >> >> >> >> On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> >> wrote: >> >> One can just use an object too. >> >> Itâs just that otherwise, it pollutes a bit the method with tons of inst >> vars >> (and then you forget to use them :P) >> >> Ben >> >> On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >> On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> >> wrote: >> >> It is not necessary better, but it saves you from having hundreds of temp >> vars :) >> >> Ben >> >> On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >> >> >> Example: >> aMenu addGroup: [ :aGroup | >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Full'; >> action: [ self browseSelectedObject ]; >> shortcut: $b command mac | $b alt win | $b alt unix ]. >> aGroup addItem: [ :anItem | >> anItem name: 'Browse Class'; >> action: [ self browseSelectedObjectClass ] ] ]. >> >> >> I do not see the value of passing block to add element to groups >> why not the normal way i.e. passing an object. I do not get why executing >> a block with an object is better? >> >> >> he, I thought the same :) >> >> >> Stef >> >> >> >> >> >>

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by Martin Dias

I think there is some issue with TreeColumnModel. For example: TreeModel exampleWithCustomColumnsAndNodes Raises "ByteSymbol(Object)>>doesNotUnderstand: #adapt:" Should I report in fogbugz? thanks, MartÃn On Tue, Nov 12, 2013 at 2:21 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes this is what I did for the change sorter. I do not like this DSL like > way of passing block over block over block > over blocks. > > I love blocks but methods are named blocks and I prefer them. > > Stef > > biut that method can be written: > > aMenu addGroup: (MenuGroupModel new > addItem: (MenuItemModel new > name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix); > addItem: (MenuItem new > name: 'Browse Class'; > action: [ self browseSelectedObjectClass ])). > > and you do not have to declare variables for that (and is a lot better than > using a block, IMO). > > > > On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> > wrote: > > One can just use an object too. > > Itâs just that otherwise, it pollutes a bit the method with tons of inst > vars > (and then you forget to use them :P) > > Ben > > On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > > It is not necessary better, but it saves you from having hundreds of temp > vars :) > > Ben > > On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Example: > aMenu addGroup: [ :aGroup | > aGroup addItem: [ :anItem | > anItem name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix ]. > aGroup addItem: [ :anItem | > anItem name: 'Browse Class'; > action: [ self browseSelectedObjectClass ] ] ]. > > > I do not see the value of passing block to add element to groups > why not the normal way i.e. passing an object. I do not get why executing > a block with an object is better? > > > he, I thought the same :) > > > Stef > > > > > >

Nov. 12, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

And of course, I forgot all the usages of ReadWriteStream. I started rewriting some usage in Squeak, and good news, 95% of usage is unecessary, a WriteStream is sufficient. 2013/11/12 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > It's just a matter of selecting a strategy. I've proposed two: > A) create a wrapper class for legacy Stream compatibility selectors > B) create extensions for Legacy Stream compatibility selectors > My preference goes to A) > > The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: > ...), otherwise we will import all the cruft in Xtream and would go back to > our starting point... > Once the minimal support written (a few hours should be enough), we should > gradually switch each every legacy Stream usage -> Xtream. > > An area which require more work is those Streams that have mixed > conventions (one portion is interpreted as text, another as binary). > In theory that's easy, we just have two streams and they both wrap on a > low level binary stream, but that means we have to be very cautious with > buffers and caches. > > Another area of work is usage of ugly selectors like name (we try to > access the file name from the Stream API, arghh). Those usages are bad and > require a rewrite. > > > 2013/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> >> >> or of course, you start looking at porting XStreams to pharo ;), which on >> the long run will >> solve many more problems. The current situation is not that satisfactory >> >> >> having experience with it and thinking about a plan for the beginning of >> 40 would be great. >> I know that nicolas ported XTream to pharo/squeak. Now understanding how >> integrate it would be nice. >> Stef >> >> >

Nov. 12, 2013

Re: [Pharo-dev] In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

It's just a matter of selecting a strategy. I've proposed two: A) create a wrapper class for legacy Stream compatibility selectors B) create extensions for Legacy Stream compatibility selectors My preference goes to A) The legacy support MUST be minimal (next nextPut: nextPutAll: peek upTo: ...), otherwise we will import all the cruft in Xtream and would go back to our starting point... Once the minimal support written (a few hours should be enough), we should gradually switch each every legacy Stream usage -> Xtream. An area which require more work is those Streams that have mixed conventions (one portion is interpreted as text, another as binary). In theory that's easy, we just have two streams and they both wrap on a low level binary stream, but that means we have to be very cautious with buffers and caches. Another area of work is usage of ugly selectors like name (we try to access the file name from the Stream API, arghh). Those usages are bad and require a rewrite. 2013/11/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > > or of course, you start looking at porting XStreams to pharo ;), which on > the long run will > solve many more problems. The current situation is not that satisfactory > > > having experience with it and thinking about a plan for the beginning of > 40 would be great. > I know that nicolas ported XTream to pharo/squeak. Now understanding how > integrate it would be nice. > Stef > >

Nov. 12, 2013

Re: [Pharo-dev] Spec new release :)

by StÃ©phane Ducasse

Yes this is what I did for the change sorter. I do not like this DSL like way of passing block over block over block over blocks. I love blocks but methods are named blocks and I prefer them. Stef > biut that method can be written: > > aMenu addGroup: (MenuGroupModel new > addItem: (MenuItemModel new > name: 'Browse Full'; > action: [ self browseSelectedObject ]; > shortcut: $b command mac | $b alt win | $b alt unix); > addItem: (MenuItem new > name: 'Browse Class'; > action: [ self browseSelectedObjectClass ])). > > and you do not have to declare variables for that (and is a lot better than using a block, IMO). > > > > On Nov 12, 2013, at 9:36 AM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > >> One can just use an object too. >> >> Itâs just that otherwise, it pollutes a bit the method with tons of inst vars >> (and then you forget to use them :P) >> >> Ben >> >> On 12 Nov 2013, at 13:05, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >>> >>> On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> >>>> It is not necessary better, but it saves you from having hundreds of temp vars :) >>>> >>>> Ben >>>> >>>> On 12 Nov 2013, at 01:49, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>>> >>>>>> >>>>>> Example: >>>>>> aMenu addGroup: [ :aGroup | >>>>>> aGroup addItem: [ :anItem | >>>>>> anItem name: 'Browse Full'; >>>>>> action: [ self browseSelectedObject ]; >>>>>> shortcut: $b command mac | $b alt win | $b alt unix ]. >>>>>> aGroup addItem: [ :anItem | >>>>>> anItem name: 'Browse Class'; >>>>>> action: [ self browseSelectedObjectClass ] ] ]. >>>>>> >>>>> >>>>> I do not see the value of passing block to add element to groups >>>>> why not the normal way i.e. passing an object. I do not get why executing >>>>> a block with an object is better? >>> >>> he, I thought the same :) >>> >>>>> >>>>> Stef >>>>> >>>> >>> >> >

Nov. 12, 2013