- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Hungry Pharo

by dimitris chloupis

I would not worry too much over this. I have MenuMeters even before I was introduced to smalltalk over a year ago and Pharo is steadily reported consuming a 5% of my CPU which is average for an ObjC app on Macos 10.7Â http://www.ragingmenace.com/software/menumeters/ So personally I am impressed with pharo speed so far. A big thumbs up from me. Also take into account that even though MacOS is a great OS it comes with its own fair share of bugs, especially the first year of its release so I would not put too much attention into this if I was you. On Monday, 28 October 2013, 18:08, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: Now with Mavericks we can tell that Pharo is hungry for energy :) Cheers! Uko

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by roberto.minelli＠usi.ch

The idea is that I have an object (a session) which has meta data (time, duration, author) and some other object inside. I want that Fuel serializes just that object and not pointes to other object, globals and what not. This causes me a lot of troubles, moreover it makes the fuel file bigger than the optimumâ¦ Cheers, R On Oct 28, 2013, at 4:57 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > Thanks, > > On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > Currently there is no such option. > > Maybe it is something which is needed, what do you think? > > The idea is that, if you serialize: > > a -> b -> c > > fuel actually would encode: > > a -> b -> nil > > > that? > >

Oct. 28, 2013

Hungry Pharo

by Yuriy Tymchuk

Now with Mavericks we can tell that Pharo is hungry for energy :) Cheers! Uko

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by Martin Dias

On Mon, Oct 28, 2013 at 4:47 PM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Thanks, > > On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > Currently there is no such option. > > Maybe it is something which is needed, what do you think? > The idea is that, if you serialize: a -> b -> c fuel actually would encode: a -> b -> nil that?

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by roberto.minelli＠usi.ch

Thanks, On Oct 28, 2013, at 4:36 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > Currently there is no such option. Maybe it is something which is needed, what do you think? > You might want to customize how your "development session" objects are encoded. Like in DateAndTime... you can look at these methods: > > #fuelAccept: > #serializeOn: > #materializeFrom: (at class-side) > > > Or you can tell fuel to ignore some instance variables, if you override #fuelIgnoredInstanceVariableNames at class-side. > > Both alternatives are covered in the documentation > > http://rmod.lille.inria.fr/web/pier/software/Fuel > > (which is sadly down in this moment, but will be up again soon) > > MartÃn > > > On Mon, Oct 28, 2013 at 4:10 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > Hi Martin, > > Thanks for the answer, I have another question. Is there any way to tell Fuel to serialize only the object with its instance variables and thatâs it? > > I donât want Fuel to traverse any reference, just the object with its fields. > > Thanks, > Roberto > > On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method. > > > > So I think in some way your object is referencing that problematic block closure. > > > > Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: > > > > Maybe a "self haltIf: anObject isClosure" > > > > HTH, > > MartÃn > > > > > > On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > > Hi, > > > > Iâm struggling with Fuel and I probably discovered my problem. > > > > When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max. > > > > I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so? > > > > Cheers and thanks for the help, > > Roberto > > > > >

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by Martin Dias

Currently there is no such option. You might want to customize how your "development session" objects are encoded. Like in DateAndTime... you can look at these methods: #fuelAccept: #serializeOn: #materializeFrom: (at class-side) Or you can tell fuel to ignore some instance variables, if you override #fuelIgnoredInstanceVariableNames at class-side. Both alternatives are covered in the documentation http://rmod.lille.inria.fr/web/pier/software/Fuel (which is sadly down in this moment, but will be up again soon) MartÃn On Mon, Oct 28, 2013 at 4:10 PM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Hi Martin, > > Thanks for the answer, I have another question. Is there any way to tell > Fuel to serialize only the object with its instance variables and thatâs it? > > I donât want Fuel to traverse any reference, just the object with its > fields. > > Thanks, > Roberto > > On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > > > I don't remember the previous discussion. When you tell fuel to > serialize an object, it traverses the references of that object *to* other > objects. By default, it uses some criteria to prune the traversal. For > example, when the traversed object is a class, then it encodes the name of > that class. Similar for a method. > > > > So I think in some way your object is referencing that problematic block > closure. > > > > Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: > > > > Maybe a "self haltIf: anObject isClosure" > > > > HTH, > > MartÃn > > > > > > On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli(a)usi.ch < > roberto.minelli(a)usi.ch> wrote: > > Hi, > > > > Iâm struggling with Fuel and I probably discovered my problem. > > > > When trying to serialize an object (that represents a development > session, i.e., contains some meta-data (title, author, etc.) and some > objects representing actions of the developer) I often encounter problem > with some BlockClosureâs which are somewhat corrupt and Fuel crashes and > cannot serialize them. We already discussed this issue in this mailing list > a while ago with Max. > > > > I do not ask directly Fuel to serialize some BlockClosures, so my > intuition is that Fuel serializes all the references to the objects I am > trying to serialize. Am I right? Is there any way to tell Fuel not to do so? > > > > Cheers and thanks for the help, > > Roberto > > > > >

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by roberto.minelli＠usi.ch

