[Pharo-dev] Epicea?

[Alexandre Bergel]

Hi!

When I close and open an image, there is an Epicea window, with apparently some 
of my previous change. 
I am not sure what to do with it beside closing it. What is it supposed to show 
me? A small help would great.

Cheers,
Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

[Pharo-dev] Epicea

[Martin Dias]

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

[Pharo-dev] Epicea feedback

[Jan Blizničenko]

Hello

I'd like to thank you for creating the Epicea. It is way more user-friendly
and dependable than previous change-handling tool. Browsing, applying and
reverting changes is way easier.

Just one note: 
It is not exactly clear from first look how to properly reapply changes
after an image has been closed without saving. If I select all changes I
want to apply without using any filter, those changes are reapplied in wrong
order (if I changed a method two times, first the new version is applied and
then the old one). As far as I understood, I have to use filter to show only
latest changes, but I think it could be clearer in the UI that I need to do
so (or something completely different?) for applying changes.

Thank you
Jan



--
View this message in context: 
http://forum.world.st/Epicea-feedback-tp4952661.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

[Pharo-dev] Epicea wishlist

[Stephane Ducasse]

Hi martin

I'm missing two features:

- keep the filter across session because this is boring to have to
redo them all over.
- a search for entities accross session.
- a search inside a session
For example I was looking for all the changes I did to the UI part of
my application but I was doing many development
loading different unrelated package and saving after.

Right now you can restrict to view changes but only if you have a
first entity of the package for example so you have to look first is
there an entity of this package.

Stef

[Pharo-dev] Epicea Feedback

[Sean P. DeNigris]

Not complaining at all and appreciate everyone's hard (mostly-unpaid) work,
but providing raw feedback in case it's helpful...

- Browser awkward: filters disappear whenever left selection changed; no
multi-select of sessions, which led to a host of difficulties described
below.
- What is the heuristic to find API access points? Epicea package has no
comment, 'Browser' tag doesn't seem to have an XyzBrowser class, no
particular class in the 'Model' tag jumps out at me as an access point; as
above Browser about text not set. I finally bring up Morphic halos on the
browser and after flopping around, find subclasses of EpLogNode; I browse it
and find EpLogNodeGraphModel, which sounds interesting and turns out to be a
spec. I figure out how to list the log files, but not how to get the entries
- I was expecting a term like that and the relevant method (#log it turns
out) has no comment to indicate it's what I'm looking for. Now that I'm
starting to understand the project organization, back to the browser to
explore EpUnifiedBrowserModel. After a bit of poking around, I suspect
(correctly) that #log is what I'm after.

Based on code I extract from the browsers and a bit of experimenting in GT,
I come up with the following seemingly very complex script:

nodes := EpFileLogNode fromAllLogsIn: EpMonitor current sessionStore
baseLocator.
nodes do: [ :node | node populateReferencedNodesWith: nodes ].
nodes flatCollect: [ :n | n log events select: [ :e | e affectedPackageName
beginsWith: 'Magritte' ] ]

I now run into a series of problems because, although EpCodeChange declares
#affectedPackageName as an abstract method, not all events are
EpCodeChanges. I exclude EpUndos. Easy enough. Now I come to an
EpGenericRefactoring. This one is harder because 

p.s. Code names for internal projects seem extremely
counterproductive. Hiedra tells me absolutely nothing about functionality.
It might as well be called XyzWidgetThing



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Epicea?

[Nicolas Passerini]

There has been already a discussion about the same topic a few days ago and
I think that there is a consensus on considering it a bug that has to be
solved (look for «confused about the "image opening session"»). Yet I think
there is not even a bug in the issue tracker.

On Fri, Jul 15, 2016 at 1:33 PM, Alexandre Bergel 
wrote:

> Hi!
>
> When I close and open an image, there is an Epicea window, with apparently
> some of my previous change.
> I am not sure what to do with it beside closing it. What is it supposed to
> show me? A small help would great.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] Epicea?

[Cyril Ferlicot Delbecque]

On 15/07/2016 16:01, Nicolas Passerini wrote:
> There has been already a discussion about the same topic a few days ago
> and I think that there is a consensus on considering it a bug that has
> to be solved (look for «confused about the "image opening session"»).
> Yet I think there is not even a bug in the issue tracker.

Hi,

I opened a bug entry yesterday because I think it's hard to get changes
back:
https://pharo.fogbugz.com/f/cases/18777/How-should-I-get-back-lost-changes-with-Epicea

And there is one about not opening the window if we leave Pharo without
a crash:
https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving


-- 
Cyril Ferlicot

http://www.synectique.eu

165 Avenue Bretagne
Lille 59000 France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Epicea?

[Alexandre Bergel]

Okay! Thanks!

Alexandre


> On Jul 15, 2016, at 4:08 PM, Cyril Ferlicot Delbecque 
>  wrote:
> 
> 
> 
> On 15/07/2016 16:01, Nicolas Passerini wrote:
>> There has been already a discussion about the same topic a few days ago
>> and I think that there is a consensus on considering it a bug that has
>> to be solved (look for «confused about the "image opening session"»).
>> Yet I think there is not even a bug in the issue tracker.
> 
> Hi,
> 
> I opened a bug entry yesterday because I think it's hard to get changes
> back:
> https://pharo.fogbugz.com/f/cases/18777/How-should-I-get-back-lost-changes-with-Epicea
> 
> And there is one about not opening the window if we leave Pharo without
> a crash:
> https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving
> 
> 
> -- 
> Cyril Ferlicot
> 
> http://www.synectique.eu
> 
> 165 Avenue Bretagne
> Lille 59000 France
> 

-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Re: [Pharo-dev] Epicea?

[stepharo]

Tx Cyril!!


Le 15/7/16 à 16:08, Cyril Ferlicot Delbecque a écrit :


On 15/07/2016 16:01, Nicolas Passerini wrote:

There has been already a discussion about the same topic a few days ago
and I think that there is a consensus on considering it a bug that has
to be solved (look for «confused about the "image opening session"»).
Yet I think there is not even a bug in the issue tracker.

Hi,

I opened a bug entry yesterday because I think it's hard to get changes
back:
https://pharo.fogbugz.com/f/cases/18777/How-should-I-get-back-lost-changes-with-Epicea

And there is one about not opening the window if we leave Pharo without
a crash:
https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving

Re: [Pharo-dev] Epicea

[Dennis Schetinin]

Is it possible log refactorings this way?


--

Best regards,


Dennis Schetinin

2014-12-17 22:50 GMT+04:00 Martin Dias :
>
> 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
>
>

Re: [Pharo-dev] Epicea

[Juraj Kubelka]

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  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
> 

Re: [Pharo-dev] Epicea

[Dennis Schetinin]

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 :
>
> 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  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
> >
>
>
>

Re: [Pharo-dev] Epicea

[Martin Dias]

On Thu, Dec 18, 2014 at 11:23 AM, Dennis Schetinin  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 :
>>
>> 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
>>
>

Re: [Pharo-dev] Epicea feedback

[Martin Dias]

Hello Jan, thanks for your feedback. I will have a look asap. Feel free to
report it in fogbugz.

Martín

On Tue, Jun 27, 2017 at 8:26 AM, Jan Blizničenko 
wrote:

> Hello
>
> I'd like to thank you for creating the Epicea. It is way more user-friendly
> and dependable than previous change-handling tool. Browsing, applying and
> reverting changes is way easier.
>
> Just one note:
> It is not exactly clear from first look how to properly reapply changes
> after an image has been closed without saving. If I select all changes I
> want to apply without using any filter, those changes are reapplied in
> wrong
> order (if I changed a method two times, first the new version is applied
> and
> then the old one). As far as I understood, I have to use filter to show
> only
> latest changes, but I think it could be clearer in the UI that I need to do
> so (or something completely different?) for applying changes.
>
> Thank you
> Jan
>
>
>
> --
> View this message in context: http://forum.world.st/Epicea-
> feedback-tp4952661.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Epicea feedback

[Stephane Ducasse]

Thanks martin for your excellent support.
What would be nice is to have some menus on the sessions items
because often I try to click on them so see what I can do with them.

Stef

On Tue, Jun 27, 2017 at 4:17 PM, Martin Dias  wrote:
> Hello Jan, thanks for your feedback. I will have a look asap. Feel free to
> report it in fogbugz.
>
> Martín
>
> On Tue, Jun 27, 2017 at 8:26 AM, Jan Blizničenko 
> wrote:
>>
>> Hello
>>
>> I'd like to thank you for creating the Epicea. It is way more
>> user-friendly
>> and dependable than previous change-handling tool. Browsing, applying and
>> reverting changes is way easier.
>>
>> Just one note:
>> It is not exactly clear from first look how to properly reapply changes
>> after an image has been closed without saving. If I select all changes I
>> want to apply without using any filter, those changes are reapplied in
>> wrong
>> order (if I changed a method two times, first the new version is applied
>> and
>> then the old one). As far as I understood, I have to use filter to show
>> only
>> latest changes, but I think it could be clearer in the UI that I need to
>> do
>> so (or something completely different?) for applying changes.
>>
>> Thank you
>> Jan
>>
>>
>>
>> --
>> View this message in context:
>> http://forum.world.st/Epicea-feedback-tp4952661.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>

Re: [Pharo-dev] Epicea feedback

[Martin Dias]

Thanks I still didn't invest time to fix them but I registered both in
fogbugz as:

https://pharo.fogbugz.com/f/cases/20223/Epicea-check-usability-bug-to-apply-changes
https://pharo.fogbugz.com/f/cases/20225/Epicea-would-be-nice-is-to-have-some-menus-on-the-sessions-items

cheers,
Martin

On Sat, Jul 1, 2017 at 5:24 AM, Stephane Ducasse 
wrote:

> Thanks martin for your excellent support.
> What would be nice is to have some menus on the sessions items
> because often I try to click on them so see what I can do with them.
>
> Stef
>
> On Tue, Jun 27, 2017 at 4:17 PM, Martin Dias  wrote:
> > Hello Jan, thanks for your feedback. I will have a look asap. Feel free
> to
> > report it in fogbugz.
> >
> > Martín
> >
> > On Tue, Jun 27, 2017 at 8:26 AM, Jan Blizničenko 
> > wrote:
> >>
> >> Hello
> >>
> >> I'd like to thank you for creating the Epicea. It is way more
> >> user-friendly
> >> and dependable than previous change-handling tool. Browsing, applying
> and
> >> reverting changes is way easier.
> >>
> >> Just one note:
> >> It is not exactly clear from first look how to properly reapply changes
> >> after an image has been closed without saving. If I select all changes I
> >> want to apply without using any filter, those changes are reapplied in
> >> wrong
> >> order (if I changed a method two times, first the new version is applied
> >> and
> >> then the old one). As far as I understood, I have to use filter to show
> >> only
> >> latest changes, but I think it could be clearer in the UI that I need to
> >> do
> >> so (or something completely different?) for applying changes.
> >>
> >> Thank you
> >> Jan
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >> http://forum.world.st/Epicea-feedback-tp4952661.html
> >> Sent from the Pharo Smalltalk Developers mailing list archive at
> >> Nabble.com.
> >>
> >
>
>

Re: [Pharo-dev] Epicea feedback

[Jan Blizničenko]

Thank you for that, since I did not managed to register those at the time.

Jan


tinchodias wrote
> Thanks I still didn't invest time to fix them but I registered both in
> fogbugz as:
> 
> https://pharo.fogbugz.com/f/cases/20223/Epicea-check-usability-bug-to-apply-changes
> https://pharo.fogbugz.com/f/cases/20225/Epicea-would-be-nice-is-to-have-some-menus-on-the-sessions-items
> 
> cheers,
> Martin
> 
> On Sat, Jul 1, 2017 at 5:24 AM, Stephane Ducasse <

> stepharo.self@

> >
> wrote:
> 
>> Thanks martin for your excellent support.
>> What would be nice is to have some menus on the sessions items
>> because often I try to click on them so see what I can do with them.
>>
>> Stef
>>
>> On Tue, Jun 27, 2017 at 4:17 PM, Martin Dias <

> tinchodias@

> > wrote:
>> > Hello Jan, thanks for your feedback. I will have a look asap. Feel free
>> to
>> > report it in fogbugz.
>> >
>> > Martín
>> >
>> > On Tue, Jun 27, 2017 at 8:26 AM, Jan Blizničenko <

> bliznjan@.cvut

> >
>> > wrote:
>> >>
>> >> Hello
>> >>
>> >> I'd like to thank you for creating the Epicea. It is way more
>> >> user-friendly
>> >> and dependable than previous change-handling tool. Browsing, applying
>> and
>> >> reverting changes is way easier.
>> >>
>> >> Just one note:
>> >> It is not exactly clear from first look how to properly reapply
>> changes
>> >> after an image has been closed without saving. If I select all changes
>> I
>> >> want to apply without using any filter, those changes are reapplied in
>> >> wrong
>> >> order (if I changed a method two times, first the new version is
>> applied
>> >> and
>> >> then the old one). As far as I understood, I have to use filter to
>> show
>> >> only
>> >> latest changes, but I think it could be clearer in the UI that I need
>> to
>> >> do
>> >> so (or something completely different?) for applying changes.
>> >>
>> >> Thank you
>> >> Jan
>> >>
>> >>
>> >>
>> >> --
>> >> View this message in context:
>> >> http://forum.world.st/Epicea-feedback-tp4952661.html
>> >> Sent from the Pharo Smalltalk Developers mailing list archive at
>> >> Nabble.com.
>> >>
>> >
>>
>>





--
View this message in context: 
http://forum.world.st/Epicea-feedback-tp4952661p4956491.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Epicea wishlist

[Martin Dias]

Stef, ok I add your request in the issue tracker:

https://pharo.fogbugz.com/f/cases/20474/Epicea-Keep-filter-across-session-improve-search-of-code-entities

It's kind of funny because the filters were kept across seassions and I
*intentionally* added the filter cleaning when session selection changes.
IMO it was misleading to keep them as you want, but also I understand your
point... I think moving the filters widget to other place in the window can
do it.

Martín

On Thu, Sep 7, 2017 at 3:15 AM, Stephane Ducasse 
wrote:

> Hi martin
>
> I'm missing two features:
>
> - keep the filter across session because this is boring to have to
> redo them all over.
> - a search for entities accross session.
> - a search inside a session
> For example I was looking for all the changes I did to the UI part of
> my application but I was doing many development
> loading different unrelated package and saving after.
>
> Right now you can restrict to view changes but only if you have a
> first entity of the package for example so you have to look first is
> there an entity of this package.
>
> Stef
>
>

Re: [Pharo-dev] Epicea wishlist

[Stephane Ducasse]

Tx Martin.

On Thu, Sep 28, 2017 at 4:33 PM, Martin Dias  wrote:
> Stef, ok I add your request in the issue tracker:
>
> https://pharo.fogbugz.com/f/cases/20474/Epicea-Keep-filter-across-session-improve-search-of-code-entities
>
> It's kind of funny because the filters were kept across seassions and I
> *intentionally* added the filter cleaning when session selection changes.
> IMO it was misleading to keep them as you want, but also I understand your
> point... I think moving the filters widget to other place in the window can
> do it.
>
> Martín
>
> On Thu, Sep 7, 2017 at 3:15 AM, Stephane Ducasse 
> wrote:
>>
>> Hi martin
>>
>> I'm missing two features:
>>
>> - keep the filter across session because this is boring to have to
>> redo them all over.
>> - a search for entities accross session.
>> - a search inside a session
>> For example I was looking for all the changes I did to the UI part of
>> my application but I was doing many development
>> loading different unrelated package and saving after.
>>
>> Right now you can restrict to view changes but only if you have a
>> first entity of the package for example so you have to look first is
>> there an entity of this package.
>>
>> Stef
>>
>

Re: [Pharo-dev] Epicea Feedback

[Sean P. DeNigris]

In case it helps anyone in the future, here is the "poor man's" browser I
hacked together to find all Magritte changes that needed to be rescued from
an image where those changes got out-of-sync so I couldn't use Iceberg:

