- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ensureCreateDirectory?

by Norbert Hartl

Am 25.10.2013 um 10:11 schrieb Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > So action=create object=directory > you want to be sure that you create a directory? > What if it already exists? > Since you want to be sure to create, will you erase and re-create? > You see the kind of misunderstanding this could create... > IOW, self ensureCreateMisunderstanding > +1 I didnât like it in the first place. It is just confusing. And probably an example how hard it can be if two or more non-native speaker try to find something that makes sense. Norbert > > 2013/10/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Consistency > ensureActionObject > > ensureCreateDirectory > ensureCreateFile > > We discuss a lot with camillo when we did it and I think that this is good right now. > > > Out of curiosity, what was the motivation behind Issue 10924: Simplifying > > ensure* and create protocol? > > > > For me #ensureCreateDirectory is less intention revealing than > > #ensureDirectory because the "ensure" means "create only if necessary", not > > "definitely create" a directory. What am I missing? Thanks. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/ensureCreateDirectory-tp4716925.html > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > >

Oct. 25, 2013

Re: [Pharo-dev] ensureCreateDirectory?

by Nicolas Cellier

So action=create object=directory you want to be sure that you create a directory? What if it already exists? Since you want to be sure to create, will you erase and re-create? You see the kind of misunderstanding this could create... IOW, self ensureCreateMisunderstanding 2013/10/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Consistency > ensureActionObject > > ensureCreateDirectory > ensureCreateFile > > We discuss a lot with camillo when we did it and I think that this is good > right now. > > > Out of curiosity, what was the motivation behind Issue 10924: Simplifying > > ensure* and create protocol? > > > > For me #ensureCreateDirectory is less intention revealing than > > #ensureDirectory because the "ensure" means "create only if necessary", > not > > "definitely create" a directory. What am I missing? Thanks. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: > http://forum.world.st/ensureCreateDirectory-tp4716925.html > > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > > > >

Oct. 25, 2013

Re: [Pharo-dev] UpdatingMenuMorph

by Camille Teruel

On 25 oct. 2013, at 09:50, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I was only use in stupid halos and the code is not really good. > Now if somebody does a pass on it we could readd it to the basis. (right now I just put it back for the sound package - but the sound package shows it agesâ¦ the code looks strange). > > floatPrecisionForDecimalPlaces: places > "Answer the floatPrecision that corresponds to the given number of decimal places" > > ^ places caseOf: > {[0]->[1] . > [1]->[0.1] . > [2]->[0.01] . > [3]->[0.001] . > [4]->[0.0001] . > [5]->[0.00001] . > [6]->[0.000001] . > [7]->[0.0000001] . > [8]->[0.00000001] . > [9]->[0.000000001]} > otherwise: > [(10.0 raisedTo: places negated) asFloat] Ha yes, I remember this one :D ! > > " > (0 to: 6) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] > (-10 to: 20) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] > " > > like decimalPlaces: > > valueFromContents > "Return a new value from the current contents string." > > format = #symbol ifTrue: [^ lastValue]. > format = #string ifTrue: [^ contents]. > ^ self class evaluatorClass evaluate: contents > > setPrecision > "Allow the user to specify a number of decimal places. This UI is > invoked from a menu. Nowadays the precision can be set by simple > type-in, making this menu approach mostly obsolete. However, it's > still useful for read-only readouts, where type-in is not allowed." > | aMenu | > aMenu := UIManager default > newMenuIn: self for: self. > aMenu > addTitle: ('How many decimal places? (currently {1})' translated format: {self decimalPlaces}). > 0 > to: 5 > do: [:places | aMenu > add: places asString > target: self > selector: #setDecimalPlaces: > argument: places]. > aMenu popUpInWorld > > > > > >> >> On 24 oct. 2013, at 22:07, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >>> What happened to it and why? I'm porting TWM to 3.0 and didn't find any >>> mention of removal on the dev or issue mailing list... Thanks. >> >> It was removed in 30507. >> The decision to remove it has been made during the august sprint. >> I just remember that I did the job. >> Does someone remember why? >> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/UpdatingMenuMorph-tp4716928.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >>> >> >

