What is the point of this folder?
Do you expect us to write documentation there?
Why do you systematically are again pier?  especially when I wrote successfully 
the seaside book with it
and so far the only book I saw using markdown are not book?

May be I should go back to write in plain latex and like that everybody will be 
happy.
Or I should even do not write any book. Because when I see the amount of energy 
it takes and 
after people kill my fun with fucking syntactic issue because I do not use 
markdown.

Stef

> I added https://github.com/pharo-project/pharo-documentation 
> 
> On 2013-11-13, at 02:47, Stéphane Ducasse <stephane.duca...@inria.fr> wrote:
> 
>> Ben it would be good to do it pier format so that we get html and pdf
>> and also to avoid to have documentation spread all over.
>> 
>> Stef
>> 
>> On Nov 12, 2013, at 11:42 PM, Benjamin 
>> <benjamin.vanryseghem.ph...@gmail.com> wrote:
>> 
>>> 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.al...@gmail.com> wrote:
>>> 
>>>> Is there any new documentation planned ? 
>>>> 
>>>> 
>>>> On Tue, Nov 12, 2013 at 11:42 PM, Benjamin 
>>>> <benjamin.vanryseghem.ph...@gmail.com> wrote:
>>>> Confirmed and fixed :P
>>>> https://pharo.fogbugz.com/default.asp?12153
>>>> 
>>>> 
>>>> Ben
>>>> 
>>>> On 12 Nov 2013, at 17:08, Martin Dias <tinchod...@gmail.com> wrote:
>>>> 
>>>>> (Checked in Pharo 30567)
>>>>> 
>>>>> On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchod...@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.ph...@gmail.com> wrote:
>>>>>>> It’s this one: https://pharo.fogbugz.com/default.asp?12135
>>>>>>> 
>>>>>>> Ben
>>>>>>> 
>>>>>>> On 12 Nov 2013, at 14:49, Martin Dias <tinchod...@gmail.com> wrote:
>>>>>>> 
>>>>>>> I forgot to specify: in latest Pharo (30565)
>>>>>>> 
>>>>>>> On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchod...@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.duca...@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.ph...@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 <esteba...@gmail.com> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> On Nov 12, 2013, at 4:22 AM, Benjamin 
>>>>>>> <benjamin.vanryseghem.ph...@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.duca...@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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
> 


Reply via email to