Re: [Pharo-dev] Tools for automatic recognition of Design Patterns
stepharo wrote Now if you are interested in a topic that is somehow related: one of the key challenge for today software development is how do we document in an executable way frameworks so that during the next 10 ot 15 years they can be maintained an extended even when the main developers left. It's not a question of how, but when, really. There are many answers to this question and one of them is Chimera: https://www.ics.uci.edu/~taylor/ics228/chimera.pdf http://forum.world.st/file/n4802920/chimera.png There are no perfect solutions of course, but a lot could be done to improve the current situation, for example, executable flow charts (Grail is a great example) would be also a great start. Visual arrangement of concepts such as classes and annotations (in the form of mind maps) would be also great. The concepts are there, they just have to be rediscovered and integrated into Pharo. What your system needs is a hypermedia system and the liveliness would make it a perfect candidate. I have written about future directions, but nobody seemed interested which was quite a surprise to me. -- View this message in context: http://forum.world.st/Tools-for-automatic-recognition-of-Design-Patterns-tp4802777p4802920.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Tools for automatic recognition of Design Patterns
Sounds exciting, I'd be also happy to know if there is any tool I might have missed. You might want to take a look at the ASTInterpreter and write the analyses yourselves, if that is an option. As a matter of fact, I have some experience in doing program analysis and design pattern detection, but that's a long time ago. If you need any help, please let me know. -- View this message in context: http://forum.world.st/Tools-for-automatic-recognition-of-Design-Patterns-tp4802777p4802793.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] Create window group for Playground
Funny, I didn't know about that feature either. Thanks for the informative video, kilon. The issue of many windows is a significant problem that deserves a closer attention. Well, for starters, I am wondering why the World Window is limited to my screen size (or have I missed something?). I think it would make a better experience if the main window was infinite in size just like in the Self Environment http://www.selflanguage.org/ . This way I could put windows, workspaces and other artifacts to locations that have specific meanings to me (spatial memory, very important), just like you would organize any working place. This would work great with a seemless zoom function. http://forum.world.st/file/n4802751/cvp1yvcvjigd3fyi7.gif In addition, it might be helpful to have multiple world windows and to be able to arrange them, just like in Xmonad http://xmonad.org/ . Unfortuantely, I do not have the resources to implement that but I think that these changes would be very beneficial. For a start, it would be great to have a zoomable infinite workspace. -- View this message in context: http://forum.world.st/Create-window-group-for-Playground-tp4802517p4802751.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] What Logging framework for Pharo
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.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] What Logging framework for Pharo
Nice demonstration on ZnLogEvent, Sven! My two cents: This is broken because it implies that the human should read the log as a way of understanding it. [...] but in practice all logs I have seen in enterprise systems are mostly /unstructured /and one has to spend great effort to extract the useful information out of them. That's a good point. Object-oriented logging is certainly a step forward, but I wonder at which point does an object-oriented log become unreadable, especially when we talk about large scale systems with millions of objects, multiple layers of abstraction, subsystems etc.? I claim that even with object-oriented loggers at some point when a system evolves, there will be either too much or too little information: Simply because logging is not a first-class citizen (also in Pharo's conceptual architecture as far as I have seen). All systems that I have seen lack self-description at higher levels (i.e., of their architecture). Given that fact, how can an object-oriented logger know which role its objects play in the architecture of a system and represent that information in a comprehensible way? It would be nice to zoom into logs, having level of detail, but this cannot be done by merely putting logging calls into methods. You could try, but it would require an immense programming effort and the logging scheme would still be incomplete or incomprehensible to someone else. I do not want to rely on programming to see what is happening in my system or on others to do that programming for me (after all, how can a programmer really know what I want to see?). I rather more imagine a system where I can see the connections between objects, where I can put instruments (such as loggers) between the connections. In such a visual representation, it would be also easier to observe cause and effect, observe message flows and to zoom into different layers. This way, I do not have to touch the source code, I can learn about the system in my own way. It's much like electronics by putting measurement devices between connections: In software we even have the advantage to zoom into bigger blocks and to measurements in a uniform way. I think that is the metaphor we should be after (or one of them) - in my opinion. Cheers -- View this message in context: http://forum.world.st/What-Logging-framework-for-Pharo-tp4799073p4799227.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] What Logging framework for Pharo
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. 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. 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. There are many, many usage scenarios and even more might pop up with more accessible and comprehensible logging schemes. We need to go far beyond logging. -- View this message in context: http://forum.world.st/What-Logging-framework-for-Pharo-tp4799073p4799254.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] What Logging framework for Pharo
philippeback wrote Text is here to stay once we get into the sysadmin realm. People do not want to deal with code internals when they are doing the piping. Just my experience dealing with such admins working with a lot of different systems. We cannot ask them to become polyglot coders as their hands are full already. I agree that people should deal with code internals, that was my entire point. We should try to find ways to make systems more *self-representative, self-explanatory and direct*. People who want to instrument a system should not have to resort to programming, and, borrowing the metaphor from electronics they don't have to (at least for the static parts of the system, see my previous post). As for text: Who says that text is here to say? Just because it always has been this way, does not mean it always will. Instead of using the traditional ways and metaphors of building systems, we should look for better alternatives - isn't that the whole point of the Pharo project? And looking at the past of computing, there are a lot of good ideas and metaphors that need to be incorporated into Pharo, instead of doing old things in a slightly different fashion and repeating all mistakes in different clothings. In other words: To me the need for logging facilities is a symptom of a larger architectural problem: self-representation. This problem needs to be tackled at its roots and there are many ways to do this. The problem that I see is that immediate needs have to be satisfied but that doesn't mean to cave in. I won't, I am done with code hacking. -- View this message in context: http://forum.world.st/What-Logging-framework-for-Pharo-tp4799073p4799263.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] Modifying methodDict breaks System Browser
Hi, After replacing the method of a class with an object of a class implementing the /run:with:in/ method, the context menu of the System Browser stops appearing, a debug context menu Why you see this menu. Debug pops up instead. After putting the original method back, the browser works again. Code: o := Interceptee new. m := Interceptee methodDict at: #method. Interceptee methodDict at: #method put: Interceptor new. o method. Breaks context menu? Interceptee methodDict at: #method put: m. Browser works again Is anyone else having this problem? Or am I doing anything wrong? Thanks -- View this message in context: http://forum.world.st/Modifying-methodDict-breaks-System-Browser-tp4799147.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] TextMorph broken?
Thanks Stef, that's good to know. It's certainly not an easy task, and I am glad that there is progress! Thanks Alain! -- View this message in context: http://forum.world.st/TextMorph-broken-tp4798645p4798755.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] TextMorph broken?
I used PluggableTextMorph instead and an override to vIsScrollbarNeeded. However, it seems problem (4) is also present in the PluggableTextMorph class. Also, there is no font change button for LabelItems in the morphic menu. Looking at the, sometimes rather obscure code in Morphic classes, it seems that some major refactoring is in order. Are there any plans to revise Morphic? Also, is there additional documentation for Morphic? (Unfortunately, the Squeak Wiki is rather superficial :(). Well, at least the live environment makes inspection and experimentation easy :) -- View this message in context: http://forum.world.st/TextMorph-broken-tp4798645p4798713.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] The Smalltalk Revolution
In my humble opinion, there is no point battling naysayers: the energy required is best spent with people sharing a vision, improving the system and experimenting with concepts to help us tackle the complexity of large systems. Smalltalk is only the beginning, not the final solution. As for corporate and private computing: Trust is a big issue. With recent events, maybe a bigger issue than ever. Corporations and users need to trust their software. Smalltalk provides a degree of transparency and accessibility not found in other systems. If you don't know what your application is doing, you simply plug it apart and inspect it. The uniformity of the system makes this process far easier than inspecting a mountain of, for instance, C code. Then, there is the problem of language integration and obsoletion. It is funny that many corporations still rely on a handful of trendy languages to solve all kinds of problems. Some have already realized that polyglot programming is the way to go and Smalltalk provides an ideal basis to do this. However, we have to demonstrate that we can build better, larger systems in a far more productive and comprehensible fashion. What we need is to establish a unified systems architecture and Smalltalk is an ideal candidate. But there is still a long way ahead (but the malleability of Smalltalk might make it easy for us to explore new horizons and set new directions). The naysayers will, inevitably, follow. -- View this message in context: http://forum.world.st/The-Smalltalk-Revolution-tp4798320p4798516.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
[Pharo-dev] TextMorph broken?
Hi, I hate to bring this up, but it seems that TextMorph is broken: (1) The width of a TextMorph cannot be changed directly, only resetting the content (via #contents:) changes its width. (2) It's not possible to position the cursor past the last character with a point and click operation. (3) Moving the cursor past the last character with the arrow keys makes it disappear (even though it is positioned correctly). (4) It's not possible to change the font in the meta-menu. Is anyone else having similar problems? Any recommendations? All I need is a single line TextMorph that matches its width with the width of its text. I am using Pharo 3.0 (the most recent official version retrievable via the website). Thanks -- View this message in context: http://forum.world.st/TextMorph-broken-tp4798645.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] The Smalltalk Revolution
I am curious. Which frameworks can we expect to see? -- View this message in context: http://forum.world.st/The-Smalltalk-Revolution-tp4798320p4798561.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] The Smalltalk Revolution
-based programming. Although only networks with a fixed topology can be effectively modeled this way, I assume that most parts of, for instance GUI systems, could be made more self-explanatory. Wouldn't it be nice to visually connect a button event to a method? Or a label to a clock? Workable examples could be of course, reachable in the hypermedia system. Memory as a First Class Citizen Further ideas are to make *memory a first class citizen*: I think that memory should be, just as an object, part of the hypermedia system, or a hypermedia system itself. Since it represents the state of the system, it should be self-explanatory. Tradtionally, memory is allocated in indivisible, incomprehensible and (inaccessible) lumps to processes. However, I think memory should not only contain data but also interpretable metadata about the contents of its cells and relationships. From a Smalltalk viewpoint, I imagine that every attribute of an object is visibly connected to a memory location with a name (and further metadata). This way, computations running in different processes or runtime environments could simply connect to the memory, consume data and write it back. This would also make it easy to have true *heterogeneous flow-based programming*. (Conversions between data types could be just plugged in between). Ideally, Smalltalk takes the place of current operating systems (such as SqueakNOS), running the hypermedia kernel and providing access to the *conceptual* memory. Languages such as C, C++ or Haskell could then be used to implement /pure computations/ and they could be attached to memory cells, waiting for input. Also, security policies can be expressed in a uniform way. There is also a firm theoretical foundation (the Ambient Calculus) which can be used to express hairy details about security policies. Ultimately, I think it would greatly benefit interoperability. There is also a huge potential benefit to testing: One simply has to identify the input network of the memory, and record a subset or all of the patterns occurring in the other part of the system. Then, by replaying the input, one can compare the resulting pattern with the record. Also, undo operations could be performed by changing cell values back to their recorded images. Smalltalk everywhere I imagine that every part of the computer contained such a Smalltalk hypermedia system describing the objects and relations in its memory contents. This would make it easy to browse, visualize and manipulate computer components, network infrastructure, anything really. With the vast improvement of computer hardware, in particular programmable logic, having a Smalltalk interpreter on almost every device seems quite feasible to me. The future of Smalltalk is indeed grand! (I hope I have not got delusional at this point). Atlas Project I have started working on a prototype, I am anxious to test some of the ideas I proposed. There is much uncharted territory and Pharo seems to be a great platform and vehicle to explore new ideas. Are there people willing to contribute, help? What are your opinions? [1] http://www.selflanguage.org/ [2] https://www.ics.uci.edu/~taylor/ics228/chimera.pdf [3] http://scg.unibe.ch/archive/papers/Reng09bLanguageShootout.pdf [4] http://infoscience.epfl.ch/record/176887/files/DeprecatingObservers2012.pdf [5] http://www.dougengelbart.org/pubs/augment-3906.html -- View this message in context: http://forum.world.st/The-Smalltalk-Revolution-tp4798320p4798412.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