nodes := EpFileLogNode fromAllLogsIn: EpMonitor current sessionStore
baseLocator.
relevantNodes := nodes reject: [ :n | (n globalName endsWith: 'g3') or: [ n
globalName endsWith: 'ng' ] ].
relevantNodes do: [ :node | node populateReferencedNodesWith: relevantNodes
].
entries := relevantNodes flatCollect: [ :n | n log entries ].
filter := EpAndFilter withAll: {
EpImpactCodeChangeFilter new environment: self class environment; 
yourself.
EpPluggableFilter new condition: [ :e | 
e content isCodeChange and: [ 
e content affectedPackageName beginsWith: 'Magritte' ] 
].
EpPluggableFilter noTriggerFilter }.
filteredEntries := entries select: [ :e | filter accepts: e ].
filteredEntries sort: [ :a :b | (a tagAt: #time) > (b tagAt: #time) ].
groups := filteredEntries groupedBy: [ :e | (e content respondsTo:
#methodAffected) ifFalse: [ '?' ] ifTrue: [ e content methodAffected ] ].
events := groups collect: [ :col | col first content ] as:
OrderedCollection.
events collect: [ :e | "{ e." DiffModel new
showOptions: true;
leftText: (e accept: EpOldStateVisitor new);
rightText: (e accept: EpNewStateVisitor new);
contextClass: e class;
buildWithSpec "}" ].



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Epicea Feedback

[ducasse]

Thanks sean for the feedback 
Now pay attention that we cannot digest fast non PRs because we are super busy 
with P8 alpha.
Can you open an issue so that martin can get an idea of what should be improved?

Stef

> On 18 Aug 2019, at 21:41, Sean P. DeNigris  wrote:
> 
> In case it helps anyone in the future, here is the "poor man's" browser I
> hacked together to find all Magritte changes that needed to be rescued from
> an image where those changes got out-of-sync so I couldn't use Iceberg:
> 
> nodes := EpFileLogNode fromAllLogsIn: EpMonitor current sessionStore
> baseLocator.
> relevantNodes := nodes reject: [ :n | (n globalName endsWith: 'g3') or: [ n
> globalName endsWith: 'ng' ] ].
> relevantNodes do: [ :node | node populateReferencedNodesWith: relevantNodes
> ].
> entries := relevantNodes flatCollect: [ :n | n log entries ].
> filter := EpAndFilter withAll: {
>   EpImpactCodeChangeFilter new environment: self class environment; 
> yourself.
>   EpPluggableFilter new condition: [ :e | 
>   e content isCodeChange and: [ 
>   e content affectedPackageName beginsWith: 'Magritte' ] 
> ].
>   EpPluggableFilter noTriggerFilter }.
> filteredEntries := entries select: [ :e | filter accepts: e ].
> filteredEntries sort: [ :a :b | (a tagAt: #time) > (b tagAt: #time) ].
> groups := filteredEntries groupedBy: [ :e | (e content respondsTo:
> #methodAffected) ifFalse: [ '?' ] ifTrue: [ e content methodAffected ] ].
> events := groups collect: [ :col | col first content ] as:
> OrderedCollection.
> events collect: [ :e | "{ e." DiffModel new
>   showOptions: true;
>   leftText: (e accept: EpOldStateVisitor new);
>   rightText: (e accept: EpNewStateVisitor new);
>   contextClass: e class;
>   buildWithSpec "}" ].
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Epicea Feedback

[ducasse]

Are you in P8?

Stef

> On 18 Aug 2019, at 21:21, Sean P. DeNigris  wrote:
> 
> Not complaining at all and appreciate everyone's hard (mostly-unpaid) work,
> but providing raw feedback in case it's helpful...
> 
> - Browser awkward: filters disappear whenever left selection changed; no
> multi-select of sessions, which led to a host of difficulties described
> below.
> - What is the heuristic to find API access points? Epicea package has no
> comment, 'Browser' tag doesn't seem to have an XyzBrowser class, no
> particular class in the 'Model' tag jumps out at me as an access point; as
> above Browser about text not set. I finally bring up Morphic halos on the
> browser and after flopping around, find subclasses of EpLogNode; I browse it
> and find EpLogNodeGraphModel, which sounds interesting and turns out to be a
> spec. I figure out how to list the log files, but not how to get the entries
> - I was expecting a term like that and the relevant method (#log it turns
> out) has no comment to indicate it's what I'm looking for. Now that I'm
> starting to understand the project organization, back to the browser to
> explore EpUnifiedBrowserModel. After a bit of poking around, I suspect
> (correctly) that #log is what I'm after.
>   
> Based on code I extract from the browsers and a bit of experimenting in GT,
> I come up with the following seemingly very complex script:
> 
> nodes := EpFileLogNode fromAllLogsIn: EpMonitor current sessionStore
> baseLocator.
> nodes do: [ :node | node populateReferencedNodesWith: nodes ].
> nodes flatCollect: [ :n | n log events select: [ :e | e affectedPackageName
> beginsWith: 'Magritte' ] ]
> 
> I now run into a series of problems because, although EpCodeChange declares
> #affectedPackageName as an abstract method, not all events are
> EpCodeChanges. I exclude EpUndos. Easy enough. Now I come to an
> EpGenericRefactoring. This one is harder because 
>   
> p.s. Code names for internal projects seem extremely
> counterproductive. Hiedra tells me absolutely nothing about functionality.
> It might as well be called XyzWidgetThing
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Epicea Feedback

[Sean P. DeNigris]

Done:
https://github.com/pharo-project/pharo/issues/4496
https://github.com/pharo-project/pharo/issues/4495



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] Epicea applying multiple changes

[Andrei Chis]

Hi,

Is there some known bug in Epicea when applying multiple changes at once in
Pharo 6?

I had a few crashes lately and each time when recovering the changes by
selecting multiple changes at once some changes are skipped. If I apply
manually each change it works.

Cheers,
Andrei

[Pharo-dev] Epicea feedback - save points

[Ben Coman]

When I'm in need Epicea, the common scenario is that I've working in the
same session of an Image most of the day, or even days, and I've done
something stupid to lock up the UI, and its only been an hour since my last
save point (force of habit).  When I review Epicea, "Filter > Show latest
changes" its still ahrd to determine which changes I'm missing.  What I've
just realised is I miss the visibility of the Save Point in the old changes
system.  I'd find it really useful for the save points to be show in the
changes list, and also a filter I'd find really useful is "Shows latest
changes since last save".


cheers -ben

[Pharo-dev] Epicea user experience report

[Ben Coman]

1. Created fresh Pharo image (build 60269)


2. Opened World > Tools > Epicea > All changes

Points for discussion...

  a. How many submenu items are expected for Epicea? Can we push the
current ones up so the Tools menu remains a flat menu.

  b. Do we need the two current menu items?  "Current session" is
encompassed by "All changes"?  What expectations do people have of how
often they'll use the former rather than the latter?

  c. When people move from Pharo 5 to Pharo 6 and in a panic want to
"recover changes" for a crashed image, they'll be looking for that
familiar feature name, not a new app name. Could the app name be left
out or placed in brackets "Changes (Epicea)".

btw, the interface looks really slick! nice work.


3. Opened World > System Browser.

4. Added package AAA
All Changes window - no dynamic change.
On , still no change, i.e. no sessions
#New All Changes window - not visible, no sessions.

5. Added class AA.
All Changes window - no dynamic change.
On , shows new session with AAA & AA.

5. Added method...
AA>a
   ^'something'
Prompted for author, entered 'BenComan'
All Changes window with session selected - dynamic update showing AA>>a.

6. Added package BBB.
All Changes window - no dynamic update.
On , BBB still not visible in session.

7. Added class A to package AAA.
All Changes window - dynamic update showing A.
On , BBB still not visible in session.

8. Added class BB to package BBB.
All Changes window - dynamic update showing BBB & BB.

  a. Package creation event seems not handled properly, being only
pushed through when a class is created in it.

  b. Since there is a dynamic update for class and method
modifications, could the session creation also dynamically update it
UI.

---
9. Killed the vm from command line
$ ps -ef | grep pharo
$ kill 29349
   Restarted Pharo image

10. World > Tools > Epica > All changes.
Authorship is inconsistent:
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'BenComan'.

 a. I understand this follows on from Author not being requested until
the first method was defined. Did the old changes track the author of
packages and classes at all?

 b. Since Epicea can track package and class authors, can we trigger
the author prompt earlier for them?

11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
and did .
Prompted for author. Entered 'DrWho'
Existing All Changes window - no change
New All Changes window - shows new session with all six changes.
Authorship is a little inconsistent:
* AAA and AA have author 'Unknown'.
* AA>>a, A, BBB, B have blank author.

12. Killed the vm from command line
$ ps -ef | grep pharo
$ kill 30696
   Restarted Pharo image

13. World > Tools > Epica > All changes.
Authorship is a little inconsistent:
First session
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'BenComan'.
Second session
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'DrWho'.

 a. Epicea changes are reapplied as the current author.  This seems a
semantic change from Pharo 5 where changes were reapplied as their
original author. Is this accidental or by design?  Can we have some
community discussion on this point (I don't remember seeing any)?

cheers -ben

P.S. I'll wait to see what arises out of discussion before creating any issues.

[Pharo-dev] Epicea should ask before recovering

[Peter Uhnak]

Hi,

can we modify epicea before asking for recovery?
Because right now when I close image to intentionally throw away changes 
(because I managed to break the image or whatever), Epicea will freeze the 
image on startup for 10-15 seconds for even a mere 6-method change.

(I also had it freeze for (couple) minutes on a rather big changeset...)

Closing image and reopening is a very convenient way to get back to usable 
state of the image, so maybe a configuration option that would first prompt me 
"Epicea has detected lost changes, do you want to review them?  " 
would be nice.

Of course if I am the only person that uses images in such a way then I can 
just work around it myself. (because having endless lists of config options is 
also nightmare)

Peter

[Pharo-dev] Epicea and #name in #behaviorAffectedName

[Torsten Bergmann]

Hi,

in latest Pharo 6 image 60494 I run into some trouble today where the 
deprecation warning dialog popped up and repeated itself unstoppable
due to Epicea.

It is hard to reproduce but what I found out was that I had a class
modification (represented by EpClassModification) which run into a state 
where "newClass" was nil and therefore in 
EpClassModification>>#behaviorAffectedName 
the message #name was sent to nil.

So #name was found in Object and as we all know we deprecated it now
which lead to the deprecation dialog, leading to the deprecation dialog, 
leading to the deprecation dialog, ... 

Nearly all implementors of Epiceas #behaviorAffectedName send #name
which is ok if there is a valid object it is sent to.

I do not know if we should protect them somehow in case something
goes wrong (like having nil in newClass) or if we should keep this 
untouched.

At least I wanted to inform because I do not know if this later
gets others into trouble too and losing their changes because Epicea
does not record.

Thanks
T.

Re: [Pharo-dev] Epicea applying multiple changes

[Stephane Ducasse]

Hi andrei

this is strange because I recovered multiple time recently due to some
hidden bugs and I did not face the one you report.

Stef

On Tue, Jul 18, 2017 at 10:48 AM, Andrei Chis
 wrote:
> Hi,
>
> Is there some known bug in Epicea when applying multiple changes at once in
> Pharo 6?
>
> I had a few crashes lately and each time when recovering the changes by
> selecting multiple changes at once some changes are skipped. If I apply
> manually each change it works.
>
> Cheers,
> Andrei

Re: [Pharo-dev] Epicea applying multiple changes

[Tim Mackinnon]

I thought I had the same problem at Pharo Days, but actually I think it's just 
the UI is a bit confusing. Stephane E and I had a look and it seemed to be fine 
for the case I thought I had.

Possibly it was that , it's easy to load in more than you think you should 
which gives weird outcomes.

Tim 

Sent from my iPhone

> On 18 Jul 2017, at 22:21, Stephane Ducasse  wrote:
> 
> Hi andrei
> 
> this is strange because I recovered multiple time recently due to some
> hidden bugs and I did not face the one you report.
> 
> Stef
> 
> On Tue, Jul 18, 2017 at 10:48 AM, Andrei Chis
>  wrote:
>> Hi,
>> 
>> Is there some known bug in Epicea when applying multiple changes at once in
>> Pharo 6?
>> 
>> I had a few crashes lately and each time when recovering the changes by
>> selecting multiple changes at once some changes are skipped. If I apply
>> manually each change it works.
>> 
>> Cheers,
>> Andrei
> 

Re: [Pharo-dev] Epicea applying multiple changes

[Tudor Girba]

Hi,

I experienced the same issues. It seems somehow related that when we have 
multiple changes to the same method, not all changes are applied and we do not 
get back the latest version.

Cheers,
Doru


> On Jul 18, 2017, at 10:48 AM, Andrei Chis  wrote:
> 
> Hi,
> 
> Is there some known bug in Epicea when applying multiple changes at once in 
> Pharo 6?
> 
> I had a few crashes lately and each time when recovering the changes by 
> selecting multiple changes at once some changes are skipped. If I apply 
> manually each change it works. 
> 
> Cheers,
> Andrei

--
www.tudorgirba.com
www.feenk.com

"Things happen when they happen,
not when you talk about them happening."

Re: [Pharo-dev] Epicea applying multiple changes

[Denis Kudriashov]

It is issue 20223


2017-07-19 9:41 GMT+02:00 Tudor Girba :

> Hi,
>
> I experienced the same issues. It seems somehow related that when we have
> multiple changes to the same method, not all changes are applied and we do
> not get back the latest version.
>
> Cheers,
> Doru
>
>
> > On Jul 18, 2017, at 10:48 AM, Andrei Chis 
> wrote:
> >
> > Hi,
> >
> > Is there some known bug in Epicea when applying multiple changes at once
> in Pharo 6?
> >
> > I had a few crashes lately and each time when recovering the changes by
> selecting multiple changes at once some changes are skipped. If I apply
> manually each change it works.
> >
> > Cheers,
> > Andrei
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Things happen when they happen,
> not when you talk about them happening."
>
>
>

Re: [Pharo-dev] Epicea applying multiple changes

[Martin Dias]

I'll check the bug, it's important.

However, Tim and others, I'm interested in your experience with the UI. If
you want to send me more details...

Maybe I can remark: Epicea has work and feedback accumulated during my phd.
Now that phd finished and Epicea comes with Pharo 6.0, the project is open
to much more developers to collaborate with their work and feedback. So you
are welcome. The project belongs to the community now even though I'm still
responsible to maintain it, of course.

Cheers, Martín

On Thu, Jul 20, 2017 at 5:18 AM, Denis Kudriashov 
wrote:

> It is issue 20223
> 
>
> 2017-07-19 9:41 GMT+02:00 Tudor Girba :
>
>> Hi,
>>
>> I experienced the same issues. It seems somehow related that when we have
>> multiple changes to the same method, not all changes are applied and we do
>> not get back the latest version.
>>
>> Cheers,
>> Doru
>>
>>
>> > On Jul 18, 2017, at 10:48 AM, Andrei Chis 
>> wrote:
>> >
>> > Hi,
>> >
>> > Is there some known bug in Epicea when applying multiple changes at
>> once in Pharo 6?
>> >
>> > I had a few crashes lately and each time when recovering the changes by
>> selecting multiple changes at once some changes are skipped. If I apply
>> manually each change it works.
>> >
>> > Cheers,
>> > Andrei
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Things happen when they happen,
>> not when you talk about them happening."
>>
>>
>>
>

Re: [Pharo-dev] Epicea applying multiple changes

[Jan Blizničenko]

Hello

Might it be related to a problem I described over here?
http://forum.world.st/Epicea-feedback-td4952661.html

In short, I think that when I select multiple changes, epicea applies them
in wrong order, so, if for example a single method is changed two times,
Epicea first creates newer content and then replaces it by older content. It
seems to be solvable by filtering just latest changes, but I am not sure
whether it might not have other unwanted consequences.

Jan


tinchodias wrote
> I'll check the bug, it's important.
> 
> However, Tim and others, I'm interested in your experience with the UI. If
> you want to send me more details...
> 
> Maybe I can remark: Epicea has work and feedback accumulated during my
> phd.
> Now that phd finished and Epicea comes with Pharo 6.0, the project is open
> to much more developers to collaborate with their work and feedback. So
> you
> are welcome. The project belongs to the community now even though I'm
> still
> responsible to maintain it, of course.
> 
> Cheers, Martín
> 
> On Thu, Jul 20, 2017 at 5:18 AM, Denis Kudriashov <

> dionisiydk@

> >
> wrote:
> 
>> It is issue 20223
>> ;
>>
>> 2017-07-19 9:41 GMT+02:00 Tudor Girba <

> tudor@

> >:
>>
>>> Hi,
>>>
>>> I experienced the same issues. It seems somehow related that when we
>>> have
>>> multiple changes to the same method, not all changes are applied and we
>>> do
>>> not get back the latest version.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> > On Jul 18, 2017, at 10:48 AM, Andrei Chis <

> chisvasileandrei@

> >
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > Is there some known bug in Epicea when applying multiple changes at
>>> once in Pharo 6?
>>> >
>>> > I had a few crashes lately and each time when recovering the changes
>>> by
>>> selecting multiple changes at once some changes are skipped. If I apply
>>> manually each change it works.
>>> >
>>> > Cheers,
>>> > Andrei
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Things happen when they happen,
>>> not when you talk about them happening."
>>>
>>>
>>>
>>





--
View this message in context: 
http://forum.world.st/Epicea-applying-multiple-changes-tp4955502p4956482.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Epicea applying multiple changes

[Tim Mackinnon]

In retrospect, this is the problem I also had - But I put it down to the UI 
being a bit confusing about what you were loading.

I will give some constructive feedback on the UI as like others, I think the 
underlying idea is very good.

Tim

Sent from my iPhone

> On 23 Jul 2017, at 22:10, Jan Blizničenko  wrote:
> 
> Hello
> 
> Might it be related to a problem I described over here?
> http://forum.world.st/Epicea-feedback-td4952661.html
> 
> In short, I think that when I select multiple changes, epicea applies them
> in wrong order, so, if for example a single method is changed two times,
> Epicea first creates newer content and then replaces it by older content. It
> seems to be solvable by filtering just latest changes, but I am not sure
> whether it might not have other unwanted consequences.
> 
> Jan
> 
> 
> tinchodias wrote
>> I'll check the bug, it's important.
>> 
>> However, Tim and others, I'm interested in your experience with the UI. If
>> you want to send me more details...
>> 
>> Maybe I can remark: Epicea has work and feedback accumulated during my
>> phd.
>> Now that phd finished and Epicea comes with Pharo 6.0, the project is open
>> to much more developers to collaborate with their work and feedback. So
>> you
>> are welcome. The project belongs to the community now even though I'm
>> still
>> responsible to maintain it, of course.
>> 
>> Cheers, Martín
>> 
>> On Thu, Jul 20, 2017 at 5:18 AM, Denis Kudriashov <
> 
>> dionisiydk@
> 
>> >
>> wrote:
>> 
>>> It is issue 20223
>>> ;
>>> 
>>> 2017-07-19 9:41 GMT+02:00 Tudor Girba <
> 
>> tudor@
> 
>> >:
>>> 
 Hi,
 
 I experienced the same issues. It seems somehow related that when we
 have
 multiple changes to the same method, not all changes are applied and we
 do
 not get back the latest version.
 
 Cheers,
 Doru
 
 
> On Jul 18, 2017, at 10:48 AM, Andrei Chis <
> 
>> chisvasileandrei@
> 
>> >
 wrote:
> 
> Hi,
> 
> Is there some known bug in Epicea when applying multiple changes at
 once in Pharo 6?
> 
> I had a few crashes lately and each time when recovering the changes
 by
 selecting multiple changes at once some changes are skipped. If I apply
 manually each change it works.
> 
> Cheers,
> Andrei
 
 --
 www.tudorgirba.com
 www.feenk.com
 
 "Things happen when they happen,
 not when you talk about them happening."
 
 
 
>>> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://forum.world.st/Epicea-applying-multiple-changes-tp4955502p4956482.html
> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
> 

Re: [Pharo-dev] Epicea feedback - save points

[Norbert Hartl]

Same for me. I thought the last save point would be the last session in the 
list but I don‘t think that is really true. So I‘m confused by Epicea, too.

Norbert

> Am 13.12.2017 um 08:27 schrieb Ben Coman :
> 
> When I'm in need Epicea, the common scenario is that I've working in the same 
> session of an Image most of the day, or even days, and I've done something 
> stupid to lock up the UI, and its only been an hour since my last save point 
> (force of habit).  When I review Epicea, "Filter > Show latest changes" its 
> still ahrd to determine which changes I'm missing.  What I've just realised 
> is I miss the visibility of the Save Point in the old changes system.  I'd 
> find it really useful for the save points to be show in the changes list, and 
> also a filter I'd find really useful is "Shows latest changes since last 
> save".
> 
> 
> cheers -ben

Re: [Pharo-dev] Epicea feedback - save points

[Stephane Ducasse]

I think that epicea save point are the list elements on the left.


On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl  wrote:
> Same for me. I thought the last save point would be the last session in the 
> list but I don‘t think that is really true. So I‘m confused by Epicea, too.
>
> Norbert
>
>> Am 13.12.2017 um 08:27 schrieb Ben Coman :
>>
>> When I'm in need Epicea, the common scenario is that I've working in the 
>> same session of an Image most of the day, or even days, and I've done 
>> something stupid to lock up the UI, and its only been an hour since my last 
>> save point (force of habit).  When I review Epicea, "Filter > Show latest 
>> changes" its still ahrd to determine which changes I'm missing.  What I've 
>> just realised is I miss the visibility of the Save Point in the old changes 
>> system.  I'd find it really useful for the save points to be show in the 
>> changes list, and also a filter I'd find really useful is "Shows latest 
>> changes since last save".
>>
>>
>> cheers -ben
>

Re: [Pharo-dev] Epicea feedback - save points

[Ben Coman]

Hi Stef,

I think that is incorrect. Its easy to be certain...
1. Open Epicea
2. Save and continue
3. Open Epicea and observe there is no difference

cheers -ben

On 13 December 2017 at 17:59, Stephane Ducasse 
wrote:

> I think that epicea save point are the list elements on the left.
>
>
> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl  wrote:
> > Same for me. I thought the last save point would be the last session in
> the list but I don‘t think that is really true. So I‘m confused by Epicea,
> too.
> >
> > Norbert
> >
> >> Am 13.12.2017 um 08:27 schrieb Ben Coman :
> >>
> >> When I'm in need Epicea, the common scenario is that I've working in
> the same session of an Image most of the day, or even days, and I've done
> something stupid to lock up the UI, and its only been an hour since my last
> save point (force of habit).  When I review Epicea, "Filter > Show latest
> changes" its still ahrd to determine which changes I'm missing.  What I've
> just realised is I miss the visibility of the Save Point in the old changes
> system.  I'd find it really useful for the save points to be show in the
> changes list, and also a filter I'd find really useful is "Shows latest
> changes since last save".
> >>
> >>
> >> cheers -ben
> >
>
>

Re: [Pharo-dev] Epicea feedback - save points

[Stephane Ducasse]

Ok so we should check because it should not be complex to add that.
The model is quite nice.

On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman  wrote:
> Hi Stef,
>
> I think that is incorrect. Its easy to be certain...
> 1. Open Epicea
> 2. Save and continue
> 3. Open Epicea and observe there is no difference
>
> cheers -ben
>
>
> On 13 December 2017 at 17:59, Stephane Ducasse 
> wrote:
>>
>> I think that epicea save point are the list elements on the left.
>>
>>
>> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl  wrote:
>> > Same for me. I thought the last save point would be the last session in
>> > the list but I don‘t think that is really true. So I‘m confused by Epicea,
>> > too.
>> >
>> > Norbert
>> >
>> >> Am 13.12.2017 um 08:27 schrieb Ben Coman :
>> >>
>> >> When I'm in need Epicea, the common scenario is that I've working in
>> >> the same session of an Image most of the day, or even days, and I've done
>> >> something stupid to lock up the UI, and its only been an hour since my 
>> >> last
>> >> save point (force of habit).  When I review Epicea, "Filter > Show latest
>> >> changes" its still ahrd to determine which changes I'm missing.  What I've
>> >> just realised is I miss the visibility of the Save Point in the old 
>> >> changes
>> >> system.  I'd find it really useful for the save points to be show in the
>> >> changes list, and also a filter I'd find really useful is "Shows latest
>> >> changes since last save".
>> >>
>> >>
>> >> cheers -ben
>> >
>>
>

Re: [Pharo-dev] Epicea feedback - save points

[Martin Dias]

Hi

When you "save and close" or "save as..." then next changes will go to a
new log file. Then, they will have a new item of the left of the browser
(as Stef said).
When you just "save", I agree I'd like that. It was there originally but I
disabled it because of a bug related with the announcement. Apparently now
it can be re-enabled:
https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving

Martín

On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse 
wrote:

> Ok so we should check because it should not be complex to add that.
> The model is quite nice.
>
> On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman  wrote:
> > Hi Stef,
> >
> > I think that is incorrect. Its easy to be certain...
> > 1. Open Epicea
> > 2. Save and continue
> > 3. Open Epicea and observe there is no difference
> >
> > cheers -ben
> >
> >
> > On 13 December 2017 at 17:59, Stephane Ducasse 
> > wrote:
> >>
> >> I think that epicea save point are the list elements on the left.
> >>
> >>
> >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl 
> wrote:
> >> > Same for me. I thought the last save point would be the last session
> in
> >> > the list but I don‘t think that is really true. So I‘m confused by
> Epicea,
> >> > too.
> >> >
> >> > Norbert
> >> >
> >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman :
> >> >>
> >> >> When I'm in need Epicea, the common scenario is that I've working in
> >> >> the same session of an Image most of the day, or even days, and I've
> done
> >> >> something stupid to lock up the UI, and its only been an hour since
> my last
> >> >> save point (force of habit).  When I review Epicea, "Filter > Show
> latest
> >> >> changes" its still ahrd to determine which changes I'm missing.
> What I've
> >> >> just realised is I miss the visibility of the Save Point in the old
> changes
> >> >> system.  I'd find it really useful for the save points to be show in
> the
> >> >> changes list, and also a filter I'd find really useful is "Shows
> latest
> >> >> changes since last save".
> >> >>
> >> >>
> >> >> cheers -ben
> >> >
> >>
> >
>
>

Re: [Pharo-dev] Epicea feedback - save points

[Stephane Ducasse]

Thanks Martin!!!

On Wed, Dec 13, 2017 at 1:29 PM, Martin Dias  wrote:
> Hi
>
> When you "save and close" or "save as..." then next changes will go to a new
> log file. Then, they will have a new item of the left of the browser (as
> Stef said).
> When you just "save", I agree I'd like that. It was there originally but I
> disabled it because of a bug related with the announcement. Apparently now
> it can be re-enabled:
> https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving
>
> Martín
>
> On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse 
> wrote:
>>
>> Ok so we should check because it should not be complex to add that.
>> The model is quite nice.
>>
>> On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman  wrote:
>> > Hi Stef,
>> >
>> > I think that is incorrect. Its easy to be certain...
>> > 1. Open Epicea
>> > 2. Save and continue
>> > 3. Open Epicea and observe there is no difference
>> >
>> > cheers -ben
>> >
>> >
>> > On 13 December 2017 at 17:59, Stephane Ducasse 
>> > wrote:
>> >>
>> >> I think that epicea save point are the list elements on the left.
>> >>
>> >>
>> >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl 
>> >> wrote:
>> >> > Same for me. I thought the last save point would be the last session
>> >> > in
>> >> > the list but I don‘t think that is really true. So I‘m confused by
>> >> > Epicea,
>> >> > too.
>> >> >
>> >> > Norbert
>> >> >
>> >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman :
>> >> >>
>> >> >> When I'm in need Epicea, the common scenario is that I've working in
>> >> >> the same session of an Image most of the day, or even days, and I've
>> >> >> done
>> >> >> something stupid to lock up the UI, and its only been an hour since
>> >> >> my last
>> >> >> save point (force of habit).  When I review Epicea, "Filter > Show
>> >> >> latest
>> >> >> changes" its still ahrd to determine which changes I'm missing.
>> >> >> What I've
>> >> >> just realised is I miss the visibility of the Save Point in the old
>> >> >> changes
>> >> >> system.  I'd find it really useful for the save points to be show in
>> >> >> the
>> >> >> changes list, and also a filter I'd find really useful is "Shows
>> >> >> latest
>> >> >> changes since last save".
>> >> >>
>> >> >>
>> >> >> cheers -ben
>> >> >
>> >>
>> >
>>
>

Re: [Pharo-dev] Epicea feedback - save points

[Stephane Ducasse]

I love epicea :)
Did you see that now people use my extension to generate docs :)

Stef

On Sat, Dec 16, 2017 at 9:03 AM, Stephane Ducasse
 wrote:
> Thanks Martin!!!
>
> On Wed, Dec 13, 2017 at 1:29 PM, Martin Dias  wrote:
>> Hi
>>
>> When you "save and close" or "save as..." then next changes will go to a new
>> log file. Then, they will have a new item of the left of the browser (as
>> Stef said).
>> When you just "save", I agree I'd like that. It was there originally but I
>> disabled it because of a bug related with the announcement. Apparently now
>> it can be re-enabled:
>> https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving
>>
>> Martín
>>
>> On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse 
>> wrote:
>>>
>>> Ok so we should check because it should not be complex to add that.
>>> The model is quite nice.
>>>
>>> On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman  wrote:
>>> > Hi Stef,
>>> >
>>> > I think that is incorrect. Its easy to be certain...
>>> > 1. Open Epicea
>>> > 2. Save and continue
>>> > 3. Open Epicea and observe there is no difference
>>> >
>>> > cheers -ben
>>> >
>>> >
>>> > On 13 December 2017 at 17:59, Stephane Ducasse 
>>> > wrote:
>>> >>
>>> >> I think that epicea save point are the list elements on the left.
>>> >>
>>> >>
>>> >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl 
>>> >> wrote:
>>> >> > Same for me. I thought the last save point would be the last session
>>> >> > in
>>> >> > the list but I don‘t think that is really true. So I‘m confused by
>>> >> > Epicea,
>>> >> > too.
>>> >> >
>>> >> > Norbert
>>> >> >
>>> >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman :
>>> >> >>
>>> >> >> When I'm in need Epicea, the common scenario is that I've working in
>>> >> >> the same session of an Image most of the day, or even days, and I've
>>> >> >> done
>>> >> >> something stupid to lock up the UI, and its only been an hour since
>>> >> >> my last
>>> >> >> save point (force of habit).  When I review Epicea, "Filter > Show
>>> >> >> latest
>>> >> >> changes" its still ahrd to determine which changes I'm missing.
>>> >> >> What I've
>>> >> >> just realised is I miss the visibility of the Save Point in the old
>>> >> >> changes
>>> >> >> system.  I'd find it really useful for the save points to be show in
>>> >> >> the
>>> >> >> changes list, and also a filter I'd find really useful is "Shows
>>> >> >> latest
>>> >> >> changes since last save".
>>> >> >>
>>> >> >>
>>> >> >> cheers -ben
>>> >> >
>>> >>
>>> >
>>>
>>

Re: [Pharo-dev] Epicea feedback - save points

[Martin Dias]

El 16 dic. 2017 5:04 AM, "Stephane Ducasse" 
escribió:

I love epicea :)
Did you see that now people use my extension to generate docs :)


no i didnt! how could i see that?


Stef

On Sat, Dec 16, 2017 at 9:03 AM, Stephane Ducasse
 wrote:
> Thanks Martin!!!
>
> On Wed, Dec 13, 2017 at 1:29 PM, Martin Dias  wrote:
>> Hi
>>
>> When you "save and close" or "save as..." then next changes will go to a
new
>> log file. Then, they will have a new item of the left of the browser (as
>> Stef said).
>> When you just "save", I agree I'd like that. It was there originally but
I
>> disabled it because of a bug related with the announcement. Apparently
now
>> it can be re-enabled:
>> https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving
>>
>> Martín
>>
>> On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse <
stepharo.s...@gmail.com>
>> wrote:
>>>
>>> Ok so we should check because it should not be complex to add that.
>>> The model is quite nice.
>>>
>>> On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman  wrote:
>>> > Hi Stef,
>>> >
>>> > I think that is incorrect. Its easy to be certain...
>>> > 1. Open Epicea
>>> > 2. Save and continue
>>> > 3. Open Epicea and observe there is no difference
>>> >
>>> > cheers -ben
>>> >
>>> >
>>> > On 13 December 2017 at 17:59, Stephane Ducasse <
stepharo.s...@gmail.com>
>>> > wrote:
>>> >>
>>> >> I think that epicea save point are the list elements on the left.
>>> >>
>>> >>
>>> >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl 
>>> >> wrote:
>>> >> > Same for me. I thought the last save point would be the last
session
>>> >> > in
>>> >> > the list but I don‘t think that is really true. So I‘m confused by
>>> >> > Epicea,
>>> >> > too.
>>> >> >
>>> >> > Norbert
>>> >> >
>>> >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman :
>>> >> >>
>>> >> >> When I'm in need Epicea, the common scenario is that I've working
in
>>> >> >> the same session of an Image most of the day, or even days, and
I've
>>> >> >> done
>>> >> >> something stupid to lock up the UI, and its only been an hour
since
>>> >> >> my last
>>> >> >> save point (force of habit).  When I review Epicea, "Filter > Show
>>> >> >> latest
>>> >> >> changes" its still ahrd to determine which changes I'm missing.
>>> >> >> What I've
>>> >> >> just realised is I miss the visibility of the Save Point in the
old
>>> >> >> changes
>>> >> >> system.  I'd find it really useful for the save points to be show
in
>>> >> >> the
>>> >> >> changes list, and also a filter I'd find really useful is "Shows
>>> >> >> latest
>>> >> >> changes since last save".
>>> >> >>
>>> >> >>
>>> >> >> cheers -ben
>>> >> >
>>> >>
>>> >
>>>
>>

Re: [Pharo-dev] Epicea feedback - save points

[Stephane Ducasse]

This is my bookHelpers on SmalltalkHub. I extended Epicea and we can
fileout changes into pillar or mardown.

On Sat, Dec 16, 2017 at 4:40 PM, Martin Dias  wrote:
>
>
> El 16 dic. 2017 5:04 AM, "Stephane Ducasse" 
> escribió:
>
> I love epicea :)
> Did you see that now people use my extension to generate docs :)
>
>
> no i didnt! how could i see that?
>
>
> Stef
>
> On Sat, Dec 16, 2017 at 9:03 AM, Stephane Ducasse
>  wrote:
>> Thanks Martin!!!
>>
>> On Wed, Dec 13, 2017 at 1:29 PM, Martin Dias  wrote:
>>> Hi
>>>
>>> When you "save and close" or "save as..." then next changes will go to a
>>> new
>>> log file. Then, they will have a new item of the left of the browser (as
>>> Stef said).
>>> When you just "save", I agree I'd like that. It was there originally but
>>> I
>>> disabled it because of a bug related with the announcement. Apparently
>>> now
>>> it can be re-enabled:
>>> https://pharo.fogbugz.com/f/cases/18754/Epicea-should-log-image-saving
>>>
>>> Martín
>>>
>>> On Wed, Dec 13, 2017 at 8:52 AM, Stephane Ducasse
>>> 
>>> wrote:

 Ok so we should check because it should not be complex to add that.
 The model is quite nice.

 On Wed, Dec 13, 2017 at 11:47 AM, Ben Coman  wrote:
 > Hi Stef,
 >
 > I think that is incorrect. Its easy to be certain...
 > 1. Open Epicea
 > 2. Save and continue
 > 3. Open Epicea and observe there is no difference
 >
 > cheers -ben
 >
 >
 > On 13 December 2017 at 17:59, Stephane Ducasse
 > 
 > wrote:
 >>
 >> I think that epicea save point are the list elements on the left.
 >>
 >>
 >> On Wed, Dec 13, 2017 at 9:05 AM, Norbert Hartl 
 >> wrote:
 >> > Same for me. I thought the last save point would be the last
 >> > session
 >> > in
 >> > the list but I don‘t think that is really true. So I‘m confused by
 >> > Epicea,
 >> > too.
 >> >
 >> > Norbert
 >> >
 >> >> Am 13.12.2017 um 08:27 schrieb Ben Coman :
 >> >>
 >> >> When I'm in need Epicea, the common scenario is that I've working
 >> >> in
 >> >> the same session of an Image most of the day, or even days, and
 >> >> I've
 >> >> done
 >> >> something stupid to lock up the UI, and its only been an hour
 >> >> since
 >> >> my last
 >> >> save point (force of habit).  When I review Epicea, "Filter > Show
 >> >> latest
 >> >> changes" its still ahrd to determine which changes I'm missing.
 >> >> What I've
 >> >> just realised is I miss the visibility of the Save Point in the
 >> >> old
 >> >> changes
 >> >> system.  I'd find it really useful for the save points to be show
 >> >> in
 >> >> the
 >> >> changes list, and also a filter I'd find really useful is "Shows
 >> >> latest
 >> >> changes since last save".
 >> >>
 >> >>
 >> >> cheers -ben
 >> >
 >>
 >

>>>
>
>

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

Hello Ben,

About discussion points in 2 (a, b and c): I agree with your arguments...
somebody that just moved from Pharo 5 to 6 and crashed an image will look
for a "Recover lost changes" in the menu and can have a problem to discover
it the replacement in a World->Tools->Epicea->... entry.

Then, as a first step we could flatten the 2 menu entries and then at least
anybody will easily find an entry related to changes in World->Tools.

Second, we could try to merge both Epicea GUIs into one (suggestions are
welcome).

I still have to read more in detail the remaining of your report to answer.
Anyway, thanks a lot for it.

Cheers,
Martin


On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:

> 1. Created fresh Pharo image (build 60269)
>
>
> 2. Opened World > Tools > Epicea > All changes
>
> Points for discussion...
>
>   a. How many submenu items are expected for Epicea? Can we push the
> current ones up so the Tools menu remains a flat menu.
>
>   b. Do we need the two current menu items?  "Current session" is
> encompassed by "All changes"?  What expectations do people have of how
> often they'll use the former rather than the latter?
>
>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
> "recover changes" for a crashed image, they'll be looking for that
> familiar feature name, not a new app name. Could the app name be left
> out or placed in brackets "Changes (Epicea)".
>
> btw, the interface looks really slick! nice work.
>
>
> 3. Opened World > System Browser.
>
> 4. Added package AAA
> All Changes window - no dynamic change.
> On , still no change, i.e. no sessions
> #New All Changes window - not visible, no sessions.
>
> 5. Added class AA.
> All Changes window - no dynamic change.
> On , shows new session with AAA & AA.
>
> 5. Added method...
> AA>a
>^'something'
> Prompted for author, entered 'BenComan'
> All Changes window with session selected - dynamic update showing AA>>a.
>
> 6. Added package BBB.
> All Changes window - no dynamic update.
> On , BBB still not visible in session.
>
> 7. Added class A to package AAA.
> All Changes window - dynamic update showing A.
> On , BBB still not visible in session.
>
> 8. Added class BB to package BBB.
> All Changes window - dynamic update showing BBB & BB.
>
>   a. Package creation event seems not handled properly, being only
> pushed through when a class is created in it.
>
>   b. Since there is a dynamic update for class and method
> modifications, could the session creation also dynamically update it
> UI.
>
> ---
> 9. Killed the vm from command line
> $ ps -ef | grep pharo
> $ kill 29349
>Restarted Pharo image
>
> 10. World > Tools > Epica > All changes.
> Authorship is inconsistent:
> * AAA and AA have blank author
> * AA>>a, A, BBB, B have author 'BenComan'.
>
>  a. I understand this follows on from Author not being requested until
> the first method was defined. Did the old changes track the author of
> packages and classes at all?
>
>  b. Since Epicea can track package and class authors, can we trigger
> the author prompt earlier for them?
>
> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
> and did .
> Prompted for author. Entered 'DrWho'
> Existing All Changes window - no change
> New All Changes window - shows new session with all six changes.
> Authorship is a little inconsistent:
> * AAA and AA have author 'Unknown'.
> * AA>>a, A, BBB, B have blank author.
>
> 12. Killed the vm from command line
> $ ps -ef | grep pharo
> $ kill 30696
>Restarted Pharo image
>
> 13. World > Tools > Epica > All changes.
> Authorship is a little inconsistent:
> First session
> * AAA and AA have blank author
> * AA>>a, A, BBB, B have author 'BenComan'.
> Second session
> * AAA and AA have blank author
> * AA>>a, A, BBB, B have author 'DrWho'.
>
>  a. Epicea changes are reapplied as the current author.  This seems a
> semantic change from Pharo 5 where changes were reapplied as their
> original author. Is this accidental or by design?  Can we have some
> community discussion on this point (I don't remember seeing any)?
>
> cheers -ben
>
> P.S. I'll wait to see what arises out of discussion before creating any
> issues.
>
>

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

Hi all,

One point of Ben's feedback is how Epicea code changes tool is presented in
the World Menu. Below you can see the current state + 3 options to discuss
it.


1. "Epicea" main entry > "Session Changes" + "All Changes" children
[current state]



2. Attach purpose to the name: "Epicea Code Changes"




3. Just "Code Changes" + rephrase children:

​
​

4. Flatten


​


Reminder: In World Menu > Help > Help Browser > Epicea you can find a
description of the tool and it's model.

Cheers.
Martin

On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:

> Hello Ben,
>
> About discussion points in 2 (a, b and c): I agree with your arguments...
> somebody that just moved from Pharo 5 to 6 and crashed an image will look
> for a "Recover lost changes" in the menu and can have a problem to discover
> it the replacement in a World->Tools->Epicea->... entry.
>
> Then, as a first step we could flatten the 2 menu entries and then at
> least anybody will easily find an entry related to changes in World->Tools.
>
> Second, we could try to merge both Epicea GUIs into one (suggestions are
> welcome).
>
> I still have to read more in detail the remaining of your report to
> answer. Anyway, thanks a lot for it.
>
> Cheers,
> Martin
>
>
> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
>
>> 1. Created fresh Pharo image (build 60269)
>>
>>
>> 2. Opened World > Tools > Epicea > All changes
>>
>> Points for discussion...
>>
>>   a. How many submenu items are expected for Epicea? Can we push the
>> current ones up so the Tools menu remains a flat menu.
>>
>>   b. Do we need the two current menu items?  "Current session" is
>> encompassed by "All changes"?  What expectations do people have of how
>> often they'll use the former rather than the latter?
>>
>>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
>> "recover changes" for a crashed image, they'll be looking for that
>> familiar feature name, not a new app name. Could the app name be left
>> out or placed in brackets "Changes (Epicea)".
>>
>> btw, the interface looks really slick! nice work.
>>
>>
>> 3. Opened World > System Browser.
>>
>> 4. Added package AAA
>> All Changes window - no dynamic change.
>> On , still no change, i.e. no sessions
>> #New All Changes window - not visible, no sessions.
>>
>> 5. Added class AA.
>> All Changes window - no dynamic change.
>> On , shows new session with AAA & AA.
>>
>> 5. Added method...
>> AA>a
>>^'something'
>> Prompted for author, entered 'BenComan'
>> All Changes window with session selected - dynamic update showing AA>>a.
>>
>> 6. Added package BBB.
>> All Changes window - no dynamic update.
>> On , BBB still not visible in session.
>>
>> 7. Added class A to package AAA.
>> All Changes window - dynamic update showing A.
>> On , BBB still not visible in session.
>>
>> 8. Added class BB to package BBB.
>> All Changes window - dynamic update showing BBB & BB.
>>
>>   a. Package creation event seems not handled properly, being only
>> pushed through when a class is created in it.
>>
>>   b. Since there is a dynamic update for class and method
>> modifications, could the session creation also dynamically update it
>> UI.
>>
>> ---
>> 9. Killed the vm from command line
>> $ ps -ef | grep pharo
>> $ kill 29349
>>Restarted Pharo image
>>
>> 10. World > Tools > Epica > All changes.
>> Authorship is inconsistent:
>> * AAA and AA have blank author
>> * AA>>a, A, BBB, B have author 'BenComan'.
>>
>>  a. I understand this follows on from Author not being requested until
>> the first method was defined. Did the old changes track the author of
>> packages and classes at all?
>>
>>  b. Since Epicea can track package and class authors, can we trigger
>> the author prompt earlier for them?
>>
>> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
>> and did .
>> Prompted for author. Entered 'DrWho'
>> Existing All Changes window - no change
>> New All Changes window - shows new session with all six changes.
>> Authorship is a little inconsistent:
>> * AAA and AA have author 'Unknown'.
>> * AA>>a, A, BBB, B have blank author.
>>
>> 12. Killed the vm from command line
>> $ ps -ef | grep pharo
>> $ kill 30696
>>Restarted Pharo image
>>
>> 13. World > Tools > Epica > All changes.
>> Authorship is a little inconsistent:
>> First session
>> * AAA and AA have blank author
>> * AA>>a, A, BBB, B have author 'BenComan'.
>> Second session
>> * AAA and AA have blank author
>> * AA>>a, A, BBB, B have author 'DrWho'.
>>
>>  a. Epicea changes are reapplied as the current author.  This seems a
>> semantic change from Pharo 5 where changes were reapplied as their
>> original author. Is this accidental or by design?  Can we have some
>> community discussion on this point (I don't remember seeing any)?
>>
>> cheers -ben
>>
>> P.S. I'll wait to see what arises out of discussion before creating any
>> issues.
>>
>>
>

Re: [Pharo-dev] Epicea user experience report

[Marcus Denker]

> 
> 
> 3. Just "Code Changes" + rephrase children:
> 
> ​
> ​
> 

I like that most. It is the easiest to understand for newcomers.

Marcus

Re: [Pharo-dev] Epicea user experience report

[Sean P. DeNigris]

Marcus Denker-4 wrote
>> 3. Just "Code Changes" + rephrase children:
> I like that most. It is the easiest to understand for newcomers.

+1



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/Epicea-user-experience-report-tp4920653p4927604.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Epicea user experience report

[stepharong]

I like the second because it associates the name with the function.

Stef



Hi all,

One point of Ben's feedback is how Epicea code changes tool is presented  
in the World Menu. Below you can see the current state + 3 options to  
discuss it.



1. "Epicea" main entry > "Session Changes" + "All Changes" children  
[current state]





2. Attach purpose to the name: "Epicea Code Changes"




3. Just "Code Changes" + rephrase children:

​
​

4. Flatten


​


Reminder: In World Menu > Help > Help Browser > Epicea you can find a  
description of the tool and it's model.


Cheers.
Martin

On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias   
wrote:

Hello Ben,

About discussion points in 2 (a, b and c): I agree with your  
arguments... somebody that just moved from Pharo 5 to 6 and crashed an  
image will look for a "Recover lost changes" in the menu >>and can have  
a problem to discover it the replacement in a World->Tools->Epicea->...  
entry.


Then, as a first step we could flatten the 2 menu entries and then at  
least anybody will easily find an entry related to changes in  
World->Tools.
Second, we could try to merge both Epicea GUIs into one (suggestions  
are welcome).


I still have to read more in detail the remaining of your report to  
answer. Anyway, thanks a lot for it.


Cheers,
Martin


On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:

1. Created fresh Pharo image (build 60269)


2. Opened World > Tools > Epicea > All changes

Points for discussion...

 a. How many submenu items are expected for Epicea? Can we push the
current ones up so the Tools menu remains a flat menu.

 b. Do we need the two current menu items?  "Current session" is
encompassed by "All changes"?  What expectations do people have of how
often they'll use the former rather than the latter?

 c. When people move from Pharo 5 to Pharo 6 and in a panic want to
"recover changes" for a crashed image, they'll be looking for that
familiar feature name, not a new app name. Could the app name be left
out or placed in brackets "Changes (Epicea)".

btw, the interface looks really slick! nice work.


3. Opened World > System Browser.

4. Added package AAA
All Changes window - no dynamic change.
On , still no change, i.e. no sessions
#New All Changes window - not visible, no sessions.

5. Added class AA.
All Changes window - no dynamic change.
On , shows new session with AAA & AA.

5. Added method...
   AA>a
  ^'something'
Prompted for author, entered 'BenComan'
All Changes window with session selected - dynamic update showing  
AA>>a.


6. Added package BBB.
All Changes window - no dynamic update.
On , BBB still not visible in session.

7. Added class A to package AAA.
All Changes window - dynamic update showing A.
On , BBB still not visible in session.

8. Added class BB to package BBB.
All Changes window - dynamic update showing BBB & BB.

 a. Package creation event seems not handled properly, being only
pushed through when a class is created in it.

 b. Since there is a dynamic update for class and method
modifications, could the session creation also dynamically update it
UI.

---
9. Killed the vm from command line
   $ ps -ef | grep pharo
   $ kill 29349
  Restarted Pharo image

10. World > Tools > Epica > All changes.
Authorship is inconsistent:
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'BenComan'.

a. I understand this follows on from Author not being requested until
the first method was defined. Did the old changes track the author of
packages and classes at all?

b. Since Epicea can track package and class authors, can we trigger
the author prompt earlier for them?

11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
and did .
Prompted for author. Entered 'DrWho'
Existing All Changes window - no change
New All Changes window - shows new session with all six changes.
Authorship is a little inconsistent:
* AAA and AA have author 'Unknown'.
* AA>>a, A, BBB, B have blank author.

12. Killed the vm from command line
   $ ps -ef | grep pharo
   $ kill 30696
  Restarted Pharo image

13. World > Tools > Epica > All changes.
Authorship is a little inconsistent:
First session
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'BenComan'.
Second session
* AAA and AA have blank author
* AA>>a, A, BBB, B have author 'DrWho'.

a. Epicea changes are reapplied as the current author.  This seems a
semantic change from Pharo 5 where changes were reapplied as their
original author. Is this accidental or by design?  Can we have some
community discussion on this point (I don't remember seeing any)?

cheers -ben

P.S. I'll wait to see what arises out of discussion before creating  
any issues.










--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Epicea user experience report

[Tudor Girba]

Hi,

I think I would prefer to not have to think about this choice at all when in 
the world menu level. The user interface from the Epicea window already allows 
me to switch between current session and all sessions, and usually the decision 
of what to look at is based on whether I find what I am looking for or not. So, 
rather then asking the user to think about it upfront, I would prefer to have 
one command that opens the Epicea window on the current session and allow the 
user to dive deeper. This would also imply that we would have only one command 
in the menu item. What do you think?

Cheers,
Doru


> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
> 
> I like the second because it associates the name with the function. 
> 
> Stef
>  
>  
> Hi all,
> 
> One point of Ben's feedback is how Epicea code changes tool is presented in 
> the World Menu. Below you can see the current state + 3 options to discuss it.
> 
> 
> 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current 
> state]
> 
> 
> 
> 
> 2. Attach purpose to the name: "Epicea Code Changes"
> 
> 
> 
> 
> 3. Just "Code Changes" + rephrase children:
> 
> ​
> ​
> 
> 4. Flatten
> 
> 
> ​
> 
> 
> Reminder: In World Menu > Help > Help Browser > Epicea you can find a 
> description of the tool and it's model.
> 
> Cheers.
> Martin
> 
> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:
> Hello Ben,
> 
> About discussion points in 2 (a, b and c): I agree with your arguments... 
> somebody that just moved from Pharo 5 to 6 and crashed an image will look for 
> a "Recover lost changes" in the menu and can have a problem to discover it 
> the replacement in a World->Tools->Epicea->... entry.
> 
> Then, as a first step we could flatten the 2 menu entries and then at least 
> anybody will easily find an entry related to changes in World->Tools. 
> 
> Second, we could try to merge both Epicea GUIs into one (suggestions are 
> welcome).
> 
> I still have to read more in detail the remaining of your report to answer. 
> Anyway, thanks a lot for it.
> 
> Cheers,
> Martin
> 
> 
> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
> 1. Created fresh Pharo image (build 60269)
> 
> 
> 2. Opened World > Tools > Epicea > All changes
> 
> Points for discussion...
> 
>   a. How many submenu items are expected for Epicea? Can we push the
> current ones up so the Tools menu remains a flat menu.
> 
>   b. Do we need the two current menu items?  "Current session" is
> encompassed by "All changes"?  What expectations do people have of how
> often they'll use the former rather than the latter?
> 
>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
> "recover changes" for a crashed image, they'll be looking for that
> familiar feature name, not a new app name. Could the app name be left
> out or placed in brackets "Changes (Epicea)".
> 
> btw, the interface looks really slick! nice work.
> 
> 
> 3. Opened World > System Browser.
> 
> 4. Added package AAA
> All Changes window - no dynamic change.
> On , still no change, i.e. no sessions
> #New All Changes window - not visible, no sessions.
> 
> 5. Added class AA.
> All Changes window - no dynamic change.
> On , shows new session with AAA & AA.
> 
> 5. Added method...
> AA>a
>^'something'
> Prompted for author, entered 'BenComan'
> All Changes window with session selected - dynamic update showing AA>>a.
> 
> 6. Added package BBB.
> All Changes window - no dynamic update.
> On , BBB still not visible in session.
> 
> 7. Added class A to package AAA.
> All Changes window - dynamic update showing A.
> On , BBB still not visible in session.
> 
> 8. Added class BB to package BBB.
> All Changes window - dynamic update showing BBB & BB.
> 
>   a. Package creation event seems not handled properly, being only
> pushed through when a class is created in it.
> 
>   b. Since there is a dynamic update for class and method
> modifications, could the session creation also dynamically update it
> UI.
> 
> ---
> 9. Killed the vm from command line
> $ ps -ef | grep pharo
> $ kill 29349
>Restarted Pharo image
> 
> 10. World > Tools > Epica > All changes.
> Authorship is inconsistent:
> * AAA and AA have blank author
> * AA>>a, A, BBB, B have author 'BenComan'.
> 
>  a. I understand this follows on from Author not being requested until
> the first method was defined. Did the old changes track the author of
> packages and classes at all?
> 
>  b. Since Epicea can track package and class authors, can we trigger
> the author prompt earlier for them?
> 
> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
> and did .
> Prompted for author. Entered 'DrWho'
> Existing All Changes window - no change
> New All Changes window - shows new session with all six changes.
> Authorship is a little inconsistent:
> * AAA and AA have author 'Unknown'.
> * AA>>a, A, BBB, B have blank author.
> 
> 12. Killed the vm from command line
> $ ps -ef | grep pharo
> $ kill 30696
>

Re: [Pharo-dev] Epicea user experience report

[Norbert Hartl]

I don't like the extra menu. I think going three levels in a menu should only 
be done for thing used rarely. Feels awkward very time.
Do we have three cases wirh epicea? 

- this session meaning all changed since start of the image?
- last session/aborted session the last session that did not finished because 
of unexpected image stop. This should open automatically which does not work in 
current pharo6
- all other sessions

In this situation when the aborted session opens automatically it means I 
deliberately open epicea through the menu for other reasons. In this case I'm 
with Doru that it should be a single menu entry which opens epicea and someone 
can choose there what to see. In case of list display this session will be the 
top most entry anyway so it can be discussed if it is important to separate 
this session and the others really. 

Norbert

> Am 20.12.2016 um 17:17 schrieb Martin Dias :
> 
> Hi all,
> 
> One point of Ben's feedback is how Epicea code changes tool is presented in 
> the World Menu. Below you can see the current state + 3 options to discuss it.
> 
> 
> 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current 
> state]
> 
> 
> 
> 
> 2. Attach purpose to the name: "Epicea Code Changes"
> 
> 
> 
> 
> 3. Just "Code Changes" + rephrase children:
> 
> ​
> ​
> 
> 4. Flatten
> 
> 
> ​
> 
> 
> Reminder: In World Menu > Help > Help Browser > Epicea you can find a 
> description of the tool and it's model.
> 
> Cheers.
> Martin
> 
>> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:
>> Hello Ben,
>> 
>> About discussion points in 2 (a, b and c): I agree with your arguments... 
>> somebody that just moved from Pharo 5 to 6 and crashed an image will look 
>> for a "Recover lost changes" in the menu and can have a problem to discover 
>> it the replacement in a World->Tools->Epicea->... entry.
>> 
>> Then, as a first step we could flatten the 2 menu entries and then at least 
>> anybody will easily find an entry related to changes in World->Tools. 
>> 
>> Second, we could try to merge both Epicea GUIs into one (suggestions are 
>> welcome).
>> 
>> I still have to read more in detail the remaining of your report to answer. 
>> Anyway, thanks a lot for it.
>> 
>> Cheers,
>> Martin
>> 
>> 
>>> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
>>> 1. Created fresh Pharo image (build 60269)
>>> 
>>> 
>>> 2. Opened World > Tools > Epicea > All changes
>>> 
>>> Points for discussion...
>>> 
>>>   a. How many submenu items are expected for Epicea? Can we push the
>>> current ones up so the Tools menu remains a flat menu.
>>> 
>>>   b. Do we need the two current menu items?  "Current session" is
>>> encompassed by "All changes"?  What expectations do people have of how
>>> often they'll use the former rather than the latter?
>>> 
>>>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
>>> "recover changes" for a crashed image, they'll be looking for that
>>> familiar feature name, not a new app name. Could the app name be left
>>> out or placed in brackets "Changes (Epicea)".
>>> 
>>> btw, the interface looks really slick! nice work.
>>> 
>>> 
>>> 3. Opened World > System Browser.
>>> 
>>> 4. Added package AAA
>>> All Changes window - no dynamic change.
>>> On , still no change, i.e. no sessions
>>> #New All Changes window - not visible, no sessions.
>>> 
>>> 5. Added class AA.
>>> All Changes window - no dynamic change.
>>> On , shows new session with AAA & AA.
>>> 
>>> 5. Added method...
>>> AA>a
>>>^'something'
>>> Prompted for author, entered 'BenComan'
>>> All Changes window with session selected - dynamic update showing AA>>a.
>>> 
>>> 6. Added package BBB.
>>> All Changes window - no dynamic update.
>>> On , BBB still not visible in session.
>>> 
>>> 7. Added class A to package AAA.
>>> All Changes window - dynamic update showing A.
>>> On , BBB still not visible in session.
>>> 
>>> 8. Added class BB to package BBB.
>>> All Changes window - dynamic update showing BBB & BB.
>>> 
>>>   a. Package creation event seems not handled properly, being only
>>> pushed through when a class is created in it.
>>> 
>>>   b. Since there is a dynamic update for class and method
>>> modifications, could the session creation also dynamically update it
>>> UI.
>>> 
>>> ---
>>> 9. Killed the vm from command line
>>> $ ps -ef | grep pharo
>>> $ kill 29349
>>>Restarted Pharo image
>>> 
>>> 10. World > Tools > Epica > All changes.
>>> Authorship is inconsistent:
>>> * AAA and AA have blank author
>>> * AA>>a, A, BBB, B have author 'BenComan'.
>>> 
>>>  a. I understand this follows on from Author not being requested until
>>> the first method was defined. Did the old changes track the author of
>>> packages and classes at all?
>>> 
>>>  b. Since Epicea can track package and class authors, can we trigger
>>> the author prompt earlier for them?
>>> 
>>> 11. Selected all previous changes AAA, AA, AA>>a, A, BBB, BB
>>> and did .
>>> Prompted for 

Re: [Pharo-dev] Epicea user experience report

[Denis Kudriashov]

2016-12-21 8:03 GMT+01:00 Tudor Girba :

> Hi,
>
> I think I would prefer to not have to think about this choice at all when
> in the world menu level. The user interface from the Epicea window already
> allows me to switch between current session and all sessions, and usually
> the decision of what to look at is based on whether I find what I am
> looking for or not. So, rather then asking the user to think about it
> upfront, I would prefer to have one command that opens the Epicea window on
> the current session and allow the user to dive deeper. This would also
> imply that we would have only one command in the menu item. What do you
> think?
>

+1

Re: [Pharo-dev] Epicea user experience report

[Ben Coman]

On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba  wrote:
> Hi,
>
> I think I would prefer to not have to think about this choice at all when in 
> the world menu level. The user interface from the Epicea window already 
> allows me to switch between current session and all sessions, and usually the 
> decision of what to look at is based on whether I find what I am looking for 
> or not. So, rather then asking the user to think about it upfront, I would 
> prefer to have one command that opens the Epicea window on the current 
> session and allow the user to dive deeper. This would also imply that we 
> would have only one command in the menu item. What do you think?

Good point. I had a similar thought earlier.  The individual Session
Changes window is almost completely embedded in the All Sessions
window, so the former seems superfluous. The  and <+> buttons
would need to be added to the All Sessions window, probably above the
"sesssion" pane.

Two additional things I think are required to facilitate this...
1. The left-pane of the All Sessions windows needs to update when a
new session is created - per <+> button.
2. It would be useful if a new session was created "when the image
opened" rather than when a change is made, so that it can be
preselected in the left-side pane when a fresh image is opened.  But
the file shouldn't be created until the first change, for the case
like a web service image being invoked multiple times a second.

Also one other request, That the current-session be tagged "Current"
rather than just "Today".

I can log issues if they all sound reasonable.

cheers -ben

>
>> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
>>
>> I like the second because it associates the name with the function.
>>
>> Stef
>>
>>
>> Hi all,
>>
>> One point of Ben's feedback is how Epicea code changes tool is presented in 
>> the World Menu. Below you can see the current state + 3 options to discuss 
>> it.
>>
>>
>> 1. "Epicea" main entry > "Session Changes" + "All Changes" children [current 
>> state]
>>
>> 
>>
>>
>> 2. Attach purpose to the name: "Epicea Code Changes"
>>
>> 
>>
>>
>> 3. Just "Code Changes" + rephrase children:
>>
>> 
>>
>>
>> 4. Flatten
>>
>> 
>>
>>
>>
>> Reminder: In World Menu > Help > Help Browser > Epicea you can find a 
>> description of the tool and it's model.
>>
>> Cheers.
>> Martin
>>
>> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:
>> Hello Ben,
>>
>> About discussion points in 2 (a, b and c): I agree with your arguments... 
>> somebody that just moved from Pharo 5 to 6 and crashed an image will look 
>> for a "Recover lost changes" in the menu and can have a problem to discover 
>> it the replacement in a World->Tools->Epicea->... entry.
>>
>> Then, as a first step we could flatten the 2 menu entries and then at least 
>> anybody will easily find an entry related to changes in World->Tools.
>>
>> Second, we could try to merge both Epicea GUIs into one (suggestions are 
>> welcome).
>>
>> I still have to read more in detail the remaining of your report to answer. 
>> Anyway, thanks a lot for it.
>>
>> Cheers,
>> Martin
>>
>>
>> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
>> 1. Created fresh Pharo image (build 60269)
>>
>>
>> 2. Opened World > Tools > Epicea > All changes
>>
>> Points for discussion...
>>
>>   a. How many submenu items are expected for Epicea? Can we push the
>> current ones up so the Tools menu remains a flat menu.
>>
>>   b. Do we need the two current menu items?  "Current session" is
>> encompassed by "All changes"?  What expectations do people have of how
>> often they'll use the former rather than the latter?
>>
>>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
>> "recover changes" for a crashed image, they'll be looking for that
>> familiar feature name, not a new app name. Could the app name be left
>> out or placed in brackets "Changes (Epicea)".
>>
>> btw, the interface looks really slick! nice work.
>>
>>
>> 3. Opened World > System Browser.
>>
>> 4. Added package AAA
>> All Changes window - no dynamic change.
>> On , still no change, i.e. no sessions
>> #New All Changes window - not visible, no sessions.
>>
>> 5. Added class AA.
>> All Changes window - no dynamic change.
>> On , shows new session with AAA & AA.
>>
>> 5. Added method...
>> AA>a
>>^'something'
>> Prompted for author, entered 'BenComan'
>> All Changes window with session selected - dynamic update showing AA>>a.
>>
>> 6. Added package BBB.
>> All Changes window - no dynamic update.
>> On , BBB still not visible in session.
>>
>> 7. Added class A to package AAA.
>> All Changes window - dynamic update showing A.
>> On , BBB still not visible in session.
>>
>> 8. Added class BB to package BBB.
>> All Changes window - dynamic update showing BBB & BB.
>>
>>   a. Package creation event seems not handled properly, being only
>> pushed through when a class is created in it.
>>
>>   b. Since there is a dynamic update for class and method
>> modifica

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

Ben, yes, please create the issues if you want, and I will try to implement
them soon. I guess if they are mostly UI changes and categorized to "first
impression count" or something like that, they can still be included in
Pharo 6, no?

One thing to discuss: what do you think about the fact that...
- the "Session changes" displays the changes of multiple log files in the
same list widget (silently concatenated), versus
- the "All changes" way of displaying, where the changes of each log file
are separated.

That was my main reason to keep two windows by separate. I had the
impression that in some cases
- the user wants to see all changes together and he/she doesn't care in
which log file the changes are written, while in other cases
- the user wants to know the log files and see how are they connected,
because they have some meaning
What do you think of this?
BTW I don't like the file names... hints are welcome to improve it

Martin

On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:

> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba  wrote:
> > Hi,
> >
> > I think I would prefer to not have to think about this choice at all
> when in the world menu level. The user interface from the Epicea window
> already allows me to switch between current session and all sessions, and
> usually the decision of what to look at is based on whether I find what I
> am looking for or not. So, rather then asking the user to think about it
> upfront, I would prefer to have one command that opens the Epicea window on
> the current session and allow the user to dive deeper. This would also
> imply that we would have only one command in the menu item. What do you
> think?
>
> Good point. I had a similar thought earlier.  The individual Session
> Changes window is almost completely embedded in the All Sessions
> window, so the former seems superfluous. The  and <+> buttons
> would need to be added to the All Sessions window, probably above the
> "sesssion" pane.


> Two additional things I think are required to facilitate this...
> 1. The left-pane of the All Sessions windows needs to update when a
> new session is created - per <+> button.
> 2. It would be useful if a new session was created "when the image
> opened" rather than when a change is made, so that it can be
> preselected in the left-side pane when a fresh image is opened.  But
> the file shouldn't be created until the first change, for the case
> like a web service image being invoked multiple times a second.
>
> Also one other request, That the current-session be tagged "Current"
> rather than just "Today".
>
> I can log issues if they all sound reasonable.
>
> cheers -ben
>
> >
> >> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
> >>
> >> I like the second because it associates the name with the function.
> >>
> >> Stef
> >>
> >>
> >> Hi all,
> >>
> >> One point of Ben's feedback is how Epicea code changes tool is
> presented in the World Menu. Below you can see the current state + 3
> options to discuss it.
> >>
> >>
> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children
> [current state]
> >>
> >> 
> >>
> >>
> >> 2. Attach purpose to the name: "Epicea Code Changes"
> >>
> >> 
> >>
> >>
> >> 3. Just "Code Changes" + rephrase children:
> >>
> >> 
> >>
> >>
> >> 4. Flatten
> >>
> >> 
> >>
> >>
> >>
> >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a
> description of the tool and it's model.
> >>
> >> Cheers.
> >> Martin
> >>
> >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias 
> wrote:
> >> Hello Ben,
> >>
> >> About discussion points in 2 (a, b and c): I agree with your
> arguments... somebody that just moved from Pharo 5 to 6 and crashed an
> image will look for a "Recover lost changes" in the menu and can have a
> problem to discover it the replacement in a World->Tools->Epicea->... entry.
> >>
> >> Then, as a first step we could flatten the 2 menu entries and then at
> least anybody will easily find an entry related to changes in World->Tools.
> >>
> >> Second, we could try to merge both Epicea GUIs into one (suggestions
> are welcome).
> >>
> >> I still have to read more in detail the remaining of your report to
> answer. Anyway, thanks a lot for it.
> >>
> >> Cheers,
> >> Martin
> >>
> >>
> >> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
> >> 1. Created fresh Pharo image (build 60269)
> >>
> >>
> >> 2. Opened World > Tools > Epicea > All changes
> >>
> >> Points for discussion...
> >>
> >>   a. How many submenu items are expected for Epicea? Can we push the
> >> current ones up so the Tools menu remains a flat menu.
> >>
> >>   b. Do we need the two current menu items?  "Current session" is
> >> encompassed by "All changes"?  What expectations do people have of how
> >> often they'll use the former rather than the latter?
> >>
> >>   c. When people move from Pharo 5 to Pharo 6 and in a panic want to
> >> "recover changes" for a crashed image, they'll be looking for that
> >> familiar feature name, not a new app name.

Re: [Pharo-dev] Epicea user experience report

[Ben Coman]

On Sat, Dec 24, 2016 at 2:46 AM, Martin Dias  wrote:
> Ben, yes, please create the issues if you want, and I will try to implement
> them soon. I guess if they are mostly UI changes and categorized to "first
> impression count" or something like that, they can still be included in
> Pharo 6, no?
>
> One thing to discuss: what do you think about the fact that...
> - the "Session changes" displays the changes of multiple log files in the
> same list widget (silently concatenated), versus

Well the biggest thing is probably that I did not realise it did this.
So this is a problem for intuitive use of the tool. Actually it seems
adverse to show multiple sessions where "Session Changes" implies
"This Session".


> - the "All changes" way of displaying, where the changes of each log file
> are separated.
>
> That was my main reason to keep two windows by separate. I had the
> impression that in some cases
> - the user wants to see all changes together and he/she doesn't care in
> which log file the changes are written, while in other cases
> - the user wants to know the log files and see how are they connected,
> because they have some meaning
> What do you think of this?

You are right, that is useful feature. But I keep "intuitively
wanting**" to do this is to multi-select sessions in the "All changes"
window.

My use case is yesterday playing with sockets, the image froze half
way through saving (hung at blank white window).  So after killing the
pharo process, the Image would not open. So before recreating the
Image in PharoLauncher, I copied the ombu-sessions folder and copied
into a fresh Image folder and selected each session in turn.  (So btw
that was a nice benefit of epicea versus the changes file needing to
be kept more in sync with image file.)  I only had half a dozen
sessions so it wasn't too much trouble.  But potentially there could
be a lot more sessions and being able to do them all at once would be
useful.

** i.e. I didn't learn the first time I tried this and it didn't work,
and found I accidentally tried doing it a few more times after that.


> BTW I don't like the file names... hints are welcome to improve it

Which file names do you mean?

cheers -ben


>
> Martin
>
> On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:
>>
>> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba  wrote:
>> > Hi,
>> >
>> > I think I would prefer to not have to think about this choice at all
>> > when in the world menu level. The user interface from the Epicea window
>> > already allows me to switch between current session and all sessions, and
>> > usually the decision of what to look at is based on whether I find what I 
>> > am
>> > looking for or not. So, rather then asking the user to think about it
>> > upfront, I would prefer to have one command that opens the Epicea window on
>> > the current session and allow the user to dive deeper. This would also 
>> > imply
>> > that we would have only one command in the menu item. What do you think?
>>
>> Good point. I had a similar thought earlier.  The individual Session
>> Changes window is almost completely embedded in the All Sessions
>> window, so the former seems superfluous. The  and <+> buttons
>> would need to be added to the All Sessions window, probably above the
>> "sesssion" pane.
>>
>>
>> Two additional things I think are required to facilitate this...
>> 1. The left-pane of the All Sessions windows needs to update when a
>> new session is created - per <+> button.
>> 2. It would be useful if a new session was created "when the image
>> opened" rather than when a change is made, so that it can be
>> preselected in the left-side pane when a fresh image is opened.  But
>> the file shouldn't be created until the first change, for the case
>> like a web service image being invoked multiple times a second.
>>
>> Also one other request, That the current-session be tagged "Current"
>> rather than just "Today".
>>
>> I can log issues if they all sound reasonable.
>>
>> cheers -ben
>>
>> >
>> >> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
>> >>
>> >> I like the second because it associates the name with the function.
>> >>
>> >> Stef
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> One point of Ben's feedback is how Epicea code changes tool is
>> >> presented in the World Menu. Below you can see the current state + 3 
>> >> options
>> >> to discuss it.
>> >>
>> >>
>> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children
>> >> [current state]
>> >>
>> >> 
>> >>
>> >>
>> >> 2. Attach purpose to the name: "Epicea Code Changes"
>> >>
>> >> 
>> >>
>> >>
>> >> 3. Just "Code Changes" + rephrase children:
>> >>
>> >> 
>> >>
>> >>
>> >> 4. Flatten
>> >>
>> >> 
>> >>
>> >>
>> >>
>> >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a
>> >> description of the tool and it's model.
>> >>
>> >> Cheers.
>> >> Martin
>> >>
>> >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias 
>> >> wrote:
>> >> Hello Ben,
>> >>
>> >> About discussion points in 2 (a, b

Re: [Pharo-dev] Epicea user experience report

[stepharong]

On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias   
wrote:


Ben, yes, please create the issues if you want, and I will try to  
implement them soon. I guess if they are mostly UI changes and  
categorized to "first impression count" or something like that, they  
>can still be included in Pharo 6, no?


yes



One thing to discuss: what do you think about the fact that...- the  
"Session changes" displays the changes of multiple log files in the same  
list widget (silently concatenated), versus- the "All changes" way of  
displaying, where the changes of each log file are separated.
That was my main reason to keep two windows by separate. I had the  
impression that in some cases- the user wants to see all changes  
together and he/she doesn't care in which log file the changes are  
written, while in other cases
- the user wants to know the log files and see how are they connected,  
because they have some meaning

What do you think of this?
BTW I don't like the file names... hints are welcome to improve it

Martin

On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:
On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba   
wrote:

Hi,

I think I would prefer to not have to think about this choice at all  
when in the world menu level. The user interface from the Epicea  
window already allows me to switch between current >>session and all  
sessions, and usually the decision of what to look at is based on  
whether I find what I am looking for or not. So, rather then asking  
the user to think about it upfront, I would >>prefer to have one  
command that opens the Epicea window on the current session and allow  
the user to dive deeper. This would also imply that we would have only  
one command in the >>menu item. What do you think?


Good point. I had a similar thought earlier.  The individual Session
Changes window is almost completely embedded in the All Sessions
window, so the former seems superfluous. The  and <+> buttons
would need to be added to the All Sessions window, probably above the
"sesssion" pane.

Two additional things I think are required to facilitate this...
1. The left-pane of the All Sessions windows needs to update when a
new session is created - per <+> button.
2. It would be useful if a new session was created "when the image
opened" rather than when a change is made, so that it can be
preselected in the left-side pane when a fresh image is opened.  But
the file shouldn't be created until the first change, for the case
like a web service image being invoked multiple times a second.

Also one other request, That the current-session be tagged "Current"
rather than just "Today".

I can log issues if they all sound reasonable.

cheers -ben




On Dec 20, 2016, at 10:16 PM, stepharong  wrote:

I like the second because it associates the name with the function.

Stef


Hi all,

One point of Ben's feedback is how Epicea code changes tool is  
presented in the World Menu. Below you can see the current state + 3  
options to discuss it.



1. "Epicea" main entry > "Session Changes" + "All Changes" children  
[current state]





2. Attach purpose to the name: "Epicea Code Changes"




3. Just "Code Changes" + rephrase children:




4. Flatten





Reminder: In World Menu > Help > Help Browser > Epicea you can find a  
description of the tool and it's model.


Cheers.
Martin

On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias   
wrote:

Hello Ben,

About discussion points in 2 (a, b and c): I agree with your  
arguments... somebody that just moved from Pharo 5 to 6 and crashed  
an image will look for a "Recover lost changes" in the >>menu and can  
have a problem to discover it the replacement in a  
World->Tools->Epicea->... entry.


Then, as a first step we could flatten the 2 menu entries and then at  
least anybody will easily find an entry related to changes in  
World->Tools.


Second, we could try to merge both Epicea GUIs into one (suggestions  
are welcome).


I still have to read more in detail the remaining of your report to  
answer. Anyway, thanks a lot for it.


Cheers,
Martin


On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman   
wrote:

1. Created fresh Pharo image (build 60269)


2. Opened World > Tools > Epicea > All changes

Points for discussion...

  a. How many submenu items are expected for Epicea? Can we push the
current ones up so the Tools menu remains a flat menu.

  b. Do we need the two current menu items?  "Current session" is
encompassed by "All changes"?  What expectations do people have of how
often they'll use the former rather than the latter?

  c. When people move from Pharo 5 to Pharo 6 and in a panic want to
"recover changes" for a crashed image, they'll be looking for that
familiar feature name, not a new app name. Could the app name be left
out or placed in brackets "Changes (Epicea)".

btw, the interface looks really slick! nice work.


3. Opened World > System Browser.

4. Added package AAA
All Changes window - no dynamic change.
On , still no change, i.e. no sessions

Re: [Pharo-dev] Epicea user experience report

[serge . stinckwich]

I prefer option 2 because Epicea name is not really important and means nothing 
for the beginner. What is really important in then world menu is the function.

Envoyé de mon iPhone

> Le 24 déc. 2016 à 09:35, stepharong  a écrit :
> 
> On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias  wrote:
> 
> Ben, yes, please create the issues if you want, and I will try to implement 
> them soon. I guess if they are mostly UI changes and categorized to "first 
> impression count" or something like that, they can still be included in Pharo 
> 6, no?
> 
> yes
> 
> 
> One thing to discuss: what do you think about the fact that... 
> - the "Session changes" displays the changes of multiple log files in the 
> same list widget (silently concatenated), versus 
> - the "All changes" way of displaying, where the changes of each log file are 
> separated.
>  
> That was my main reason to keep two windows by separate. I had the impression 
> that in some cases 
> - the user wants to see all changes together and he/she doesn't care in which 
> log file the changes are written, while in other cases
> - the user wants to know the log files and see how are they connected, 
> because they have some meaning
> What do you think of this?
> BTW I don't like the file names... hints are welcome to improve it
> 
> Martin
> 
>> On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:
>> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba  wrote:
>> > Hi,
>> >
>> > I think I would prefer to not have to think about this choice at all when 
>> > in the world menu level. The user interface from the Epicea window already 
>> > allows me to switch between current session and all sessions, and usually 
>> > the decision of what to look at is based on whether I find what I am 
>> > looking for or not. So, rather then asking the user to think about it 
>> > upfront, I would prefer to have one command that opens the Epicea window 
>> > on the current session and allow the user to dive deeper. This would also 
>> > imply that we would have only one command in the menu item. What do you 
>> > think?
>> 
>> Good point. I had a similar thought earlier.  The individual Session
>> Changes window is almost completely embedded in the All Sessions
>> window, so the former seems superfluous. The  and <+> buttons
>> would need to be added to the All Sessions window, probably above the
>> "sesssion" pane.
>> 
>> Two additional things I think are required to facilitate this...
>> 1. The left-pane of the All Sessions windows needs to update when a
>> new session is created - per <+> button.
>> 2. It would be useful if a new session was created "when the image
>> opened" rather than when a change is made, so that it can be
>> preselected in the left-side pane when a fresh image is opened.  But
>> the file shouldn't be created until the first change, for the case
>> like a web service image being invoked multiple times a second.
>> 
>> Also one other request, That the current-session be tagged "Current"
>> rather than just "Today".
>> 
>> I can log issues if they all sound reasonable.
>> 
>> cheers -ben
>> 
>> >
>> >> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
>> >>
>> >> I like the second because it associates the name with the function.
>> >>
>> >> Stef
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> One point of Ben's feedback is how Epicea code changes tool is presented 
>> >> in the World Menu. Below you can see the current state + 3 options to 
>> >> discuss it.
>> >>
>> >>
>> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children 
>> >> [current state]
>> >>
>> >> 
>> >>
>> >>
>> >> 2. Attach purpose to the name: "Epicea Code Changes"
>> >>
>> >> 
>> >>
>> >>
>> >> 3. Just "Code Changes" + rephrase children:
>> >>
>> >> 
>> >>
>> >>
>> >> 4. Flatten
>> >>
>> >> 
>> >>
>> >>
>> >>
>> >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a 
>> >> description of the tool and it's model.
>> >>
>> >> Cheers.
>> >> Martin
>> >>
>> >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  wrote:
>> >> Hello Ben,
>> >>
>> >> About discussion points in 2 (a, b and c): I agree with your arguments... 
>> >> somebody that just moved from Pharo 5 to 6 and crashed an image will look 
>> >> for a "Recover lost changes" in the menu and can have a problem to 
>> >> discover it the replacement in a World->Tools->Epicea->... entry.
>> >>
>> >> Then, as a first step we could flatten the 2 menu entries and then at 
>> >> least anybody will easily find an entry related to changes in 
>> >> World->Tools.
>> >>
>> >> Second, we could try to merge both Epicea GUIs into one (suggestions are 
>> >> welcome).
>> >>
>> >> I still have to read more in detail the remaining of your report to 
>> >> answer. Anyway, thanks a lot for it.
>> >>
>> >> Cheers,
>> >> Martin
>> >>
>> >>
>> >> On Sat, Oct 29, 2016 at 5:22 AM, Ben Coman  wrote:
>> >> 1. Created fresh Pharo image (build 60269)
>> >>
>> >>
>> >> 2. Opened World > Tools > Epicea > All changes
>> >>
>> >> Points for discussion...

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

In summary, we want to change the "Epicea" menu entry to:

"Epicea Code Changes" (Option 2)
--> Stef, Serge

or:

"Code Changes" (Option 3)
--> Marcus, Sean

I do not care a lot. BTW, what about other tools in the same manu such as
Komitter and Versionner?


Apart from that, many agree on merging Epicea windows in one.
--> Doru, Norbert, Denis, Ben


Martin

On Sat, Dec 24, 2016 at 6:02 AM,  wrote:

> I prefer option 2 because Epicea name is not really important and means
> nothing for the beginner. What is really important in then world menu is
> the function.
>
> Envoyé de mon iPhone
>
> Le 24 déc. 2016 à 09:35, stepharong  a écrit :
>
> On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias 
> wrote:
>
> Ben, yes, please create the issues if you want, and I will try to
> implement them soon. I guess if they are mostly UI changes and categorized
> to "first impression count" or something like that, they can still be
> included in Pharo 6, no?
>
>
> yes
>
>
> One thing to discuss: what do you think about the fact that...
> - the "Session changes" displays the changes of multiple log files in the
> same list widget (silently concatenated), versus
> - the "All changes" way of displaying, where the changes of each log file
> are separated.
>
> That was my main reason to keep two windows by separate. I had the
> impression that in some cases
> - the user wants to see all changes together and he/she doesn't care in
> which log file the changes are written, while in other cases
> - the user wants to know the log files and see how are they connected,
> because they have some meaning
> What do you think of this?
> BTW I don't like the file names... hints are welcome to improve it
>
> Martin
>
> On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:
>
>> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba 
>> wrote:
>> > Hi,
>> >
>> > I think I would prefer to not have to think about this choice at all
>> when in the world menu level. The user interface from the Epicea window
>> already allows me to switch between current session and all sessions, and
>> usually the decision of what to look at is based on whether I find what I
>> am looking for or not. So, rather then asking the user to think about it
>> upfront, I would prefer to have one command that opens the Epicea window on
>> the current session and allow the user to dive deeper. This would also
>> imply that we would have only one command in the menu item. What do you
>> think?
>>
>> Good point. I had a similar thought earlier.  The individual Session
>> Changes window is almost completely embedded in the All Sessions
>> window, so the former seems superfluous. The  and <+> buttons
>> would need to be added to the All Sessions window, probably above the
>> "sesssion" pane.
>
>
>> Two additional things I think are required to facilitate this...
>> 1. The left-pane of the All Sessions windows needs to update when a
>> new session is created - per <+> button.
>> 2. It would be useful if a new session was created "when the image
>> opened" rather than when a change is made, so that it can be
>> preselected in the left-side pane when a fresh image is opened.  But
>> the file shouldn't be created until the first change, for the case
>> like a web service image being invoked multiple times a second.
>>
>> Also one other request, That the current-session be tagged "Current"
>> rather than just "Today".
>>
>> I can log issues if they all sound reasonable.
>>
>> cheers -ben
>>
>> >
>> >> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
>> >>
>> >> I like the second because it associates the name with the function.
>> >>
>> >> Stef
>> >>
>> >>
>> >> Hi all,
>> >>
>> >> One point of Ben's feedback is how Epicea code changes tool is
>> presented in the World Menu. Below you can see the current state + 3
>> options to discuss it.
>> >>
>> >>
>> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children
>> [current state]
>> >>
>> >> 
>> >>
>> >>
>> >> 2. Attach purpose to the name: "Epicea Code Changes"
>> >>
>> >> 
>> >>
>> >>
>> >> 3. Just "Code Changes" + rephrase children:
>> >>
>> >> 
>> >>
>> >>
>> >> 4. Flatten
>> >>
>> >> 
>> >>
>> >>
>> >>
>> >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a
>> description of the tool and it's model.
>> >>
>> >> Cheers.
>> >> Martin
>> >>
>> >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias 
>> wrote:
>> >> Hello Ben,
>> >>
>> >> About discussion points in 2 (a, b and c): I agree with your
>> arguments... somebody that just moved from Pharo 5 to 6 and crashed an
>> image will look for a "Recover lost changes" in the menu and can have a
>> problem to discover it the replacement in a World->Tools->Epicea->... entry.
>> >>
>> >> Then, as a first step we could flatten the 2 menu entries and then at
>> least anybody will easily find an entry related to changes in World->Tools.
>> >>
>> >> Second, we could try to merge both Epicea GUIs into one (suggestions
>> are welcome).
>> >>
>> >> I still have to read more in detai

Re: [Pharo-dev] Epicea user experience report

[Norbert Hartl]

> Am 27.12.2016 um 10:49 schrieb Martin Dias :
> 
> I do not care a lot. BTW, what about other tools in the same manu such as 
> Komitter and Versionner?

It has a cool name that describes what it does. Putting Epicea in front of it 
does not add information only confusion. Versionner and Kommiter carry some 
meaning in their name. But have a better descriptive/more generic name would be 
good.

Norbert

Re: [Pharo-dev] Epicea user experience report

[Esteban Lorenzano]

this is a debate we have with Stef time to time: 

my side: just descriptive names that explain them selves what they do. 
Stef’s side: cool fantasy names, that have some “punch”.

After more than 2 years arguing... both arguments have pros and cons :) 
for example we can have several browsers then we need to identify them and just 
call them “class browser” is not enough. But of course, a newbie will have a 
hard time trying to figure out what “Nautilus” means…
(btw… the world many says "system browser” and not “Nautilus” but then we have 
“monticello browser” and not “SCM package browser”… and later we will have 
“Iceberg” and not “SCM project browser”… so is not consistent either... also if 
everything is a browser then nothing is, etc., etc., etc. :)

… now, what I would like is a way to find tools both from his fantasy name and 
function (for example: “Epicea" and "change logger”)… and a way to list those 
tools/components in both ways… 
Yeah, I’m aware this approach “solves” a problem by adopting both solutions 
instead proposing a synthesis, but well… this is the better I was able to 
elaborate :)

Any ideas are welcome, both on what’s better and how to implement it. 

Esteban

> On 27 Dec 2016, at 11:03, Norbert Hartl  wrote:
> 
> 
> 
>> Am 27.12.2016 um 10:49 schrieb Martin Dias :
>> 
>> I do not care a lot. BTW, what about other tools in the same manu such as 
>> Komitter and Versionner?
> 
> It has a cool name that describes what it does. Putting Epicea in front of it 
> does not add information only confusion. Versionner and Kommiter carry some 
> meaning in their name. But have a better descriptive/more generic name would 
> be good.
> 
> Norbert
> 

Re: [Pharo-dev] Epicea user experience report

[serge . stinckwich]

Sorry I'm for option 3 like Markus or Sean.

Envoyé de mon iPhone

> Le 27 déc. 2016 à 10:49, Martin Dias  a écrit :
> 
> In summary, we want to change the "Epicea" menu entry to:
> 
> "Epicea Code Changes" (Option 2)
> --> Stef, Serge
> 
> or:
> 
> "Code Changes" (Option 3)
> --> Marcus, Sean
> 
> I do not care a lot. BTW, what about other tools in the same manu such as 
> Komitter and Versionner?
> 
> 
> Apart from that, many agree on merging Epicea windows in one.
> --> Doru, Norbert, Denis, Ben
> 
> 
> Martin
> 
>> On Sat, Dec 24, 2016 at 6:02 AM,  wrote:
>> I prefer option 2 because Epicea name is not really important and means 
>> nothing for the beginner. What is really important in then world menu is the 
>> function.
>> 
>> Envoyé de mon iPhone
>> 
>>> Le 24 déc. 2016 à 09:35, stepharong  a écrit :
>>> 
>>> On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias  
>>> wrote:
>>> 
>>> Ben, yes, please create the issues if you want, and I will try to implement 
>>> them soon. I guess if they are mostly UI changes and categorized to "first 
>>> impression count" or something like that, they can still be included in 
>>> Pharo 6, no?
>>> 
>>> yes
>>> 
>>> 
>>> One thing to discuss: what do you think about the fact that... 
>>> - the "Session changes" displays the changes of multiple log files in the 
>>> same list widget (silently concatenated), versus 
>>> - the "All changes" way of displaying, where the changes of each log file 
>>> are separated.
>>>  
>>> That was my main reason to keep two windows by separate. I had the 
>>> impression that in some cases 
>>> - the user wants to see all changes together and he/she doesn't care in 
>>> which log file the changes are written, while in other cases
>>> - the user wants to know the log files and see how are they connected, 
>>> because they have some meaning
>>> What do you think of this?
>>> BTW I don't like the file names... hints are welcome to improve it
>>> 
>>> Martin
>>> 
 On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:
 On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba  wrote:
 > Hi,
 >
 > I think I would prefer to not have to think about this choice at all 
 > when in the world menu level. The user interface from the Epicea window 
 > already allows me to switch between current session and all sessions, 
 > and usually the decision of what to look at is based on whether I find 
 > what I am looking for or not. So, rather then asking the user to think 
 > about it upfront, I would prefer to have one command that opens the 
 > Epicea window on the current session and allow the user to dive deeper. 
 > This would also imply that we would have only one command in the menu 
 > item. What do you think?
 
 Good point. I had a similar thought earlier.  The individual Session
 Changes window is almost completely embedded in the All Sessions
 window, so the former seems superfluous. The  and <+> buttons
 would need to be added to the All Sessions window, probably above the
 "sesssion" pane.
 
 Two additional things I think are required to facilitate this...
 1. The left-pane of the All Sessions windows needs to update when a
 new session is created - per <+> button.
 2. It would be useful if a new session was created "when the image
 opened" rather than when a change is made, so that it can be
 preselected in the left-side pane when a fresh image is opened.  But
 the file shouldn't be created until the first change, for the case
 like a web service image being invoked multiple times a second.
 
 Also one other request, That the current-session be tagged "Current"
 rather than just "Today".
 
 I can log issues if they all sound reasonable.
 
 cheers -ben
 
 >
 >> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
 >>
 >> I like the second because it associates the name with the function.
 >>
 >> Stef
 >>
 >>
 >> Hi all,
 >>
 >> One point of Ben's feedback is how Epicea code changes tool is 
 >> presented in the World Menu. Below you can see the current state + 3 
 >> options to discuss it.
 >>
 >>
 >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children 
 >> [current state]
 >>
 >> 
 >>
 >>
 >> 2. Attach purpose to the name: "Epicea Code Changes"
 >>
 >> 
 >>
 >>
 >> 3. Just "Code Changes" + rephrase children:
 >>
 >> 
 >>
 >>
 >> 4. Flatten
 >>
 >> 
 >>
 >>
 >>
 >> Reminder: In World Menu > Help > Help Browser > Epicea you can find a 
 >> description of the tool and it's model.
 >>
 >> Cheers.
 >> Martin
 >>
 >> On Mon, Oct 31, 2016 at 1:02 AM, Martin Dias  
 >> wrote:
 >> Hello Ben,
 >>
 >> About discussion points in 2 (a, b and c): I agree with your 
 >> arguments... somebody that just moved from Pharo 5 to 6 and 

Re: [Pharo-dev] Epicea user experience report

[serge . stinckwich]

Ok I see ;-)

Tools can have cool names but items in menus should be understandable by 
everyone  including beginners.

Envoyé de mon iPhone

> Le 27 déc. 2016 à 11:39, Esteban Lorenzano  a écrit :
> 
> this is a debate we have with Stef time to time: 
> 
> my side: just descriptive names that explain them selves what they do. 
> Stef’s side: cool fantasy names, that have some “punch”.
> 
> After more than 2 years arguing... both arguments have pros and cons :) 
> for example we can have several browsers then we need to identify them and 
> just call them “class browser” is not enough. But of course, a newbie will 
> have a hard time trying to figure out what “Nautilus” means…
> (btw… the world many says "system browser” and not “Nautilus” but then we 
> have “monticello browser” and not “SCM package browser”… and later we will 
> have “Iceberg” and not “SCM project browser”… so is not consistent either... 
> also if everything is a browser then nothing is, etc., etc., etc. :)
> 
> … now, what I would like is a way to find tools both from his fantasy name 
> and function (for example: “Epicea" and "change logger”)… and a way to list 
> those tools/components in both ways… 
> Yeah, I’m aware this approach “solves” a problem by adopting both solutions 
> instead proposing a synthesis, but well… this is the better I was able to 
> elaborate :)
> 
> Any ideas are welcome, both on what’s better and how to implement it. 
> 
> Esteban
> 
>> On 27 Dec 2016, at 11:03, Norbert Hartl  wrote:
>> 
>> 
>> 
>>> Am 27.12.2016 um 10:49 schrieb Martin Dias :
>>> 
>>> I do not care a lot. BTW, what about other tools in the same manu such as 
>>> Komitter and Versionner?
>> 
>> It has a cool name that describes what it does. Putting Epicea in front of 
>> it does not add information only confusion. Versionner and Kommiter carry 
>> some meaning in their name. But have a better descriptive/more generic name 
>> would be good.
>> 
>> Norbert
>> 
> 
> 

