Hi all, I would like to ask your opinion on Epicea, a tool that logs code changes you do in your Pharo image. In a few words, its comparable to the traditional "change sorter + .changes file mechanism ": - it's serializable to/from a textual format file, that you can file in/file out. - the changes are logged to file immediately after they are announced by the system. - there is a UI where you can browse/manipulate the changes The main difference is that in .changes/.cs, the history is modelled as a sequence of chunks (DoIt's or just strings) that the tools *try* to parse in order to know what happened. In Epicea, the history elements are reified. For example, EpMethodModification models a method that was modified from an old state to a new state, so it answers to #oldMethod with a RGMethod holding the source code and the protocol as it was before the code change. I have been working on it during last time, it has been used by several users, and it's quite stable. The project is in a "work in progress" state, but I think it can be useful. To install it in latest Pharo4: Gofer new smalltalkhubUser: #MartinDias project: #Epicea; configuration; load. (#ConfigurationOfEpicea asClass project version: '4.7') load. To try it: 1. Word Menu -> Tools -> Epicea -> Ensure logging 2. Word Menu -> Tools -> Epicea -> Log 3. Open Nautilus and perform some changes 4. Check they are displayed in the log open in 2. 5. You can undo, redo, comment and file out log entries. Cheers, MartÃn
Is it possible log refactorings this way? -- Best regards, Dennis Schetinin 2014-12-17 22:50 GMT+04:00 Martin Dias <tinchodias@gmail.com>:
Hi all,
I would like to ask your opinion on Epicea, a tool that logs code changes you do in your Pharo image. In a few words, its comparable to the traditional "change sorter + .changes file mechanism ":
- it's serializable to/from a textual format file, that you can file in/file out. - the changes are logged to file immediately after they are announced by the system. - there is a UI where you can browse/manipulate the changes
The main difference is that in .changes/.cs, the history is modelled as a sequence of chunks (DoIt's or just strings) that the tools *try* to parse in order to know what happened. In Epicea, the history elements are reified. For example, EpMethodModification models a method that was modified from an old state to a new state, so it answers to #oldMethod with a RGMethod holding the source code and the protocol as it was before the code change.
I have been working on it during last time, it has been used by several users, and it's quite stable. The project is in a "work in progress" state, but I think it can be useful.
To install it in latest Pharo4:
Gofer new smalltalkhubUser: #MartinDias project: #Epicea; configuration; load. (#ConfigurationOfEpicea asClass project version: '4.7') load.
To try it:
1. Word Menu -> Tools -> Epicea -> Ensure logging 2. Word Menu -> Tools -> Epicea -> Log 3. Open Nautilus and perform some changes 4. Check they are displayed in the log open in 2. 5. You can undo, redo, comment and file out log entries.
Cheers, MartÃn
On Thu, Dec 18, 2014 at 11:23 AM, Dennis Schetinin <chaetal@gmail.com> wrote:
Is it possible log refactorings this way?
Yes, it is possible. But this feature of recording refactorings (and MC save/load, and test runs as well) belongs to an optional package, because it overrides methods in system and I decided to have a core package without that. MartÃn
--
Best regards,
Dennis Schetinin
2014-12-17 22:50 GMT+04:00 Martin Dias <tinchodias@gmail.com>:
Hi all,
I would like to ask your opinion on Epicea, a tool that logs code changes you do in your Pharo image. In a few words, its comparable to the traditional "change sorter + .changes file mechanism ":
- it's serializable to/from a textual format file, that you can file in/file out. - the changes are logged to file immediately after they are announced by the system. - there is a UI where you can browse/manipulate the changes
The main difference is that in .changes/.cs, the history is modelled as a sequence of chunks (DoIt's or just strings) that the tools *try* to parse in order to know what happened. In Epicea, the history elements are reified. For example, EpMethodModification models a method that was modified from an old state to a new state, so it answers to #oldMethod with a RGMethod holding the source code and the protocol as it was before the code change.
I have been working on it during last time, it has been used by several users, and it's quite stable. The project is in a "work in progress" state, but I think it can be useful.
To install it in latest Pharo4:
Gofer new smalltalkhubUser: #MartinDias project: #Epicea; configuration; load. (#ConfigurationOfEpicea asClass project version: '4.7') load.
To try it:
1. Word Menu -> Tools -> Epicea -> Ensure logging 2. Word Menu -> Tools -> Epicea -> Log 3. Open Nautilus and perform some changes 4. Check they are displayed in the log open in 2. 5. You can undo, redo, comment and file out log entries.
Cheers, MartÃn
In this screenshot you can see an Epicea Log Browser where the item in the bottom (EpOracleRunner: baseDirectory ---> analysisDataSet) represents an instance variable rename, and that triggered a modification in 5 methods of EpOracleRunner. On Thu, Dec 18, 2014 at 1:37 PM, Martin Dias <tinchodias@gmail.com> wrote:
On Thu, Dec 18, 2014 at 11:23 AM, Dennis Schetinin <chaetal@gmail.com> wrote:
Is it possible log refactorings this way?
Yes, it is possible. But this feature of recording refactorings (and MC save/load, and test runs as well) belongs to an optional package, because it overrides methods in system and I decided to have a core package without that.
MartÃn
--
Best regards,
Dennis Schetinin
2014-12-17 22:50 GMT+04:00 Martin Dias <tinchodias@gmail.com>:
Hi all,
I would like to ask your opinion on Epicea, a tool that logs code changes you do in your Pharo image. In a few words, its comparable to the traditional "change sorter + .changes file mechanism ":
- it's serializable to/from a textual format file, that you can file in/file out. - the changes are logged to file immediately after they are announced by the system. - there is a UI where you can browse/manipulate the changes
The main difference is that in .changes/.cs, the history is modelled as a sequence of chunks (DoIt's or just strings) that the tools *try* to parse in order to know what happened. In Epicea, the history elements are reified. For example, EpMethodModification models a method that was modified from an old state to a new state, so it answers to #oldMethod with a RGMethod holding the source code and the protocol as it was before the code change.
I have been working on it during last time, it has been used by several users, and it's quite stable. The project is in a "work in progress" state, but I think it can be useful.
To install it in latest Pharo4:
Gofer new smalltalkhubUser: #MartinDias project: #Epicea; configuration; load. (#ConfigurationOfEpicea asClass project version: '4.7') load.
To try it:
1. Word Menu -> Tools -> Epicea -> Ensure logging 2. Word Menu -> Tools -> Epicea -> Log 3. Open Nautilus and perform some changes 4. Check they are displayed in the log open in 2. 5. You can undo, redo, comment and file out log entries.
Cheers, MartÃn
Hi Martin, I think this is the great effort and it should be, at some point, integrated to Pharo â and replace the current *.changes format. Then I believe it is worth to think how to change Pharo core the way, Epicea can also log higher actions, e.g. class cloning, refactoring, renaming. Cheers, Juraj
On 17. Dec 2014, at 19:50, Martin Dias <tinchodias@gmail.com> wrote:
Hi all,
I would like to ask your opinion on Epicea, a tool that logs code changes you do in your Pharo image. In a few words, its comparable to the traditional "change sorter + .changes file mechanism ":
- it's serializable to/from a textual format file, that you can file in/file out. - the changes are logged to file immediately after they are announced by the system. - there is a UI where you can browse/manipulate the changes
The main difference is that in .changes/.cs, the history is modelled as a sequence of chunks (DoIt's or just strings) that the tools *try* to parse in order to know what happened. In Epicea, the history elements are reified. For example, EpMethodModification models a method that was modified from an old state to a new state, so it answers to #oldMethod with a RGMethod holding the source code and the protocol as it was before the code change.
I have been working on it during last time, it has been used by several users, and it's quite stable. The project is in a "work in progress" state, but I think it can be useful.
To install it in latest Pharo4:
Gofer new smalltalkhubUser: #MartinDias project: #Epicea; configuration; load. (#ConfigurationOfEpicea asClass project version: '4.7') load.
To try it:
1. Word Menu -> Tools -> Epicea -> Ensure logging 2. Word Menu -> Tools -> Epicea -> Log 3. Open Nautilus and perform some changes 4. Check they are displayed in the log open in 2. 5. You can undo, redo, comment and file out log entries.
Cheers, MartÃn
Yeah, that's I was asking about: it should be used (finally) for version control! -- Best regards, Dennis Schetinin 2014-12-18 14:42 GMT+04:00 Juraj Kubelka <juraj.kubelka@gmail.com>:
Hi Martin,
I think this is the great effort and it should be, at some point, integrated to Pharo â and replace the current *.changes format. Then I believe it is worth to think how to change Pharo core the way, Epicea can also log higher actions, e.g. class cloning, refactoring, renaming.
Cheers, Juraj
On 17. Dec 2014, at 19:50, Martin Dias <tinchodias@gmail.com> wrote:
Hi all,
I would like to ask your opinion on Epicea, a tool that logs code changes you do in your Pharo image. In a few words, its comparable to the traditional "change sorter + .changes file mechanism ":
- it's serializable to/from a textual format file, that you can file in/file out. - the changes are logged to file immediately after they are announced by the system. - there is a UI where you can browse/manipulate the changes
The main difference is that in .changes/.cs, the history is modelled as a sequence of chunks (DoIt's or just strings) that the tools *try* to parse in order to know what happened. In Epicea, the history elements are reified. For example, EpMethodModification models a method that was modified from an old state to a new state, so it answers to #oldMethod with a RGMethod holding the source code and the protocol as it was before the code change.
I have been working on it during last time, it has been used by several users, and it's quite stable. The project is in a "work in progress" state, but I think it can be useful.
To install it in latest Pharo4:
Gofer new smalltalkhubUser: #MartinDias project: #Epicea; configuration; load. (#ConfigurationOfEpicea asClass project version: '4.7') load.
To try it:
1. Word Menu -> Tools -> Epicea -> Ensure logging 2. Word Menu -> Tools -> Epicea -> Log 3. Open Nautilus and perform some changes 4. Check they are displayed in the log open in 2. 5. You can undo, redo, comment and file out log entries.
Cheers, MartÃn
participants (3)
-
Dennis Schetinin -
Juraj Kubelka -
Martin Dias