- Pharo-dev - lists.pharo.org

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

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

by Eliot Miranda

On Sat, Dec 15, 2012 at 3:42 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > H. Hirzel wrote > > As Chris points out, the difference is minimal. > > > > Sean, it looks like you need better examples to show how you perceive > > the benefits of the FileSystem design > > While you ignored the point of my followup post, which is that beauty and > simplicity lead to more than the sum of a few keywords, here are a few > basic > examples... > > Example #1: > file := FileDirectory directoryEntryFor: '/path/to/file'. > FileDirectory extensionFor: file name. > > vs. > > file2 := '/path/to/file' asFileReference. > file2 extension. > > #2: > (FileDirectory on: 'path') entryAt: 'nohup.out'. > vs. > 'path' asFileReference / 'filename' > > "Most operations routed through one massive FD class" vs. "immediate access > to the domain object you want"; not to mention the appreciated absence of > parens. > > No difference?? > > But with String methods for *FileSystem-utilities / aPath ^self asFileReference / aPath you get 'path' / 'filename' and that's *really* nice. Does anyone think that '123' / '45' is good?? This is a compromise: / arg self size = 0 ifTrue: [self error: 'cannot coerce the empty string]. ^('+-01234456789' incudes: self first) ifTrue: [arg adaptToString: self andSend: #/] ifFalse: [self asFileReference / arg] the issue here being whether FileSystem wants '.profile' or '.hg' et al or math wants '.123'. If FileSystem provides path-name checking then the above could include a specific legality check instead of the naive discrimination. Personally I find the prospect of a concise file scripting api much more appealing than lazy numeric conversion. The absence of the former is why so much of my life involves bash scripts. The latter isn't necessary if one starts off with numbers in the first place, and being literals they're as easy, no, easier than denoting numbers using strings (1 + 1 is shorter than '1' + 1). I hope Squeak integrates FileSystem in 4.4 for 4.5. -- best, Eliot

Dec. 22, 2012

[Pharo-project] [update 2.0] #20450

by Marcus Denker

20450 ----- Issue 7162: clean dead code Form/DisplayObject/Quadrangle http://code.google.com/p/pharo/issues/detail?id=7162 Issue 7168: Newlis>>listForSearching has undeclared var getItemAtIndexSelector http://code.google.com/p/pharo/issues/detail?id=7168 Issue 7166: CompiledMethod>>#getSource should be #sourceCode http://code.google.com/p/pharo/issues/detail?id=7166& Issue 7165: CleanUp MethodChangeRecord (part 1) http://code.google.com/p/pharo/issues/detail?id=7165 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Changes-MarcusDenker.194.diff http://ss3.gemstone.com/ss/Pharo20/NewList-MarcusDenker.14.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1275.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.101.diff http://ss3.gemstone.com/ss/Pharo20/FuelMetalevelTests-MarcusDenker.52.diff http://ss3.gemstone.com/ss/Pharo20/FuelMetalevel-MarcusDenker.62.diff

Dec. 22, 2012

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

by StÃ©phane Ducasse

On Dec 22, 2012, at 2:44 PM, Igor Stasenko wrote: > On 22 December 2012 14:34, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> What I love is the impact of not having cool invariant. >> Imagine a world where every morph would have a owner, suddenly the logic of morphic >> would be cut by two :) >> > > Well, for some morphs, nil is the only owner which they deserve to have :) lol :) Indeed :) Stef

Dec. 22, 2012