January 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GT tool request

by Tudor Girba

It is indeed fixed in the GT repo. We still have to test a bit and we will announce when it's done. Doru On Tue, Jan 13, 2015 at 6:54 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 13 Jan 2015, at 17:43, stepharo <stepharo(a)free.fr> wrote: > > > > > >> > >> IMPOV, enter feels more easy to understand, while cmd+v feels the > oposite (because you are proposing a cmd+v without the previous cmd+c). > >> So, I still vote for enter :) > > > > + 1 > > Stef, be sure to read all mail, this was already fixed today: > > https://pharo.fogbugz.com/f/cases/14711 > > Sven > -- www.tudorgirba.com "Every thing has its own flow"

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by HernÃ¡n Morales Durand

2015-01-13 13:42 GMT-03:00 stepharo <stepharo(a)free.fr>: > You see if people using logging frameworks would have look for real at > Beacon or systemLogger and add one single appenders and publish the code > then we would have more of them. We will merge Beacon and SystemLogger > with Doru and Norbert and we will slowly add some backends. > Of course you can do whatever you want in Pharo, but people will still choose.

Jan. 13, 2015

Re: [Pharo-dev] The Smalltalk Renaissance Program

by Paul DeBruicker

Can't believe I forgot about this one: http://squeak.joyful.com/LanguageNotes I used to use it all the time when learning the basics horrido wrote > My Resources page is looking rather sparse. Doesn't anybody have any > favourite Smalltalk resources? Especially for "advanced" Smalltalkers. > horrido wrote >> Do a search for Smalltalk resources, such as books, videos, tutorials, >> blogs, etc., and you will face a virtual avalanche of material. This can >> be overwhelming for Smalltalk newcomers to filter. >> >> Submit your favourite Smalltalk resources and I shall curate them and >> choose the best ones to place on our Resources page: >> http://smalltalkrenaissance.wordpress.com/resources/ >> <http://smalltalkrenaissance.wordpress.com/resources/> >> >> Thanks. -- View this message in context: http://forum.world.st/The-Smalltalk-Renaissance-Program-tp4797112p4799381.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 13, 2015

Re: [Pharo-dev] GT tool request

by Sven Van Caekenberghe

> On 13 Jan 2015, at 17:43, stepharo <stepharo(a)free.fr> wrote: > > >> >> IMPOV, enter feels more easy to understand, while cmd+v feels the oposite (because you are proposing a cmd+v without the previous cmd+c). >> So, I still vote for enter :) > > + 1 Stef, be sure to read all mail, this was already fixed today: https://pharo.fogbugz.com/f/cases/14711 Sven

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by HernÃ¡n Morales Durand

2015-01-13 10:00 GMT-03:00 Atlas <erde(a)chello.at>: > It's all a matter of viewpoint, that's why we should include as many of > them > possible :) > > But, even though the answer was not directed as me, I'd like to step in: > > > Log4J does a good job of what I would consider the laymen spirit of > > logging production > he default event logging done captures the specific > > of class, line number, timestamp, method et als. > > A dog's breakfast actually. > > Strings lack self-description and this causes many unnecessary > architectural > problems. > > As Doru already pointed out, you have to write parsers and analysers to > interpret the output. And since might be many different formats for the > same > thing (dialects), you lose uniformity and have to handle all corner cases. > That depends in what you want to interpret. A log entry format is something you invent for your system. For log analysis you don't usually write a parser, you can just grep over the output to see why things didn't worked. Or you may use one of the tools for output analysis. > Worse yet, there is the implicit assumption that the software (or human) > inspecting the log has to understand all formats, i.e. has to have > knowledge > about: > What the names of the classes and methods mean, which subsystems (MQ, > databases) are in use and how their communication protocols look like etc. > And that does not factor in possible format changes or versions of > subsystems. > > It's hard to write generic browsers and analysers (the automated tooling > Doru pointed out) that way. > Also, there is the problem of reusing these parsers and analyers and code > duplication, maintenance issues etc. > > You don't *have to* write tools and parsers to do log analysis. > With that said, ultimately, it depends on the use cases.* For a fixed set * > of inspection use cases, this logging strategy might work fine. But it > certainly lacks the real flexibility to make a system more accessible and > to > adopt the generated information to the person and it's needs and > viewpoints. > You cannot address that easily with Log4j (or any logging facility for that > matter). As for Log4j and its 7 levels of logging: Why not 8, 9 or a 100? > What does INFO really mean? To whom? It all depends on the context. > > Exactly, you define the meaning of INFO for your system. There should not be just one conception of INFO.

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Sven Van Caekenberghe

