January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] What Logging framework for Pharo

by Atlas

Nice demonstration on ZnLogEvent, Sven! My two cents: > This is broken because it implies that the human should read the log as a > way of understanding it. [...] > but in practice all logs I have seen in enterprise systems are mostly > /unstructured /and one has to spend great effort to extract the useful > information out of them. That's a good point. Object-oriented logging is certainly a step forward, but I wonder at which point does an object-oriented log become unreadable, especially when we talk about large scale systems with millions of objects, multiple layers of abstraction, subsystems etc.? I claim that even with object-oriented loggers at some point when a system evolves, there will be either too much or too little information: Simply because logging is not a first-class citizen (also in Pharo's conceptual architecture as far as I have seen). All systems that I have seen lack self-description at higher levels (i.e., of their architecture). Given that fact, how can an object-oriented logger know which role its objects play in the architecture of a system and represent that information in a comprehensible way? It would be nice to zoom into logs, having level of detail, but this cannot be done by merely putting logging calls into methods. You could try, but it would require an immense programming effort and the logging scheme would still be incomplete or incomprehensible to someone else. I do not want to rely on programming to see what is happening in my system or on others to do that programming for me (after all, how can a programmer really know what I want to see?). I rather more imagine a system where I can see the connections between objects, where I can put instruments (such as loggers) between the connections. In such a visual representation, it would be also easier to observe cause and effect, observe message flows and to zoom into different layers. This way, I do not have to touch the source code, I can learn about the system in my own way. It's much like electronics by putting measurement devices between connections: In software we even have the advantage to zoom into bigger blocks and to measurements in a uniform way. I think that is the metaphor we should be after (or one of them) - in my opinion. Cheers -- View this message in context: http://forum.world.st/What-Logging-framework-for-Pharo-tp4799073p4799227.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 13, 2015

Re: [Pharo-dev] Woden on Windows?

by Richard Wettel

Hi again @Thorsten: thanks for the tip. That was the exact problem. Now the Woden example works. @all: There were only a couple of places where the "opt" prefix was missing in the parameters of the call to #options: method, which I have now corrected. I would like to commit these changes in NativeBoost-Win32, but I do not know where (which repository). Can someone can help me with directions? Cheers Ricky On Mon, Jan 12, 2015 at 7:24 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Richard, > > this is an error from NativeBoost. Have a look at the previous methods back > in the debugger stack. There must be one with a native Boost call > including something like > > options: { WinUnicode }. > > Change this to optWinUnicode and try again. > > I guess we now use "opt" prefix for Native Boost options. > > Bye > T. > > > > Gesendet: Montag, 12. Januar 2015 um 16:18 Uhr > Von: "Richard Wettel" <wettel(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Woden on Windows? > > Hi > > I am also interested in the current status of Woden.I tried to follow the > instructions from Alex (under Windows 7) and I get a: > > NBFFICallout>>error: 'Invalid option name WinUnicode, must begin with > ''opt''' > > Any help is appreciated. > > Cheers > Ricky > > On Mon, Jan 12, 2015 at 2:46 PM, Alexandre Bergel <alexandre.bergel(a)me.com> > wrote:You should do: > > Gofer new smalltalkhubUser: 'PharoExtras' project: 'NBOpenGL'; package: > 'ConfigurationOfNBOpenGL'; load. ((Smalltalk at: #ConfigurationOfNBOpenGL) > project version: '3.0') load. > > Gofer new smalltalkhubUser: 'Pharo' project: 'OSWindow'; package: > 'ConfigurationOfOSWindow'; load. (Smalltalk at: #ConfigurationOfOSWindow) > loadBleedingEdge. > > Gofer new smalltalkhubUser: 'ronsaldo' project: 'Woden'; package: > 'ConfigurationOfWoden'; load. (Smalltalk at: #ConfigurationOfWoden) > loadBleedingEdge. > > Some of the things are not up to date in pharo. > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu[http://www.bergel.eu] > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > On Jan 11, 2015, at 2:06 PM, Torsten Bergmann <astares(a)gmx.de[ > astares(a)gmx.de]> wrote: > > > > Hi, > > > > is woden 3D engine for Pharo working out of the box with Pharo 4 and > > latest VM on Windows? As OSWindow is already integrated I do not know > > if the load script still fits. Wanted to ask first. > > What is required to load? > > > > If so can we have a config in the config browser for easy access? > > > > Thx > > T. > > > > > >

Jan. 13, 2015

Re: [Pharo-dev] PettitParser and Python