Re: [Pharo-dev] Epicea user experience report

[Ben Coman]

On Tue, Dec 27, 2016 at 5:49 PM, Martin Dias  wrote:
> In summary, we want to change the "Epicea" menu entry to:
>
> "Epicea Code Changes" (Option 2)
> --> Stef, Serge
>
> or:
>
> "Code Changes" (Option 3)
> --> Marcus, Sean
>
> I do not care a lot. BTW, what about other tools in the same manu such as
> Komitter and Versionner?

Option 3 for me.  Komitter and Versionner are new tools so are
starting their meme-space from scratch, and also their names reflect
their function.  Epicea name is replacing an existing tool and also is
more abstract.

"Epicea" should still appear in the title bar of the window it pops up
to identify the tool - similar to what Nautilus does.

cheers -ben


> Apart from that, many agree on merging Epicea windows in one.
> --> Doru, Norbert, Denis, Ben

cool.  Now since Pharo 6 is the first release of Epicea, and as UI
rather than fundamenta change,
I hope this can be done as an exception to the feature freeze, so we
get it right from the start.
And so we will need to pay attention to giving it a good workout
leading up to release.

cheers -ben

>
>
> Martin
>
> On Sat, Dec 24, 2016 at 6:02 AM,  wrote:
>>
>> I prefer option 2 because Epicea name is not really important and means
>> nothing for the beginner. What is really important in then world menu is the
>> function.

