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

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

by Chris Muller

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

March 4, 2010

Re: [Pharo-project] Problems using java code importer with inFusion under windows

by Eliot Miranda

Hi David, On Wed, Mar 3, 2010 at 4:29 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Wed, Mar 03, 2010 at 04:51:25PM +0100, Levente Uzonyi wrote: > > On Wed, 3 Mar 2010, Simon Denier wrote: > > > > > > > > On 3 mars 2010, at 03:34, David T. Lewis wrote: > > > > > >> On Tue, Mar 02, 2010 at 02:18:20PM +0100, Fabrizio Perin wrote: > > >>> Because the discussion about this topic happened on the moose mailing > list i > > >>> just update also the pharo mailing list. To summarize: > > >>> > > >>> I had problems using the importer of java code with inFusion on > Windows, at > > >>> the end i discovered that the primitives into > WindowsOSProcessAccessor just > > >>> fails during the initialization and that the process is not able to > access > > >>> the OS. There is also a bug report here: > > >>> > > >>> > http://code.google.com/p/moose-technology/issues/detail?id=321&q=OSProcess&… > > >> > > >> Hi Fabrizio, > > >> > > >> The failure that you are seeing is because the OSProcessPlugin is not > > >> present in your VM, and therefore the primitives are not there (so > really > > >> there is nothing to debug). > > >> > > >> OSProcess is not fully implemented on Windows. You can find some > information > > >> about OSProcess at http://wiki.squeak.org/squeak/708 > > >> > > >> If you have the option to use Unix/Linux or Mac, you should get better > results. > > > > > > > > > Hi David > > > > > > Is there other means to launch a command line (and external tools) form > a Windows VM then? > > > > You can give this a try: http://www.squeaksource.com/ProcessWrapper.html. > > Don't know if it works in Pharo or not. > > You can also run a Windows exe using FFI, and if you are comfortable > building your on VM you can build the OSProcessPlugin for Windows. > Both of these will allow you to run an external program, but will > not allow you to directly read the output of the external program > as you can do on unix systems with OSProcess. > I implemented code to do this on Windows and its in the Newspeak code base. If you can find it then good, otherwise let me know and I'll dig it out. > I think that ProcessWrapper will do what you need, so I suggest to > try that first for Windows. > > Dave > > _______________________________________________ > 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] Problems using java code importer with inFusion under windows

by David T. Lewis

On Wed, Mar 03, 2010 at 04:51:25PM +0100, Levente Uzonyi wrote: > On Wed, 3 Mar 2010, Simon Denier wrote: > > > > > On 3 mars 2010, at 03:34, David T. Lewis wrote: > > > >> On Tue, Mar 02, 2010 at 02:18:20PM +0100, Fabrizio Perin wrote: > >>> Because the discussion about this topic happened on the moose mailing list i > >>> just update also the pharo mailing list. To summarize: > >>> > >>> I had problems using the importer of java code with inFusion on Windows, at > >>> the end i discovered that the primitives into WindowsOSProcessAccessor just > >>> fails during the initialization and that the process is not able to access > >>> the OS. There is also a bug report here: > >>> > >>> http://code.google.com/p/moose-technology/issues/detail?id=321&q=OSProcess&… > >> > >> Hi Fabrizio, > >> > >> The failure that you are seeing is because the OSProcessPlugin is not > >> present in your VM, and therefore the primitives are not there (so really > >> there is nothing to debug). > >> > >> OSProcess is not fully implemented on Windows. You can find some information > >> about OSProcess at http://wiki.squeak.org/squeak/708 > >> > >> If you have the option to use Unix/Linux or Mac, you should get better results. > > > > > > Hi David > > > > Is there other means to launch a command line (and external tools) form a Windows VM then? > > You can give this a try: http://www.squeaksource.com/ProcessWrapper.html . > Don't know if it works in Pharo or not. You can also run a Windows exe using FFI, and if you are comfortable building your on VM you can build the OSProcessPlugin for Windows. Both of these will allow you to run an external program, but will not allow you to directly read the output of the external program as you can do on unix systems with OSProcess. I think that ProcessWrapper will do what you need, so I suggest to try that first for Windows. Dave

