July 2012 - Pharo-dev - lists.pharo.org

[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

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

by Sean P. DeNigris

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

Re: [Pharo-project] [update 2.0] #20209

by StÃ©phane Ducasse

> > We could just add a good version of #version to SystemPlatform in 1.4. > Because what is called on 1.4 is #version of ClassDescription which is related to a > concept of class versions which seems to be some arcane stuff in need of cleanup. > > version > "Return the version number string of the platform we're running on" > "OSPlatform version" > > ^(Smalltalk vm getSystemAttribute: 1002) asString yes

July 14, 2012

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

by StÃ©phane Ducasse

> > Well, using Exceptions for non-exceptional conditions is a hack. But > these aren't, they're Notifications, which are entirely different! > > Seriously though, resumable exceptions are at the core of how > Squeak/Pharo work. They're really useful. > > frank I agree

July 14, 2012

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

by StÃ©phane Ducasse

>> Sven Van Caekenberghe wrote >>> >>> With Announcements the problem is that you have to specify an Announcer, >>> Notifications are just thrown in the air ;-) > >> How about an announcer per client that also forwards to one for the whole Zinc library? > > I think I understand what you are trying to achieve, yes it makes sense. > But this feels like a architectural decision - I don't feel qualified to decide. > > Anybody else care to comment ? I did not get it. Stef

July 14, 2012

Re: [Pharo-project] DateAndTime

by StÃ©phane Ducasse

thanks! Stef On Jul 13, 2012, at 9:20 PM, Camillo Bruni wrote: > Finally after a 5h marathon of hacking and fixing broken stuff > we are proud (and completely brain dead) to present the fixed > Date/Time objects. > > We fixed: > - all internals are represented in UTC > - all relative stuff is represented in UTC plus an additional timezone (currently a simple Duration) > > > All Date related tests are green! > We are not sure about the complete implications of these changes, > but they were clearly necessary, since the current system will break > under moving timezone... > > > ben+2:00 > cami+2:00

July 14, 2012