P.S. this sounded like support for option 3 :)  ?

>>
>> Envoyé de mon iPhone
>>
>> Le 24 déc. 2016 à 09:35, stepharong  a écrit :
>>
>> On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias 
>> wrote:
>>
>> Ben, yes, please create the issues if you want, and I will try to
>> implement them soon. I guess if they are mostly UI changes and categorized
>> to "first impression count" or something like that, they can still be
>> included in Pharo 6, no?
>>
>>
>> yes
>>
>>
>> One thing to discuss: what do you think about the fact that...
>> - the "Session changes" displays the changes of multiple log files in the
>> same list widget (silently concatenated), versus
>> - the "All changes" way of displaying, where the changes of each log file
>> are separated.
>>
>> That was my main reason to keep two windows by separate. I had the
>> impression that in some cases
>> - the user wants to see all changes together and he/she doesn't care in
>> which log file the changes are written, while in other cases
>> - the user wants to know the log files and see how are they connected,
>> because they have some meaning
>> What do you think of this?
>> BTW I don't like the file names... hints are welcome to improve it
>>
>> Martin
>>
>> On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:
>>>
>>> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba 
>>> wrote:
>>> > Hi,
>>> >
>>> > I think I would prefer to not have to think about this choice at all
>>> > when in the world menu level. The user interface from the Epicea window
>>> > already allows me to switch between current session and all sessions, and
>>> > usually the decision of what to look at is based on whether I find what I 
>>> > am
>>> > looking for or not. So, rather then asking the user to think about it
>>> > upfront, I would prefer to have one command that opens the Epicea window 
>>> > on
>>> > the current session and allow the user to dive deeper. This would also 
>>> > imply
>>> > that we would have only one command in the menu item. What do you think?
>>>
>>> Good point. I had a similar thought earlier.  The individual Session
>>> Changes window is almost completely embedded in the All Sessions
>>> window, so the former seems superfluous. The  and <+> buttons
>>> would need to be added to the All Sessions window, probably above the
>>> "sesssion" pane.
>>>
>>>
>>> Two additional things I think are required to facilitate this...
>>> 1. The left-pane of the All Sessions windows needs to update when a
>>> new session is created - per <+> button.
>>> 2. It would be useful if a new session was created "when the image
>>> opened" rather than when a change is made, so that it can be
>>> preselected in the left-side pane when a fresh image is opened.  But
>>> the file shouldn't be created until the first change, for the case
>>> like a web service image being invoked multiple times a second.
>>>
>>> Also one other request, That the current-session be tagged "Current"
>>> rather than just "Today".
>>>
>>> I can log issues if they all sound reasonable.
>>>
>>> cheers -ben
>>>
>>> >
>>> >> On Dec 20, 2016, at 10:16 PM, stepharong  wrote:
>>> >>
>>> >> I like the second because it associates the name with the function.
>>> >>
>>> >> Stef
>>> >>
>>> >>
>>> >> Hi all,
>>> >>
>>> >> One point of Ben's feedback is how Epicea code changes tool is
>>> >> presented in the World Menu. Below you can see the current state + 3 
>>> >> options
>>> >> to discuss it.
>>> >>
>>> >>
>>> >> 1. "Epicea" main entry > "Session Changes" + "All Changes" children
>>> >> [current state]
>>> >>
>>> >> 
>>> >>
>>> >>
>>> >> 2. Attach purpose to the name: "Epicea Code Changes"
>>> >>
>>> >> 
>>> >>
>>> >>
>>> >> 3. Just "Cod

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

