- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Esteban Lorenzano

On 16 Jun 2014, at 05:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 16 Jun 2014, at 10:01, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> I find I'm unable to use a recent vm with Roassal/cairo on Mac OS 7.5. > > I am assuming this is a typo, right ? > > Mac OS System 7.5 is from September 1994 ... > > http://en.wikipedia.org/wiki/System_7#Version_history > >> The dec 12 version works, but all new ones say: failed to get a symbol address: cairo_image_surface_create do you have an easy way to reproduce it? Esteban >> >> Stephan > >

June 16, 2014

Re: [Pharo-dev] [experimental/in-progress] Framework agnostic pure object logging for Zinc

by Norbert Hartl

Am 16.06.2014 um 09:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 16 Jun 2014, at 08:25, stepharo <stepharo(a)free.fr> wrote: > >> Hi sven >> >> Objects are the way to go. > > Yes ! > >> Will this compatible be with SystemLogger? I mean could not you use SystemLogger? > > I hope that SystemLogger can work with a subsystem that generates a stream of log objects, without requiring them to be subclasses of something. If so, then it will be compatible (just connect the announcer to where you want to sent the objects to). If not, then I don't understand how SystemLogger can be a pure object log. > > I said this before (and I miss this in the SystemLogger documentation, and even in the Beacon description): show real object based logging from the beginning, not degenerate string logging. > > In the case of SystemLogger, the class BasicLog already contains a message, why ? The API is also still mainly expressed with strings. (BTW, there should not be a messageText in exception, for example, being an instance of ZeroDivide or KeyNotFound with a key says it all). This is somethings that bugged me for a long time. The message instVar in BasicLog has probably a misleading name. The message is suppsoed to contain any object not just a string. BasicLog and Log are not supposed to be subclassed if you havenât special needs. BasicLog has two instVars: a timestamp and a message object. It acts as a decorator for any object you like to log. Therefor we have Object>>#asLog ^ self class newLog message: self Object class>>#newLog ^ self logClass new Object class>>#logClass "Hook supporting the redefinition by object of their associated log. When using myObject asLog emit, the logClass will be used and myObject will be passed as message argument." ^ Log If you need another decorator for your log objects then you override #logClass on the class side of your business object. This is exactly so you do not have to derive your objects from any class in SystemLogger. The BasicLog resembles the most basic thing. To me a log entry has always a timestamp when the event occurred. And there is a message instVar for keeping any object. The Log class derives from BasicLog and resembles a Log class that is used in other frameworks/operating systems. How the Log is converted to is defined in the Loggers itself at the best possible time before they leave the image. Norbert > > And like in the basic BeaconSignal, you predefine a timeStamp, why ? Is it really needed, or not ? In my other projects I don't use DateAndTime but ZTimestamp, things like that should not be forced on user. A timestamp even with high precision is not necessarily unique, that is why I added a secondary id. > >> Because I do not see them why I spend my time to build infrastructure. > > Sure, I need/want a nice backend with lots of functionality (like what Norbert was experimenting with). Also, for casual usage, some classes to inherit from are useful. Maybe a system level API as well. > > Second, we will probably need conventions, maybe expressed as traits of useful attributes for log objects so that we can write general analysis tools. > >> Stef >> >>> Hi, >>> >>> Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though. >>> >>> In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result. >>> >>> Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft: >>> >>> https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md >>> >>> And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think. >>> >>> Monitoring logging output can be done by opening an Announcement Spy. >>> >>> ZnNewLogEvent open. >>> >>> Next you run some code (start a server, do one request, stop the server). >>> >>> (ZnServer defaultOn: 1701) >>> route: #server1; >>> start. >>> >>> ZnClient new >>> clientId: #client1; >>> beOneShot; >>> get: 'http://localhost:1701/random'. >>> >>> ZnServer stopDefault. >>> >>> Which give the following output (using the standard string representation). >>> >>> <Mail Attachment.png> >>> >>> However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer. >>> >>> <Mail Attachment.png> >>> >>> As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on. >>> >>> Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object. >>> >>> I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there. >>> >>> When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback. >>> >>> Sven

June 16, 2014

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

by Norbert Hartl