by Frank Shearar

On 10 January 2015 at 18:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The challenge with Python parsing is dealing with whitespace properly. > > Jan Kurs was working on such a parser. I do not know how advanced it is. > Jan? Maybe one can take inspiration from http://www.cs.nott.ac.uk/~gmh/monparsing.pdf (see section 8) for handling the offside rule? PetitParser is, after all, a parser combinator library. frank > Cheers, > Doru > > > > On Fri, Jan 9, 2015 at 7:30 PM, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> Hello guys I am learning PettitParser , I dowloaded the video tutorials of >> Tudor Girba (very good tutorial Tudor , well done ) and other documentation >> and I was wondering if a parser for Python already exists . I hope I am not >> asking something obvious. >> >> For my project I want to parse python types , that will be given to me as >> strings , to pharo objects. So that means parsing lists, dictionaries and >> other usual candidates. For example a python list is like >> >> '[1, 3, 50, [45, 'hello', 0.2], 63]' >> >> etc >> >> Anyone already worked on such problem ? >> >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Norbert Hartl

Doru, > Am 13.01.2015 um 10:54 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > > Hi, > > Log4j types of logging systems do a reasonable job at capturing log entries, but they are poor at helping the human make sense of the produced log. Of course, they do attempt, but given that they see the log as a long string, there is a significant mechanism built around formatting. > > This is broken because it implies that the human should read the log as a way of understanding it. This works fine for a couple of lines but fails miserably for even Mb logs (not to mention larger logs). One could tweak the formatting to make it machine readable, but in practice all logs I have seen in enterprise systems are mostly unstructured and one has to spend great effort to extract the useful information out of them. For example, I use the information in logs to understand performance and diagnose errors, and I am using automatic tools for that. But, to build those tools, the hardest part is to parse the log. That cost should not exist. > > The object as an item of logging preserves the original information so that the machine can read it. String is just a way of serializing an object, and we should only use it only in this way. Formatting still has a place, but it should be clear that it is just one tool - most often the least useful one. That is the reason why in Beacon, there is no formatting in the core. > > Priority is another thing I find rather artificial. For example, developers should mark as DEBUG things that are not useful in production, but in the end, they mark as DEBUG things that are too large to have in production all the time. The problem with this is that sometimes you really want to have access to a very specific event regardless of "priority". So, a better way of looking at filtering is by allowing the developer to cherry pick any event at any given moment. > > We definitely have to get good at the backend, but logging objects should provide a significant advantage. > will you attend pharodays? Maybe this would be a good target to sit together and merge SystemLogger and Beacon. Norbert > > > On Tue, Jan 13, 2015 at 10:05 AM, S Krish <krishnamachari.sudhakar(a)gmail.com <mailto:krishnamachari.sudhakar@gmail.com>> wrote: > > Log4J does do Event object logging by default. I see it may be relevant to roll it into log4s also. I remember Toothpick probably did that > > On Tue, Jan 13, 2015 at 11:30 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: > First of all, I am not the developer of Log4s, but I have been using it for a while and I see no significant gain switching to SystemLogger or ZnLogEvent. As Alain said, it is based in Log4j, which has his own Wikipedia page: http://en.wikipedia.org/wiki/Log4j <http://en.wikipedia.org/wiki/Log4j> > > I don't think there is too much sense in having "Log Objects" around, where probably I want to tail a daily rolled log from a headless remote image. I read the documentation of SystemLogger hoping to find a mechansim which dynamically selects compression strategies based in what's logged, or some other advanced feature, but I didn't found any :( > > So if Object logging is implementing #asLog and #logClass methods maybe I should add them so Log4s can log "Object" :). But seriously, such comparison is not fair. Let's compare real logging features: priorities, levels, appenders, output destinations, hierarchical logging, formatting layout, etc. Many of them are implemented in Log4s. > > Cheers, > > HernÃ¡n > > 2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > > > > On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm.cat(a)gmail.com <mailto:alf.mmm.cat@gmail.com>> wrote: > > > > hi all, > > > > Googling a bit for a logging framework in Pharo, I found sl4j, which sounds familiar to me. > > http://ss3.gemstone.com/ss/Log4s.html/Wiki <http://ss3.gemstone.com/ss/Log4s.html/Wiki> > > > > I suppose the API is the same as the java package, as claimed by the project page. > > I wonder if anybody is using it , or has tried it and have an advice on that package ? > > (I saw there was no test and no comments ... :( ) > > > > I think it could be great for Pharo to have a standard package like that, a logging facility is mandatory for most -if not all- applications > > > > Any advice or pointers ? > > Object logging instead of String logging is the way to go. SystemLogger, Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past discussions. > > > TIA > > -- > > Regards, > > > > Alain > > > > > > > > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Norbert Hartl

