- Pharo-dev - lists.pharo.org

[Pharo-project] O2 does not run on PharoCore 1.1
by Alexandre Bergel March 4, 2010

March 4, 2010

Unfortunately, I spotted some important bugs. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Re: [Pharo-project] about code formatting in pharo
by Dale Henrichs March 4, 2010

March 4, 2010

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

6 7

[Pharo-project] Fwd: [Moose-dev] Re: ConfigurationOfMetacello and OB
by Lukas Renggli March 4, 2010

March 4, 2010

Sorry, forgot to add the Pharo list ... ---------- Forwarded message ---------- From: Lukas Renggli <renggli(a)gmail.com> Date: 4 March 2010 20:13 Subject: Re: [Moose-dev] Re: ConfigurationOfMetacello and OB To: Related to the development of Moose and other related tools <moose-dev(a)iam.unibe.ch> I am looking into this. I reply to the Pharo list, I think the Moose list is the wrong one. The refactoring engine seems to work well. All tests pass. OmniBrowser is more difficult. There are 7 tests failing, and there are 8 errors. There is a large number of deprecated code that OB is calling. What am I supposed to do so that OB continues to work in Pharo 1.0 and 1.1? Can I expect that people have the deprecated warnings disabled? - How are menus registered? TheWorldMenu does not exist any longer. - What is the replacement for #intialExtent? Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch -- Lukas Renggli http://www.lukas-renggli.ch

5 9

Re: [Pharo-project] [Moose-dev] Re: Fwd: Re: ConfigurationOfMetacello and OB
by Lukas Renggli March 4, 2010

March 4, 2010

> Yes, an OBPlatform for each major version... Well, the problem is that ... OBPlatform OBMorphicPlatform OBShoutPlatform That doesn't really work without an explosion of classes and I don't feel like changing all that :-( Lukas > > > Dale > -- Lukas Renggli http://www.lukas-renggli.ch

2 3

Re: [Pharo-project] ConfigurationOfMetacello and OB
by Dale Henrichs March 4, 2010

March 4, 2010

Alexandre, You _can_ load Metacello without requiring OB. The current default is to _not_ include the tools (at one point in time OB was required, but with more recent versions that is no longer the case). I just loaded ConfigurationOfMetacello into PharoCore-1.1-11239 this morning: Gofer new gemsource: 'metacello'; package: 'ConfigurationOfMetacello'; load. ConfigurationOfMetacello project latestVersion load ...doesn't help with not being able to load OB though:) Dale ----- "Alexandre Bergel" <alexandre(a)bergel.eu> wrote: | Hi all, | | Installing ConfigurationOfMetacello requires the installation of OB. | | However, OB does not properly install in Core 1.1. | Is there something we can do against that? It would be great to do | so. | | Cheers, | Alexandre | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | | | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0

[Pharo-project] ConfigurationOfMetacello and OB
by Alexandre Bergel March 4, 2010

March 4, 2010

Hi all, Installing ConfigurationOfMetacello requires the installation of OB. However, OB does not properly install in Core 1.1. Is there something we can do against that? It would be great to do so. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

[Pharo-project] String>>beginsWith: with empty strings issue
by Gabriel Cotelli March 4, 2010

March 4, 2010

Hi, I noticed that 'pharo' beginsWith: '' returns false. Is that Ok? I expect that this returns true, because the empty string is a prefix (and suffix) of any other string. Similar behavior exhibits endsWith:. This seems a bug to me. What do you think? In case we acknowledge it's a bug I can post an entry in the issue tracker and tonight upload a SLICE with the fix. Regards, Gabriel

4 8

[Pharo-project] about code formatting in pharo
by Torsten Bergmann March 4, 2010

March 4, 2010

>what do you mean by now used? >Did they change that recently? According to http://planetmisc.squeak.org/ a new package Compiler-cmm.131.mcz is now in Squeak inbox and may find its way into trunk ... >I don't like Beck's rule "3. Rectangular Block" vs. >So for me personally, Beck's rule 3 is the one that looks better. And there we have them: discussions on what looks better :) Bye T. -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

10 15

[Pharo-project] SmalltalkImage current vs Smalltalk : plan B
by Nicolas Cellier March 4, 2010

March 4, 2010

For now, plan A has more votes than plan B. plan A: move all SmalltalkImage methods back into SystemDictionary in trunk. Let SmalltalkImage current ^Smalltalk for crossfork compatibility plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class = SystemDictionary. Use messages indirections like: Smalltalk vm imagePath Smalltalk commandLine optionAt: 2. etc... (see previous thread) At 1st step, they are not much different: both unify Smalltalk and SmalltalkImage current API. Also Plan A is much simpler, thus attractive. But: - Plan A is essentially coming back to 3.8 statu quo. - Plan B is essentially introducing message indirections Advantages of plan B I see for the future: - cleaner separation of concerns - less vulnerable to refactoring (thanks to messages indirection) - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...) easier thru messages Last, I do not desesperate to sell plan B to other forks. See the outline pf plan B below. So do you still buy plan A ? Nicolas ------------------------------------------ OUTLINE OF PLAN B : ------------------------------------------ PART I - Fusion of the 2 APIs in 1 1) add a globals instance variable to SmalltalkImage 2) initialize this instance variable SmalltalkImage current globals: Smalltalk 3) implement SystemDictionary methods in use to SmalltalkImage, and redirect them through globals MessageSentToGlobalFinder testMessagesSentToSmalltalk may help 4) initialize Smalltalk at: Smalltalk put: SmalltalkImage current. PART II - Refactoring 1) add a few messages in SmalltalkImage (vm ^self) 2) refactor users of SmalltalkImage current -> Smalltalk vm (or Smalltalk commandLine or...) This is the compatibility layer which will enable cross fork compatibility PART III - Provide cross fork compatibility layers: simple, Cuis and Pharo and Squeak3.8 and... just have to respond to Smalltalk vm (and a few others) either ^self or ^SmalltalkImage current or whatever they prefer PART IV - deeper refactorings 1) split SmalltalkImage at will (no precipitation good Rationale SHALL be provided). 2) introduce other Smalltalk hooks for not so well known classes (SystemNavigation / SourceFiles etc...)

3 4

March 4, 2010

Hi guys We just released a new chapter for Pharo by Example Vol.2 on Exceptions http://pharobyexample.org/ Let us know what you think. Stef

8 20