2012/5/31 Guillermo Polito <[email protected]> > On Thu, May 31, 2012 at 9:21 AM, Santiago Bragagnolo < > [email protected]> wrote: > >> Hi again >> >> Im already add several classes to the logger. >> >> http://ss3.gemstone.com/ss/PaulLePulp >> >> the way to use it still primitive, but is a nice draft. >> >> >> If you look at LogConfiguration configuration (class method) you'll find >> something like this >> >> >> self for:[ :builder | >> builder forClass:LogTestObject >> useLevel:#info >> showingLogAs: ('[%pid | %tstmp | %tag] #%class >> >> %selector' asPatternFormatter) >> > > nice :) > > into: Transcript asLogWriter >> > > What if you want to configure multiple destinies? :D >
> * great idea, i just thogh about classes, packages and defaults. I'll > add a class enumeration and a regular expression. (wait, finally it could > be just regular expressions :3, with defaults)* > > > >> retain:true. >> >> builder forKey:'default' useLevel:#error. >> ] >> > > What about moving the configuration elsewhere? :) Having to change the > #configuration method every time is a pain in the ass. > * yes yes, i know, its there cause i didnt think any better place :(. Im all ears. * >> then, with LogTestObject, if you send it "error", "warn" or "info", all >> you send there (blocks, strings, symbols or what-understand-value) will be >> showed at Transcript. (im didnt test on file or stdout yet) >> >> Finally retain:true adds the log to LogHolder, which responds to >> LogHolder instance select:[ :log | log whatYouWantToTest ]. >> > > didn't get this #retain: part. Maybe I should have a look at the code. > * The retain is a flag that say 'hey! i want that logObject to work with it later' then, it's stored on LogHolder instance collection. I'll refact later the mechanism to make a writer strategy of that LogHolder, but i need to extend my writers to a composite solution first, and think a cool way to compose them at configuration ( im all ears here too)* > >> Ill be testing tomorrow and fixing, but, if you want to see and advise >> me, you are welcome :) >> > > And now you have another thing to post on your blog :3. > * Yeah :D * > > >> >> Ok, is 4am, im going to sleep >> >> >> >> >> 2012/5/30 Stéphane Ducasse <[email protected]> >> >>> I would like a logging mechanism that manipulate objects that then are >>> printed in various format. >>> The compiler could use such logger >>> >>> I did not look at the code of toothpick probably extending LoggingEvent >>> should do it. >>> >>> Stef >>> >>> >>> On May 30, 2012, at 3:41 PM, Santiago Bragagnolo wrote: >>> >>> > Ok, i'll take what i need from the marianito's and zn and fork them in >>> an other package, add what i need for massive loggin (like levels of >>> loggin) and make a log-framework. >>> > >>> > Any names? clairvoyant :3? >>> > >>> > Then, is any easy aspect fwk that could i use for the logger? >>> (sometimes i need just trace runtime, or i dont want to add a log line one >>> by one) that works in pharo 2.0 ? :P? >>> > >>> > >>> > 2012/5/30 Sven Van Caekenberghe <[email protected]> >>> > >>> > On 30 May 2012, at 01:56, Santiago Bragagnolo wrote: >>> > >>> > > Im looking for a log framework with configurable levels. Theres any >>> stable and useful? I browsed the list and didn't find nothing but >>> something like 'every body has its own logging framework'. >>> > > >>> > > I wrote a small logging fwk for my project, but if is any more >>> complete, it would be great. >>> > >>> > There is one logging framework already in your image: >>> Zinc-HTTP-Logging. >>> > It is based on Announcments. Although it is part of Zn, it is general >>> purpose. >>> > What is special is that it logs the process ID as well, which is >>> useful to debug multiprocess applications. >>> > See the Zn documentation for more info. >>> > >>> > Sven >>> > >>> > >>> > >>> >>> >>> >> >
