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

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Sean P. DeNigris

nicolas cellier-2 wrote: > > On the other hand, if old packages are usefull, they should be > maintained and upgraded. > This is a great ideal, but in reality there are a ton of useful, out-of-date packages out there. Anything that helps restore them to usability for the community is a plus. For example, some projects I use all the time in my personal image that I had to update for current Squeak and/or Pharo: Applescript CommandShell ExternalWebBrowser HTML (Validating Parser) KeyBinder Keymapping MathMorphs rST SHWorkspace (World Menu Fix) sqlite3 SSpec SVI Sophie MP3 playing Sophie QuickTime video playing Sean -- View this message in context: http://forum.world.st/WeakArray-isFinalizationSupported-tp3168849p3169475.h… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Igor Stasenko

ahahaa.. you guys are killing me.. You are taking things too serious. Yeah.. i would be gladly hear from Levente, what is 'the proper deprecation policy'. But since nobody described it, we are doomed to use one, invented before :) Nothing is perfect, but its not the reason to fight. On 31 December 2010 15:34, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Stephane, > You can't be serious: you learn something usefull from students acid > comments and nothing from the ones of Levente ? > Comm'on! > It's guaranteed that you'll get complaints. Only who doesn't do anything won't. > Forgetting is human, mistakes are, and unfortunately your are human too. > You must accept to fail, and you must accept some critics: it's up to > you to turn these in positive feedback. > > cheers > > Nicolas > > 2010/12/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> Thanks for the usual rant. This is good to have you here because we could have forgotten. >> Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) >> but there are moments when there is too much to deprecate or when people forget. >> And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed >> and apply even more software engineering practices. >> Now it does not mean that we do not pay attention. We pay attention to people and to their product. >> May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice >> if you could give us a break. >> >> Stef >> >> >> On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote: >> >>> On Thu, 30 Dec 2010, John McIntosh wrote: >>> >>>> Well the question as pointed out was does this vm support weak object >>>> finalization? and since all closure vm support finalization, then >>>> asking the question was mute, so it was ditched. Sophie from the 2003 >>>> era had to ask. >>> >>> The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning. >>> >>> >>> Levente >>> >>>> >>>> >>>> On 12/30/10, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>>> Hopefully that can eventually be said as "backward compatibility with good >>>>> stuff is a priority for Pharo." Â Moving targets are perhaps best left >>>>> moving for now. >>>>> >>>>> >>>>> >>>>> ________________________________________ >>>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>>>> [leves(a)elte.hu] >>>>> Sent: Thursday, December 30, 2010 6:13 PM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported >>>>> >>>>> (or so) which is unrelated. The method was removed during a "cleanup". And >>>>> as you know, backwards compatibility is not a priority for Pharo. >>>>> >>>>> >>>>> Levente >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> =========================================================================== >>>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >>>> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com >>>> =========================================================================== >>>> >>>> >>> >> >> >> > > -- Best regards, Igor Stasenko AKA sig.

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Nicolas Cellier

