- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Logging API discussion

by stepharo

Le 27/4/16 Ã 14:16, Denis Kudriashov a Ã©crit : > 2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > I must confess I cannot follow you completely. What we were/are > talking about is that the assumption a logging entry needs > timestamp, log level and such is not appropriate. If you have > legacy syslog style logging in mind it appears natural but for a > lot of use cases it is not. > > > Could you provide example where it is not? > > Even if you could say that a timestamp is part of the logging > domain it is not said if that timestamp needs to be part of the > log object or the logger consuming this object. This question > arises for every quality of a logging object. Even the logging > level could be some behavioral quality that a logger matches to > log levels. Contrary to this is logging thisContext which has to > be done in the log object. > I think the hard part is the way of distribution of log objects > and filtering of them. While the former is being discussed with > Beacon the latter is mostly ignored while being really important. > Not having default qualities of a log object is good on one hand > but on the other hand the filtering is much harder. > In SystemLogger we didn't go far enough at first. The Log class > contained level and such. That was the reason for me to split it > into BasicLog consisting of timestamp and a message object and Log > which contains the extra qualities. > > > My problem with such approach is that it forces me to create hierarchy > of log events as subclasses of base log component. not necessary we could have Log being a potential wrapper. > Imaging that my application already provide hierarchy of events but > they have no timestamps. How to log them? Should I use some > WrapperSignal? > Now imaging that application uses some library which provides events > too. But this events are log entries themselves. What I will see in my > logs? > I will see mix of WrapperSignal's and normal events. It would be not > easy to analize such log. > > That's why I want unified log entries. I would model it with single > class LogEntry which nobody needs to subclass. It would contain > logging domain information: timestamp, importance level, user message > and whatever. And it would have *content *property to keep logging > object. So our tools can rely on this structure to make it easy to > work with logs. And when anybody will look at particular log he will > be sure that logging object is inside "content" variables of each record

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by stepharo

Le 27/4/16 Ã 13:01, Denis Kudriashov a Ã©crit : > Hi Norbert > > 2016-04-27 10:43 GMT+02:00 Norbert Hartl <norbert(a)hartl.name > <mailto:norbert@hartl.name>>: > > So assuming the Log class would not contain log levels but SysLog > would do you could easily override #logClass in your domain object > and use it this way > > MyDomainClass class>>#logClass > ^ SysLog > > myDomainObject asLog > warning; > emit > > This way we do not need to pollute Object with a lot of methods > that are tight to one use case. The call to #warning could be > something else that only depends on the Log class you want to use. > > > There is one problem with this approach when we split preparation and > emitting of log object. It will always produce garbage. If no logs > will have interest in myDomainObject or #warning-level messages > application will continue create log entries. Denis I do not get what you mean with the sentence above. > I think it is important to minimize cost of logging when nobody have > interest on particular event. If debug-level log is disabled then no > garbage should be created. If stack traces log is disabled then no > stack information should be retrieved anywhere. > To achieve this we should create log entry instances only when we will > find any logs for them. It imposes restriction on possible API. At > point when we are ready to log something we should have all > information which can be part of filter. So if we want to filter logs > by domain objects and log-levels we need both parameters in one > message send. Then we can ask every registered log for interest about > both of them. And only when we will find any one we will create log > entry instance for them. > > >

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by stepharo