Am 16.06.2014 um 12:10 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Hi Sven, > > > On Mon, Jun 16, 2014 at 11:54 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 16 Jun 2014, at 10:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > - Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ? > > > > As you can see at the end of the post, you can just use your own Announcements. There is no real magic there. So, it should be no technical problem to accommodate the logging of ZincEvents as they are. > > Yes, but even being an Announcement subclass is debatable. > > If you can announce any object, then you do not need Announcements either :). I agree with Sven here. I think the need to subclass another framework class is a big restriction. Announcements (as any object) have static part (class, instVars) and a dynamic part. In this case it is the infrastructure and the way they get delivered, the way I can register for receiving them etc. To me the latter is the important part. I never understood why not every object can be an announcement. This way it just leads to doubled class hierarchies just for the sake to announce anything. Norbert > > > > However, one thing that we should also think about is the actual analyses that we might want to do. For example, the inspector extension for RecordingBeacon uses: > > - timestamp, and > > - printOneLineContentsOn: > > > > And these requirements will grow even more as we are building more specialized tools. So, to this end, it is useful to have some common ground. > > Yes, I mentioned this already several times: traits listing expected protocol would be good. Maximum polymorphism, latest possible binding, no dependencies, composable. > > Agreed. All I said is that to find the useful protocols we need to build the tools and not stop the discussion at the recording part of the logging. > > > > Now, as far as I know, the only reason why you do not want to subclass BeaconSignal is because you want to use ZnTimestamp. I see no reason to have two Timestamps in the image anyway, so I have no problem pushing just one. > > Or do you have another reason? > > I first of all want no dependency so that different logging backends can be plugged in or used. I think that this takes away any lock-in anxiety from people like myself, which will increase adoption. > > I do not understand that. First, we talk about a handful of lines of code. Second, actually your newest implementation already ships a more specialized version of Beacon, so from this perspective Zinc already binds me at least to Announcements. Is this a bad thing? I think it is rather pragmatic. > > > BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do with Zinc. ZTimestamp is second precision, UTC only, and takes half the size. It comes with cool formatting/parsing, full timezone and basic SNTP support. > > Yeah, my bad. > > No, I want all users to be able to make there own choices for whatever reason (efficiency, precision, portability). The timestamp is the only concrete element we can discuss now, but there could be others. > > Freedom is good in the sense that people should be able to customize anything they want. At the same time if you want to provide services on top, you need to find a useful commonality. In our concrete case, I see no reason to keep DateAndTime when the other one is better. > > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 16, 2014

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

by Tudor Girba

Hi Sven, On Mon, Jun 16, 2014 at 11:54 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 16 Jun 2014, at 10:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > - Like I said in my document and like I tried to show in my > implementation for Zinc, I want framework agnostic pure object logging, so > I don't want to subclass from anything (I do from Announcement, but that is > an implementation detail, the technique how #emit is done), can you deal > with the ZnNewLogEvents as the are ? > > > > As you can see at the end of the post, you can just use your own > Announcements. There is no real magic there. So, it should be no technical > problem to accommodate the logging of ZincEvents as they are. > > Yes, but even being an Announcement subclass is debatable. If you can announce any object, then you do not need Announcements either :). > > However, one thing that we should also think about is the actual > analyses that we might want to do. For example, the inspector extension for > RecordingBeacon uses: > > - timestamp, and > > - printOneLineContentsOn: > > > > And these requirements will grow even more as we are building more > specialized tools. So, to this end, it is useful to have some common ground. > > Yes, I mentioned this already several times: traits listing expected > protocol would be good. Maximum polymorphism, latest possible binding, no > dependencies, composable. Agreed. All I said is that to find the useful protocols we need to build the tools and not stop the discussion at the recording part of the logging. > > Now, as far as I know, the only reason why you do not want to subclass > BeaconSignal is because you want to use ZnTimestamp. I see no reason to > have two Timestamps in the image anyway, so I have no problem pushing just > one. > > Or do you have another reason? > > I first of all want no dependency so that different logging backends can > be plugged in or used. I think that this takes away any lock-in anxiety > from people like myself, which will increase adoption. > I do not understand that. First, we talk about a handful of lines of code. Second, actually your newest implementation already ships a more specialized version of Beacon, so from this perspective Zinc already binds me at least to Announcements. Is this a bad thing? I think it is rather pragmatic. > BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do > with Zinc. ZTimestamp is second precision, UTC only, and takes half the > size. It comes with cool formatting/parsing, full timezone and basic SNTP > support. > Yeah, my bad. > No, I want all users to be able to make there own choices for whatever > reason (efficiency, precision, portability). The timestamp is the only > concrete element we can discuss now, but there could be others. > Freedom is good in the sense that people should be able to customize anything they want. At the same time if you want to provide services on top, you need to find a useful commonality. In our concrete case, I see no reason to keep DateAndTime when the other one is better. Doru -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014

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

