- Pharo-dev - lists.pharo.org

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by StÃ©phane Ducasse

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] UI for Shortcuts [WAS: Which Keymaps/Shortcuts do we want to have?]

by StÃ©phane Ducasse

Alain This is where your great work pays off. It is often difficult when you work at infrastructural level. People can think that you fix things for the sake of it :) but infrastructure is really important because it is the enabler for the future. Stef > Very cool, thanks. > The setting browser is easily extendable. see how Shout colors settings are integrated. > Have a look at SHStyleSetting. the UI is declared in SHStyleSetting class>>settingInputWidgetForNode: > Maybe we can have something like that for shortcuts: a drop list for the key modifier and a text field for the shortcut character. > Cheers > Alain > > Le 31/12/2010 00:28, Guillermo Polito a Ã©crit : >> Hi, I would like to discuss the UI for shortcuts and not to impose it :). So.. >> >> I was exploring the Idea of configuring the shortcuts in settings as the screenshot shows. What do you think of that? I don't think we need a separated tool to configure shortcuts. Settings look ok. >> >> Tomorrow I'll be putting a lot of effort on it ;).

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Igor Stasenko

On 31 December 2010 12:45, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 31 December 2010 11:03, Nicolas Cellier > <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> On the other hand, if old packages are usefull, they should be >> maintained and upgraded. >> >> If Pharo wants to remove these deprecated methods, an alternative >> policy is to move deprecated methods in a separate backward >> compatibility package. >> > > +1 > I would call it 'Pharo-Cruft' > :) Sorry for quick comment. I think this idea is userful to safely remove anything from system and it can be even automated Utilities moveDeprecatedToCruft "put all senders of #deprecated to '*Pharo-Cruft' category" ... Because a package author who wants to upgrade his package can be always sure that he can fix it, because he can use Pharo-Cruft for checking what removed methods was doing, and what is analogous functionality he can use in modern image (all deprecated methods should contain a comment describing, why it was removed and what should be used instead). Just removing methods, as it shown by this topic (isFinalizationSupported), could lead to unnecessary questions and confusion. > >> Nicolas -- Best regards, Igor Stasenko AKA sig.

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Igor Stasenko

On 31 December 2010 11:03, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > On the other hand, if old packages are usefull, they should be > maintained and upgraded. > > If Pharo wants to remove these deprecated methods, an alternative > policy is to move deprecated methods in a separate backward > compatibility package. > +1 I would call it 'Pharo-Cruft' :) > Nicolas > > 2010/12/31 Levente Uzonyi <leves(a)elte.hu>: >> 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] realized and learned something today :)

by laurent laffont

On Fri, Dec 31, 2010 at 3:59 AM, Francisco Ortiz PeÃ±aloza < patchinko(a)gmail.com> wrote: > I couldn't agree more with you Stef, specially with > > "So each time we get down because we do not see the little flame opening in > the eyes of the others > > we can think hard and get from them what we missed." > > Many times i try to explain or show some feature expecting that flame... > that doesn't show up. Putting expectations on others is a a *double* > -edged *weapon but *I'll try harder. > On the other side, I've taught VB, Delphi, Java, Python, Ruby and Pharo. I've seen more little flames with Pharo than in any other programming ecosystem. May be I'm an eternal optimist but when you make OO newbie students get the one-click image, develop a tiny little project, debug it and share it on SqueakSource in 4 hours, that rocks. I think that in course the show must go on, it should be like if you are a musician and you get on stage. So like musicians share good tunes and scores to create their show, we can share good kata which provides the "Ahaaaa" effect. Indeed this is what I'm trying to do with Pharocasts and it's great when you can show these katas in course. Laurent. > > Cheers, > Francisco > > On Thu, Dec 30, 2010 at 11:33 PM, <csrabak(a)bol.com.br> wrote: > >> Em 30/12/2010 19:56, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > >> escreveu: >> >> > Hi guys >> > I think that over the years I (but also many of you, I know) tried >> > to expose newbies to smalltalk or our culture. And often we get bad >> > reactions, bad windows, bad colors, slow, why not in svn, ..... I >> >> Those specific reactions are more likely to be about Squeak of Pharo >> than Smalltalk in general, isn't? >> >> > think that showing Smalltalk to newbies is the best we can do to >> > ourselves, not really to attract new people but also to get a large >> > kick in the %^&* because most of the time students are not stupid, >> > they are exposed to other technos. >> >> Yes. They make an excellent litmus test without the risks of expending >> lots of money in the 'launching of product' which can become an Edsel >> of the programming languages... >> >> > So each time we believe we want >> > to show them something cool and they do not really consider it as >> > cool as we believe, we can of course think that they are idiot (some >> > of them are) but most of the time we can also think that may be we >> > stayed too long in our little boxes and the world moved (interfaced >> > well with c, fast, cool frameworks, has cool tools, processes >> > (integration...), cool UIs, web stuff.....). >> >> Indeed. >> >> > So each time we get >> > down because we do not see the little flame opening in the yes of >> > the others we can think hard and get from them what we missed. >> >> I believe this is the first step to get the best direction to follow. >> >> > I really happy to get exposed to student acid tests, this is a >> > valuable feedback and I wanted to share that with you. >> >> Stef, now comes the rub: do you think it is possible to systematize >> the lessons learned and post a summary for us here? >> >> Perhaps we should open a specific Wiki page on this? >> >> Regards, >> >> -- >> Cesar Rabak >> >> >

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Nicolas Cellier

