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

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Norbert Hartl

Denis, > Am 18.04.2016 um 18:28 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: > > Hello. > > Year ago Beacon and SystemLogger were announced. There was big discussion about them. And there were plans to provide single solution. What was done around that? > we had some talks but nothing happened afterwards. The whole discussion went somehow off track. The good part is that we had a conclusion that we want to log objects instead of strings. The bad part is that we forget to talk about the "logging" part of it. And the discussion and actions are not a good example for collaboration rather the opposite. The SystemLogger started as a project to build a small core about what is usually done in logging frameworks. Usually log messages are strings with a severity level like error, warn, etc attached. The log messages are dispatched to a central location. At that location there is a bunch of log message consumers that filter by severity level or other criteria. This filtering consumers are attached to sinks that store the messages in some format somewhere. The sinks implement formatting and adaptation to storage like files, syslog, database,â¦ We want to do better and we care about objects instead of strings. In case of writing to a file it will be a string anyway. So we can see that "logging objects" means that the distribution of a log through the system should happen as objects with rich interfaces. And it means that the conversion to a string should happen (if needed at all) at the latest possible moment. So in my opinion the logging framework should support: - having an easy way to emit any kind of log object. The most basic thing a log entity should have is a timestamp. Around it there could be some common use cases but most of it is application specific. - multiple log consumers - filtering of log entities. IMO this includes filtering of objects you log to store. In a typical scenario where you would have a severity level you only want to log certain messages. This can also include filtering for special types of objects. That would mean you filter the kind of objects the consumer can understand - storage facilities. It is quite important to support files storage in many flavors, logging to syslog, logging to database etc. Without that you are just logging in memory and I'm not sure if a lot of people would agree that this is what is meant by using the word logging As an example I can put one of my projects where I use SystemLogger. When sending a push notification I log/emit an object/event of type COMessageSent with sublcasses for apple, google, etc. It is emitted to a central location. In SystemLogger there a three loggers configured. One is in memory and counts the number of events per class. One takes the object, converts it into a short string representation like "apple push sent to XXXX" and sends it via syslog/UDP to a central logging server. Finally the third one takes the object, converts it to json and stores the json in a elasticsearch database. The database allows me to do all sorts of statistical analysis of the data over a long time frame such as number of push messages per month for one year. Which looks like this So if you take my point of view then Beacon is pretty useless. SystemLogger and Beacon both use a singleton to dispatch log entities. In SystemLogger has own implementation of registry for that loggers. Beacon uses Announcements for it. That's basically the difference. I like the idea of using Announcements and not invent yet another distribution mechanism. But with Announcements you can only filter by class and not by instance. So it cannot do what system logger can do. Doru writes that he is working on that and it would be great. Although I have doubt this can be done performant I would be lucky to have it. On the other hand Beacon implements a handful of classes for some use cases but nothing more. So I see Svens point that you don't need it really because Announcements are there anyway and most of the stuff is application specific so I can just do that without having to integrate a "framework". > What exactly should be merged between this libraries? Was Beacon or SystemLogger planned to be end solution? > I'm not sure anymore. I can see some good things in Beacon that enable to register a logger for part of the execution. The drawback is that if you think about output facilities like log files there is no central place to attach it. And I surely don't want to have log configurations in the middle of my code. Beacon is not well thought in that direction, yet. IMHO I'd like to have a SystemLogger with the distribution of objects like it is done in Beacon. Filtering is to be solved. This is hard to do with Announcements and to be honest I don't really like it how it is done in SystemLogger. > We definitely need legacy logging tool for Pharo. And I am going to work on this direction. > Personally I prefer metaphor and names from Beacon. But both libraries implement similar idea. > Agreed. As I said above. If you take to point of view from legacy logging tool Beacon is not a big help. But the ideas in it are good and should be integrated somewhere. If you are talking about legacy tooling it might ok to use the terms logging as well, no? I personally like the work Beacon but in my opinion it is wrong for this purpose. A beacon sends a uniform signal in order to be discovered. The Beacon code sends signals to a beacon. And I can register at the beacon in which signals I'm interested in. Feels wrong to me. Norbert

April 20, 2016

Re: [Pharo-dev] [Ann] New version of Mocketry 3.0

by Denis Kudriashov

2016-04-20 2:27 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > Tudor Girba-2 wrote > > It is your prerogative :), but âshould got" sounds broken :(. > > Sounds like fingernails on a chalkboard IMH-native-english-speaker-O ;) > Ok. I open new thread about names

April 20, 2016

Mocketry names again

by Denis Kudriashov

Hi. People start argue that my choice of names are not good. For now Mocketry use "should got" to verify that following message was occurred: mock *should got* someMessage This is broken for native english speakers. Do you agree to replace it with correct #haveReceived? Can we use more short version #haveGot? mock should haveReceived someMessage mock should haveGot someMessage Also there is new expression to verify how object was received during test: result should *beReturnedFrom:* [mock someMessage] Should it be #haveReturnedFrom: ? result should haveReturnedFrom: [mock someMessage] I hope we can make consensus and be happy with Mocketry. Best regards, Denis

April 20, 2016

[Pharo5] Status: 23 open issues

by marcus.denker＠inria.fr

Hi, There are now 23 open issues tagged for Milestone âPharo5â. https://pharo.fogbugz.com/f/filters/125/5-0-All The plan is to release in 2 weeks. Please check if - all these issues are real show-stoppers. The idea is that e.g. everything that was already a problem in Pharo4 can not be a showstopper, as we did release Pharo4â¦ - Did you report an issue that is not listed here? New issues are do now pre-fill the form with âPharo6â, but then, if an issue was reported e.g. last week and nobody realised it was in the wrong milestone, I guess it can be said that this issue by default is not a show-stopperâ¦ - If you have this âobviousâ bug that is so obvious that you did not even report it: Keep in mind that it will *not* be fixed as we do not know about it. It does not exist. Marcus

April 20, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Henrik Johansen

> On 20 Apr 2016, at 9:54 , Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > >> On Apr 20, 2016, at 9:37 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: >> >> >>> On 19 Apr 2016, at 3:34 , Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> In the process I also added the possibility to remove Announcements from an AnnouncementSet and I would like to push this in Pharo 6.0. One thing I would work on is to add to Annoucements the possibility of filtering announcements based on instances not just types. This is a longer term plan. >> AnnouncementSet is just a normal set, so it has always been possible to remove items, just not recommended. >> Filtering on instances is in the same category of making actual delivery after subscription more dynamic; both also have the effect that it becomes even harder to reason about what is going to happen as a result of an Announcement without actually running the code. > > The fact that AnnouncementSet is a Set is actually debatable because it basically reuses the implementation, not the type. I agree, it would be better if AnnouncementSet didn't inherit the full Set API. > Indeed, Set does allow for removing items, but I was referring to excluding items which is a slightly different use case (like is the case for Exceptions). Ah, exclusions are a different matter from removal, that sounds like a good change indeed! My point was, messing with the subscription to alter what is being delivered outside of registration/de-registration, would lead to hard(er)-to-understand code; that's would not be the case for exclusions like: announcer when: SuperAnnouncement - SpecificAnnouncementImNotInterestedIn do: [:ann | ... ] Cheers, Henry

April 20, 2016

Re: [Pharo-dev] unzip:to:

by Damien Cassou

Valentin Ryckewaert <valentin.ryckewaert(a)gmail.com> writes: > Hello, > > I understood the problem with pathString and I'm ok with your opinion but I > would like to come back on the first one "fullfilename" as I understand it, > it must be a basename ? > When I read the implementation with fullfilename which would be a path > '/aPath/foo.zip'. > > newName := fullFileName copyUpToLast: FileSystem disk extensionDelimiter. > newName would be in that case : /aPath/foo' > > unzipped := FileStream newFileNamed: (pathString asFileReference / newName) > fullName. > Here the newFileNamed: parameter will be '/aPathDestination/aPath/foo' so > it could be something like '/home/home/foo' it's not correct according to > me. > > As I understand it, this message only works if fullFileName is 'foo.zip' > and is in the folder which contain Pharo image as we can't specify a path. I agree with Valentin. I have the impression this method can only unzip files in the working directory. That's a bit strange :-). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

April 20, 2016

Re: [Pharo-dev] unzip:to:

by Valentin Ryckewaert

Hello, I understood the problem with pathString and I'm ok with your opinion but I would like to come back on the first one "fullfilename" as I understand it, it must be a basename ? When I read the implementation with fullfilename which would be a path '/aPath/foo.zip'. newName := fullFileName copyUpToLast: FileSystem disk extensionDelimiter. newName would be in that case : /aPath/foo' unzipped := FileStream newFileNamed: (pathString asFileReference / newName) fullName. Here the newFileNamed: parameter will be '/aPathDestination/aPath/foo' so it could be something like '/home/home/foo' it's not correct according to me. As I understand it, this message only works if fullFileName is 'foo.zip' and is in the folder which contain Pharo image as we can't specify a path. Valentin 2016-04-19 20:40 GMT+02:00 stepharo <stepharo(a)free.fr>: > > > Le 19/4/16 15:53, Valentin Ryckewaert a Ã©crit : > > I mean, fileRef basename is myZip.zip and workingDirectory is the place > files will go after being unziped but how does we find the file named > fileRef basename ? > > > > 'foo.txt' asFileReference -> a fileRef > > 'foo.txt' asFileReference basename. > > (FileSystem disk workingDirectory / 'foo.txt') basename > > this is explained in the File chapter. > > > Can you open a bug entry to improve the comment of the method? > > > 2016-04-19 15:46 GMT+02:00 stepharo <stepharo(a)free.fr>: > >> >> >> Le 19/4/16 15:41, Valentin Ryckewaert a Ã©crit : >> >> How does unzip:to: access to the file ? >> >> I do not get your question? >> >> It must be in the workingDirectory? >> >> >> Read the code luke.... >> >> >> unzip: fullFileName to: pathString >> "Unzip the contents of the file specified by the full path name >> fullFileName to the location given by pathString." >> >> | zipped buffer unzipped newName | >> newName := fullFileName copyUpToLast: FileSystem disk >> extensionDelimiter. >> pathString asFileReference ensureCreateDirectory. >> unzipped := FileStream newFileNamed: (pathString asFileReference / >> newName) fullName. >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> >> >> >> unzipped ifNil: [self error: pathString, ' looks incorrect']. >> [ unzipped binary. >> zipped := self on: (FileStream readOnlyFileNamed: fullFileName). >> buffer := ByteArray new: 50000. >> [zipped atEnd] whileFalse: [unzipped nextPutAll: (zipped nextInto: >> buffer)]] >> ensure: [ >> zipped close. >> unzipped close]. >> ^ newName >> >> >> >> >> >> 2016-04-19 15:06 GMT+02:00 HernÃ¡n Morales Durand < >> hernan.morales(a)gmail.com>: >> >>> I use it a lot to uncompress external resources like this: >>> >>> fileRef := .... >>> GZipReadStream unzip: fileRef basename to: FileSystem workingDirectory. >>> >>> but it could be used to pass a directory as String I guess. >>> Comment should be corrected. >>> >>> >>> 2016-04-19 9:54 GMT-03:00 stepharo < <stepharo(a)free.fr>stepharo(a)free.fr> >>> : >>> >>>> unzip: fullFileName to: pathString >>>> "Unzip the contents of the file specified by the full path name >>>> fullFileName to the location given by pathString." >>>> >>>> so we would expect to pass a string in the second argument? >>>> >>>> the unique sender of it in the system >>>> >>>> unzip: fullFileName >>>> "Unzip the contents of a gzipped file specified by its full file >>>> name to the current working directory" >>>> >>>> ^ self unzip: fullFileName to: FileSystem disk workingDirectory >>>> >>>> >>>> but the implementation seems to indicate that fullFileName is should be >>>> a string as well as pathString >>>> >>>> unzip: fullFileName to: pathString >>>> "Unzip the contents of the file specified by the full path name >>>> fullFileName to the location given by pathString." >>>> >>>> | zipped buffer unzipped newName | >>>> newName := fullFileName copyUpToLast: FileSystem disk >>>> extensionDelimiter. >>>> pathString asFileReference ensureCreateDirectory. >>>> unzipped := FileStream newFileNamed: (pathString asFileReference / >>>> newName) fullName. >>>> unzipped ifNil: [self error: pathString, ' looks incorrect']. >>>> [ unzipped binary. >>>> zipped := self on: (FileStream readOnlyFileNamed: fullFileName). >>>> buffer := ByteArray new: 50000. >>>> [zipped atEnd] whileFalse: [unzipped nextPutAll: (zipped nextInto: >>>> buffer)]] >>>> ensure: [ >>>> zipped close. >>>> unzipped close]. >>>> ^ newName >>>> >>>> Am I correct to think that the comments are not really good enough? >>>> >>>> Stef >>>> >>>> >>>> >>>> >>> >> >> > >

