March 2010 - Pharo-dev - lists.pharo.org

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

by Dale Henrichs

It is obvious that a consensus will not be reached on the "one and only true format." If my browser displays code formatted the way I want to see it and the difference tools are format neutral (i.e., the source and target code is formatted using the same rules) there is no need to agree on a standard style. For all intents and purposes each developer's favored format _is the standard_. We only need to agree to disagree and then figure out how to make it possible to customize the formatter and resolve any other technical details (performance and others) that are deemed important. These are technical problems with technical solutions. Dale ----- "Chris Muller" <asqueaker(a)gmail.com> wrote: | > Another visual problem with "[" and "]" is that they are but one | > character, and if you place them together with something else, like | > "[self", they lose their visual identity (btw, we read words in | chunks | > not by characters) and get harder to spot. It's true that some fonts | > and extra coloring could solve this problem, but whitespace is | always | > the best and least invasive design weapon. | | Tudor, for what its worth, the white-space surrounding the blocks is | not really at issue or discussion here. It's about formatting blocked | code into rectangular shapes. | | In fact, I agree with you about your point about the whitespace. IOW, | I prefer: | | someVar = someValue | ifTrue: [ self doOneThing ] | ifFalse: | [ self | doOtherThing ; | doYetAnotherThing. | anotherObject doSomething ] | | Not: | | someVar = someValue | ifTrue: [self doOneThing] | ifFalse: | [self | doOtherThing ; | doYetAnotherThing. | anotherObject doSomething] | | Perhaps if you looked at a longer method example, with nested blocks, | you might be able to "see", visually, the blocks more obviously. | Perhaps not, I don't know. | | Regards, | Chris | | > The lines are clearly belonging together, [ is clearly observed and | > clicking anywhere on the first line after [ will select the whole | block. | > | > Yet another thing it solves is the consistency between block and | > method. They both define behavior, and thus Â it would be great if | they | > would be treated similarly. This is better seen in the context of a | > block with parameter: | > | > aCollection do: [ :each | | > Â Â Â Â Â Â Â Â self something. | > Â Â Â Â Â Â Â Â self somethingElse. ] | > | > Just like a method has the top line with the signature and the | > parameters, a block should be the same. In this case, each is a | > parameter and it is clearly distinct from everything else. When | there | > is no parameter, this is information made very clear, too (because | of | > the absence of anything following [ ). | > | > | > An argument against this convention was that it looks like C and | that | > blocks are not dumb {. While I understand the built-in adversity, we | > are talking about a visual notation that makes sense for Smalltalk | and | > not one that make it different from everything else around us. | > | > Another option would be to have: | > boolean ifTrue: | > Â Â Â Â [ Â Â Â self clearCaches. | > Â Â Â Â Â Â Â Â self current soleInstance yada yada blah blah | > Â Â Â Â Â Â Â Â self recomputeAngle ] | > | > with everything inside the block being aligned. However, this has | the | > problem of wasting space. One space can also be used, but only when | > the font is monospaced, so it would not work in general. | Furthermore, | > it would be inconsistent or even more space wasting when it comes to | > blocks with parameters. | > | > Cheers, | > Doru | > | > | > On 4 Mar 2010, at 03:38, Chris Muller wrote: | > | >>>> Â Â ifTrue: [ | >>>> Â Â Â Â line1 yo. | >>>> Â Â Â Â line2 eh ] | >>> | >>> Horrible, horrible, horrible ;) Â Poor block. Â The block is an | >>> object... | >> | >> Exactly what I was thinking; and how some of the new editor | features | >> since 3.9, that seem to reify "statements". Â For example, clicking | >> inside parens or square-brackets selects that statement(s). Â I also | >> really enjoyed the ability to "surround", thereby creating | additional | >> statement-levels. | >> | >> The whole interaction becomes much more liked working with tiled | code | >> rather than a text-editor. | >> | >>> I think the conclusion has to be (and I can confirm that the | >>> VisualWorks | >>> team was equally divided) that no one formatting regime will make | >>> every one | >>> happy and that all regimes will make a substantial minority | >>> unhappy. Â So | >>> perhaps we should step up to having code formatted automatically | >>> according | >>> to tailorable preferences. | >> | >> | >> | >>> My only concern is comment formatting but the way to deal with | that | >>> is to | >>> use automatic formatting and deal with comment problems as they | >>> arise. Â I | >>> always used to be concerned about e.g. comments spanning multiple | >>> lines. | >>> Â But without day to day exposure I don't think one can know how | >>> much of an | >>> issue it is. | >> | >> As someone who's logged 5-digits of hours in Squeak these last few | >> years, I think the best thing is to just not. Â Let 'em wrap! Â Use | >> shout to turn them light gray, so they don't really intrude on the | >> code, but are there if you want focus on the extra prose. | >> | >> Unfortunately, the real problem with comments within BlockNodes is | how | >> they duplicate themselves within the parse-tree.. ouch! Â I hope | that | >> is what you and Nicolas were talking about or that you'll have a | fix | >> for that.. | >> | >>> One upside will be less effort reformatting when indent levels | >>> change. Â Have | >>> you noticed that Smalltalk tends to be more difficult to reformat | >>> than C | >>> syntax languages, I guess because of keywords? Â Not having to | worry | >>> about | >>> this could be great. | >> | >> Very cool, I hope there'll be enough additional consensus to adopt | >> these Beckian formats for Squeaks pretty-print refinement. | >> | >>> Of course, what format gets written to a source file could still | be | >>> a source | >>> of conflict ;) Â We may all want our syntax to be the Â format of | >>> record :) | >> | >> Absolutely. Â To not, would be the machine dictating to the user. | >> Invoking automatic formatting is always the users choice. | >> browseWithPrettyPrint allows readers to have it formatted | dynamically | >> if they wish.. | >> | >> Cheers.. | >> | >>> P.S. Â and don't get me started on the trailing period (putrid | >>> excressence), | >>> or the space between ^ and the return expression (vomitous mass). | >> | >> _______________________________________________ | >> Pharo-project mailing list | >> Pharo-project(a)lists.gforge.inria.fr | >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > -- | > www.tudorgirba.com | > | > "Live like you mean it." | > | > | > _______________________________________________ | > 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

March 4, 2010

[Pharo-project] [1.1] Object>>initialExtent

by Alexandre Bergel

Hi! I do not have a solution, but Object>>initialExtent was recently deprecated and this causes great usability problem. This deprecation is very valuable for a clean UI separation. However, I have a warning deprecation each time a window is open. The reason stems from the method: SystemWindow>>initialExtent ^ model initialExtent For now, in my image, I suppressed this deprecation. Again, I do not have a clean solution. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 4, 2010

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by Gabriel Cotelli

ouch! I missed that point from the definition :P .... Too bad that beginsWith: is not in the standard... I still feel that 'bbb' beginsWith: '' should return true... but it seems to be incompatible with indexOfSubCollection:startingAt: behavior... Gabriel. 2010/3/4 Henrik Johansen <henrik.s.johansen(a)veloxit.no> > > > Den 04.03.2010 16:03, skrev Gabriel Cotelli: > > *Message: indexOfSubCollection: targetSequence startingAt: start * > > *Start searching at index start in the receiver. Answer 0 if no such > subsequence is found. > * > > *snip* > > * Answer 0 if no such > subsequence is found in the receiver, or if targetSequence is empty. > * > > > I don't see how that is ambigous regarding whether an empty collection is > defined as a subsequence or not. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

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

by Chris Muller

> Another visual problem with "[" and "]" is that they are but one > character, and if you place them together with something else, like > "[self", they lose their visual identity (btw, we read words in chunks > not by characters) and get harder to spot. It's true that some fonts > and extra coloring could solve this problem, but whitespace is always > the best and least invasive design weapon. Tudor, for what its worth, the white-space surrounding the blocks is not really at issue or discussion here. It's about formatting blocked code into rectangular shapes. In fact, I agree with you about your point about the whitespace. IOW, I prefer: someVar = someValue ifTrue: [ self doOneThing ] ifFalse: [ self doOtherThing ; doYetAnotherThing. anotherObject doSomething ] Not: someVar = someValue ifTrue: [self doOneThing] ifFalse: [self doOtherThing ; doYetAnotherThing. anotherObject doSomething] Perhaps if you looked at a longer method example, with nested blocks, you might be able to "see", visually, the blocks more obviously. Perhaps not, I don't know. Regards, Chris > The lines are clearly belonging together, [ is clearly observed and > clicking anywhere on the first line after [ will select the whole block. > > Yet another thing it solves is the consistency between block and > method. They both define behavior, and thus Â it would be great if they > would be treated similarly. This is better seen in the context of a > block with parameter: > > aCollection do: [ :each | > Â Â Â Â Â Â Â Â self something. > Â Â Â Â Â Â Â Â self somethingElse. ] > > Just like a method has the top line with the signature and the > parameters, a block should be the same. In this case, each is a > parameter and it is clearly distinct from everything else. When there > is no parameter, this is information made very clear, too (because of > the absence of anything following [ ). > > > An argument against this convention was that it looks like C and that > blocks are not dumb {. While I understand the built-in adversity, we > are talking about a visual notation that makes sense for Smalltalk and > not one that make it different from everything else around us. > > Another option would be to have: > boolean ifTrue: > Â Â Â Â [ Â Â Â self clearCaches. > Â Â Â Â Â Â Â Â self current soleInstance yada yada blah blah > Â Â Â Â Â Â Â Â self recomputeAngle ] > > with everything inside the block being aligned. However, this has the > problem of wasting space. One space can also be used, but only when > the font is monospaced, so it would not work in general. Furthermore, > it would be inconsistent or even more space wasting when it comes to > blocks with parameters. > > Cheers, > Doru > > > On 4 Mar 2010, at 03:38, Chris Muller wrote: > >>>> Â Â ifTrue: [ >>>> Â Â Â Â line1 yo. >>>> Â Â Â Â line2 eh ] >>> >>> Horrible, horrible, horrible ;) Â Poor block. Â The block is an >>> object... >> >> Exactly what I was thinking; and how some of the new editor features >> since 3.9, that seem to reify "statements". Â For example, clicking >> inside parens or square-brackets selects that statement(s). Â I also >> really enjoyed the ability to "surround", thereby creating additional >> statement-levels. >> >> The whole interaction becomes much more liked working with tiled code >> rather than a text-editor. >> >>> I think the conclusion has to be (and I can confirm that the >>> VisualWorks >>> team was equally divided) that no one formatting regime will make >>> every one >>> happy and that all regimes will make a substantial minority >>> unhappy. Â So >>> perhaps we should step up to having code formatted automatically >>> according >>> to tailorable preferences. >> >> >> >>> My only concern is comment formatting but the way to deal with that >>> is to >>> use automatic formatting and deal with comment problems as they >>> arise. Â I >>> always used to be concerned about e.g. comments spanning multiple >>> lines. >>> Â But without day to day exposure I don't think one can know how >>> much of an >>> issue it is. >> >> As someone who's logged 5-digits of hours in Squeak these last few >> years, I think the best thing is to just not. Â Let 'em wrap! Â Use >> shout to turn them light gray, so they don't really intrude on the >> code, but are there if you want focus on the extra prose. >> >> Unfortunately, the real problem with comments within BlockNodes is how >> they duplicate themselves within the parse-tree.. ouch! Â I hope that >> is what you and Nicolas were talking about or that you'll have a fix >> for that.. >> >>> One upside will be less effort reformatting when indent levels >>> change. Â Have >>> you noticed that Smalltalk tends to be more difficult to reformat >>> than C >>> syntax languages, I guess because of keywords? Â Not having to worry >>> about >>> this could be great. >> >> Very cool, I hope there'll be enough additional consensus to adopt >> these Beckian formats for Squeaks pretty-print refinement. >> >>> Of course, what format gets written to a source file could still be >>> a source >>> of conflict ;) Â We may all want our syntax to be the Â format of >>> record :) >> >> Absolutely. Â To not, would be the machine dictating to the user. >> Invoking automatic formatting is always the users choice. >> browseWithPrettyPrint allows readers to have it formatted dynamically >> if they wish.. >> >> Cheers.. >> >>> P.S. Â and don't get me started on the trailing period (putrid >>> excressence), >>> or the space between ^ and the return expression (vomitous mass). >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Live like you mean it." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

Re: [Pharo-project] [update 1.1] #11243

by Jorge Ressia

Hi, Sure - We need a way of testing the New compiler, It is very hard to now if the changes I am introducing work. I have a set of test but they are mainly oriented towards the closure implementation. - Not everything is done with visitors. - The ASTTranslator and subclasses have methods of considerable size which are hard to understand, mainly the emits and accepts - The Decompiler does not work - IRTranslator: needs some work, there are some abstractions that are not clear like sequences and pending instructions which make the code in every other method more complicated. - It is not completely modular, we do not have a way of configuring it from scratch - The phases of the compiler are not clearly defined If you ask me, I would say that the key point is to have a way of validating our compiler. This is what is holding me back from introducing more aggressive refactorings. This does not mean that we need all those point in order to have a running compiler, on the contrary, the compiler is working quite well, I am fixing special cases right now. But, if we what something we could improve and experiment with, we will need these points. Cheers, Jorge On Thu, Mar 4, 2010 at 1:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > jorge > > could you make a list of things to do in 10 min? > So that we get an idea. I really believe that we should invest for the future. > > Stef > > On Mar 4, 2010, at 10:07 AM, Jorge Ressia wrote: > >> Yes, the New compiler is not better. However, I think the New Compiler >> is the right direction to pursue. >> >> After fighting with it for some months to make the Closures work in it >> I can tell you that I learn a great deal from it, painfully :) . >> But I now have a pretty good idea of what it is required to have a >> modularized compiler with more suitable abstraction for this >> particular domain. >> I implemented many tests and I have to implement a lot more. Then, I >> believe that by expressing ourselves through these tests we will be >> able to modify the compiler to make it look the way we want. >> >> At least that is my plan with the New compiler. >> >> Cheers, >> >> Jorge >> >> On Thu, Mar 4, 2010 at 9:53 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> I'll try to build the tests and come up with a better solution. >>>> >>>> You what I would love to spend 2/3 weeks just coding in the new compiler and making sure >>>> that it has the right abstractions/messages to deal with issue like that. >>> >>> The problem is that the New Compiler is not really in a better state >>> than the old compiler. Of course it has more objects and is much >>> easier to extend, but all in all it is a mess too. This is mostly due >>> to the fact that the system below it changed quite a bit in the past >>> years (pragmas, properties, closures, primitives, new bytecodes, ...) >>> and that the New Compiler had to be patched and changed quite heavily >>> to accommodate these new requirements that it was not designed for. >>> Maintaining and fixing the New Compiler got so extremely expensive >>> that it is questionable if this is still a viable platform? Ask Jorge >>> and Marcus. >>> >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

