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

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 23.02.2014 um 08:10 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > From my point of view, the problem comes from the following forces: > - the class side wants to be a log > - the instance side wants to be a log entry > > The better solution here would be to have two classes: Log and LogEntry. This is particularly important in the light of extensibility when people will want to define their own log entries. > Iâm not sure what you consider a âlogâ. To me that are all log entries (I like log events even more) and they are named log for simplicity. The âlogâ is more tied to the logger being file logger, database logger and so on. Maybe there are some words we need to straighten out first. Norbert > > > > On Sun, Feb 23, 2014 at 1:48 AM, <btc(a)openinworld.com> wrote: > Tudor Girba wrote: >> >> Excellent, Stef! >> >> I reviewed a bit the code: >> - The name log denotes the recording of multiple events. However, the Log class models only one event, not many. Thus, a more suitable name would be LogEvent. Or maybe LogEntry (like in StarTrek :)) > Except Log as only accessed as a class, not as instances. In days of old, sailing ships had a single Log book kept in the captain's room. Also Transcript is not called TranscriptEvent. So for me the semantics of Log are fine. > cheers -ben > > >> - Similarly, SystemLogger>>logs should be something like logEvents/logEvents. >> >> I like it a log that LogEvents are full objects because we can subclass them with specific semantics. This is particularly important if we want to build tools for custom applications. The first application I have in mind is Zinc. >> >> Zinc already comes with a logging mechanism that treats LogEvents as objects, but they are all of the same type, so in the end, if you want to track the events for request/response you have to reverse engineer the text. These semantics could be preserved. >> >> From what I see, the main difference between the Zinc log system and the SystemLogger is that the latter has a dispatcher that can dispatch to multiple loggers. Is there anything else that is different? I think it would be cool to merge the two. >> >> Doru >> >> >> 2014-02-22 13:24 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 22.02.2014 um 20:27 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: > Super man! > > Let's just merge all the "nice stuff" from the others. My SimpleLog is definitely not something I want to maintain if there is a better one that does the same and more. > > We have to learn merging projects ;) > +1 Norbert

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 22.02.2014 um 18:49 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Excellent, Stef! > > I reviewed a bit the code: > - The name log denotes the recording of multiple events. However, the Log class models only one event, not many. Thus, a more suitable name would be LogEvent. Or maybe LogEntry (like in StarTrek :)) I had the same objections. But I can also see the huge win of the short name because it is used all the time. Norbert > - Similarly, System > Logger>>logs should be something like logEvents/logEvents. > > I like it a log that LogEvents are full objects because we can subclass them with specific semantics. This is particularly important if we want to build tools for custom applications. The first application I have in mind is Zinc. > > Zinc already comes with a logging mechanism that treats LogEvents as objects, but they are all of the same type, so in the end, if you want to track the events for request/response you have to reverse engineer the text. These semantics could be preserved. > > From what I see, the main difference between the Zinc log system and the SystemLogger is that the latter has a dispatcher that can dispatch to multiple loggers. Is there anything else that is different? I think it would be cool to merge the two. > > Doru > > > 2014-02-22 13:24 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Norbert Hartl

