Spec new release :)
Hello everyone, I am glad to announce a step has been made in Spec with the introduction of five new models: TreeNodeModel, TreeColumnModel, MenuModel, MenuGroupModel and MenuItemModel. I. Trees The two first models (TreeNodeModel, TreeColumnModel) are used to build and specify trees (in addition with TreeModel). a) TreeNodeModel TreeNode represent a node of the tree, and hold some basic information like what the children of the node are, or which icon to use. Previously, one could use directly subclasses of MorphTreeNodeModel directly. This has been removed to loose the bonds between Spec and Morphic. If you used direct Morphic nodes in your tree, you will need to replace them by TreeNodeModel instances. You could also have used TreeModel methods used to generically describe your nodes. In this case, the only change you will need is how you access the content of a node. The MorphTreeNodeModel method used for this is #item while in TreeNodeModel it is #content. TreeNodeModel also support filtering out of the box with an extensible mechanism. b) TreeColumnModel TreeColumnModel is used to specify the columns used to render the tree nodes. Where one used to use TreeColumnMorph, now TreeColumnModel have to be use. The mainly behave the same, only the API differs to provide a less morphic oriented set of methods. TreeColumnModel also resolve some some updating issue encountered in TreeColumnMorph. II. Menus The three remaining models are used to build menus for the spec models. The way to build menus has been rethink to provide a more natural way to think menus. a) MenuModel A MenuModel is a quite a simple object with only an optional name, an optional icon and a list of menu groups. A MenuModel can also be turned into an auto-refreshing menu. The main method of MenuModel is #addGroup: which takes a block as argument and build a group before adding it to the menu model groups list. 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 ] ] ]. b) MenuGroupModel A MenuGroupModel represent a set of menu items which belong to a same logical set by providing related actions. A menu group only hold a list of menu items. The main method of MenuGroupModel is #addItem: , as you have seen in the previous example. Example: aGroup addItem: [ :anItem | anItem name: 'Browse Hierarchy'; action: [ self browseSelectedObjectClassHierarchy ]; shortcut: $h command mac | $h alt win | $h alt unix ] c) MenuItemModel A menu item is the core of a menu. It is the object that can actually perform an action. A MenuItemModel holds multiple information related to this action like the name of the menu entry, the optional icon you want to use, if the action is doable in the current context, and the optional shortcut triggering the action. An interesting feature is that by applying a menu to a spec model, the shortcuts of its items will be used to automatically bind the corresponding key combination to the menu item action (taking in account the context to prevent to fire action when it does not make sense). So far, this feature has been introduced only in NewListModel to fix the possible issues before a global deployment. Thanks for reading this long email, thanks for your support and your feedback, and see you soon :) Ben
Benjamin wrote:
Hello everyone,
I am glad to announce a step has been made in Spec with the introduction of five new models: TreeNodeModel, TreeColumnModel, MenuModel, MenuGroupModel and MenuItemModel.
I. Trees
The two first models (TreeNodeModel, TreeColumnModel) are used to build and specify trees (in addition with TreeModel).
a) TreeNodeModel
TreeNode represent a node of the tree, and hold some basic information like what the children of the node are, or which icon to use.
Previously, one could use directly subclasses of MorphTreeNodeModel directly. This has been removed to loose the bonds between Spec and Morphic.
If you used direct Morphic nodes in your tree, you will need to replace them by TreeNodeModel instances.
You could also have used TreeModel methods used to generically describe your nodes. In this case, the only change you will need is how you access the content of a node. The MorphTreeNodeModel method used for this is #item while in TreeNodeModel it is #content.
TreeNodeModel also support filtering out of the box with an extensible mechanism.
b) TreeColumnModel
TreeColumnModel is used to specify the columns used to render the tree nodes. Where one used to use TreeColumnMorph, now TreeColumnModel have to be use.
The mainly behave the same, only the API differs to provide a less morphic oriented set of methods. TreeColumnModel also resolve some some updating issue encountered in TreeColumnMorph.
II. Menus
The three remaining models are used to build menus for the spec models. The way to build menus has been rethink to provide a more natural way to think menus.
a) MenuModel
A MenuModel is a quite a simple object with only an optional name, an optional icon and a list of menu groups. A MenuModel can also be turned into an auto-refreshing menu.
The main method of MenuModel is #addGroup: which takes a block as argument and build a group before adding it to the menu model groups list.
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 ] ] ].
b) MenuGroupModel
A MenuGroupModel represent a set of menu items which belong to a same logical set by providing related actions. A menu group only hold a list of menu items.
The main method of MenuGroupModel is #addItem: , as you have seen in the previous example. Example: aGroup addItem: [ :anItem | anItem name: 'Browse Hierarchy'; action: [ self browseSelectedObjectClassHierarchy ]; shortcut: $h command mac | $h alt win | $h alt unix ]
c) MenuItemModel
A menu item is the core of a menu. It is the object that can actually perform an action. A MenuItemModel holds multiple information related to this action like the name of the menu entry, the optional icon you want to use, if the action is doable in the current context, and the optional shortcut triggering the action.
An interesting feature is that by applying a menu to a spec model, the shortcuts of its items will be used to automatically bind the corresponding key combination to the menu item action (taking in account the context to prevent to fire action when it does not make sense).
So far, this feature has been introduced only in NewListModel to fix the possible issues before a global deployment.
Thanks for reading this long email, thanks for your support and your feedback, and see you soon :)
Ben
Thanks for your efforts. I'll try them out soon. regards -ben
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? Stef
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@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?
Stef
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
I forgot to specify: in latest Pharo (30565) On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
Itâs this one: https://pharo.fogbugz.com/default.asp?12135 Ben On 12 Nov 2013, at 14:49, Martin Dias <tinchodias@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
(Checked in Pharo 30567) On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias@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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
Confirmed and fixed :P https://pharo.fogbugz.com/default.asp?12153 Ben On 12 Nov 2013, at 17:08, Martin Dias <tinchodias@gmail.com> wrote:
(Checked in Pharo 30567)
On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias@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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
Is there any new documentation planned ? On Tue, Nov 12, 2013 at 11:42 PM, Benjamin < Benjamin.VanRyseghem.Pharo@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@gmail.com> wrote:
(Checked in Pharo 30567)
On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias@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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin < benjamin.vanryseghem.pharo@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@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
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@gmail.com> wrote:
Is there any new documentation planned ?
On Tue, Nov 12, 2013 at 11:42 PM, Benjamin <Benjamin.VanRyseghem.Pharo@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@gmail.com> wrote:
(Checked in Pharo 30567)
On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias@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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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.Pharo@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.alios@gmail.com> wrote:
Is there any new documentation planned ?
On Tue, Nov 12, 2013 at 11:42 PM, Benjamin <Benjamin.VanRyseghem.Pharo@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@gmail.com> wrote:
(Checked in Pharo 30567)
On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias@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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
Hi, I have some questions: 1/ Before the removal of morphic dependencies in spec, I used aNode selectedNode parentNode item to get the parent of the selected item. What is the new way to do that? 2/ I also defined specific nodes for a Tree model. These nodes overrode the childrenItems method to provide children elements. It looks like this method is not used anymore in TreeNodeModel. What should I now use to provide children elements in a TreeNodeModel? Thanks, Christophe.
Ben On 13 Nov 2013, at 12:43, Christophe Demarey <Christophe.Demarey@inria.fr> wrote:
Hi,
I have some questions:
1/ Before the removal of morphic dependencies in spec, I used aNode selectedNode parentNode item to get the parent of the selected item. What is the new way to do that?
I think I forgot about this one :) The fix is easy though. Can you open an issue, I will have a look this evening :)
2/ I also defined specific nodes for a Tree model. These nodes overrode the childrenItems method to provide children elements. It looks like this method is not used anymore in TreeNodeModel. What should I now use to provide children elements in a TreeNodeModel?
You used to have Morphic node specific classes. Now there is only TreeNodeModel. So instead of creating a subclass, you will have to specify the TreeNodeModels you want (and specifying children is #children:) It is also possible that I forgot some scenarios, in this case, you can send another email, or wait tip next week so we can sit together :) Ben
Thanks, Christophe.
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ... No seriously? If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it. I will not write any book in markdown. Now you can try and we see. Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
It was a real question, and it feels like you overreacted the answer ⦠To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument. Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown. This was a real question, not a troll ... Ben On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling. But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books. There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html? Maybe my question is naive, I do not know. On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files. Alexandre On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 13 Nov 2013, at 20:22, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html? Maybe my question is naive, I do not know.
It is not silly, and yes it could be done quite easily I guess, if it even has not yet been done already.
On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files.
Alexandre
On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I ask Damien Cassou this morning about that. He told me it should be quite easy to do :) (just another visitor I guess) Ben On 13 Nov 2013, at 20:28, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 20:22, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html? Maybe my question is naive, I do not know.
It is not silly, and yes it could be done quite easily I guess, if it even has not yet been done already.
On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files.
Alexandre
On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html? Maybe my question is naive, I do not know.
this is planned. Now I can count the people writing books on my right hand.
On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files.
I would prefer to work in tex because I go much much faster. but I do not have a .tex parser to get a document tree. Stef
Alexandre
On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html?
I did => suicidal tendencies. The results looks like shit. I did not try pdf2html. Now pier is a compromise so that normal people can write chapter without being a latex freaks like us. Stef
Maybe my question is naive, I do not know.
On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files.
Alexandre
On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Stephane I think you need to sit down and write the Guidelines for Pharo Documentation, explaining the tools, the workflow, the goals, the principles and most importantly where documentation can be found. Post it on pharo website. This way you will save a lot of time from answering questions here . So next time someone asks a relevant question you only post a link to it. On Wed, Nov 13, 2013 at 9:44 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html?
I did => suicidal tendencies. The results looks like shit.
I did not try pdf2html.
Now pier is a compromise so that normal people can write chapter without being a latex freaks like us.
Stef
Maybe my question is naive, I do not know.
On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files.
Alexandre
On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <
Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really
an argument.
Then I am open to a real answer but I also see that markdown is
integrated to a lot of tools (github and jekylls by examples)
and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I will write and send a proposal to the list. Good idea. Stef
Stephane I think you need to sit down and write the Guidelines for Pharo Documentation, explaining the tools, the workflow, the goals, the principles and most importantly where documentation can be found. Post it on pharo website. This way you will save a lot of time from answering questions here . So next time someone asks a relevant question you only post a link to it.
On 2013-11-13, at 22:26, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I will write and send a proposal to the list. Good idea.
... and put it in the documentation repository, I thought of gathering the documentation there, centralized, transparent open for contributions from everybody.
That would be appreciated :) Ben On 13 Nov 2013, at 21:18, kilon alios <kilon.alios@gmail.com> wrote:
Stephane I think you need to sit down and write the Guidelines for Pharo Documentation, explaining the tools, the workflow, the goals, the principles and most importantly where documentation can be found. Post it on pharo website. This way you will save a lot of time from answering questions here . So next time someone asks a relevant question you only post a link to it.
On Wed, Nov 13, 2013 at 9:44 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html?
I did => suicidal tendencies. The results looks like shit.
I did not try pdf2html.
Now pier is a compromise so that normal people can write chapter without being a latex freaks like us.
Stef
Maybe my question is naive, I do not know.
On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files.
Alexandre
On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 13 Nov 2013, at 20:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Nov 13, 2013, at 8:22 PM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html?
I did => suicidal tendencies. The results looks like shit.
I did not try pdf2html.
Now pier is a compromise so that normal people can write chapter without being a latex freaks like us.
Stef
Thatâs also the thing, md is designed in a (shitty) way so one does not have to âlearnâ it since itâs is âcloseâ to what one will write in an email Ben
Maybe my question is naive, I do not know.
On some point, i have tried to generate the roassal documentation from the Roassal Help, but it makes the maintenance loop heavy: If I want to fix something in the text, I had to edit the Help in Pharo, generating the document, compiling into .pdf. Quite heavy it was. At the end, I only worked on the .tex files.
Alexandre
On Nov 13, 2013, at 4:05 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Why not generating markdown code from pier code? If the whole problem is exposure on the web. Someone has considered pdf2html or latex2html?
I did => suicidal tendencies. The results looks like shit.
I did not try pdf2html.
Now pier is a compromise so that normal people can write chapter without being a latex freaks like us.
Stef
Thatâs also the thing, md is designed in a (shitty) way so one does not have to âlearnâ it since itâs is âcloseâ to what one will write in an email
did you check pier syntax? how far it is from markdown? why is it a wiki syntax? remember wiki means fast do you think that I did not think about it? Ignacio already wrote 5 pages of calculator spec and I do not think that it took him more that 10 min to get the syntax. Some details should be remembered but the main is dead simple.
On 13 Nov 2013, at 20:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ok :) But as an end user, do you feel the difference ? There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) then one could generate Pier format out of markdown :) Ben
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
On 13 Nov 2013, at 20:22, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 13 Nov 2013, at 20:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ok :) But as an end user, do you feel the difference ?
I know, but the documentation is meant to be integrated in the Pharo ecosystem. It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) then one could generate Pier format out of markdown :)
So indeed, that is what we need. [And what we already have for Pier]. But be sure to ask Camillo how his 2 attempts went before you get ambitious. I look at the PP MD code and thought, I can do better, but after writing some actual code, I stopped ;-) BTW, please point me to grammar, I never found one ! Each MD parser is one big hack.
Ben
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image. Now one step at a time.
There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) then one could generate Pier format out of markdown :)
What most of you do not get is that. But I do not care about Pier format. I care about a REAL solution that can produce a REAL document tree AND that ***I*** can edit and maintain and enhance so that I can create books. So I'm pragmatic we wrote the seaside book with pier so I took pier because I do not want to write a MD parser and building model and reinventing the wheel. And I do not want to have to learn a new language just to make sure that I can write books. Stef
On 2013-11-13, at 21:19, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image.
What has this to do with athens? We already have a prototype implementation with Markdown using the existing text model. Worked already fine, so that should be 1 afternoon of work to get the pier syntax running in the current image.
On 2013-11-13, at 23:29, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
We already have a prototype implementation with Markdown using the existing text model.Worked already fine,
Where can I find it? I'm quite interested.
The code is under http://smalltalkhub.com/mc/Pharo/NativeBoost/main/ NativeBoost-Help-IgorStasenko.6 should do under 2.0. Though there seems to be a problem since the original PetitParser repository is down, hence, petit-markdown does not load anymore under 2.0. The newer version of petit markdown which works under 3.0 uses slightly different nodes, resulting in a broken NativeBoost-Help. I short you can look at the code but not at the result :/
ok I will On Nov 14, 2013, at 12:13 PM, Camillo Bruni <camillobruni@gmail.com> wrote:
The code is underhttp://smalltalkhub.com/mc/Pharo/NativeBoost/main/ NativeBoost-Help-IgorStasenko.6 should do under 2.0.
Though there seems to be a problem since the original PetitParser repository is down, hence, petit-markdown does not load anymore under 2.0. The newer version of petit markdown which works under 3.0 uses slightly different nodes, resulting in a broken NativeBoost-Help.
I short you can look at the code but not at the result :/
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image.
What has this to do with athens?
I want really nice font so this is not really related to athens and was confused.
We already have a prototype implementation with Markdown using the existing text model. Worked already fine, so that should be 1 afternoon of work to get the pier syntax running in the current image.
Where it is? that we add it to our todo? because having a real domain model (which we have) is the way to go. I do not want to hack stuff. Now we ***HAVE*** a fully working pier parser and creating domain and we ARE enhancing it already. Stef
On 2013-11-14, at 00:58, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image.
What has this to do with athens?
I want really nice font so this is not really related to athens and was confused.
We already have a prototype implementation with Markdown using the existing text model. Worked already fine, so that should be 1 afternoon of work to get the pier syntax running in the current image.
Where it is? that we add it to our todo? because having a real domain model (which we have) is the way to go. I do not want to hack stuff. Now we ***HAVE*** a fully working pier parser and creating domain and we ARE enhancing it already.
Igor did it 2 years ago.
Camillo I would love that you spend all your energy in doing something elseâ¦than arguing for arguing So I created a filter that will kill any mail containing markdown. Because I'm doing pharo for positive energy not endless arguing. Stef
I want really nice font so this is not really related to athens and was confused.
We already have a prototype implementation with Markdown using the existing text model. Worked already fine, so that should be 1 afternoon of work to get the pier syntax running in the current image.
Where it is? that we add it to our todo? because having a real domain model (which we have) is the way to go. I do not want to hack stuff. Now we ***HAVE*** a fully working pier parser and creating domain and we ARE enhancing it already.
Igor did it 2 years ago.
On 13 Nov 2013, at 21:19, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image. Now one step at a time.
There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) then one could generate Pier format out of markdown :)
What most of you do not get is that. But I do not care about Pier format. I care about a REAL solution that can produce a REAL document tree AND that ***I*** can edit and maintain and enhance so that I can create books.
So why not extending markdown then ? Ben
So I'm pragmatic we wrote the seaside book with pier so I took pier because I do not want to write a MD parser and building model and reinventing the wheel. And I do not want to have to learn a new language just to make sure that I can write books.
Stef
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
With Athens inside the image we will use the pier parser to generate a document tree and render it inside the image. Now one step at a time.
There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) then one could generate Pier format out of markdown :)
What most of you do not get is that. But I do not care about Pier format. I care about a REAL solution that can produce a REAL document tree AND that ***I*** can edit and maintain and enhance so that I can create books.
So why not extending markdown then ?
repeat after me: - we have a working parser + model that works and we produce books with it since YEARS! - do you want to hack in haskell or whatever language - not me :) - what is the value of an extended markdown if it is not supported by git tools = the same as pier syntax - we have a cool emacs mode for pier with big fonts for sections and all the rest. - we have a pier cms with pier syntax, so if we want we can even write directly on the web. Lukas and me wrote the seaside book like that after latex and XML. - we have a latex exporter for pier domain - we have a html exporter for pier domain - we have nice visitors so why should I hack a non standard under specified language without a decent debugger in a language that I do not want to learn? I prefer to concentrate on writing books and coding more important things. Now if you want you can try your own way and create a pier exporter so that your documentation find its way in our books. But I will not do it. Stef
Have a look at http://jgm.github.io/lunamark/ :) It may be a dirty hack, that I do not know :) Ben On 13 Nov 2013, at 20:27, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 20:22, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 13 Nov 2013, at 20:05, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 13 Nov 2013, at 19:59, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll â¦
I like .md as well and yes, the github integration makes it compelling.
But one objective argument against Markdown and in favour of Pier is that the former has no good parser and/or document model and and the latter does have both, in Pharo. That means that we can write all sorts of tools ourselves and get things finished, as was proven with the books.
There simply isnât any definitive, unambiguous Markdown syntax (the github variant is only one version).
Ok :) But as an end user, do you feel the difference ?
I know, but the documentation is meant to be integrated in the Pharo ecosystem.
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
There are some PEG grammar for markdown, maybe it could be reused so PP can parse it :) then one could generate Pier format out of markdown :)
So indeed, that is what we need. [And what we already have for Pier]. But be sure to ask Camillo how his 2 attempts went before you get ambitious. I look at the PP MD code and thought, I can do better, but after writing some actual code, I stopped ;-)
BTW, please point me to grammar, I never found one ! Each MD parser is one big hack.
Ben
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
Is it because this is not in Pharo that this is better? May be this is a new trend? Now if you have the time, you can write a pier exporter and everybody will be happy but I will not code in lua nor haskell nor ruby nor PHP. Personally I prefer to focus on the real parts: writing good books Stef
Have a look at http://jgm.github.io/lunamark/ :) It may be a dirty hack, that I do not know :)
Ben
On 14 Nov 2013, at 02:25, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Is it because this is not in Pharo that this is better? May be this is a new trend?
Itâs because Sven ask me to point him the PEG grammar I saw for markdown. And I think that Pier could benefit from a md parser
Now if you have the time, you can write a pier exporter and everybody will be happy but I will not code in lua nor haskell nor ruby nor PHP.
Personally I prefer to focus on the real parts: writing good books
Stef
Have a look at http://jgm.github.io/lunamark/ :) It may be a dirty hack, that I do not know :)
Ben
Is it because this is not in Pharo that this is better? May be this is a new trend?
Itâs because Sven ask me to point him the PEG grammar I saw for markdown. Ok
And I think that Pier could benefit from a md parser
may be to do what? so that people can edit file with pier using mardown? in addition to the pier syntax? May be but I do not have time for that. Now if somebody needs that the pier code is MIT.
Now if you have the time, you can write a pier exporter and everybody will be happy but I will not code in lua nor haskell nor ruby nor PHP.
Personally I prefer to focus on the real parts: writing good books
Stef
So one can import a md file and turn it into pier Ben On 14 Nov 2013, at 02:37, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Is it because this is not in Pharo that this is better? May be this is a new trend?
Itâs because Sven ask me to point him the PEG grammar I saw for markdown. Ok
And I think that Pier could benefit from a md parser
may be to do what? so that people can edit file with pier using mardown? in addition to the pier syntax? May be but I do not have time for that. Now if somebody needs that the pier code is MIT.
Now if you have the time, you can write a pier exporter and everybody will be happy but I will not code in lua nor haskell nor ruby nor PHP.
Personally I prefer to focus on the real parts: writing good books
Stef
Sven Van Caekenberghe writes:
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
We actually do that in the new IDE of Amber :) Then we have very nicely displayed class comments. Nico
Nico when I will read a book on Amber written using the default markdown language and that the book will be of decent quality, I will reconsider my position. Start writing (but extend markdown first because else you will get a kind of book with no cross ref no citation no index) so a "book" that I would not like to read and enjoy. Stef On Nov 14, 2013, at 1:09 AM, Nicolas Petton <petton.nicolas@gmail.com> wrote:
Sven Van Caekenberghe writes:
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
We actually do that in the new IDE of Amber :) Then we have very nicely displayed class comments.
Nico
I'm just talking about class comment, writing a book is a totally different story :) Nico Stéphane Ducasse writes:
Nico
when I will read a book on Amber written using the default markdown language and that the book will be of decent quality, I will reconsider my position. Start writing (but extend markdown first because else you will get a kind of book with no cross ref no citation no index) so a "book" that I would not like to read and enjoy.
Stef
On Nov 14, 2013, at 1:09 AM, Nicolas Petton <petton.nicolas@gmail.com> wrote:
Sven Van Caekenberghe writes:
It would be completely silly to have class comments in MD (no matter how cool this would be) _and_ *not* be able to have Nautilus parse/render them, with active links, etcâ¦
We actually do that in the new IDE of Amber :) Then we have very nicely displayed class comments.
Nico
-- Nicolas Petton http://nicolas-petton.fr
So read the thread that yuriy rasied last week my sumarry - write in pier publish in latex, html, markdong - too many variation of markdown - do not want to ask in haskell, ruby⦠to extend libraries - markdown does not support references and other essential points for making decent books Stef On Nov 13, 2013, at 7:59 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll ...
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
On 13 Nov 2013, at 20:40, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
So read the thread that yuriy rasied last week my sumarry - write in pier publish in latex, html, markdong
âmarkdongâ ? thatâs a chinese variant :P For md, there is pandoc (http://johnmacfarlane.net/pandoc/) it converts a lot of format into a lot of other formats :)
- too many variation of markdown - do not want to ask in haskell, ruby⦠to extend libraries
I do not get it
- markdown does not support references and other essential points for making decent books
What do you mean by "references and other essential pointsâ ? Ben
Stef
On Nov 13, 2013, at 7:59 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll ...
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
On Nov 14, 2013, at 1:03 AM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
On 13 Nov 2013, at 20:40, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
So read the thread that yuriy rasied last week my sumarry - write in pier publish in latex, html, markdong
âmarkdongâ ? thatâs a chinese variant :P
;P yes 400 Ã 195 - baudelet.net vietnamese apparently
For md, there is pandoc (http://johnmacfarlane.net/pandoc/) it converts a lot of format into a lot of other formats :)
Yes we know. But again as I said it one million times. Markdown does not offer what is needed to write books. I will not repeat here. And I will not hack pandoc to make it works.
- too many variation of markdown - do not want to ask in haskell, ruby⦠to extend libraries
I do not get it
- do not want to **hack** in haskell, ruby⦠to extend libraries
- markdown does not support references and other essential points for making decent books
What do you mean by "references and other essential pointsâ ?
I will not repeat it :) Read the thread of yuriy.
Ben
Stef
On Nov 13, 2013, at 7:59 PM, Benjamin <Benjamin.VanRyseghem.Pharo@gmail.com> wrote:
It was a real question, and it feels like you overreacted the answer â¦
To me, markdown or pier is a new syntax to learn so I am asking ⦠To me, doing Pier because you do or because you said to is no really an argument.
Then I am open to a real answer but I also see that markdown is integrated to a lot of tools (github and jekylls by examples) and that a lot of people knows about markdown.
This was a real question, not a troll ...
Ben
On 13 Nov 2013, at 19:22, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
do you really think that I insist of using pier syntax because A- I want to lose my time B- this is for my ego? C- because I'm funny D- ...
No seriously?
If you want to get an answer read the thread that yuri raised a while ago. Because we already discussed discussed and discussed it.
I will not write any book in markdown. Now you can try and we see.
Stef
Stef, what is the advantages of writing it in Pier compared to markdown ?
Ben
I added https://github.com/pharo-project/pharo-documentation On 2013-11-13, at 02:47, Stéphane Ducasse <stephane.ducasse@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.Pharo@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.alios@gmail.com> wrote:
Is there any new documentation planned ?
On Tue, Nov 12, 2013 at 11:42 PM, Benjamin <Benjamin.VanRyseghem.Pharo@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@gmail.com> wrote:
(Checked in Pharo 30567)
On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias@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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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.ducasse@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.Pharo@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.alios@gmail.com> wrote:
Is there any new documentation planned ?
On Tue, Nov 12, 2013 at 11:42 PM, Benjamin <Benjamin.VanRyseghem.Pharo@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@gmail.com> wrote:
(Checked in Pharo 30567)
On Tue, Nov 12, 2013 at 5:08 PM, Martin Dias <tinchodias@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@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@gmail.com> wrote:
I forgot to specify: in latest Pharo (30565)
On Tue, Nov 12, 2013 at 2:48 PM, Martin Dias <tinchodias@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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@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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
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@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@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@gmail.com> wrote:
On Nov 12, 2013, at 4:22 AM, Benjamin <benjamin.vanryseghem.pharo@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@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
I'm working on the changeSorter menus because they do not work anymore. And we will see what we can learn from there. Stef On Nov 12, 2013, at 1:49 AM, Stéphane Ducasse <stephane.ducasse@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?
Stef
participants (14)
-
Alexandre Bergel -
Benjamin -
Benjamin
-
btc＠openinworld.com -
Camillo Bruni -
Christophe Demarey -
Esteban Lorenzano -
Jan Vrany -
kilon alios -
Martin Dias -
Nicolas Petton -
Norbert Hartl -
Stéphane Ducasse -
Sven Van Caekenberghe