May 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo 5] Locale broken

by Hilaire

On the tracker, I asked for feedback on the changes occuring in the Locale class, because from the outside it looks like random refactoring, but I may miss a bigger picture. So? Hilaire Le 24/04/2016 19:40, Hilaire a Ã©crit : > https://pharo.fogbugz.com/f/cases/18076/Locale-broken -- Dr. Geo http://drgeo.eu

May 2, 2016

Re: [Pharo-dev] [Pharo 5] Some feedbacks

by Hilaire

Original authors should take responsability to write proper description. I can't imagine asking a Dr. Geo user to write a description on a tool he does not understand. Hilaire Le 02/05/2016 07:24, stepharo a Ã©crit : > Fix the ones that can easily be fixed and think about the others :) > So providing a better setting description is around 2 min work so we > should do it. > > Stef -- Dr. Geo http://drgeo.eu

May 2, 2016

Re: [Pharo-dev] STON - a little suggestion

by Sven Van Caekenberghe

Hi Carlos, First off: thanks for the feedback, it is very useful to discuss various real world scenarios. > On 28 Apr 2016, at 02:33, Carlos Lombardi <carlombardi(a)gmail.com> wrote: > > Hi, > > I want to use STON to enable the backup a graph of objects pertaining to an application. Would it be possible to provide more details (maybe off list), I would like to have a better idea of the issue you are trying to solve. What does that mean 'not supported by STON', why is that so ? Why do you need to write extra information ? what is in it ? how do you deal with it afterwards ? > Some of the objects in this graph include, in their state, a Map that is not supported by STON. > To write these objects, I would like to write via the standard procedure all the instance variables unless that pointing to such a map, and then add a modified version of that map by hand. > > To exclude the conflicting variable is easy, I just redefine #stonAllInstVarNames at the class side as follows: > ^self instVarNames reject: [ :theName | (theName = #references) ] > in this way, I do not need to modify the method if the state of these objects changes. Yes, that is one extension point. > On the other hand, I found not easy to use the standard mechanism for the included instance variables. This mechanism is embedded in STONWriter>>writeObject: . I found no option but repeat the logic codified there, in the method #stonOn: of my class. > > The easiest way to let STON integrate the standard mechanism to store the state of an object, with by-hand additions, is to slightly modify STONWriter>>writeObject:, adding just one line. Objects including instance variables would be written as follows: > > self writeObject: anObject streamMap: [ :dictionary | > instanceVariableNames do: [ :each | > (anObject instVarNamed: each) > ifNotNil: [ :value | > dictionary at: each asSymbol put: value ] > ifNil: [ > anObject stonShouldWriteNilInstVars > ifTrue: [ dictionary at: each asSymbol put: nil ] ] ] . > anObject stonAdditionalInfoOn: dictionary . ] > > the added line is the last one, the invocation to #stonAdditionalInfoOn:. Of course, the method #stonAdditionalInfoOn: should be added to the Object class. > By redefining this method in my class, I was able to easily add the modified, STON-compatlble value, to the values handled by the STON code. Overwriting #stonOn: is meant to be an extension point as well. > I did not need to modify the STON code to read the STON String to generate a new object. How can that work ? Via additional accessors ? Like I said, a concrete example, maybe of the STON output would be helpful. > Do you think that doing this modification to STON could be a good idea? Customising STON is OK, it should indeed be possible without changing the core code. But I would like to better understand your use case before really commenting. Regards, Sven > Cordially - Carlos > > > PS: I envisaged as an alternative, to allow the following method in my class > > stonOn:stonWriter > stonWriter writeObjectAsMap: self > do: [:mapWriter | > // added code goes here > stonWriter writeInstVarsOf: self on: mapWriter > // added code goes here > ] > > To this end, the methods #writeObjectAsMap:do: and #writeInstVarsOf:on should be added to STONWriter. The method > writeInstVar: aSymbol of: anObject on: mapWriter > could be offered as well, to allow more fine-grained redefinitions of stonOn: , while keeping the ability to use the standard mechanism to store an instance variable. > > I think that the option I described earlier is simpler, I include this one because maybe other people would prefere it. > >

May 2, 2016

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50741 Home: https://github.com/pharo-project/pharo-core

May 2, 2016

[pharo-project/pharo-core] a0845b: 50741

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: a0845baf8b1f465380959b56d1898655e8a68687 https://github.com/pharo-project/pharo-core/commit/a0845baf8b1f465380959b56… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-05-02 (Mon, 02 May 2016) Changed paths: A FreeType.package/FT2Handle.class/class/private/destroyMutex.st M FreeType.package/FT2Handle.class/definition.st M FreeType.package/FT2Handle.class/instance/private/pvtDestroyHandle.st A Kernel.package/CompiledMethod.class/instance/converting/asOrderedCollection.st A Kernel.package/CompiledMethod.class/instance/testing/isCollection.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50740.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50741.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50740.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50741.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50741 18133 GTInspector subscript out of bounds in raw tab https://pharo.fogbugz.com/f/cases/18133 18147 pvtDestroyHandle still presenting problems https://pharo.fogbugz.com/f/cases/18147 http://files.pharo.org/image/50/50741.zip