Am 22.02.2014 um 18:12 schrieb GÃ¶ran Krampe <goran(a)krampe.se>: > Hi! > > On 02/22/2014 05:26 PM, Pharo4Stef wrote: >> Hi goran >> >> There are only two questions: >> 'Why when I load code do I have to open the transcript before to see the shadow and undeclared. >> and why I cannot click on an object and jump to the broken code?" >> >> Now with SimpleLogger I imagine that I cannot log compiler shadow, donât you :). > > I am not quite sure what you are saying... Ah, you mean logging objects instead of strings? Sure, I didn't say SimpleLog was BETTER, I just said you didn't look at it and thus may be missing out on nice stuff that you can steal :) > Sure, seems so nobody knew about it then :) > - Using syslog levels, it is very standard and logging these days of clouds do NOT stay on the local machine. > - Stealing the syslog emitter, it is just 20 lines of code. That is a nice extension to SystemLogger. > - Stealing log file rotation perhaps? I think its in there. Are you are using this? I think it is not too common to do that in your application because there are tools like logrotate that do those things way better with compressing, deleting files, etc.. The only thing it needs is that the filestream sees when the file is gone and reopens. > - Stealing whatever else seems good. > > Having log objects in the image is great. > >> 100 timesRepeat: [Goran repeatAfter: me what: âString sucks, string are dead objectsâ] > > Well, do remember that logs in a "system world" end up getting routed through syslog (and tons of variations on that theme) and eventually end up in event collecting systems etc - just look at fluentd.org to understand what I mean. > > So actually, I would make sure that SimpleLogger could also easily log in JSON, let me quote from fluentd: > > "Fluentd treats logs as JSON, a popular machine-readable format. It is written primarily in C with a thin-Ruby wrapper that gives users flexibility. > > Fluentdâs performance has been proven in the field: its largest user currently collects logs from 5000+ servers, 5 TB of daily data, handling 50,000 msgs/sec at peak time.â This is also a nice extension to the SystemLogger. The goal of the framework is simplicity _and_ extendability so you can add your use case with ease. I personally decided against using fluentd because I try to avoid much of the system complexity if I donât need it (I have not even close to 50000 reqs/s). Putting the logs from within the image into syslog only to have it transported to fluentd wouldnât be a clever thing to do. First you squeeze your object into a string just to have the fluentd tool apply a filter to create a json object of it. So converting a log to JSON and put it directly into fluentd would be the way to go. This way you can have fluentd for the buffering and for the single point of configuration for the log sink. If you look at the FormattingLogger it does provide the hooks for this. There is a conversion and a storing method because these are two things you want to adjust if you need a different format like JSON and a different way of storing (sockets, http,â¦). I use the SystemLogger to put all the logs into elasticsearch directly. Norbert > >> Iâm coding in Smalltalk and not in perl! > > In fact, now that I am looking at SimpleLog I realize we could have had an emitter that collected objects and just let "message" be whatever - and send asString or asJSON to it when it reaches the emitter instead. > >> Now if you want to have syslog output this is probably one method definition in a new formatter in our nice frameworks. >> Do you have an output that shows what is needed for sysLog? because I can add a package for sysLog outputter. > > Its very short code. Just steal it. I attached all the code as an .st fileout so that you can get it trivially. Its the SLSyslogSender class. > > The SLLogWatchDog is a trivial "send an email if a certain level is reached" with some bundling etc. > > SLLogFile has log file rotation. > > SLLogMorph is the simple search and filter UI. > > regards, GÃ¶ran > > > <SimpleLog.st>

Feb. 23, 2014

R: Morphic UI designer

by Lorenzo Schiavina

Hi Steff, may I ask why Phobos is not considered as a good candidate as a basis for an interface designer? I have experience with PARTS (which is the best application in the field I have ever seen in ST environment) and I believe that it could be used as a basis for tools of this kind. If anyone is interested in PARTS (included in VSE ST) as a model, I will be pleased to send it. Lorenzo Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Pharo4Stef Inviato: sabato 22 febbraio 2014 17:19 A: Pharo Development List Oggetto: Re: [Pharo-dev] Morphic UI designer On 22 Feb 2014, at 15:24, jannik laval < <mailto:jannik.laval@gmail.com> jannik.laval(a)gmail.com> wrote: Does it make sense to add energy on it ? Probably, we should investigate UIPainter. may be the first thing to do would be to convert some of the widgets to work in Pharo with announcements. I did not have the time to verify but I did the following experience I built a simple naive browser using self changed:/updates then I wanted to rewrite it using Announcement only and it did not work probably because some of our widgets are not done to be used with announcements (probably they expect changedÂ.) so it may be the same with his widgets. Stef Jannik 2014-02-21 22:02 GMT+01:00 Stephan Eggermont < <mailto:stephan@stack.nl> stephan(a)stack.nl>: At the moment I'm moving, so I have very little time to do something about it. Current state is described in a thread from end of last year: <http://forum.world.st/have-a-question-for-morphic-Designer-in-pharo-td47313 07.html> http://forum.world.st/have-a-question-for-morphic-Designer-in-pharo-td473130 7.html Stephan -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur <http://www.jannik-laval.eu/> http://www.jannik-laval.eu <http://car.mines-douai.fr/> http://car.mines-douai.fr/

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by Tudor Girba

