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.den...@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.mine...@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 <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 >> > >