March 4, 2010

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

by Eliot Miranda

On Wed, Mar 3, 2010 at 1:50 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > Chris Muller wrote: > > On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > >> Isn't readability a matter of taste...? > > > > Not according to the pattern description; did you read it? It says, > > the "tendency of the eye to distinguish and interpolate vertical and > > horizontal lines. The square brackets used to signify blocks lead the > > eye to create the illusion of a whole rectangle even though one isn't > > there." For me, it's absolutely true. > > I was going from memory of Beck'isms, but I've read it just now. Now I > remember that I didn't like this rule the last time I read it. I still > think it's handwaving, without studies done with Smalltalk code, but > let's go along with the argument for now: the eye can distinguish > rectangles easily, so to have better readability, arrange '[' and ']' to > create a rectangular illusion. > I assure you that for a good many of us (me included) it works very well. > > In the first example: > > ifTrue: [self recomputeAngle] > > I see a rectangle formed by the '[' and ']' on the same line. So, I buy > the argument. > > In the second example given: > > ifTrue: > [self clearCaches. > self recomputeAngle] > > The rectangle is getting harder for me to spot, and the argument is > starting to feel sketchy to me. > > What happens with more lines: > > ifTrue: > [self clearCaches. > self current soleInstance yada yada blah blah > self recomputeAngle] > Where's the rectangle now? Compare this with the highly disturbing fact > (to me, anyways) that the first line should have the same level of > indent as the rest of the lines in the block, but it's tabbed differently. > I see it immediately and it looks elegant and comprehensible. It doesn't for you. We're all wired differently. I suspect that if you're a visual thinker Beck's rule is for you, and if you're not you'll hate it. > > > I'm not sure what "hanging left bracket" is. In Rectangular Block, > > subsequent lines have the "same tabbing" so it may be the same thing. > > I just made up the term because some other poster had mentioned they'd > never seen code where the '[' was left dangling at the end of a line. I > should have give an example: > > ifTrue: [ > line1 yo. > line2 eh ] > Horrible, horrible, horrible ;) Poor block. The block is an object, not braces in some pathetic C derivative. It needs love and respect. Its beginning doesn't belong to the ifTrue:, its entirety is an argument to ifTrue:. The rectangular rule emphasises this (for those that can see it ;) ). > > > I don't know how anything related to formatting could be faster than > > having the machine doing it. > > When the automated formatting does a poor job, and you have do undo it > manually. Or, you refactor your code just so the automated formatting > does a good job. > > > But if you are not using > > automatic-formatting, then you won't really be affected by these > > proposed pretty-print changes.. > > This thread started out talking about how the core Pharo code base > should be formatted. Maybe the Squeak thread was only about > pretty-printing. > 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. 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. 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 :) best Eliot P.S. and don't get me started on the trailing period (putrid excressence), or the space between ^ and the return expression (vomitous mass). > -- > Yanni > > > _______________________________________________ > 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] SmalltalkImage current vs Smalltalk : plan B

by Nicolas Cellier

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

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by Henrik Sperre Johansen

On 03.03.2010 22:21, Alexandre Bergel wrote: >> The paper talks about using stack pointer and program counter as >> identifiers, I doubt stack depth as returned by such a method will >> provide a good enough granularity to do proper disambiguation. >> (not to mention the main reason for using them is that they can be >> gotten with virtually no overhead...) > Not only the stack depth. But the function identity is given by the > compiled method reference. > Associating the stack depth with the compiled method will do the job > apparently. > > Cheers, > Alexandre > Read a little past the abstract, and you'll understand what I was trying to tell you. Cheers, Henry

March 3, 2010

[Pharo-project] Fwd: Pharo by Example vol 2: new chapter available

by StÃ©phane Ducasse