I created an entry in fogbugz and had progress:

 https://pharo.fogbugz.com/f/cases/19534/Unify-Epicea-UIs

Cheers,
Martin

On Tue, Dec 27, 2016 at 11:20 PM, Ben Coman  wrote:

> On Tue, Dec 27, 2016 at 5:49 PM, Martin Dias  wrote:
> > In summary, we want to change the "Epicea" menu entry to:
> >
> > "Epicea Code Changes" (Option 2)
> > --> Stef, Serge
> >
> > or:
> >
> > "Code Changes" (Option 3)
> > --> Marcus, Sean
> >
> > I do not care a lot. BTW, what about other tools in the same manu such as
> > Komitter and Versionner?
>
> Option 3 for me.  Komitter and Versionner are new tools so are
> starting their meme-space from scratch, and also their names reflect
> their function.  Epicea name is replacing an existing tool and also is
> more abstract.
>
> "Epicea" should still appear in the title bar of the window it pops up
> to identify the tool - similar to what Nautilus does.
>
> cheers -ben
>
>
> > Apart from that, many agree on merging Epicea windows in one.
> > --> Doru, Norbert, Denis, Ben
>
> cool.  Now since Pharo 6 is the first release of Epicea, and as UI
> rather than fundamenta change,
> I hope this can be done as an exception to the feature freeze, so we
> get it right from the start.
> And so we will need to pay attention to giving it a good workout
> leading up to release.
>
> cheers -ben
>
> >
> >
> > Martin
> >
> > On Sat, Dec 24, 2016 at 6:02 AM,  wrote:
> >>
> >> I prefer option 2 because Epicea name is not really important and means
> >> nothing for the beginner. What is really important in then world menu
> is the
> >> function.
>
> P.S. this sounded like support for option 3 :)  ?
>
> >>
> >> Envoyé de mon iPhone
> >>
> >> Le 24 déc. 2016 à 09:35, stepharong  a écrit :
> >>
> >> On Fri, 23 Dec 2016 19:46:34 +0100, Martin Dias 
> >> wrote:
> >>
> >> Ben, yes, please create the issues if you want, and I will try to
> >> implement them soon. I guess if they are mostly UI changes and
> categorized
> >> to "first impression count" or something like that, they can still be
> >> included in Pharo 6, no?
> >>
> >>
> >> yes
> >>
> >>
> >> One thing to discuss: what do you think about the fact that...
> >> - the "Session changes" displays the changes of multiple log files in
> the
> >> same list widget (silently concatenated), versus
> >> - the "All changes" way of displaying, where the changes of each log
> file
> >> are separated.
> >>
> >> That was my main reason to keep two windows by separate. I had the
> >> impression that in some cases
> >> - the user wants to see all changes together and he/she doesn't care in
> >> which log file the changes are written, while in other cases
> >> - the user wants to know the log files and see how are they connected,
> >> because they have some meaning
> >> What do you think of this?
> >> BTW I don't like the file names... hints are welcome to improve it
> >>
> >> Martin
> >>
> >> On Wed, Dec 21, 2016 at 9:19 AM, Ben Coman  wrote:
> >>>
> >>> On Wed, Dec 21, 2016 at 3:03 PM, Tudor Girba 
> >>> wrote:
> >>> > Hi,
> >>> >
> >>> > I think I would prefer to not have to think about this choice at all
> >>> > when in the world menu level. The user interface from the Epicea
> window
> >>> > already allows me to switch between current session and all
> sessions, and
> >>> > usually the decision of what to look at is based on whether I find
> what I am
> >>> > looking for or not. So, rather then asking the user to think about it
> >>> > upfront, I would prefer to have one command that opens the Epicea
> window on
> >>> > the current session and allow the user to dive deeper. This would
> also imply
> >>> > that we would have only one command in the menu item. What do you
> think?
> >>>
> >>> Good point. I had a similar thought earlier.  The individual Session
> >>> Changes window is almost completely embedded in the All Sessions
> >>> window, so the former seems superfluous. The  and <+> buttons
> >>> would need to be added to the All Sessions window, probably above the
> >>> "sesssion" pane.
> >>>
> >>>
> >>> Two additional things I think are required to facilitate this...
> >>> 1. The left-pane of the All Sessions windows needs to update when a
> >>> new session is created - per <+> button.
> >>> 2. It would be useful if a new session was created "when the image
> >>> opened" rather than when a change is made, so that it can be
> >>> preselected in the left-side pane when a fresh image is opened.  But
> >>> the file shouldn't be created until the first change, for the case
> >>> like a web service image being invoked multiple times a second.
> >>>
> >>> Also one other request, That the current-session be tagged "Current"
> >>> rather than just "Today".
> >>>
> >>> I can log issues if they all sound reasonable.
> >>>
> >>> cheers -ben
> >>>
> >>> >
> >>> >> On Dec 20, 2016, at 10:16 PM, stepharong 
> wrote:
> >>> >>
> >>> >> I like the second because it associates the name with the function.
> >>> >>
> >>> >> Stef
> >>> >>
> >>> >>
> >>> >> Hi all,
> >>> >>
> >

