April 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Logging API discussion

by Tudor Girba

Hi, > On Apr 28, 2016, at 2:29 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-04-28 11:07 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Put you logging api in a Trait instead of Object and let your MySpecialDomainObject use this trait ? > > > > Really? > > Try remember usual workflow when we investigate some problems with code when we can't use debugger. We put kind of "Transcript show:" in multiple places to see state of our objects at concrete point of time. With object logging we will log our objects directly without converting to strings. Do you want to stop your "debugging workflow" every time you need to log objects which not support it? (to add special trait). > > This is a totally different scenario than the one of logging for an unforeseen situation. For this purpose, in Beacon we have dedicated signals such as those that capture the stack or the context and we can imagine several more. It is more powerful than Transcript and requires no string. Furthermore, because we have the type signal, we can also easily have an inspector that shows the relevant information. > > I hope you not think that I suggested to log strings. I never did it. I proposed to log domain objects instead of signals with ability to annotate them with additional information. No, I did not suggest that you want to log strings. I simply said that this type of use case is different than the regular logging use case. I think it is important to treat these two separately because indeed when you debug you are in a prototyping mode and you want to go fast. In this situation, you do not want to have to create a separate class. But, for the long term logging you have different requirements and there you want to be more rigorous, and in that scenario creating a new class is acceptable. If we design a logging infrastructure the second use case is what we want to optimize around. Of course, we should still think about the prototyping part. I found that it is often more interesting to log entire contexts (and have a post-mortem debugger) than individual objects. Nevertheless, with something as simple as: object asBeaconSignal log. It worked fine. And if I really wanted to add extra information, I rudimentary did: {âsome textâ . object } asBeaconSignal log. Or even: {âsome textâ . #someSymbol . 42 . object } asBeaconSignal log. It is not the most elegant solution, but it is very malleable and good enough for debugging purposes. If we would have instance-based filtering for announcements, we could filter based on that without any extra effort. Also, if we would have a composition mechanism in place, we could build these objects with a more elegant API. Regarding your statement of logging domain objects, you will have to store these objects with the additional information somewhere, and that will be a wrapper class. I do not see the difference with the Signal. Cheers, Doru -- www.tudorgirba.com www.feenk.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

April 28, 2016

Re: [Pharo-dev] Looking for moderators and helpers for the Pharo Mooc

by Serge Stinckwich

I can help. On Thu, Apr 28, 2016 at 8:43 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > We are looking for moderators and people to help in the forum on the mooc. > > Let me know if you want to help. > > Stef > > -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

April 28, 2016

Looking for moderators and helpers for the Pharo Mooc

by stepharo

Hi guys We are looking for moderators and people to help in the forum on the mooc. Let me know if you want to help. Stef

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Tudor Girba

Hi, > On Apr 28, 2016, at 2:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-04-28 11:07 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > But anyway with Trait you can't add timestamp to your domain object which is always required for logs (I think we all agree about timestamp). > > We can indeed agree on timestamp, but as Sven said, we might need flexibility on how to capture it (DateAndTime vs ZTimestamp). > > Domain objects can supply own timestamp to log entries. I do not understand this point. Could you clarify? > But both kinds of time should be polimorphic in some cases. Certainly. > By the way why we need multiple timestamp representation in system? Can we choose best option and use it anywhere? (But this question is not for this topic) Indeed, we know that we do not need both, but someone has to clean them up :). In any case, in some cases you might want a certain precision even if it costs, and in others you do not. So, having the initialization of the timestamp factored out would be a good thing. Cheers, Doru -- www.tudorgirba.com www.feenk.com "Obvious things are difficult to teach."

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-28 11:07 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > But anyway with Trait you can't add timestamp to your domain object which > is always required for logs (I think we all agree about timestamp). > > We can indeed agree on timestamp, but as Sven said, we might need > flexibility on how to capture it (DateAndTime vs ZTimestamp). Domain objects can supply own timestamp to log entries. But both kinds of time should be polimorphic in some cases. By the way why we need multiple timestamp representation in system? Can we choose best option and use it anywhere? (But this question is not for this topic)

April 28, 2016

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

2016-04-28 11:07 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Put you logging api in a Trait instead of Object and let your > MySpecialDomainObject use this trait ? > > > > Really? > > Try remember usual workflow when we investigate some problems with code > when we can't use debugger. We put kind of "Transcript show:" in multiple > places to see state of our objects at concrete point of time. With object > logging we will log our objects directly without converting to strings. Do > you want to stop your "debugging workflow" every time you need to log > objects which not support it? (to add special trait). > > This is a totally different scenario than the one of logging for an > unforeseen situation. For this purpose, in Beacon we have dedicated signals > such as those that capture the stack or the context and we can imagine > several more. It is more powerful than Transcript and requires no string. > Furthermore, because we have the type signal, we can also easily have an > inspector that shows the relevant information. I hope you not think that I suggested to log strings. I never did it. I proposed to log domain objects instead of signals with ability to annotate them with additional information.

April 28, 2016

[pharo-project/pharo-core] c333d7: 50729

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: c333d77ad1f5b4b83f3599a26f54bfac339e4127 https://github.com/pharo-project/pharo-core/commit/c333d77ad1f5b4b83f3599a2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-28 (Thu, 28 Apr 2016) Changed paths: M ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/symbolic versions/stable_.st A ConfigurationOfQualityAssistant.package/ConfigurationOfQualityAssistant.class/instance/versions/v2%5F6%5F7_.st M QualityAssistant.package/QANautilusPluginMorph.class/class/cleanup/cleanUp.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50728.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50729.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50728.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50729.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M System-Support.package/Author.class/class/instance creation/reset.st Log Message: ----------- 50729 18118 Author reset should not create new instance https://pharo.fogbugz.com/f/cases/18118 18122 QA accessing undeclared var https://pharo.fogbugz.com/f/cases/18122 http://files.pharo.org/image/50/50729.zip

April 28, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50729 Home: https://github.com/pharo-project/pharo-core

April 28, 2016

Re: [Pharo-dev] [pharo-project/pharo-core] c500cc: 50727

by Marcus Denker

> > Log Message: > ----------- > 50727 > 18114 Incorrect handling of events when raising windows to the front > https://pharo.fogbugz.com/f/cases/18114 > > 18117 Fuel fix for class substitutions > https://pharo.fogbugz.com/f/cases/18117 > This seems to be wrong, the Fuel update. It loads lots of code with undeclared references. We should revert to to the version before, we have to release! Marcus

April 28, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50728 Home: https://github.com/pharo-project/pharo-core

April 28, 2016