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

[Pharo-project] [update 2.0] #20452

by StÃ©phane Ducasse

Dec. 23, 2012

Re: [Pharo-project] A contorted way of making things work :)

by StÃ©phane Ducasse

>>> Yeah, blame and flame everyone who doesn't write code the way you do... >>> But before you do that, tell me what's wrong with that assignment. >> >> why do I always have the impression you're at extinction when I read >> an email from you? I know I can be very annoying as well :D but you > > If I understand correctly what you're trying to say, then the reason why I don't write mails here more often is because it's pointless. > >> should consider a friendlier tone ;) > > Do you think my question would have been answered if I were using a friendlier tone? I doubt it. > Do you think the mail I was replying to was friendlier than mine? I doubt it. Levente We do not consider you as a asshole or whatever. I personally always consider what you are writing with interest and you do not need to write it in a blunt way for that. I do not know why you think that sending emails here is pointless but this is not true. We value feedback, questions and remarks of people. My objective is to build an ecosystem where people can make business and invent their future, no more. Now for this exact point, morphic has some dark corners and we should address them one by one and we will. Now if certain invariants would be clear and respected the code would be in general much nicer. Stef

Dec. 23, 2012

Re: [Pharo-project] KeyChain/UsersManager

by StÃ©phane Ducasse

Yes In fact usman got interested by the package because we should deploy application to clients with restriction. Now we should rethink it if this is to be integrated in the image. Now one of the problem is that benjmain cannot manage it completely with a configuration because some code can only be applied using CS and this is this point that we should look at. Stef > Firstly we need to aswer on question how deep this mechanism should be > integrated with the kernel. If kernel should be able to work without > UsersManger, if Monticello and Metacello should be able to work > without UsersManager, if we should provide some basic minimal > UsersManager implementation etc. > > currently the have problems with this methods: > Author>>fullNamePerSe > Author>>fullName: > MCHttpRepository>>password > MCHttpRepository>>user > > -- Pavel > > On Sun, Dec 23, 2012 at 2:13 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> Yes we should unload it. >> Now I would like to know what are the hooks that we need in the kernel to support its smooth loading. >> >> Stef >> >> On Dec 23, 2012, at 1:48 PM, Pavel Krivanek wrote: >> >>> There is a lot of reasons why I think that the whole concept of >>> UsersManager is poor: >>> - direct dependency on cryptography packages >>> - there is only one current user. What about if more users is >>> connected to one image? >>> - users avatar as an ImageMorph! >>> - permissions do not reflect modular architecture. Why to have >>> permissions like canBrowse canDebug canEditCode canEvaluateCode >>> canInspect canShowMorphHalo for image that has now browser, no >>> debugger, no editor, no inspector, no compiler, no Morphic? >>> - in Smalltalk this permissions bring no real security >>> - UsersManager is not an abstract class >>> - everything is in one package >>> >>> Thanks to this addition in current state the Pharo Kernel is not able >>> to load Monticello packages and in most cases even start. We really >>> need to reject it for Pharo 2.0. >>> >>> Cheers, >>> -- Pavel >>> >>> On Thu, Dec 20, 2012 at 5:23 PM, StÃ©phane Ducasse >>> <stephane.ducasse(a)inria.fr> wrote: >>>> I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. >>>> Apparently ben add to provide a cs because some changes could not be applied via a slice. >>>> I planned to have a look but so far I did not find the time. >>>> >>>> >>>> >>>> On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote: >>>> >>>>> It broke following Pharo Kernel jobs because the image crashes when a >>>>> directory is changed. So how to fix that. We have several options: >>>>> - make simple ugly fix that will check presence of this class, it will >>>>> generate unimplemented calls >>>>> - remove it and add it back fixed in 3.0 >>>>> - rewrite the Author change mechanism to Announcements (in 3.0?) >>>>> What do you propose? >>>>> >>>>> -- Pavel >>>>> >>>>> On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>>> it was in the list of things to integrate :) >>>>>> but we should check to clean the dependence, because is not good. >>>>>> >>>>>> Esteban >>>>>> >>>>>> On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> 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? ;-) >>>>>>> >>>>>>> Cheers, >>>>>>> -- Pavel >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >

Dec. 23, 2012

Re: [Pharo-project] A contorted way of making things work :)

by Levente Uzonyi