Thanks laurent Stef Begin forwarded message: > From: laurent laffont <laurent.laffont(a)gmail.com> > Date: March 3, 2010 10:09:32 PM GMT+01:00 > To: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Subject: Re: [Pharo-project] Pharo by Example vol 2: new chapter available > > Some notes: > > Page 1: The basic idea behing exception .... I would expect a schema to show the workflow. > > Page 8: When an exception is signaled, the exception handling mechanism ....I've read it 3 times (for something finally quite simple), maybe it needs a sequence diagram or reformulation. > > Section 1.15: How exceptions are implemented. I had to read several times to understand, lot of informations to handle at once. > > Page 27 (bottom): For example, in method 1.1 ... specify "on page 19" or put the snippet again so we can easily compare with method 1.2. > > I like the "real code" examples. The "How..." sections too. > > When not to use Exceptions: not to "hide errors". I have too many times seen try ... catch ... to hide errors to the users. > > Maybe add a "When to use Exceptions" section, reminding the "Crash early" principle. > > Laurent Laffont > > > On Tue, Mar 2, 2010 at 2:26 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 3, 2010

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

by Yanni Chiu

Chris Muller wrote: > On Wed, Mar 3, 2010 at 9:53 AM, Yanni Chiu <yanni(a)rogers.com> wrote: >> Isn't readability a matter of taste...? > > Not according to the pattern description; did you read it? It says, > the "tendency of the eye to distinguish and interpolate vertical and > horizontal lines. The square brackets used to signify blocks lead the > eye to create the illusion of a whole rectangle even though one isn't > there." For me, it's absolutely true. I was going from memory of Beck'isms, but I've read it just now. Now I remember that I didn't like this rule the last time I read it. I still think it's handwaving, without studies done with Smalltalk code, but let's go along with the argument for now: the eye can distinguish rectangles easily, so to have better readability, arrange '[' and ']' to create a rectangular illusion. In the first example: ifTrue: [self recomputeAngle] I see a rectangle formed by the '[' and ']' on the same line. So, I buy the argument. In the second example given: ifTrue: [self clearCaches. self recomputeAngle] The rectangle is getting harder for me to spot, and the argument is starting to feel sketchy to me. What happens with more lines: ifTrue: [self clearCaches. self current soleInstance yada yada blah blah self recomputeAngle] Where's the rectangle now? Compare this with the highly disturbing fact (to me, anyways) that the first line should have the same level of indent as the rest of the lines in the block, but it's tabbed differently. > I'm not sure what "hanging left bracket" is. In Rectangular Block, > subsequent lines have the "same tabbing" so it may be the same thing. I just made up the term because some other poster had mentioned they'd never seen code where the '[' was left dangling at the end of a line. I should have give an example: ifTrue: [ line1 yo. line2 eh ] > I don't know how anything related to formatting could be faster than > having the machine doing it. When the automated formatting does a poor job, and you have do undo it manually. Or, you refactor your code just so the automated formatting does a good job. > But if you are not using > automatic-formatting, then you won't really be affected by these > proposed pretty-print changes.. This thread started out talking about how the core Pharo code base should be formatted. Maybe the Squeak thread was only about pretty-printing. -- Yanni

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by Alexandre Bergel

> The paper talks about using stack pointer and program counter as > identifiers, I doubt stack depth as returned by such a method will > provide a good enough granularity to do proper disambiguation. > (not to mention the main reason for using them is that they can be > gotten with virtually no overhead...) Not only the stack depth. But the function identity is given by the compiled method reference. Associating the stack depth with the compiled method will do the job apparently. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 3, 2010

Re: [Pharo-project] Quickly getting the method call stack depth

by Henrik Sperre Johansen

On 03.03.2010 21:35, Alexandre Bergel wrote: > Indeed. Thanks! > > >> This is more than twice as fast, though it may be still too slow for >> your >> needs: >> >> | depth running | >> running := thisContext. >> depth := 1. >> [ (running := running instVarAt: 1) == nil ] >> whileFalse: [ depth := depth + 1 ]. >> depth The paper talks about using stack pointer and program counter as identifiers, I doubt stack depth as returned by such a method will provide a good enough granularity to do proper disambiguation. (not to mention the main reason for using them is that they can be gotten with virtually no overhead...) Cheers, Henry

March 3, 2010