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

Re: [Pharo-dev] Where is the postcard with syntax?

by phil＠highoctane.be

I made a little cheat sheet package from http://www.smalltalkhub.com/#!/~philippeback/HOExtras/packages/HOCheatSheet "A HOCheatSheet is a set of useful things to remember See Class Side. Using content from Chris Rathman / ChrisRath(a)aol.com" Obviously not a postcard :-) Phil On Mon, Jun 16, 2014 at 3:35 PM, Oscar Nierstrasz < oscar.nierstrasz(a)gmail.com> wrote: > > I got it from Stef, who always said it came originally from Ralph Johnson. > > http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard > > Googling around finds various copies of this, but no original source. > > Oscar > > On 16 Jun 2014, at 10:58 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > > I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf > > > > I think that it would be interesting to put the syntax on a postcard. It > can work as a proof of concept, some addition cheat-sheet for newcomers and > also as some king of souvenir. > > > > Uko > > > > On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: > > > >> you have the flyer of Damien (no idea where it is) but no real postcard. > >> > >> Stef > >> > >> On 16/6/14 09:35, Yuriy Tymchuk wrote: > >>> Hi guys, > >>> > >>> we all are talking about the syntax fitting in a postcard, but was > there any real postcard with Pharo syntax prototype? This would be really > interesting. > >>> > >>> Uko > >>> > >>> > >> > >> > > > > > > >

June 16, 2014

Re: [Pharo-dev] Where is the postcard with syntax?

by Oscar Nierstrasz

I got it from Stef, who always said it came originally from Ralph Johnson. http://c2.com/cgi-bin/wiki?SmalltalkSyntaxInaPostcard Googling around finds various copies of this, but no original source. Oscar On 16 Jun 2014, at 10:58 , Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I guess itâs here: http://files.pharo.org/media/flyer-cheat-sheet.pdf > > I think that it would be interesting to put the syntax on a postcard. It can work as a proof of concept, some addition cheat-sheet for newcomers and also as some king of souvenir. > > Uko > > On 16 Jun 2014, at 10:36, stepharo <stepharo(a)free.fr> wrote: > >> you have the flyer of Damien (no idea where it is) but no real postcard. >> >> Stef >> >> On 16/6/14 09:35, Yuriy Tymchuk wrote: >>> Hi guys, >>> >>> we all are talking about the syntax fitting in a postcard, but was there any real postcard with Pharo syntax prototype? This would be really interesting. >>> >>> Uko >>> >>> >> >> > >

June 16, 2014

Re: [Pharo-dev] Spec list with checkboxes?

by Yuriy Tymchuk

No, I thought that chances for list to have checkboxes are higher than for tree :) Thank you On 16 Jun 2014, at 14:52, Christophe Demarey <Christophe.Demarey(a)inria.fr> wrote: > Did you check TreeModel>>beCheckList ? > > Le 16 juin 2014 Ã 14:36, Yuriy Tymchuk a Ã©crit : > >> Hi everyone. I need to generate arbitrary number of checkboxes and I wander if there is something like a list with checkboxes or something similar. I know that I can use dynamic UI, but maybe there are some existing components that can help to solve the problem. >> >> Uko >> >

June 16, 2014

Re: [Pharo-dev] Spec list with checkboxes?

by Christophe Demarey

Did you check TreeModel>>beCheckList ? Le 16 juin 2014 Ã 14:36, Yuriy Tymchuk a Ã©crit : > Hi everyone. I need to generate arbitrary number of checkboxes and I wander if there is something like a list with checkboxes or something similar. I know that I can use dynamic UI, but maybe there are some existing components that can help to solve the problem. > > Uko >

June 16, 2014

Spec list with checkboxes?

by Yuriy Tymchuk

Hi everyone. I need to generate arbitrary number of checkboxes and I wander if there is something like a list with checkboxes or something similar. I know that I can use dynamic UI, but maybe there are some existing components that can help to solve the problem. Uko

June 16, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Esteban Lorenzano

On 16 Jun 2014, at 09:00, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 16 Jun 2014, at 05:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 16 Jun 2014, at 10:01, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >>> I find I'm unable to use a recent vm with Roassal/cairo on Mac OS 7.5. >> >> I am assuming this is a typo, right ? >> >> Mac OS System 7.5 is from September 1994 ... >> >> http://en.wikipedia.org/wiki/System_7#Version_history >> >>> The dec 12 version works, but all new ones say: failed to get a symbol address: cairo_image_surface_create > > do you have an easy way to reproduce it? btwâ¦ tiger demo runs out of the box in my machine. So I assume is not a problem of VM or Athens. It has to be someplace else. if it is not a type, MacOS 7.5 is certainly not supported for us :) but of course, if builds from dec used to work, there is no reason why it shouldnât continue working (the merge I did just affect internals of VM, not the platform sources). Esteban > > Esteban > >>> >>> Stephan >> >> >