Oct. 25, 2013

Re: [Pharo-dev] UpdatingMenuMorph

by StÃ©phane Ducasse

I was only use in stupid halos and the code is not really good. Now if somebody does a pass on it we could readd it to the basis. (right now I just put it back for the sound package - but the sound package shows it agesâ¦ the code looks strange). floatPrecisionForDecimalPlaces: places "Answer the floatPrecision that corresponds to the given number of decimal places" ^ places caseOf: {[0]->[1] . [1]->[0.1] . [2]->[0.01] . [3]->[0.001] . [4]->[0.0001] . [5]->[0.00001] . [6]->[0.000001] . [7]->[0.0000001] . [8]->[0.00000001] . [9]->[0.000000001]} otherwise: [(10.0 raisedTo: places negated) asFloat] " (0 to: 6) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] (-10 to: 20) collect: [:i | Utilities floatPrecisionForDecimalPlaces: i] " like decimalPlaces: valueFromContents "Return a new value from the current contents string." format = #symbol ifTrue: [^ lastValue]. format = #string ifTrue: [^ contents]. ^ self class evaluatorClass evaluate: contents setPrecision "Allow the user to specify a number of decimal places. This UI is invoked from a menu. Nowadays the precision can be set by simple type-in, making this menu approach mostly obsolete. However, it's still useful for read-only readouts, where type-in is not allowed." | aMenu | aMenu := UIManager default newMenuIn: self for: self. aMenu addTitle: ('How many decimal places? (currently {1})' translated format: {self decimalPlaces}). 0 to: 5 do: [:places | aMenu add: places asString target: self selector: #setDecimalPlaces: argument: places]. aMenu popUpInWorld > > On 24 oct. 2013, at 22:07, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> What happened to it and why? I'm porting TWM to 3.0 and didn't find any >> mention of removal on the dev or issue mailing list... Thanks. > > It was removed in 30507. > The decision to remove it has been made during the august sprint. > I just remember that I did the job. > Does someone remember why? > >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/UpdatingMenuMorph-tp4716928.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> >

Oct. 25, 2013

Re: [Pharo-dev] ensureCreateDirectory?

by StÃ©phane Ducasse

Consistency ensureActionObject ensureCreateDirectory ensureCreateFile We discuss a lot with camillo when we did it and I think that this is good right now. > Out of curiosity, what was the motivation behind Issue 10924: Simplifying > ensure* and create protocol? > > For me #ensureCreateDirectory is less intention revealing than > #ensureDirectory because the "ensure" means "create only if necessary", not > "definitely create" a directory. What am I missing? Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/ensureCreateDirectory-tp4716925.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Oct. 25, 2013

Re: [Pharo-dev] Use #shouldnt:raise: only with specific errors, or evaluate the given expression directly

by StÃ©phane Ducasse

> <rant> > It's part of the Pharo manifesto: "Not backward compatible" > </rant> Levente I hope that writing this little pun created some jubilation to you. Or I do not understand your point. But this is ok for me. If pun on Pharo helps you then this is ok and they make me smile, and I'm serious If I can laugh from them this is that I should be quite strong no? We are all committed to build a robust and clean system that people can use to create their own wealth and feed their family. We are making HUGE progress. I mean REALLY HUGE and the space it opens is LARGE. It is not easy but people like marcus, sven, esteban, igor, camillo and many many others are dedicated to that goal. All the rest does not matter :) I'm just sad that other smart people do not understand that we want to create a future to everybody not just a bunch of fun programmers else we would only focus on what is fun and exciting for us. Writing a new text editor is not what really makes igor having real fun but he does it because this is needed for y-our future. Same for esteban, removing Package info or improving our VM is not the most exciting topics but he does it and I thank them for that. Stef

