- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] Logging API discussion

by Denis Kudriashov

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. And I saw hierarchy of ZnClientLogEvent (9 classes) which is just data objects without any behaviour. 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. 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. 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.

April 26, 2016

Re: [Pharo-dev] [Vm-dev] New Cog VMs available

by Holger Freyther

> On 23 Apr 2016, at 21:48, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: Dear Eliot, > > ... at http://www.mirandabanda.org/files/Cog/VM/VM.r3684 > > CogVM binaries as per VMMaker.oscog-eem.1834/r3684 thank you for the new release. I re-ran my TCAP decoding benchmark and this release is comparable to the previous one and as such slower than the < 3500 releases were. kind regards holger

April 26, 2016

Re: [Pharo-dev] Logging API discussion

by Robert Withers

Hi Denis, I was missing this fine-grained logging also so I wrote a couple of classes, long ago, that use events. It still logs to the Transcript and to a log file, in parallel. The test doesn't even make a test, to my chagrin. Look at TraceMonitor for the output bits and at senders of Object>>#etrace: aTraceEvent for the input side. It's in the class category: OCapPresentation-Base-Trace & extensions in the Cryptography repository. I was thinking remote logging, if I can ever untangle this code. It's always a question of crafty avoidance or sitting down and digging into code. I can be crafty7. Cheers, Robert On 04/26/2016 04:23 PM, Denis Kudriashov wrote: > Hi > > 2016-04-26 20:16 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu > <mailto:sven@stfx.eu>>: > > Try to look at it this way: by using objects (events, signals, > announcements, whatever) and just generating them on the spot and > sending them off somewhere, you have everything you need, without > imposing any restrictions. > > > If logging system will not allow me to log arbitrary object it would > be restriction. And by "log object" I mean not just adding it to some > log collection. But I need ability to mark objects with tags, messages > and timestamps. > > If you want to use log/severity levels and/or categories and/or > tags, you can do that. But I don't want to. Your objects will > contain that info and you will be able to filter on it. > > > Most of objects not have timestamp, tag or user message. So I can't > filter them in such naked state. And instead of generating special > objects with such information I want logging library take care about it. > Of course for some cases I will need special objects for logs. But I > should not be forced to do it every time. -- Robert . .. ... ^,^

April 26, 2016