- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3500 in pharo: Create deprecated13

by pharo＠googlecode.com

Status: Fixed Owner: stephane.ducasse New issue 3500 by stephane.ducasse: Create deprecated13 http://code.google.com/p/pharo/issues/detail?id=3500 We should create a package deprecated13 as one of the first move in 1.3.

Jan. 1, 2011

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

by StÃ©phane Ducasse

Thanks stan :) If you are looking for a master topic let us know :) Now my point was more on us getting reality check than students not adoring our language. Stef > It vastly depends on the way it's presented. I'm a forth year student > myself, I've been working for several years in java shops (& flex > recently) and since I've discovered Pharo I started avoiding > everything else :) > > The image itself, dev tools in the same vm that runs the application, > excellent frameworks (seaside is much much much more easier to setup > and also that much easier to use compared to any, any java web > framework), the really nice api/kernel classes. I DO love it!, and > I've been exposed to basically everything else popular :) > > However, one has to walk the path of pain (manually editing source > code without highlight and completion, non-verbose compilers, missing > debuggers, weird runtime dependencies/dll/jar hells, etc) to fully > appreciate pharo and smalltalk in general. Otherwise he won't have the > base to compare. > Stanislav Paskalev > > > > On Fri, Dec 31, 2010 at 7:06 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> My point was not about pharo against squeak. I'm not at the microscopic level.... >> I'm just thinking that remembering when is the last we were bold and face a complete room to students knowing Java, ruby.... >> is a good way to get feedback on what we believe is cool. >> >> Stef >

Jan. 1, 2011

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by StÃ©phane Ducasse

Eliot I was replying and I throw away the mail :) I already applied my new year resolution :) Stef PS: we know all that we should have better deprecation policy. We apply that but deprecation is good for little changes not huge ones. > > > On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > Oh, come on... > > Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated. > > I'm tired of this stupid arguments. > > I expect the new year will bring us more doing and less discussing :). > > Unless we are prepared to discuss, discover, admit and correct our mistakes our doing will be of little worth. I don't see anything stupid in discussing deprecation policy. This criticism of Levente is entirely unjustified and reminds me of recent treatment of certain prominent whistle-blowers. Can we just drop the childish feelings of hurt, and direct ourselves to the substance of arguments rather than our immediate emotional reactions to email? We should all know by now that email is a particularly inexpressive medium, prone to misinterpretation and therefore it behooves us to take a breath before we reply and try and read beyond our surface perceptions. [I am a hypocrite in this regard having over-reacted recently over timestamps.] > > Doubtless we are all imperfect in our use of email and can all do better here. But we won't get any better by lacking objectivity and reacting emotionally to valid criticism. Can we make one of our new year's resolutions an attempt to be less emotional and more objective in all our email discussions in the broader Squeak community? Please? > > Happy New Year > Eliot > > 2010/12/31 Levente Uzonyi <leves(a)elte.hu> > > On Fri, 31 Dec 2010, Miguel CobÃ¡ wrote: > > El vie, 31-12-2010 a las 20:05 +0100, Levente Uzonyi escribiÃ³: > What you describe here is simply bad practice. One should run the tests > before deploying code (besides testing the complete system thoroughly). > If you use RFB, you can access the GUI in headless mode. Also when a > debugger opens with a deprecation warning, the stack trace is written to > the log file, so you will be notified about the problem even when you > don't have access to the GUI. > > Yeah, sure. But if it a second level dependency (a package I use that > uses a package that contains popups deprecation warnings) I have big > chances of being bite by this problem. I concede, this could be avoided > by test-running every and whatnot package in the image but for a system > that updates automatically this will bite. > > So you're saying that it's better to get a DNU instead of a deprecation warning with proper description about what and how to update/change? > > > Levente > > > Also, even if I can use RFB or read the image logs, I most likely will > monitor the application logs and will pass a time without me knowing > that some part of the application is waiting some user input. > At the end I expect that the maintainer of the package is the > *responsible* of test the application for the image I use, and not the > user of the package. That is what I do with magma on Pharo. I test and > fix the issues generated by the evolution of Pharo and then I release a > new ConfigurationOfMagma that the user can use without knowing that n > deprecations were involved in the upgrade of the package. > > > > Anyway, there's no reason to remove a method (especially an API method) > without deprecating and keeping it around for a few releases. > > > I agree that is better to not forget to mark some method as deprecated > but, again, I think that this promote the external packages not being > updated to the current pharo image. > > Cheers > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > > >

Jan. 1, 2011

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by StÃ©phane Ducasse

On Dec 31, 2010, at 8:50 PM, Guillermo Polito wrote: > Oh, come on... > > Levente, we all agree with you. Pharo is trying to use that deprecation policy since some months ago... Sometimes people make mistakes (me included) and don't do it, but we agreed that we have to deprecate and remove after two versions of being deprecated. > > I'm tired of this stupid arguments. > > I expect the new year will bring us more doing and less discussing :). + 1 What is interesting is to see that such kind of emails are often coming from the same source. BTW guillermo I reallllllly deeply appreciate what you are doing on shortcut. I will have a look soon. Now I'm fighting with pomodoro to get rid of an important porposal I keep postponing like an idiot. Stef

Jan. 1, 2011

Re: [Pharo-project] Proper Smalltalk lots of classes

by StÃ©phane Ducasse

> Hello, > > I am porting the FIX protocol to Squeak/Pharo. > http://www.fixprotocol.org/ > > It is the Financial Information eXchange protocol. It is used by many firms in the financial industries, stocks, forex, etc. Excellent! > > There is good documentation and also a semi-reference implementation in Java. > http://www.quickfixj.org > > I have a partial port started but I wanted a check with those who know more than I about proper Smalltalk coding. > > In the Java implementation there are over 2000 classes. In the protocol there are approximately 90 message types and 956 field types. > > I am initially creating the message classes as they form the basis of the protocol and the fields are simply instance variables and methods in the message classes. do you have some examples because replying like that in the blue is difficult. > I am not porting the Java library. I am implementing the protocol in Smalltalk from the documentation. > > Initially I have created a Fix44Field class with its necessary variables. > There are several versions of the Protocol and FIX 4.4 is the one required for my application. > > With this Fix44Field class I am creating a Dictionary with the 956 different field types. I am planning on creating a constructor method which will create the desired field from the information in the dictionary about the field and its properties. this sounds right. or you can have a method that takes a list and fill up > > Am I way off base here? Should I really create the 956 classes necessary to for each field in addition to the 90 or so message classes, and then I don't know what else I haven't discovered yet. Having 1000+ classes just seems unwieldy and naively it just doesn't feel like the Smalltalk way. For me number of classes has never been a design criteria. Now is the behavior different on each of them? what are the variations? Can we represent them as constant in a classVar somewhere? > I could be wrong, but I haven't seen such an example to my memory. I don't know enough about Java to know if it is good Java form either. > > When I have a reasonably fleshed out, tested and working solution, I will make the source available under a MIT license. I would love to see Squeak/Pharo become an out of the box viable option for trading applications. me toooooooooooo :) > > Advise and wisdom greatly appreciated. > > Thanks. > > Jimmie >

Jan. 1, 2011

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

by pharo＠googlecode.com

Comment #6 on issue 3498 by rydier: remove:ifAbsent: in linked list leads to interruption/sync problems http://code.google.com/p/pharo/issues/detail?id=3498 For the record, it was rewritten to accept regular objects as well as links as arguments (in which case a ValueLink for the object is created with add/found and removed with remove) removeLink:ifAbsent: is exactly the same as remove:ifAbsent: in Squeak The reason I did not add the ifAbsent: block to the removeLink: call in new remove:ifAbsent: was pure ignorance, I was not aware LinkedLists methods were supposed to be thread-safe, for instance add:after: is not, neither in Pharo nor Squeak. The version currently in Pharo (without ifAbsent:) is perfectly valid if thread-safeness is not a criterion.