Hernan, > Am 13.01.2015 um 07:00 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > First of all, I am not the developer of Log4s, but I have been using it for a while and I see no significant gain switching to SystemLogger or ZnLogEvent. As Alain said, it is based in Log4j, which has his own Wikipedia page: http://en.wikipedia.org/wiki/Log4j <http://en.wikipedia.org/wiki/Log4j> > > I don't think there is too much sense in having "Log Objects" around, where probably I want to tail a daily rolled log from a headless remote image. I read the documentation of SystemLogger hoping to find a mechansim which dynamically selects compression strategies based in what's logged, or some other advanced feature, but I didn't found any :( > if your only concern is to have syslog style logging (maybe even just file based) than all of what we've done is not of any value. If you peek at current logging trends you will see things like logstash et al. In those log collectors they provide huge parsing libraries just to be able to parse every available log format out there in order to produce objects from it that you can store in e.g. elasticsearch. Especially if you have GBs of logging information it makes sense to be able to query the log information for things you are interested in. So think about moving the DEBUG quality from the logger to the viewer of the log. I personally do enjoy using SystemLogger. Instead of a huge logging framework and the need to parse them back into a system like logstash I did a shortcut by emitting the log objects and send them as json into a elasticsearch database. From there I have queries for finding problems and second I produce stats from it that give me some insight of the health of the system. To me there a plenty of advantages to do it that way. From a simple (well :) ) query I can see something like this. This things are important for me. Norbert > So if Object logging is implementing #asLog and #logClass methods maybe I should add them so Log4s can log "Object" :). But seriously, such comparison is not fair. Let's compare real logging features: priorities, levels, appenders, output destinations, hierarchical logging, formatting layout, etc. Many of them are implemented in Log4s. > > Cheers, > > HernÃ¡n > > 2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > > > On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm.cat(a)gmail.com <mailto:alf.mmm.cat@gmail.com>> wrote: > > > > hi all, > > > > Googling a bit for a logging framework in Pharo, I found sl4j, which sounds familiar to me. > > http://ss3.gemstone.com/ss/Log4s.html/Wiki <http://ss3.gemstone.com/ss/Log4s.html/Wiki> > > > > I suppose the API is the same as the java package, as claimed by the project page. > > I wonder if anybody is using it , or has tried it and have an advice on that package ? > > (I saw there was no test and no comments ... :( ) > > > > I think it could be great for Pharo to have a standard package like that, a logging facility is mandatory for most -if not all- applications > > > > Any advice or pointers ? > > Object logging instead of String logging is the way to go. SystemLogger, Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past discussions. > > > TIA > > -- > > Regards, > > > > Alain > > > > > > >

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Tudor Girba