Oct. 25, 2013

Re: [Pharo-dev] Startup Preferences: An Alternative

by StÃ©phane Ducasse

this is what I do for the PharoTopics :) On Oct 24, 2013, at 4:17 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 23 October 2013 20:21, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > This is really cool, is that in the image already ? > What about plain HTTP repos ? > > > indeed, what could be simpler than: > > Compiler evaluate: (ZnEasy get: 'http://my.url.with.script.st') > > and you can, of course place it on github, if you need version control, like: > > https://raw.github.com/pharo-project/pharo-vm/master/codegen-scripts/LoadVM… > > > On 23 Oct 2013, at 20:04, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > philippeback wrote > >> Would be great to have a logout, in order to give images to other people > >> without leaving credentials around. > > > > Done, added to world menu under the individual repo login options > > > > The way the logins work is that a file named .mcconfig is expected in the > > general preferences folder with the format: > > > > [squeaksource] > > user := 'me'. > > password := 'pwd'. > > [squeaksource3] > > user := 'me'. > > password = 'pwd'. > > [smalltalkhub] > > user := 'me'. > > password := 'pwd'. > > > > > > > > ----- > > Cheers, > > Sean > > -- > > View this message in context: http://forum.world.st/Startup-Preferences-An-Alternative-tp4713968p4716686.… > > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > > > > > > > -- > Best regards, > Igor Stasenko.

Oct. 25, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by StÃ©phane Ducasse

> > With respect to Seaside (and its cross-platform-ness), this is probably a good decision, for now. > > But it is fundamentally unfair to call this an arbitrary unimportant change meant to annoy people. On the contrary ! I even think that there are too many methods in TAssertable and the #shouldnt: checks are very confusing and are candidates for removal, IMHO. Too much unnecessary code is not good in the long run. > > Have you ever written a #shouldnt: test ? I have never done so ! > > I took a Seaside image and looked at the senders of #shouldnt: and friends. There are that many from Seaside and I havenât seen any good example that could not be written otherwise. > > My 2c. They are important :) Would be good to make a pass on TAssertable too. I will add a discussion and a big warning in the SUnit Chapter for the next release of the PBE. Because Camillo is right. shouldnt:raise: Error should not be used. Stef

Oct. 25, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by StÃ©phane Ducasse

tx! On Oct 24, 2013, at 1:55 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > From the comments I think we can agree that it is a better to have a lint rule > instead of breaking things the way it was introduced by the original issue #11876. > > I therefore opened an issue > https://pharo.fogbugz.com/f/cases/11989/shouldnt-raise-Error-from-issue-118… > and uploaded a slice > > SLICE-Issue-11989-shouldntraise-Error-from-issue-11876-is-too-offensive-TorstenBergmann.1 > > to Pharo30Inbox on STHub (http://smalltalkhub.com/mc/Pharo/Pharo30Inbox/main) that > removed #validateShouldntException: > > I used a fresh 3.0 image (Pharo3.0 Latest update: #30519) > > Please test so it can be integrated and we can continue to focus on more interesting stuff. > > Thanks > Torsten > > >

Oct. 25, 2013

Re: [Pharo-dev] Issue #11876 (Do not allow shouldnt:raise: Error) and Seaside dev. on Pharo 3.0

by StÃ©phane Ducasse

>>> >> >> yes, people are not willing to change code all the timeâ¦ > > We are willing to change the code where there is a clear benefit. For example it's hard to argue that the new filesystem is an improvement over FileDirectory. We have a partically working Spec based UI for the servers. We would happily change the walkback to a new context API should it fix the bugs in the existing one. However this isn't the case with this change. To sole and only purpose of this change is to break code. This is what annoys me. don't worry we understand :) We are building real applications too for real clients too :) This is a one line change and we will revert it. Stef > > Cheers > Philippe > > >

Oct. 25, 2013