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

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

by Benjamin

Yes it is planned :) The idea is to have it ready for the release of Pharo 3.0 (at last). There is a git repo I just opened[1] where the doc will be :) Every body is free to fork it and to pull-request me :) Ben [1]https://github.com/BenjaminVanRyseghem/Spec_Documentation On 12 Nov 2013, at 23:09, kilon alios <kilon.alios(a)gmail.com> wrote: > Is there any new documentation planned ? > > > On Tue, Nov 12, 2013 at 11:42 PM, Benjamin <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Confirmed and fixed :P > https://pharo.fogbugz.com/default.asp?12153 > > > Ben > > On 12 Nov 2013, at 17:08, Martin Dias <tinchodias(a)gmail.com> wrote: > >> (Checked in Pharo 30567) >> >> On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >>> Thanks Ben. It's neat to have Spec models for tree columns. It was >>> strange to instantiate MorphTreeColumnMorph directly from my Spec >>> model. >>> >>> I found an issue in TreeModel: Only one level of children is shown. >>> Reproduce with: >>> >>> TreeModel new >>> roots: (1 to: 5); >>> childrenBlock: [ :item | 1+item to: 5+item ]; >>> openWithSpec >>> >>> Should I report? >>> >>> MartÃn >>> >>> On Tue, Nov 12, 2013 at 2:59 PM, Benjamin >>> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>>> 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 kilon alios

Is there any new documentation planned ? On Tue, Nov 12, 2013 at 11:42 PM, Benjamin < Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > Confirmed and fixed :P > https://pharo.fogbugz.com/default.asp?12153 > > > Ben > > On 12 Nov 2013, at 17:08, Martin Dias <tinchodias(a)gmail.com> wrote: > > (Checked in Pharo 30567) > > On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > Thanks Ben. It's neat to have Spec models for tree columns. It was > strange to instantiate MorphTreeColumnMorph directly from my Spec > model. > > I found an issue in TreeModel: Only one level of children is shown. > Reproduce with: > > TreeModel new > roots: (1 to: 5); > childrenBlock: [ :item | 1+item to: 5+item ]; > openWithSpec > > Should I report? > > MartÃn > > On Tue, Nov 12, 2013 at 2:59 PM, Benjamin > <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: > > 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] Monticello SmalltalkHub no longer asks for credentials

by Sean P. DeNigris

StÃ©phane Ducasse wrote > sean this is strange because this morning I used my credentials I take back what I said. I think this is a different issue, since it seems to still request in an older 3.0 version, and the change I was talking about I think was in 2.0 ----- Cheers, Sean -- View this message in context: http://forum.world.st/Monticello-SmalltalkHub-no-longer-asks-for-credential… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 12, 2013

Re: [Pharo-dev] Issue with last line / line ending between FileTree and other repositoroes

by Nicolas Cellier

Just a guess, but github warns when a newline is missing at end of file, because there are still a few unix tools in the world inheriting from the early 70s that cannot deal with such files, so maybe someone wanted github to be happy and forced some extra newline at end of each Smalltalk method? 2013/11/12 Eliot Miranda <eliot.miranda(a)gmail.com> > > > > On Tue, Nov 12, 2013 at 12:09 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> Hi Dale, >> >> During Smalltalks, you helped me to start loading my code into GemStone. >> For that, we created a temp FileTree repository so that we could easily >> edit/save and retry the load. That saved us modifying the code elsewhere, >> commit, load again etc... Cool! >> But now I have a problem... I am trying to merge from filetree to my >> original repo. And when I do a diff (Monticello "Changes"), ALL methods >> look like modified. FileTree either: >> >> - Removed last empty lines >> - Changed the last dot of the last line. >> - Removed last space of the last line >> > > Did it perhaps change the line-end character? > > >> >> So...in summary, it is like if it has changed always the very last >> character (whether it is a space, a dot or an empty line). Maybe this is >> related to crlf I don't know. But it is a pain because it looks like I am >> committing 5k changes! hahaha and I cannot easily see what I have really >> changed. >> >> Is this a known problem? Any workaround? >> >> I will send you by private email some screenshots. >> >> Thanks! >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > best, > Eliot >

Nov. 12, 2013

Re: [Pharo-dev] Issue with last line / line ending between FileTree and other repositoroes

by Eliot Miranda

On Tue, Nov 12, 2013 at 12:09 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Dale, > > During Smalltalks, you helped me to start loading my code into GemStone. > For that, we created a temp FileTree repository so that we could easily > edit/save and retry the load. That saved us modifying the code elsewhere, > commit, load again etc... Cool! > But now I have a problem... I am trying to merge from filetree to my > original repo. And when I do a diff (Monticello "Changes"), ALL methods > look like modified. FileTree either: > > - Removed last empty lines > - Changed the last dot of the last line. > - Removed last space of the last line > Did it perhaps change the line-end character? > > So...in summary, it is like if it has changed always the very last > character (whether it is a space, a dot or an empty line). Maybe this is > related to crlf I don't know. But it is a pain because it looks like I am > committing 5k changes! hahaha and I cannot easily see what I have really > changed. > > Is this a known problem? Any workaround? > > I will send you by private email some screenshots. > > Thanks! > > -- > Mariano > http://marianopeck.wordpress.com > -- best, Eliot

Nov. 12, 2013

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

by Benjamin

