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

Re: [Pharo-dev] meeting today?

by Norbert Hartl

Esteban wrote a mail that it has been canceled again and he donât knows why. Heâll create a new one in half an hour and then we can meet. Btw. The hangout is for the consortium. So it might be better not to send such inquiries to the usual mailing lists. Norbert Am 17.06.2014 um 17:06 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: > Hi! > > Sorry if I have missed some email. Esteban has canceled the meeting for today? So, no meeting? > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

June 17, 2014

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

by Norbert Hartl

Stef, Am 17.06.2014 um 16:37 schrieb stepharo <stepharo(a)free.fr>: > I do not understand why log should be announcement. > Especially since log: is in Object in SystemLogger. > But I will not talk about this topic anymore because I felt insulted. > Doru like do not expect that people wants to join effort on any project, if the only reaction you have > when ask for help is to create a competitive solution. I wrote in my last mail that if you were insulted by me, too, I like to apologize because my mail was not written the way I think. Norbert

June 17, 2014

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

by Norbert Hartl

Am 17.06.2014 um 17:02 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 17 Jun 2014, at 16:37, stepharo <stepharo(a)free.fr> wrote: > >> I do not understand why log should be announcement. >> Especially since log: is in Object in SystemLogger. > > Being an Announcement is not a requirement to me, it is a delivery mechanism. > > Log event objects should be anything, as defined by the log producer. > Of course and that we have. Maybe it is just that you understood BasicLog>>#message to be text based instead of being an arbitrary object (and so it can be a string but it neednât). As well as we chose the approach to decorate an arbitrary object instead of having to subclass from one. I would be really glad if that turns out to be a misunderstanding. Norbert

June 17, 2014

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

by Norbert Hartl

Stef, Am 17.06.2014 um 16:32 schrieb stepharo <stepharo(a)free.fr>: > >> >> I had troubles myself seeing how this can contribute to SystemLogger. It looks a lot like âI donât like yours here is mineâ. But if you remember that is the same reason why you've started SystemLogger. > > no I started SystemLogger because > - it should log objects > - it should be the basis for the future logger. > ok. Here the combination of sentences is unfortunate. Iâm sorry! I know the reasons why you did it. And you know that I chimed in (not developing my own solution) because I liked the idea from the beginning (because I have thought about that often before). I just wanted to say that there are good reasons to start your own implementation (like you did). Thatâs all! >> So you should be fair here. Now it is the time to see how we can benefit from each other. I see it as an advantage to have code to compare because a lot of discussions are usual too theoretical to make something of it. >> I did not have the time to look at svens and dorus code. But I will because I had the impression, too, in the beginning that the dispatching of events would be better done with announcements. > > If you have an hammer everything looks like a nail. Right. In my case it is just a gut feeling I had all the time. Might be it turns out that announcements are not the way to go. But I want to look at it. > To me it just kills my fun. > I understand and Iâm sorry if the mail I wrote supported that. To be really honest I had the same feeling when I talked with Sven and Doru. It appeared to me that everyone wanted to place his own solution. But I like to take the chance that we get something out where a lot of people are happy with. On the other hand SystemLogger is not final. It can be improved and we should improve it. Now it is the time to collaborate and tame our egos. Otherwise there will be three half baked approaches, one in zinc, one in GT* tools and one in pharo. That would be the worst outcome. In order to prevent that I wanted to talk. Just that! My plan is to: - look at beacon to see what Doru has in his mind. Maybe I get a good idea from it - then I would look at Svenâs new code to see the difference to Doruâs and to actual see if that works for more than a framework - finally I would like to look at the SystemLogger design again and improve it where it might be improved. - then there will be a new version of SystemLogger. Thatâs it. I personally donât plan to skip SystemLogger in favour of beacon or zinc log. beacon is a proof of concept but there are AFAIK no formatters, outputs and so on. So it is not even a replacement for SystemLogger. Zinc log is a log system for a single framework called zinc. Iâm not sure it can be useful for anything else and I donât think Sven is hitting in that direction. I want a basic logging support that either has a central access for pain free logging or it has multiple announcers (maybe one per module/framework) that can be composed to a log source that can be attached to some kind of dispatcher. I donât know. That I need to figure out Norbert >> We all should review the other implementations and all of us should be open minded for any reason why the own implementation is probably _not_ the way to go. >> I wish we can find an agreement about an optimal implementation we like to promote. >> >> Norbert >> >> >>>> It is called Beacon, it is based entirely on Announcements, it has ~200 lines of code, it has no tags or levels, and in my opinion it is fully functional. >>>> >>>> You can see a detailed description here including some informal comparisons with SystemLogger: >>>> http://www.humane-assessment.com/blog/beacon >>>> >>>> Please let me know what you think. I would be happy to join forces to reach a mature solution that is both versatile and that can show how Pharo is different. >>> So should we see it as a competitor to SystemLogger? >>> (you will say of course not) but I do not understand. >>> >>> >>>> >>>> Cheers, >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>> >> >