June 16, 2014

Re: [Pharo-dev] [experimental/in-progress] Framework agnostic pure object logging for Zinc

by Ben Coman

June 16, 2014

Re: [Pharo-dev] Vm on Mac OS 7.5 no cairo

by Esteban Lorenzano

On 16 Jun 2014, at 05:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 16 Jun 2014, at 10:01, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> I find I'm unable to use a recent vm with Roassal/cairo on Mac OS 7.5. > > I am assuming this is a typo, right ? > > Mac OS System 7.5 is from September 1994 ... > > http://en.wikipedia.org/wiki/System_7#Version_history > >> The dec 12 version works, but all new ones say: failed to get a symbol address: cairo_image_surface_create do you have an easy way to reproduce it? Esteban >> >> Stephan > >

June 16, 2014

Re: [Pharo-dev] [experimental/in-progress] Framework agnostic pure object logging for Zinc

by Norbert Hartl

Am 16.06.2014 um 09:15 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 16 Jun 2014, at 08:25, stepharo <stepharo(a)free.fr> wrote: > >> Hi sven >> >> Objects are the way to go. > > Yes ! > >> Will this compatible be with SystemLogger? I mean could not you use SystemLogger? > > I hope that SystemLogger can work with a subsystem that generates a stream of log objects, without requiring them to be subclasses of something. If so, then it will be compatible (just connect the announcer to where you want to sent the objects to). If not, then I don't understand how SystemLogger can be a pure object log. > > I said this before (and I miss this in the SystemLogger documentation, and even in the Beacon description): show real object based logging from the beginning, not degenerate string logging. > > In the case of SystemLogger, the class BasicLog already contains a message, why ? The API is also still mainly expressed with strings. (BTW, there should not be a messageText in exception, for example, being an instance of ZeroDivide or KeyNotFound with a key says it all). This is somethings that bugged me for a long time. The message instVar in BasicLog has probably a misleading name. The message is suppsoed to contain any object not just a string. BasicLog and Log are not supposed to be subclassed if you havenât special needs. BasicLog has two instVars: a timestamp and a message object. It acts as a decorator for any object you like to log. Therefor we have Object>>#asLog ^ self class newLog message: self Object class>>#newLog ^ self logClass new Object class>>#logClass "Hook supporting the redefinition by object of their associated log. When using myObject asLog emit, the logClass will be used and myObject will be passed as message argument." ^ Log If you need another decorator for your log objects then you override #logClass on the class side of your business object. This is exactly so you do not have to derive your objects from any class in SystemLogger. The BasicLog resembles the most basic thing. To me a log entry has always a timestamp when the event occurred. And there is a message instVar for keeping any object. The Log class derives from BasicLog and resembles a Log class that is used in other frameworks/operating systems. How the Log is converted to is defined in the Loggers itself at the best possible time before they leave the image. Norbert > > And like in the basic BeaconSignal, you predefine a timeStamp, why ? Is it really needed, or not ? In my other projects I don't use DateAndTime but ZTimestamp, things like that should not be forced on user. A timestamp even with high precision is not necessarily unique, that is why I added a secondary id. > >> Because I do not see them why I spend my time to build infrastructure. > > Sure, I need/want a nice backend with lots of functionality (like what Norbert was experimenting with). Also, for casual usage, some classes to inherit from are useful. Maybe a system level API as well. > > Second, we will probably need conventions, maybe expressed as traits of useful attributes for log objects so that we can write general analysis tools. > >> Stef >> >>> Hi, >>> >>> Since years, Zinc has been using its own Announcements-based logging mechanism for client and server logging. The payload of the Announcements used was still essentially text based though. >>> >>> In some discussions months ago with Norbert Hartl in the context of his work on SystemLogger, the concept of pure object logging as an alternative to text based logging became an interesting alternative for me. In an internal project that I did earlier this year I tried out this concept for myself and was quite happy with the result. >>> >>> Doru Girba had indicated several times to me that he was also interested in thinking about logging, so when he started talking about Beacon, I decided to write down my ideas a bit in a quick draft: >>> >>> https://github.com/svenvc/docs/blob/master/draft/logging-with-objects.md >>> >>> And to make this even clearer, I had to change Zinc logging to work along these principles. The current #bleedingEdge experimental/in-progress version of Zinc now contains a first working version of 'framework agnostic pure object logging'. The conversion is not yet finished - there is still much to learn here - but it already looks quite nice I think. >>> >>> Monitoring logging output can be done by opening an Announcement Spy. >>> >>> ZnNewLogEvent open. >>> >>> Next you run some code (start a server, do one request, stop the server). >>> >>> (ZnServer defaultOn: 1701) >>> route: #server1; >>> start. >>> >>> ZnClient new >>> clientId: #client1; >>> beOneShot; >>> get: 'http://localhost:1701/random'. >>> >>> ZnServer stopDefault. >>> >>> Which give the following output (using the standard string representation). >>> >>> <Mail Attachment.png> >>> >>> However, each line is a rich object containing tons of information. Here is the highlighted line in the Explorer. >>> >>> <Mail Attachment.png> >>> >>> As you can see, all information from during the client and the server's execution is preserved, ready to be used for logging and/or debugging, right now or later on. >>> >>> Nowhere in the main ZnClient or ZnServer logging code is there simple string or text logging, everything being logged by announcing a log event object. >>> >>> I hope that this plays well with both SystemLogger, Beacon and maybe other logging frameworks out there. >>> >>> When I bring this approach more and more in production use, it will most probably evolve further. In the meantime, have a look: I would love feedback. >>> >>> Sven