> I must confess I cannot follow you completely. What we were/are > talking about is that the assumption a logging entry needs timestamp, > log level and such is not appropriate. If you have legacy syslog style > logging in mind it appears natural but for a lot of use cases it is > not. Even if you could say that a timestamp is part of the logging > domain it is not said if that timestamp needs to be part of the log > object or the logger consuming this object. This question arises for > every quality of a logging object. Even the logging level could be > some behavioral quality that a logger matches to log levels. Contrary > to this is logging thisContext which has to be done in the log object. > I think the hard part is the way of distribution of log objects and > filtering of them. While the former is being discussed with Beacon the > latter is mostly ignored while being really important. Not having > default qualities of a log object is good on one hand but on the other > hand the filtering is much harder. > In SystemLogger we didn't go far enough at first. The Log class > contained level and such. That was the reason for me to split it into > BasicLog consisting of timestamp and a message object and Log which > contains the extra qualities. Nowadays I think you should be able to > use any object as log object. The provided classes are just helpers. A > composed object that has timestamp, level and a message object is a > good utility but not a requirement. We need to support all of these. > And so I would object against putting a lot of protocol in the Object > class. In SystemLogger you 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 > > So assuming the Log class would not contain log levels but SysLog > would do you could easily override #logClass in your domain object and > use it this way > > MyDomainClass class>>#logClass > ^ SysLog > > myDomainObject asLog > warning; > emit > > This way we do not need to pollute Object with a lot of methods that > are tight to one use case. The call to #warning could be something > else that only depends on the Log class you want to use. > > So to me the discussion about Log classes is not very helpful. We can > have dedicated log classes like the stack capturing one but also one > that is composed of the message object and certain qualities. If you > would have a WrappedSyslogSignal you can have a log object that is > composed and syslog aware by providing log levels. Again I think the > hard part is to have flexible logging and still be able to filter it. > I would like to be able to attach a handful of loggers and be sure the > loggers get the right set of log objects they are interested in. > Hi norbert I agree. I have the impression that in SystemLogger I would change message: into object: in Log and remove all the extension API I tried to design. This way people can just pass the object they want if they want still to have the object wrapped into a Log instances. I think that Log instances and subclasses would be nice to have specific behavior (like menu actions when we want to manipulate logs). For example, I would like to have a tool looging all the methods that I did not define during a prototype session and after I can click on them and say "define skeleton" and boum I get a skeleton for all the methods inside their respective classes. Stef

April 27, 2016

Re: [Pharo-dev] [Pharo 5] Gettext

by Hilaire

Here are the overall process http://pharo.gemtalksystems.com/book/LanguageAndLibraries/Localisation For Dr. Geo I have bit more to decide which font to load at start up depending on the locale (This is where Pharo5's locale refactoring break it) but you should not need it for European languages. Hilaire Le 27/04/2016 19:23, stepharo a Ã©crit : > > Do you have some examples/doc/text how you do the internationalisation > in DrGeo because I will start to need that? -- Dr. Geo http://drgeo.eu

April 27, 2016

Re: [Pharo-dev] Command Line Arguments

by Esteban Lorenzano

pharo Pharo.image --list will give you the command lines available, then pharo Pharo.image aCommand --help will give you the subcommands possible in your case, you want something like this: pharo Pharo.image eval â99 factorialâ cheers, Esteban ps: this questions are more for the pharo-users list than pharo-dev :) > On 27 Apr 2016, at 20:04, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > > there should be a handler name in there. > > Like in pharo-ui Pharo.image st somefile.st <http://somefile.st/> > st is the handler. > as is eval or config or your own. > > Check subclasses of CommandLineHandler including class side. > > Phil > > On Apr 27, 2016 6:50 PM, "blake watson" <dsblakewatson(a)gmail.com <mailto:dsblakewatson@gmail.com>> wrote: > Hi-- > > I've seen this come up several times (and it's in "Deep") but I can't seem to actually make Command Line Arguments work. > > If I do (this is under Windows, but I set up a fresh Linux just to ensure it wasn't a Windows quirk): > > Pharo.exe Pharo4.0image 99 > > Pharo comes up with "Command line handler failed". I see in the stack trace that the "99" comes in as an orderedCollection. And if I do: > > Pharo.exe Pharo4.0image 99 100 101 > > I get an orderedCollection with 99, 100 and 101, which is what I'd expect. In fact, it would be perfect if it didn't crash and put those values somewhere, like, I don't know, CommandLineArguments' arguments variable? =) > > So, I'm obviously not getting something here. How do I make simple parm passing work? > > Also, I note that: > > Pharo.exe 99 100 101 > > Brings up Pharo with the default image but swallows the 99, which seems odd. I'm guessing that it looks for a 99.image and not finding it, ignores the parameter and loads the default image. But it'd be smarter at that point to put the 99 back, I think. > > ===Blake=== >

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by stepharo

