Persistency of Changes (or: please allow us to commit)

May 17, 2009 at 6:56 PM


My way to Irony is quite stony:

i found Irony through Ben Morrison's CodeProject essay, downloaded it, tried some things that didn't work (my current goal is a MIPS Simulator in C#).

Then I found Your CodeProject essay, downloaded those sources, tried again - new errors.

finally, I followed the small link to this CodePlex Project, updated my sources, and found new errors.

The Core of the question is: what happens to my changes when you release your next results.

Example: Running the GrammarExplorer in the current release failed due to the known missing-Grammar-Settings bug, so i deleted the ComboBox'Items, and it worked.

When I then opened the Samples dll, some of the Items were checked, but most weren't. Seemed strange. a little debugging leaded me to the source: When adding the grammars from the assembly, you always select the last Item in the ListBox of the dialog. But the listbox is ordered alphabetically, so as soon as a language starting with, say, a Z is added, all the other (dictionary-orderedly smaller)languages aren't selected.

Again, if I fix that (rather unimportant, I know, but it`s an example) bug, how can I be sure, that it helps the project.

Another aspect: while studying your sources, and understanding more and more of the context, I could add /// <summary> comments to the classes, so that the gap between non-documented and perfectly-documented shrinks. But if there is no possibility to commit, what would it use? (I guess, that is not a sentence you can say in english... sounds not well.)

It would be great if I could help (and surely, others would like to, too), because the project seems really great.

Please let us.

with kind regards,


May 18, 2009 at 7:08 AM

I do agree that Irony's roadmap is quite "stony", and landscape is quite fragmented - published articles and code don't work with latest version. Irony continues to evolve, that's why it is still in alpha (not feature-complete); sorry, it's just nature of development.

I hope as soon as I bring the current source up-to-date - restore all functionality that was working in alpha-zip in Downloads page - it will be moved to beta stage, meaning public interfaces would freeze. As soon as it happens, I will go through some published code and fix it to work with beta version, and re-publish it (either here or in original publications). That would also be the time to start xml-comments, with intent to produce help file and some guide/documentation. I would welcome help with this.

As for bugs and how to you can help to fix them - there's already a way to do so. Just open an item on "Issue tracker" page, explain the bug, attach a patch file, and I will put the fix into the next code drop. I'm doing this already on routine basis, guys like you submit fixes and I put them in place. The problem with directly allowing many people to do bug fixes is again the same - the code evolves, and sometimes troubles go away as part of bigger refactorings, sometimes the code gets moved and it's not there anymore. So it's better if I apply the patch.

If you want to contribute on a bigger scale, not just bug fixes - let's discuss it..

Thank you