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 :
compileSilently and method history / changes file

not half silenlty
Test Cases should not do things half silently

not "SystemAnnouncer-silent"
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