On the other hand, if old packages are usefull, they should be maintained and upgraded. If Pharo wants to remove these deprecated methods, an alternative policy is to move deprecated methods in a separate backward compatibility package. Nicolas 2010/12/31 Levente Uzonyi <leves(a)elte.hu>: > 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] UI for Shortcuts [WAS: Which Keymaps/Shortcuts do we want to have?]

by Mariano Martinez Peck

Guille, I like the UI. Few comments: - what is that KMMeta ? seems kryptic to me. Shortcuts have to be very clear and easy to understand. I really didn't understand at all :( - what is the difference between '+' and ',' ? Maybe a little help somewhere would be fine. Ahhh and what about letting you type something and recognize the shortcut instead of writing it? heheh this is a good one ;) cheers mariano On Fri, Dec 31, 2010 at 12:28 AM, Guillermo Polito < guillermopolito(a)gmail.com> wrote: > Hi, I would like to discuss the UI for shortcuts and not to impose it :). > So.. > > I was exploring the Idea of configuring the shortcuts in settings as the > screenshot shows. What do you think of that? I don't think we need a > separated tool to configure shortcuts. Settings look ok. > > Tomorrow I'll be putting a lot of effort on it ;). > > Cheers! > > On Mon, Dec 27, 2010 at 6:53 PM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Mon, Dec 27, 2010 at 12:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: >> >>> I also would like a cmd+f: search anything... but that needs also an >>> application (like algernon, which I'm currently not supporting anymore due >>> time issues), not just a command :( >>> well, at least a cmd+f: search class would be fine :) >>> >> >> +1 >> It sound like a good project for someone with time and wanting to learn :) >> >> >>> >>> El 27/12/2010, a las 5:38a.m., StÃ©phane Ducasse escribiÃ³: >>> >>> > I suggest that you define lists = >>> > >>> > simple eamcs bindings = >>> > ctral a ctrle >>> > >>> > Windows manipulation >>> > cmd W >>> > ... >>> > >>> > Your special binding >>> > >>> > >>> > Then you should have contexts >>> > World >>> > TextMorph >>> > Editor only >>> > >>> > (of course some list will only be able to be attached to a given >>> object programmatically >>> > example: for botsinc I wanted specific binding to that morph >>> class only -- but you do not care) >>> > >>> > then a config is >>> > >>> > (lists, lists) context >>> > (mybinding, lists, lists) context >>> > >>> > where , make sure that mybinding take precedence >>> > >>> > >>> > Does it make sense? >>> > >>> > Stef >>> > >>> > >>> > >>> > On Dec 27, 2010, at 2:37 AM, Guillermo Polito wrote: >>> > >>> >> What about something like the attach? >>> >> >>> >> On Sun, Dec 26, 2010 at 7:45 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >> Wow, haha, this is wonderful! So, putting some order: >>> >> >>> >> 1) shortcuts published as settings with a default? Will that be ok? >>> This make me think the following: >>> >> - how to share shortcuts. Files? Keymapping used to use SIXX, but >>> maybe it is not suitable for a light solution (I don't know much about SIXX) >>> >> - downloading a new image (or a new version of a package with >>> shortcuts) could make us lose our own-defined shortcuts. >>> >> >>> >> 2) support for the following shortcuts: >>> >> >>> >> - a shortcut to bring up the wolrd menu. Not sure which shortcut. >>> >> - use ctrl + tab to switch between windows instead of cmd + arrows >>> >> - a shortcut for what it is (hidden) now with cmd + shift + click >>> (list of opened windows) >>> >> - Shortcuts for opening standard tools: Workspace, Transcript, >>> TestRunner, etc. >>> >> - Shortcut for duplicating a windows >>> >> - a shortcut for saving the image (cmd+ shoft + s ?) >>> >> - a shortcut for quitting the image with and without saving >>> >> - a shortcut to see a list of shortcuts >>> >> >>> >> I would like to add some more items to #2, and to define the keys that >>> triggers them. >>> >> #1 seems to be of some work :). I'll work on it ASAP. >>> >> >>> >> Step by step, as Stef and Mostaza Merlo says :). >>> >> >>> >> Cheers! >>> >> Guille >>> >> >>> >> >>> >> On Sun, Dec 26, 2010 at 7:18 PM, StÃ©phane Ducasse < >>> stephane.ducasse(a)inria.fr> wrote: >>> >> + 1 :) >>> >> And save them as configuration >>> >> >>> >>> On Sun, Dec 26, 2010 at 1:13 PM, Igor Stasenko <siguctua(a)gmail.com> >>> wrote: >>> >>> my wishlist: >>> >>> >>> >>> - a shortcut to see all available shortcuts and change them >>> >>> >>> >>> + a lot >>> >> >>> >> >>> >> >>> >> >>> >> <PharoScreenshot.2.png> >>> > >>> > >>> >>> >>> >> >