Re: [Pharo-dev] Epicea user experience report

[Ben Coman]

On Wed, Jan 11, 2017 at 3:29 PM, Martin Dias  wrote:

> I created an entry in fogbugz and had progress:
>
>  https://pharo.fogbugz.com/f/cases/19534/Unify-Epicea-UIs
>
> Cheers,
> Martin
>

 hi Martin,

I like the result - especially when opening a fresh image and
directly going
World > Tools > Code Changes
the current session already exists as an empty session.
Watching the file system I see the session file is not created until an
edit is made, which is good.

However after making the a change so the session file is created,
then Save&Quit, then reopening the Image and Epicea, I expected to see two
sessions but see only the last session.
The current session doesn't show up until a new change is made, which feels
like the session hasn't changed so confused me for a while.

I'm not seeing my name as author of methods.  I can't remember exactly but
I thought this was previously visible in the right pane.

Its nice having just one World menu item one level higher than before.

cheers -ben

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

On Mon, Jan 23, 2017 at 2:44 PM, Ben Coman  wrote:

> On Wed, Jan 11, 2017 at 3:29 PM, Martin Dias  wrote:
>
>> I created an entry in fogbugz and had progress:
>>
>>  https://pharo.fogbugz.com/f/cases/19534/Unify-Epicea-UIs
>>
>> Cheers,
>> Martin
>>
>
>  hi Martin,
>

hi


>
> I like the result - especially when opening a fresh image and
> directly going
> World > Tools > Code Changes
> the current session already exists as an empty session.
> Watching the file system I see the session file is not created until an
> edit is made, which is good.
>

Good to hear that, thanks. Finally I found the time to do it. Now I would
like to pay attention to recording performance improvement... there is
something reported about that in fogbugz.


> However after making the a change so the session file is created,
> then Save&Quit, then reopening the Image and Epicea, I expected to see two
> sessions but see only the last session.
>
The current session doesn't show up until a new change is made, which feels
> like the session hasn't changed so confused me for a while.
>

Right. I created a fogbugz case and fixed it by adding a registration in
the SessionManager as a tool.


>
> I'm not seeing my name as author of methods.  I can't remember exactly but
> I thought this was previously visible in the right pane.
>

This is a feature :) it may be wrong, of course, but it was on purpose...
and this is not recent! More than a one year ago, I felt it was too
redundant to see my user name on each change, so made the #asMorph to only
show the author when it's not the Author current. It could say 'Me' instead
of nothing. Do you sometimes switch Author in your environment?

What might be nice is, for example, to show author X when a method is
created by loading a MC package. Right now, it considers the author is just
the current Author.


>
> Its nice having just one World menu item one level higher than before.
>
> cheers -ben
>

Re: [Pharo-dev] Epicea user experience report

[Ben Coman]

On Tue, Jan 24, 2017 at 6:43 AM, Martin Dias  wrote:
>
>
>
> On Mon, Jan 23, 2017 at 2:44 PM, Ben Coman  wrote:
>>
>> On Wed, Jan 11, 2017 at 3:29 PM, Martin Dias  wrote:
>>>
>>> I created an entry in fogbugz and had progress:
>>>
>>>  https://pharo.fogbugz.com/f/cases/19534/Unify-Epicea-UIs
>>>
>>> Cheers,
>>> Martin
>>
>>
>>  hi Martin,
>
>
> hi
>
>>
>>
>> I like the result - especially when opening a fresh image and directly going
>> World > Tools > Code Changes
>> the current session already exists as an empty session.
>> Watching the file system I see the session file is not created until an edit 
>> is made, which is good.
>
>
> Good to hear that, thanks. Finally I found the time to do it. Now I would 
> like to pay attention to recording performance improvement... there is 
> something reported about that in fogbugz.
>
>>
>> However after making the a change so the session file is created,
>> then Save&Quit, then reopening the Image and Epicea, I expected to see two 
>> sessions but see only the last session.
>>
>> The current session doesn't show up until a new change is made, which feels 
>> like the session hasn't changed so confused me for a while.
>
>
> Right. I created a fogbugz case and fixed it by adding a registration in the 
> SessionManager as a tool.
>
>>
>>
>> I'm not seeing my name as author of methods.  I can't remember exactly but I 
>> thought this was previously visible in the right pane.
>
>
> This is a feature :) it may be wrong, of course, but it was on purpose... and 
> this is not recent! More than a one year ago, I felt it was too redundant to 
> see my user name on each change, so made the #asMorph to only show the author 
> when it's not the Author current.

Makes sense, but the impression is a bug.

>
>
> It could say 'Me' instead of nothing.

That would be acceptable, even cool.
And its nice and short.

> Do you sometimes switch Author in your environment?

I don't.  But if my first impression is a bug, likely some random
sample of other people may feel the same which is a detraction.

>
> What might be nice is, for example, to show author X when a method is created 
> by loading a MC package. Right now, it considers the author is just the 
> current Author.

That is a good idea.  It is what I would expect.

Now I wonder if its possible to record both, with the original
author's modification date as well as date loaded into the Image.
It could perhaps be displayed as " Me(OriginalAuthor)
LoadedDate(OriginalDate)"  ??
I'm not exactly sure how useful it would be, but perhaps you could
have discussion with the guys at your end.

cheers -ben

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

On Mon, Jan 23, 2017 at 8:44 PM, Ben Coman  wrote:

> On Tue, Jan 24, 2017 at 6:43 AM, Martin Dias  wrote:
> >
> >
> >
> > On Mon, Jan 23, 2017 at 2:44 PM, Ben Coman  wrote:
> >>
> >> On Wed, Jan 11, 2017 at 3:29 PM, Martin Dias 
> wrote:
> >>>
> >>> I created an entry in fogbugz and had progress:
> >>>
> >>>  https://pharo.fogbugz.com/f/cases/19534/Unify-Epicea-UIs
> >>>
> >>> Cheers,
> >>> Martin
> >>
> >>
> >>  hi Martin,
> >
> >
> > hi
> >
> >>
> >>
> >> I like the result - especially when opening a fresh image and directly
> going
> >> World > Tools > Code Changes
> >> the current session already exists as an empty session.
> >> Watching the file system I see the session file is not created until an
> edit is made, which is good.
> >
> >
> > Good to hear that, thanks. Finally I found the time to do it. Now I
> would like to pay attention to recording performance improvement... there
> is something reported about that in fogbugz.
> >
> >>
> >> However after making the a change so the session file is created,
> >> then Save&Quit, then reopening the Image and Epicea, I expected to see
> two sessions but see only the last session.
> >>
> >> The current session doesn't show up until a new change is made, which
> feels like the session hasn't changed so confused me for a while.
> >
> >
> > Right. I created a fogbugz case and fixed it by adding a registration in
> the SessionManager as a tool.
> >
> >>
> >>
> >> I'm not seeing my name as author of methods.  I can't remember exactly
> but I thought this was previously visible in the right pane.
> >
> >
> > This is a feature :) it may be wrong, of course, but it was on
> purpose... and this is not recent! More than a one year ago, I felt it was
> too redundant to see my user name on each change, so made the #asMorph to
> only show the author when it's not the Author current.
>
> Makes sense, but the impression is a bug.
>

I see... for the moment we can just never show an author and then it's
consistent.

BTW, in the latest integrated release it was not ony the unified of the UIs
but also I added a new setting: the naming strategy for new log files.
There is the Random (the only option before), the Sequential (1, 2, 3...)
and the timestamp (a print of the nanoseconds).


> >
> >
> > It could say 'Me' instead of nothing.
>
> That would be acceptable, even cool.
> And its nice and short.
>
> > Do you sometimes switch Author in your environment?
>
> I don't.  But if my first impression is a bug, likely some random
> sample of other people may feel the same which is a detraction.
>
> >
> > What might be nice is, for example, to show author X when a method is
> created by loading a MC package. Right now, it considers the author is just
> the current Author.
>
> That is a good idea.  It is what I would expect.
>
> Now I wonder if its possible to record both, with the original
> author's modification date as well as date loaded into the Image.
> It could perhaps be displayed as " Me(OriginalAuthor)
> LoadedDate(OriginalDate)"  ??
> I'm not exactly sure how useful it would be, but perhaps you could
> have discussion with the guys at your end.
>
> cheers -ben
>
>

[Pharo-dev] Epicea - showing latest lost changes

[Ben Coman]

One thing I am missing from Epicea that I used to be able to do
is being able to filter out old changes.  If I've been thrashing
some method back and forth between a few implementations,
often I don't want to see *all* the old changes,only the latest ones.

An option to restore old versions would also be nice, but I don't think
that feature existed previously.

cheers -ben

Re: [Pharo-dev] Epicea user experience report

[Igor Stasenko]

Epicea is most valuable jewel i ever wished to have in Pharo..
Martin big thanks for your effort to make such a wonderful piece of
software.

-- 
Best regards,
Igor Stasenko.

Re: [Pharo-dev] Epicea user experience report

[Martin Dias]

Ehhh... thanks for your generous words Igor! that's too much, but at least
I hope it's useful.

On Fri, Feb 24, 2017 at 5:30 PM, Igor Stasenko  wrote:

>
> Epicea is most valuable jewel i ever wished to have in Pharo..
> Martin big thanks for your effort to make such a wonderful piece of
> software.
>
> --
> Best regards,
> Igor Stasenko.
>

Re: [Pharo-dev] Epicea should ask before recovering

[Denis Kudriashov]

2017-04-16 12:09 GMT+02:00 Peter Uhnak :

> Of course if I am the only person that uses images in such a way then I
> can just work around it myself. (because having endless lists of config
> options is also nightmare)


Me too

Re: [Pharo-dev] Epicea should ask before recovering

[Dimitris Chloupis]

Me three

Recover dialog is standard on all apps anyway
On Sun, 16 Apr 2017 at 16:22, Denis Kudriashov  wrote:

>
> 2017-04-16 12:09 GMT+02:00 Peter Uhnak :
>
>> Of course if I am the only person that uses images in such a way then I
>> can just work around it myself. (because having endless lists of config
>> options is also nightmare)
>
>
> Me too
>

Re: [Pharo-dev] Epicea should ask before recovering

[Martin Dias]

You can disable it: World Menu > Settings > Tools > Epicea > Detect lost
events on start up

I can make it initially disabled by default.
However, I have an optimization that can improve a lot the time to read,
maybe we can still integrate a new version of Epicea before 6.0 release.
I've been testing it for a couple of weeks and works well.

On Sun, Apr 16, 2017 at 11:09 AM, Dimitris Chloupis 
wrote:

> Me three
>
> Recover dialog is standard on all apps anyway
> On Sun, 16 Apr 2017 at 16:22, Denis Kudriashov 
> wrote:
>
>>
>> 2017-04-16 12:09 GMT+02:00 Peter Uhnak :
>>
>>> Of course if I am the only person that uses images in such a way then I
>>> can just work around it myself. (because having endless lists of config
>>> options is also nightmare)
>>
>>
>> Me too
>>
>

Re: [Pharo-dev] Epicea should ask before recovering

[Denis Kudriashov]

Hi Martin.

2017-04-18 0:22 GMT+02:00 Martin Dias :

> You can disable it: World Menu > Settings > Tools > Epicea > Detect lost
> events on start up


Idea to not disable it but to show notification about lost changes with
button to open changes browser. It should remove delay on image startup
because full changes will be not loaded in that case.

Re: [Pharo-dev] Epicea should ask before recovering

[Guillermo Polito]

Yeh, What they mean is that instead of loading the list of "possible stuff
to recover" you launch at startup a dialog:

"It seems your last Pharo session exited without saving some code. Do you
want to recover it?" YES/NO

:)

On Tue, Apr 18, 2017 at 10:03 AM, Denis Kudriashov 
wrote:

> Hi Martin.
>
> 2017-04-18 0:22 GMT+02:00 Martin Dias :
>
>> You can disable it: World Menu > Settings > Tools > Epicea > Detect lost
>> events on start up
>
>
> Idea to not disable it but to show notification about lost changes with
> button to open changes browser. It should remove delay on image startup
> because full changes will be not loaded in that case.
>
>

Re: [Pharo-dev] Epicea should ask before recovering

[Peter Uhnak]

On Wed, Apr 19, 2017 at 10:04:01AM +0200, Guillermo Polito wrote:
> Yeh, What they mean is that instead of loading the list of "possible stuff
> to recover" you launch at startup a dialog:
> 
> "It seems your last Pharo session exited without saving some code. Do you
> want to recover it?" YES/NO

Precisely.

(and reading my original mail I've realized that I should not write when I am 
tired... the first sentence there made no sense at all... sorry :))

Peter

> 
> :)
> 
> On Tue, Apr 18, 2017 at 10:03 AM, Denis Kudriashov 
> wrote:
> 
> > Hi Martin.
> >
> > 2017-04-18 0:22 GMT+02:00 Martin Dias :
> >
> >> You can disable it: World Menu > Settings > Tools > Epicea > Detect lost
> >> events on start up
> >
> >
> > Idea to not disable it but to show notification about lost changes with
> > button to open changes browser. It should remove delay on image startup
> > because full changes will be not loaded in that case.
> >
> >

Re: [Pharo-dev] Epicea should ask before recovering

[Rajula Vineet]

Hi,

I am interested in this issue. Maybe I will try adding this feature of a pop
up when an image crashes, which asks 'do you want to recover your lost
changes?'

Rajula



--
View this message in context: 
http://forum.world.st/Epicea-should-ask-before-recovering-tp4942281p4942694.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Epicea should ask before recovering

[Ben Coman]

On Wed, Apr 19, 2017 at 9:42 PM, Rajula Vineet 
wrote:

> Hi,
>
> I am interested in this issue. Maybe I will try adding this feature of a
> pop
> up when an image crashes, which asks 'do you want to recover your lost
> changes?'
>
> Rajula
>
>
Give it a go.
http://pharo.org/contribute-propose-fix
https://pharo.fogbugz.com/f/cases/19955/Epicea-should-ask-before-recovering

For approach, use "World menu > Tools > Finder > Source"
searching for the window title "Lost Changes Detected".
Drop a "self halt" at the top of that method.
Save the Image, then change any random method and Quit the image.
Next startup a debugger should open in the appropriate spot.

---

However a side question is, when someone goes "World menu > Quit"
should that be taken to mean they are throwing away outstanding changes?

---

Something else, I went to test previous behaviour of Lost Changes in Pharo
5.0
and I'm confounded by this behaviour.

Preparation...
1. Downloaded and uznipped
http://files.pharo.org/platform/Pharo5.0-linux.zip
2. From the command line, ran ./pharo
3. Opened System Browser on random method EllipseMorph>>closestPointTo:
4. Appended "aPoint + 0@0" and saved method.
5. Save&Quit Image, then re-opened Image

Test...
6. Changed 0@0 to 1@1.
7. At the command line, hit  to crash-stop the image
8. Re-open image
==> Expect "Lost Changes" dialog but there is none.
Do I misremember the expected behaviour?

This is the same with...
   http://files.pharo.org/platform/Pharo2.0-linux.zip

cheers -ben

Re: [Pharo-dev] Epicea should ask before recovering

[Denis Kudriashov]

I as trying to write little tips. But I realized new issue 19957


2017-04-20 3:34 GMT+02:00 Ben Coman :

>
>
> On Wed, Apr 19, 2017 at 9:42 PM, Rajula Vineet 
> wrote:
>
>> Hi,
>>
>> I am interested in this issue. Maybe I will try adding this feature of a
>> pop
>> up when an image crashes, which asks 'do you want to recover your lost
>> changes?'
>>
>> Rajula
>>
>>
> Give it a go.
> http://pharo.org/contribute-propose-fix
> https://pharo.fogbugz.com/f/cases/19955/Epicea-should-ask-
> before-recovering
>
> For approach, use "World menu > Tools > Finder > Source"
> searching for the window title "Lost Changes Detected".
> Drop a "self halt" at the top of that method.
> Save the Image, then change any random method and Quit the image.
> Next startup a debugger should open in the appropriate spot.
>
> ---
>
> However a side question is, when someone goes "World menu > Quit"
> should that be taken to mean they are throwing away outstanding changes?
>
> ---
>
> Something else, I went to test previous behaviour of Lost Changes in Pharo
> 5.0
> and I'm confounded by this behaviour.
>
> Preparation...
> 1. Downloaded and uznipped http://files.pharo.org/
> platform/Pharo5.0-linux.zip
> 2. From the command line, ran ./pharo
> 3. Opened System Browser on random method EllipseMorph>>closestPointTo:
> 4. Appended "aPoint + 0@0" and saved method.
> 5. Save&Quit Image, then re-opened Image
>
> Test...
> 6. Changed 0@0 to 1@1.
> 7. At the command line, hit  to crash-stop the image
> 8. Re-open image
> ==> Expect "Lost Changes" dialog but there is none.
> Do I misremember the expected behaviour?
>
> This is the same with...
>http://files.pharo.org/platform/Pharo2.0-linux.zip
>
> cheers -ben
>

