- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Introducing Myself / FFI comments

by csrabak＠bol.com.br

I would like to add to this discussion. The issue on "breaking code compatibility" /per se/ it is not the central issue, the real trouble is to have to expend too much time to learn how to "re-compatibilize" the cote, or use [the] new construct that is not deprecated. I'm not an active Python developer, but I used to work in a place where it was used extensively and the 'elbow' feedback I got from colleagues was that that Python did a good job on this aspect. my 0.01999.... -- Cesar Rabak Em 28/02/2010 05:24, Hilaire Fernandes < hilaire(a)ofset.org > escreveu: Andreas Raab a Ã©crit : > The *one* tradeoff I wasn't willing to make for the sake of my users was > to break their code; was to make their code non-loadable for absolutely > no benefit for these users. Cleaning up two methods and fifty lines of > code isn't worth breaking six years of work from lots of people. It > wasn't then, it isn't today. However, breaking code compatibility is very common in opensource world, probably to ease evolution. I remember to read somewhere it happens several time in Python, an alive and kicking community... _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by Adrian Lienhard

Hi Bill, Don't worry. Nobody wants to force you to use his conventions :) The question really only concerns the code of PharoCore. I think a consistent way of code formatting really is a good idea, even if not everybody agrees with each rule. Cheers, Adrian On Feb 28, 2010, at 18:43 , Schwab,Wilhelm K wrote: > Adrian, > > Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always. > > I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!! > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard > Sent: Sunday, February 28, 2010 8:11 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] about code formatting in pharo > > I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". > > According to these rules I would format the following example: > > --------------- > 1 to: (mine size min: his size) do: > [ :ind | > (mine at: ind) = (his at: ind) > ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. > --------------- > > as: > > --------------- > 1 > to: (mine size min: his size) > do: [ :index | > (mine at: index) = (his at: index) ifTrue: [ > self > instVarAt: index > put: (anotherObject instVarAt: index) ] ]. > --------------- > > Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. > > Cheers, > Adrian > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010

Re: [Pharo-project] Scamper revival

by Eagle Offshore

I wouldn't be so sure. http://html5demos.com/ http://jqtouch.com/ On Feb 27, 2010, at 4:41 PM, Schwab,Wilhelm K wrote: > there is no way in hell that HTML+CSS+JavaScript is going to keep up

Feb. 28, 2010

Re: [Pharo-project] Infinite Loop and Ctrl+.

by Mariano Martinez Peck

we should open a ticket On Sun, Feb 28, 2010 at 2:15 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Sure, no worries. In any case it would be nice if it always worked... > > Adrian > > On Feb 28, 2010, at 13:52 , Lukas Renggli wrote: > > > I wasn't implying that this was the fault of Pharo. I just noticed it > > suddenly and I somehow thought that this worked at some point in the > > past, but I might be wrong. > > > > Lukas > > > > On 28 February 2010 13:29, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> It worked for me the first time I tried, but not the second time (the VM > eventually crashed). > >> > >> Already in Squeak 3.9 it was sometimes impossible to break endless > recursions. So I'm not sure if this related to changes in Pharo 1.0. > >> > >> Adrian > >> > >> On Feb 26, 2010, at 16:50 , Lukas Renggli wrote: > >> > >>>>> Is this just me that suddenly cannot break out of an infinite loop > >>>>> with Ctrl+. in Pharo 1.0 anymore? > >>>> > >>>> Works here. [true] whileTrue: [] > >>> > >>> Yes, that works for me too, but try: > >>> > >>> UndefinedObject compile: 'foo self foo'. > >>> nil foo > >>> > >>>> Which vm are you using? Squeak 4.2.2beta1U here right now... > >>> > >>> Yes, I am using this one too. > >>> > >>> Lukas > >>> > >>> -- > >>> Lukas Renggli > >>> http://www.lukas-renggli.ch > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > > > > > > > -- > > Lukas Renggli > > http://www.lukas-renggli.ch > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by Schwab,Wilhelm K

Adrian, Horrible is an understatement :) Your version is a big improvement. I frequently put ending brackets on their own line with indentation to aid in matching, but not always. I do not (much) care what conventions the benevolent dictators select for Pharo, but I **do** care that it not be forced on my code that I retain for my own use. There should be ways to compile, export and load code and packagets w/o encountering automatic formatting. As long as that is the case, enjoy!! Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Sunday, February 28, 2010 8:11 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo I've attached the coding conventions that we use at Cmsbox and netstyle.ch. They closely follow the suggestions of Kent Beck's "Smalltalk Best Practice Patterns". According to these rules I would format the following example: --------------- 1 to: (mine size min: his size) do: [ :ind | (mine at: ind) = (his at: ind) ifTrue: [ self instVarAt: ind put: (anotherObject instVarAt: ind) ] ]. --------------- as: --------------- 1 to: (mine size min: his size) do: [ :index | (mine at: index) = (his at: index) ifTrue: [ self instVarAt: index put: (anotherObject instVarAt: index) ] ]. --------------- Putting "[ :ind |" on a new line and using multiple tab indentation looks horrible to me. Cheers, Adrian

Feb. 28, 2010

Re: [Pharo-project] SqueakSave on Pharo