Stephane, You can't be serious: you learn something usefull from students acid comments and nothing from the ones of Levente ? Comm'on! It's guaranteed that you'll get complaints. Only who doesn't do anything won't. Forgetting is human, mistakes are, and unfortunately your are human too. You must accept to fail, and you must accept some critics: it's up to you to turn these in positive feedback. cheers Nicolas 2010/12/31 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Thanks for the usual rant. This is good to have you here because we could have forgotten. > Now of course we apply deprecation (we are probably the guy responsible to get the methods in Squeak long long time ago) > but there are moments when there is too much to deprecate or when people forget. > And forgetting is humane. Now if your company has lot of money, we can hire another engineer and work full speed > and apply even more software engineering practices. > Now it does not mean that we do not pay attention. We pay attention to people and to their product. > May be each community needs its pain in the ass after all it shows that we get cooler and cooler. But it would be nice > if you could give us a break. > > Stef > > > On Dec 31, 2010, at 10:22 AM, Levente Uzonyi wrote: > >> On Thu, 30 Dec 2010, John McIntosh wrote: >> >>> Well the question as pointed out was does this vm support weak object >>> finalization? and since all closure vm support finalization, then >>> asking the question was mute, so it was ditched. Sophie from the 2003 >>> era had to ask. >> >> The need for the check it outdated, but the method is still sent by external packages. With proper deprecation policy the method would be still available. It would simply return true and raise a deprecation warning. >> >> >> Levente >> >>> >>> >>> On 12/30/10, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: >>>> Hopefully that can eventually be said as "backward compatibility with good >>>> stuff is a priority for Pharo." Â Moving targets are perhaps best left >>>> moving for now. >>>> >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>>> [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Levente Uzonyi >>>> [leves(a)elte.hu] >>>> Sent: Thursday, December 30, 2010 6:13 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] WeakArray>>isFinalizationSupported >>>> >>>> (or so) which is unrelated. The method was removed during a "cleanup". And >>>> as you know, backwards compatibility is not a priority for Pharo. >>>> >>>> >>>> Levente >>>> >>>> >>>> >>> >>> >>> -- >>> =========================================================================== >>> John M. McIntosh <johnmci(a)smalltalkconsulting.com> >>> Corporate Smalltalk Consulting Ltd. Â http://www.smalltalkconsulting.com >>> =========================================================================== >>> >>> >> > > >

Dec. 31, 2010

Re: [Pharo-project] realized and learned something today :)

by Igor Stasenko

On 31 December 2010 14:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I was not specifically talking about pharo more about the fact that we can all ask ourselves when is the last > time that we got ready to exposed ourselves to the sharp eyes of others. > Because this is good to believe that we are the best and it may work in a nice little club in a small village may be we are important > and know the truth Â but if you go to a real city then reality is just different. > Everyone have a sense of beauty. Its just happens that we having different tastes. And that's ok. But then, when it going about measurable things, like features, robustness, error-free etc.. then of course it is silly to blindly pretend that we already have the best in the world. We can do better. And for me, i never needed to have a sharp eye from outside to understand it. :) > Now about the old dudes tshirt even the color is bad :) may be anti marketing works when this is trendy to be anti-fame but I doubt about it. > > Stef > > -- Best regards, Igor Stasenko AKA sig.

Dec. 31, 2010

Re: [Pharo-project] Issue 3498 in pharo: remove:ifAbsent: in linked list leads to interruption/sync problems

by Nicolas Cellier

2010/12/31 <pharo(a)googlecode.com>: > Updates: > Â Â Â Â Cc: marcus.denker > > Comment #4 on issue 3498 by marianopeck: remove:ifAbsent: in linked list > leads to interruption/sync problems > http://code.google.com/p/pharo/issues/detail?id=3498 > > Stef, I am not Adrian, but yes, I think that can be the reasons. Just take > the example of Andreas. When you do foo == nil, when that's compiled, it put > a special bytcode for the == primitive (no method is send). > It seems the scheduler can change processes during method sends. In most > clases, this may not be a problem. But if you cahnge foo == nil, by foo > isNil, it may be a point where it can be preempted. And maybe there are > places where this cannot happen, probably the place where the the processes > are managed or the code needed for that, like Andras said, process, delay, > semaphore, etc. > > What I don't understand is that I thought that the compiler replaces foo > isNil by foo == nil. And if this is the case, then what has been explained > doesn't make sense :( > No, only #ifNil: is a selector handled specially by Compiler. Nicolas

Dec. 31, 2010

Re: [Pharo-project] Issue 3498 in pharo: remove:ifAbsent: in linked list leads to interruption/sync problems

by pharo＠googlecode.com

Updates: Cc: marcus.denker Comment #4 on issue 3498 by marianopeck: remove:ifAbsent: in linked list leads to interruption/sync problems http://code.google.com/p/pharo/issues/detail?id=3498 Stef, I am not Adrian, but yes, I think that can be the reasons. Just take the example of Andreas. When you do foo == nil, when that's compiled, it put a special bytcode for the == primitive (no method is send). It seems the scheduler can change processes during method sends. In most clases, this may not be a problem. But if you cahnge foo == nil, by foo isNil, it may be a point where it can be preempted. And maybe there are places where this cannot happen, probably the place where the the processes are managed or the code needed for that, like Andras said, process, delay, semaphore, etc. What I don't understand is that I thought that the compiler replaces foo isNil by foo == nil. And if this is the case, then what has been explained doesn't make sense :(

