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

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

by Mariano Martinez Peck

Indeed, I think I agree with Max. You can also use the substitute feature and replace the instVars you don't want with nil or something...See the doc link Martin sent. On Mon, Oct 28, 2013 at 7:00 PM, Max Leske <maxleske(a)gmail.com> wrote: > In my opinion the #fuelAccept: for the meta description object should be > overridden and there the behaviour for problematic references should be > defined. > > Roberto, what references does your meta object hold on to? > > Max > > > On 28.10.2013, at 22:16, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > > On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli(a)usi.ch < > roberto.minelli(a)usi.ch> wrote: > >> 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â¦ >> > > Still there is something that I don't understand in your problem. If you > just prune the graph, what your objects represent (conceptually) can be > lost. Did you pick one of your problematic "session objects" are explored > it until find how the unwanted block closures are referenced? I mean, fuel > doesn't invent the unwanted closures magically, you are saying to fuel to > serialize the graph with the unwanted objects already there. > > >> >> 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? >> > >> > >> >> >> > > -- Mariano http://marianopeck.wordpress.com

Oct. 28, 2013

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

by Max Leske

In my opinion the #fuelAccept: for the meta description object should be overridden and there the behaviour for problematic references should be defined. Roberto, what references does your meta object hold on to? Max On 28.10.2013, at 22:16, Martin Dias <tinchodias(a)gmail.com> wrote: > > > > On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: > 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â¦ > > Still there is something that I don't understand in your problem. If you just prune the graph, what your objects represent (conceptually) can be lost. Did you pick one of your problematic "session objects" are explored it until find how the unwanted block closures are referenced? I mean, fuel doesn't invent the unwanted closures magically, you are saying to fuel to serialize the graph with the unwanted objects already there. > > > 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

Re: [Pharo-dev] SmalltalkHub red

by Nicolas Petton

Yes, we need to look at this issue. I'll do that when I'll be back from Argentina in a week or so. Nico Manfred KrÃ¶hnert writes: > Hi everyone, > > are there any news on this issue? > I tried to load SmalltalkHub into a new Pharo 2.0 image yesterday and was > hit by this. > > Best, > Manfred > > > > > On Wed, Oct 9, 2013 at 9:33 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> Yes, running the Grease/Seaside tests works fine. But, you will only see >> the "packages" problems when you do something with packages. So you will >> have to trigger RPackage tests to notice the issue. >> >> After all, you spotted the issue by running the Pharo regression tests >> after loading Moose/Grease/Seaside. >> >> Doru >> >> >> On Wed, Oct 9, 2013 at 9:28 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: >> >>> so is seaside: https://ci.inria.fr/pharo-contribution/job/Seaside/ >>> >>> On 2013-10-09, at 17:48, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> > On Wed, Oct 9, 2013 at 4:47 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> >>> wrote: >>> >> Do you know who is working with grease? It doesn't sound too hard to >>> solve this. >>> > >>> > >>> > and Grease seems to be ok: >>> https://ci.inria.fr/pharo-contribution/job/Grease/ >>> >>> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> -- Nicolas Petton http://nicolas-petton.fr

Oct. 28, 2013

Re: [Pharo-dev] About SqNumberParser

by Chris Cunningham

I just used the parsing of a number like this: -1.2e+3 just a scant 15 minutes ago, so I appreciate the support. -cbc On Mon, Oct 28, 2013 at 11:46 AM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Concerning FORTRAN, I think it was removed for a long time, it was just an > example of how the NumberParser could be used. > Concerning the ExtendedNumberParser, I find it useful to have it, because > it can parse inputs like: > +1.4 > -1.2e+3 > .005 > 127.e6 > A lot of languages/applications around the world would accept these as > valid Number. > Smalltalk syntax is much stricter... > > OK, it's just a DSL, and it could as well be implemented by other means... > Whether such DSL implementation belongs to NumberParser hierarchy or not, > is a choice that was guided by 2 things > - NumberParser provides an implementation that will correctly round the > number to nearest Float (or ScaledDecimal eventually) > I've seen too many Smalltalk implementations departing from universal > standards with this respect (IOW, wrong) > - NumerParser tries to be efficient (as far as Smalltalk can be), > especially in the cases with many digits > The first point is mandatory. > The second is just an optimization. > > Now that you have more insight about rationale which guided those > decisions, it's up to you :) > > Cheers > > Nicolas > > > > 2013/10/28 Marcus Denker <marcus.denker(a)inria.fr> > >> >> 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] [Fuel] How to tell Fuel *not* to encode references?

by Martin Dias

On Mon, Oct 28, 2013 at 5:13 PM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > 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â¦ > Still there is something that I don't understand in your problem. If you just prune the graph, what your objects represent (conceptually) can be lost. Did you pick one of your problematic "session objects" are explored it until find how the unwanted block closures are referenced? I mean, fuel doesn't invent the unwanted closures magically, you are saying to fuel to serialize the graph with the unwanted objects already there. > > 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

Re: [Pharo-dev] Url deprecated

by Sven Van Caekenberghe

