- Pharo-dev - lists.pharo.org

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

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