- Pharo-dev - lists.pharo.org

[Pharo-project] pharo-2.0-tests Â» 32,linux - Build # 224 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 15, 2012

[Pharo-project] pharo-2.0-tests Â» 32,mac - Build # 224 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 15, 2012

[Pharo-project] pharo-2.0-tests Â» 32,win - Build # 224 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 15, 2012

[Pharo-project] pharo-2.0-tests Â» 32,mac - Build # 223 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 15, 2012

[Pharo-project] pharo-2.0-tests Â» 32,linux - Build # 223 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 15, 2012

[Pharo-project] pharo-2.0-tests Â» 32,win - Build # 223 - Still Failing!

by jenkins-pharo.ci.inria.fr＠jenkins-server.lille.inria.fr

July 15, 2012

Re: [Pharo-project] [BUG]: Zinc-HTTP-SvenVanCaekenberghe.285 GoferRepositoryError

by Sven Van Caekenberghe

Sean, I took 1.4 #14453 and executed Gofer it url: 'http://mc.stfx.eu/ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-FileSystem-Legacy'; package: 'Zinc-Tests'; load. Thus loading the latest versions like Zinc-HTTP-SvenVanCaekenberghe.287 And yes, for some reason the first Zn related operation fails (related to a process local (ZnSignalProgress) var not being there, its an index out of bounds), but if you try again it works. And all tests pass. So its a bit hard to debug. The latest 2.0 image has the same transient problem ;-) Sven On 15 Jul 2012, at 01:51, Sean P. DeNigris wrote: > In the latest Pharo 1.4 > (https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/455/artifa…) > > 1. Download > http://forum.world.st/file/n4640031/ConfigurationLoadingPhexample.st > ConfigurationLoadingPhexample.st > 2. Evaluate the following: > Gofer it > url: 'http://mc.stfx.eu/ZincHTTPComponents'; > version: 'Zinc-HTTP-SvenVanCaekenberghe.285'; > load. > '/path/to/ConfigurationLoadingPhexample.st' asFileReference fileStreamDo: [ > :str | str fileIn ]. > ((Smalltalk at: #ConfigurationLoadingPhexample) project version: > #'bleedingEdge') load. > > You should get: "Error: Could not resolve: ConfigurationOfPhexample > [ConfigurationOfPhexample] in /path/to/package-cache > http://www.squeaksource.com/MetacelloRepository ERROR: > 'GoferRepositoryError: 2'" > > If you change the HTTP package line to "version: > 'Zinc-HTTP-SvenVanCaekenberghe.284';", it successfully downloads. > > n.b. if the package is in your cache, you won't see the error > > -- > View this message in context: http://forum.world.st/BUG-Zinc-HTTP-SvenVanCaekenberghe-285-GoferRepository… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 15, 2012

Re: [Pharo-project] Keymapping - Class vs. Instance Targets

by Tudor Girba

+1 On Fri, Jul 13, 2012 at 9:35 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > may be we should get > an instance variable plus a class variable > by default the instance variable points to the class var > and all the method use only the instance var > => we can have sharing via the class var and instance based specific customization because there is the instance var > and the user can copy the class var contents and modify it. > > Stef > > On Jul 13, 2012, at 5:10 PM, Sean P. DeNigris wrote: > >> I've run into a lot of trouble implementing the vim bindings because morph >> instances don't make local copies of the class's maps, so there's no way to >> override class defaults in an instance. For example, for a particular >> instance, I can't detach a category that is attached to the class without >> detaching it from all instances, which I think will not work anyway because >> existing instances don't pick up those changes. >> >> Sean >> >> -- >> View this message in context: http://forum.world.st/Keymapping-Class-vs-Instance-Targets-tp4639863.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > -- www.tudorgirba.com "Every thing has its own flow"

July 15, 2012

[Pharo-project] [BUG]: Zinc-HTTP-SvenVanCaekenberghe.285 GoferRepositoryError

by Sean P. DeNigris

In the latest Pharo 1.4 (https://ci.lille.inria.fr/pharo/view/Pharo%201.4/job/Pharo%201.4/455/artifa…) 1. Download http://forum.world.st/file/n4640031/ConfigurationLoadingPhexample.st ConfigurationLoadingPhexample.st 2. Evaluate the following: Gofer it url: 'http://mc.stfx.eu/ZincHTTPComponents'; version: 'Zinc-HTTP-SvenVanCaekenberghe.285'; load. '/path/to/ConfigurationLoadingPhexample.st' asFileReference fileStreamDo: [ :str | str fileIn ]. ((Smalltalk at: #ConfigurationLoadingPhexample) project version: #'bleedingEdge') load. You should get: "Error: Could not resolve: ConfigurationOfPhexample [ConfigurationOfPhexample] in /path/to/package-cache http://www.squeaksource.com/MetacelloRepository ERROR: 'GoferRepositoryError: 2'" If you change the HTTP package line to "version: 'Zinc-HTTP-SvenVanCaekenberghe.284';", it successfully downloads. n.b. if the package is in your cache, you won't see the error -- View this message in context: http://forum.world.st/BUG-Zinc-HTTP-SvenVanCaekenberghe-285-GoferRepository… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 14, 2012

Re: [Pharo-project] [ENH]: Zinc - Streaming Download Progress

by Camillo Bruni

Notification/Exception vs Announcements is pretty easy to answer in my opinion: Notification/Exception should only be used when the original action can be modified, typical examples are UI dialogs which ask for something. Announcements can be used when there is no need for feedback. I would consider the following things be better using Announcements - inform: - progress bar Furthermore I would say each Notification/Exception should trigger an Announcement as well. Somehow they are the weak form of Notification/Exception because they are only an outgoing communication channel. Whereas Notification/Exception allow information to be injected back.. On 2012-07-14, at 21:12, Sean P. DeNigris wrote: > > StÃ©phane Ducasse wrote >> >> I did not get it. >> > > Besides being hackish, using exceptions to notify progress has other > drawbacks. For example, if you use announcements, then everyone who is > interested in receiving them will be notified. With exceptions, even if you > want to be notified, the exception may get handled before you ever get a > chance. My whole journey with cleaning SystemProgress started because I was > trying to get progress notifications, but they were being handled by code > that I didn't own before I got them. Announcements also allow elegant > simplifications like e.g. for system progress, the progress bar might be > just another subscriber to the announcements, so it's really easy to > enable/disable it. > > > Also, > | client | > client := ZnClient new. > [ client > signalProgress: true; > url: fileUrl; > downloadTo: self workspace fullName. ] > on: HTTPProgress > do: [ :progress | > "handle progress" > progress resume ]. > > vs. > > client := ZnClient new. > client > onProgressSend: #progress: to: self. > url: fileUrl; > downloadTo: self workspace fullName. > > -- > View this message in context: http://forum.world.st/ENH-Zinc-Streaming-Download-Progress-tp4639686p464002… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 14, 2012