December 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] KeyChain/UsersManager

by Damien Cassou

On Sat, Dec 15, 2012 at 2:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > what is the reason for integration of KeyChain/UsersManager to the image? It > created the next kernel dependency. Should it replace Author? Should it be > in the Pharo Kernel? And why there was no mention about it in this mailing > list before? ;-) I'm not sure what is KeyChain, but the name sounds familiar and makes the package very important as it might solve a critical problem: - how do you store Monticello/webservices/any application's passwords safely? To me KeyChain should provide an API to store and access any kind of credentials. This API could then delegate to the O.S. one. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Dec. 17, 2012

Re: [Pharo-project] Athens + Amber + HTML5 canvas

by Igor Stasenko

sounds nice :) On 17 December 2012 09:13, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Wed, Nov 28, 2012 at 11:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> Any takers? :) > > what do you think of this proposal: > > http://rmod.lille.inria.fr/web/pier/research/ProjectsProposal/Amber-html5-c… > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill -- Best regards, Igor Stasenko.

Dec. 17, 2012

Re: [Pharo-project] Could someone resuscitate the Google Groups mirror?

by Adrian Sampaleanu

Any idea who this is? -- View this message in context: http://forum.world.st/Could-someone-resuscitate-the-Google-Groups-mirror-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 17, 2012

Re: [Pharo-project] Athens + Amber + HTML5 canvas

by Damien Cassou

On Wed, Nov 28, 2012 at 11:30 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Any takers? :) what do you think of this proposal: http://rmod.lille.inria.fr/web/pier/research/ProjectsProposal/Amber-html5-c… -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Dec. 17, 2012

Re: [Pharo-project] CI down?

by Max Leske