> This type of usage should be discouraged in my opinion. We should > instead encourage people to use typed logging signals, like we > should also discourage people from using > self error: âa magic string hereâ. > > > > But when we log some information we usually want to log it with > little remark, importance level and (most important) timestamp. > This information is kind of standard for logging domain. But it > requires much more methods for logging API. > > So we need extra information to put together with objects: > > â¢ timestamp > > â¢ user message > > â¢ importance level (debug, info, error, etc.) > > Please do not do that. This might make sense for C or Java > (although it does not), but we have objects and we should filter > based on those without relying on a rigid system based on random > levels. Please. > > > Before I start to think about logging I was agree with you. Now I am > not. This kind of information belongs to logging domain. It can be > retrieved from application objects as default values but at the end it > should be explicit part of log entries. We can read it in logs for > every record to realize when and why object was added to log, what > this record is about. But denis why this is not for a certain kind of subclass You have Log with the minimal information (timestamp and an object) then you can have logger with levels and other. > > And you say let's replace this "log object context" information with > first class entities "typed signals". It means that for any possible > case when I want to put something in log I should create class for new > signal. It's just not practical. why? MySpecialLog ... emit > Beacon introduce WrapperSignal to solve it. But it only provides > target and timestamp. What I should do if I want to put little remark > for my object? And what if I want to put little remark for > ThisContextSignal? > > My idea that logging should be as simple as possible and we not need > another "everything is signal" concept here: it is restriction. > Everything is object. And every object should be able to log. In the minimalLog MinimalLog object: MyCoolObject new; emit no need of message > > And about random log levels. Their purpose is to mark log entries with > importance level which is useful to explore logs. > Imaging we have system which produce some events and we log them. (My > and your approaches allow it. Only difference that in my approach this > event will be part of log entry (as composition) and with your > approach this event will be log entry itself). > Now imagine that we need to explore some problem situation when > particular events are appeared but they should not. I would try to > find wrong places in code where events can be signalled and I would > log them their. > With my approach I will log them with specific importance level > (#warning) and specific message to distinguish them from normal > events. With my API it is super easy. > With your approach I will need to create new classes to signal this > situation. > Also my approach allows me to configure in advance my application to > put warnings in separate log. So I will not need to change app configs > to simplify experiment. I will just deploy new code with extra logging > and wait results in ready to use log. > > My proposals are not opposite to your. I just not put extra > restrictions. Beacon can be based on top of it but not vice versa.

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by stepharo

what I can tell you is that I do not like the API I did for extending Log in SystemLogger. I will try to read your long email. Now I have the impression that wrapping an object in the log could be a way to offer extensibility. Le 26/4/16 Ã 15:26, Denis Kudriashov a Ã©crit : > Hello. > > I resumed discussion about SystemLogger and Beacon here > http://forum.world.st/What-the-state-of-unifying-Beacon-with-SystemLogger-t…. > > I plan to unify both approaches by saving traditional terminology from > SystemLogger and cool features from Beacon. > > Let's think about logging API to log any object in the system. Most > natural way is just send message #log to object itself: > > anObject log > > > It would be nice replacement for Object>>logCr. > But when we log some information we usually want to log it with little > remark, importance level and (most important) timestamp. This > information is kind of standard for logging domain. But it requires > much more methods for logging API. > So we need extra information to put together with objects: > > 1. timestamp > 2. user message > 3. importance level (debug, info, error, etc.) > 4. whatever (process hash, process name for example) > 5. sometimes it can be needed to put in log something different than > object itself. (for example it can be just copy of object to not > change state of log entry during app lifetime) > > Here is possible API based on Object extensions. It has drawbacks but > it is good to think about it too: > > "it will put anObject in logs with default #info level" > > anObject log > > "it will put anObject in logs with default #info level and given > user message" > anObject logWith: 'something interesting was happened with anObject' > > "inside block we can put any logging domain information from > application and also override content by specific representation" > anObject logBy: [:logEntry | > > logEntry message: 'something interesting to be saved with > our object' > > logEntry content: anotherObject] "here logs with interest > about anObject will receive logEntry with anotherObject instead of > anObject" > > > And similar for different kind of levels: > > anObject logForDebug. > anObject logForDebugWith: 'some debug message' > anObject logForDebugBy: [:logEntry | ] > > > anObject logAsError. > anObject logAsError: 'object computation was wrong' > anObject logAsErrorBy: [:logEntry | ] > > And most general: > > anObject logAs: LogLevel warn > > anObject logAs: LogLevel warn with: 'something interesting' > anObject logAs: LogLevel warn by: [:logEntry | ] > > > And in case of classic logging with strings only first expressions > would be used: > > 'some info message' log. > 'some debug message' logForDebug > 'some error message' logAsError > 'some warn message' logAs: LogLevel warn > > Problem with this approach: it pollutes Object with 12 extra methods > and it can be more. So maybe it is better to use current SystemLogger > API based on class Log: > > Log info: anObject > Log info: anObject as: 'computation result' "as example" > Log info: anObject as: [:logEntry | > > logEntry message: 'something interesting to be saved with our > object > > logEntry content: anotherObject] > > > Log error: anObject > > Log error: anObject as: 'computation was wrong'' > > Log error: anObject as: [:logEntry | ] > > > Comparing to original SystemLogger versions I separate user message > from object content. It makes possible to log any object with extra > user message. > But anyway it not feels very well IMHO. And it requires three methods > for each log level. Maybe we can put this methods into LogLevel itself: > > Log info add: anObject > Log info add: anObject as: 'computation result' > Log info add: anObject as: [:logEntry | > > logEntry message: 'something interesting to be saved with our > object > > logEntry content: anotherObject] > > > Log error add: anObject > > Log error add: anObject as: 'computation was wrong'' > > Log error add: anObject as: [:logEntry | ] > > > And we can make short version for default logging level (which can be > object specific): > > > Log add: anObject > > Log add: anObject as: 'computation result' > > Log add: anObject as: [:logEntry | ] > > > That's all. I hope we can produce best suitable API for object > logging. Then we can think how to adopt SystemLogger or Beacon for it. > Also think about this API in context that we can register specific > loggers for specific objects and specific importance level. > > Best regards, > Denis

April 27, 2016

Re: [Pharo-dev] Happy with Pharo 5.0 release!

by stepharo

Thanks mariano But it is not out yet :) And yes this is great to see all the good energy that went into Pharo 50. Stef Le 27/4/16 Ã 16:09, Mariano Martinez Peck a Ã©crit : > Hi guys, > > This is just to let you know I am very happy with Pharo 5.0 upcoming > release. I was already used quite a lot for other projects > (OSSubprocess etc), but a couple of days ago, I started to develop my > client's app (Quuve) and so far so great. It only took me an hour or > so to update all my dependencies in my Metacello conf (I have a lot of > dependencies). So..thanks for all those who have been updating their > confs! > > I was already familiar with all the GT tools so I was happy with that. > I really notice a speed up (I guess in big part thanks to Spur) and so > far it was quite robust. I also noticed some memory leak fixing...as > previously in 4.0 I was re-building images all the time because I get > to 500MB in no time. Right now I keep using the same image as for > several days and so far no problem with memory. > > Finally...let me say.... if for Pharo 6.0 we finally get Git support > directly integrated into the image and we get expected Sista speedup, > I think it will be the best release ever hahahahha. > > Thanks for all your efforts and congratulations for the upcoming > release. I am already enjoying it since several weeks already. > > -- > Mariano > http://marianopeck.wordpress.com