Hi, Log4j types of logging systems do a reasonable job at capturing log entries, but they are poor at helping the human make sense of the produced log. Of course, they do attempt, but given that they see the log as a long string, there is a significant mechanism built around formatting. This is broken because it implies that the human should read the log as a way of understanding it. This works fine for a couple of lines but fails miserably for even Mb logs (not to mention larger logs). One could tweak the formatting to make it machine readable, but in practice all logs I have seen in enterprise systems are mostly unstructured and one has to spend great effort to extract the useful information out of them. For example, I use the information in logs to understand performance and diagnose errors, and I am using automatic tools for that. But, to build those tools, the hardest part is to parse the log. That cost should not exist. The object as an item of logging preserves the original information so that the machine can read it. String is just a way of serializing an object, and we should only use it only in this way. Formatting still has a place, but it should be clear that it is just one tool - most often the least useful one. That is the reason why in Beacon, there is no formatting in the core. Priority is another thing I find rather artificial. For example, developers should mark as DEBUG things that are not useful in production, but in the end, they mark as DEBUG things that are too large to have in production all the time. The problem with this is that sometimes you really want to have access to a very specific event regardless of "priority". So, a better way of looking at filtering is by allowing the developer to cherry pick any event at any given moment. We definitely have to get good at the backend, but logging objects should provide a significant advantage. Cheers, Doru On Tue, Jan 13, 2015 at 10:05 AM, S Krish <krishnamachari.sudhakar(a)gmail.com > wrote: > > Log4J does do Event object logging by default. I see it may be relevant to > roll it into log4s also. I remember Toothpick probably did that > > On Tue, Jan 13, 2015 at 11:30 AM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> First of all, I am not the developer of Log4s, but I have been using it >> for a while and I see no significant gain switching to SystemLogger or >> ZnLogEvent. As Alain said, it is based in Log4j, which has his own >> Wikipedia page: http://en.wikipedia.org/wiki/Log4j >> >> I don't think there is too much sense in having "Log Objects" around, >> where probably I want to tail a daily rolled log from a headless remote >> image. I read the documentation of SystemLogger hoping to find a mechansim >> which dynamically selects compression strategies based in what's logged, or >> some other advanced feature, but I didn't found any :( >> >> So if Object logging is implementing #asLog and #logClass methods maybe I >> should add them so Log4s can log "Object" :). But seriously, such >> comparison is not fair. Let's compare real logging features: priorities, >> levels, appenders, output destinations, hierarchical logging, formatting >> layout, etc. Many of them are implemented in Log4s. >> >> Cheers, >> >> HernÃ¡n >> >> 2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >>> > On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >>> > >>> > hi all, >>> > >>> > Googling a bit for a logging framework in Pharo, I found sl4j, which >>> sounds familiar to me. >>> > http://ss3.gemstone.com/ss/Log4s.html/Wiki >>> > >>> > I suppose the API is the same as the java package, as claimed by the >>> project page. >>> > I wonder if anybody is using it , or has tried it and have an advice >>> on that package ? >>> > (I saw there was no test and no comments ... :( ) >>> > >>> > I think it could be great for Pharo to have a standard package like >>> that, a logging facility is mandatory for most -if not all- applications >>> > >>> > Any advice or pointers ? >>> >>> Object logging instead of String logging is the way to go. SystemLogger, >>> Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past >>> discussions. >>> >>> > TIA >>> > -- >>> > Regards, >>> > >>> > Alain >>> > >>> > >>> >>> >>> >> > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by S Krish

Log4J does do Event object logging by default. I see it may be relevant to roll it into log4s also. I remember Toothpick probably did that On Tue, Jan 13, 2015 at 11:30 AM, HernÃ¡n Morales Durand < hernan.morales(a)gmail.com> wrote: > First of all, I am not the developer of Log4s, but I have been using it > for a while and I see no significant gain switching to SystemLogger or > ZnLogEvent. As Alain said, it is based in Log4j, which has his own > Wikipedia page: http://en.wikipedia.org/wiki/Log4j > > I don't think there is too much sense in having "Log Objects" around, > where probably I want to tail a daily rolled log from a headless remote > image. I read the documentation of SystemLogger hoping to find a mechansim > which dynamically selects compression strategies based in what's logged, or > some other advanced feature, but I didn't found any :( > > So if Object logging is implementing #asLog and #logClass methods maybe I > should add them so Log4s can log "Object" :). But seriously, such > comparison is not fair. Let's compare real logging features: priorities, > levels, appenders, output destinations, hierarchical logging, formatting > layout, etc. Many of them are implemented in Log4s. > > Cheers, > > HernÃ¡n > > 2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > >> > On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: >> > >> > hi all, >> > >> > Googling a bit for a logging framework in Pharo, I found sl4j, which >> sounds familiar to me. >> > http://ss3.gemstone.com/ss/Log4s.html/Wiki >> > >> > I suppose the API is the same as the java package, as claimed by the >> project page. >> > I wonder if anybody is using it , or has tried it and have an advice on >> that package ? >> > (I saw there was no test and no comments ... :( ) >> > >> > I think it could be great for Pharo to have a standard package like >> that, a logging facility is mandatory for most -if not all- applications >> > >> > Any advice or pointers ? >> >> Object logging instead of String logging is the way to go. SystemLogger, >> Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past >> discussions. >> >> > TIA >> > -- >> > Regards, >> > >> > Alain >> > >> > >> >> >> >

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Sven Van Caekenberghe

