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

Access to Pharo/TxText

by Bernardo Ezequiel Contreras

Hi, Could someone take a look at this https://pharo.fogbugz.com/f/cases/14632/Access-to-Pharo-TxText ? Thanks. -- Bernardo E.C. Sent from a cheap desktop computer in South America.

Jan. 14, 2015

Fixing DNU binding in GT and Nautilus

by stepharo

Hi in nautilus method pane and GT, when I select a global variable such as SystemOrganization and press command B + N I get DNU binding. Apparently this DNU only happen when the name does not match any class substring Transcript or Undeclared will not raise an error because we have classes having name matching the expression. Fixed included. PS: I'm dead after 1h30 train delay (after giving 6 hours lecture) today. So this mail will be sent whenever I get connected. Stef

Jan. 13, 2015

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

by Alain Rastoul

Le 13/01/2015 17:39, stepharo a Ã©crit : > Sorry to look harsh but you often kill my fun and energy with strange > expectations. > We have one and half full time engineer working for Pharo now. And we > are pretty successful. > Now imagine how pharo would look like if you would participate for real > each at its own degree Stef, I'm really sorry if my question and the answers, opinions and expectations of this thread made you feel bad. It was a not a strange expectation or a general discussion on logging at all, but a true question about existing logging facility in Pharo that I do not know, and the fact is there was Beacon, SystemLogger and ZnLogger, and albeit it may look depressing to you, this thread has some very interesting pointers to me. I think everybody's answer has some valid arguments from it's own point of view, none of them is really controversial, and the merging you talked about should settle everyone's expectations right. For me, I was looking for a logging tool for a project I (re)started some time ago and broke recently, trying to refactor it. More precisely I don't know why a client socket connection is closing, here I think Beacon will really help me on that, ZnLogger or SystemLogger could too. And even if the sl4s package looks good, it would help less for debugging (I 'm not saying it is not good), inspecting logged objects will be really a big plus. I 'll do some experiments with beacon and try to make something like "sensors" (signalers) plugged in the code (like sql server extended events framework plugged in sql server code) to replace a BlackBox I did in my system that is really weak. I would be very interested in following, participating or helping (docs, or whatever useful, eventually code or tests with my very limited skills and with some guidance) on this logging subject if needed, but I do not feel skilled enough on the Pharo part to solve most (if not any) fogbugz cases I saw, I would certainly only do a mess (I'm sure I'm not the only one in that case, the sep is very high between using and solving cases). So to me just using it for now is a good way to get deeper into it and probably one day be skilled enough to help ... :) And I'm very sorry too that I cannot go to Pharo day, I would have loved to see presentations , meet some people, talk about it (logging tools or whatever) but I definitely can't . too bad :( > > Stef > > -- Regards, Alain

Jan. 13, 2015

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

by Norbert Hartl