Dec. 31, 2010

Re: [Pharo-project] realized and learned something today :)

by StÃ©phane Ducasse

I was not specifically talking about pharo more about the fact that we can all ask ourselves when is the last time that we got ready to exposed ourselves to the sharp eyes of others. Because this is good to believe that we are the best and it may work in a nice little club in a small village may be we are important and know the truth but if you go to a real city then reality is just different. Now about the old dudes tshirt even the color is bad :) may be anti marketing works when this is trendy to be anti-fame but I doubt about it. Stef On Dec 31, 2010, at 9:13 AM, Geert Claes wrote: > > I reckon Pharo has already addressed some of the "bad windows, bad colors, > slow, why not in svn, ..... " complaints but it is a very very good idea to > listen to what everyone (not just the old dudes: > http://www.cafepress.com/redhillstrading.329889873) wants Pharo to be to set > the roadmap :) > > http://forum.world.st/file/n3169180/olddude.jpg > > -- > View this message in context: http://forum.world.st/realized-and-learned-something-today-tp3168835p316918… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 31, 2010

Re: [Pharo-project] Issue 3498 in pharo: remove:ifAbsent: in linked list leads to interruption/sync problems

by pharo＠googlecode.com

Comment #3 on issue 3498 by stephane.ducasse: remove:ifAbsent: in linked list leads to interruption/sync problems http://code.google.com/p/pharo/issues/detail?id=3498 The bug is probably linked to the fact that the vm does preempt == while the other definition is based on messages and can be preempted. Adrian what do you think?

Dec. 31, 2010

Re: [Pharo-project] Issue 3498 in pharo: remove:ifAbsent: in linked list leads to interruption/sync problems

by pharo＠googlecode.com

Comment #2 on issue 3498 by stephane.ducasse: remove:ifAbsent: in linked list leads to interruption/sync problems http://code.google.com/p/pharo/issues/detail?id=3498 andreas wrote on squeak-dev: Oh, I also just noticed something else: It seems as if the VMMaker changes for atomic suspend never made it into the main line. I just posted the relevant bits but that means you have another workaround. You can use the Cog VM, which has had these changes from the beginning. By using Cog, the primitive suspend will never fail and consequently the (still broken) code in LinkedList>>remove:ifAbsent: will never be executed.

Dec. 31, 2010

Re: [Pharo-project] Issue 3498 in pharo: remove:ifAbsent: in linked list leads to interruption/sync problems

by pharo＠googlecode.com

Updates: Status: Fixed Cc: adrian.lienhard Labels: Milestone-1.2 Comment #1 on issue 3498 by stephane.ducasse: remove:ifAbsent: in linked list leads to interruption/sync problems http://code.google.com/p/pharo/issues/detail?id=3498 the definition is remove: aLinkOrObject ifAbsent: aBlock "Remove aLink from the receiver. If it is not there, answer the result of evaluating aBlock." |link| link := self linkOf: aLinkOrObject ifAbsent: [^aBlock value]. self removeLink: link. ^aLinkOrObject and andreas suggests to revert to use the squeak version remove: aLink ifAbsent: aBlock "Remove aLink from the receiver. If it is not there, answer the result of evaluating aBlock." | tempLink | aLink == firstLink ifTrue: [firstLink := aLink nextLink. aLink == lastLink ifTrue: [lastLink := nil]] ifFalse: [tempLink := firstLink. [tempLink == nil ifTrue: [^aBlock value]. tempLink nextLink == aLink] whileFalse: [tempLink := tempLink nextLink]. tempLink nextLink: aLink nextLink. aLink == lastLink ifTrue: [lastLink := tempLink]]. aLink nextLink: nil. ^aLink

Dec. 31, 2010