About "compileSilently"
Locked
 
|
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 - compile for tests - compile autogenerated methods. nicolai |
|
|
2015-05-28 16:49 GMT+02:00 Nicolai Hess <[hidden email]>:
? Silent means that: Core infrastructure is not updated properly (i.e. RPackage) and tools (Browsers) can end desynchronised with the methods.
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.
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. Thierry
|
|
|
Today we were discussing about that with Camille. Actually we would like to split the current compile into: - compile: just compiles and returns the compiled method. The method is not installed in the class. Nobody knows it's there. - install: it properly installs the method in the class, and notifies whoever needs installs it. Compiling is always silent by default, as it has not really an effect in the system. Then, the silentliness should be in the install part. Even, logging the source code in whatever source code representation we want (now the changes file) should be part of the installation (and pluggable). El jue., 28 de may. de 2015 a la(s) 4:55 p. m., Thierry Goubier <[hidden email]> escribió:
|
|
|
That’s a great idea! Just one request: please keep a single selector to do compilation + installation (what #compile: currently does). That’s very convenient and it’s the bevhaviour you (I) usually want. Cheers, Max
|
|
|
Le 28/05/2015 18:52, Max Leske a écrit :
> >> On 28 May 2015, at 18:34, Guillermo Polito <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Today we were discussing about that with Camille. Actually we would >> like to split the current compile into: >> >> - compile: just compiles and returns the compiled method. The method >> is not installed in the class. Nobody knows it's there. >> - install: it properly installs the method in the class, and notifies >> whoever needs installs it. >> >> Compiling is always silent by default, as it has not really an effect >> in the system. Then, the silentliness should be in the install >> part. Even, logging the source code in whatever source code >> representation we want (now the changes file) should be part of the >> installation (and pluggable). > > That’s a great idea! > Just one request: please keep a single selector to do compilation + > installation (what #compile: currently does). That’s very convenient and > it’s the bevhaviour you (I) usually want. +1 to both :) And maybe a bit of howto to explain how tests can properly install and remove cleanly temporary code by defining them as refactoring (RB) operations. Thierry > Cheers, > Max > > >> >> >> El jue., 28 de may. de 2015 a la(s) 4:55 p. m., Thierry Goubier >> <[hidden email] <mailto:[hidden email]>> escribió: >> >> 2015-05-28 16:49 GMT+02:00 Nicolai Hess <[hidden email] >> <mailto:[hidden email]>>: >> >> 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. >> >> Thierry >> >> >> >> >> >> nicolai >> >> > |
|
|
In reply to this post by Thierry Goubier
2015-05-28 16:55 GMT+02:00 Thierry Goubier <[hidden email]>:
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.
|
|
|
Le 28/05/2015 20:40, Nicolai Hess a écrit :
> > > 2015-05-28 16:55 GMT+02:00 Thierry Goubier <[hidden email] > <mailto:[hidden email]>>: > > > > 2015-05-28 16:49 GMT+02:00 Nicolai Hess <[hidden email] > <mailto:[hidden email]>>: > > 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 |
|
|
2015-05-28 21:14 GMT+02:00 Thierry Goubier <[hidden email]>: Le 28/05/2015 20:40, Nicolai Hess a écrit : 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.
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).
|
Re: About "compileSilently"
|
|
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 <[hidden email]> wrote: > > > > 2015-05-28 21:14 GMT+02:00 Thierry Goubier <[hidden email]>: > Le 28/05/2015 20:40, Nicolai Hess a écrit : > > > 2015-05-28 16:55 GMT+02:00 Thierry Goubier <[hidden email] > <mailto:[hidden email]>>: > > > > 2015-05-28 16:49 GMT+02:00 Nicolai Hess <[hidden email] > <mailto:[hidden email]>>: > > 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 |
|
|
Not known, but the whole #prepareDebuggerExample method is very strange. We should remove it.
> On 29 Jul 2015, at 16:05, [hidden email] 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 <[hidden email]> wrote: >> >> >> >> 2015-05-28 21:14 GMT+02:00 Thierry Goubier <[hidden email]>: >> Le 28/05/2015 20:40, Nicolai Hess a écrit : >> >> >> 2015-05-28 16:55 GMT+02:00 Thierry Goubier <[hidden email] >> <mailto:[hidden email]>>: >> >> >> >> 2015-05-28 16:49 GMT+02:00 Nicolai Hess <[hidden email] >> <mailto:[hidden email]>>: >> >> 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 > |
|
|
https://pharo.fogbugz.com/f/cases/16067/remove-prepareDebuggerExample
|
Re: About "compileSilently"
|
|
In reply to this post by Marcus Denker-4
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 <[hidden email]> wrote: > > Not known, but the whole #prepareDebuggerExample method is very strange. We should remove it. > >> On 29 Jul 2015, at 16:05, [hidden email] 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 <[hidden email]> wrote: >>> >>> >>> >>> 2015-05-28 21:14 GMT+02:00 Thierry Goubier <[hidden email]>: >>> Le 28/05/2015 20:40, Nicolai Hess a écrit : >>> >>> >>> 2015-05-28 16:55 GMT+02:00 Thierry Goubier <[hidden email] >>> <mailto:[hidden email]>>: >>> >>> >>> >>> 2015-05-28 16:49 GMT+02:00 Nicolai Hess <[hidden email] >>> <mailto:[hidden email]>>: >>> >>> 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 >> > > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |