- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Connecting ZnLogEvents to SystemLogger or Beacon

by Tudor Girba

Hi, On Wed, Jun 18, 2014 at 12:20 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Sven, > Am 18.06.2014 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > Hi, > > > > I think we are all pretty much on the same page with how we think > logging has to be done. In any case, here is the code (one, 1, line of > code) that connects ZnLogEvent with either SystemLogger or Beacon - > provided I understood everything correctly. > > > > ZnLogEvent announcer > > when: ZnLogEvent > > do: [ :each | BasicLog message: each ] > > for: #systemLogger. > > > You can do that. Iâd prefer using âeach asLogâ instead of âBasicLog > message: eachâ. This way each can specify its desired wrapper class. I like it that each Object can define its log event representation. In Beacon I have the same (asBeaconSignal), but I did not really considered the idea of using it for having other types of events choose the type of log events. > > ZnLogEvent announcer > > when: ZnLogEvent > > do: [ :each | WrapperSignal log: each ] > > for: #beacon. > > > > Now this is using a wrapper object, BasicLog and WrapperSignal > respectively. It even seems to work without the wrapping as well. > > > > ZnLogEvent announcer > > when: ZnLogEvent > > do: [ :each | LogDispatcher current addLog: each ] > > for: #systemLogger. > > > > ZnLogEvent announcer > > when: ZnLogEvent > > do: [ :each | Beacon announce: each ] > > for: #beacon. > > > > Question is, is the wrapping needed ? For the implementation or for the > user ? Right now, only a timestamp is added. As I indicated before, I don't > think that even 'forcing' a particular timestamp is a good idea. Here is my > reasoning. > > The wrapping does two things. It adds additional state to form a log > object and it adds the behaviour for simplifying the use of a log object > (e.g. have a look at BasicLog>>#emit) . To me the timestamp in a log is > mandatory. That is IMHO what it makes a log. I agree that we should decide on a way to specify time. I also find it to be essential to the logging domain. I like the timestamp proposal. See below. > Without I would call it âan objectâ. Actually, I would call it an announcement because I consider logging to made of two things: - announcing the event - at a given moment in time > > Log events arrive in a certain order and that order should be > maintained. Making log events sortable could be nice to have, but it is not > 100% necessary. The same goes for uniquely identifying log events, nice to > have but not necessary. > I was intrigued by this the first time Sven mentioned this, but I made peace with it in the meantime :). > A timestamp might seem like a good idea for both properties, but it is > not. > I agree that the timestamp is not for ordering, but for managing time. Of course, we could see time as being relative, which in distributed systems makes even more sense, but log events are events in time, but I still consider that a time representation is an essential thing in this domain. I think the only disagreement is on how to model time (see below). > Consider: > > > > (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: > DateAndTime now ] ]) asSet. > > > > The set will contain only a couple of instances. And this is for the > most precise timing that we currently have. It is also easy to think of > alternatives for DateAndTime that some people might prefer: just Time, > seconds, micro or milliseconds since a reference, ZTimestamp (which I use > in other code), some class from Chronos, whatever. Features, abstraction, > performance, precision, memory consumption are all different. > Agreed. > I donât see a problem here. The timestamp is either a visual help here or > if it is more important you need to make sure the precision does cope with > your use case. A timestamp might be just a grouping thing to focus more > easy on the entries of interest. Iâm not sure it is definable for all use > cases. If the order is important than we need to make sure the order is > preserved. To pull out an edge case to proof it is of no value is nothing I > can submit to. That is indeed an interesting point of view, see below. > > But regardless of clock precision, I think an id is useful as a > secondary sort or identity criterium, just in case. But again, I would not > require it. > > > That is a good point. In the beginning there was only one Log class. It > contained all the stuff like levels, tag and such. That is understandable > because logging is done this way (expected by people) usually and we need > to break free from that (what we do at the moment by introducing object > oriented logging). In my mission to break free from (sys)log I divided the > class in BasicLog and Log. BasicLog is what makes a Log: an object and a > timestamp. The Log class resembles the other fields like level etc. You can > argue that level, tag etc are not needed but a lot of people will need them > so why not support them? > What if you donât need level, tag etc. but you want to have an id and use > another class for timestamp? Thatâs easy just subclass BasicLog, add an id > instVar, initialize timestamp with your own class and then overwrite your > business objects class side method logClass to return your own decorating > class. Thatâs how we always do it, right? And still you could use the stuff > from the workspace by doing > > (SpecialEvent new > foo: âbarâ; > id: 10000 atRandom) asLog emit > > > On the other hand, we need common protocol. What about the following: > each log event object should implement #timestamp, which has to return a > Magnitude compatible object so that increasing values conform with the > order of the events (but not necessarily vice versa). > > Thatâs basically how it is. We should define the protocol the logger needs > internally. If there needs to be some access to #timestamp it is part of > the interface. So that way we expect an log event object to respond to > #timestamp. And the BasicLog is a wrapper that has a default implementation > for it. I donât understand what we need to define except the interface that > is needed which is obvious? > So letâs take the three use cases: subclassing, wrapping and forced duck > typing. If it works I would support all of them because people have > different ideas how things should work. If that is too much we need to > choose. I personally donât like to have to subclass a framework class > because Iâd like to preserve the inheritance chain for my own stuff. I think that this does not apply well here. I think that what applies for Exceptions and Announcements applies for logging as well. Subclassing makes sense there, and I think it makes sense here, too. You will be unlikely to want to mix events with your domain. > I also donât like forced duck typing because a framework that forces me > to implement a method in every class I want to log is cumbersome to me. I agree as well. > So I like wrapping the most because I can add log specific stuff to any > object and by being able to supply a wrapping class Iâm free to adapt any > object to be a log compatible object. I would not favor wrapping. Doru > > Norbert > > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 18, 2014

Re: [Pharo-dev] Complaints about Spec

by Yuriy Tymchuk

Sent from my iPhone > On 18 Jun 2014, at 12:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Yuriy, > > I can't really comment on the overal questions you are asking. But please keep in mind that Apple's Cocoa has had a little bit more resource behind it, for many decades, of course they have a nice design and excellent documentation. I'm not telling that Spec is bad. In fact I like it. I'm just telling than maybe we should write a tutorial on how to develop UI in Pharo. Uko > > I actually have a calculator project which contains a Spec GUI and Seaside GUI on the same model ready, with shared unit tests at the model and both GUI levels. I even use some kind of meta spec to generate both GUIs automatically. My goal is to write a Pharo tutorial about that. But I need more time (I haven't started yet). I'll see what I can do. > > Overall, although Spec is new to me, I found it acceptable for building functional GUIs. > > Sven > >> On 18 Jun 2014, at 11:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >> Hi guys, >> >> I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. >> >> I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. >> >> Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? >> >> Uko > >

June 18, 2014

Re: [Pharo-dev] Connecting ZnLogEvents to SystemLogger or Beacon

by Norbert Hartl

Am 18.06.2014 um 12:39 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Hi Sven, > > Thanks for pushing this. > > For Beacon, you do not need the wrapper because that is meant for other objects that are not announcements. If you use the Wrapper you lose the type of the event. So, the integration can be even simpler and more powerful: > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | each log ] > for: #beacon. > > Afterwards, we can listen to specific events only by using the Announcement filtering mechanism. > > Taking a step back, indeed it is easy to write the code to integrate but it comes at the cost of indirection. Specifically for logging we want the overhead to be as cheap as possible, and for this reason, we want the integration to be as tight as possible. > > If we look at it, all these three solutions have identical structure: > - there is an event (Log, Announcement) > - there is something like a broker through which the events are being triggered (LogDispatcher, Beacon, ZnLogEvent announcer) > - there are bindings that do something concrete with the events (Logger, BoundedBeacon, AnnouncementSpy) > > In the case of using Announcements, we can just have support for a central announcer in the image and the integration would be even tighter. For example, if ZnLogEvent would use this global announcer, rather than its own global announcer, it would be cheaper. Cheaper in which aspect? Did you test? If you have one central announcer that has 10 listeners attached what is cheaper than? Every subscription has to be tested for every event. Listening to you and Sven I got the idea that localized announcers could be better. I could compose the announcers Iâm interested in into a central composer and ignore stuff Iâm not interested in. Itâs about tradeoffs. > > So, I think the main thing is just to agree on the transmission mechanism. As we have Announcements already, the question is why implement another one? Or, if it is a nail, perhaps a hammer is the right thing to use :) > The transmission mechanism ist the only thing we are talking about. If you install an central announcer it isnât much different to the LogDispatcher. So this is a lot of discussion for a single aspect. I think supporting popular use cases is even more important. I still had no time to look at all the code but I would be interested how real use cases are done with your approach. I have one LogDispatcher with to Loggers: one syslog logger and one custom logger. The syslog logger events need a log level and a tag assigned. The custom logger takes events converts them to json and transmits them to another image via http. So I guess the main difficulty lays in the distribution and filtering of events and not only in the best way to get it out of the own code. Norbert > Cheers, > Doru > > > > On Wed, Jun 18, 2014 at 11:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I think we are all pretty much on the same page with how we think logging has to be done. In any case, here is the code (one, 1, line of code) that connects ZnLogEvent with either SystemLogger or Beacon - provided I understood everything correctly. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | BasicLog message: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | WrapperSignal log: each ] > for: #beacon. > > Now this is using a wrapper object, BasicLog and WrapperSignal respectively. It even seems to work without the wrapping as well. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | LogDispatcher current addLog: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | Beacon announce: each ] > for: #beacon. > > Question is, is the wrapping needed ? For the implementation or for the user ? Right now, only a timestamp is added. As I indicated before, I don't think that even 'forcing' a particular timestamp is a good idea. Here is my reasoning. > > Log events arrive in a certain order and that order should be maintained. Making log events sortable could be nice to have, but it is not 100% necessary. The same goes for uniquely identifying log events, nice to have but not necessary. > > A timestamp might seem like a good idea for both properties, but it is not. Consider: > > (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: DateAndTime now ] ]) asSet. > > The set will contain only a couple of instances. And this is for the most precise timing that we currently have. It is also easy to think of alternatives for DateAndTime that some people might prefer: just Time, seconds, micro or milliseconds since a reference, ZTimestamp (which I use in other code), some class from Chronos, whatever. Features, abstraction, performance, precision, memory consumption are all different. > > But regardless of clock precision, I think an id is useful as a secondary sort or identity criterium, just in case. But again, I would not require it. > > On the other hand, we need common protocol. What about the following: each log event object should implement #timestamp, which has to return a Magnitude compatible object so that increasing values conform with the order of the events (but not necessarily vice versa). > > Sven > > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 18, 2014

Re: [Pharo-dev] Connecting ZnLogEvents to SystemLogger or Beacon

by Tudor Girba

Hi Sven, Thanks for pushing this. For Beacon, you do not need the wrapper because that is meant for other objects that are not announcements. If you use the Wrapper you lose the type of the event. So, the integration can be even simpler and more powerful: ZnLogEvent announcer when: ZnLogEvent do: [ :each | each log ] for: #beacon. Afterwards, we can listen to specific events only by using the Announcement filtering mechanism. Taking a step back, indeed it is easy to write the code to integrate but it comes at the cost of indirection. Specifically for logging we want the overhead to be as cheap as possible, and for this reason, we want the integration to be as tight as possible. If we look at it, all these three solutions have identical structure: - there is an event (Log, Announcement) - there is something like a broker through which the events are being triggered (LogDispatcher, Beacon, ZnLogEvent announcer) - there are bindings that do something concrete with the events (Logger, BoundedBeacon, AnnouncementSpy) In the case of using Announcements, we can just have support for a central announcer in the image and the integration would be even tighter. For example, if ZnLogEvent would use this global announcer, rather than its own global announcer, it would be cheaper. So, I think the main thing is just to agree on the transmission mechanism. As we have Announcements already, the question is why implement another one? Or, if it is a nail, perhaps a hammer is the right thing to use :) Cheers, Doru On Wed, Jun 18, 2014 at 11:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I think we are all pretty much on the same page with how we think logging > has to be done. In any case, here is the code (one, 1, line of code) that > connects ZnLogEvent with either SystemLogger or Beacon - provided I > understood everything correctly. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | BasicLog message: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | WrapperSignal log: each ] > for: #beacon. > > Now this is using a wrapper object, BasicLog and WrapperSignal > respectively. It even seems to work without the wrapping as well. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | LogDispatcher current addLog: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | Beacon announce: each ] > for: #beacon. > > Question is, is the wrapping needed ? For the implementation or for the > user ? Right now, only a timestamp is added. As I indicated before, I don't > think that even 'forcing' a particular timestamp is a good idea. Here is my > reasoning. > > Log events arrive in a certain order and that order should be maintained. > Making log events sortable could be nice to have, but it is not 100% > necessary. The same goes for uniquely identifying log events, nice to have > but not necessary. > > A timestamp might seem like a good idea for both properties, but it is > not. Consider: > > (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: > DateAndTime now ] ]) asSet. > > The set will contain only a couple of instances. And this is for the most > precise timing that we currently have. It is also easy to think of > alternatives for DateAndTime that some people might prefer: just Time, > seconds, micro or milliseconds since a reference, ZTimestamp (which I use > in other code), some class from Chronos, whatever. Features, abstraction, > performance, precision, memory consumption are all different. > > But regardless of clock precision, I think an id is useful as a secondary > sort or identity criterium, just in case. But again, I would not require it. > > On the other hand, we need common protocol. What about the following: each > log event object should implement #timestamp, which has to return a > Magnitude compatible object so that increasing values conform with the > order of the events (but not necessarily vice versa). > > Sven > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 18, 2014

