On 28 May 2015, at 18:34, Guillermo Polito <guillermopolito@gmail.com> wrote:

Today we were discussing about that with Camille. Actually we would like to split the current compile into:

- compile: just compiles and returns the compiled method. The method is not installed in the class. Nobody knows it's there. - install: it properly installs the method in the class, and notifies whoever needs installs it.

Compiling is always silent by default, as it has not really an effect in the system. Then, the silentliness should be in the install part. Even, logging the source code in whatever source code representation we want (now the changes file) should be part of the installation (and pluggable).

That’s a great idea! Just one request: please keep a single selector to do compilation + installation (what #compile: currently does). That’s very convenient and it’s the bevhaviour you (I) usually want. Cheers, Max

El jue., 28 de may. de 2015 a la(s) 4:55 p. m., Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> escribió: 2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>>: How silent should "compileSilently" be?

no trace in the system : 15314 <https://pharo.fogbugz.com/default.asp?15314> compileSilently and method history / changes file

not half silenlty 13023 <https://pharo.fogbugz.com/default.asp?13023> Test Cases should not do things half silently

not "SystemAnnouncer-silent" 10560 <https://pharo.fogbugz.com/default.asp?10560> SystemAnnouncer and compileSilently

?

What do you think, what granularity of "silent" do we need. I see at least three different use cases:

- just an ordinary compile

? Silent means that: Core infrastructure is not updated properly (i.e. RPackage) and tools (Browsers) can end desynchronised with the methods.

- compile for tests

Probably the one... But I wonder if this is a good idea anyway. I'd believe most tests using silently are using it wrongly and shouldn't be using it in the first place.

- compile autogenerated methods.

This one may not be silent. If the auto-generated method will be visible (saved in a package, can be browsed, etc...) then it shouldn't be silent.

Thierry

nicolai

2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess@web.de>:

...

How silent should "compileSilently" be?

no trace in the system : 15314 <https://pharo.fogbugz.com/default.asp?15314> compileSilently and method history / changes file

not half silenlty 13023 <https://pharo.fogbugz.com/default.asp?13023> Test Cases should not do things half silently

not "SystemAnnouncer-silent" 10560 <https://pharo.fogbugz.com/default.asp?10560> SystemAnnouncer and compileSilently

?

What do you think, what granularity of "silent" do we need. I see at least three different use cases:

- just an ordinary compile

? Silent means that: Core infrastructure is not updated properly (i.e. RPackage) and tools (Browsers) can end desynchronised with the methods.

...

- compile for tests

Probably the one... But I wonder if this is a good idea anyway. I'd believe most tests using silently are using it wrongly and shouldn't be using it in the first place.

...

- compile autogenerated methods.

This one may not be silent. If the auto-generated method will be visible (saved in a package, can be browsed, etc...) then it shouldn't be silent.

What about compiled method for which the source did not change? I am interested on this for issue 15315, everytime you open spotter, you'll get a new "method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015 20:34" in you changes file. Another case are autogenerated methods from NativeBoost. For example, open a fresh image and execute code that triggers NativeBoost to install native functions for this session. (EllipseMorph new openInSceneView) And now look at your list of recent changes. I get about 30 entries for athens/cairo methods.

Thierry

...

nicolai

2015-05-28 21:14 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

Le 28/05/2015 20:40, Nicolai Hess a écrit :

...

2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:

2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>>:

How silent should "compileSilently" be?

no trace in the system : 15314 <https://pharo.fogbugz.com/default.asp?15314> compileSilently and method history / changes file

not half silenlty 13023 <https://pharo.fogbugz.com/default.asp?13023> Test Cases should not do things half silently

not "SystemAnnouncer-silent" 10560 <https://pharo.fogbugz.com/default.asp?10560> SystemAnnouncer and compileSilently

?

What do you think, what granularity of "silent" do we need. I see at least three different use cases:

- just an ordinary compile

? Silent means that: Core infrastructure is not updated properly (i.e. RPackage) and tools (Browsers) can end desynchronised with the methods.

- compile for tests

Probably the one... But I wonder if this is a good idea anyway. I'd believe most tests using silently are using it wrongly and shouldn't be using it in the first place.

- compile autogenerated methods.

This one may not be silent. If the auto-generated method will be visible (saved in a package, can be browsed, etc...) then it shouldn't be silent.

What about compiled method for which the source did not change?

Hum. I see what you mean.

I do silent compilation when I install tracing probes inside methods, to make sure they don't appear as changed in browsers... But I don't create new methods. I guess this will be the same with the MetaLinks Marcus is preparing.

But, yes, as I said: methods or changes that are not visible then you can make them silent.

But in a different case, such as compiling a SmaCC parser, you want that code to be visible.

For NativeBoost generated methods, I may want to have that code visible too. I just don't want the code to be marked as "changed" after a recompilation. For example, a subclass of NativeBoosts NBExternalStructure or NBExternalArray must be recompiled when used in a new session, or when the structure changed. The compiler installs the generated accessor methods and you may want to see that code - just to make sure the structure change was applied. But you really don't want this code in a changeset, because whenever you use this code in another image or in a new session it will be recompiled anyway.

I am interested on this for issue 15315, everytime you open spotter,

...

you'll get a new

"method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015 20:34"

in you changes file.

This one makes for some annoying noise in the changes. But as I say below, maybe it doesn't matter.

Another case are autogenerated methods from NativeBoost.

...

For example, open a fresh image and execute code that triggers NativeBoost to install native functions for this session. (EllipseMorph new openInSceneView)

And now look at your list of recent changes. I get about 30 entries for athens/cairo methods.

One of the thing to consider is what you use the changes for. If it is to recover from crashes, then what you just need to make sure is that replaying all since the last save is ok... even if you have multiple times the same method source saved in it.

Yes, you are right. It does not hurt to have this in the changes file. (But it does not have any use to be there).

True changes management is happening in the packages these days, and most code written in the changes shouldn't be recorded there imho (oh, well, apart for the source pointer, of course).

And other uses it could have (recording all do its, for example) is reimplemented / duplicated elsewhere in the system anyway.

Thierry

Not known, but the whole #prepareDebuggerExample method is very strange. We should remove it.

On 29 Jul 2015, at 16:05, roberto.minelli@usi.ch wrote:

Hi,

I don’t know if this is related, but recently happens something super strange to my images.

From time to time, in one of my commits the author is suddenly changed to ‘AutoGenTutorial’ and, if I don’t spot this, from now on the Pharo image stops recording my changes.

This is very frustrating.. is this a known issue?

Thanks a lot, RM

...

On 30 May 2015, at 06:01, Nicolai Hess <nicolaihess@web.de> wrote:

2015-05-28 21:14 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>: Le 28/05/2015 20:40, Nicolai Hess a écrit :

2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:

2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>>:

How silent should "compileSilently" be?

no trace in the system : 15314 <https://pharo.fogbugz.com/default.asp?15314> compileSilently and method history / changes file

not half silenlty 13023 <https://pharo.fogbugz.com/default.asp?13023> Test Cases should not do things half silently

not "SystemAnnouncer-silent" 10560 <https://pharo.fogbugz.com/default.asp?10560> SystemAnnouncer and compileSilently

?

What do you think, what granularity of "silent" do we need. I see at least three different use cases:

- just an ordinary compile

? Silent means that: Core infrastructure is not updated properly (i.e. RPackage) and tools (Browsers) can end desynchronised with the methods.

- compile for tests

Probably the one... But I wonder if this is a good idea anyway. I'd believe most tests using silently are using it wrongly and shouldn't be using it in the first place.

- compile autogenerated methods.

This one may not be silent. If the auto-generated method will be visible (saved in a package, can be browsed, etc...) then it shouldn't be silent.

What about compiled method for which the source did not change?

Hum. I see what you mean.

I do silent compilation when I install tracing probes inside methods, to make sure they don't appear as changed in browsers... But I don't create new methods. I guess this will be the same with the MetaLinks Marcus is preparing.

But, yes, as I said: methods or changes that are not visible then you can make them silent.

But in a different case, such as compiling a SmaCC parser, you want that code to be visible.

For NativeBoost generated methods, I may want to have that code visible too. I just don't want the code to be marked as "changed" after a recompilation.

For example, a subclass of NativeBoosts NBExternalStructure or NBExternalArray must be recompiled when used in a new session, or when the structure changed.

The compiler installs the generated accessor methods and you may want to see that code - just to make sure the structure change was applied. But you really don't want this code in a changeset, because whenever you use this code in another image or in a new session it will be recompiled anyway.

I am interested on this for issue 15315, everytime you open spotter, you'll get a new

"method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015 20:34"

in you changes file.

This one makes for some annoying noise in the changes. But as I say below, maybe it doesn't matter.

Another case are autogenerated methods from NativeBoost. For example, open a fresh image and execute code that triggers NativeBoost to install native functions for this session. (EllipseMorph new openInSceneView)

And now look at your list of recent changes. I get about 30 entries for athens/cairo methods.

One of the thing to consider is what you use the changes for. If it is to recover from crashes, then what you just need to make sure is that replaying all since the last save is ok... even if you have multiple times the same method source saved in it.

Yes, you are right. It does not hurt to have this in the changes file. (But it does not have any use to be there).

True changes management is happening in the packages these days, and most code written in the changes shouldn't be recorded there imho (oh, well, apart for the source pointer, of course).

And other uses it could have (recording all do its, for example) is reimplemented / duplicated elsewhere in the system anyway.

Thierry

Yeah, I also removed #prepareDebuggerExample from my image... It is the third time in the last two weeks that this happens to me and I have to spend lot of time to recover the changes from one image to the other. Cheers, R

On 29 Jul 2015, at 11:16, Marcus Denker <marcus.denker@inria.fr> wrote:

Not known, but the whole #prepareDebuggerExample method is very strange. We should remove it.

...

On 29 Jul 2015, at 16:05, roberto.minelli@usi.ch wrote:

Hi,

I don’t know if this is related, but recently happens something super strange to my images.

From time to time, in one of my commits the author is suddenly changed to ‘AutoGenTutorial’ and, if I don’t spot this, from now on the Pharo image stops recording my changes.

This is very frustrating.. is this a known issue?

Thanks a lot, RM

...

On 30 May 2015, at 06:01, Nicolai Hess <nicolaihess@web.de> wrote:

2015-05-28 21:14 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>: Le 28/05/2015 20:40, Nicolai Hess a écrit :

2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>:

2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>>:

How silent should "compileSilently" be?

no trace in the system : 15314 <https://pharo.fogbugz.com/default.asp?15314> compileSilently and method history / changes file

not half silenlty 13023 <https://pharo.fogbugz.com/default.asp?13023> Test Cases should not do things half silently

not "SystemAnnouncer-silent" 10560 <https://pharo.fogbugz.com/default.asp?10560> SystemAnnouncer and compileSilently

?

What do you think, what granularity of "silent" do we need. I see at least three different use cases:

- just an ordinary compile

? Silent means that: Core infrastructure is not updated properly (i.e. RPackage) and tools (Browsers) can end desynchronised with the methods.

- compile for tests

Probably the one... But I wonder if this is a good idea anyway. I'd believe most tests using silently are using it wrongly and shouldn't be using it in the first place.

- compile autogenerated methods.

This one may not be silent. If the auto-generated method will be visible (saved in a package, can be browsed, etc...) then it shouldn't be silent.

What about compiled method for which the source did not change?

Hum. I see what you mean.

I do silent compilation when I install tracing probes inside methods, to make sure they don't appear as changed in browsers... But I don't create new methods. I guess this will be the same with the MetaLinks Marcus is preparing.

But, yes, as I said: methods or changes that are not visible then you can make them silent.

But in a different case, such as compiling a SmaCC parser, you want that code to be visible.

For NativeBoost generated methods, I may want to have that code visible too. I just don't want the code to be marked as "changed" after a recompilation.

For example, a subclass of NativeBoosts NBExternalStructure or NBExternalArray must be recompiled when used in a new session, or when the structure changed.

The compiler installs the generated accessor methods and you may want to see that code - just to make sure the structure change was applied. But you really don't want this code in a changeset, because whenever you use this code in another image or in a new session it will be recompiled anyway.

I am interested on this for issue 15315, everytime you open spotter, you'll get a new

"method: PharoSyntaxTutorial divideTwoByZero; AutoGenTutorial 5/28/2015 20:34"

in you changes file.

This one makes for some annoying noise in the changes. But as I say below, maybe it doesn't matter.

Another case are autogenerated methods from NativeBoost. For example, open a fresh image and execute code that triggers NativeBoost to install native functions for this session. (EllipseMorph new openInSceneView)

And now look at your list of recent changes. I get about 30 entries for athens/cairo methods.

One of the thing to consider is what you use the changes for. If it is to recover from crashes, then what you just need to make sure is that replaying all since the last save is ok... even if you have multiple times the same method source saved in it.

Yes, you are right. It does not hurt to have this in the changes file. (But it does not have any use to be there).

True changes management is happening in the packages these days, and most code written in the changes shouldn't be recorded there imho (oh, well, apart for the source pointer, of course).

And other uses it could have (recording all do its, for example) is reimplemented / duplicated elsewhere in the system anyway.

Thierry