Re: [Pharo-dev] Epicea and #name in #behaviorAffectedName

[Martin Dias]

Hi Torsten, just copied your report into here:

https://pharo.fogbugz.com/f/cases/20222/Epicea-deprecation-warning-dialog-popped-up-and-repeated-itself-unstoppable

I'll see it ASAP. Thanks and sorry for my delay.

Martín


El 19/5/2017 17:45, "Torsten Bergmann"  escribió:

> Hi,
>
> in latest Pharo 6 image 60494 I run into some trouble today where the
> deprecation warning dialog popped up and repeated itself unstoppable
> due to Epicea.
>
> It is hard to reproduce but what I found out was that I had a class
> modification (represented by EpClassModification) which run into a state
> where "newClass" was nil and therefore in EpClassModification>>#behavior
> AffectedName
> the message #name was sent to nil.
>
> So #name was found in Object and as we all know we deprecated it now
> which lead to the deprecation dialog, leading to the deprecation dialog,
> leading to the deprecation dialog, ...
>
> Nearly all implementors of Epiceas #behaviorAffectedName send #name
> which is ok if there is a valid object it is sent to.
>
> I do not know if we should protect them somehow in case something
> goes wrong (like having nil in newClass) or if we should keep this
> untouched.
>
> At least I wanted to inform because I do not know if this later
> gets others into trouble too and losing their changes because Epicea
> does not record.
>
> Thanks
> T.
>
>

[Pharo-dev] Epicea changes broken in latest 7

[Sven Van Caekenberghe]

World Menu > Tools > Code Changes

click on any change, boom.

[ :error | 
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] in [ :readStream | 
[ ^ aBlockClosure value: readStream ]
on: Error
do: [ :error | 
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] ] in 
OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
BlockClosure>>cull:
Context>>evaluateSignal:
Context>>handleSignal:
Context>>handleSignal:
MessageNotUnderstood(Exception)>>signal
UndefinedObject(Object)>>doesNotUnderstand: #<
ZnUTF8Encoder>>nextCodePointFromStream:
ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
ZnCharacterReadStream>>nextElement
[ :out | 
| partialMatch pattern matched |
partialMatch := (self collectionSpecies new: aCollection size)
writeStream.
pattern := aCollection readStream.
matched := false.
[ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
whileFalse: [ | ch |
(ch := self nextElement) = pattern next
ifTrue: [ pattern atEnd
ifTrue: [ matched := true ]
ifFalse: [ partialMatch nextPut: ch ] ]
ifFalse: [ pattern reset.
out nextPutAll: partialMatch contents.
partialMatch reset.
out nextPut: ch ] ].
matched
ifFalse: [ out nextPutAll: partialMatch contents ] ] in 
ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
String class(SequenceableCollection class)>>new:streamContents:
String class(SequenceableCollection class)>>streamContents:
ZnCharacterReadStream>>upToAll:
[ stream upToAll: token ] in 
OmSTONEntryReader>>nextEntryPositionIfFound:ifNone: in Block: [ stream upToAll: 
token ]
BlockClosure>>on:do:
OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
OmSTONEntryReader>>entryPositionsDo:
OmSTONEntryReader>>entryPositionsUpTo:
[ :readStream | 
readStream position: startPosition.
^ self newEntryReader
stream: readStream;
entryPositionsUpTo: endPosition ] in 
OmBlockFileStore>>entryPositionsStartingAt:upTo: in Block: [ :readStream | ...
[ ^ aBlockClosure value: readStream ] in [ :readStream | 
[ ^ aBlockClosure value: readStream ]
on: Error
do: [ :error | 
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] ] in 
OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure 
value: readStream ]
BlockClosure>>on:do:
[ :readStream | 
[ ^ aBlockClosure value: readStream ]
on: Error
do: [ :error | 
(OmFileStoreReadingError
readingError: error
on: self fileReference
position: readStream position) signal ] ] in 
OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream | ...
[ aBlock value: stream ] in FileReference(AbstractFileReference)>>readStreamDo: 
in Block: [ aBlock value: stream ]
BlockClosure>>ensure:
FileReference(AbstractFileReference)>>readStreamDo:
OmBlockFileStore(OmFileStore)>>readEntriesWith:
OmBlockFileStore>>entryPositionsStartingAt:upTo:
OmBlock>>refresh
OmBlock>>checkIfMustRefreshBlock

[Pharo-dev] Epicea or the launcher gets confused

[Stephane Ducasse]

Hi

I downloaded the latest version of Pharo and I coded.
When I open Epicea, I see changes I did three days ago but this is not possible
since I just took the image now.

Stef

Re: [Pharo-dev] Epicea - showing latest lost changes

[stepharong]

I agree :)

On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman  wrote:


One thing I am missing from Epicea that I used to be able to do
is being able to filter out old changes.  If I've been thrashingsome  
method back and forth between a few implementations,often I don't want  
to see *all* the old changes,only the latest ones.  
An option to restore old versions would also be nice, but I don't think  
that feature existed previously.


cheers -ben




--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Epicea - showing latest lost changes

[Martin Dias]

Hi. Does this report match your idea?
https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters

Martin

On Thu, Feb 23, 2017 at 3:35 PM, stepharong  wrote:

> I agree :)
>
> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman  wrote:
>
> One thing I am missing from Epicea that I used to be able to do
> is being able to filter out old changes.  If I've been thrashing
> some method back and forth between a few implementations,
> often I don't want to see *all* the old changes,only the latest ones.
>
> An option to restore old versions would also be nice, but I don't think
> that feature existed previously.
>
> cheers -ben
>
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>

Re: [Pharo-dev] Epicea - showing latest lost changes

[stepharong]

Hi martin

Thanks for our constant improvement of epicea.
In VW they have a nice way to filter

you can filter the entitiies
 doit or not
 method or not
 packages or not
and you can deselect a selected item.

this way you can say I do not want any doit except this one.



On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias   
wrote:


Hi. Does this report match your idea? 
https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters

Martin

On Thu, Feb 23, 2017 at 3:35 PM, stepharong  wrote:

I agree :)

On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman   
wrote:



One thing I am missing from Epicea that I used to be able to do
is being able to filter out old changes.  If I've been thrashingsome  
method back and forth between a few implementations,often I don't want  
to see *all* the old changes,only the latest ones.  
An option to restore old versions would also be nice, but I don't  
think that feature existed previously.


cheers -ben




--Using Opera's mail client: http://www.opera.com/mail/






--
Using Opera's mail client: http://www.opera.com/mail/

Re: [Pharo-dev] Epicea - showing latest lost changes

[Yuriy Tymchuk]

I have one more suggestion for Epicea. When the window pops up I’d like to have 
a big “RESTORE” button to reapply all the changes. I think it will be also more 
user friendly, as how should an newcomer know that he has to select all the 
items in the list and use the context menu.

Cheers.
Uko

> On 24 Feb 2017, at 08:33, stepharong  wrote:
> 
> Hi martin
> 
> Thanks for our constant improvement of epicea. 
> In VW they have a nice way to filter
> 
> you can filter the entitiies
>  doit or not
>  method or not
>  packages or not
> and you can deselect a selected item. 
> 
> this way you can say I do not want any doit except this one. 
> 
> 
> 
> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias  wrote:
> 
> Hi. Does this report match your idea? 
> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters 
>  
> 
> Martin
> 
> On Thu, Feb 23, 2017 at 3:35 PM, stepharong  > wrote:
> I agree :)
> 
> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman  > wrote:
> 
> One thing I am missing from Epicea that I used to be able to do
> is being able to filter out old changes.  If I've been thrashing 
> some method back and forth between a few implementations, 
> often I don't want to see *all* the old changes,only the latest ones.  
> 
> An option to restore old versions would also be nice, but I don't think that 
> feature existed previously.
> 
> cheers -ben
> 
> 
> 
> --
> Using Opera's mail client: http://www.opera.com/mail/ 
> 
> 
> 
> 
> --
> Using Opera's mail client: http://www.opera.com/mail/ 
> 

Re: [Pharo-dev] Epicea - showing latest lost changes

[Ben Coman]

Except you may need to exclude the last few changes which made your image
crash.
Maybe there could be two buttons  "1. Select lost changes" and "2. Restore
selected"
which gives you the opportunity to manually deselect between the steps.
Step 1 might select only the latest of each method, without the need to
filter.

cheers -ben

On Fri, Feb 24, 2017 at 11:04 PM, Yuriy Tymchuk 
wrote:

> I have one more suggestion for Epicea. When the window pops up I’d like to
> have a big “RESTORE” button to reapply all the changes. I think it will be
> also more user friendly, as how should an newcomer know that he has to
> select all the items in the list and use the context menu.
>
> Cheers.
> Uko
>
>
> On 24 Feb 2017, at 08:33, stepharong  wrote:
>
> Hi martin
>
> Thanks for our constant improvement of epicea.
> In VW they have a nice way to filter
>
> you can filter the entitiies
>  doit or not
>  method or not
>  packages or not
> and you can deselect a selected item.
>
> this way you can say I do not want any doit except this one.
>
>
>
> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias 
> wrote:
>
> Hi. Does this report match your idea?
> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters
>
> Martin
>
> On Thu, Feb 23, 2017 at 3:35 PM, stepharong  wrote:
>
>> I agree :)
>>
>> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman 
>> wrote:
>>
>> One thing I am missing from Epicea that I used to be able to do
>> is being able to filter out old changes.  If I've been thrashing
>> some method back and forth between a few implementations,
>> often I don't want to see *all* the old changes,only the latest ones.
>>
>> An option to restore old versions would also be nice, but I don't think
>> that feature existed previously.
>>
>> cheers -ben
>>
>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
>
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>
>

Re: [Pharo-dev] Epicea - showing latest lost changes

[Martin Dias]

On Fri, Feb 24, 2017 at 12:04 PM, Yuriy Tymchuk 
wrote:

> I have one more suggestion for Epicea. When the window pops up I’d like to
> have a big “RESTORE” button to reapply all the changes. I think it will be
> also more user friendly, as how should an newcomer know that he has to
> select all the items in the list and use the context menu.
>

Uko, maybe it could be an "Apply all" button on top of the list of changes?



>
> Cheers.
> Uko
>
>
> On 24 Feb 2017, at 08:33, stepharong  wrote:
>
> Hi martin
>
> Thanks for our constant improvement of epicea.
> In VW they have a nice way to filter
>
> you can filter the entitiies
>  doit or not
>  method or not
>  packages or not
> and you can deselect a selected item.
>
> this way you can say I do not want any doit except this one.
>
>
>
> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias 
> wrote:
>
> Hi. Does this report match your idea?
> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters
>
> Martin
>
> On Thu, Feb 23, 2017 at 3:35 PM, stepharong  wrote:
>
>> I agree :)
>>
>> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman 
>> wrote:
>>
>> One thing I am missing from Epicea that I used to be able to do
>> is being able to filter out old changes.  If I've been thrashing
>> some method back and forth between a few implementations,
>> often I don't want to see *all* the old changes,only the latest ones.
>>
>> An option to restore old versions would also be nice, but I don't think
>> that feature existed previously.
>>
>> cheers -ben
>>
>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
>
>
>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>
>

Re: [Pharo-dev] Epicea - showing latest lost changes

[Yuriy Tymchuk]

Of course. For me it’s about 2 things:

1) I usually need to restore 100% of the changes, so having such button is 
convenient.
2) I think that newcomers will be confused if they just se a list without any 
hints what to do with it.

Uko

> On 27 Feb 2017, at 05:41, Martin Dias  wrote:
> 
> 
> 
> On Fri, Feb 24, 2017 at 12:04 PM, Yuriy Tymchuk  > wrote:
> I have one more suggestion for Epicea. When the window pops up I’d like to 
> have a big “RESTORE” button to reapply all the changes. I think it will be 
> also more user friendly, as how should an newcomer know that he has to select 
> all the items in the list and use the context menu.
> 
> Uko, maybe it could be an "Apply all" button on top of the list of changes?
> 
>  
> 
> Cheers.
> Uko
> 
> 
>> On 24 Feb 2017, at 08:33, stepharong > > wrote:
>> 
>> Hi martin
>> 
>> Thanks for our constant improvement of epicea. 
>> In VW they have a nice way to filter
>> 
>> you can filter the entitiies
>>  doit or not
>>  method or not
>>  packages or not
>> and you can deselect a selected item. 
>> 
>> this way you can say I do not want any doit except this one. 
>> 
>> 
>> 
>> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias > > wrote:
>> 
>> Hi. Does this report match your idea? 
>> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters 
>>  
>> 
>> Martin
>> 
>> On Thu, Feb 23, 2017 at 3:35 PM, stepharong > > wrote:
>> I agree :)
>> 
>> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman > > wrote:
>> 
>> One thing I am missing from Epicea that I used to be able to do
>> is being able to filter out old changes.  If I've been thrashing 
>> some method back and forth between a few implementations, 
>> often I don't want to see *all* the old changes,only the latest ones.  
>> 
>> An option to restore old versions would also be nice, but I don't think that 
>> feature existed previously.
>> 
>> cheers -ben
>> 
>> 
>> 
>> --
>> Using Opera's mail client: http://www.opera.com/mail/ 
>> 
>> 
>> 
>> 
>> --
>> Using Opera's mail client: http://www.opera.com/mail/ 
>> 
> 

Re: [Pharo-dev] Epicea - showing latest lost changes

[Martin Dias]

Uko: OK, added it as: https://pharo.fogbugz.com/f/cases/19768/Epicea-Lost-
Changes-Detector-Add-Apply-all-button-on-top-of-the-list-of-change

Stef: I see... each line should have a checkbox. I remember to see in
Spec's FastTableModel a method to enable that... I will try.

Ben: I think that's not necessary because the EpLostChangesDetector already
opens a browser where only the "lost changes" are visible. Where "lost
changes" means everything logged by Epicea after last Image Save. About
selection, I like it but in the past I had problems to programatically
select items in Spec wodget (a TreeModel) so don't have too much
expectatives for now... Maybe as checkboxes as Stef said.


Martín


On Mon, Feb 27, 2017 at 2:42 PM, Yuriy Tymchuk  wrote:

> Of course. For me it’s about 2 things:
>
> 1) I usually need to restore 100% of the changes, so having such button is
> convenient.
> 2) I think that newcomers will be confused if they just se a list without
> any hints what to do with it.
>
> Uko
>
> On 27 Feb 2017, at 05:41, Martin Dias  wrote:
>
>
>
> On Fri, Feb 24, 2017 at 12:04 PM, Yuriy Tymchuk 
> wrote:
>
>> I have one more suggestion for Epicea. When the window pops up I’d like
>> to have a big “RESTORE” button to reapply all the changes. I think it will
>> be also more user friendly, as how should an newcomer know that he has to
>> select all the items in the list and use the context menu.
>>
>
> Uko, maybe it could be an "Apply all" button on top of the list of changes?
>
>
>
>>
>> Cheers.
>> Uko
>>
>>
>> On 24 Feb 2017, at 08:33, stepharong  wrote:
>>
>> Hi martin
>>
>> Thanks for our constant improvement of epicea.
>> In VW they have a nice way to filter
>>
>> you can filter the entitiies
>>  doit or not
>>  method or not
>>  packages or not
>> and you can deselect a selected item.
>>
>> this way you can say I do not want any doit except this one.
>>
>>
>>
>> On Fri, 24 Feb 2017 06:29:36 +0100, Martin Dias 
>> wrote:
>>
>> Hi. Does this report match your idea?
>> https://pharo.fogbugz.com/f/cases/19686/Epicea-Filters
>>
>> Martin
>>
>> On Thu, Feb 23, 2017 at 3:35 PM, stepharong  wrote:
>>
>>> I agree :)
>>>
>>> On Wed, 22 Feb 2017 18:10:35 +0100, Ben Coman 
>>> wrote:
>>>
>>> One thing I am missing from Epicea that I used to be able to do
>>> is being able to filter out old changes.  If I've been thrashing
>>> some method back and forth between a few implementations,
>>> often I don't want to see *all* the old changes,only the latest ones.
>>>
>>> An option to restore old versions would also be nice, but I don't think
>>> that feature existed previously.
>>>
>>> cheers -ben
>>>
>>>
>>>
>>>
>>> --
>>> Using Opera's mail client: http://www.opera.com/mail/
>>>
>>
>>
>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
>>
>>
>
>

Re: [Pharo-dev] Epicea - showing latest lost changes

[Ben Coman]

On Tue, Feb 28, 2017 at 7:04 AM, Martin Dias  wrote:

> Uko: OK, added it as: https://pharo.fogbugz.com/
> f/cases/19768/Epicea-Lost-Changes-Detector-Add-Apply-all-
> button-on-top-of-the-list-of-change
>
> Stef: I see... each line should have a checkbox. I remember to see in
> Spec's FastTableModel a method to enable that... I will try.
>
> Ben: I think that's not necessary because the EpLostChangesDetector
> already opens a browser where only the "lost changes" are visible. Where
> "lost changes" means everything logged by Epicea after last Image Save.
>

I paid particular attention this time to starting after a crash and one
thing I'm uncertain about.
Its good that the window says "Lost Changes Detected"
but its not clear the meaning at the bottom where it says "22 filtered
entries"
Does this mean these 22 entries were not lost?
Or is it some other reason?
Also, I've a (only mild) concern that I can't see what these other entries
are, since I don't know if they are important?

Can you make it more explicit what the filter is?
Oh, after a while I realise there is a tab for this.
Perhaps at the bottom of the changes list
you could say   "22 filtered entries (see Active Filters tab)"
to help slow people like me.

So if 'remove all filters", what is the easy way to return to
the identical previous "Lost Changes" filter.
I realise now that I've been missing the old "indication of save points"
Then I guess I'd be able to select that line and filter "afterwards"

cheers -ben

Re: [Pharo-dev] Epicea - showing latest lost changes

[Martin Dias]

On Fri, Mar 3, 2017 at 1:55 AM, Ben Coman  wrote:

>
>
> On Tue, Feb 28, 2017 at 7:04 AM, Martin Dias  wrote:
>
>> Uko: OK, added it as: https://pharo.fogbugz.com/
>> f/cases/19768/Epicea-Lost-Changes-Detector-Add-Apply-all-but
>> ton-on-top-of-the-list-of-change
>>
>> Stef: I see... each line should have a checkbox. I remember to see in
>> Spec's FastTableModel a method to enable that... I will try.
>>
>> Ben: I think that's not necessary because the EpLostChangesDetector
>> already opens a browser where only the "lost changes" are visible. Where
>> "lost changes" means everything logged by Epicea after last Image Save.
>>
>
> I paid particular attention this time to starting after a crash and one
> thing I'm uncertain about.
> Its good that the window says "Lost Changes Detected"
> but its not clear the meaning at the bottom where it says "22 filtered
> entries"
> Does this mean these 22 entries were not lost?
> Or is it some other reason?
> Also, I've a (only mild) concern that I can't see what these other entries
> are, since I don't know if they are important?
>
>
Hi! you are the first one that mentions this "x filtered entries". Yes,
"filtered" like "hidden by a filter".

Casually, I've worked on its removal. Reasons: implementation is ugly; it
difficults time optimizations; it's not standard visually (I suspected
nobody undertand it). I'm also removing the "See 50 more" button, which
makes the list of changes look more as a standard list, to the user eyes.
I'm preparing a new release with these changes, and replacing the TreeModel
by a FastTableModel which is much better to scroll on the changes freely.


> Can you make it more explicit what the filter is?
> Oh, after a while I realise there is a tab for this.
> Perhaps at the bottom of the changes list
> you could say   "22 filtered entries (see Active Filters tab)"
> to help slow people like me.
>

For the moment, I only added the number of applied filters in the Tab's
title, like "Active filters (2)".


> So if 'remove all filters", what is the easy way to return to
> the identical previous "Lost Changes" filter.
> I realise now that I've been missing the old "indication of save points"
>

The "save points" were deactivated as a workaround the this bug:

https://pharo.fogbugz.com/f/cases/18374/

If we fix this case in another way, then we can restore the logging of
image save points (EpSessionSnapshot event).

Cheers
Martín

Then I guess I'd be able to select that line and filter "afterwards"
>
> cheers -ben
>
>

[Pharo-dev] Epicea: Revert the removal of a class

[Cyril Ferlicot D.]

Hi,

Today I tried to remove a class, go in Epicea and revert the removal of
the class.

At the end the class was here but with no methods. Is that the normal
behaviour? I think it is a bug but since I don't really use Epicea a lot
for know I am not sure.

Have a nice day.

-- 
Cyril Ferlicot
https://ferlicot.fr

http://www.synectique.eu
2 rue Jacques Prévert 01,
59650 Villeneuve d'ascq France



signature.asc
Description: OpenPGP digital signature

Re: [Pharo-dev] Epicea changes broken in latest 7

[Guillermo Polito]

I cannot reproduce it from here... does your file have non-ascii characters?

On Wed, Mar 14, 2018 at 10:55 AM, Sven Van Caekenberghe 
wrote:

