April 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50723 Home: https://github.com/pharo-project/pharo-core

April 27, 2016

Re: [Pharo-dev] Logging API discussion

by Norbert Hartl

Denis, > Am 26.04.2016 um 17:28 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hi Tudor. > > 2016-04-26 15:36 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>>: > > > 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. > > 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. > > 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. > 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. > > 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. 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. Norbert

April 27, 2016

Re: [Pharo-dev] XMLParser changes

by Cyril Ferlicot Delbecque

On 27/04/2016 09:12, stepharo wrote: > Hi guys > > > I did not understand where are the spaces? > The whitespaces are the line return and tabulation (indent) for the pretty print. > Can you show me? > > Stef > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

April 27, 2016

Re: [Pharo-dev] Mocketry names again

by Denis Kudriashov

2016-04-27 0:33 GMT+02:00 Carlos Lombardi <carlombardi(a)gmail.com>: > ... maybe > > #result should beTheResultOf: [mock someMessage]. > #result should not beTheResultOf: [mock anotherMessage]. > It's nice.I think "The" can be omitted: #result should beResultOf: [mock someMessage]. But anyway I use word #return because there are different types of result: value return and error signal. There is no expression for last case but it would be like: anError should beRaisedBy: [mock someMessage]

April 27, 2016

Re: [Pharo-dev] XMLParser changes

by Norbert Hartl

Stef, if you have <a>foo</a> and then you indent it <a> foo </a> you insert after <a> a newline and spaces or tabs as well as after . In this case the whitespace between <a> and is valid but ignorable. Norbert > Am 27.04.2016 um 09:12 schrieb stepharo <stepharo(a)free.fr>: > > Hi guys > > > I did not understand where are the spaces? > > Can you show me? > > Stef > > >>>> (XMLDOMParser parse: '<?xml version="1.0" encoding="UTF-8"?> >>>>  >>>> <Clones> >>>> <ClonedFragment cloneName="test"> >>>> <Member fileName="ProgramA"/> >>>> <Member fileName="ProgramB"/> >>>> </ClonedFragment> >>>> <ClonedFragment cloneName="test2"> >>>> <Member fileName="ProgramA"/> >>>> <Member fileName="ProgramB"/> >>>> </ClonedFragment> >>>> </Clones>') elements first nodes >>>> >>>> With the release 2.7.4 we get 2 nodes but in release 2.7.6 we get 5 >>>> nodes. The 2 previous ones and 3 empty String nodes. >>>> >>>> I think this is not what we expect. Correct me if I am wrong :) >>>> >>>> >>> >> > >

April 27, 2016

Re: [Pharo-dev] XMLParser changes

by stepharo

Hi guys I did not understand where are the spaces? Can you show me? Stef >>> (XMLDOMParser parse: '<?xml version="1.0" encoding="UTF-8"?> >>>  >>> <Clones> >>> <ClonedFragment cloneName="test"> >>> <Member fileName="ProgramA"/> >>> <Member fileName="ProgramB"/> >>> </ClonedFragment> >>> <ClonedFragment cloneName="test2"> >>> <Member fileName="ProgramA"/> >>> <Member fileName="ProgramB"/> >>> </ClonedFragment> >>> </Clones>') elements first nodes >>> >>> With the release 2.7.4 we get 2 nodes but in release 2.7.6 we get 5 >>> nodes. The 2 previous ones and 3 empty String nodes. >>> >>> I think this is not what we expect. Correct me if I am wrong :) >>> >>> >> >

April 27, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50722 Home: https://github.com/pharo-project/pharo-core

April 27, 2016

