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 <[email protected]> wrote: > Is there any new documentation planned ? > > > On Tue, Nov 12, 2013 at 11:42 PM, Benjamin > <[email protected]> wrote: > Confirmed and fixed :P > https://pharo.fogbugz.com/default.asp?12153 > > > Ben > > On 12 Nov 2013, at 17:08, Martin Dias <[email protected]> wrote: > >> (Checked in Pharo 30567) >> >> On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <[email protected]> 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 >>> <[email protected]> wrote: >>>> It’s this one: https://pharo.fogbugz.com/default.asp?12135 >>>> >>>> Ben >>>> >>>> On 12 Nov 2013, at 14:49, Martin Dias <[email protected]> wrote: >>>> >>>> I forgot to specify: in latest Pharo (30565) >>>> >>>> On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <[email protected]> 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 >>>> <[email protected]> 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 >>>> <[email protected]> >>>> 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 <[email protected]> wrote: >>>> >>>> >>>> On Nov 12, 2013, at 4:22 AM, Benjamin >>>> <[email protected]> >>>> 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 <[email protected]> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> > >
