- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by StÃ©phane Ducasse

Excellent You know what I'm dreaming of (may be this is already in) you get the list of methods in the method list and you start to type and automatically all the methods not matching are greyed out or we only see the methods matching the beginning. Stef On Jan 9, 2011, at 10:26 AM, Johan Brichau wrote: > Andy agreed to pair program it with me, starting next week. Unless someone beats us to it ;-) > > On 09 Jan 2011, at 10:12, StÃ©phane Ducasse wrote: > >> + 1 >> >> does anybody want to implement this hovering excellent idea. >> >> >> On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote: >> >>> And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. >>> We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more.... >> > >

Jan. 9, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Johan Brichau

Andy agreed to pair program it with me, starting next week. Unless someone beats us to it ;-) On 09 Jan 2011, at 10:12, StÃ©phane Ducasse wrote: > + 1 > > does anybody want to implement this hovering excellent idea. > > > On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote: > >> And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. >> We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more.... >

Jan. 9, 2011

[Pharo-project] 4 days sprints in february

by StÃ©phane Ducasse

Hi guys we are brainstorming with alain plantec to organize a sprint at roscoff (close to brest - excellent sea food). The set up would be: - 21 - 24 of february - this is holiday time here. I will rent a house with the kids there. - we can get access to a room for 450 Euros (break included). - the hosting is 50 Euros per day breakfast included - lunches are about 15 euros. So are some of you interested by participating. We could ask some sponsoring to ESUG. http://maps.google.fr/maps?client=safari&rls=en&q=roscoff&oe=UTF-8&redir_es… http://www.google.fr/images?client=safari&rls=en&q=roscoff&oe=UTF-8&redir_e… Stef

Jan. 9, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by StÃ©phane Ducasse

+ 1 does anybody want to implement this hovering excellent idea. On Jan 9, 2011, at 10:02 AM, Johan Brichau wrote: > And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. > We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more....

Jan. 9, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Johan Brichau

On 08 Jan 2011, at 23:07, Nicolas Cellier wrote: > You mean something like: > > | collec | > collec := #('foo' 'bar'). > shallowCopy := collec copy. > self assert: collec first == shallowCopy first > > Well, yes those copies are shallow, but what's the difference between > copy, copyFrom:to: first, first: etc... with this respect ? I think Stephan intended to say that the return result of #first is not a copy of (parts of) the receiver. #first is an accessor, not a copy message. And yes, the rule of thumb is that one reads the comments (or implementation) of a method to understand it, rather than (only) trying to guess it's semantics from its selector. We all got used to coding like that in Smalltalk. However, it's _just_ a rule of thumb that comments on top of the method body should document the method. Not all methods do it, and people coming from different languages and development environments are not immediately comfortable because they 'need to look at the implementation of an API to understand it'. So, I think there is something we can learn from other development environments: in XCode, for example, you can request the documentation of a method in a small 'hover window' by a <ctrl>+<click> on the method name. I wonder if such a system in Smalltalk development environment would make documenting a method more important, and thus, force people to write and use it more.... Johan

Jan. 9, 2011

Re: [Pharo-project] Issue 3420 in pharo: ReleaseTest>>#testUndeclared is failing

by pharo＠googlecode.com

Comment #1 on issue 3420 by guillermopolito: ReleaseTest>>#testUndeclared is failing http://code.google.com/p/pharo/issues/detail?id=3420 Marcus, what is the hudson build code you are talking about? :)

Jan. 9, 2011

Re: [Pharo-project] Issue 3514 in pharo: Failing Test: NewTextMorphTests.testAcceptContents

by pharo＠googlecode.com

Comment #1 on issue 3514 by guillermopolito: Failing Test: NewTextMorphTests.testAcceptContents http://code.google.com/p/pharo/issues/detail?id=3514 This is because TextEditor>>accept does: accept "Save the current text of the text being edited as the current acceptable version for purposes of canceling. Allow my morph to take appropriate action" morph enableTextChange ifTrue: [morph acceptContents] and morph (a NewTextMorph) dnu #enableTextChange. Does NewTextMorph has the capability of beign enabled or disabled? Shoud it do only morph acceptContents ?