Hi Thierry, On 28 Oct 2013, at 11:31, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Le 28/10/2013 11:18, Sven Van Caekenberghe a Ã©crit : >> Thierry, >> >> ZnUrl now implements #mcRepositoryAsUser:withPassword: though it is currently a hack. >> Do you have a suggestion how to make it extendable ? >> I will think about it as well, I do have some ideas. > > Well, I would just move the schemeName on the repository class and add a fromUrl:asUser:withPassword: in the repository instance creation, and change the mcRepositoryAsUser:withPassword: to search among repository types based on the scheme in the url and dispatch with a call to fromUrl:asUser:withPassword: on the right repository class. Sounds like an excellent idea/design. The dispatching/searching could be done on all subclasses of MCRepository, maybe using a more general #handlesUrl: method that for now just says ^ url scheme = #http but is general enough for potential special cases in the future. Having an instanciation class method on MCRepository subclasses like #fromUrl: would then do the actual action. The fact that username/password are passed as arguments while they could be part of the url is strange, but maybe necessary since you might not want them in the url proper - but the url can be freely manipulated (like safeUrl := url copy; username: nil; password: nil; yourself). Now, your idea solves the problem entirely external to ZnUrl itself, maybe it will hinder portability of Monticello itself (but the version in Pharo is probably customised anyway) ? My idea was to have some kind of global registry for actions to be performed on ZnUrl, the arguments being the url, an operation name, and an optional argument, ZnUrl>>#performOperation:withArgs: - To register a handler you specify a selection block, ZnUrl class>>#registerOperationWhen:do: For example, there is currently ZnUrl>>#resolve which should work differently on file urls. ZnUrl>>#resolve ^ self performOperation: #resolve withArgs: nil ZnUrl registerOperationWhen: [ :url :operation :args | (url scheme = #http | url scheme = #https) & operation = #resolve ] do: [ :url :args | ZnClient new beOneShot; enforceHttpSuccess: true; get: self ]. ZnUrl registerOperationWhen: [ :url :operation :args | url scheme = #file | operation = #resolve ] do: [ :url :args | url asFileReference contents ]. #performOperation:with: would search for a handler whose condition block matches and then execute it. But I am not 100% sure about this idea myself ;-) It is extendable but is require registration which can be a bit brittle. Sven > Thierry > >> Sven >> >> On 28 Oct 2013, at 11:18, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: >> >>> Hi All, >>> >>> Url has been deprecated. What is to be done with the Monticello use of the subclasses of Url? >>> >>> At the moment, ZnUrl has a hardcoded case switch to redirect on the right type of repository [1], but... It's not extendable, and breaks gitfiletree://. >>> >>> [1] https://github.com/pharo-project/pharo-core/blob/e89b4ac70d5cef761667317d58… >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> >> >> >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Oct. 28, 2013

Re: [Pharo-dev] About SqNumberParser

by Yuriy Tymchuk

On 28 Oct 2013, at 17:59, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > 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â¦ :-) I think that Iâll follow newt plan: - leave only the one clues that is currently used - write down the syntax that is provided - then one can think about what is odd and what is missing - improve parser if needed Uko > > Marcus

Oct. 28, 2013

Re: [Pharo-dev] About SqNumberParser

by Nicolas Cellier

Concerning FORTRAN, I think it was removed for a long time, it was just an example of how the NumberParser could be used. Concerning the ExtendedNumberParser, I find it useful to have it, because it can parse inputs like: +1.4 -1.2e+3 .005 127.e6 A lot of languages/applications around the world would accept these as valid Number. Smalltalk syntax is much stricter... OK, it's just a DSL, and it could as well be implemented by other means... Whether such DSL implementation belongs to NumberParser hierarchy or not, is a choice that was guided by 2 things - NumberParser provides an implementation that will correctly round the number to nearest Float (or ScaledDecimal eventually) I've seen too many Smalltalk implementations departing from universal standards with this respect (IOW, wrong) - NumerParser tries to be efficient (as far as Smalltalk can be), especially in the cases with many digits The first point is mandatory. The second is just an optimization. Now that you have more insight about rationale which guided those decisions, it's up to you :) Cheers Nicolas 2013/10/28 Marcus Denker <marcus.denker(a)inria.fr> > > 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] Hungry Pharo

by Sven Van Caekenberghe

There was already a discussion about this, search for the subject 'Pharo on Mac OS X 10.9 Mavericksâ. On 28 Oct 2013, at 18:37, Thomas Kendelbacher <tkendel(a)me.com> wrote: > A greater than, say, 1% base CPU load from an otherwise idle application would indicate that it's doing some busy waiting somewhere... in my Activity Monitor, I don't see too many processes doing that, so just using an ObjC framework doesn't seem to be the guilty part. By the way, very old versions of VisualWorks used to be bad in that way, but not any more; so there is something that can be done about it. > > A large virtual memory working set wouldn't help either for power efficiency, though with today's RAM sizes it's probably less important. > > On Oct 28, 2013, at 11:46, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: >> 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 Thomas Kendelbacher

A greater than, say, 1% base CPU load from an otherwise idle application would indicate that it's doing some busy waiting somewhere... in my Activity Monitor, I don't see too many processes doing that, so just using an ObjC framework doesn't seem to be the guilty part. By the way, very old versions of VisualWorks used to be bad in that way, but not any more; so there is something that can be done about it. A large virtual memory working set wouldn't help either for power efficiency, though with today's RAM sizes it's probably less important. On Oct 28, 2013, at 11:46, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > 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