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 <nicolaih...@web.de> wrote: > > > > 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