April 20, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Tudor Girba

Hi, > On Apr 20, 2016, at 9:37 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 19 Apr 2016, at 3:34 , Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> In the process I also added the possibility to remove Announcements from an AnnouncementSet and I would like to push this in Pharo 6.0. One thing I would work on is to add to Annoucements the possibility of filtering announcements based on instances not just types. This is a longer term plan. > AnnouncementSet is just a normal set, so it has always been possible to remove items, just not recommended. > Filtering on instances is in the same category of making actual delivery after subscription more dynamic; both also have the effect that it becomes even harder to reason about what is going to happen as a result of an Announcement without actually running the code. The fact that AnnouncementSet is a Set is actually debatable because it basically reuses the implementation, not the type. Indeed, Set does allow for removing items, but I was referring to excluding items which is a slightly different use case (like is the case for Exceptions). > IMHO, if the logic is "I want to handle this announcement some of the time", that is much easier to understand if handled explicitly in announcement handling code, rather than through state changes to the announcement delivery. I disagree. I have a project which has about 50 different signals, and I am interested in all but one. Listing all 49 would be impractical and not particularly clear. Furthermore, when you have inheritance, it becomes even more complicated. You have the same case with exceptions and there we allow exclusions for good reasons. > As I think Glamour is a poster child for, current usage patterns can already be hard to follow ;) I do not understand this statement in the context of this email. Cheers, Doru > Cheers, > Henry -- www.tudorgirba.com www.feenk.com "Reasonable is what we are accustomed with."

April 20, 2016

Re: [Pharo-dev] About CommentPane

by lb

Hi, Serge, Nice to meet you. Welcome to China again, I live in shanghai. pudong new area. Best Regards! Bing Liang

April 20, 2016

Re: [Pharo-dev] What the state of unifying Beacon with SystemLogger?

by Henrik Johansen

> On 19 Apr 2016, at 3:34 , Tudor Girba <tudor(a)tudorgirba.com> wrote: > > In the process I also added the possibility to remove Announcements from an AnnouncementSet and I would like to push this in Pharo 6.0. One thing I would work on is to add to Annoucements the possibility of filtering announcements based on instances not just types. This is a longer term plan. AnnouncementSet is just a normal set, so it has always been possible to remove items, just not recommended. Filtering on instances is in the same category of making actual delivery after subscription more dynamic; both also have the effect that it becomes even harder to reason about what is going to happen as a result of an Announcement without actually running the code. IMHO, if the logic is "I want to handle this announcement some of the time", that is much easier to understand if handled explicitly in announcement handling code, rather than through state changes to the announcement delivery. As I think Glamour is a poster child for, current usage patterns can already be hard to follow ;) Cheers, Henry

April 20, 2016