June 17, 2014

meeting today?

by Alexandre Bergel

Hi! Sorry if I have missed some email. Esteban has canceled the meeting for today? So, no meeting? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 17, 2014

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

by Sven Van Caekenberghe

On 17 Jun 2014, at 16:37, stepharo <stepharo(a)free.fr> wrote: > I do not understand why log should be announcement. > Especially since log: is in Object in SystemLogger. Being an Announcement is not a requirement to me, it is a delivery mechanism. Log event objects should be anything, as defined by the log producer.

June 17, 2014

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

by stepharo

I do not understand why log should be announcement. Especially since log: is in Object in SystemLogger. But I will not talk about this topic anymore because I felt insulted. Doru like do not expect that people wants to join effort on any project, if the only reaction you have when ask for help is to create a competitive solution. Stef

June 17, 2014

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

by stepharo

> > I had troubles myself seeing how this can contribute to SystemLogger. > It looks a lot like âI donât like yours here is mineâ. But if you > remember that is the same reason why you've started SystemLogger. no I started SystemLogger because - it should log objects - it should be the basis for the future logger. > So you should be fair here. Now it is the time to see how we can > benefit from each other. I see it as an advantage to have code to > compare because a lot of discussions are usual too theoretical to make > something of it. > I did not have the time to look at svens and dorus code. But I will > because I had the impression, too, in the beginning that the > dispatching of events would be better done with announcements. If you have an hammer everything looks like a nail. To me it just kills my fun. > We all should review the other implementations and all of us should be > open minded for any reason why the own implementation is probably > _not_ the way to go. > I wish we can find an agreement about an optimal implementation we > like to promote. > > Norbert > > >>> It is called Beacon, it is based entirely on Announcements, it has >>> ~200 lines of code, it has no tags or levels, and in my opinion it >>> is fully functional. >>> >>> You can see a detailed description here including some informal >>> comparisons with SystemLogger: >>> http://www.humane-assessment.com/blog/beacon >>> >>> Please let me know what you think. I would be happy to join forces >>> to reach a mature solution that is both versatile and that can show >>> how Pharo is different. >> So should we see it as a competitor to SystemLogger? >> (you will say of course not) but I do not understand. >> >> >>> >>> Cheers, >>> Doru >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> >>> "Every thing has its own flow" >> >

June 17, 2014

ConfigurationOfSandstoneDB?

by Udo Schneider

All, I'm searching for an up-to-date version of ConfigurationOfSandstoneDB. In the past I used the MetacelloRepository on SS. However this doesn't seem to be updated anymore (as a side-effect of SS being made read-only). So can anybody point me to an updated version of ConfigurationOfSandstoneDB or even better to an "official" successor of MetacelloRepository? Thanks, Udo

June 17, 2014

Survey: outdated slices

by Martin Dias

Hello dear Pharo community, I'm looking for fogbugz issues where a slice that was ready to be integrated became outdated because of other issues that were integrated before. In other words: the author of a slice writes it in Pharo-30XXX. Then, a responsible of integration wants to merge it in a Pharo-30YYY (where YYY > XXX), and the slice is rejected because it is old. Note: the reason of rejection can be a merge conflict, but I'm particularly interested in more subtle cases, where the reason was not that clear. Regards, MartÃn

June 17, 2014