On Sat, 22 Dec 2012, Camillo Bruni wrote: > > On 2012-12-22, at 09:56, Levente Uzonyi <leves(a)elte.hu> wrote: > >> On Sat, 22 Dec 2012, Fernando Olivero wrote: >> >>> Well, the assignment within the and: block says it allâ¦ >> >> Yeah, blame and flame everyone who doesn't write code the way you do... >> But before you do that, tell me what's wrong with that assignment. > > why do I always have the impression you're at extinction when I read > an email from you? I know I can be very annoying as well :D but you If I understand correctly what you're trying to say, then the reason why I don't write mails here more often is because it's pointless. > should consider a friendlier tone ;) Do you think my question would have been answered if I were using a friendlier tone? I doubt it. Do you think the mail I was replying to was friendlier than mine? I doubt it. Levente >

Dec. 23, 2012

Re: [Pharo-project] KeyChain/UsersManager

by Pavel Krivanek

Firstly we need to aswer on question how deep this mechanism should be integrated with the kernel. If kernel should be able to work without UsersManger, if Monticello and Metacello should be able to work without UsersManager, if we should provide some basic minimal UsersManager implementation etc. currently the have problems with this methods: Author>>fullNamePerSe Author>>fullName: MCHttpRepository>>password MCHttpRepository>>user -- Pavel On Sun, Dec 23, 2012 at 2:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes we should unload it. > Now I would like to know what are the hooks that we need in the kernel to support its smooth loading. > > Stef > > On Dec 23, 2012, at 1:48 PM, Pavel Krivanek wrote: > >> There is a lot of reasons why I think that the whole concept of >> UsersManager is poor: >> - direct dependency on cryptography packages >> - there is only one current user. What about if more users is >> connected to one image? >> - users avatar as an ImageMorph! >> - permissions do not reflect modular architecture. Why to have >> permissions like canBrowse canDebug canEditCode canEvaluateCode >> canInspect canShowMorphHalo for image that has now browser, no >> debugger, no editor, no inspector, no compiler, no Morphic? >> - in Smalltalk this permissions bring no real security >> - UsersManager is not an abstract class >> - everything is in one package >> >> Thanks to this addition in current state the Pharo Kernel is not able >> to load Monticello packages and in most cases even start. We really >> need to reject it for Pharo 2.0. >> >> Cheers, >> -- Pavel >> >> On Thu, Dec 20, 2012 at 5:23 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. >>> Apparently ben add to provide a cs because some changes could not be applied via a slice. >>> I planned to have a look but so far I did not find the time. >>> >>> >>> >>> On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote: >>> >>>> It broke following Pharo Kernel jobs because the image crashes when a >>>> directory is changed. So how to fix that. We have several options: >>>> - make simple ugly fix that will check presence of this class, it will >>>> generate unimplemented calls >>>> - remove it and add it back fixed in 3.0 >>>> - rewrite the Author change mechanism to Announcements (in 3.0?) >>>> What do you propose? >>>> >>>> -- Pavel >>>> >>>> On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>>> it was in the list of things to integrate :) >>>>> but we should check to clean the dependence, because is not good. >>>>> >>>>> Esteban >>>>> >>>>> On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> 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? ;-) >>>>>> >>>>>> Cheers, >>>>>> -- Pavel >>>>> >>>>> >>>> >>> >>> >> > >

Dec. 23, 2012

Re: [Pharo-project] KeyChain/UsersManager

by StÃ©phane Ducasse

Yes we should unload it. Now I would like to know what are the hooks that we need in the kernel to support its smooth loading. Stef On Dec 23, 2012, at 1:48 PM, Pavel Krivanek wrote: > There is a lot of reasons why I think that the whole concept of > UsersManager is poor: > - direct dependency on cryptography packages > - there is only one current user. What about if more users is > connected to one image? > - users avatar as an ImageMorph! > - permissions do not reflect modular architecture. Why to have > permissions like canBrowse canDebug canEditCode canEvaluateCode > canInspect canShowMorphHalo for image that has now browser, no > debugger, no editor, no inspector, no compiler, no Morphic? > - in Smalltalk this permissions bring no real security > - UsersManager is not an abstract class > - everything is in one package > > Thanks to this addition in current state the Pharo Kernel is not able > to load Monticello packages and in most cases even start. We really > need to reject it for Pharo 2.0. > > Cheers, > -- Pavel > > On Thu, Dec 20, 2012 at 5:23 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. >> Apparently ben add to provide a cs because some changes could not be applied via a slice. >> I planned to have a look but so far I did not find the time. >> >> >> >> On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote: >> >>> It broke following Pharo Kernel jobs because the image crashes when a >>> directory is changed. So how to fix that. We have several options: >>> - make simple ugly fix that will check presence of this class, it will >>> generate unimplemented calls >>> - remove it and add it back fixed in 3.0 >>> - rewrite the Author change mechanism to Announcements (in 3.0?) >>> What do you propose? >>> >>> -- Pavel >>> >>> On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> it was in the list of things to integrate :) >>>> but we should check to clean the dependence, because is not good. >>>> >>>> Esteban >>>> >>>> On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> 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? ;-) >>>>> >>>>> Cheers, >>>>> -- Pavel >>>> >>>> >>> >> >> >