Re: [Pharo-dev] Complaints about Spec

by Benjamin

I understand your frustration, but writing doc takes time. I have a more industry oriented example in polishing mode Ben On 18 Jun 2014, at 11:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, > > I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. > > I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. > > Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? > > Uko > >

June 18, 2014

Re: [Pharo-dev] Connecting ZnLogEvents to SystemLogger or Beacon

by Norbert Hartl

Sven, Am 18.06.2014 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > I think we are all pretty much on the same page with how we think logging has to be done. In any case, here is the code (one, 1, line of code) that connects ZnLogEvent with either SystemLogger or Beacon - provided I understood everything correctly. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | BasicLog message: each ] > for: #systemLogger. > You can do that. Iâd prefer using âeach asLogâ instead of âBasicLog message: eachâ. This way each can specify its desired wrapper class. > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | WrapperSignal log: each ] > for: #beacon. > > Now this is using a wrapper object, BasicLog and WrapperSignal respectively. It even seems to work without the wrapping as well. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | LogDispatcher current addLog: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | Beacon announce: each ] > for: #beacon. > > Question is, is the wrapping needed ? For the implementation or for the user ? Right now, only a timestamp is added. As I indicated before, I don't think that even 'forcing' a particular timestamp is a good idea. Here is my reasoning. The wrapping does two things. It adds additional state to form a log object and it adds the behaviour for simplifying the use of a log object (e.g. have a look at BasicLog>>#emit) . To me the timestamp in a log is mandatory. That is IMHO what it makes a log. Without I would call it âan objectâ. > > Log events arrive in a certain order and that order should be maintained. Making log events sortable could be nice to have, but it is not 100% necessary. The same goes for uniquely identifying log events, nice to have but not necessary. > > A timestamp might seem like a good idea for both properties, but it is not. Consider: > > (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: DateAndTime now ] ]) asSet. > > The set will contain only a couple of instances. And this is for the most precise timing that we currently have. It is also easy to think of alternatives for DateAndTime that some people might prefer: just Time, seconds, micro or milliseconds since a reference, ZTimestamp (which I use in other code), some class from Chronos, whatever. Features, abstraction, performance, precision, memory consumption are all different. I donât see a problem here. The timestamp is either a visual help here or if it is more important you need to make sure the precision does cope with your use case. A timestamp might be just a grouping thing to focus more easy on the entries of interest. Iâm not sure it is definable for all use cases. If the order is important than we need to make sure the order is preserved. To pull out an edge case to proof it is of no value is nothing I can submit to. > > But regardless of clock precision, I think an id is useful as a secondary sort or identity criterium, just in case. But again, I would not require it. > That is a good point. In the beginning there was only one Log class. It contained all the stuff like levels, tag and such. That is understandable because logging is done this way (expected by people) usually and we need to break free from that (what we do at the moment by introducing object oriented logging). In my mission to break free from (sys)log I divided the class in BasicLog and Log. BasicLog is what makes a Log: an object and a timestamp. The Log class resembles the other fields like level etc. You can argue that level, tag etc are not needed but a lot of people will need them so why not support them? What if you donât need level, tag etc. but you want to have an id and use another class for timestamp? Thatâs easy just subclass BasicLog, add an id instVar, initialize timestamp with your own class and then overwrite your business objects class side method logClass to return your own decorating class. Thatâs how we always do it, right? And still you could use the stuff from the workspace by doing (SpecialEvent new foo: âbarâ; id: 10000 atRandom) asLog emit > On the other hand, we need common protocol. What about the following: each log event object should implement #timestamp, which has to return a Magnitude compatible object so that increasing values conform with the order of the events (but not necessarily vice versa). Thatâs basically how it is. We should define the protocol the logger needs internally. If there needs to be some access to #timestamp it is part of the interface. So that way we expect an log event object to respond to #timestamp. And the BasicLog is a wrapper that has a default implementation for it. I donât understand what we need to define except the interface that is needed which is obvious? So letâs take the three use cases: subclassing, wrapping and forced duck typing. If it works I would support all of them because people have different ideas how things should work. If that is too much we need to choose. I personally donât like to have to subclass a framework class because Iâd like to preserve the inheritance chain for my own stuff. I also donât like forced duck typing because a framework that forces me to implement a method in every class I want to log is cumbersome to me. So I like wrapping the most because I can add log specific stuff to any object and by being able to supply a wrapping class Iâm free to adapt any object to be a log compatible object. Norbert

