- Pharo-dev - lists.pharo.org

Re: [Pharo-project] #anyChanges still needed?

by Mariano Martinez Peck

On Sat, Jun 16, 2012 at 11:53 PM, Benjamin < benjamin.vanryseghem.pharo(a)gmail.com> wrote: > My 2cts is for some event (and I think *modified is part of them), you got > the event twice: before and after. > So basically, one of the two events is wrong. > > Mariano, you should try to put an halt, and see :) > I did, but it gets call only once per modification. > > Ben > > > On Jun 16, 2012, at 10:26 PM, Guillermo Polito wrote: > > Yeah, but logging superfluous changes does not really make a change, does > it? > > On Sat, Jun 16, 2012 at 10:04 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> may be because the source changes was listening to the event. >> And the log file needed to log any thing like doits and other. >> >> On Jun 16, 2012, at 9:14 PM, Mariano Martinez Peck wrote: >> >> > Hi guys. ChangeSet does at some point: >> > >> > anEvent itemKind = SystemChangeNotifier classKind ifTrue: [ >> > ... >> > anEvent isModified >> > ifTrue: [anEvent anyChanges ifTrue: [self >> changeClass: anEvent item from: anEvent oldItem]]. >> > anEven >> > >> > >> > >> > So...I don't understand the #anyChanges. We received an event saying >> that a class was modified, but it may not have any changes? if true, why >> was the event sent? >> > Ok...let's say that there could be several reasons that a class was >> modified but only some of them make sense to change set. I can imagine >> people wanted to avoid writing stuff to .changes that didn't actullay >> represente a change? >> > >> > If this is the case, then #anyChanges looks like a bad name for me. >> > >> > Now, do we still need this mesage? can there be ClassModified events >> without changes? >> > thanks >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> >> > > -- Mariano http://marianopeck.wordpress.com

June 17, 2012

[Pharo-project] Help review ! Re: [Pharo-bugtracker] Issue 6077 in pharo: Let DataStream only for Monticello Part2

by Mariano Martinez Peck

Hi guys. I touched a couple of packages so it will get obsolete soon if we don't integrate it. Anywone to review? On Sun, Jun 17, 2012 at 3:36 PM, <pharo(a)googlecode.com> wrote: > Updates: > Status: FixReviewNeeded > > Comment #1 on issue 6077 by marianopeck: Let DataStream only for > Monticello Part2 > http://code.google.com/p/**pharo/issues/detail?id=6077<http://code.google.com/p/pharo/issues/detail?id=6077> > > So slice in inbox. > IMPORTANT: after integrating, you have to evaluate: > > ScriptLoader new deletePackage: 'System-Object Storage' > > > > ______________________________**_________________ > Pharo-bugtracker mailing list > Pharo-bugtracker(a)lists.gforge.**inria.fr<Pharo-bugtracker(a)lists.gforge.inria.fr> > http://lists.gforge.inria.fr/**cgi-bin/mailman/listinfo/**pharo-bugtracker<http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker> > -- Mariano http://marianopeck.wordpress.com

June 17, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,mac - Build # 129 - Failure!

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

June 17, 2012

[Pharo-project] Pharo-2.0-Tests Â» 32,linux - Build # 129 - Failure!

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

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by Sean P. DeNigris

philippeback wrote > > OB if we want traction with embarking new people into Pharo. > ... That makes sense. The only downside is that we will train people on one browser and almost immediately switch to a new one. I remember questions about how to "get the browser from PBE" (it was O2 I think). Although, I guess this is a good tradeoff vs. exposing newbies to a bleeding edge tool under heavy development. Also, about that release date... Sean -- View this message in context: http://forum.world.st/start-thinking-on-summer-release-of-Pharo-1-4-tp46345… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 17, 2012

Re: [Pharo-project] start thinking on summer release of Pharo 1.4

by btc＠openInWorld.com

June 17, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Sean P. DeNigris

Igor Stasenko wrote > > I bet if you do that, some people will be alienated/antagonized by > this change Yes, but 2.0 is changing *alot*, so this is a good time to sneak this in :) Like pulling off a BandAid... the best thing to do is pull fast and get it over with. Igor Stasenko wrote > > As a compromise i would suggest to force people to explicitly tell > their intent That would be an improvement... Also, what's the status of this limitation (http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p4082565.html) : when:do: anActionBlock subscription does > not work weakly, you are constrained to when:send:to IIUC it was waiting on ephemerons (http://forum.world.st/Working-with-weak-announcements-td3305802.html) -- View this message in context: http://forum.world.st/Why-don-t-we-always-register-weakly-in-SystemAnnounce… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 17, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Guillermo Polito

On Sun, Jun 17, 2012 at 2:42 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 17 June 2012 01:30, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > > Igor Stasenko wrote > >> > >> because 'announcer weak subscribe: ' is explicit > >> > > > > Either way, something is implicit. Why not make the common case implicit > and > > the uncommon one slightly more verbose? "Make common things easy, rare > > things possible" > > > I bet if you do that, some people will be alienated/antagonized by > this change (oh... its really hard > to make everyone happy). > > As a compromise i would suggest to force people to explicitly tell > their intent.. i.e. > if they want to subscribe strongly, then they should say: > > announcer strong on:.. > > and weakly, is > > announcer weak on:.. > > but if they do: > > announcer on: > > they shall get a DNU/error. > He, I like that! > > -- > Best regards, > Igor Stasenko. > >

June 17, 2012

Re: [Pharo-project] Why don't we always register weakly in SystemAnnouncer?

by Igor Stasenko

On 17 June 2012 01:30, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Igor Stasenko wrote >> >> because 'announcer weak subscribe: ' is explicit >> > > Either way, something is implicit. Why not make the common case implicit and > the uncommon one slightly more verbose? "Make common things easy, rare > things possible" > I bet if you do that, some people will be alienated/antagonized by this change (oh... its really hard to make everyone happy). As a compromise i would suggest to force people to explicitly tell their intent.. i.e. if they want to subscribe strongly, then they should say: announcer strong on:.. and weakly, is announcer weak on:.. but if they do: announcer on: they shall get a DNU/error. -- Best regards, Igor Stasenko.

June 17, 2012

[Pharo-project] [update 2.0] #20134

by StÃ©phane Ducasse

20134 ----- - Issue 5750: RPackage should rename extension methods in pckage renames. Thanks Mariano Martinez-Peck and Guillermo Polito. http://code.google.com/p/pharo/issues/detail?id=5750 - Issue 6073: Make PragmaCollector rely on SystemAnnouncer instead of SystemChangeNotifier. Thanks Mariano Martinez-Peck and Guillermo Polito. http://code.google.com/p/pharo/issues/detail?id=6073

June 17, 2012