June 16, 2014

Re: [Pharo-dev] [ann] beacon - a slim announcement-based logging engine

by Norbert Hartl

Am 16.06.2014 um 12:10 schrieb Tudor Girba <tudor(a)tudorgirba.com>: > Hi Sven, > > > On Mon, Jun 16, 2014 at 11:54 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 16 Jun 2014, at 10:53, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > - Like I said in my document and like I tried to show in my implementation for Zinc, I want framework agnostic pure object logging, so I don't want to subclass from anything (I do from Announcement, but that is an implementation detail, the technique how #emit is done), can you deal with the ZnNewLogEvents as the are ? > > > > As you can see at the end of the post, you can just use your own Announcements. There is no real magic there. So, it should be no technical problem to accommodate the logging of ZincEvents as they are. > > Yes, but even being an Announcement subclass is debatable. > > If you can announce any object, then you do not need Announcements either :). I agree with Sven here. I think the need to subclass another framework class is a big restriction. Announcements (as any object) have static part (class, instVars) and a dynamic part. In this case it is the infrastructure and the way they get delivered, the way I can register for receiving them etc. To me the latter is the important part. I never understood why not every object can be an announcement. This way it just leads to doubled class hierarchies just for the sake to announce anything. Norbert > > > > However, one thing that we should also think about is the actual analyses that we might want to do. For example, the inspector extension for RecordingBeacon uses: > > - timestamp, and > > - printOneLineContentsOn: > > > > And these requirements will grow even more as we are building more specialized tools. So, to this end, it is useful to have some common ground. > > Yes, I mentioned this already several times: traits listing expected protocol would be good. Maximum polymorphism, latest possible binding, no dependencies, composable. > > Agreed. All I said is that to find the useful protocols we need to build the tools and not stop the discussion at the recording part of the logging. > > > > Now, as far as I know, the only reason why you do not want to subclass BeaconSignal is because you want to use ZnTimestamp. I see no reason to have two Timestamps in the image anyway, so I have no problem pushing just one. > > Or do you have another reason? > > I first of all want no dependency so that different logging backends can be plugged in or used. I think that this takes away any lock-in anxiety from people like myself, which will increase adoption. > > I do not understand that. First, we talk about a handful of lines of code. Second, actually your newest implementation already ships a more specialized version of Beacon, so from this perspective Zinc already binds me at least to Announcements. Is this a bad thing? I think it is rather pragmatic. > > > BTW, it is ZTimestamp not ZnTimestamp, it has absolutely nothing to do with Zinc. ZTimestamp is second precision, UTC only, and takes half the size. It comes with cool formatting/parsing, full timezone and basic SNTP support. > > Yeah, my bad. > > No, I want all users to be able to make there own choices for whatever reason (efficiency, precision, portability). The timestamp is the only concrete element we can discuss now, but there could be others. > > Freedom is good in the sense that people should be able to customize anything they want. At the same time if you want to provide services on top, you need to find a useful commonality. In our concrete case, I see no reason to keep DateAndTime when the other one is better. > > Doru > > > -- > www.tudorgirba.com > > "Every thing has its own flow"

June 16, 2014