Confirmed and fixed :P https://pharo.fogbugz.com/default.asp?12153 Ben On 12 Nov 2013, at 17:08, Martin Dias <tinchodias(a)gmail.com> wrote: > (Checked in Pharo 30567) > > On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias(a)gmail.com> wrote: >> Thanks Ben. It's neat to have Spec models for tree columns. It was >> strange to instantiate MorphTreeColumnMorph directly from my Spec >> model. >> >> I found an issue in TreeModel: Only one level of children is shown. >> Reproduce with: >> >> TreeModel new >> roots: (1 to: 5); >> childrenBlock: [ :item | 1+item to: 5+item ]; >> openWithSpec >> >> Should I report? >> >> MartÃn >> >> On Tue, Nov 12, 2013 at 2:59 PM, Benjamin >> <Benjamin.VanRyseghem.Pharo(a)gmail.com> wrote: >>> 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] In-memory FileSystem write streams not being polymorphic

by Nicolas Cellier

And the tests pass, except the file tests which are based on creating a stream thru (FileDirectory default / ...) 2013/11/12 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Hi Sven, > The last Squeak/Pharo locations I am aware of are: > - http://www.squeaksource.org/Xtreams for the Xtreams package > - http://www.squeaksource.org/MetacelloRepository for > ConfigurationOfXtreams (but I just copied the last Config to above repo) > A very important repository for resources of all kind from the original > authors is https://code.google.com/p/xtreams/ > > Those versions above do not load in Pharo3.0 due to several problems > - FileDirectory deprecation (there is an extension method that should be > removed in Pharo branch) > - Xtras package of Xtreams depends on FFI, and FFI does not load cleanly > in Pharo (at least the one found from the ConfigurationOfXtreams) because > ShortRunArray is not found... > > I will try and publish a Pharo branch, but before I do so, is anyone aware > of more recent work, or repository? > > > > > 2013/11/12 Sven Van Caekenberghe <sven(a)stfx.eu> > >> Nicolas, >> >> Is it currently possible to load some latest version of Xtream into Pharo >> 3.0 ? >> >> If yes, from which repository using which Configuration ? >> >> I know that at ESUG 2012, Sean and Martin worked a bit on getting all >> different versions better in sync. >> >> It would be cool if we could at least load it, separate from the >> transition strategy (I agree with your proposal BTW), because many people >> do not know or have not seen what we are actually talking about. >> >> The clean, start from scratch approach of Xtreams also includes a much >> tighter and semantically better defined API. IMHO, a consequence is that >> #get / #next and #put: / #nextPut: are not just plain aliases (a modern use >> of exception handling is one big difference). The compatibility layer might >> be more of a challenge. >> >> The biggest gain is of course if clients switch to the newer API ;-) >> >> Sven >> >> On 12 Nov 2013, at 14:31, Nicolas Cellier < >> nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> > 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] Large difference in image size when loading configuration

by phil＠highoctane.be

Current image is 66.212.444 now (with Glorp and GlorpDBX loaded and working with Postgresql native driver). Configuration now loading nicely and all, including preferences in a single shot. Cool stuff once it works. Phil On Tue, Nov 12, 2013 at 10:20 PM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > >> > > > > It seems that for each repository instance up to 512 (!) versions can be > cached in memory (instance variable cache), including all their version > info, full ancestry until the middle ages, and definitions, including > source code and meta data, in the snapshot. This is really massive. > > marcus is complaining about it since years :) > > > > > The package-cache already contains this data, non-parsed, I know. > > > > Still, the in memory cache should be managed way better, using LRU or > something like that. > > >

Nov. 12, 2013

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

by Nicolas Cellier

Hi Sven, The last Squeak/Pharo locations I am aware of are: - http://www.squeaksource.org/Xtreams for the Xtreams package - http://www.squeaksource.org/MetacelloRepository for ConfigurationOfXtreams (but I just copied the last Config to above repo) A very important repository for resources of all kind from the original authors is https://code.google.com/p/xtreams/ Those versions above do not load in Pharo3.0 due to several problems - FileDirectory deprecation (there is an extension method that should be removed in Pharo branch) - Xtras package of Xtreams depends on FFI, and FFI does not load cleanly in Pharo (at least the one found from the ConfigurationOfXtreams) because ShortRunArray is not found... I will try and publish a Pharo branch, but before I do so, is anyone aware of more recent work, or repository? 2013/11/12 Sven Van Caekenberghe <sven(a)stfx.eu> > Nicolas, > > Is it currently possible to load some latest version of Xtream into Pharo > 3.0 ? > > If yes, from which repository using which Configuration ? > > I know that at ESUG 2012, Sean and Martin worked a bit on getting all > different versions better in sync. > > It would be cool if we could at least load it, separate from the > transition strategy (I agree with your proposal BTW), because many people > do not know or have not seen what we are actually talking about. > > The clean, start from scratch approach of Xtreams also includes a much > tighter and semantically better defined API. IMHO, a consequence is that > #get / #next and #put: / #nextPut: are not just plain aliases (a modern use > of exception handling is one big difference). The compatibility layer might > be more of a challenge. > > The biggest gain is of course if clients switch to the newer API ;-) > > Sven > > On 12 Nov 2013, at 14:31, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 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] Large difference in image size when loading configuration

by StÃ©phane Ducasse

>> > > It seems that for each repository instance up to 512 (!) versions can be cached in memory (instance variable cache), including all their version info, full ancestry until the middle ages, and definitions, including source code and meta data, in the snapshot. This is really massive. marcus is complaining about it since years :) > > The package-cache already contains this data, non-parsed, I know. > > Still, the in memory cache should be managed way better, using LRU or something like that.

Nov. 12, 2013