[pharo-project/pharo-core] 784a2d: 50722

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 784a2d28016f67372b71fa0916f695902921ab87 https://github.com/pharo-project/pharo-core/commit/784a2d28016f67372b71fa09… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-04-27 (Wed, 27 Apr 2016) Changed paths: M ConfigurationOfOSWindow.package/ConfigurationOfOSWindow.class/instance/symbolic versions/stable_.st A ConfigurationOfOSWindow.package/ConfigurationOfOSWindow.class/instance/versions/version1210_.st A ConfigurationOfOSWindow.package/ConfigurationOfOSWindow.class/instance/versions/version1211_.st M OSWindow-Core.package/OSTouchGestureDetector.class/class/settings/touchGestureSettingsOn_.st M OSWindow-Core.package/OSWindowGLRenderer.class/instance/misc/makeCurrent.st A OSWindow-Core.package/OSWindowGLRenderer.class/instance/misc/makeCurrent_.st M OSWindow-Core.package/OSWindowGLRenderer.class/instance/misc/swapBuffers.st A OSWindow-Core.package/OSWindowGLRenderer.class/instance/misc/swapBuffers_.st M OSWindow-Core.package/OSWindowRenderThread.class/class/render thread/createRenderThread.st M OSWindow-Core.package/OSWindowRenderThread.class/class/render thread/enqueueOperation_blocking_.st A OSWindow-Core.package/OSWindowRenderThread.class/class/render thread/enqueueOperation_blocking_ifError_.st M OSWindow-Core.package/OSWindowRenderThread.class/class/render thread/executeRenderOperations.st M OSWindow-Core.package/OSWindowRenderThread.class/class/window animation/performAnimationFrames.st M OSWindow-Core.package/OSWindowRenderThreadOperation.class/definition.st A OSWindow-Core.package/OSWindowRenderThreadOperation.class/instance/accessing/failed.st M OSWindow-Core.package/OSWindowRenderThreadOperation.class/instance/execute/execute.st M OSWindow-SDL2-Examples.package/OSWindowGenericRendererExample.class/definition.st A OSWindow-SDL2-Examples.package/OSWindowGenericRendererExample.class/instance/as yet unclassified/enqueueRender.st M OSWindow-SDL2-Examples.package/OSWindowGenericRendererExample.class/instance/initialize/destroy.st R OSWindow-SDL2-Examples.package/OSWindowGenericRendererExample.class/instance/instance creation/createDrawingProcess.st M OSWindow-SDL2-Examples.package/OSWindowGenericRendererExample.class/instance/instance creation/open.st A OSWindow-SDL2-Examples.package/OSWindowGenericRendererExampleEventHandler.class/instance/visiting/visitWindowExposeEvent_.st A OSWindow-SDL2-Examples.package/OSWindowGenericRendererExampleEventHandler.class/instance/visiting/visitWindowFrameEvent_.st M OSWindow-SDL2.package/OSSDL2Driver.class/instance/events-processing/processEvent_.st M OSWindow-SDL2.package/OSSDL2GLRenderer.class/definition.st M OSWindow-SDL2.package/OSSDL2GLRenderer.class/instance/initialize/destroy.st M OSWindow-SDL2.package/OSSDL2GLRenderer.class/instance/misc/createContext.st R OSWindow-SDL2.package/OSSDL2GLRenderer.class/instance/misc/makeCurrent.st A OSWindow-SDL2.package/OSSDL2GLRenderer.class/instance/misc/makeCurrent_.st R OSWindow-SDL2.package/OSSDL2GLRenderer.class/instance/misc/swapBuffers.st A OSWindow-SDL2.package/OSSDL2GLRenderer.class/instance/misc/swapBuffers_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50721.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50722.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50721.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50722.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Inspector.package/EyeAbstractInspector.class/instance/initialization/initializePresenter.st M Spec-Inspector.package/EyeInspector.class/instance/event-handling/objectChanged.st M Spec-Inspector.package/EyeInspector.class/instance/initialization/initializePresenter.st M Spec-Inspector.package/EyePointerExplorer.class/instance/event-handling/objectChanged.st M Spec-Inspector.package/EyeTreeInspector.class/instance/accessing/tree.st A Spec-Inspector.package/EyeTreeInspector.class/instance/event-handling/elementChanged.st M Spec-Inspector.package/EyeTreeInspector.class/instance/event-handling/objectChanged.st Log Message: ----------- 50722 18109 EyeInspector has correct syntax highlighting https://pharo.fogbugz.com/f/cases/18109 18110 Support added for using an OpenGL context with multiples windows. https://pharo.fogbugz.com/f/cases/18110 http://files.pharo.org/image/50/50722.zip

April 27, 2016

Re: [Pharo-dev] Mocketry names again

by Carlos Lombardi

... maybe #result should beTheResultOf: [mock someMessage]. #result should not beTheResultOf: [mock anotherMessage]. Cordially - Carlos On Wed, Apr 20, 2016 at 9:22 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-04-20 20:36 GMT+02:00 S Krish <krishnamachari.sudhakar(a)gmail.com>: > >> result should return: [mock someMessage] > > > It should verify that result was returned from message defined inside > block. That's why I use "should beReturnedFrom: [mock someMessage]". > Following test demonstrates idea: > > mock := Mock new. > mock stub someMessage willReturn: #result. > > mock stub anotherMessage willReturn: #anotherResult. > > > mock someMessage should be: #result. > mock anotherMessage should be: #anotherResult. > > #result should beReturnedFrom: [mock someMessage]. > > #result should not beReturnedFrom: [mock anotherMessage] > > >

April 26, 2016

Re: [Pharo-dev] Logging API discussion

by Sven Van Caekenberghe

> On 26 Apr 2016, at 23:17, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-04-26 20:16 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Making log events subclasses of Announcement and using an Announcer instance local to a subsystem is one easy implementation choice, but not necessarily the only one. > > One concrete (but not perfect) implementation of my ideas can be found in the package 'Zinc-HTTP-Logging' in your image. > > I look at it. Thanks for giving feedback. > And I saw hierarchy of ZnClientLogEvent (9 classes) which is just data objects without any behaviour. Right now the event objects themselves are indeed pretty simple, but not totally without behaviour I would say. Most of the functionality is in the objects they encapsulate (like the request and response, the timing information). > For each class there is method in ZnClient with #log...thisEvent pattern. And most of this methods has only sender which executes real business logic on httpClient. For example: > > ZnConnectionEstablishedEvent > ^ > logConnectionEstablishedTo: url started: initialMilliseconds > ^ > newConnectionTo: url > > So for each event ZnClient has two methods. The fact that the logging is abstracted into helper methods is not a requirement per se, it is just code organisation, preferable to super long methods. I see only one #logXXX method per log event. > What I feel here is that if Zinc will be designed with some kind of command pattern all of this would be not needed. > Instead of events and corresponding methods Zinc would have commands which implement real logic and can be logged directly without any special objects. > > I know designing http library is complex task. And maybe my idea is not applicable here. The idea of using command objects as log objects might work in specific situations, it is a good idea, but I doubt it would be applicable to many situations, or cover all logging needs. I'll certainly think about it. > But what I want to say: applications usually already have objects which incapsulate all needed information for logs. And logging system should not require anything else. But that is what is happening here (where it is applicable): the log event object that signals that a request resulted in a specific response for example, contains the actual, original objects; that is why doing this is cheap, the objects already exist. Sven

April 26, 2016