June 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Connecting ZnLogEvents to SystemLogger or Beacon

by Tudor Girba

Hi Sven, Thanks for pushing this. For Beacon, you do not need the wrapper because that is meant for other objects that are not announcements. If you use the Wrapper you lose the type of the event. So, the integration can be even simpler and more powerful: ZnLogEvent announcer when: ZnLogEvent do: [ :each | each log ] for: #beacon. Afterwards, we can listen to specific events only by using the Announcement filtering mechanism. Taking a step back, indeed it is easy to write the code to integrate but it comes at the cost of indirection. Specifically for logging we want the overhead to be as cheap as possible, and for this reason, we want the integration to be as tight as possible. If we look at it, all these three solutions have identical structure: - there is an event (Log, Announcement) - there is something like a broker through which the events are being triggered (LogDispatcher, Beacon, ZnLogEvent announcer) - there are bindings that do something concrete with the events (Logger, BoundedBeacon, AnnouncementSpy) In the case of using Announcements, we can just have support for a central announcer in the image and the integration would be even tighter. For example, if ZnLogEvent would use this global announcer, rather than its own global announcer, it would be cheaper. So, I think the main thing is just to agree on the transmission mechanism. As we have Announcements already, the question is why implement another one? Or, if it is a nail, perhaps a hammer is the right thing to use :) Cheers, Doru On Wed, Jun 18, 2014 at 11:15 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I think we are all pretty much on the same page with how we think logging > has to be done. In any case, here is the code (one, 1, line of code) that > connects ZnLogEvent with either SystemLogger or Beacon - provided I > understood everything correctly. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | BasicLog message: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | WrapperSignal log: each ] > for: #beacon. > > Now this is using a wrapper object, BasicLog and WrapperSignal > respectively. It even seems to work without the wrapping as well. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | LogDispatcher current addLog: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | Beacon announce: each ] > for: #beacon. > > Question is, is the wrapping needed ? For the implementation or for the > user ? Right now, only a timestamp is added. As I indicated before, I don't > think that even 'forcing' a particular timestamp is a good idea. Here is my > reasoning. > > Log events arrive in a certain order and that order should be maintained. > Making log events sortable could be nice to have, but it is not 100% > necessary. The same goes for uniquely identifying log events, nice to have > but not necessary. > > A timestamp might seem like a good idea for both properties, but it is > not. Consider: > > (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: > DateAndTime now ] ]) asSet. > > The set will contain only a couple of instances. And this is for the most > precise timing that we currently have. It is also easy to think of > alternatives for DateAndTime that some people might prefer: just Time, > seconds, micro or milliseconds since a reference, ZTimestamp (which I use > in other code), some class from Chronos, whatever. Features, abstraction, > performance, precision, memory consumption are all different. > > But regardless of clock precision, I think an id is useful as a secondary > sort or identity criterium, just in case. But again, I would not require it. > > On the other hand, we need common protocol. What about the following: each > log event object should implement #timestamp, which has to return a > Magnitude compatible object so that increasing values conform with the > order of the events (but not necessarily vice versa). > > Sven > > > > -- www.tudorgirba.com "Every thing has its own flow"

June 18, 2014

Re: [Pharo-dev] Complaints about Spec

by Benjamin

I understand your frustration, but writing doc takes time. I have a more industry oriented example in polishing mode Ben On 18 Jun 2014, at 11:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, > > I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. > > I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. > > Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? > > Uko > >

June 18, 2014

Re: [Pharo-dev] Connecting ZnLogEvents to SystemLogger or Beacon

by Norbert Hartl