Re: [Pharo-project] Polymorph fixes

by Gary Chambers

I know what you mean... too close could mean litigation though! A lot of the difference are, of course, due to merely replacing the controls without layout changes... I'll be giving Hilaire all the help I can for the new theme though. Regards, Gary ----- Original Message ----- From: "Richard Durr" <richard.durr(a)googlemail.com> To: <Pharo-project(a)lists.gforge.inria.fr>; <gazzaguru2(a)btinternet.com> Sent: Wednesday, March 03, 2010 1:42 PM Subject: Re: [Pharo-project] Polymorph fixes Cool. I dislike the Watery2 look a little bit, because it seems to me so close but not really matching the Mac OS X Aqua design. On Tue, Mar 2, 2010 at 2:15 AM, Gary Chambers <gazzaguru2(a)btinternet.com> wrote: > Yes, Hilaire is doing a theme to match the XO UI specs... some good will > come from this for Polymorph generally, in terms of extending the > "Widget set"... date pickers etc... > > On Mon, 2010-03-01 at 23:20 +0100, Richard Durr wrote: >> What's the Sugar theme? For the XO-Laptop? >> >> On Mon, Mar 1, 2010 at 8:34 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >> > Thanks. >> > I will give a try but may be we have a bug in scriptLoader :) >> > >> > Stef >> > On Mar 1, 2010, at 6:52 PM, Gary Chambers wrote: >> > >> >> A few fixes on SqueakSource. >> >> >> >> Polymorph-Widgets-gvc.24 >> >> Polymorph-Tools-Diff-gvc.24 >> >> >> >> Notably: >> >> >> >> Table layout of submorphs with #shrinkWrap attributes. >> >> Themeing of menu item text colours to help Hilaire in his Sugar theme >> >> efforts. ThemeSettings integration left for another time... >> >> Wrong "sides" for "compare to current" when using diff tools in change >> >> sets (versions browser etc.). >> >> Prevention of window dragging from submorphs promoted from >> >> StandardWindow to SystemWindow (deals with oddities when >> >> click-dragging from submorphs... offset would be wrong and window >> >> "jumps"). >> >> Wrong colours for faded background windows in Watery themes. >> >> Fix colours in W2K theme (requires class-side reinitialisation of >> >> defaultSettings. Do "UIThemeW2K defaultSettings: nil" before changing >> >> theme). >> >> Toolbars now Panel-based to adapt to pane colour. >> >> DockingBar based menus now deal with mouseFocus correctly. >> >> >> >> >> >> Regards, Gary >> >> _______________________________________________ >> >> 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 >> > >> >> _______________________________________________ >> 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

