December 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Fwd: [squeak-dev] The Trunk: Network-ar.42.mcz

by StÃ©phane Ducasse

> > mike > > is it worth/ integrable in pharo? > > Stef > > Begin forwarded message: > >> From: commits(a)source.squeak.org >> Date: December 4, 2009 7:19:29 PM GMT+01:00 >> To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org >> Subject: [squeak-dev] The Trunk: Network-ar.42.mcz >> Reply-To: squeak-dev(a)lists.squeakfoundation.org >> >> Andreas Raab uploaded a new version of Network to project The Trunk: >> http://source.squeak.org/trunk/Network-ar.42.mcz >> >> ==================== Summary ==================== >> >> Name: Network-ar.42 >> Author: ar >> Time: 4 December 2009, 10:19:10 am >> UUID: bd7d181a-24b5-ac4c-a9a3-28a2b472d669 >> Ancestors: Network-ul.41 >> >> Fixes for SMTPClient: >> - http://bugs.squeak.org/view.php?id=6843 >> - http://bugs.squeak.org/view.php?id=6768 >> - Add an accessor for the localHostName in SMPTClient since Unix systems often return 'localhost.localdomain' or '0.0.0.0' from NetNameResolver localHostName which is not accepted by many MTAs. If client code knows the name from elsewhere (by means of configuration etc.) it can provide it explicitly. >> >> =============== Diff against Network-ul.41 =============== >> >> Item was changed: >> ----- Method: SMTPClient>>encodeString: (in category 'utility') ----- >> encodeString: aString >> + | str dec out | >> - | str dec | >> str := String new: (aString size * 4 / 3 + 3) ceiling. >> dec := Base64MimeConverter new. >> dec >> + mimeStream: (out := WriteStream on: str); >> - mimeStream: (WriteStream on: str); >> dataStream: (ReadStream on: aString); >> + multiLine: false; >> mimeEncode. >> + ^out contents! >> - ^ str! >> >> Item was added: >> + ----- Method: SMTPClient>>localHostName: (in category 'public protocol') ----- >> + localHostName: aString >> + "The local host name for purposes of identifying the the server. >> + If nil, NetNameResolver localHostName will be used." >> + >> + ^self connectionInfo at: #localHostName put: aString! >> >> Item was added: >> + ----- Method: SMTPClient>>localHostName (in category 'public protocol') ----- >> + localHostName >> + "The local host name for purposes of identifying the the server. >> + If nil, NetNameResolver localHostName will be used." >> + >> + ^self connectionInfo at: #localHostName ifAbsent: [NetNameResolver localHostName]! >> >> Item was added: >> + ----- Method: SMTPClient>>useHelo: (in category 'public protocol') ----- >> + useHelo: aBoolean >> + "Tell client to use HELO instead of EHLO. HELO is the old protocol and >> + an old server may require it instead of EHLO." >> + >> + ^self connectionInfo at: #useHelo put: aBoolean! >> >> Item was changed: >> ----- Method: SMTPClient>>login (in category 'private protocol') ----- >> login >> self user ifNil: [^self]. >> + self initiateSession. >> self sendCommand: 'AUTH LOGIN ' , (self encodeString: self user). >> [self checkResponse] >> on: TelnetProtocolError >> do: [ :ex | ex isCommandUnrecognized ifTrue: [^ self] ifFalse: [ex pass]]. >> self sendCommand: (self encodeString: self password). >> self checkResponse! >> >> Item was changed: >> ----- Method: SMTPClient>>initiateSession (in category 'private protocol') ----- >> initiateSession >> + "EHLO <SP> <domain> <CRLF>" >> - "HELO <SP> <domain> <CRLF>" >> >> + self sendCommand: (self useHelo ifTrue:['HELO '] ifFalse: ['EHLO ']) , self localHostName. >> - "self checkResponse." >> - self sendCommand: 'HELO ' , NetNameResolver localHostName. >> self checkResponse. >> ! >> >> Item was added: >> + ----- Method: SMTPClient>>useHelo (in category 'public protocol') ----- >> + useHelo >> + "If client use HELO instead of EHLO. HELO is the old protocol and >> + an old server may require it instead of EHLO." >> + >> + ^self connectionInfo at: #useHelo ifAbsent: [false]! >> >> Item was removed: >> - ----- Method: SMTPClient class>>openOnHost:port: (in category 'instance creation') ----- >> - openOnHost: hostIP port: portNumber >> - >> - | client | >> - client := super openOnHost: hostIP port: portNumber. >> - client initiateSession. >> - ^client! >> >> > > > >

Dec. 18, 2009

Re: [Pharo-project] Refactoring Browser depenences

by Mariano Martinez Peck

