Hi,
I just wanted to let you know that I started to rework the PetitParser browser.
There are several things that have changed:
- it is modular, currently being formed of 3 distinct browsers. To give them a try (I also attached a couple of screenshots): PPAllParsersBrowser open. PPParserBrowser openOn: PPArithmeticParser. PPParserInspector openOn: PPArithmeticParser new.
- it only relies on the Glamour mechanisms without state in the implementation code. This was more of a validation that the engine is expressive enough
- it has a slightly different layout
- the Mondrian map can be used as a navigation, so clicking on a node will focus the browser on that production.
- it uses a tree widget for the debugger so we can scale for large debugging traces
What is still to do: - install the associated instance variable for each newly created production. - introduce parser renaming refactoring. This would entail triggering both a method and an instance var rename. - add the possibility to remove a production. This would entail removing a method and the corresponding instance var. - make the morph graph view interactive. - add a new grammar class. - integrate tests for each production. This would involve being able to browse tests associated to a production, run, add and remove them.
If these would work, we would have a true IDE and for most parts we would not need the Smalltalk editor for building parsers. But, I could use some help on the todos left, especially on the refactorings.
Cheers, Doru
-- www.tudorgirba.com
"Presenting is storytelling."
Looks cool.
- I would put the drop-down list with classes on top, seem to be strange to read from the bottom. - Editing a production does not seem to work. The method definition disappears and graph and example are broken. - I missed production protocols already in the old browser. - The start production is somehow missing in the list. - Also useful would be a static tree with the references in the leaves - Inspecting a parse result inspects a GLMMultiValue. - There should be a button to expand the debug trace, at least to a given level.
Below my suggestion for the remove-production refactoring:
remove: aSymbol in: aClass | references | references := aClass new productionNames values intersection: (aClass whichSelectorsReallyRead: aSymbol). references notEmpty ifTrue: [ (self confirm: 'The following production(s) refer to ' , aSymbol printString , ':' , String cr , ((references collect: [ :each | each printString ]) fold: [ :a :b | a , ', ' , b ]) , '. Really delete?') ifFalse: [ ^ self ] ]. (aClass instVarNames includes: aSymbol) ifTrue: [ aClass removeInstVarNamed: aSymbol ]. (aClass selectors includes: aSymbol) ifTrue: [ aClass removeSelector: aSymbol ]
Lukas
On 6 December 2011 22:53, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I just wanted to let you know that I started to rework the PetitParser browser.
There are several things that have changed:
- it is modular, currently being formed of 3 distinct browsers. To give
them a try (I also attached a couple of screenshots): PPAllParsersBrowser open. PPParserBrowser openOn: PPArithmeticParser. PPParserInspector openOn: PPArithmeticParser new.
- it only relies on the Glamour mechanisms without state in the
implementation code. This was more of a validation that the engine is expressive enough
it has a slightly different layout
the Mondrian map can be used as a navigation, so clicking on a node will
focus the browser on that production.
- it uses a tree widget for the debugger so we can scale for large
debugging traces
What is still to do:
- install the associated instance variable for each newly created
production.
- introduce parser renaming refactoring. This would entail triggering both
a method and an instance var rename.
- add the possibility to remove a production. This would entail removing a
method and the corresponding instance var.
- make the morph graph view interactive.
- add a new grammar class.
- integrate tests for each production. This would involve being able to
browse tests associated to a production, run, add and remove them.
If these would work, we would have a true IDE and for most parts we would not need the Smalltalk editor for building parsers. But, I could use some help on the todos left, especially on the refactorings.
Cheers, Doru
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
Thanks for looking into this.
On Tue, Dec 6, 2011 at 11:34 PM, Lukas Renggli renggli@gmail.com wrote:
Looks cool.
- I would put the drop-down list with classes on top, seem to be strange
to read from the bottom.
- Editing a production does not seem to work. The method definition
disappears and graph and example are broken.
Indeed, this is not yet properly working.
- I missed production protocols already in the old browser.
For now, I would like to keep it simple from the modeling of the interaction point of view. Once the current shape is working I would look into categories.
- The start production is somehow missing in the list.
Indeed, this was missing in the original browser as well :)
- Also useful would be a static tree with the references in the leaves
I do not understand this one. Could you explain a bit more?
- Inspecting a parse result inspects a GLMMultiValue.
Bug :).
- There should be a button to expand the debug trace, at least to a given
level.
Below my suggestion for the remove-production refactoring:
Cool. I will give it a try soon.
Cheers, Doru
remove: aSymbol in: aClass | references | references := aClass new productionNames values intersection: (aClass whichSelectorsReallyRead: aSymbol). references notEmpty ifTrue: [ (self confirm: 'The following production(s) refer to ' , aSymbol printString , ':' , String cr , ((references collect: [ :each | each printString ]) fold: [ :a :b | a , ', ' , b ]) , '. Really delete?') ifFalse: [ ^ self ] ]. (aClass instVarNames includes: aSymbol) ifTrue: [ aClass removeInstVarNamed: aSymbol ]. (aClass selectors includes: aSymbol) ifTrue: [ aClass removeSelector: aSymbol ]
Lukas
On 6 December 2011 22:53, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I just wanted to let you know that I started to rework the PetitParser browser.
There are several things that have changed:
- it is modular, currently being formed of 3 distinct browsers. To give
them a try (I also attached a couple of screenshots): PPAllParsersBrowser open. PPParserBrowser openOn: PPArithmeticParser. PPParserInspector openOn: PPArithmeticParser new.
- it only relies on the Glamour mechanisms without state in the
implementation code. This was more of a validation that the engine is expressive enough
it has a slightly different layout
the Mondrian map can be used as a navigation, so clicking on a node
will focus the browser on that production.
- it uses a tree widget for the debugger so we can scale for large
debugging traces
What is still to do:
- install the associated instance variable for each newly created
production.
- introduce parser renaming refactoring. This would entail triggering
both a method and an instance var rename.
- add the possibility to remove a production. This would entail removing
a method and the corresponding instance var.
- make the morph graph view interactive.
- add a new grammar class.
- integrate tests for each production. This would involve being able to
browse tests associated to a production, run, add and remove them.
If these would work, we would have a true IDE and for most parts we would not need the Smalltalk editor for building parsers. But, I could use some help on the todos left, especially on the refactorings.
Cheers, Doru
-- www.tudorgirba.com
"Presenting is storytelling."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
- I missed production protocols already in the old browser.
For now, I would like to keep it simple from the modeling of the interaction point of view. Once the current shape is working I would look into categories.
Fair enough, I think it is an important feature though.
- The start production is somehow missing in the list.
Indeed, this was missing in the original browser as well :)
In the original browser you got the start production if you just selected the class.
- Also useful would be a static tree with the references in the leaves
I do not understand this one. Could you explain a bit more?
Just that you nest referred productions below the parent production. Gives kind of a static navigable view of the grammar. Maybe there are better ways to get the same, like being able to click on a production in the source pane.
- There should be a button to expand the debug trace, at least to a given
level.
Below my suggestion for the remove-production refactoring:
Cool. I will give it a try soon.
If you want I can provide some "real refactorings" using the refactoring engine. Then we will also be able to undo/redo each action.
Lukas
Hi,
On Wed, Dec 7, 2011 at 5:47 PM, Lukas Renggli renggli@gmail.com wrote:
- I missed production protocols already in the old browser.
For now, I would like to keep it simple from the modeling of the interaction point of view. Once the current shape is working I would look into categories.
Fair enough, I think it is an important feature though.
- The start production is somehow missing in the list.
Indeed, this was missing in the original browser as well :)
In the original browser you got the start production if you just selected the class.
Right. I will think of another solution.
- Also useful would be a static tree with the references in the leaves
I do not understand this one. Could you explain a bit more?
Just that you nest referred productions below the parent production. Gives kind of a static navigable view of the grammar. Maybe there are better ways to get the same, like being able to click on a production in the source pane.
Right. This will be possible in some way. One possibility would be to get the morphic chart to be interactive.
- There should be a button to expand the debug trace, at least to a given
level.
Below my suggestion for the remove-production refactoring:
Cool. I will give it a try soon.
If you want I can provide some "real refactorings" using the refactoring engine. Then we will also be able to undo/redo each action.
Definitely! (in fact, this was my secret wish :))
Cheers, Doru
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
Just to keep you up to date, Lukas provided the much needed refactorings, and now they are integrated in the new PetitParser browser. The following actions work pretty much neatly: - add new production - remove production - rename production
The next steps will be towards the management of parser classes and hopefully, their associated tests.
It would be great to get feedback :)
Cheers, Doru
On 7 Dec 2011, at 17:58, Tudor Girba wrote:
Hi,
On Wed, Dec 7, 2011 at 5:47 PM, Lukas Renggli renggli@gmail.com wrote:
- I missed production protocols already in the old browser.
For now, I would like to keep it simple from the modeling of the interaction point of view. Once the current shape is working I would look into categories.
Fair enough, I think it is an important feature though.
- The start production is somehow missing in the list.
Indeed, this was missing in the original browser as well :)
In the original browser you got the start production if you just selected the class.
Right. I will think of another solution.
- Also useful would be a static tree with the references in the leaves
I do not understand this one. Could you explain a bit more?
Just that you nest referred productions below the parent production. Gives kind of a static navigable view of the grammar. Maybe there are better ways to get the same, like being able to click on a production in the source pane.
Right. This will be possible in some way. One possibility would be to get the morphic chart to be interactive.
- There should be a button to expand the debug trace, at least to a given
level.
Below my suggestion for the remove-production refactoring:
Cool. I will give it a try soon.
If you want I can provide some "real refactorings" using the refactoring engine. Then we will also be able to undo/redo each action.
Definitely! (in fact, this was my secret wish :))
Cheers, Doru
Lukas
-- Lukas Renggli www.lukas-renggli.ch
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com
"Some battles are better lost than fought."
-
Lukas Renggli -
Tudor Girba