Hi Martin, Thanks for the answer, I have another question. Is there any way to tell Fuel to serialize only the object with its instance variables and thatâs it? I donât want Fuel to traverse any reference, just the object with its fields. Thanks, Roberto On Oct 28, 2013, at 4:00 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method. > > So I think in some way your object is referencing that problematic block closure. > > Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: > > Maybe a "self haltIf: anObject isClosure" > > HTH, > MartÃn > > > On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > Hi, > > Iâm struggling with Fuel and I probably discovered my problem. > > When trying to serialize an object (that represents a development session, i.e., contains some meta-data (title, author, etc.) and some objects representing actions of the developer) I often encounter problem with some BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot serialize them. We already discussed this issue in this mailing list a while ago with Max. > > I do not ask directly Fuel to serialize some BlockClosures, so my intuition is that Fuel serializes all the references to the objects I am trying to serialize. Am I right? Is there any way to tell Fuel not to do so? > > Cheers and thanks for the help, > Roberto >

Oct. 28, 2013

Re: [Pharo-dev] [Fuel] How to tell Fuel *not* to encode references?

by Martin Dias

I don't remember the previous discussion. When you tell fuel to serialize an object, it traverses the references of that object *to* other objects. By default, it uses some criteria to prune the traversal. For example, when the traversed object is a class, then it encodes the name of that class. Similar for a method. So I think in some way your object is referencing that problematic block closure. Maybe it can give you a clue if you put a halt in FLAnalysis>>trace: Maybe a "self haltIf: anObject isClosure" HTH, MartÃn On Mon, Oct 28, 2013 at 8:16 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Hi, > > Iâm struggling with Fuel and I probably discovered my problem. > > When trying to serialize an object (that represents a development session, > i.e., contains some meta-data (title, author, etc.) and some objects > representing actions of the developer) I often encounter problem with some > BlockClosureâs which are somewhat corrupt and Fuel crashes and cannot > serialize them. We already discussed this issue in this mailing list a > while ago with Max. > > I do not ask directly Fuel to serialize some BlockClosures, so my > intuition is that Fuel serializes all the references to the objects I am > trying to serialize. Am I right? Is there any way to tell Fuel not to do so? > > Cheers and thanks for the help, > Roberto >

Oct. 28, 2013

Re: [Pharo-dev] github repository documentation

by Camillo Bruni

On 2013-10-28, at 15:16, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, Oct 28, 2013 at 11:02 AM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> https://github.com/pharo-project/pharo-project-proposals >> https://github.com/pharo-project/pharo-ubuntu >> https://github.com/pharo-project/pharo-flyers > > > I will do it for these 3 nice :)

Oct. 28, 2013

Re: [Pharo-dev] missing updates: 30503 30504

by Camillo Bruni

On 2013-10-27, at 20:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > On Oct 27, 2013, at 6:18 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > >> Things got updated: >> >> The tracker job https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-1-Tracker/ has >> now a version number check + the recent pharo version allows the #update command line handler >> to detect if wrong update files were specified. Together with Stef's fix to always >> merge updates the update process should now be more stable. > Tx camillo. > > Pay attention that my change is to ignore conflict warning I am not fully sure about that, since there are two steps required: 1. MCMergeOrLoadWarning 2. MergeResolutionRequest >From what I got, you only deal with the first one, which asks the user if he wants to merge or not (which for instance in git never happens). The second one actually does the merging. I am pretty much convinced that we don't need the two of them, since I see that we basically spread the following code all over the place: [aLoadBlock on: MCMergeOrLoadWarning do: [ :request | request merge ]] on: MCMergeResolutionRequest do: [ :request | request autoMerge ]. The real merge conflict is only available in the MCMergeResolutionRequest, before it is a warning that is solely based on whether a package is dirty or not, a very crude approximation of a conflict...

Oct. 28, 2013