May 2, 2016

Re: [Pharo-dev] Logging API discussion

by stepharo

Le 28/4/16 Ã 15:06, Denis Kudriashov a Ã©crit : > > 2016-04-28 14:51 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com > <mailto:tudor@tudorgirba.com>>: > > And if I really wanted to add extra information, I rudimentary did: > > {âsome textâ . object } asBeaconSignal log. > > Or even: > > {âsome textâ . #someSymbol . 42 . object } asBeaconSignal log. > > > And for such cases we definitely need simple #log message without > #asBeaconSignal. It can be hidden inside. Or it can be: > > Log add: {âsome textâ . #someSymbol . 42 . object } > Yes I would prefer that instead sending add: Log information: {âsome textâ . #someSymbol . 42 . object }

May 2, 2016

Re: [Pharo-dev] Logging API discussion

by stepharo

> No, I did not suggest that you want to log strings. I simply said that this type of use case is different than the regular logging use case. I think it is important to treat these two separately because indeed when you debug you are in a prototyping mode and you want to go fast. In this situation, you do not want to have to create a separate class. But, for the long term logging you have different requirements and there you want to be more rigorous, and in that scenario creating a new class is acceptable. If we design a logging infrastructure the second use case is what we want to optimize around. Indeed Logging is not just about replace Transcript show: > > Of course, we should still think about the prototyping part. I found that it is often more interesting to log entire contexts (and have a post-mortem debugger) than individual objects. Nevertheless, with something as simple as: > > object asBeaconSignal log. > > It worked fine. > > And if I really wanted to add extra information, I rudimentary did: > > {âsome textâ . object } asBeaconSignal log. > > Or even: > > {âsome textâ . #someSymbol . 42 . object } asBeaconSignal log. I got a similar but not based on array but with a block to handle extension without subclasses. > > It is not the most elegant solution, but it is very malleable and good enough for debugging purposes. If we would have instance-based filtering for announcements, we could filter based on that without any extra effort. Also, if we would have a composition mechanism in place, we could build these objects with a more elegant API. > > Regarding your statement of logging domain objects, you will have to store these objects with the additional information somewhere, and that will be a wrapper class. I do not see the difference with the Signal. > > Cheers, > Doru > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of reality." > > >

May 2, 2016

Re: [Pharo-dev] Logging API discussion

by stepharo

Le 28/4/16 Ã 10:13, Denis Kudriashov a Ã©crit : > > 2016-04-27 20:50 GMT+02:00 stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>>: > >> >> And you say let's replace this "log object context" information >> with first class entities "typed signals". It means that for any >> possible case when I want to put something in log I should create >> class for new signal. It's just not practical. > why? > MySpecialLog > ... > emit > > > What I am talking about is that I don't want create MySpecialLog for > any MySpecialDomainObject which I want to log. I do not get it. Inheritance is good and if you combine it with delegation you can rule part of the world. BasicLog timeStamp object: MySpecialLog what I want

May 2, 2016

Re: [Pharo-dev] [Pharo 5] Some feedbacks

by stepharo

> I don't know what you want to do with these feedbacks, mostly UI oriented. Fix the ones that can easily be fixed and think about the others :) So providing a better setting description is around 2 min work so we should do it. Stef > > Hilaire > > Le 01/05/2016 09:11, stepharo a Ã©crit : >> Now it would be good to open bug entries to each of your points >> >> and help to address some of them. >> >> Stef

May 2, 2016

Re: [Pharo-dev] looking for pictures of new contributors

by Tudor Girba

Hi Peter, We know the existing contributors, but we would like to make sure that we have the necessary info (e.g., license agreement signed) about the new ones. Cheers, Doru > On May 1, 2016, at 5:47 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > And what if I am not new contributor (I've contributed to both 4 and 5), not on this list, and not on the website? :) > > On Sun, May 1, 2016 at 5:21 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > For the pharo.org site, I need photos of this persons (Pharo 5 new contributors): > > Abdelghani Alidra > David Allouche > Thibault Arloing > Vincent Blondeau > Miguel Campusano > Christopher Coat > Paul DeBruicker > Sergio Fedi > HolgerHansPeter Freyther > Thomas Heniart > Skip Lentz > Henrik Nergaard > Marion Noirbent > Merwan Ouddane > Alain Rastoul > Stefn Reichhart > Valentin Ryckewaert > Boris Spasojevic > Roger Stebler > Pablo Tesone > Franck Warlouzet > > Photo has to be a 70x70 PNG fileâ¦ if you do not send me a photo you will appear as a nice gray pharo, like this: http://pharo.org/files/faces/noface.png :) > > cheers, > Esteban > > > -- www.tudorgirba.com www.feenk.com "If you can't say why something is relevant, it probably isn't."

May 1, 2016