by Sven Van Caekenberghe

On 16 Jun 2014, at 10:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > - Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ? > > As you can see at the end of the post, you can just use your own Announcements. There is no real magic there. So, it should be no technical problem to accommodate the logging of ZincEvents as they are. Yes, but even being an Announcement subclass is debatable. > However, one thing that we should also think about is the actual analyses that we might want to do. For example, the inspector extension for RecordingBeacon uses: > - timestamp, and > - printOneLineContentsOn: > > And these requirements will grow even more as we are building more specialized tools. So, to this end, it is useful to have some common ground. Yes, I mentioned this already several times: traits listing expected protocol would be good. Maximum polymorphism, latest possible binding, no dependencies, composable. > Now, as far as I know, the only reason why you do not want to subclass BeaconSignal is because you want to use ZnTimestamp. I see no reason to have two Timestamps in the image anyway, so I have no problem pushing just one. > Or do you have another reason? I first of all want no dependency so that different logging backends can be plugged in or used. I think that this takes away any lock-in anxiety from people like myself, which will increase adoption. BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do with Zinc. ZTimestamp is second precision, UTC only, and takes half the size. It comes with cool formatting/parsing, full timezone and basic SNTP support. No, I want all users to be able to make there own choices for whatever reason (efficiency, precision, portability). The timestamp is the only concrete element we can discuss now, but there could be others.

June 16, 2014

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

by kilon alios

sure you guys know pharo better than me , I am sure you will make the right choice :) On Mon, Jun 16, 2014 at 12:13 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > Sure, that is the way we should follow from pharo 4.0 on. Making a > modular system means making dependencies visible. If you compose your > system there will be parts that are closer to the core and parts which are > farther away like applications. The logging is just one thing we need to be > closer to the core because it should be usable by core functionality too. > May this be a description that suits you more. > > Norbert > > Am 16.06.2014 um 11:05 schrieb kilon alios <kilon.alios(a)gmail.com>: > > I think it would be better if pharo was stripped down to core basics , > excluding any logging system as well, and instead the user would be able to > add the functionality he / she wants with configuration browser. I think > this also will show a very clean look highly modular. > > > On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Hi Norbert, >> >> Indeed it was not meant as "I donât like yours here is mine". >> It was meant as "I donât like yours because ... so here is my concrete >> proposal of how to address ..." >> >> And the goal is not SystemLogger vs Beacon either. The goal should be the >> one cool engine that will ship with Pharo 4. >> >> Doru >> >> >> On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert(a)hartl.name> >> wrote: >> >>> Stef, >>> >>> Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)free.fr>: >>> >>> >>> Hi, >>> >>> I like very much the new energy people are putting into creating the >>> SystemLogger engine for Pharo. I think this is a specifically important >>> area for which we have to have a solution out of the box. At the same time, >>> I also think that Pharo provides an infrastructure that makes room for >>> ideas that are otherwise hard to reach in other languages or environments. >>> >>> >>> Why Java does not have announcements? >>> >>> Stef asked for collaborations around this project, so here is my >>> literally small contribution: a rather different logging engine. >>> >>> I do not see how this contribute to SystemLogger. So at least please do >>> not say it, respect the amount of time I spent >>> design it and working with Norbert. >>> >>> >>> I had troubles myself seeing how this can contribute to SystemLogger. It >>> looks a lot like âI donât like yours here is mineâ. But if you remember >>> that is the same reason why you've started SystemLogger. So you should be >>> fair here. Now it is the time to see how we can benefit from each other. I >>> see it as an advantage to have code to compare because a lot of discussions >>> are usual too theoretical to make something of it. >>> I did not have the time to look at svens and dorus code. But I will >>> because I had the impression, too, in the beginning that the dispatching of >>> events would be better done with announcements. We all should review the >>> other implementations and all of us should be open minded for any reason >>> why the own implementation is probably _not_ the way to go. >>> I wish we can find an agreement about an optimal implementation we like >>> to promote. >>> >>> Norbert >>> >>> >>> It is called Beacon, it is based entirely on Announcements, it has >>> ~200 lines of code, it has no tags or levels, and in my opinion it is fully >>> functional. >>> >>> You can see a detailed description here including some informal >>> comparisons with SystemLogger: >>> http://www.humane-assessment.com/blog/beacon >>> >>> Please let me know what you think. I would be happy to join forces to >>> reach a mature solution that is both versatile and that can show how Pharo >>> is different. >>> >>> So should we see it as a competitor to SystemLogger? >>> (you will say of course not) but I do not understand. >>> >>> >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > >

June 16, 2014

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

by Norbert Hartl

Sure, that is the way we should follow from pharo 4.0 on. Making a modular system means making dependencies visible. If you compose your system there will be parts that are closer to the core and parts which are farther away like applications. The logging is just one thing we need to be closer to the core because it should be usable by core functionality too. May this be a description that suits you more. Norbert Am 16.06.2014 um 11:05 schrieb kilon alios <kilon.alios(a)gmail.com>: > I think it would be better if pharo was stripped down to core basics , excluding any logging system as well, and instead the user would be able to add the functionality he / she wants with configuration browser. I think this also will show a very clean look highly modular. > > > On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Norbert, > > Indeed it was not meant as "I donât like yours here is mine". > It was meant as "I donât like yours because ... so here is my concrete proposal of how to address ..." > > And the goal is not SystemLogger vs Beacon either. The goal should be the one cool engine that will ship with Pharo 4. > > Doru > > > On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > Stef, > > Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)free.fr>: > >> >>> Hi, >>> >>> I like very much the new energy people are putting into creating the SystemLogger engine for Pharo. I think this is a specifically important area for which we have to have a solution out of the box. At the same time, I also think that Pharo provides an infrastructure that makes room for ideas that are otherwise hard to reach in other languages or environments. >> >> Why Java does not have announcements? >> >>> Stef asked for collaborations around this project, so here is my literally small contribution: a rather different logging engine. >> I do not see how this contribute to SystemLogger. So at least please do not say it, respect the amount of time I spent >> design it and working with Norbert. > > I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. > I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. > I wish we can find an agreement about an optimal implementation we like to promote. > > Norbert > > >>> It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional. >>> >>> You can see a detailed description here including some informal comparisons with SystemLogger: >>> http://www.humane-assessment.com/blog/beacon >>> >>> Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. >> So should we see it as a competitor to SystemLogger? >> (you will say of course not) but I do not understand. >> >> >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >> > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 16, 2014

Re: [Pharo-dev] WhatsUp from: 2014-06-16 until: 2014-06-30

by Tudor Girba

> > ### Here's what I've been up to since the last WhatsUp: > - Showed GTInspector at speakerconf.com - Gave a talk about Pharo at NDC Oslo: http://vimeo.com/channels/ndc2014/97315968 - Fixed with Andrei the Rubric performance problem with syntax highlighting - Implemented an Announcement based logging engine to start a discussion in this direction: http://www.humane-assessment.com/blog/beacon > > ### What's next, until 2014-06-30 (*): > > - Try to use logging for a couple of examples and explore analyses opportunities in this space -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014

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

by Tudor Girba