Jan. 9, 2011

Re: [Pharo-project] About preloaded packages

by Tudor Girba

+1 Doru On 8 Jan 2011, at 17:02, StÃ©phane Ducasse wrote: > > On Jan 8, 2011, at 4:42 PM, Schwab,Wilhelm K wrote: > >> Stef, >> >> I'm not sure I follow. I think we agree that loading all configurations and running tests is good. > > I meant that the configurations do not have to be loaded in the image. > >> I understand why the web image went away when it took somebody's time time build it, but the Hudson server can do that work now. It seems reasonable to leave a range of targets that might be of value to people. > > yes now somebody should maintain the configuration and fix conflict. > >> There could be a few likely useful targets (minimal, dev, web) and then one with absolutely everything that is mostly for testing. But if somebody wants to use that, why not leave it on the server so they can get it? > > because who maintains if there is a bug due to a conflict. > Building the seaside image took lukas time and effort. I'm learned that things do not magically work. > So if somebody stands up and say ok I'm responsible for the imageXZK why not and we can set up hudson to build it. > Now we (the core minimal team) should spend time on getting the infrastructure right on tracks because this is an enabler of the future. > >> >> Bill >> >> >> >> ________________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] >> Sent: Saturday, January 08, 2011 10:30 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] About preloaded packages >> >>> It would also like a PharoBloat image built by Hudson with all ConfigurationOfXXX which are supposed to work on all operating systems. >> >> Not loaded :) >> Just published in the right squeaksource repository and validated (run, tests run and results shown....) via an hudson server. >> > > -- www.tudorgirba.com "Obvious things are difficult to teach."

Jan. 8, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken (pharo@googlecode.com)

by Nicolas Cellier

2011/1/8 Stephan Eggermont <stephan(a)stack.nl>: > Nicolas wrote: >>Then group the selectors (first, first: etc..), explain that they are >>extensions, and don't need a copy prefix, because anyway most messages >>will do a copy. > > You are aware first doesn't copy, do you? The explanation should be > that you always have to take a look at the implementation to see if it copies > or not (or sometimes), and explain when it doesn't matter (small integers, characters). > > Stephan > > You mean something like: | collec | collec := #('foo' 'bar'). shallowCopy := collec copy. self assert: collec first == shallowCopy first Well, yes those copies are shallow, but what's the difference between copy, copyFrom:to: first, first: etc... with this respect ? Nicolas

Jan. 8, 2011

[Pharo-project] cog 2343 fails smoke test on linux

by Matthew Fulmer