April 27, 2016

Re: [Pharo-dev] Command Line Arguments

by philippe.back＠highoctane.be

there should be a handler name in there. Like in pharo-ui Pharo.image st somefile.st st is the handler. as is eval or config or your own. Check subclasses of CommandLineHandler including class side. Phil On Apr 27, 2016 6:50 PM, "blake watson" <dsblakewatson(a)gmail.com> wrote: > Hi-- > > I've seen this come up several times (and it's in "Deep") but I can't seem > to actually make Command Line Arguments work. > > If I do (this is under Windows, but I set up a fresh Linux just to ensure > it wasn't a Windows quirk): > > Pharo.exe Pharo4.0image 99 > > Pharo comes up with "Command line handler failed". I see in the stack > trace that the "99" comes in as an orderedCollection. And if I do: > > Pharo.exe Pharo4.0image 99 100 101 > > I get an orderedCollection with 99, 100 and 101, which is what I'd expect. > In fact, it would be perfect if it didn't crash and put those values > somewhere, like, I don't know, CommandLineArguments' arguments variable? =) > > So, I'm obviously not getting something here. How do I make simple parm > passing work? > > Also, I note that: > > Pharo.exe 99 100 101 > > Brings up Pharo with the default image but swallows the 99, which seems > odd. I'm guessing that it looks for a 99.image and not finding it, ignores > the parameter and loads the default image. But it'd be smarter at that > point to put the 99 back, I think. > > ===Blake=== > >

April 27, 2016

Maintainer of pharo-contribution/job/PharoBookWorkInProgress CI

by Esteban A. Maringolo

Hi, Who is the maintainer of PharoBookWorkInProgress contribution job? It is failing since several builds ago, and apparently it has to do with a missing font in the LaTeX to PDF conversion. https://ci.inria.fr/pharo-contribution/job/PharoBookWorkInProgress/ Regards! Esteban A. Maringolo

April 27, 2016