- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] block brace alignment (Re: feedback from J Brant)

by Peter UhnÃ¡k

> > self xxx > ifTrue: [ self bla. > self foo I don't like this very much because equivalent messages are formatted differently (they are not aligned). Now when you introduce block parameters, which everybody so far (Kent's book included) has ignored, it suddenly makes more sense to leave the first row empty. self xxx ifTrue: [ :param | self nicely. self aligned. ] Also the examples in the book seem to be picked to fit the rectangle criteria: ifTrue: [ [self clearCaches. self recomputeAngle] ifTrue: [ [self at: each put: 0] they both fit into a rectangle with a reason quite nicely. But if I pick [:each | aShape sendCommandAt: each; to: self] or a block which is very top heavy (long methods at top, short at bottom) I can hardly consider the bottom bracket as corner of a rectangle. But why not add a new option to the formatter to fit your criteria? (Btw I would love to have what IDEs often have -- code preview next to it to which all the options are being applied as you select it.) Peter On Thu, Sep 3, 2015 at 11:01 AM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > I also code in the same way as Svenâs example. For more advanced things, > why not to have: > > self xxx > ifTrue: > [ self bla. > self foo > > or > > self xxx > ifTrue: [ self bla. > self foo > > this are the interesting things to me. I guess I should read Kent Beck's > formatting rules :) but one more thing that I like to have is > > anObject > a: param1; > cascading: param2; > message: param3; > formatted: param4 > > Although there are some issues around it. > > Uko > > On 03 Sep 2015, at 07:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > And what happened to the plain normal (in my mind/experience) ? > > self xxx > ifTrue: [ > self bla. > self foo ]. > > I would say that is the most common one I've seen in the image. And it is > how the old formatter worked. > > On 03 Sep 2015, at 03:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > Hi Ben, > > have you read Kent Beck's formatting rules? I wish we would adhere to > these in our formatters. And I wish he would put the formatting rules in > the public domain on the web (Kent?). He actually justifies the rules he > chooses; they're not just personal preferences. And IMO they produce > eleant, readable Smalltalk. I have to say your block formatting below is > horrible. Blocks are blocks. [ & ] are /not/ the same as { & } in C. > [...] define an *object*, not merely delimit syntax. As such any good > Smalltalk format will emphasize the objectness of blocks. And IMNERHO that > is to make them rectangles as in > > self ifIWantedYouToWriteC ifTrue: > [self useABloodyCCompiler. > self useCCMinusPToMakeSenseOfTheDamageDoneByTheCPreProcessor] > > > On Wed, Sep 2, 2015 at 6:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Thu, Sep 3, 2015 at 2:28 AM, stepharo <stepharo(a)free.fr> wrote: > > > I do not really like all the formattings of kent. Because sometimes it just > does not work. > But this is why we ask franck (an interns to start to have a look). > > For example I do not like > > self xxx > ifTrue: > [ > self bla > self foo. > > > Agreed. Unneccessary waste of a line. > > in the current default formatter. > and I prefer > > self xxx > ifTrue: [ self bla. > self foo > But here the problem is that the self foo is not tab aligned because > ifTrue: [ > > self xxx > ifTrue: > [ self bla. > self foo > So may be this one is a nice compromise > > > Not quite there. The "self bla" is still not actually vertically aligned. > > I think that we should change some settings. In fact in alpha things are > there to evolve until the release :) > > > I like... > self xxx > ifTrue: > [ self bla. > self foo. > ]. > > for three reasons: > * the first statement of the block is vertically aligned with the rest > * vertical alignment of paired brackets makes visual matching *simple* > * the vertical whitespace enforced by the closing bracket on its > own visually groups blocks. > > Now some people don't like the closing brace on its own because they > prefer code density. So maybe this... > > self xxx > ifTrue: > [ self bla. > self foo. ] > ifFalse: > [ self baa. > self moo. ]. > > But still I prefer... > > self xxx > ifTrue: > [ self bla. > self foo. > ] > ifFalse: > [ self baa. > self moo. > ]. > > cheers -ben > > > > > -- > _,,,^..^,,,_ > best, Eliot > > > > >

Sept. 3, 2015

Looking for a way to build SQL query

by stepharo

Hi guys I'm looking for a lib that I can use to build sql queries instead of manipulating strings. ROE? Stef

Sept. 3, 2015

Re: [Pharo-dev] Removing name from Object

by Sven Van Caekenberghe

I am reviving the following (old) case: https://pharo.fogbugz.com/f/cases/7241/Object-name-should-best-be-removed I will add some more comments there. Sven > On 02 Sep 2015, at 13:53, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > EstebanLM wrote >> deprecate it like any other method change or removal? (And then remove it >> in Pharo 6) >> >> +1 >> thatâs the way to do it :) > > +1. I'm glad we're finally getting around to this :) > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Removing-name-from-Object-tp4847514p4847641.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by Peter UhnÃ¡k

> > The new, large size, makes it a very scary tool. That many packages? That > many repositories? > Pharo 4 image has just 2 external repos (Pharo + PharoInbox), Pharo 5 has 19 fucking repositories. I don't want to generalize, but how often does an end user care about any of them? For example the only time I interact with Pharo or PharoInbox is when I am fixing issues and I do that from clean image. So my proposal: Why not hide them? There could be a checkbox "[ ] Show system repositories" (default unchecked). That way the window can be much much smaller and users will see what is important for them. Peter

Sept. 3, 2015

Re: [Pharo-dev] block brace alignment (Re: feedback from J Brant)

by Yuriy Tymchuk

I also code in the same way as Svenâs example. For more advanced things, why not to have: self xxx ifTrue: [ self bla. self foo or self xxx ifTrue: [ self bla. self foo this are the interesting things to me. I guess I should read Kent Beck's formatting rules :) but one more thing that I like to have is anObject a: param1; cascading: param2; message: param3; formatted: param4 Although there are some issues around it. Uko > On 03 Sep 2015, at 07:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > And what happened to the plain normal (in my mind/experience) ? > > self xxx > ifTrue: [ > self bla. > self foo ]. > > I would say that is the most common one I've seen in the image. And it is how the old formatter worked. > >> On 03 Sep 2015, at 03:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Ben, >> >> have you read Kent Beck's formatting rules? I wish we would adhere to these in our formatters. And I wish he would put the formatting rules in the public domain on the web (Kent?). He actually justifies the rules he chooses; they're not just personal preferences. And IMO they produce eleant, readable Smalltalk. I have to say your block formatting below is horrible. Blocks are blocks. [ & ] are /not/ the same as { & } in C. [...] define an *object*, not merely delimit syntax. As such any good Smalltalk format will emphasize the objectness of blocks. And IMNERHO that is to make them rectangles as in >> >> self ifIWantedYouToWriteC ifTrue: >> [self useABloodyCCompiler. >> self useCCMinusPToMakeSenseOfTheDamageDoneByTheCPreProcessor] >> >> >> On Wed, Sep 2, 2015 at 6:23 PM, Ben Coman <btc(a)openinworld.com> wrote: >> On Thu, Sep 3, 2015 at 2:28 AM, stepharo <stepharo(a)free.fr> wrote: >>> >>> I do not really like all the formattings of kent. Because sometimes it just >>> does not work. >>> But this is why we ask franck (an interns to start to have a look). >>> >>> For example I do not like >>> >>> self xxx >>> ifTrue: >>> [ >>> self bla >>> self foo. >> >> Agreed. Unneccessary waste of a line. >> >>> in the current default formatter. >>> and I prefer >>> >>> self xxx >>> ifTrue: [ self bla. >>> self foo >>> But here the problem is that the self foo is not tab aligned because >>> ifTrue: [ >>> >>> self xxx >>> ifTrue: >>> [ self bla. >>> self foo >>> So may be this one is a nice compromise >> >> Not quite there. The "self bla" is still not actually vertically aligned. >> >>> I think that we should change some settings. In fact in alpha things are >>> there to evolve until the release :) >> >> I like... >> self xxx >> ifTrue: >> [ self bla. >> self foo. >> ]. >> >> for three reasons: >> * the first statement of the block is vertically aligned with the rest >> * vertical alignment of paired brackets makes visual matching *simple* >> * the vertical whitespace enforced by the closing bracket on its >> own visually groups blocks. >> >> Now some people don't like the closing brace on its own because they >> prefer code density. So maybe this... >> >> self xxx >> ifTrue: >> [ self bla. >> self foo. ] >> ifFalse: >> [ self baa. >> self moo. ]. >> >> But still I prefer... >> >> self xxx >> ifTrue: >> [ self bla. >> self foo. >> ] >> ifFalse: >> [ self baa. >> self moo. >> ]. >> >> cheers -ben >> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > >

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by Thierry Goubier

2015-09-03 10:29 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 03 Sep 2015, at 10:03, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-09-03 7:56 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> +1 >> >> I also submitted an issue about MCBrowser not taking into account the >> size of the world window (and then appearing with part of it hidden out of >> the visible area) >> > > > That one is fixed: > 16401 > <https://pharo.fogbugz.com/f/cases/16401/opening-monticello-window-does-not-…> > opening monticello window does not respect world size > > > hehâ¦ I missed that one :) > > > > and for "size of MCbrowser should be proportional": > > We don't have any other windows with a size proportional to the display > size. > Why should only MCBrowser behave like that? (Nautilus uses the same size). > > And what would be a good size, max. half the screen? > > And if we want a display screen dependent window size, this should be done > by > RealEstateAgent, and not for every single tool. > > > I really donât know if it should be proportional. I has never been like > that. What I do know is that now is too big (while before was to small) :) > So maybe best is to play a bit with the sizesâ¦ it was small, now is big, > lets find something in the middle :) > The previous size, small, made it not too scary. The new, large size, makes it a very scary tool. That many packages? That many repositories? Ok, that was there before, but in XXL size, it becomes a bit too obvious there is a lot in there. Thierry > > Esteban > > > > > > >> > On 02 Sep 2015, at 10:07, stepharo <stepharo(a)free.fr> wrote: >> > >> > Hi guys >> > >> > now when I open MCBrowser it gets 80% of my window. >> > So this is good to make it larger but it should be proportional to the >> actual size. >> > >> > >> https://pharo.fogbugz.com/f/cases/16451/MCBrowser-default-size-should-propo… >> > Could the person that originally changed it fix it? >> > >> > Stef >> > >> >> >> > >

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by Esteban Lorenzano

> On 03 Sep 2015, at 10:03, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-09-03 7:56 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > +1 > > I also submitted an issue about MCBrowser not taking into account the size of the world window (and then appearing with part of it hidden out of the visible area) > > > That one is fixed: > 16401 <https://pharo.fogbugz.com/f/cases/16401/opening-monticello-window-does-not-…> opening monticello window does not respect world size hehâ¦ I missed that one :) > > > and for "size of MCbrowser should be proportional": > > We don't have any other windows with a size proportional to the display size. > Why should only MCBrowser behave like that? (Nautilus uses the same size). > > And what would be a good size, max. half the screen? > > And if we want a display screen dependent window size, this should be done by > RealEstateAgent, and not for every single tool. I really donât know if it should be proportional. I has never been like that. What I do know is that now is too big (while before was to small) :) So maybe best is to play a bit with the sizesâ¦ it was small, now is big, lets find something in the middle :) Esteban > > > > > > > On 02 Sep 2015, at 10:07, stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>> wrote: > > > > Hi guys > > > > now when I open MCBrowser it gets 80% of my window. > > So this is good to make it larger but it should be proportional to the actual size. > > > > https://pharo.fogbugz.com/f/cases/16451/MCBrowser-default-size-should-propo… <https://pharo.fogbugz.com/f/cases/16451/MCBrowser-default-size-should-propo…> > > Could the person that originally changed it fix it? > > > > Stef > > > > >

Sept. 3, 2015

Re: [Pharo-dev] size of MCbrowser should be proportional

by Nicolai Hess

2015-09-03 7:56 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > +1 > > I also submitted an issue about MCBrowser not taking into account the size > of the world window (and then appearing with part of it hidden out of the > visible area) > That one is fixed: 16401 <https://pharo.fogbugz.com/f/cases/16401/opening-monticello-window-does-not-…> opening monticello window does not respect world size and for "size of MCbrowser should be proportional": We don't have any other windows with a size proportional to the display size. Why should only MCBrowser behave like that? (Nautilus uses the same size). And what would be a good size, max. half the screen? And if we want a display screen dependent window size, this should be done by RealEstateAgent, and not for every single tool. > > On 02 Sep 2015, at 10:07, stepharo <stepharo(a)free.fr> wrote: > > > > Hi guys > > > > now when I open MCBrowser it gets 80% of my window. > > So this is good to make it larger but it should be proportional to the > actual size. > > > > > https://pharo.fogbugz.com/f/cases/16451/MCBrowser-default-size-should-propo… > > Could the person that originally changed it fix it? > > > > Stef > > > > >

Sept. 3, 2015

Re: [Pharo-dev] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by Ben Coman

On Thu, Sep 3, 2015 at 1:33 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 03 Sep 2015, at 06:01, H. Hirzel <hannes.hirzel(a)gmail.com> wrote: >> >> On 9/2/15, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> But Timestamp was already removed completely from 4.0, why re-add it, even >>> deprecated ? >> >> Because it will be added in a compatibility layer package which is >> only loaded by packages which need it. There might be other things in >> the Pharo 5/4 compatibility package. > > But still, if external packages do load that code, they will never have to change, and the class will remain in the image forever. > > It is like when you load certain Squeak packages that are 'ported' with compatibility layers to Pharo: they just add again all the methods that we tried to clean up. Unfortunately this is a pragmatic engineering approach to porting. I haven't done a lot of this in practice, but I expect much of the effort in replacing deprecated methods in applications is ensuring that the replacement *really* is functionally equivalent. So the quickest route is reintegrating those methods. The downside is that: * When reading existing code, use of deprecated method is not obvious. * Deprecated methods can be accidently reused for new code. So just brainstorming... perhaps these downsides can be addressed by a deprecation-compatability package that makes use of it more explicit by prepending each deprecated method with "deprecatedNN", e.g... SomeClass>>xyz self deprecated: 'Blahblah' on: 'April 2015' in: #Pharo4.0. self deprecated40xyz. SomeClass>>deprecated40xyz "original code or call to replacement code..." So this splits porting into a few steps. 1. Loading the deprecation-compatability package gives *functional-equivalence* with Deprecation Warnings turned off. 2. Gradually (manually or with rewrite tool) replacing #xyz calls with #deprecated40xyz calls, results in *functionally-equivalent* but *ugly* and obvious code. 3. Gradually migrate #deprecated40xyz calls to whatever the final replacement is. 4. Easy to search for remaining users of #deprecated40 and when none are left (btw, is there a deprecation-compatability package/repository somewhere? I couldn't see one on Smalltalkhub) cheers -ben >> --HH >> >>> I am sure many external packages are already modified, I know I did it for >>> mine. >> >>>> On 02 Sep 2015, at 13:19, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>>> >>>> >>>>> On 02 Sep 2015, at 12:32, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> Hi guille >>>>> >>>>> there is not stress. I just wanted to let you know. >>>>> I was wondering if just subclassing DateAndTime would not be enough for >>>>> now. >>>> >>>> Yes, as far as I remember Timestamp was just an empy subclass. >>>> >>>> We could: >>>> >>>> -> add it back to Deprecated50 or maybe even to a âCompatibilityâ package >>>> -> Write a Quality Check rule. >>>> >>>>> I will go back to code with Pharo 40 >>>>> >>>>> stef >>>>> >>>>> Le 2/9/15 10:30, Guillermo Polito a Ã©crit : >>>>>> If somebody can check it and fix it it would be good :). I've just >>>>>> started my new job and my evenings are busy looking for an apartment or >>>>>> staying in a hostel without a proper internet connection... >>>>>> >>>>>> If not, I think we can wait a bit. The first step should be enabling CI >>>>>> jobs for pharo5. Also, I do not think the intersection between 'people >>>>>> using garage opendbx' and 'people using pharo5' is that big to justify a >>>>>> rush. >>>>>> >>>>>> Guille >>>>>> >>>>>> El miÃ©., 2 de sept. de 2015 a la(s) 10:12 a. m., stepharo >>>>>> <stepharo(a)free.fr> escribiÃ³: >>>>>> for your info... >>>>>> >>>>>> Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp >>>>>> >>>>>> Stef >>>>>> >>>>> >>>> >>> >>> >>> >> > >

Sept. 3, 2015

Re: [Pharo-dev] block brace alignment (Re: feedback from J Brant)

by Peter UhnÃ¡k

> > I like... > self xxx > ifTrue: > [ self bla. > self foo. > ]. Check the settings. It's called "align brackets" I think. He actually justifies the rules he chooses; they're not just personal > preferences. This is thin ice. The justifications can still be based on personal preferences. Imagine tabs vs spaces flame wars, where both side do have valid arguments and you pick side based on what is more important to you. Now with the new Rubric and BlueInk you can automatically have methods formatted for you, so it doesn't matter as much what other people use. But generally agreement is a good thing. And what happened to the plain normal (in my mind/experience) ? > self xxx > ifTrue: [ > self bla. > self foo ]. I'm pretty sure this is a bug; I've reported it few days ago. https://pharo.fogbugz.com/f/cases/edit/16422/BlueInk-Formatter-breaks-line-… And there is settings for that also. Peter On Thu, Sep 3, 2015 at 7:29 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > And what happened to the plain normal (in my mind/experience) ? > > self xxx > ifTrue: [ > self bla. > self foo ]. > > I would say that is the most common one I've seen in the image. And it is > how the old formatter worked. > > > On 03 Sep 2015, at 03:39, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > Hi Ben, > > > > have you read Kent Beck's formatting rules? I wish we would adhere > to these in our formatters. And I wish he would put the formatting rules > in the public domain on the web (Kent?). He actually justifies the rules > he chooses; they're not just personal preferences. And IMO they produce > eleant, readable Smalltalk. I have to say your block formatting below is > horrible. Blocks are blocks. [ & ] are /not/ the same as { & } in C. > [...] define an *object*, not merely delimit syntax. As such any good > Smalltalk format will emphasize the objectness of blocks. And IMNERHO that > is to make them rectangles as in > > > > self ifIWantedYouToWriteC ifTrue: > > [self useABloodyCCompiler. > > self useCCMinusPToMakeSenseOfTheDamageDoneByTheCPreProcessor] > > > > > > On Wed, Sep 2, 2015 at 6:23 PM, Ben Coman <btc(a)openinworld.com> wrote: > > On Thu, Sep 3, 2015 at 2:28 AM, stepharo <stepharo(a)free.fr> wrote: > > > > > > I do not really like all the formattings of kent. Because sometimes it > just > > > does not work. > > > But this is why we ask franck (an interns to start to have a look). > > > > > > For example I do not like > > > > > > self xxx > > > ifTrue: > > > [ > > > self bla > > > self foo. > > > > Agreed. Unneccessary waste of a line. > > > > > in the current default formatter. > > > and I prefer > > > > > > self xxx > > > ifTrue: [ self bla. > > > self foo > > > But here the problem is that the self foo is not tab aligned > because > > > ifTrue: [ > > > > > > self xxx > > > ifTrue: > > > [ self bla. > > > self foo > > > So may be this one is a nice compromise > > > > Not quite there. The "self bla" is still not actually vertically aligned. > > > > > I think that we should change some settings. In fact in alpha things > are > > > there to evolve until the release :) > > > > I like... > > self xxx > > ifTrue: > > [ self bla. > > self foo. > > ]. > > > > for three reasons: > > * the first statement of the block is vertically aligned with the > rest > > * vertical alignment of paired brackets makes visual matching > *simple* > > * the vertical whitespace enforced by the closing bracket on its > > own visually groups blocks. > > > > Now some people don't like the closing brace on its own because they > > prefer code density. So maybe this... > > > > self xxx > > ifTrue: > > [ self bla. > > self foo. ] > > ifFalse: > > [ self baa. > > self moo. ]. > > > > But still I prefer... > > > > self xxx > > ifTrue: > > [ self bla. > > self foo. > > ] > > ifFalse: > > [ self baa. > > self moo. > > ]. > > > > cheers -ben > > > > > > > > > > -- > > _,,,^..^,,,_ > > best, Eliot > > >

Sept. 3, 2015