Sven, Am 18.06.2014 um 11:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > I think we are all pretty much on the same page with how we think logging has to be done. In any case, here is the code (one, 1, line of code) that connects ZnLogEvent with either SystemLogger or Beacon - provided I understood everything correctly. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | BasicLog message: each ] > for: #systemLogger. > You can do that. Iâd prefer using âeach asLogâ instead of âBasicLog message: eachâ. This way each can specify its desired wrapper class. > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | WrapperSignal log: each ] > for: #beacon. > > Now this is using a wrapper object, BasicLog and WrapperSignal respectively. It even seems to work without the wrapping as well. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | LogDispatcher current addLog: each ] > for: #systemLogger. > > ZnLogEvent announcer > when: ZnLogEvent > do: [ :each | Beacon announce: each ] > for: #beacon. > > Question is, is the wrapping needed ? For the implementation or for the user ? Right now, only a timestamp is added. As I indicated before, I don't think that even 'forcing' a particular timestamp is a good idea. Here is my reasoning. The wrapping does two things. It adds additional state to form a log object and it adds the behaviour for simplifying the use of a log object (e.g. have a look at BasicLog>>#emit) . To me the timestamp in a log is mandatory. That is IMHO what it makes a log. Without I would call it âan objectâ. > > Log events arrive in a certain order and that order should be maintained. Making log events sortable could be nice to have, but it is not 100% necessary. The same goes for uniquely identifying log events, nice to have but not necessary. > > A timestamp might seem like a good idea for both properties, but it is not. Consider: > > (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: DateAndTime now ] ]) asSet. > > The set will contain only a couple of instances. And this is for the most precise timing that we currently have. It is also easy to think of alternatives for DateAndTime that some people might prefer: just Time, seconds, micro or milliseconds since a reference, ZTimestamp (which I use in other code), some class from Chronos, whatever. Features, abstraction, performance, precision, memory consumption are all different. I donât see a problem here. The timestamp is either a visual help here or if it is more important you need to make sure the precision does cope with your use case. A timestamp might be just a grouping thing to focus more easy on the entries of interest. Iâm not sure it is definable for all use cases. If the order is important than we need to make sure the order is preserved. To pull out an edge case to proof it is of no value is nothing I can submit to. > > But regardless of clock precision, I think an id is useful as a secondary sort or identity criterium, just in case. But again, I would not require it. > That is a good point. In the beginning there was only one Log class. It contained all the stuff like levels, tag and such. That is understandable because logging is done this way (expected by people) usually and we need to break free from that (what we do at the moment by introducing object oriented logging). In my mission to break free from (sys)log I divided the class in BasicLog and Log. BasicLog is what makes a Log: an object and a timestamp. The Log class resembles the other fields like level etc. You can argue that level, tag etc are not needed but a lot of people will need them so why not support them? What if you donât need level, tag etc. but you want to have an id and use another class for timestamp? Thatâs easy just subclass BasicLog, add an id instVar, initialize timestamp with your own class and then overwrite your business objects class side method logClass to return your own decorating class. Thatâs how we always do it, right? And still you could use the stuff from the workspace by doing (SpecialEvent new foo: âbarâ; id: 10000 atRandom) asLog emit > On the other hand, we need common protocol. What about the following: each log event object should implement #timestamp, which has to return a Magnitude compatible object so that increasing values conform with the order of the events (but not necessarily vice versa). Thatâs basically how it is. We should define the protocol the logger needs internally. If there needs to be some access to #timestamp it is part of the interface. So that way we expect an log event object to respond to #timestamp. And the BasicLog is a wrapper that has a default implementation for it. I donât understand what we need to define except the interface that is needed which is obvious? So letâs take the three use cases: subclassing, wrapping and forced duck typing. If it works I would support all of them because people have different ideas how things should work. If that is too much we need to choose. I personally donât like to have to subclass a framework class because Iâd like to preserve the inheritance chain for my own stuff. I also donât like forced duck typing because a framework that forces me to implement a method in every class I want to log is cumbersome to me. So I like wrapping the most because I can add log specific stuff to any object and by being able to supply a wrapping class Iâm free to adapt any object to be a log compatible object. Norbert

June 18, 2014

Re: [Pharo-dev] Complaints about Spec

by Sven Van Caekenberghe

Hi Yuriy, I can't really comment on the overal questions you are asking. But please keep in mind that Apple's Cocoa has had a little bit more resource behind it, for many decades, of course they have a nice design and excellent documentation. I actually have a calculator project which contains a Spec GUI and Seaside GUI on the same model ready, with shared unit tests at the model and both GUI levels. I even use some kind of meta spec to generate both GUIs automatically. My goal is to write a Pharo tutorial about that. But I need more time (I haven't started yet). I'll see what I can do. Overall, although Spec is new to me, I found it acceptable for building functional GUIs. Sven On 18 Jun 2014, at 11:40, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi guys, > > I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. > > I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. > > Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? > > Uko > >

June 18, 2014

Complaints about Spec

by Yuriy Tymchuk

Hi guys, I was very frustrated, but as usually complaints are useless, Iâll try to be constructive. Maybe the problem is not about Spec itself but all the UI related tool-chain. I find UI very fragile part in software design. And by now Iâve seen only 2 very nice documentations on how to develop UI (with MVC). One was for Ruby on Rails, and another was for iOS applications. Documentation was straightforward: 1) this is how your model, view and controller should look like, 2) this is how they have to talk, 3) other useful cases. Now, there is description about how to do something with Spec, and itâs cool, but for example I always get myself caught in initialisation stuff. Spec intends that I provide some default solution if itâs not initialised with proper data. And I even cannot initialise some variables, because initialisation of superclass initialises widgets and they need default behaviour. I can move to sort of lazy initialisation stuff, but maybe there is some reason in making some calculator example tutorial that will show how mvc apps should be developed in Pharo? Uko

June 18, 2014

Connecting ZnLogEvents to SystemLogger or Beacon

by Sven Van Caekenberghe