Jan. 1, 2011

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

by pharo＠googlecode.com

Comment #5 on issue 3498 by rydier: remove:ifAbsent: in linked list leads to interruption/sync problems http://code.google.com/p/pharo/issues/detail?id=3498 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 ifAbsent: [^aBlock value]. ^aLinkOrObject

Jan. 1, 2011

Re: [Pharo-project] UI for Shortcuts [WAS: Which Keymaps/Shortcuts do we want to have?]

by Tudor Girba

Hi, On 31 Dec 2010, at 17:44, Guillermo Polito wrote: > > > On Fri, Dec 31, 2010 at 6:57 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > 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 ',' ? > > Yes, yes, I was only prototyping... Actually I shoud rename KMMeta to KMCommand :P. If I understand correctly what + and , mean I like them a lot. As I understand the difference is: - with + you to compose keys (for example, Ctrl+s accepts in Smalltalk) - with , you concatenate key sequences for example (for example, Ctrl+x , s saves in Emacs) Cheers, Doru > 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 ;) > > Mmm, I can take what Alain said and this, and have a nice thing ;) > > > 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> > > > > > > > > > > -- www.tudorgirba.com "Presenting is storytelling."

Jan. 1, 2011

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

by Schwab,Wilhelm K

Smalltalk didn't do it: Dan did it USING Smalltalk :) No argument that there is room for improvement, but the changes in Pharo over the past couple of years should not be ignored. For years, I beat drums that Morphic was a great simulation environment, and that it was time for it to be used to simulate a modern user interface. Pinesoft has made wonderful progress on that. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Geert Claes [geert.wl.claes(a)gmail.com] Sent: Friday, December 31, 2010 2:26 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] realized and learned something today :) StÃ©phane Ducasse wrote: > > 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. > Smalltalk invented the graphical user interface and IDE 30 years ago and this is where I reckon some re-inventing is long overdue with a focus ons user experience and usability :) -- View this message in context: http://forum.world.st/realized-and-learned-something-today-tp3168835p316973… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Igor Stasenko

On 31 December 2010 22:49, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Fri, Dec 31, 2010 at 11:50 AM, Guillermo Polito > <guillermopolito(a)gmail.com> wrote: >> >> Oh, come on... >> >> Levente, we all agree with you.Â Pharo is trying to use that deprecation >> policy since some months ago...Â Sometimes people make mistakes (me >> included) and don't do it, but we agreed that we have to deprecate and >> remove after two versions of being deprecated. >> >> I'm tired of this stupid arguments. >> >> I expect the new year will bring us more doing and less discussing :). > > Unless we are prepared to discuss, discover, admit and correct our mistakes > our doing will be of little worth. Â I don't see anything stupid in > discussing Â deprecation policy. Â This criticism of Levente is entirely > unjustified and reminds me of recent treatment of certain prominent > whistle-blowers. Â Can we just drop the childish feelings of hurt, and direct > ourselves to the substance of arguments rather than our immediate emotional > reactions to email? Â We should all know by now that email is a particularly > inexpressive medium, prone to misinterpretation and therefore it behooves us > to take a breath before we reply and try and read beyond our surface > perceptions. Â [I am a hypocrite in this regard having over-reacted recently > over timestamps.] I have expressed my disgust about stamps quite emotionally too. Didn't mean to hurt anybody, just were too sad that we have to spend our energy to take care about things like that instead of doing something else. > Doubtless we are all imperfect in our use of email and can all do better > here. Â But we won't get any better by lacking objectivity and reacting > emotionally to valid criticism. Â Can we make one of our new year's > resolutions an attempt to be less emotional and more objective in all our > email discussions in the broader Squeak community? Â Please? Amen. > Happy New Year > Eliot >> -- Best regards, Igor Stasenko AKA sig.

Dec. 31, 2010