> Am 13.01.2015 um 21:46 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > > > 2015-01-13 17:08 GMT-03:00 Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>>: > >> Am 13.01.2015 um 19:41 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>>: >> >> >> >> 2015-01-13 14:50 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: >> >> > On 13 Jan 2015, at 18:27, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: >> > >> > >> > >> > 2015-01-13 5:17 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: >> > >> > > On 13 Jan 2015, at 07:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@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 <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. >> >> >> Instead of analogies, I would love to read about how your Log system proposals works with headless images. Because to me it is really easy to write a grep command (I don't have to *explore* logs). >> > It can work the way you want it to. The main difference might be that you don't produce strings inside your code when logging. You create objects with contextual information and you emit them. A convert/outputter/appender can then convert the objects into a desired format before it leaves the image. Or you can keep the objects in the image. The only difference might be that we keep objects as long as possible and postpone to convert it to less rich format as long as possible. But you don't need to produce special objects, you can just log strings as the most basic thing as well (because string is an object). > So it is up to you if you write those objects as strings to a file, if you generate a hierarchical format like json and transmit it via tcp or you keep the objects in the image having a http handler where you can specify a query for the objects and format to be returned. We just want it to be small and extensible. Using objects in the core is the best way to do it. Because then it is up to you if you want to log string messages or a whole stack. > > > Thanks for the clarification Norbert. > > Though it could seem I want to kill your efforts, I really want you succeed with your projects. Today, I see your logging objects as unnecessary entities for my requirements. Unfortunately it seems nobody had enough time to benchmark and compare loggers, if that's the case we wouldn't had this thread. > Maybe. I find it valuable to have those discussions. Performance is surely important for a logging framework but maybe not the ultimate goal. The lack of performance should be justified by flexibility, extensibility etc. We are still in the progress to make it useful for a lot of people. So if you don't like it I'm interested in the reasons because we still need to learn how to improve. > Is the sense that tools and projects should be promoted with more humility in this community. If people chose other tools doesn't mean they don't get it right nor they fail miserably. I don't think anyone was implying that. Norbert > > > Norbert > >> > 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. >> >> >> So you didn't answered my questions. Do I have to create 1 million of log objects and that is less expensive than flushing them as they occur into a file? >> What's the point of creating objects if I don't need them? >> >> >> <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> >> >> >> I see. In the end we (still) read Strings, whatever conceptualization is above them. >> >> > 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. >> >> The point is isn't just me. I haven't seen any intensive computation software which creates log objects for self-exploration. And if you find one, I could cite 100 of them which does "String logging", and they just work, and people using it is not stupid, they know they have limitations, it happens that they prioritize other requirements. >> >> >> 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, ..). >> >> >> It is weird to read sometimes how Java developers have it so wrong, and sometimes they are visionary souls which drive us into the future. >> >> HernÃ¡n

Jan. 13, 2015

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

by HernÃ¡n Morales Durand

2015-01-13 17:08 GMT-03:00 Norbert Hartl <norbert(a)hartl.name>: > > Am 13.01.2015 um 19:41 schrieb HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com>: > > > > 2015-01-13 14:50 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> > 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. >> >> > Instead of analogies, I would love to read about how your Log system > proposals works with headless images. Because to me it is really easy to > write a grep command (I don't have to *explore* logs). > > > It can work the way you want it to. The main difference might be that you > don't produce strings inside your code when logging. You create objects > with contextual information and you emit them. A convert/outputter/appender > can then convert the objects into a desired format before it leaves the > image. Or you can keep the objects in the image. The only difference might > be that we keep objects as long as possible and postpone to convert it to > less rich format as long as possible. But you don't need to produce special > objects, you can just log strings as the most basic thing as well (because > string is an object). > So it is up to you if you write those objects as strings to a file, if you > generate a hierarchical format like json and transmit it via tcp or you > keep the objects in the image having a http handler where you can specify a > query for the objects and format to be returned. We just want it to be > small and extensible. Using objects in the core is the best way to do it. > Because then it is up to you if you want to log string messages or a whole > stack. > Thanks for the clarification Norbert. Though it could seem I want to kill your efforts, I really want you succeed with your projects. Today, I see your logging objects as unnecessary entities for my requirements. Unfortunately it seems nobody had enough time to benchmark and compare loggers, if that's the case we wouldn't had this thread. Is the sense that tools and projects should be promoted with more humility in this community. If people chose other tools doesn't mean they don't get it right nor they fail miserably. HernÃ¡n > > Norbert > > > 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. >> >> > So you didn't answered my questions. Do I have to create 1 million of log > objects and that is less expensive than flushing them as they occur into a > file? > What's the point of creating objects if I don't need them? > > > >> <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> >> >> > I see. In the end we (still) read Strings, whatever conceptualization is > above them. > > >> > 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. >> > > The point is isn't just me. I haven't seen any intensive computation > software which creates log objects for self-exploration. And if you find > one, I could cite 100 of them which does "String logging", and they just > work, and people using it is not stupid, they know they have limitations, > it happens that they prioritize other requirements. > > >> >> 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, ..). >> >> > It is weird to read sometimes how Java developers have it so wrong, and > sometimes they are visionary souls which drive us into the future. > > HernÃ¡n > > > >

Jan. 13, 2015

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

by HernÃ¡n Morales Durand

2015-01-13 16:25 GMT-03:00 Atlas <erde(a)chello.at>: > hernanmd wrote > > 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. > > Provided that the parts of the system *I* am interested in have been > enriched with logging code. And provided the log messages are informative > -- > and that's a highly subjective matter. > Also, different users and developers might have different opinions as to > which parts of the system to instrument. > (Of course, I could use an aspect weaver to do instrumentation, but that's > a > rather indirect way to address the problem) > > > hernanmd wrote > > Exactly, you define the meaning of INFO for your system. There should not > > be just one conception of INFO. > > I might define what INFO means for my system from *my *point of view, but > there might be many other different viewpoints. How can these be > incorporated, if the decisions what and how to log and how are determined > by > someone else? > > But that's what developement cycles and peer-review suppose to provide, a feedback system where you reach consensus through subjective modeling. > > hernanmd wrote > > The point is isn't just me. I haven't seen any intensive computation > > software which creates log objects for self-exploration. And if you find > > one, I could cite 100 of them which does "String logging", and they just > > work, and people using it is not stupid, they know they have limitations, > > it happens that they prioritize other requirements. > > They should prioritize other requirements, yes. There should be no need to > write (much) logging code. Agree > In an object-oriented system, I am interested > about the information flow / messages between objects. While you may log objects information flows, I have seen people often use specialized tracers and samplers. > With hierarchical > decomposition, I can zoom in and out, see the messages and their effects, > which in my opinion, is a more holistic perspective on system analysis. > Agree, but maybe that's a requirement for software re-engineering or code analysis which doesn't apply to whole domains of applications. > With grep, I would have to reconstruct this information (caller graph, > state > changes etc.) from the logs or use a tool which only works if the log > messages follow a specific format (and these formats might change). > > Of course, I am not saying that string messages are useless and cannot be > informative, but they cover only one aspect of the problem. > > > hernanmd wrote > > I see. In the end we (still) read Strings, whatever conceptualization is > > above them. > > This rests on the assumption that the string and/or strings from related > log > messages carry enough information (and additional context) to infer the > concepts. > > > Sure, why one shouldn't include all the necessary information? Unless you're instrumenting legacy system or auditing... Cheers, HernÃ¡n