> On 13 Jan 2015, at 18:27, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > > > 2015-01-13 5:17 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 13 Jan 2015, at 07:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > > > > First of all, I am not the developer of Log4s, but I have been using it for a while and I see no significant gain switching to SystemLogger or ZnLogEvent. As Alain said, it is based in Log4j, which has his own Wikipedia page: http://en.wikipedia.org/wiki/Log4j > > > > I don't think there is too much sense in having "Log Objects" around, where probably I want to tail a daily rolled log from a headless remote image. I read the documentation of SystemLogger hoping to find a mechansim which dynamically selects compression strategies based in what's logged, or some other advanced feature, but I didn't found any :( > > Maybe we should do away with Events as objects, Methods as objects, Exceptions as objects, Announcements as objects, Ring, MC, Commands as objects, Windows, Menus, ... - well, this whole objects everywhere thing is silly, let's use strings instead ;-) > > > Sarcasm is never the answer. Let's focus on logging, and specifically the case with remote image where you don't have access to "local log objects". I suppose there are other (specially web) developers with the same requirement. The analogy was to make a point, but you don't seem to see it, too bad. It is technically easy to export log objects out of an image. > We'll keep on trying to explain and to explore the possibilities. > > Log objects are much more powerful, less expensive than you think, and backwards compatible with textual output. > > > If I have to use a bayesian model with markov chains, which could take up to 1 million of samplings only to begin stabilization, and I want to log them... do you expect to have every entry as a Log object... right? That would be less expensive in terms of memory and speed than flushing to a text file? That would only be true if you kept them all in memory. That is an orthogonal point. <sorry-for-the-sarcasm>A String instance is an object too, composing/formatting a log message is a computation too, similar to serialising an object in some format.</sorry-for-the-sarcasm> > Logging is deceptively simple, managing megabytes of log files is a PITA. Structure, classification, intelligence, behaviour are the answers. > > BTW, it is not that you are not allowed to log some simple things to the Transcript, it is that it does not really scale, conceptually. > > > In my system I am not logging to the Transcript (which obviously does not scale). I was using the Transcript as an example of a text based logging facility. I meant that it doesn't scale conceptually, it becomes one big mess of dozens of log files that helps very little. Look, you don't have to use any form of Object Logging if you fail to see the point, there is nothing wrong with logging to a file. I was just trying to explain. We have dozens of servers producing many, many log files, most of them produced by log4j, writing more than 1Gb a day. 90% of that is a waste, but it is never enough. And it is a big mess. Even our Java developers say so. And what are they looking at ? Right, storing JSON log objects in searchable databases. (LogStash, ElasticSearch, blabla, ..). Sven > Cheers, > > HernÃ¡n >

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by HernÃ¡n Morales Durand

2015-01-13 5:17 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > On 13 Jan 2015, at 07:00, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > > > > First of all, I am not the developer of Log4s, but I have been using it > for a while and I see no significant gain switching to SystemLogger or > ZnLogEvent. As Alain said, it is based in Log4j, which has his own > Wikipedia page: http://en.wikipedia.org/wiki/Log4j > > > > I don't think there is too much sense in having "Log Objects" around, > where probably I want to tail a daily rolled log from a headless remote > image. I read the documentation of SystemLogger hoping to find a mechansim > which dynamically selects compression strategies based in what's logged, or > some other advanced feature, but I didn't found any :( > > Maybe we should do away with Events as objects, Methods as objects, > Exceptions as objects, Announcements as objects, Ring, MC, Commands as > objects, Windows, Menus, ... - well, this whole objects everywhere thing is > silly, let's use strings instead ;-) > > Sarcasm is never the answer. Let's focus on logging, and specifically the case with remote image where you don't have access to "local log objects". I suppose there are other (specially web) developers with the same requirement. > We'll keep on trying to explain and to explore the possibilities. > > Log objects are much more powerful, less expensive than you think, and > backwards compatible with textual output. > > If I have to use a bayesian model with markov chains, which could take up to 1 million of samplings only to begin stabilization, and I want to log them... do you expect to have every entry as a Log object... right? That would be less expensive in terms of memory and speed than flushing to a text file? > Logging is deceptively simple, managing megabytes of log files is a PITA. > Structure, classification, intelligence, behaviour are the answers. > > BTW, it is not that you are not allowed to log some simple things to the > Transcript, it is that it does not really scale, conceptually. > > In my system I am not logging to the Transcript (which obviously does not scale). Cheers, HernÃ¡n