On Fri, Jan 07, 2011 at 06:15:52PM -0800, Eliot Miranda wrote: > Hi All, > > find new VMs in > VM.r2342/<http://www.mirandabanda.org/files/Cog/VM/VM.r2342/> > (SimpleStackBasedCogit) > and VM.r2343/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> ( > StackToRegisterMappingCogit). 2343 seems fine but I appear to have > introduced a regression into 2342. The 2343 VMs fix both of the bugs > mentioned by Matthew and Yoshiki: > > As usual I'm very grateful for you pounding on these (ok, at least the 2343 > VM :) ). Erm, at least on my ubuntu linux box, 2343 won't even launch the trunk image without segfaulting on startup: http://ftp.squeak.org/4.2/Squeak4.2-10856-beta.zip --------------------------------------------------- ./cog.r2343/bin/i686-pc-linux-gnu/squeak Squeak4.2-10856-beta.image Segmentation fault Smalltalk stack dump: 0xbfe28ba0 M IdentityDictionary>scanFor: 2009736128: a(n) IdentityDictionary 0xbfe28bc8 M IdentityDictionary(Dictionary)>at:ifAbsent: 2009736128: a(n) IdentityDictionary 0xbfe28bf0 I Preferences class>preferenceAt:ifAbsent: 2010414284: a(n) Preferences class 0xbfe28c18 I Preferences class>valueOfPreference:ifAbsent: 2010414284: a(n) Preferences class 0xbfe28c40 I Preferences class>valueOfFlag:ifAbsent: 2010414284: a(n) Preferences class 0xbfe28c68 I Preferences class>swapMouseButtons 2010414284: a(n) Preferences class 0xbfe28c88 I InputSensor class>installMouseDecodeTable 2010135976: a(n) InputSensor class 0xbfe28ca8 I InputSensor class>startUp 2010135976: a(n) InputSensor class 0xbfe28cc0 M InputSensor class(Behavior)>startUp: 2010135976: a(n) InputSensor class 0xbfe28cec M [] in SmalltalkImage>send:toClassesNamedIn:with: 2011753028: a(n) SmalltalkImage 0xbfe28d14 I OrderedCollection>do: 2011782444: a(n) OrderedCollection 0xbfe28d3c I SmalltalkImage>send:toClassesNamedIn:with: 2011753028: a(n) SmalltalkImage 0xbfe28d68 I SmalltalkImage>processStartUpList: 2011753028: a(n) SmalltalkImage 0xbfe28d94 I SmalltalkImage>snapshot:andQuit:embedded: 2011753028: a(n) SmalltalkImage 2019217856 s SmalltalkImage>snapshot:andQuit: 2019217524 s SmalltalkImage>saveImageInFileNamed: 2019217432 s SmalltalkImage>saveAs: 2019193036 s SmalltalkImage>saveAs 2019192920 s TheWorldMenu>doMenuItem:with: 2019192828 s [] in MenuItemMorph>invokeWithEvent: 2019192712 s BlockClosure>ensure: 2019192620 s CursorWithMask(Cursor)>showWhile: 2019192528 s MenuItemMorph>invokeWithEvent: 2019192436 s MenuMorph 2019192344 s [] in MenuMorph>keyStroke: 2019192252 s [] in Array(Collection)>detect:ifNone: 2019192088 s Array(SequenceableCollection)>do: 2019191996 s Array(Collection)>detect:ifNone: 2019191864 s MenuMorph>keyStroke: 2019191772 s MenuMorph(Morph)>handleKeystroke: 2019191680 s KeyboardEvent>sentTo: 2019191588 s MenuMorph(Morph)>handleEvent: 2019191496 s MorphicEventDispatcher>dispatchDefault:with: 2019191388 s MorphicEventDispatcher>dispatchEvent:with: 2019191256 s MenuMorph(Morph)>processEvent:using: 2019191164 s MenuMorph(Morph)>processEvent: 2019191072 s MenuMorph>handleFocusEvent: 2019190980 s [] in HandMorph>sendFocusEvent:to:clear: 2019190888 s [] in PasteUpMorph>becomeActiveDuring: 2019190708 s BlockClosure>on:do: 2019190588 s PasteUpMorph>becomeActiveDuring: 2019190496 s HandMorph>sendFocusEvent:to:clear: 2019190404 s HandMorph>sendEvent:focus:clear: 2019190272 s HandMorph>sendKeyboardEvent: 2019190180 s HandMorph>handleEvent: 2019190016 s HandMorph>processEvents 2019189900 s [] in WorldState>doOneCycleNowFor: 2019189808 s Array(SequenceableCollection)>do: 2019189708 s WorldState>handsDo: 2019189616 s WorldState>doOneCycleNowFor: 2019189524 s WorldState>doOneCycleFor: 2019189432 s PasteUpMorph>doOneCycle 2013075760 s [] in Project class>? 2013075628 s [] in BlockClosure>newProcess Most recent primitives basicNew size at: basicNew: decompress:fromByteArray:at: beCursorWithMask: vmParameterAt:put: vmParameterAt:put: ensure: valueNoContextSwitch wait specialObjectsArray new: at:put: signal basicNew new: at: identityHash stringHash:initialHash: perform:with: millisecondClockValue signal identityHash stringHash:initialHash: size \\ at: at: perform:with: actualScreenSize species species supportsDisplayDepth: basicNew: basicNew beDisplay stringHash:initialHash: size \\ size \\ = perform:with: beCursorWithMask: stringHash:initialHash: = perform:with: zsh: abort ./cog.r2343/bin/i686-pc-linux-gnu/squeak Squeak4.2-10856-beta.image -- Matthew Fulmer (a.k.a. Tapple)

Jan. 8, 2011