- Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

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] GitFileTree: Playing Nice with FileTree

by Thierry Goubier

Hi Sean, Le 03/09/2015 04:29, Sean P. DeNigris a Ã©crit : > If I have a filetree://path/to/canonical/local/repo repository, can I later > point a GitFileTree repo to that folder? From the MC Browser +Repository > menu, I only seem to be able to set the subfolder relative to the > #imageDirectory, not the absolute pathâ¦ Are you sure about the local path? I know I played with a few things to try to get local paths to work if used. But gitfiletree://path/to/canonical/local/repo will work. Thierry

Sept. 3, 2015

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

by H. Hirzel

On 9/2/15, 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 +1 > -> 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 <mailto:stepharo@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] Garage-OpenDBX does not load on Pharo 50 because it uses Timestamp

by H. Hirzel

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. --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

GitFileTree: Playing Nice with FileTree

by Sean P. DeNigris

If I have a filetree://path/to/canonical/local/repo repository, can I later point a GitFileTree repo to that folder? From the MC Browser +Repository menu, I only seem to be able to set the subfolder relative to the #imageDirectory, not the absolute pathâ¦ ----- Cheers, Sean -- View this message in context: http://forum.world.st/GitFileTree-Playing-Nice-with-FileTree-tp4847786.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 3, 2015

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

by Eliot Miranda

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

block brace alignment (Re: feedback from J Brant)

by Ben Coman

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

Sept. 3, 2015

Re: [Pharo-dev] feedback from J Brant

by Thierry Goubier