That should happen with the modularization work started by Pavel and Stef. That is a primary goal for Pharo 4. But, at the end, we will still prebuild a handy to use image. That image should have a logging engine. Doru On Mon, Jun 16, 2014 at 11:05 AM, kilon alios <kilon.alios(a)gmail.com> wrote: > I think it would be better if pharo was stripped down to core basics , > excluding any logging system as well, and instead the user would be able to > add the functionality he / she wants with configuration browser. I think > this also will show a very clean look highly modular. > > > On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > >> Hi Norbert, >> >> Indeed it was not meant as "I donât like yours here is mine". >> It was meant as "I donât like yours because ... so here is my concrete >> proposal of how to address ..." >> >> And the goal is not SystemLogger vs Beacon either. The goal should be the >> one cool engine that will ship with Pharo 4. >> >> Doru >> >> >> On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert(a)hartl.name> >> wrote: >> >>> Stef, >>> >>> Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)free.fr>: >>> >>> >>> Hi, >>> >>> I like very much the new energy people are putting into creating the >>> SystemLogger engine for Pharo. I think this is a specifically important >>> area for which we have to have a solution out of the box. At the same time, >>> I also think that Pharo provides an infrastructure that makes room for >>> ideas that are otherwise hard to reach in other languages or environments. >>> >>> >>> Why Java does not have announcements? >>> >>> Stef asked for collaborations around this project, so here is my >>> literally small contribution: a rather different logging engine. >>> >>> I do not see how this contribute to SystemLogger. So at least please do >>> not say it, respect the amount of time I spent >>> design it and working with Norbert. >>> >>> >>> I had troubles myself seeing how this can contribute to SystemLogger. It >>> looks a lot like âI donât like yours here is mineâ. But if you remember >>> that is the same reason why you've started SystemLogger. So you should be >>> fair here. Now it is the time to see how we can benefit from each other. I >>> see it as an advantage to have code to compare because a lot of discussions >>> are usual too theoretical to make something of it. >>> I did not have the time to look at svens and dorus code. But I will >>> because I had the impression, too, in the beginning that the dispatching of >>> events would be better done with announcements. We all should review the >>> other implementations and all of us should be open minded for any reason >>> why the own implementation is probably _not_ the way to go. >>> I wish we can find an agreement about an optimal implementation we like >>> to promote. >>> >>> Norbert >>> >>> >>> It is called Beacon, it is based entirely on Announcements, it has >>> ~200 lines of code, it has no tags or levels, and in my opinion it is fully >>> functional. >>> >>> You can see a detailed description here including some informal >>> comparisons with SystemLogger: >>> http://www.humane-assessment.com/blog/beacon >>> >>> Please let me know what you think. I would be happy to join forces to >>> reach a mature solution that is both versatile and that can show how Pharo >>> is different. >>> >>> So should we see it as a competitor to SystemLogger? >>> (you will say of course not) but I do not understand. >>> >>> >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >>> >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > > -- www.tudorgirba.com "Every thing has its own flow"

June 16, 2014

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

by kilon alios

I think it would be better if pharo was stripped down to core basics , excluding any logging system as well, and instead the user would be able to add the functionality he / she wants with configuration browser. I think this also will show a very clean look highly modular. On Mon, Jun 16, 2014 at 11:57 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Norbert, > > Indeed it was not meant as "I donât like yours here is mine". > It was meant as "I donât like yours because ... so here is my concrete > proposal of how to address ..." > > And the goal is not SystemLogger vs Beacon either. The goal should be the > one cool engine that will ship with Pharo 4. > > Doru > > > On Mon, Jun 16, 2014 at 9:24 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Stef, >> >> Am 16.06.2014 um 08:52 schrieb stepharo <stepharo(a)free.fr>: >> >> >> Hi, >> >> I like very much the new energy people are putting into creating the >> SystemLogger engine for Pharo. I think this is a specifically important >> area for which we have to have a solution out of the box. At the same time, >> I also think that Pharo provides an infrastructure that makes room for >> ideas that are otherwise hard to reach in other languages or environments. >> >> >> Why Java does not have announcements? >> >> Stef asked for collaborations around this project, so here is my >> literally small contribution: a rather different logging engine. >> >> I do not see how this contribute to SystemLogger. So at least please do >> not say it, respect the amount of time I spent >> design it and working with Norbert. >> >> >> I had troubles myself seeing how this can contribute to SystemLogger. It >> looks a lot like âI donât like yours here is mineâ. But if you remember >> that is the same reason why you've started SystemLogger. So you should be >> fair here. Now it is the time to see how we can benefit from each other. I >> see it as an advantage to have code to compare because a lot of discussions >> are usual too theoretical to make something of it. >> I did not have the time to look at svens and dorus code. But I will >> because I had the impression, too, in the beginning that the dispatching of >> events would be better done with announcements. We all should review the >> other implementations and all of us should be open minded for any reason >> why the own implementation is probably _not_ the way to go. >> I wish we can find an agreement about an optimal implementation we like >> to promote. >> >> Norbert >> >> >> It is called Beacon, it is based entirely on Announcements, it has >> ~200 lines of code, it has no tags or levels, and in my opinion it is fully >> functional. >> >> You can see a detailed description here including some informal >> comparisons with SystemLogger: >> http://www.humane-assessment.com/blog/beacon >> >> Please let me know what you think. I would be happy to join forces to >> reach a mature solution that is both versatile and that can show how Pharo >> is different. >> >> So should we see it as a competitor to SystemLogger? >> (you will say of course not) but I do not understand. >> >> >> >> Cheers, >> Doru >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 16, 2014