On Fri, Dec 18, 2009 at 6:31 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > Exactly, > > > Refactoring-Spelling depends on Refactoring-Core > > Refactoring-Core depends on AST-Core > > AST-Core doesn't depend on anything. > > > There are more ? and dependences with external packages? > > No more dependencies. > ok... > > However, this configuration is hardly any useful, because there is no > user-interface, this is just the model of the refactoring engine. To > get the UI tools consider loading these packages with the following > dependencies: > > OB-Refactory --> Refactoring-Core, OB-Standard > OB-Regex --> Refactoring-Core, OB-Standard > OB-Shout --> OB-Morphic > OB-SUnitIntegration --> OmniBrowser > OB-Standard --> OmniBrowser > OB-Morphic --> OmniBrowser > OmniBrowser --> (none) > ECompletionOmniBrowser --> ECompletion > ECompletion --> Shout > ShoutWorkspace --> Shout > Shout --> (none) > > I was asking particulary about the ob repository, but you information is even better :) Thank you very much. Mariano HTH, > 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 >

Dec. 18, 2009

[Pharo-project] New packages to MetacelloRepository

by Mariano Martinez Peck

Hi: I am trying to create the metacello configurations of the external packages to do the pharo dev and web images. For now I have commited: - ConfigurationOfPharoSound - ConfigurationOfPharoMorphicExtras - ConfigurationOfShout But, they are not completed. They are just a first version. There are a lot of things to do. I need to create groups for the tests, etc. I have also started to create (not comitted yet): - ConfigurationOfPharo - ConfigurationOfAutomaticMethodCategorizer - ConfigurationOfRefactoringBrowser - ConfigurationOfOmniBrowser - ConfigurationOfEnhancedOmniBrowser - ConfigurationOfOCompletion (yes Romain we need to merge ;) I will send another email for this) Cheers, Mariano

Dec. 18, 2009

Re: [Pharo-project] Refactoring Browser depenences

by Lukas Renggli

Exactly, > Refactoring-Spelling depends on Refactoring-Core > Refactoring-Core depends on AST-Core AST-Core doesn't depend on anything. > There are more ?Â and dependences with external packages? No more dependencies. However, this configuration is hardly any useful, because there is no user-interface, this is just the model of the refactoring engine. To get the UI tools consider loading these packages with the following dependencies: OB-Refactory --> Refactoring-Core, OB-Standard OB-Regex --> Refactoring-Core, OB-Standard OB-Shout --> OB-Morphic OB-SUnitIntegration --> OmniBrowser OB-Standard --> OmniBrowser OB-Morphic --> OmniBrowser OmniBrowser --> (none) ECompletionOmniBrowser --> ECompletion ECompletion --> Shout ShoutWorkspace --> Shout Shout --> (none) HTH, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 18, 2009

Re: [Pharo-project] Default code browser

by GeertClaes

