- Pharo-dev - lists.pharo.org

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

by Frank Shearar

On 13 July 2012 21:23, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe wrote >> >> Uhh, HTTPProgress was already there. I believe all progress is done that >> way, no ? >> > Oh, okay. Using exceptions for non-exceptional conditions seems like a hack. > My first cut at cleaning up the SystemProgressMorph was in preparation to > re-implement using announcements instead. 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 > 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? > > -- > View this message in context: http://forum.world.st/ENH-Zinc-Streaming-Download-Progress-tp4639686p463993… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

July 13, 2012

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

by Sven Van Caekenberghe

On 13 Jul 2012, at 15:44, Marcus Denker wrote: > Issue 6356: some cleanups related to methods moved away from SmalltalkImage (vm and os related) > http://code.google.com/p/pharo/issues/detail?id=6356 OK. but how can a poor library developer trying to write code that has to remain compatible with 1.3 and 1.4 deal with this ? Have a look at ZnUserAgentSettings class>>#platformDetails ^ self platform platformName, ' ', self platform platformSubtype, ' ', self platform osVersion Now, this is a deprecated class in Zn as well, but rewriting self platform osVersion to self platform os version does not seem to give the same result in 1.4 Any suggestions ? Thx, Sven

July 13, 2012

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

by Sven Van Caekenberghe

Sean, On 13 Jul 2012, at 22:23, Sean P. DeNigris wrote: > Sven Van Caekenberghe wrote >> >> Uhh, HTTPProgress was already there. I believe all progress is done that way, no ? > Oh, okay. Using exceptions for non-exceptional conditions seems like a hack. > My first cut at cleaning up the SystemProgressMorph was in preparation to > re-implement using announcements instead. Yes, it seems like a hack. > 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 ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

July 13, 2012

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

by Sean P. DeNigris

Sven Van Caekenberghe wrote > > Uhh, HTTPProgress was already there. I believe all progress is done that > way, no ? > Oh, okay. Using exceptions for non-exceptional conditions seems like a hack. My first cut at cleaning up the SystemProgressMorph was in preparation to re-implement using announcements instead. 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? -- View this message in context: http://forum.world.st/ENH-Zinc-Streaming-Download-Progress-tp4639686p463993… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 13, 2012

Re: [Pharo-project] DateAndTime

by Sven Van Caekenberghe

Great work. let's hope it stands the test of time, so to speak. On 13 Jul 2012, at 21:20, Camillo Bruni wrote: > ben+2:00 > cami+2:00 I bet you would rather be ben+0:00 and cami+0:00 or even benZ and camiZ ;-)

July 13, 2012

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

by Sven Van Caekenberghe

On 13 Jul 2012, at 21:21, Sean P. DeNigris wrote: > Oh, I forgot about http://mc.stfx.eu/ZincHTTPComponents.... Is it better to > try there first, in general? Yes, that is my primary one, but I normally copy immediately to SqS, unless under hacking stress > _________________________ > > > Cool! It works great :) One question - why exceptions instead of > announcements? Uhh, HTTPProgress was already there. I believe all progress is done that way, no ? With Announcements the problem is that you have to specify an Announcer, Notifications are just thrown in the air ;-)

July 13, 2012

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

by StÃ©phane Ducasse

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. >

July 13, 2012

Re: [Pharo-project] DateAndTime

by Camillo Bruni

On 2012-07-13, at 21:24, Sean P. DeNigris wrote: > > Camillo Bruni-3 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. >> > > *Thanks!* I was so burnt out discussing and fixing the UTC issues that I > couldn't look at those anymore :) it was incredibly messy... hard to imaging that we survived with this crap so long :D

July 13, 2012

Re: [Pharo-project] DateAndTime

by Sean P. DeNigris

Camillo Bruni-3 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. > *Thanks!* I was so burnt out discussing and fixing the UTC issues that I couldn't look at those anymore :) -- View this message in context: http://forum.world.st/DateAndTime-tp4639908p4639911.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

July 13, 2012

Re: [Pharo-project] start-up and shut-down lists

by Marcus Denker

On Jul 13, 2012, at 9:09 PM, Eliot Miranda wrote: > Hi All, > > I'm profiling image startup and consequently want to pause a MessageTally during a snapshot. So I want to add MessageTally to the StartUpList immediately after Delay (the first entry in StartUpList) and to the ShutDownList immediately before Delay. But when I look at the SmalltalkImage accessor I see some confusion: > In Pharo I have rewritting this: you can add either before or after, so there is support for both adding before and after: add: aClass toList: startUpOrShutDownList after: predecessor "Add the name of aClass to the startUp or shutDown list. Add it after the name of predecessor" (Smalltalk globals includes: aClass) ifFalse: [self error: aClass name , ' cannot be found in Smalltalk dictionary.']. "Add after predecessor, moving it if already there." (Smalltalk globals includes: predecessor) ifFalse: [self error: predecessor name , ' cannot be found in Smalltalk dictionary.']. (startUpOrShutDownList includes: predecessor name) ifFalse: [self error: predecessor name , ' cannot be found in the list.']. startUpOrShutDownList remove: aClass name ifAbsent:[]. startUpOrShutDownList add: aClass name after: predecessor name add: aClass toList: startUpOrShutDownList before: successor "Add the name of aClass to the startUp or shutDown list. Add it before the name of successor" (Smalltalk globals includes: aClass) ifFalse: [self error: aClass name , ' cannot be found in Smalltalk dictionary.']. "Add before successor, moving it if already there." (Smalltalk globals includes: successor) ifFalse: [self error: successor name , ' cannot be found in Smalltalk dictionary.']. (startUpOrShutDownList includes: successor name) ifFalse: [self error: successor name , ' cannot be found in the list.']. startUpOrShutDownList remove: aClass name ifAbsent: []. startUpOrShutDownList add: aClass name before: successor name. -- Marcus Denker -- http://marcusdenker.de

July 13, 2012