- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Object>>at:modify:???

by Mariano Martinez Peck

On Sat, Oct 23, 2010 at 1:32 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Ok we can deprecate it. > > ys, but please please please use deprecated: anExplanationString on: date in: version cheers mariano > On Oct 22, 2010, at 11:04 PM, Hernan Wilkinson wrote: > > > In a 1.1 image I have, the class HttpRequest is using that message... > > > > On Thu, Oct 21, 2010 at 4:08 PM, stephane ducasse < > stephane.ducasse(a)free.fr> wrote: > > I would like to deprecate the following method since nobody use it. > > What do 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 > > > > > > > > -- > > HernÃ¡n Wilkinson > > Agile Software Development, Teaching & Coaching > > Mobile: +54 - 911 - 4470 - 7207 > > email: hernan.wilkinson(a)10Pines.com > > site: http://www.10Pines.com > > > > _______________________________________________ > > 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 >

Oct. 23, 2010

Re: [Pharo-project] a useful check

by StÃ©phane Ducasse

What is the way to fix that? > SystemNavigation new browseAllSelect: > [:m| | is | > is := InstructionStream on: m. > is scanFor: [:b| b = 143 and: [(m at: is thirdByte * 256 + is fourthByte + is pc + 4) = 135]]] lookForCode: code ifDifferent: handleBlock "We are expecting a certain numeric code next. However, in the FTP protocol, multiple lines are allowed. If the response is multi-line, the fourth character of the first line is a $- and the last line repeats the numeric code but the code is followed by a space. So it's possible that there are more lines left of the last response that we need to throw away. We use peekForAll: so that we don't discard the next response that is not a continuation line." "check for multi-line response" (self lastResponse size > 3 and: [(self lastResponse at: 4) = $-]) ifTrue: ["Discard continuation lines." [ | headToDiscard | headToDiscard := self lastResponse first: 4. [[self stream peekForAll: headToDiscard] whileTrue: [self stream nextLine]] on: Exception do: [:ex | ^handleBlock value: nil]]]. ^ super lookForCode: code ifDifferent: handleBlock

Oct. 23, 2010

Re: [Pharo-project] some patterns I would like to **kill**

by StÃ©phane Ducasse

I think that if you have a container that contains morphs probably findA and other queries are useful. Now for a button that is also at the same place a field is the best. Stef On Oct 22, 2010, at 11:14 PM, Schwab,Wilhelm K wrote: > Stef, > > #respondsTo: - no argument. More defensive programming (aka masked bugs). Tests like this have their place, but are over-used in Squeak. > > Using #submorphs *might* be easier to defend. Morphs were designed to be usable in large numbers, and one might argue (playing Devil's Advocate here) that lookups are cheaper than the additional gc load. An instance variable could also cache stale information. Of course, for something that is accessed frequently, an instance variable avoids the lookup and I agree that it is cleaner and easier to read. > > Bill > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of stephane ducasse [stephane.ducasse(a)free.fr] > Sent: Thursday, October 21, 2010 4:47 PM > To: Pharo Development > Subject: [Pharo-project] some patterns I would like to **kill** > > Hi > > I was reading Pluggable and friends > I identified some patterns. > > > The respondsTo plague > Examples: > > color := self fillStyle asColor. > (self labelMorph respondsTo: #enabled:) > ifTrue: [self labelMorph enabled: self enabled]. > (self labelMorph respondsTo: #interactionState:) > ifTrue: [self labelMorph interactionState: self interactionState] > > (self labelMorph respondsTo: #enabled:) ifTrue: [ > self labelMorph enabled: aBoolean]. > > (self enabled not and: [self label isMorph and: [(self label respondsTo: #enabled:) not]]) > > > by construction a labelObject should be a morph and it should answer enabled: and the case where this is not the case should be fixed. > > > Using submorphs to avoid one single inst var makes code quite ugly to read: > > > labelMorph > "Answer the actual label morph." > > self hasSubmorphs ifFalse: [^nil]. > self firstSubmorph hasSubmorphs ifFalse: [^nil]. > ^self firstSubmorph firstSubmorph > > > > > > _______________________________________________ > 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