Dec. 31, 2010

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

by Mariano Martinez Peck

On Fri, Dec 31, 2010 at 9:42 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Dec 31, 2010, at 2:33 AM, csrabak(a)bol.com.br wrote: > > > Em 30/12/2010 19:56, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr > > escreveu: > > > >> Hi guys > >> I think that over the years I (but also many of you, I know) tried > >> to expose newbies to smalltalk or our culture. And often we get bad > >> reactions, bad windows, bad colors, slow, why not in svn, ..... I > > > > Those specific reactions are more likely to be about Squeak of Pharo > > than Smalltalk in general, isn't? > > why do you think that VW UI is appealing or that the class creation in VW > is trivial? > I am not sure if appealing, but more "normal" for sure. I don't say better. I just want to say that VW is more similar to IDEs from others lanaguages than what Squeak/Pharo is. > > >> think that showing Smalltalk to newbies is the best we can do to > >> ourselves, not really to attract new people but also to get a large > >> kick in the %^&* because most of the time students are not stupid, > >> they are exposed to other technos. > > > > Yes. They make an excellent litmus test without the risks of expending > > lots of money in the 'launching of product' which can become an Edsel > > of the programming languages... > > > >> So each time we believe we want > >> to show them something cool and they do not really consider it as > >> cool as we believe, we can of course think that they are idiot (some > >> of them are) but most of the time we can also think that may be we > >> stayed too long in our little boxes and the world moved (interfaced > >> well with c, fast, cool frameworks, has cool tools, processes > >> (integration...), cool UIs, web stuff.....). > > > > Indeed. > > > >> So each time we get > >> down because we do not see the little flame opening in the yes of > >> the others we can think hard and get from them what we missed. > > > > I believe this is the first step to get the best direction to follow. > > Not automatically this is not because people think that A is needed that it > is needed > but this is a good reality check. > > >> I really happy to get exposed to student acid tests, this is a > >> valuable feedback and I wanted to share that with you. > > > > Stef, now comes the rub: do you think it is possible to systematize > > the lessons learned and post a summary for us here? > > > Not really I do not record them but > - headless > - good ui > - not 20 tools to do the same but different > - github/make to build the vm > - decent integration tools > - not spaghetti code (you know Morph with just 800 methods show up > like a ugly class in Quality lectures) > - ... > > > > > Perhaps we should open a specific Wiki page on this? > > > > Regards, > > > > -- > > Cesar Rabak > > > > >

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Levente Uzonyi

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] UI for Shortcuts [WAS: Which Keymaps/Shortcuts do we want to have?]

by Alain Plantec

Very cool, thanks. The setting browser is easily extendable. see how Shout colors settings are integrated. Have a look at SHStyleSetting. the UI is declared in SHStyleSetting class>>settingInputWidgetForNode: Maybe we can have something like that for shortcuts: a drop list for the key modifier and a text field for the shortcut character. Cheers Alain Le 31/12/2010 00:28, Guillermo Polito a Ã©crit : > Hi, I would like to discuss the UI for shortcuts and not to impose it > :). So.. > > I was exploring the Idea of configuring the shortcuts in settings as > the screenshot shows. What do you think of that? I don't think we > need a separated tool to configure shortcuts. Settings look ok. > > Tomorrow I'll be putting a lot of effort on it ;). > > Cheers!

Dec. 31, 2010