> On 13 Jan 2015, at 07:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > First of all, I am not the developer of Log4s, but I have been using it for a while and I see no significant gain switching to SystemLogger or ZnLogEvent. As Alain said, it is based in Log4j, which has his own Wikipedia page: http://en.wikipedia.org/wiki/Log4j > > I don't think there is too much sense in having "Log Objects" around, where probably I want to tail a daily rolled log from a headless remote image. I read the documentation of SystemLogger hoping to find a mechansim which dynamically selects compression strategies based in what's logged, or some other advanced feature, but I didn't found any :( Maybe we should do away with Events as objects, Methods as objects, Exceptions as objects, Announcements as objects, Ring, MC, Commands as objects, Windows, Menus, ... - well, this whole objects everywhere thing is silly, let's use strings instead ;-) We'll keep on trying to explain and to explore the possibilities. Log objects are much more powerful, less expensive than you think, and backwards compatible with textual output. Logging is deceptively simple, managing megabytes of log files is a PITA. Structure, classification, intelligence, behaviour are the answers. BTW, it is not that you are not allowed to log some simple things to the Transcript, it is that it does not really scale, conceptually. > So if Object logging is implementing #asLog and #logClass methods maybe I should add them so Log4s can log "Object" :). But seriously, such comparison is not fair. Let's compare real logging features: priorities, levels, appenders, output destinations, hierarchical logging, formatting layout, etc. Many of them are implemented in Log4s. > > Cheers, > > HernÃ¡n > > 2015-01-12 14:56 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 12 Jan 2015, at 18:27, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > > > hi all, > > > > Googling a bit for a logging framework in Pharo, I found sl4j, which sounds familiar to me. > > http://ss3.gemstone.com/ss/Log4s.html/Wiki > > > > I suppose the API is the same as the java package, as claimed by the project page. > > I wonder if anybody is using it , or has tried it and have an advice on that package ? > > (I saw there was no test and no comments ... :( ) > > > > I think it could be great for Pharo to have a standard package like that, a logging facility is mandatory for most -if not all- applications > > > > Any advice or pointers ? > > Object logging instead of String logging is the way to go. SystemLogger, Beacon, Zinc's ZnLogEvent are examples. Search the mailing list for past discussions. > > > TIA > > -- > > Regards, > > > > Alain > > > > > > >

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Alain Rastoul

Le 13/01/2015 07:03, HernÃ¡n Morales Durand a Ã©crit : > Hi Alain, > > You have a Log4s podcast here > > http://www.jarober.com/blog/blogView?entry=3509625595 > > and documentation here > > http://www.instantiations.com/docs/852/wwhelp/wwhimpl/js/html/wwhelp.htm#hr… > > I have a real web application using Log4s here: > http://www.smalltalkhub.com/#!/~hernan/IGEVET > and a repository where I try to post fixes or any improvement: > http://www.smalltalkhub.com/#!/~hernan/Log4s (don't hesitate to ask me > for access if you want to contribute) Hi Hernan, Thank you for the pointers. I think today there are two very different use cases of a logging system : in production, where you need a robust, efficient and if possible standard (for example one that logs to system logs in a standard way, why appenders are importants IMHO), and in development, where you need to log information about your program to help you in your developement. I also asked that myself, what makes logging objects different from "standard" logging systems? May be as you say, is not so different, and may be also with growth of the "platform as a service" trend, administrators and operation systems engineers will become developers (or builders) of their own production platform, some kind of new developers? And using standard logger with objects, appenders could make the difference What I also like in the Beacon approach is that it is event driven. Having sensors plugged in the code looks very attractive. > > Let us know if you have specific questions. > > Cheers, > > HernÃ¡n -- Regards, Alain

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by HernÃ¡n Morales Durand

Hi Alain, You have a Log4s podcast here http://www.jarober.com/blog/blogView?entry=3509625595 and documentation here http://www.instantiations.com/docs/852/wwhelp/wwhimpl/js/html/wwhelp.htm#hr… I have a real web application using Log4s here: http://www.smalltalkhub.com/#!/~hernan/IGEVET and a repository where I try to post fixes or any improvement: http://www.smalltalkhub.com/#!/~hernan/Log4s (don't hesitate to ask me for access if you want to contribute) Let us know if you have specific questions. Cheers, HernÃ¡n 2015-01-12 14:27 GMT-03:00 Alain Rastoul <alf.mmm.cat(a)gmail.com>: > hi all, > > Googling a bit for a logging framework in Pharo, I found sl4j, which > sounds familiar to me. > http://ss3.gemstone.com/ss/Log4s.html/Wiki > > I suppose the API is the same as the java package, as claimed by the > project page. > I wonder if anybody is using it , or has tried it and have an advice on > that package ? > (I saw there was no test and no comments ... :( ) > > I think it could be great for Pharo to have a standard package like that, > a logging facility is mandatory for most -if not all- applications > > Any advice or pointers ? > TIA > -- > Regards, > > Alain > > >

Jan. 13, 2015