Oct. 23, 2010

Re: [Pharo-project] Object>>at:modify:???

by StÃ©phane Ducasse

Ok we can deprecate it. On Oct 22, 2010, at 11:04 PM, Hernan Wilkinson wrote: > In a 1.1 image I have, the class HttpRequest is using that message... > > On Thu, Oct 21, 2010 at 4:08 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I would like to deprecate the following method since nobody use it. > What do 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 > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2010

Re: [Pharo-project] Pharo article in linuxMag fr

by GermÃ¡n Arduino

Hi Noury: Thanks by the offer! I will try to be tunned to the next year event. Cheers. 2010/10/23 Noury Bouraqadi <bouraqadi(a)gmail.com>: > > On 22 oct. 2010, at 16:47, GermÃ¡n Arduino wrote: > >> Yes, very interesting. >> >> Here at Argentina we have an annual event about free software, this >> year schedule is: >> >> http://www.jornadasregionales.org/jrsl2010v2/schedule/index >> >> Could be interesting to present Pharo/Seaside/Pier here, may be next year..... >> > Yes. You can get some support for that from ESUG (e.g. travel costs). > > Noury > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 23, 2010

[Pharo-project] [update 1.2] #12205

by Marcus Denker

12205 ----- Issue 2619: ignore vm parameters with nil value in MessageTally, so it can be used in Cog Issue 1885: Disable Scroll Wrapping in PluggableListMorph Issue 3142: Updater package has no repository Issue 2876: setStandardClass: aClass methodSymbol: methodSym (first part) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

Re: [Pharo-project] Pavel can you check :)

by StÃ©phane Ducasse

When I clicked on a package, it got downloaded to the package cache using the writeDefinitions: method writeDefinitions: aCollection "initStream is an ugly hack until we have proper init defs" initializers := Dictionary new. (MCDependencySorter sortItems: aCollection) do: [:ea | ea accept: self] displayingProgress: 'Writing definitions...'. (Class superclassOrder: (initializers keys collect: [:each | Smalltalk classOrTraitNamed: each])) do: [:class | stream nextPutAll: (initializers at: class name) contents ]. Now it is bugging because initializers keys could contain a class that is not in the image and then put nil in the set The previous version of the method was: writeDefinitions: aCollection "initStream is an ugly hack until we have proper init defs" initStream := String new writeStream. (MCDependencySorter sortItems: aCollection) do: [:ea | ea accept: self] displayingProgress: 'Writing definitions...'. stream nextPutAll: initStream contents. - The previous version did not save initializers or may be different - Now the changes does not take into account classes that are not in the image. And this one should still be saved On Oct 23, 2010, at 12:22 PM, StÃ©phane Ducasse wrote: > Apparently when we browse > Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) > > we get a problem because there is a nil in the set. > > Can you have a look? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 23, 2010

[Pharo-project] Pavel can you check :)

by StÃ©phane Ducasse

Apparently when we browse Compiler-eem.155 from the squeak trunk (ScriptLoader new addExtraRepositories) we get a problem because there is a nil in the set. Can you have a look? Stef

Oct. 23, 2010

[Pharo-project] [update 1.2] #12204

by Marcus Denker

12204 ----- Issue 2868: allClassesUsingPool: allClassesUsingPoolVariable: for systemNavigation Issue 3046: BUG: LineMorph class>>from:to:color:width: returns a PolygonMorph Issue 3130: MethodReference >> #isLocalSelector should not be part of Monticello package Issue 3095: Character isLiteral is in wrong category Issue 3134: Cleaning uniclasses from smartRefStream -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 23, 2010

Re: [Pharo-project] Pharo article in linuxMag fr

by Noury Bouraqadi

On 22 oct. 2010, at 16:47, GermÃ¡n Arduino wrote: > Yes, very interesting. > > Here at Argentina we have an annual event about free software, this > year schedule is: > > http://www.jornadasregionales.org/jrsl2010v2/schedule/index > > Could be interesting to present Pharo/Seaside/Pier here, may be next year..... > Yes. You can get some support for that from ESUG (e.g. travel costs). Noury

Oct. 23, 2010