Le 02/09/2015 22:14, stepharo a Ã©crit : > To have fun I addressed > - > https://pharo.fogbugz.com/f/cases/16460/I-fileout-a-package-does-not-fileou… > > but it should be checked. > - https://pharo.fogbugz.com/f/cases/16461/ChunkFileParser and > introduced hooks. > > Now back to coding for real. Thanks. I think that the ability to better port Dolphin packages will help. Thierry > > Stef > > Le 2/9/15 20:28, stepharo a Ã©crit : >> Hi guys >> >> here is some feedback from John. I share it with you. >> >> >> On 02 Sep 2015, at 16:05, John Brant <brant(a)refactoryworkers.com> wrote: >> >> I've been writing some automated scripts to port SmaCC to Pharo. I >> have it where I can file in the Dolphin .pac files directly into a >> Pharo 5 image. Most things are working, but I've had to fight some >> Pharo issues. Since I wasn't sure who should be notified, I thought >> I'd complain to you :) >> >> >> :) if you would see my list of complaints about Pharo you would >> laugh a lot because it is huge and diverse. >> I put thierry on CC because he is the guy maintaining and using >> SmaCC a lot. >> So may be you can help each others. >> >> >> *) The BIConfigurableFormatter (aka RBConfigurableFormatter) sends >> #asString to nodes. First, it should format the node if it wants them >> formatted instead of relying on asString to return a formatted string. >> Second, by sending #asString, formatting has become exponential in the >> nesting level of blocks. For example, Dolphin Smalltalk runs this in 4 >> milliseconds: >> >> | stream | >> stream := WriteStream on: String new. >> stream nextPutAll: 'foo ^true and: '. >> 40 timesRepeat: [stream nextPutAll: '[true and: ']. >> stream nextPutAll: 'false'. >> 40 timesRepeat: [stream nextPut: $]]. >> (RBParser parseMethod: stream contents) formattedCode >> >> I'm guessing that Pharo wouldn't finish in a day... It takes over 4 >> seconds to format 16 nested blocks. >> >> Thanks indeed we will fix it. >> https://pharo.fogbugz.com/f/cases/16462/BIConfigurableFormatter-should-not-… >> >> >> >> *) Also on the formatter, its default doesn't appear to be compliant >> with Kent's blocks should look like blocks/rectangles/box rule. The >> way I interpret the rule is that if I draw a rectangle around >> everything in the block including the brackets, it should not include >> any text of anything outside of the block. For example, this would >> fail that test: >> >> surroundedBy: aString >> ^ self class >> streamContents: [ :s | >> s nextPutAll: aString. >> s nextPutAll: self. >> s nextPutAll: aString ] >> >> yes >> >> >> Since the block starts at the end of the #streamContents: line, a >> rectangle around all the contents in the block contains part of the >> #streamContents: selector which isn't part of the block. >> >> 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. >> >> 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 >> I think that we should change some settings. In fact in alpha >> things are there to evolve until the release :) >> >> >> >> *) If I fileout a package, it doesn't fileout the metaclass extension >> methods. The RPackage>>fileOut method needs to be updated with the >> metaclassExtensionSelectors. >> >> Oops this is a bug. >> Do you mean what I mean? the extensions done by the package on >> metaclass that are not in the package. >> >> https://pharo.fogbugz.com/f/cases/16460/I-fileout-a-package-does-not-fileou… >> >> >> >> *) On windows, it appears that while the menus say Ctrl+..., they >> really mean Ctrl+... or Alt+... -- you figure it out. >> >> Yes it sucks. We are in flux with the key essentially because the >> VM often does not even gives us the correct information. >> With the new OSWindow architecture we are putting in place we will >> have all the events and not just the one the VM does not eat (like >> shift pressed) >> and we can manage all at the image level not deep into arcane and >> old C- code. >> >> >> *) It appears that Pharo is removing subString: in favor of >> substring:. The ANSI standard defines subString:. >> >> I was not aware of it. In fact ANSI is bad and totally incomplete >> (for example we studies strings and this is a mess and totally >> incomplete). >> Now we should probably add it. I will send the mail to the >> mailing-list and let people decide. >> >> >> >> >> *) The ChunkFileFormatParser>>parseNextDeclaration is hard coded to >> handle only the Pharo format: >> | substrings | >> substrings := nextChunk parseLiterals. >> (substrings includes: 'methodsFor:') >> ifTrue: [ ^self parseMethodDeclarations: substrings ]. >> (substrings includes: 'commentStamp:') >> ifTrue: [ ^self parseCommentDeclaration: substrings ]. >> (substrings includes: 'reorganize') >> ifTrue: [ ^self parseClassOrganization: substrings ]. >> Due to the hard coded nature of the types of strings accepted, I have >> to overwrite this method to be able to file in Dolphin code. In the >> other Smalltalk's, I can write an extension method or two that I use >> to file in another dialect's code. >> >> https://pharo.fogbugz.com/f/cases/16461/ChunkFileParser >> >> If you have a solution please send it. Because we are focusing on >> the bootstrap and spur the new object format plus a new FFI. Plus >> a lot more. >> So this keeps us really busy and many people left the team and we >> are restarting to teach :) >> >> I personally hate this format and the hardcoding of these strings >> and selectors everywhere so this is why the ChunkFileFormatParser >> is already >> a big step forward. >> >> >> >> I have several other things that annoy me, >> >> me too :) >> But I tried that every couple of days I fix one. >> >> >> but this is enough for now. :) >> >> Tx john :) >> >> >> >> John Brant >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr >> http://www.synectique.eu / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Julie Jonas >> 03 59 57 78 50 >> 03 59 35 86 16 >> >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >

Sept. 2, 2015

Re: [Pharo-dev] how to contribute to Moose/GToolkit

by Andrei Chis

Hi Peter, If the change affects pharo as well, create first a bug report normally, then push the change to the Moose/GToolkit and then put the issue on fixed upstream. The change will then get picked up next time we merge with Pharo. If it's an important issue feel free to bother us :) You can also update the corresponding configuration yourself and add it to the issue. I added you to the moose team. Cheers, Andrei On Wed, Sep 2, 2015 at 11:10 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > How do I fix a bug in Moose/GToolkit? > > Do I push to change to Pharo50Inbox and let you copy it from there? > Do I commit it to Moose/GToolkit directly (I would need rights)? > Do I send fileout over mailing list? > > Thanks, > Peter >

Sept. 2, 2015

how to contribute to Moose/GToolkit

by Peter UhnÃ¡k

How do I fix a bug in Moose/GToolkit? Do I push to change to Pharo50Inbox and let you copy it from there? Do I commit it to Moose/GToolkit directly (I would need rights)? Do I send fileout over mailing list? Thanks, Peter

Sept. 2, 2015