January 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Updates: Status: Accepted Comment #3 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 we should pay attention that some methods are tagged 1.1 but this is better to key them in SmalltalkImage so we should probably just put them in a deprecated category but not in the package and add a comment to them

Jan. 1, 2011

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Comment #2 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 http://code.google.com/p/pharo/issues/detail?id=2733

Jan. 1, 2011

Re: [Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Comment #1 on issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 related to 2733

Jan. 1, 2011

[Pharo-project] Issue 3501 in pharo: Remove 1.1 deprecated methods and publish them in a separate package

by pharo＠googlecode.com

Status: Fixed Owner: stephane.ducasse Labels: Milestone-1.3 New issue 3501 by stephane.ducasse: Remove 1.1 deprecated methods and publish them in a separate package http://code.google.com/p/pharo/issues/detail?id=3501 1.1 deprecated methods should be packaged in a separate package and unloaded from 1.3

Jan. 1, 2011

[Pharo-project] fixing deprecation process once for all

by StÃ©phane Ducasse

I took 5 min and wrote down that http://code.google.com/p/pharo/wiki/DeprecationProcess comment if you want.

Jan. 1, 2011

[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