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

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Guillermo Polito

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 :). 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 >> >> >> >> >>

Dec. 31, 2010

Re: [Pharo-project] [squeak-dev] Fireworks 2011

by Francisco Ortiz PeÃ±aloza

Nice, thanks and happy new year for you all! Fran On Fri, Dec 31, 2010 at 3:14 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Thanks a lot alexander > It was really cool. > > Stupidly I increased the volume waiting for the final fireworks :) > > Stef > > > > On Dec 31, 2010, at 5:12 PM, Alexander LazareviÄ wrote: > > > Just found some old code of mine and pushed it to squeaksource. > > > > In a 4.1 Squeak or recent trunk image do > > > > (Installer repository: 'http://www.squeaksource.com/Fireworks') install: > 'Fireworks'. > > (Smalltalk at: #FireworksAnimation) start. > > > > In a 1.1.1 Pharo image do > > > > ((Gofer new squeaksource: 'Fireworks') package: 'Fireworks') load. > > (Smalltalk at: #FireworksAnimation) start. > > > > :D > > > > All the best for 2011, > > Alex > > > > PS: ALT-. or CMD-. will help ;) > > > > >

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Levente Uzonyi

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 > > > > >

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Miguel CobÃ¡

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. 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

Dec. 31, 2010

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

by Geert Claes

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] realized and learned something today :)

by Stanislav Paskalev

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

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Levente Uzonyi

On Fri, 31 Dec 2010, Miguel CobÃ¡ wrote: > El vie, 31-12-2010 a las 17:18 +0100, Levente Uzonyi escribiÃ³: >> On Fri, 31 Dec 2010, Miguel CobÃ¡ wrote: >> >>> El vie, 31-12-2010 a las 10:22 +0100, Levente Uzonyi escribiÃ³: >>>> 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. >>> >>> But having a deprecated existing method also encourage to never update >>> the external packages, so old bits are floating around even if not >>> needed. Given the refactoring-mindset of the smalltalk community I'd say >> >> You're right, those popups with the deprecation warnings are really >> encouraging people to not update the code. And who would give a damn about >> the deprecation message anyway? It's better to guess why things don't work >> or ask someone else (list). > > Of course it is better. A pop up can be in some code path that only > seldom is executed. For someone loading the code, no warnings means that > everything is ok. Suppose they install it on a server side image > thinking that everything is ok. Then sometime after that, the image > stops working because the headless mode can't allow to see the popup > that is waiting for someone to press a button. Again, the GUI is good > sometimes, but sometimes is better to fail earlier. > If on loading it doesn't load because of some missing method, the user > can see right there that something is wrong with the package is trying > to use. 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. Anyway, there's no reason to remove a method (especially an API method) without deprecating and keeping it around for a few releases. Levente > > Cheers > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > >

Dec. 31, 2010

Re: [Pharo-project] [ANN] SqueakMovieMorph (Alpha) plays any video file playable by QuickTime

by StÃ©phane Ducasse

Yes that should do it ;) Stef > StÃ©phane Ducasse wrote: >> >> Sean pay attention that the license of sophie... >> > > Thanks for reminding me Steph. I checked the Sophie site and it seems the > only requirement is to include the license text with the code, so I pasted > it into a class comment in an -Info sub-category. > > Sean > -- > View this message in context: http://forum.world.st/ANN-SqueakMovieMorph-Alpha-plays-any-video-file-playa… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 31, 2010

Re: [Pharo-project] [ANN] SqueakMovieMorph (Alpha) plays any video file playable by QuickTime

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > Sean pay attention that the license of sophie... > Thanks for reminding me Steph. I checked the Sophie site and it seems the only requirement is to include the license text with the code, so I pasted it into a class comment in an -Info sub-category. Sean -- View this message in context: http://forum.world.st/ANN-SqueakMovieMorph-Alpha-plays-any-video-file-playa… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 31, 2010

Re: [Pharo-project] WeakArray>>isFinalizationSupported

by Levente Uzonyi

On Fri, 31 Dec 2010, Igor Stasenko wrote: > 2010/12/31 Levente Uzonyi <leves(a)elte.hu>: >> On Fri, 31 Dec 2010, Igor Stasenko wrote: >> >>> 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 >>> :) >> >> I described my ideas here, so I won't repeat it. But I can tell you that >> removing a method which wasn't deprecated at all is _not_ a proper >> deprecation policy. >> > can you give a pointer, where i can read about it? You can search this mailing list. But to make it a bit easier, it's basically the same as what it's intended to be: - deprecate all non-private methods that are to be removed (some private methods should also be deprecated) - keep the deprecated methods for at least one new release - calculate the deprecation dates from the method timestamps > >>> >>> Nothing is perfect, but its not the reason to fight. >> >> There's no fight. >> > uh okay.. whatever you call it :) ... Levente > >> >> Levente >> > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Dec. 31, 2010