Hi, >From my point of view, the problem comes from the following forces: - the class side wants to be a log - the instance side wants to be a log entry The better solution here would be to have two classes: Log and LogEntry. This is particularly important in the light of extensibility when people will want to define their own log entries. Cheers, Doru On Sun, Feb 23, 2014 at 1:48 AM, <btc(a)openinworld.com> wrote: > Tudor Girba wrote: > > Excellent, Stef! > > I reviewed a bit the code: > - The name log denotes the recording of multiple events. However, the Log > class models only one event, not many. Thus, a more suitable name would be > LogEvent. Or maybe LogEntry (like in StarTrek :)) > > Except Log as only accessed as a class, not as instances. In days of old, > sailing ships had a single Log book kept in the captain's room. Also > Transcript is not called TranscriptEvent. So for me the semantics of Log > are fine. > cheers -ben > > > - Similarly, SystemLogger>>logs should be something like > logEvents/logEvents. > > I like it a log that LogEvents are full objects because we can subclass > them with specific semantics. This is particularly important if we want to > build tools for custom applications. The first application I have in mind > is Zinc. > > Zinc already comes with a logging mechanism that treats LogEvents as > objects, but they are all of the same type, so in the end, if you want to > track the events for request/response you have to reverse engineer the > text. These semantics could be preserved. > > From what I see, the main difference between the Zinc log system and the > SystemLogger is that the latter has a dispatcher that can dispatch to > multiple loggers. Is there anything else that is different? I think it > would be cool to merge the two. > > Doru > > > 2014-02-22 13:24 GMT+01:00 Pharo4Stef <pharo4Stef(a)free.fr>: > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 23, 2014

Re: [Pharo-dev] PharoChangesCondenser

by btc＠openinworld.com

Camillo Bruni wrote: > We need guinea-pigs for https://pharo.fogbugz.com/f/cases/12729/Smalltalk-condenseChanges-raises-Zn… > > I rewrote the changes condenser from scratch in a couple of methods: > - probably the same speed as before > - increased safety: source pointer switching only happens after ALL sources are exported > - massively reduced complexity by using real objects > I am game but I've not used condense changes before so I would need some script to follow. I see talk of automating condense changes as part of each system build. Does that mean for example that there would be a 30778.sources to go with each 30778.changes and 30778.image? cheers, Ben

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by btc＠openinworld.com

Feb. 23, 2014

Re: [Pharo-dev] SystemLogger unrevealed :)

by GÃ¶ran Krampe

On 02/22/2014 09:39 PM, Pharo4Stef wrote: > create an account on SmalltalkHub. I am already there since a long time: http://www.smalltalkhub.com/#!/~gokr regards, GÃ¶ran

Feb. 22, 2014

Re: [Pharo-dev] PharoChangesCondenser

by Pavel Krivanek

Great! Welcome back :-) -- Pavel 2014-02-22 20:14 GMT+01:00 Camillo Bruni <camillobruni(a)gmail.com>: > We need guinea-pigs for > https://pharo.fogbugz.com/f/cases/12729/Smalltalk-condenseChanges-raises-Zn… > > I rewrote the changes condenser from scratch in a couple of methods: > - probably the same speed as before > - increased safety: source pointer switching only happens after ALL > sources are exported > - massively reduced complexity by using real objects >

Feb. 22, 2014