October 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About SqNumberParser

by Marcus Denker

On 28 Oct 2013, at 17:55, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > > On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> >>> So what we decide to do with this? >>> >>> I can work on that case, but I have 2 questions: >>> >>> - do we care to provide parsing of numbers in other notations as Pharo one? >> >> Thatâs a good question.. I completely misunderstood the code there because that sounds a bit >> strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦ >> >> I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel >> classesâ¦ > > There are 2 extremes here. If you want to parse a fortran number, you probably also want to parse other fortran parts, and so you have some dedicated parser. > But if you want to just parse some general number and itâs +2, then you canât easily do that. > >> >>> - what is the number syntax that we want to support? >>> >> Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation. > > I can levee the implementation that is used now (a sq one). Or use extended. But it should be really nice to think about what we want to have instead of what we can use. > If we have to decide, we should take the simple path. The fact that I am completely confused about this is not a good sign (maybe more related to my intelligenceâ¦ :-) Marcus

Oct. 28, 2013

Re: [Pharo-dev] About SqNumberParser

by Yuriy Tymchuk

On 28 Oct 2013, at 17:49, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > >> So what we decide to do with this? >> >> I can work on that case, but I have 2 questions: >> >> - do we care to provide parsing of numbers in other notations as Pharo one? > > Thatâs a good question.. I completely misunderstood the code there because that sounds a bit > strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦ > > I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel > classesâ¦ There are 2 extremes here. If you want to parse a fortran number, you probably also want to parse other fortran parts, and so you have some dedicated parser. But if you want to just parse some general number and itâs +2, then you canât easily do that. > >> - what is the number syntax that we want to support? >> > Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation. I can levee the implementation that is used now (a sq one). Or use extended. But it should be really nice to think about what we want to have instead of what we can use. Uko > > Marcus > >> Cheers! >> Uko >> >> On 19 Aug 2013, at 10:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> thanks! >>> >>> Stef >>> >>>> I think just because 1.0s was explicitely not supported in Squeak? >>>> There should be some related tests... >>>> It should be rather simple to change. >>>> >>>> >>>> 2013/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>>> Hi nicolas >>>> >>>> We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax >>>> marcus raised a question that I could not answer. >>>> Do you habve nfrmation to share with us so that we can take a decision? >>>> >>>> Stef >>>> >>>> >>>> so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s >>>> >>>> - do not allow single s without following digits as ScaledDecimal >>>> >>>> It is not explained why this is a good idea. >>>> >>>> In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now. >>>> >>> >> >

Oct. 28, 2013

inria ci problem - content encoding error when clicking 'new job' in JobTemplate page

by Paul DeBruicker

Hi - After logging in, when I visit this page: https://ci.inria.fr/pharo-contribution/view/all/newJob I get a 'content encoding error' and nothing is displayed in the browser. Is there another way to create a job? Thanks Paul

Oct. 28, 2013

Re: [Pharo-dev] About SqNumberParser

by Marcus Denker

On 28 Oct 2013, at 10:41, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > So what we decide to do with this? > > I can work on that case, but I have 2 questions: > > - do we care to provide parsing of numbers in other notations as Pharo one? Thatâs a good question.. I completely misunderstood the code there because that sounds a bit strange that a language supports other languages syntax, but not âinsideâ the language but somehow as a toolâ¦ I fear that even if someone needs Fotran number parsing, the last place to look would be the Pharo base kernel classes... > - what is the number syntax that we want to support? > Yes, we we need to document it. Right now it is âsome extended Squeak formatâ which is just defined by the implementation. Marcus > Cheers! > Uko > > On 19 Aug 2013, at 10:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> thanks! >> >> Stef >> >>> I think just because 1.0s was explicitely not supported in Squeak? >>> There should be some related tests... >>> It should be rather simple to change. >>> >>> >>> 2013/8/13 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >>> Hi nicolas >>> >>> We would really like to have only one number parser in Pharo as well as handling the 1.0s syntax >>> marcus raised a question that I could not answer. >>> Do you habve nfrmation to share with us so that we can take a decision? >>> >>> Stef >>> >>> >>> so the strange thing is that this is *explicitly* implemented in SqNumberParser to not allow 2.0s >>> >>> - do not allow single s without following digits as ScaledDecimal >>> >>> It is not explained why this is a good idea. >>> >>> In general, we need to merge the whole NumberParser hierarchy into one class, i don't understand why we have three classes now. >>> >> >

Oct. 28, 2013

Re: [Pharo-dev] Hungry Pharo

by Yuriy Tymchuk

Itâs not about the thing that it uses 5% CPU. Apple does some magic with optimisation so they group threads in order to reduce power usage. And Pharo is not good at that. Iâm not telling that Pharo is slow. Battery lasts longer with Safari compared to Chrome. Probably with Pharo itâs something similar. On 28 Oct 2013, at 17:31, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > 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 :) > > <Screenshot 2013-10-28 17.05.48.png> > > Cheers! > Uko > >

Oct. 28, 2013

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