Jan. 13, 2015

Re: [Pharo-dev] What Logging framework for Pharo

by Norbert Hartl

> Am 13.01.2015 um 13:18 schrieb stepharo <stepharo(a)free.fr>: > > Norbert > > we could read beacon and give a try. > Ok, that would be nice! Norbert

Jan. 13, 2015

Re: [Pharo-dev] GTInspector does not refresh printString

by Eliot Miranda

On Jan 13, 2015, at 4:26 AM, stepharo <stepharo(a)free.fr> wrote: >> >>> >>> I was doing a lecture and this is really sad to get all features gone. >> >> I think this is not so fair :). > > indeed but reopening an inspector is a pain. Refresh buttons are useful for this and testing the inspector itself no? > >> >>> So I had to reinspect again. >> >> Yes. As Andrei said, it is a bug that will be fixed. >> >>> In addition GTInspector bubble is a pain because sometimes you really want to keep the result and not inpect it. >>> Did you see my request to get that enter put the bubble contents into the text pane? >> >> Did you see the reply? :) > > No where it is? >> >>> I'm sorry but I cannot use GT as it is now. >> >> That's a pity. > > but this is a reality. >> >> >>> And I'm working on the new version of Pharo by example and it would be good to >>> have something full working. >> >> Besides these two problems, do you have others? > > I got confused with the inspector of arrays because we have to click on an extra pane to see them if I recall. > It was so painfull with all the other problems that I stop to use GT to avoid a huge frustration and get my job done. >> >> >> Cheers, >> Doru >> >> >> >>> Stef >>> >>>> >>>> Cheers, >>>> Andrei >>>> >>>> On Mon, Jan 12, 2015 at 12:14 PM, stepharo <stepharo(a)free.fr> wrote: >>>>> Hi >>>>> >>>>> GTInspector does not change the printString representation when we change the printOn:. >>>>> Am I the only one to see this behavior? >>>>> >>>>> Stef >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >

Jan. 13, 2015

Re: [Pharo-dev] [Pharo4] Slots can now be saved with MC

by Eliot Miranda

Hi Stef On Jan 13, 2015, at 4:23 AM, stepharo <stepharo(a)free.fr> wrote: > >> >> I hope we'll also be able to follow a 5th direction, of allowing one to specify a slice or a trait or a package that just adds an inst var to a class instead of having to provide the whole class definition just to add an inst var. > > We would love. > With Epicea we have Changes representing not only class and instance addition/removal... > Now the question is also how do we initialize such new added instance variable. That's easy if the slot definition has an initialiser. > Now we have probably to recompile the full class hierarchy. I don't see a way if avoiding this unless we move to a self/newspeak model of inst var accessor. But it can be made much faster than recompiling from source. The idea is simply to disassemble every method from bytecode to an assembler level representation (such as Marcus' byte surgeon or my method massage), adjust offsets and regenerate. This is what VisualWorks does and it is /much/ faster than recompiling from source. > We are brainstorming on a modular way to initialize objects > What are the paths to achieve that in a clever way. Yes the monolithic initialize method is an issue if one wants to be able to add inst vars individually. Lazy initialize toon in accessors is one way. That works well for eg inst vars used to implement caches (although now flushing becomes an issue). There's no such thing as a free lunch :-)

Jan. 13, 2015