Hi, I think we are all pretty much on the same page with how we think logging has to be done. In any case, here is the code (one, 1, line of code) that connects ZnLogEvent with either SystemLogger or Beacon - provided I understood everything correctly. ZnLogEvent announcer when: ZnLogEvent do: [ :each | BasicLog message: each ] for: #systemLogger. ZnLogEvent announcer when: ZnLogEvent do: [ :each | WrapperSignal log: each ] for: #beacon. Now this is using a wrapper object, BasicLog and WrapperSignal respectively. It even seems to work without the wrapping as well. ZnLogEvent announcer when: ZnLogEvent do: [ :each | LogDispatcher current addLog: each ] for: #systemLogger. ZnLogEvent announcer when: ZnLogEvent do: [ :each | Beacon announce: each ] for: #beacon. Question is, is the wrapping needed ? For the implementation or for the user ? Right now, only a timestamp is added. As I indicated before, I don't think that even 'forcing' a particular timestamp is a good idea. Here is my reasoning. Log events arrive in a certain order and that order should be maintained. Making log events sortable could be nice to have, but it is not 100% necessary. The same goes for uniquely identifying log events, nice to have but not necessary. A timestamp might seem like a good idea for both properties, but it is not. Consider: (Array streamContents: [ :set | 1000 timesRepeat: [ set nextPut: DateAndTime now ] ]) asSet. The set will contain only a couple of instances. And this is for the most precise timing that we currently have. It is also easy to think of alternatives for DateAndTime that some people might prefer: just Time, seconds, micro or milliseconds since a reference, ZTimestamp (which I use in other code), some class from Chronos, whatever. Features, abstraction, performance, precision, memory consumption are all different. But regardless of clock precision, I think an id is useful as a secondary sort or identity criterium, just in case. But again, I would not require it. On the other hand, we need common protocol. What about the following: each log event object should implement #timestamp, which has to return a Magnitude compatible object so that increasing values conform with the order of the events (but not necessarily vice versa). Sven

June 18, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Sven Van Caekenberghe

Norbert, We are indeed all just discussing and exploring. On the other hand, Zinc has to work for real, on many Pharo versions and even on Gemstone. On 17 Jun 2014, at 17:09, Norbert Hartl <norbert(a)hartl.name> wrote: > Otherwise there will be three half baked approaches, one in zinc, one in GT* tools and one in pharo. What is currently in Zinc-HTTP-Logging is just a rich hierarchy of ZnLogEvent subclasses. ZnLogEvent does indeed hold onto its own announcer, pretty standard stuff I would say. Then there are two convenience methods #logToTranscript, which basically says self announcer when: self send: #crShow: to: Transcript and #open which opens an AnnouncementSpy. That's it. This gives me 99% of what I had before and a nice GUI tool as an extra. There is a #logLevel property in ZnClient and ZnServer to control the volume of log events being generated because I am concerned about performance. We'll see about that. > That would be the worst outcome. In order to prevent that I wanted to talk. Just that! > > My plan is to: > > - look at beacon to see what Doru has in his mind. Maybe I get a good idea from it > - then I would look at Svenâs new code to see the difference to Doruâs and to actual see if that works for more than a framework > - finally I would like to look at the SystemLogger design again and improve it where it might be improved. > - then there will be a new version of SystemLogger. Thatâs it. I'll send a separate mail on how easy it is, I think, to integrate ZnLogEvent with both SystemLogger and Beacon. > I personally donât plan to skip SystemLogger in favour of beacon or zinc log. beacon is a proof of concept but there are AFAIK no formatters, outputs and so on. So it is not even a replacement for SystemLogger. Zinc log is a log system for a single framework called zinc. Iâm not sure it can be useful for anything else and I donât think Sven is hitting in that direction. No, of course not. Again, Zinc-HTTP-Logging is just a rich hierarchy of ZnLogEvent subclasses. > I want a basic logging support that either has a central access for pain free logging or it has multiple announcers (maybe one per module/framework) that can be composed to a log source that can be attached to some kind of dispatcher. I donât know. That I need to figure out > > Norbert Sven

June 18, 2014

[pharo-project/pharo-core] 28f3a2: 40023

by GitHub

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 28f3a22c70ea5dd7d9e84f51a3d909e71bef214d https://github.com/pharo-project/pharo-core/commit/28f3a22c70ea5dd7d9e84f51… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-06-18 (Wed, 18 Jun 2014) Changed paths: A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script23.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40023.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tools.package/ImageCleaner.class/instance/api/cleanUpForProduction.st Log Message: ----------- 40023 13332 fix #cleanUpForProduction for 4 https://pharo.fogbugz.com/f/cases/13332 13336 FontChooser and FontInfrastructure do not have the 40 repository added to themselves. https://pharo.fogbugz.com/f/cases/13336 http://files.pharo.org/image/40/40023.zip

June 18, 2014

[pharo-project/pharo-core]

by GitHub

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

June 18, 2014

Re: [Pharo-dev] zip filesystem test cases?

by Max Leske

I have nothing. I checked my old images and there are no test cases for Zip-FileSystem that I could find. ++ for working on that! On 17.06.2014, at 23:51, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I am looking into how to fix the Zip FileSystem: > https://pharo.fogbugz.com/f/cases/12826/Zip-FileSystem-does-not-work > > Has any of you ever used it before? > > Also, Camillo mentioned that he saw some test cases, but I could not find any (I also checked in the repo of Lukas). Does any of you have some more information? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 18, 2014