June 18, 2014

Re: [Pharo-dev] Complaints about Spec

by Sven Van Caekenberghe

Hi Yuriy, I can't really comment on the overal questions you are asking. But please keep in mind that Apple's Cocoa has had a little bit more resource behind it, for many decades, of course they have a nice design and excellent documentation. I actually have a calculator project which contains a Spec GUI and Seaside GUI on the same model ready, with shared unit tests at the model and both GUI levels. I even use some kind of meta spec to generate both GUIs automatically. My goal is to write a Pharo tutorial about that. But I need more time (I haven't started yet). I'll see what I can do. Overall, although Spec is new to me, I found it acceptable for building functional GUIs. Sven On 18 Jun 2014, at 11:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, > > I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. > > I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. > > Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? > > Uko > >

June 18, 2014

Complaints about Spec

by Yuriy Tymchuk

Hi guys, I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? Uko

June 18, 2014

Connecting ZnLogEvents to SystemLogger or Beacon

by Sven Van Caekenberghe

Hi, I think we are all pretty much on the same page with how we think logging has to be done. In any case, here is the code (one, 1, line of code) that connects ZnLogEvent with either SystemLogger or Beacon - provided I understood everything correctly. ZnLogEvent announcer when: ZnLogEvent do: [ :each | BasicLog message: each ] for: #systemLogger. ZnLogEvent announcer when: ZnLogEvent do: [ :each | WrapperSignal log: each ] for: #beacon. Now this is using a wrapper object, BasicLog and WrapperSignal respectively. It even seems to work without the wrapping as well. ZnLogEvent announcer when: ZnLogEvent do: [ :each | LogDispatcher current addLog: each ] for: #systemLogger. ZnLogEvent announcer when: ZnLogEvent do: [ :each | Beacon announce: each ] for: #beacon. Question is, is the wrapping needed ? For the implementation or for the user ? Right now, only a timestamp is added. As I indicated before, I don't think that even 'forcing' a particular timestamp is a good idea. Here is my reasoning. Log events arrive in a certain order and that order should be maintained. Making log events sortable could be nice to have, but it is not 100% necessary. The same goes for uniquely identifying log events, nice to have but not necessary. A timestamp might seem like a good idea for both properties, but it is not. Consider: (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: DateAndTime now ] ]) asSet. The set will contain only a couple of instances. And this is for the most precise timing that we currently have. It is also easy to think of alternatives for DateAndTime that some people might prefer: just Time, seconds, micro or milliseconds since a reference, ZTimestamp (which I use in other code), some class from Chronos, whatever. Features, abstraction, performance, precision, memory consumption are all different. But regardless of clock precision, I think an id is useful as a secondary sort or identity criterium, just in case. But again, I would not require it. On the other hand, we need common protocol. What about the following: each log event object should implement #timestamp, which has to return a Magnitude compatible object so that increasing values conform with the order of the events (but not necessarily vice versa). Sven

June 18, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Sven Van Caekenberghe

Norbert, We are indeed all just discussing and exploring. On the other hand, Zinc has to work for real, on many Pharo versions and even on Gemstone. On 17 Jun 2014, at 17:09, Norbert Hartl <norbert(a)hartl.name> wrote: > Otherwise there will be three half baked approaches, one in zinc, one in GT* tools and one in pharo. What is currently in Zinc-HTTP-Logging is just a rich hierarchy of ZnLogEvent subclasses. ZnLogEvent does indeed hold onto its own announcer, pretty standard stuff I would say. Then there are two convenience methods #logToTranscript, which basically says self announcer when: self send: #crShow: to: Transcript and #open which opens an AnnouncementSpy. That's it. This gives me 99% of what I had before and a nice GUI tool as an extra. There is a #logLevel property in ZnClient and ZnServer to control the volume of log events being generated because I am concerned about performance. We'll see about that. > That would be the worst outcome. In order to prevent that I wanted to talk. Just that! > > My plan is to: > > - look at beacon to see what Doru has in his mind. Maybe I get a good idea from it > - then I would look at Svenâs new code to see the difference to Doruâs and to actual see if that works for more than a framework > - finally I would like to look at the SystemLogger design again and improve it where it might be improved. > - then there will be a new version of SystemLogger. Thatâs it. I'll send a separate mail on how easy it is, I think, to integrate ZnLogEvent with both SystemLogger and Beacon. > I personally donât plan to skip SystemLogger in favour of beacon or zinc log. beacon is a proof of concept but there are AFAIK no formatters, outputs and so on. So it is not even a replacement for SystemLogger. Zinc log is a log system for a single framework called zinc. Iâm not sure it can be useful for anything else and I donât think Sven is hitting in that direction. No, of course not. Again, Zinc-HTTP-Logging is just a rich hierarchy of ZnLogEvent subclasses. > I want a basic logging support that either has a central access for pain free logging or it has multiple announcers (maybe one per module/framework) that can be composed to a log source that can be attached to some kind of dispatcher. I donât know. That I need to figure out > > Norbert Sven

June 18, 2014