by Yanni Chiu

I sent an email last week, and saw no answer, so far. So I've put up what I have. StÃ©phane Ducasse wrote: > Yanni excellent to have it on squeaksource. > Now did you contact the maintainer (if any) or the people that developed it (I like it a lot) to mention that? > Because at least they should know if some changes get introduced that they can cherrypick it.

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by Levente Uzonyi

On Sun, 28 Feb 2010, James Foster wrote: > > On Feb 28, 2010, at 1:58 AM, StÃ©phane Ducasse wrote: > >> Lukas do you have some code samples. >> Something that I particularly hate is the following >> >> self bla ifTrue: [ >> ... >> >> ] ifFalse: [ >> ... >> ] > > I'd like to understand what it is about the above you hate. It's like C code, not like a message send. Do you write code like this? aCollection do: [ :each | ... ] separatedBy: [ ... ] > >> That is see in the code. >> >> I want >> self bla >> ifTrue: [ ... >> ] >> ifFalse: [ >> ... ] > > Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line? > IMHO, if the code in the first block is short enought, then it's only a single line, otherwise not, for example: self bla ifTrue: [ self bar ] ifFalse: [ ... ] self bla ifTrue: [ ... ] ifFalse: [ ... ] This book has great guidelines: http://stephane.ducasse.free.fr/FreeBooks/WithStyle/SmalltalkWithStyle.pdf Levente > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by James Foster

On Feb 28, 2010, at 1:58 AM, StÃ©phane Ducasse wrote: > Lukas do you have some code samples. > Something that I particularly hate is the following > > self bla ifTrue: [ > ... > > ] ifFalse: [ > ... > ] I'd like to understand what it is about the above you hate. > That is see in the code. > > I want > self bla > ifTrue: [ ... > ] > ifFalse: [ > ... ] Does the code in the ifTrue: block begin on the same line? How about the ifFalse: block? If it begins on the same line, then how many indents for the second line? James

Feb. 28, 2010

[Pharo-project] Smalltalk and Bioinformatics

by HernÃ¡n Morales Durand

Hi all, I'm preparing a presentation and just wondering if anyone out there is doing bioinformatics with Smalltalk? Cheers, HernÃ¡n

Feb. 28, 2010

Re: [Pharo-project] about code formatting in pharo

by Schwab,Wilhelm K

Stef, It pains me to have to be a pain about this. I never use a space after a colon; what other people do is their business, but I much prefer having the space gone. Other formatting concerns are far less trivial to me than a personal preference. Lukas is correct about using a formatter, but it has to be a separate or optional step because the current state of formatting is hostile to comments. If moving code to Pharo has taught me anything, it is that I have been correct to embed dated (month-year) comments in my code. The RB scatters them to the four corners, which is why I don't use the thing. I also format code in ways that are analogous to phrasing in music. I tried to capture it in a custom formatter, and quickly realized that I see design, workflow, organizational politics, etc., and the machine sees syntax. It will never "understand" what belongs together and what does not. Anything that forces formatting on me is defective. If there is a way for me to optionally format my code with a Pharo formatter, I'm happy to do so as I turn it over. Anything that I am actively using will be littered with comments (until I tire of them[*]) and formatted in a way that helps me see the big picture long after the machine smashes it down to a mere sequence of byte codes. Bill [*] every so often, I clean out truly obsolete information, but that is more a question of the amount of change that has occurred, not chronological age. In moving to Pharo, I ran across couple of related defects from 2003, and fixed them within an hour thanks to comments in the code. This is one of many such stories that have formed my (somewhat stubborn) thoughts on code formatting. -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Sunday, February 28, 2010 4:52 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about code formatting in pharo I would use a formatter, like this you can make it really consistent. The RBConfigurableFormatter is pretty good in that, the only thing I don't like is the placing of the square brackets. I should look into fixing that, otherwise it formats exactly the way I would format myself (and in the way you propose). Lukas On 28 February 2010 10:36, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > Hi guys > > I would like to build a set of canonical code formatting convention for Pharo. > I need your help. Now take time before replying :) I would like to > structure the discussion and proceed step by step. So at max I would like to discuss one or two formatting approach per mail. > Once we agree I would like to define a wiki page. > > > **Space after : rule > ============= > for example I would like to always have a space after a : > > classes := Smalltalk allClasses select:[:aClass| > Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â or:[aClass class includesSelector: #cleanUp:] > Â Â Â ]. > > -> > > > classes := Smalltalk allClasses select: [:aClass| > Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] > Â Â Â ]. > > > **Block arg rule > ============= > Do we want a space before and after block arg > > Smalltalk allClasses select: [:aClass :method| > > -> Smalltalk allClasses select: [ :aClass :method | > > > ** selector or block indented compared to receiver > ======================================= > > Finally do we follow kent block ideas? > > classes := Smalltalk allClasses select: [:aClass| > Â Â Â Â Â Â Â (aClass class includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:] > Â Â Â ]. > > -> > classes := Smalltalk allClasses > Â Â Â Â Â Â Â Â Â Â Â Â select: [:aClass| (aClass class > includesSelector: #cleanUp) > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â or: [aClass class includesSelector: #cleanUp:]]. > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 28, 2010