Schwab,Wilhelm K wrote: > > You didn't ask, but here's how I see it on pakages :) PackageInfo > **ABUSES** method categories to associate methods with packages. Methods > should be able to belong to multiple categories (you won't miss it until > you can do it), and to one package. Dolphin also has a class category > option, but I am not aware that anyone ever found it useful - packages are > enough to categorize classes. > I think I am with you that class categories are probably a bit overkill here since these class types are already grouped in separate (monticello) packages . Schwab,Wilhelm K wrote: > > I don't know a nice way to say it: if you are confused about packages, > ditch the package browser for a while. I have not used it for a few > versions, but I was shocked at how slow it could be, and began to suspect > that its behavior was (queue throat-clearing.wav) not deterministic. > Another possibility (if this level of re-entrancy is possible??) is that > it is SO slow that one fails to appreciate that it is still crunching on > the organization?? > It's not just that I am a bit confused or think the package browser is too slow, from a usability point of view it just does not make sense to me that it seems so complicated to load/share packages from other projects and/or components. Maybe this discussion belongs more in the 'Pharo IDE usability (was Re: Pharo for Professional Development) ' thread now? -- View this message in context: http://n2.nabble.com/Default-code-browser-tp4183317p4187788.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 18, 2009

Re: [Pharo-project] Issue 1633: Object allSubInstances appears to loop forever

by Eliot Miranda

with closures the block in allSubInstances will be a different object on each evaluation. Pre closures this would have been a single BlockContext used for each evaluation of the block (and hence non-reentrant). So you need to modify, e.g. by implementing allInstancesDo: in MethodContext class: 'From Croquet1.0beta of 11 April 2006 [latest update: #1] on 18 December 2009 at 9:26:47 am'! !MethodContext class methodsFor: 'hacks' stamp: 'ar 9/17/2008 16:24'! allInstancesDo: aBlock "Only count until thisContext" | inst next | inst := self someInstance. [inst == thisContext] whileFalse:[ next := inst nextInstance. aBlock value: inst. inst := next]! ! find it attached On Fri, Dec 18, 2009 at 7:47 AM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > Pharo image: Pharo | Pharo-core > PharoCore1.0rc1 Latest update: #10502 > VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update: > #10074] > > Steps to reproduce: > 1.Object allSubInstances > > It appears to be repeatedly adding its current context. > > ...Stan > > OrderedCollection>>addLast: > Receiver: an OrderedCollection(an Object an Object an Object an > Object an Object an Object an Object...etc... > Arguments and temporary variables: > newObject: [] in Object > class(Behavior)>>allSubInstances > Receiver's instance variables: > array: an Array(an Object an Object an Object an Object an > Object an Object an ...etc... > firstIndex: 1 > lastIndex: 1173805 > > OrderedCollection>>add: > Receiver: an OrderedCollection(an Object an Object an Object an > Object an Object an Object an Object...etc... > Arguments and temporary variables: > newObject: [] in Object > class(Behavior)>>allSubInstances > Receiver's instance variables: > array: an Array(an Object an Object an Object an Object an > Object an Object an ...etc... > firstIndex: 1 > lastIndex: 1173805 > > [] in Object class(Behavior)>>allSubInstances > Receiver: Object > Arguments and temporary variables: > aCollection: [] in Object > class(Behavior)>>allSubInstances > x: an OrderedCollection(an Object an Object an Object > an Object an Object an Ob...etc... > Receiver's instance variables: > superclass: ProtoObject > methodDict: a MethodDictionary(size 408) > format: 2 > instanceVariables: nil > organization: ('*DynamicBindings' binding binding: > hasBinding removeBinding) > ('...etc... > subclasses: {BalloonState. StandardFileMenuResult. > UndefinedObject. Boolean. Fi...etc... > name: #Object > classPool: a Dictionary(#DependentsFields->a > WeakIdentityKeyDictionary(MCWorkin...etc... > sharedPools: nil > environment: Smalltalk > category: #'Kernel-Objects' > traitComposition: {} > localSelectors: nil > ... > -- > View this message in context: > http://n2.nabble.com/Issue-1633-Object-allSubInstances-appears-to-loop-fore… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 18, 2009

Re: [Pharo-project] MetacelloRepository is online

by Romain Robbes

I added the ConfigurationOfOCompletion: Gofer new squeaksource: 'MetacelloRepository'; addPackage: 'ConfigurationOfOCompletion'; load. (Smalltalk at: #ConfigurationOfOCompletion) perform: #loadDefault Romain

Dec. 18, 2009

[Pharo-project] Refactoring Browser depenences

by Mariano Martinez Peck

Lukas: I am doing a Metacello ConfigurationOfRefactoringBrowser and I see I need these three packages for pharo: AST-Core Refactoring-Core Refactoring-Spelling Now, my question is, do you know the depences between them ? Rught now I noticed Refactoring-Spelling depends on Refactoring-Core Refactoring-Core depends on AST-Core There are more ? and dependences with external packages? Thank you. Mariano

Dec. 18, 2009

Re: [Pharo-project] about sluggines on linux

by Schwab,Wilhelm K

Stef, I have a slow linux box that stands ready to help, albeit at a snail's pace. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Friday, December 18, 2009 5:29 AM To: Arturo Zambrano Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] about sluggines on linux No problem. > Hi Stef, > I dind't see your email until today, when I came back to this topic! Don't know why it was marked as read :(. > Just to report the same test under Vista (obviously, on the same machine). > > '225948808 bytecodes/sec; 6804203 sends/sec' > they are coherent with the previous ones. > '533333333 bytecodes/sec; 12157397 sends/sec' and clearly and indication that we should get also slower machines to kick us to optimize or rethink certain decisions. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 18, 2009

Re: [Pharo-project] Default code browser

by Schwab,Wilhelm K

You didn't ask, but here's how I see it on pakages :) PackageInfo **ABUSES** method categories to associate methods with packages. Methods should be able to belong to multiple categories (you won't miss it until you can do it), and to one package. Dolphin also has a class category option, but I am not aware that anyone ever found it useful - packages are enough to categorize classes. I don't know a nice way to say it: if you are confused about packages, ditch the package browser for a while. I have not used it for a few versions, but I was shocked at how slow it could be, and began to suspect that its behavior was (queue throat-clearing.wav) not deterministic. Another possibility (if this level of re-entrancy is possible??) is that it is SO slow that one fails to appreciate that it is still crunching on the organization?? Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of GeertClaes Sent: Friday, December 18, 2009 3:48 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Default code browser Schwab,Wilhelm K wrote: > > Re the various browsers, they are not terribly well identified, so it > takes work to figure out what I am using. > +1 here Other than that, I find that none of the browsers are at this stage great yet from an intuitive, usability point of view (mind you, I consider myself to be very 'newbie'). I am also looking at Pharo + Seaside or AIDAWeb mainly as an IDE tool to create web apps as I am not that interested (or skilled for that matter) in tinkering with the core. I am hoping that the new package management system (MetaCello in Pharo 1.1?) will streamline some of the confusion and allow the user to have the option to somehow hide "system" or Pharo-Core packages from the IDE. I could be wrong here, but methods of a class can be nicely organized using protocols ... and then there is this whole vague, confusing world of how classes are managed in categories and packages ... but the term package could actually also refer to a category, which is actually a package, but a package can also be a Monticello package, which could be different than the category or should I say package? All this may make perfect sense to the gurus but it is extremely confusing, because packages also need to be able to be grouped into projects (is this the term?) and have dependencies on other packages and/or projects? I haven't even mentioned the confusion of SqueakMap/PharoMap, SqueakSouce/PharoSource, Monticello and Universes. -- View this message in context: http://n2.nabble.com/Default-code-browser-tp4183317p4185502.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 18, 2009