Jan. 13, 2015

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

by Norbert Hartl

> Am 13.01.2015 um 19:41 schrieb HernÃ¡n Morales Durand <hernan.morales(a)gmail.com>: > > > > 2015-01-13 14:50 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > > > On 13 Jan 2015, at 18:27, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>> wrote: > > > > > > > > 2015-01-13 5:17 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>>: > > > > > On 13 Jan 2015, at 07:00, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com <mailto:hernan.morales@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 <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. > > > Instead of analogies, I would love to read about how your Log system proposals works with headless images. Because to me it is really easy to write a grep command (I don't have to *explore* logs). > It can work the way you want it to. The main difference might be that you don't produce strings inside your code when logging. You create objects with contextual information and you emit them. A convert/outputter/appender can then convert the objects into a desired format before it leaves the image. Or you can keep the objects in the image. The only difference might be that we keep objects as long as possible and postpone to convert it to less rich format as long as possible. But you don't need to produce special objects, you can just log strings as the most basic thing as well (because string is an object). So it is up to you if you write those objects as strings to a file, if you generate a hierarchical format like json and transmit it via tcp or you keep the objects in the image having a http handler where you can specify a query for the objects and format to be returned. We just want it to be small and extensible. Using objects in the core is the best way to do it. Because then it is up to you if you want to log string messages or a whole stack. Norbert > > 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. > > > So you didn't answered my questions. Do I have to create 1 million of log objects and that is less expensive than flushing them as they occur into a file? > What's the point of creating objects if I don't need them? > > > <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> > > > I see. In the end we (still) read Strings, whatever conceptualization is above them. > > > 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. > > The point is isn't just me. I haven't seen any intensive computation software which creates log objects for self-exploration. And if you find one, I could cite 100 of them which does "String logging", and they just work, and people using it is not stupid, they know they have limitations, it happens that they prioritize other requirements. > > > 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, ..). > > > It is weird to read sometimes how Java developers have it so wrong, and sometimes they are visionary souls which drive us into the future. > > HernÃ¡n > >

Jan. 13, 2015

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

by Atlas

hernanmd wrote > 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. Provided that the parts of the system *I* am interested in have been enriched with logging code. And provided the log messages are informative -- and that's a highly subjective matter. Also, different users and developers might have different opinions as to which parts of the system to instrument. (Of course, I could use an aspect weaver to do instrumentation, but that's a rather indirect way to address the problem) hernanmd wrote > Exactly, you define the meaning of INFO for your system. There should not > be just one conception of INFO. I might define what INFO means for my system from *my *point of view, but there might be many other different viewpoints. How can these be incorporated, if the decisions what and how to log and how are determined by someone else? hernanmd wrote > The point is isn't just me. I haven't seen any intensive computation > software which creates log objects for self-exploration. And if you find > one, I could cite 100 of them which does "String logging", and they just > work, and people using it is not stupid, they know they have limitations, > it happens that they prioritize other requirements. They should prioritize other requirements, yes. There should be no need to write (much) logging code. In an object-oriented system, I am interested about the information flow / messages between objects. With hierarchical decomposition, I can zoom in and out, see the messages and their effects, which in my opinion, is a more holistic perspective on system analysis. With grep, I would have to reconstruct this information (caller graph, state changes etc.) from the logs or use a tool which only works if the log messages follow a specific format (and these formats might change). Of course, I am not saying that string messages are useless and cannot be informative, but they cover only one aspect of the problem. hernanmd wrote > I see. In the end we (still) read Strings, whatever conceptualization is > above them. This rests on the assumption that the string and/or strings from related log messages carry enough information (and additional context) to infer the concepts. -- View this message in context: http://forum.world.st/What-Logging-framework-for-Pharo-tp4799073p4799398.ht… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Jan. 13, 2015

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

by HernÃ¡n Morales Durand

2015-01-13 14:50 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > 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. > > Instead of analogies, I would love to read about how your Log system proposals works with headless images. Because to me it is really easy to write a grep command (I don't have to *explore* logs). > > 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. > > So you didn't answered my questions. Do I have to create 1 million of log objects and that is less expensive than flushing them as they occur into a file? What's the point of creating objects if I don't need them? > <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> > > I see. In the end we (still) read Strings, whatever conceptualization is above them. > > 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. > The point is isn't just me. I haven't seen any intensive computation software which creates log objects for self-exploration. And if you find one, I could cite 100 of them which does "String logging", and they just work, and people using it is not stupid, they know they have limitations, it happens that they prioritize other requirements. > > 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, ..). > > It is weird to read sometimes how Java developers have it so wrong, and sometimes they are visionary souls which drive us into the future. HernÃ¡n

Jan. 13, 2015

Re: [Pharo-dev] The Smalltalk Renaissance Program

by phil＠highoctane.be

On Tue, Jan 13, 2015 at 6:54 PM, Paul DeBruicker <pdebruic(a)gmail.com> wrote: > 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 > > I've put something like that in a package: http://www.smalltalkhub.com/#!/~philippeback/HOExtras/packages/HOCheatSheet Phil > > > 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