Le 28/05/2015 20:40, Nicolai Hess a écrit :
2015-05-28 16:55 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com
<mailto:thierry.goub...@gmail.com>>:
2015-05-28 16:49 GMT+02:00 Nicolai Hess <nicolaih...@web.de
<mailto:nicolaih...@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.
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.
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