I know, but I couldn't remember the address :p On 17.12.2012, at 00:45, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I repeat: Do not use the CI to download stuff from... > > Use our static file server: http://pharo.gforge.inria.fr/ci/ > > > ci jobs may change names and jenkins is too brittle to support heavy traffic! > > > On 2012-12-16, at 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Dec 16, 2012, at 5:24 PM, Max Leske wrote: >> >>> ah, thanks. >>> >>> I wanted to update the links on the pharo-project page but there's stuff missing (or I don't know where it is), e.g. the one-click build and the vm zips (from the dedicated download server). >> >> We should change everything. Now we are waiting that the inria service really open (currently in beta) and at the same time we saturated our disc space so we had to kill >> the old integration server. >> >> Stef > >

Dec. 17, 2012

Re: [Pharo-project] Interval protocol

by Frank Shearar

On 17 December 2012 07:28, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 16 December 2012 16:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> Beware, Range exists in other languages (python, etc..). >>> We should check if they correspond to a Smalltalk Interval or a >>> mathematical Interval. >>> If they correspond to a Smalltalk Interval, that will be one more >>> un-necessary trap. >>> >>> Note that we rarely use Interval, we just use #to: or #to:by:, so we >>> could as well rename Interval->Range. >>> And postpone creation of Mathematical Interval which is most likely >>> unused in kernel image. >> >> >> Why not? Now it would be good to move. >> but what I know is that igor wanted to have range intersection for the new text model. >> Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? >> I do not think so. We can check what is around and **improve** our nice system > > If you use Ruby for any length of time (and ignore most of the syntax) > you will quickly realise that Ruby _is_ Smalltalk in many fundamental > ways. It's just a pity Matz based its syntax on Perl (or so it seems). > Ruby = Smalltalk with rubbish syntax and awesome integration with > basic programmer tools and decent infrastructure. I should add: with that last clause I'm not trying to dismiss Pharo's and Squeak's massive improvement in infrastructure. It's just that it's nowhere near as slick as in Ruby. frank > frank > >> Stef >> >>> 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>>> I agree so we should introduce Range. >>>> Did not you or camillo started to have Range? >>>> It can be a really nice class. >>>> >>>> Stef >>>> On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: >>>> >>>>> So, to my sense a behavior of Interval is overloaded.. >>>>> it tries to be too many things at once: >>>>> - be an interval in math sense (which is infinite set if used for Real numbers) >>>>> - be a "collection" of numbers which you can enumerate (implies that >>>>> it is finite). >>>>> >>>>> to me, i would be much happier if we could have two different and >>>>> non-intersecting entities: >>>>> >>>>> - Enumeration. This one indeed can be used as a collection. i.e. >>>>> "give me all integer numbers lying between values A and B, count each >>>>> C-th number" >>>>> Like that, >>>>> (1 to: 1.5 by: 1) is enumeration which contains a single element. >>>>> and #last should be = 1 >>>>> >>>>> - Interval (Range). A pure interval in math sense: defines a Set of >>>>> numbers lying between numbers A and B, inclusive, where A <= B. Not >>>>> enumerable, therefore no 'step' variable, instead what it could have, >>>>> is flags to indicate whether interval endpoints included into interval >>>>> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >>>>> >>>>> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >>>>> however intersect, merge or diff two intervals etc.. same operations >>>>> which you doing on sets (but that would require another entity - >>>>> interval set). And of course, you can test whether some number lies >>>>> within given interval or not. >>>>> >>>>> The reason i started this topic is because some code were using >>>>> 'range' for variables which holding intervals.. >>>>> Now what you think is more appropriate protocol for something called >>>>> 'range', this: >>>>> >>>>> x := range first >>>>> y := range last >>>>> >>>>> or this: >>>>> >>>>> x := range start >>>>> y := range end >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>> >> >>

Dec. 17, 2012

Re: [Pharo-project] Interval protocol

by Frank Shearar

On 16 December 2012 16:51, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Beware, Range exists in other languages (python, etc..). >> We should check if they correspond to a Smalltalk Interval or a >> mathematical Interval. >> If they correspond to a Smalltalk Interval, that will be one more >> un-necessary trap. >> >> Note that we rarely use Interval, we just use #to: or #to:by:, so we >> could as well rename Interval->Range. >> And postpone creation of Mathematical Interval which is most likely >> unused in kernel image. > > > Why not? Now it would be good to move. > but what I know is that igor wanted to have range intersection for the new text model. > Another question: who thinks that ruby look at Smalltalk when they take a decision on their library? > I do not think so. We can check what is around and **improve** our nice system If you use Ruby for any length of time (and ignore most of the syntax) you will quickly realise that Ruby _is_ Smalltalk in many fundamental ways. It's just a pity Matz based its syntax on Perl (or so it seems). Ruby = Smalltalk with rubbish syntax and awesome integration with basic programmer tools and decent infrastructure. frank > Stef > >> 2012/12/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> I agree so we should introduce Range. >>> Did not you or camillo started to have Range? >>> It can be a really nice class. >>> >>> Stef >>> On Dec 16, 2012, at 4:55 PM, Igor Stasenko wrote: >>> >>>> So, to my sense a behavior of Interval is overloaded.. >>>> it tries to be too many things at once: >>>> - be an interval in math sense (which is infinite set if used for Real numbers) >>>> - be a "collection" of numbers which you can enumerate (implies that >>>> it is finite). >>>> >>>> to me, i would be much happier if we could have two different and >>>> non-intersecting entities: >>>> >>>> - Enumeration. This one indeed can be used as a collection. i.e. >>>> "give me all integer numbers lying between values A and B, count each >>>> C-th number" >>>> Like that, >>>> (1 to: 1.5 by: 1) is enumeration which contains a single element. >>>> and #last should be = 1 >>>> >>>> - Interval (Range). A pure interval in math sense: defines a Set of >>>> numbers lying between numbers A and B, inclusive, where A <= B. Not >>>> enumerable, therefore no 'step' variable, instead what it could have, >>>> is flags to indicate whether interval endpoints included into interval >>>> or not.. i.e. (a,b) vs [a,b] vs [a,b) vs (a,b]. >>>> >>>> Not supporting enumeration (no #do: , no #add: no #at: etc). You can, >>>> however intersect, merge or diff two intervals etc.. same operations >>>> which you doing on sets (but that would require another entity - >>>> interval set). And of course, you can test whether some number lies >>>> within given interval or not. >>>> >>>> The reason i started this topic is because some code were using >>>> 'range' for variables which holding intervals.. >>>> Now what you think is more appropriate protocol for something called >>>> 'range', this: >>>> >>>> x := range first >>>> y := range last >>>> >>>> or this: >>>> >>>> x := range start >>>> y := range end >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >> > >

Dec. 17, 2012

Re: [Pharo-project] CI down?

by Jimmie Houchin

On 12/16/2012 5:45 PM, Camillo Bruni wrote: > I repeat: Do not use the CI to download stuff from... > > Use our static file server: http://pharo.gforge.inria.fr/ci/ > > ci jobs may change names and jenkins is too brittle to support heavy traffic! I think the easiest way to encourage this would be to change the website to point to the latest stable version of each of the images and vms. And reduce the links to the ci server to the server itself and never to any jobs or artifacts on it. Let the only links to jobs or artifacts on the ci server come from the ci server and not the Pharo website. Its a shame that there is not a CI app in Pharo as opposed to Java/Jenkins. Maybe someday. Jimmie

Dec. 17, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Camillo Bruni

so for all those who still want "FileDirectory" semantics available, you can load the FileSystem-Compatibility package from here: http://smalltalkhub.com/#!/~dh83/fisleg/packages/FileSystem-Legacy I think we should provide a configuration and add it to the MetacelloRepository. And btw, there is your backward-compatiblity. Except for some weird Mac-specific file-type stuff that is currently missing from FileSystem everything works without changing a single line of code. so that invalidates the whole thread IMO.

Dec. 17, 2012

Re: [Pharo-project] CI down?

by Camillo Bruni

I repeat: Do not use the CI to download stuff from... Use our static file server: http://pharo.gforge.inria.fr/ci/ ci jobs may change names and jenkins is too brittle to support heavy traffic! On 2012-12-16, at 13:57, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On Dec 16, 2012, at 5:24 PM, Max Leske wrote: > >> ah, thanks. >> >> I wanted to update the links on the pharo-project page but there's stuff missing (or I don't know where it is), e.g. the one-click build and the vm zips (from the dedicated download server). > > We should change everything. Now we are waiting that the inria service really open (currently in beta) and at the same time we saturated our disc space so we had to kill > the old integration server. > > Stef

Dec. 16, 2012