2015-05-28 21:14 GMT+02:00 Thierry Goubier <thierry.goub...@gmail.com>:
> 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. > 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 >