Dec. 23, 2012

Re: [Pharo-project] KeyChain/UsersManager

by Pavel Krivanek

There is a lot of reasons why I think that the whole concept of UsersManager is poor: - direct dependency on cryptography packages - there is only one current user. What about if more users is connected to one image? - users avatar as an ImageMorph! - permissions do not reflect modular architecture. Why to have permissions like canBrowse canDebug canEditCode canEvaluateCode canInspect canShowMorphHalo for image that has now browser, no debugger, no editor, no inspector, no compiler, no Morphic? - in Smalltalk this permissions bring no real security - UsersManager is not an abstract class - everything is in one package Thanks to this addition in current state the Pharo Kernel is not able to load Monticello packages and in most cases even start. We really need to reject it for Pharo 2.0. Cheers, -- Pavel On Thu, Dec 20, 2012 at 5:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I think that we should remove the keyChain and it would be good that the system offers the right hooks so that keychain can be nicely added. > Apparently ben add to provide a cs because some changes could not be applied via a slice. > I planned to have a look but so far I did not find the time. > > > > On Dec 20, 2012, at 2:07 PM, Pavel Krivanek wrote: > >> It broke following Pharo Kernel jobs because the image crashes when a >> directory is changed. So how to fix that. We have several options: >> - make simple ugly fix that will check presence of this class, it will >> generate unimplemented calls >> - remove it and add it back fixed in 3.0 >> - rewrite the Author change mechanism to Announcements (in 3.0?) >> What do you propose? >> >> -- Pavel >> >> On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>> it was in the list of things to integrate :) >>> but we should check to clean the dependence, because is not good. >>> >>> Esteban >>> >>> On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> 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? ;-) >>>> >>>> Cheers, >>>> -- Pavel >>> >>> >> > >

Dec. 23, 2012

Re: [Pharo-project] Scripts-download job is broken

by Pavel Krivanek

I tried to remove any functionality from this job and it was not able to finish even in such configuration so I recreated that job and it seems to work well now. -- Pavel On Fri, Dec 21, 2012 at 2:33 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > hmm, while running from my machine, working well.. > > git clone git://gitorious.org/pharo-build/pharo-build.git > Cloning into 'pharo-build'... > remote: Counting objects: 4421, done. > remote: Compressing objects: 100% (1431/1431), done. > remote: Total 4421 (delta 3223), reused 4080 (delta 2967) > Receiving objects: 100% (4421/4421), 1.58 MiB | 1.12 MiB/s, done. > Resolving deltas: 100% (3223/3223), done. > > > On 21 December 2012 14:31, Igor Stasenko <siguctua(a)gmail.com> wrote: >> this is really strange.. >> >> i can only guess that there's something with git.. >> like waiting for user to type "yes" in console >> which hangs everything. >> >> On 21 December 2012 11:23, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> the Project Scripts-download job is broken on the new infrastructure, >>> it simply hangs without any sign it is doing something. It only should >>> clone pharo-build Gittorious repository. On the old infrastructure it >>> works (however the job is failing because of sources download) >>> Any idea? I tried to restrict it from "linux" to "linux64" and comment >>> the sources download but no change. >>> >>> Cheers, >>> -- Pavel >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. >

Dec. 23, 2012

[Pharo-project] [update 2.0] #20451

by Marcus Denker

20451 ----- Issue 7175: Manifest fixing http://code.google.com/p/pharo/issues/detail?id=7175 Issue 7172: CompiledMethod #getSource should call #sourceCode http://code.google.com/p/pharo/issues/detail?id=7172 Issue 7161: MCToolWindowBuilder is not used http://code.google.com/p/pharo/issues/detail?id=7161 Diff information: http://ss3.gemstone.com/ss/Pharo20/MonticelloGUI-MarcusDenker.202.diff http://ss3.gemstone.com/ss/Pharo20/Manifest-CriticBrowser-MarcusDenker.33.d… http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1277.diff

Dec. 23, 2012

Re: [Pharo-project] Favorite New Features

by Camillo Bruni

On 2012-12-15, at 08:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > On Dec 14, 2012, at 5:32 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> Hey guys, what are your favorite features added in 2.0? Please answer at >> http://code.google.com/p/pharo/wiki/ActionsInPharo20 >> >> There are so many improvements, I've definitely lost track. I remember there >> were some really useful shortcuts cami or ben showed me, something like >> cmd-click to browse class... done for my bits and pieces

Dec. 23, 2012