March 4, 2010

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by Henrik Johansen

Den 04.03.2010 16:03, skrev Gabriel Cotelli: /*Message: indexOfSubCollection: targetSequence startingAt: start */ > /**Start searching at index start in the receiver. Answer 0 if no such > subsequence is found. > / *snip* > / Answer 0 if no such > subsequence is found in the receiver, or if targetSequence is empty. > / I don't see how that is ambigous regarding whether an empty collection is defined as a subsequence or not. Cheers, Henry

March 4, 2010

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by Gabriel Cotelli

Hi Henry, for the ANSI document on indexOfSubcollection:startingAt:, i think that 'aaaaa' indexOfSubcollection: '' startingAt: 1 must return 1, not 0. (and if the argument is empty the starting index must be returned) *Message: indexOfSubCollection: targetSequence startingAt: start Synopsis Answer the index of the first element of the receiver which is the start of a subsequence which matches targetSequence. Start searching at index start in the receiver. Answer 0 if no such subsequence is found. Definition: <sequenceReadableCollection> Each subsequence of the receiver starting at index start is checked for a match with targetSequence. To match, each element of a subsequence of the receiver must be equivalent to the corresponding element of targetSequence. Answer the index of the first element which begins a matching subsequence; no further subsequences are considered. Answer 0 if no such subsequence is found in the receiver, or if targetSequence is empty. The elements are traversed in the order specified by the #do: message for the receiver. * The problem here is probably that subsequence definition is missing in the standard. If an empty sequence is allowed as argument then I think that the index must be the result. Â¿Anybody has a formal definition of subsequence? I don't know if the beginsWith: in SequenceableCollection must return true to #(1 2 3) beginsWith: #(), but for String I still think that must do. Obviously there's some part of the protocol that should remain consistent. I will try to analyze that in deeper detail later. Regards, Gabriel On Thu, Mar 4, 2010 at 11:27 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Den 04.03.2010 14:40, skrev Julian Fitzell: > > I'm not sure, but in ANSI, indexOfSubcollection:startingAt: is defined > > as returning 0 (no match) for an empty collection. > > > If a string can not contain the empty string, then how can (and does) it > start/end with it? > IMHO, to be consistent, the set of what I contain should be a strict > superset of what I begin/end with. > > In that regards, according to the ansi-standard, returning false is > correct. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 4, 2010

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by StÃ©phane Ducasse

ok see '' isDifferentFrom: Character space :) Stupid me Stef On Mar 4, 2010, at 3:27 PM, Henrik Johansen wrote: > Den 04.03.2010 14:40, skrev Julian Fitzell: >> I'm not sure, but in ANSI, indexOfSubcollection:startingAt: is defined >> as returning 0 (no match) for an empty collection. >> > If a string can not contain the empty string, then how can (and does) it > start/end with it? > IMHO, to be consistent, the set of what I contain should be a strict > superset of what I begin/end with. > > In that regards, according to the ansi-standard, returning false is correct. > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 4, 2010

Re: [Pharo-project] String>>beginsWith: with empty strings issue

by Henrik Johansen

Den 04.03.2010 14:40, skrev Julian Fitzell: > I'm not sure, but in ANSI, indexOfSubcollection:startingAt: is defined > as returning 0 (no match) for an empty collection. > If a string can not contain the empty string, then how can (and does) it start/end with it? IMHO, to be consistent, the set of what I contain should be a strict superset of what I begin/end with. In that regards, according to the ansi-standard, returning false is correct. Cheers, Henry

March 4, 2010