> World Menu > Tools > Code Changes
>
> click on any change, boom.
>
> [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] in [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
> BlockClosure>>cull:
> Context>>evaluateSignal:
> Context>>handleSignal:
> Context>>handleSignal:
> MessageNotUnderstood(Exception)>>signal
> UndefinedObject(Object)>>doesNotUnderstand: #<
> ZnUTF8Encoder>>nextCodePointFromStream:
> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> ZnCharacterReadStream>>nextElement
> [ :out |
> | partialMatch pattern matched |
> partialMatch := (self collectionSpecies new: aCollection size)
> writeStream.
> pattern := aCollection readStream.
> matched := false.
> [ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
> whileFalse: [ | ch |
> (ch := self nextElement) = pattern next
> ifTrue: [ pattern atEnd
> ifTrue: [ matched := true ]
> ifFalse: [ partialMatch nextPut:
> ch ] ]
> ifFalse: [ pattern reset.
> out nextPutAll: partialMatch contents.
> partialMatch reset.
> out nextPut: ch ] ].
> matched
> ifFalse: [ out nextPutAll: partialMatch contents ] ] in
> ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
> String class(SequenceableCollection class)>>new:streamContents:
> String class(SequenceableCollection class)>>streamContents:
> ZnCharacterReadStream>>upToAll:
> [ stream upToAll: token ] in 
> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> in Block: [ stream upToAll: token ]
> BlockClosure>>on:do:
> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> OmSTONEntryReader>>entryPositionsDo:
> OmSTONEntryReader>>entryPositionsUpTo:
> [ :readStream |
> readStream position: startPosition.
> ^ self newEntryReader
> stream: readStream;
> entryPositionsUpTo: endPosition ] in 
> OmBlockFileStore>>entryPositionsStartingAt:upTo:
> in Block: [ :readStream | ...
> [ ^ aBlockClosure value: readStream ] in [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^
> aBlockClosure value: readStream ]
> BlockClosure>>on:do:
> [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream |
> ...
> [ aBlock value: stream ] in 
> FileReference(AbstractFileReference)>>readStreamDo:
> in Block: [ aBlock value: stream ]
> BlockClosure>>ensure:
> FileReference(AbstractFileReference)>>readStreamDo:
> OmBlockFileStore(OmFileStore)>>readEntriesWith:
> OmBlockFileStore>>entryPositionsStartingAt:upTo:
> OmBlock>>refresh
> OmBlock>>checkIfMustRefreshBlock
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] Epicea changes broken in latest 7

[Martin Dias]

Couldn't reproduce in latest Pharo 7 32 bits.

>From stack trace: it's strange that ZnUTF8Encoder>>nextCodePointFromStream:
got that nil when parsing the stream.

Martin

On Wed, Mar 14, 2018 at 8:32 AM, Guillermo Polito  wrote:

> I cannot reproduce it from here... does your file have non-ascii
> characters?
>
> On Wed, Mar 14, 2018 at 10:55 AM, Sven Van Caekenberghe 
> wrote:
>
>> World Menu > Tools > Code Changes
>>
>> click on any change, boom.
>>
>> [ :error |
>> (OmFileStoreReadingError
>> readingError: error
>> on: self fileReference
>> position: readStream position) signal ] in [ :readStream |
>> [ ^ aBlockClosure value: readStream ]
>> on: Error
>> do: [ :error |
>> (OmFileStoreReadingError
>> readingError: error
>> on: self fileReference
>> position: readStream position) signal ] ] in
>> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
>> BlockClosure>>cull:
>> Context>>evaluateSignal:
>> Context>>handleSignal:
>> Context>>handleSignal:
>> MessageNotUnderstood(Exception)>>signal
>> UndefinedObject(Object)>>doesNotUnderstand: #<
>> ZnUTF8Encoder>>nextCodePointFromStream:
>> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
>> ZnCharacterReadStream>>nextElement
>> [ :out |
>> | partialMatch pattern matched |
>> partialMatch := (self collectionSpecies new: aCollection size)
>> writeStream.
>> pattern := aCollection readStream.
>> matched := false.
>> [ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
>> whileFalse: [ | ch |
>> (ch := self nextElement) = pattern next
>> ifTrue: [ pattern atEnd
>> ifTrue: [ matched := true ]
>> ifFalse: [ partialMatch nextPut:
>> ch ] ]
>> ifFalse: [ pattern reset.
>> out nextPutAll: partialMatch contents.
>> partialMatch reset.
>> out nextPut: ch ] ].
>> matched
>> ifFalse: [ out nextPutAll: partialMatch contents ] ] in
>> ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
>> String class(SequenceableCollection class)>>new:streamContents:
>> String class(SequenceableCollection class)>>streamContents:
>> ZnCharacterReadStream>>upToAll:
>> [ stream upToAll: token ] in 
>> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
>> in Block: [ stream upToAll: token ]
>> BlockClosure>>on:do:
>> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
>> OmSTONEntryReader>>entryPositionsDo:
>> OmSTONEntryReader>>entryPositionsUpTo:
>> [ :readStream |
>> readStream position: startPosition.
>> ^ self newEntryReader
>> stream: readStream;
>> entryPositionsUpTo: endPosition ] in
>> OmBlockFileStore>>entryPositionsStartingAt:upTo: in Block: [ :readStream
>> | ...
>> [ ^ aBlockClosure value: readStream ] in [ :readStream |
>> [ ^ aBlockClosure value: readStream ]
>> on: Error
>> do: [ :error |
>> (OmFileStoreReadingError
>> readingError: error
>> on: self fileReference
>> position: readStream position) signal ] ] in
>> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^
>> aBlockClosure value: readStream ]
>> BlockClosure>>on:do:
>> [ :readStream |
>> [ ^ aBlockClosure value: readStream ]
>> on: Error
>> do: [ :error |
>> (OmFileStoreReadingError
>> readingError: error
>> on: self fileReference
>> position: readStream position) signal ] ] in
>> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream
>> | ...
>> [ aBlock value: stream ] in 
>> FileReference(AbstractFileReference)>>readStreamDo:
>> in Block: [ aBlock value: stream ]
>> BlockClosure>>ensure:
>> FileReference(AbstractFileReference)>>readStreamDo:
>> OmBlockFileStore(OmFileStore)>>readEntriesWith:
>> OmBlockFileStore>>entryPositionsStartingAt:upTo:
>> OmBlock>>refresh
>> OmBlock>>checkIfMustRefreshBlock
>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13
>

Re: [Pharo-dev] Epicea changes broken in latest 7

[Sven Van Caekenberghe]

Argh, yes, I am sorry. I can no longer reproduce it either, must have occurred 
in a hacking image.

I tested with the latest 7 and all was OK, even with a full Unicode comment like

foo
"élève Français - 100 €"

^ foo

> On 20 Mar 2018, at 17:12, Martin Dias  wrote:
> 
> Couldn't reproduce in latest Pharo 7 32 bits. 
> 
> From stack trace: it's strange that ZnUTF8Encoder>>nextCodePointFromStream: 
> got that nil when parsing the stream.
> 
> Martin
> 
> On Wed, Mar 14, 2018 at 8:32 AM, Guillermo Polito  
> wrote:
> I cannot reproduce it from here... does your file have non-ascii characters?
> 
> On Wed, Mar 14, 2018 at 10:55 AM, Sven Van Caekenberghe  wrote:
> World Menu > Tools > Code Changes
> 
> click on any change, boom.
> 
> [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] in [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in 
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
> BlockClosure>>cull:
> Context>>evaluateSignal:
> Context>>handleSignal:
> Context>>handleSignal:
> MessageNotUnderstood(Exception)>>signal
> UndefinedObject(Object)>>doesNotUnderstand: #<
> ZnUTF8Encoder>>nextCodePointFromStream:
> ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> ZnCharacterReadStream>>nextElement
> [ :out |
> | partialMatch pattern matched |
> partialMatch := (self collectionSpecies new: aCollection size)
> writeStream.
> pattern := aCollection readStream.
> matched := false.
> [ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
> whileFalse: [ | ch |
> (ch := self nextElement) = pattern next
> ifTrue: [ pattern atEnd
> ifTrue: [ matched := true ]
> ifFalse: [ partialMatch nextPut: ch ] 
> ]
> ifFalse: [ pattern reset.
> out nextPutAll: partialMatch contents.
> partialMatch reset.
> out nextPut: ch ] ].
> matched
> ifFalse: [ out nextPutAll: partialMatch contents ] ] in 
> ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
> String class(SequenceableCollection class)>>new:streamContents:
> String class(SequenceableCollection class)>>streamContents:
> ZnCharacterReadStream>>upToAll:
> [ stream upToAll: token ] in 
> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone: in Block: [ stream 
> upToAll: token ]
> BlockClosure>>on:do:
> OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> OmSTONEntryReader>>entryPositionsDo:
> OmSTONEntryReader>>entryPositionsUpTo:
> [ :readStream |
> readStream position: startPosition.
> ^ self newEntryReader
> stream: readStream;
> entryPositionsUpTo: endPosition ] in 
> OmBlockFileStore>>entryPositionsStartingAt:upTo: in Block: [ :readStream | ...
> [ ^ aBlockClosure value: readStream ] in [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in 
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure 
> value: readStream ]
> BlockClosure>>on:do:
> [ :readStream |
> [ ^ aBlockClosure value: readStream ]
> on: Error
> do: [ :error |
> (OmFileStoreReadingError
> readingError: error
> on: self fileReference
> position: readStream position) signal ] ] in 
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream | ...
> [ aBlock value: stream ] in 
> FileReference(AbstractFileReference)>>readStreamDo: in Block: [ aBlock value: 
> stream ]
> BlockClosure>>ensure:
> FileReference(AbstractFileReference)>>readStreamDo:
> OmBlockFileStore(OmFileStore)>>readEntriesWith:
> OmBlockFileStore>>entryPositionsStartingAt:upTo:
> OmBlock>>refresh
> OmBlock>>checkIfMustRefreshBlock
> 
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr
> 
> Web: http://guillep.github.io
> Phone: +33 06 52 70 66 13
> 

Re: [Pharo-dev] Epicea changes broken in latest 7

[Damien Pollet]

I can perfectly reproduce, in fact I've had to copy-paste by hand from the
changes file and switched back to a 6.1 image to be able to do any work on
Clap.
Perhaps this is triggered by the actual contents of the ombu files?

On 20 March 2018 at 17:26, Sven Van Caekenberghe  wrote:

> Argh, yes, I am sorry. I can no longer reproduce it either, must have
> occurred in a hacking image.
>
> I tested with the latest 7 and all was OK, even with a full Unicode
> comment like
>
> foo
> "élève Français - 100 €"
>
> ^ foo
>
> > On 20 Mar 2018, at 17:12, Martin Dias  wrote:
> >
> > Couldn't reproduce in latest Pharo 7 32 bits.
> >
> > From stack trace: it's strange that ZnUTF8Encoder>>nextCodePointFromStream:
> got that nil when parsing the stream.
> >
> > Martin
> >
> > On Wed, Mar 14, 2018 at 8:32 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
> > I cannot reproduce it from here... does your file have non-ascii
> characters?
> >
> > On Wed, Mar 14, 2018 at 10:55 AM, Sven Van Caekenberghe 
> wrote:
> > World Menu > Tools > Code Changes
> >
> > click on any change, boom.
> >
> > [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] in [ :readStream |
> > [ ^ aBlockClosure value: readStream ]
> > on: Error
> > do: [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
> > BlockClosure>>cull:
> > Context>>evaluateSignal:
> > Context>>handleSignal:
> > Context>>handleSignal:
> > MessageNotUnderstood(Exception)>>signal
> > UndefinedObject(Object)>>doesNotUnderstand: #<
> > ZnUTF8Encoder>>nextCodePointFromStream:
> > ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> > ZnCharacterReadStream>>nextElement
> > [ :out |
> > | partialMatch pattern matched |
> > partialMatch := (self collectionSpecies new: aCollection size)
> > writeStream.
> > pattern := aCollection readStream.
> > matched := false.
> > [ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
> > whileFalse: [ | ch |
> > (ch := self nextElement) = pattern next
> > ifTrue: [ pattern atEnd
> > ifTrue: [ matched := true ]
> > ifFalse: [ partialMatch nextPut:
> ch ] ]
> > ifFalse: [ pattern reset.
> > out nextPutAll: partialMatch contents.
> > partialMatch reset.
> > out nextPut: ch ] ].
> > matched
> > ifFalse: [ out nextPutAll: partialMatch contents ] ] in
> ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
> > String class(SequenceableCollection class)>>new:streamContents:
> > String class(SequenceableCollection class)>>streamContents:
> > ZnCharacterReadStream>>upToAll:
> > [ stream upToAll: token ] in OmSTONEntryReader>>
> nextEntryPositionIfFound:ifNone: in Block: [ stream upToAll: token ]
> > BlockClosure>>on:do:
> > OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> > OmSTONEntryReader>>entryPositionsDo:
> > OmSTONEntryReader>>entryPositionsUpTo:
> > [ :readStream |
> > readStream position: startPosition.
> > ^ self newEntryReader
> > stream: readStream;
> > entryPositionsUpTo: endPosition ] in 
> > OmBlockFileStore>>entryPositionsStartingAt:upTo:
> in Block: [ :readStream | ...
> > [ ^ aBlockClosure value: readStream ] in [ :readStream |
> > [ ^ aBlockClosure value: readStream ]
> > on: Error
> > do: [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^
> aBlockClosure value: readStream ]
> > BlockClosure>>on:do:
> > [ :readStream |
> > [ ^ aBlockClosure value: readStream ]
> > on: Error
> > do: [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream |
> ...
> > [ aBlock value: stream ] in 
> > FileReference(AbstractFileReference)>>readStreamDo:
> in Block: [ aBlock value: stream ]
> > BlockClosure>>ensure:
> > FileReference(AbstractFileReference)>>readStreamDo:
> > OmBlockFileStore(OmFileStore)>>readEntriesWith:
> > OmBlockFileStore>>entryPositionsStartingAt:upTo:
> > OmBlock>>refresh
> > OmBlock>>checkIfMustRefreshBlock
> >
> >
> >
> >
> >
> > --
> >
> > Guille Polito
> > Resea

Re: [Pharo-dev] Epicea changes broken in latest 7

[Sven Van Caekenberghe]

> On 20 Mar 2018, at 17:31, Damien Pollet  wrote:
> 
> I can perfectly reproduce, in fact I've had to copy-paste by hand from the 
> changes file and switched back to a 6.1 image to be able to do any work on 
> Clap.
> Perhaps this is triggered by the actual contents of the ombu files?

Probably.

Can you describe a reproducible scenario ?

> On 20 March 2018 at 17:26, Sven Van Caekenberghe  wrote:
> Argh, yes, I am sorry. I can no longer reproduce it either, must have 
> occurred in a hacking image.
> 
> I tested with the latest 7 and all was OK, even with a full Unicode comment 
> like
> 
> foo
> "élève Français - 100 €"
> 
> ^ foo
> 
> > On 20 Mar 2018, at 17:12, Martin Dias  wrote:
> >
> > Couldn't reproduce in latest Pharo 7 32 bits.
> >
> > From stack trace: it's strange that ZnUTF8Encoder>>nextCodePointFromStream: 
> > got that nil when parsing the stream.
> >
> > Martin
> >
> > On Wed, Mar 14, 2018 at 8:32 AM, Guillermo Polito 
> >  wrote:
> > I cannot reproduce it from here... does your file have non-ascii characters?
> >
> > On Wed, Mar 14, 2018 at 10:55 AM, Sven Van Caekenberghe  
> > wrote:
> > World Menu > Tools > Code Changes
> >
> > click on any change, boom.
> >
> > [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] in [ :readStream |
> > [ ^ aBlockClosure value: readStream ]
> > on: Error
> > do: [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] ] in 
> > OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
> > BlockClosure>>cull:
> > Context>>evaluateSignal:
> > Context>>handleSignal:
> > Context>>handleSignal:
> > MessageNotUnderstood(Exception)>>signal
> > UndefinedObject(Object)>>doesNotUnderstand: #<
> > ZnUTF8Encoder>>nextCodePointFromStream:
> > ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> > ZnCharacterReadStream>>nextElement
> > [ :out |
> > | partialMatch pattern matched |
> > partialMatch := (self collectionSpecies new: aCollection size)
> > writeStream.
> > pattern := aCollection readStream.
> > matched := false.
> > [ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
> > whileFalse: [ | ch |
> > (ch := self nextElement) = pattern next
> > ifTrue: [ pattern atEnd
> > ifTrue: [ matched := true ]
> > ifFalse: [ partialMatch nextPut: ch 
> > ] ]
> > ifFalse: [ pattern reset.
> > out nextPutAll: partialMatch contents.
> > partialMatch reset.
> > out nextPut: ch ] ].
> > matched
> > ifFalse: [ out nextPutAll: partialMatch contents ] ] in 
> > ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
> > String class(SequenceableCollection class)>>new:streamContents:
> > String class(SequenceableCollection class)>>streamContents:
> > ZnCharacterReadStream>>upToAll:
> > [ stream upToAll: token ] in 
> > OmSTONEntryReader>>nextEntryPositionIfFound:ifNone: in Block: [ stream 
> > upToAll: token ]
> > BlockClosure>>on:do:
> > OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> > OmSTONEntryReader>>entryPositionsDo:
> > OmSTONEntryReader>>entryPositionsUpTo:
> > [ :readStream |
> > readStream position: startPosition.
> > ^ self newEntryReader
> > stream: readStream;
> > entryPositionsUpTo: endPosition ] in 
> > OmBlockFileStore>>entryPositionsStartingAt:upTo: in Block: [ :readStream | 
> > ...
> > [ ^ aBlockClosure value: readStream ] in [ :readStream |
> > [ ^ aBlockClosure value: readStream ]
> > on: Error
> > do: [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] ] in 
> > OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^ aBlockClosure 
> > value: readStream ]
> > BlockClosure>>on:do:
> > [ :readStream |
> > [ ^ aBlockClosure value: readStream ]
> > on: Error
> > do: [ :error |
> > (OmFileStoreReadingError
> > readingError: error
> > on: self fileReference
> > position: readStream position) signal ] ] in 
> > OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :readStream | 
> > ...
> > [ aBlock value: stream ] in 
> > FileReference(AbstractFileReference)>>readStreamDo: in Block: [ aBlock 
> > value: stream ]
> > BlockClosure>>ensure:
> > FileReference(AbstractFileReference)>>readStreamDo:
> > OmBlockFileStore(OmFileStore)>>readEntriesWith:
> > OmBlockFileStore>>entryPo

Re: [Pharo-dev] Epicea changes broken in latest 7

[Damien Pollet]

Trying to open Epicea in at least one project on my machine ;-)

Perhaps it's best if I check with Guille in person tomorrow.

On 20 March 2018 at 18:36, Sven Van Caekenberghe  wrote:

>
>
> > On 20 Mar 2018, at 17:31, Damien Pollet  wrote:
> >
> > I can perfectly reproduce, in fact I've had to copy-paste by hand from
> the changes file and switched back to a 6.1 image to be able to do any work
> on Clap.
> > Perhaps this is triggered by the actual contents of the ombu files?
>
> Probably.
>
> Can you describe a reproducible scenario ?
>
> > On 20 March 2018 at 17:26, Sven Van Caekenberghe  wrote:
> > Argh, yes, I am sorry. I can no longer reproduce it either, must have
> occurred in a hacking image.
> >
> > I tested with the latest 7 and all was OK, even with a full Unicode
> comment like
> >
> > foo
> > "élève Français - 100 €"
> >
> > ^ foo
> >
> > > On 20 Mar 2018, at 17:12, Martin Dias  wrote:
> > >
> > > Couldn't reproduce in latest Pharo 7 32 bits.
> > >
> > > From stack trace: it's strange that 
> > > ZnUTF8Encoder>>nextCodePointFromStream:
> got that nil when parsing the stream.
> > >
> > > Martin
> > >
> > > On Wed, Mar 14, 2018 at 8:32 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
> > > I cannot reproduce it from here... does your file have non-ascii
> characters?
> > >
> > > On Wed, Mar 14, 2018 at 10:55 AM, Sven Van Caekenberghe 
> wrote:
> > > World Menu > Tools > Code Changes
> > >
> > > click on any change, boom.
> > >
> > > [ :error |
> > > (OmFileStoreReadingError
> > > readingError: error
> > > on: self fileReference
> > > position: readStream position) signal ] in [ :readStream |
> > > [ ^ aBlockClosure value: readStream ]
> > > on: Error
> > > do: [ :error |
> > > (OmFileStoreReadingError
> > > readingError: error
> > > on: self fileReference
> > > position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ :error | ...
> > > BlockClosure>>cull:
> > > Context>>evaluateSignal:
> > > Context>>handleSignal:
> > > Context>>handleSignal:
> > > MessageNotUnderstood(Exception)>>signal
> > > UndefinedObject(Object)>>doesNotUnderstand: #<
> > > ZnUTF8Encoder>>nextCodePointFromStream:
> > > ZnUTF8Encoder(ZnCharacterEncoder)>>nextFromStream:
> > > ZnCharacterReadStream>>nextElement
> > > [ :out |
> > > | partialMatch pattern matched |
> > > partialMatch := (self collectionSpecies new: aCollection size)
> > > writeStream.
> > > pattern := aCollection readStream.
> > > matched := false.
> > > [ matched or: [ self atEnd or: [ pattern atEnd ] ] ]
> > > whileFalse: [ | ch |
> > > (ch := self nextElement) = pattern next
> > > ifTrue: [ pattern atEnd
> > > ifTrue: [ matched := true ]
> > > ifFalse: [ partialMatch
> nextPut: ch ] ]
> > > ifFalse: [ pattern reset.
> > > out nextPutAll: partialMatch contents.
> > > partialMatch reset.
> > > out nextPut: ch ] ].
> > > matched
> > > ifFalse: [ out nextPutAll: partialMatch contents ] ] in
> ZnCharacterReadStream>>upToAll: in Block: [ :out | ...
> > > String class(SequenceableCollection class)>>new:streamContents:
> > > String class(SequenceableCollection class)>>streamContents:
> > > ZnCharacterReadStream>>upToAll:
> > > [ stream upToAll: token ] in OmSTONEntryReader>>
> nextEntryPositionIfFound:ifNone: in Block: [ stream upToAll: token ]
> > > BlockClosure>>on:do:
> > > OmSTONEntryReader>>nextEntryPositionIfFound:ifNone:
> > > OmSTONEntryReader>>entryPositionsDo:
> > > OmSTONEntryReader>>entryPositionsUpTo:
> > > [ :readStream |
> > > readStream position: startPosition.
> > > ^ self newEntryReader
> > > stream: readStream;
> > > entryPositionsUpTo: endPosition ] in 
> > > OmBlockFileStore>>entryPositionsStartingAt:upTo:
> in Block: [ :readStream | ...
> > > [ ^ aBlockClosure value: readStream ] in [ :readStream |
> > > [ ^ aBlockClosure value: readStream ]
> > > on: Error
> > > do: [ :error |
> > > (OmFileStoreReadingError
> > > readingError: error
> > > on: self fileReference
> > > position: readStream position) signal ] ] in
> OmBlockFileStore(OmFileStore)>>readEntriesWith: in Block: [ ^
> aBlockClosure value: readStream ]
> > > BlockClosure>>on:do:
> > > [ :readStream |
> > > [ ^ aBlockClosure value: readStream ]
> > > on: Error
> > > do: [ :error |
> > > (OmFileStoreReadingError
> > > readingError: error
> > > on: self fileReference
> > > position: readStream position) signal