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

Re: [Pharo-project] Creating temporary classes for testing

by Luc Fabresse

Hi, You should look at : ClassFactoryWithOrganizationForTestCase I guess it is exactly what you are looking for. And also SystemNavigationTest and SystemNavigationOnNewlyCreatedEnvironmentTest that uses an instance of this above class. #Luc 2010/12/10 Noury Bouraqadi <bouraqadi(a)gmail.com> > > On 10 dÃ©c. 2010, at 02:15, Sean P. DeNigris wrote: > > Noury Bouraqadi-2 wrote: > >> > >> You need... to delete all references to classes for your environment > from > >> their superclasses. > >> This is part of what is performed by the obsolete message. > >> > > > > If I evaluated the code from my original post in a workspace, and then > > closed it, wouldn't everything go away when the temporary > SystemDictionary > > (which contains the SystemOrganizer and newClass) was gc-ed? > > > Object subclasses collection still includes a reference to the class you > created in a different envirenment. It will never be GCed. So, this is a > memory leak! > > Noury > > >

Dec. 10, 2010

[Pharo-project] [update 1.2] #12274

by Marcus Denker

12274 ----- Issue 3394: Adopt disappeared from Monticello Browser Issue 3395: Capitalization of Author -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Dec. 10, 2010

Re: [Pharo-project] Issue 3395 in pharo: Capitalization of Author

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3395 by marcus.denker: Capitalization of Author http://code.google.com/p/pharo/issues/detail?id=3395 12274

Dec. 10, 2010

Re: [Pharo-project] Issue 3394 in pharo: Adopt disappeared from Monticello Browser

by pharo＠googlecode.com

Updates: Status: Closed Comment #3 on issue 3394 by marcus.denker: Adopt disappeared from Monticello Browser http://code.google.com/p/pharo/issues/detail?id=3394 12274

Dec. 10, 2010

Re: [Pharo-project] Creating temporary classes for testing

by Noury Bouraqadi

On 10 dÃ©c. 2010, at 02:15, Sean P. DeNigris wrote: > Noury Bouraqadi-2 wrote: >> >> You need... to delete all references to classes for your environment from >> their superclasses. >> This is part of what is performed by the obsolete message. >> > > If I evaluated the code from my original post in a workspace, and then > closed it, wouldn't everything go away when the temporary SystemDictionary > (which contains the SystemOrganizer and newClass) was gc-ed? > Object subclasses collection still includes a reference to the class you created in a different envirenment. It will never be GCed. So, this is a memory leak! Noury

Dec. 10, 2010

Re: [Pharo-project] Fuel - a fast object deployment tool

by Levente Uzonyi

On Thu, 9 Dec 2010, StÃ©phane Ducasse wrote: >>>>> It does! >>>>> It seems that you did not work in VW2.5 and 3.0 and when parcels arrived loading was realllllly a big difference >>>>> I do not see why this would not the same with Fuel. >>>> >>>> No I didn't, but the version number of VW is around 7.x now, so I guess the CPUs and VMs are now several times faster. Does it really matter if it takes 200ms or 20ms to load a package? >>> >>> When I load a package with MC so far I still notice it and I would not even think about it. >>> It should load in a unnoticeable amount of time. >> >> Do you think MC is "slow" because the Compiler is "slow"? > > not totally but I do not understand why this is obligatory to compile everything all the time. > Then Opal will be slower than the old comcrapiler. > I did a quick test where it took 4294ms to load RoelTyper + OCompletion from disk (no socket creation, no network latency, etc). These packages contain 790 methods. 5.1% of the total time was spent for compilation, that's 219ms. The rest is used by other stuff like: - loading the files from disk - writing the source code to disk (sources/changes files) - evaluating class side #initialize methods - processing system change notifications Another 51ms was spent in creating 63 classes and 107ms to install the CompiledMethods to the classes. So that's 219+51+107 = 377ms for creating all classes and their methods. The rest is administration which can not be avoided by binary loading. Even if binary loading is 10x faster than compiling the code (which I doubt), then you save 339ms. So it would take only 3917ms to load these packages. That would save you 7.9% of the total time. Levente

Dec. 10, 2010

Re: [Pharo-project] Creating temporary classes for testing

by Sean P. DeNigris

Thanks, Noury. I didn't understand one part: Noury Bouraqadi-2 wrote: > > You need... to delete all references to classes for your environment from > their superclasses. > This is part of what is performed by the obsolete message. > If I evaluated the code from my original post in a workspace, and then closed it, wouldn't everything go away when the temporary SystemDictionary (which contains the SystemOrganizer and newClass) was gc-ed? Sean -- View this message in context: http://forum.world.st/Creating-temporary-classes-for-testing-tp3080408p3081… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 10, 2010

Re: [Pharo-project] about cloud in pharo

by GermÃ¡n Arduino

When I read about the Heroku buy the first thing I remembered was Morphle project because it's leader, Merik, all the time was focused in a business model as Heroku had. Myself worked a bit (on the side image) some time ago to help have (not cloud still) but multiple seaside customers (as some others experiments). Today I think that Morphle is already running such business and, may be, doing things thinking in cloud. In summary, I'm sure that cloud is the way to go, and count me in to any idea related with some sort of business/startup/entrepreneural initiative around Pharo on the cloud. Cheers. GermÃ¡n. 2010/12/9 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > On Thu, Dec 9, 2010 at 11:14 AM, stephane ducasse <stephane.ducasse(a)free.fr> > wrote: >> >> Hi guys >> >> When I see that. I would really like to see how we can create something >> around the cloud. We have a lot of assets. >> Does anybody have some interest bootstrapping a business around that? > > _very_ Â I'd love to do high-quality VM work funded in this kind of context. > >> >> Today http://heroku.com/ were bought by Salesforce for over 200 million >> (http://techcrunch.com/2010/12/08/breaking-salesforce-buys-heroku-for-212-mi…) >> >> Stef > > -- ================================================= GermÃ¡n S. ArduinoÂ <gsa @ arsol.net>Â Â Twitter: garduino Arduino Software & Web HostingÂ Â http://www.arduinosoftware.com PasswordsProÂ http://www.passwordspro.com =================================================

Dec. 9, 2010

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by Lukas Renggli

> I said it before: just give the variable a different name. For example, textStyle. That would solve all loading problems. I said it before: This doesn't solve anything at all. In fact it is much easier to remove the variable and fork the code. Renaming causes a ripple effect to lots of methods and makes it impossible to merge the forks in the future. The style variable is just one example of the problem. I am suggesting that the next time the editor framework is replaced the old code is left untouched, then deprecated, and different class names are chosen for the new implementation. Like this both frameworks can coexist for a while making it much easier to migrate the code. The current situation comes from the fact that some existing classes changed their class layout and API completely making migration really difficult. Lukas -- Lukas Renggli www.lukas-renggli.ch

Dec. 9, 2010

Re: [Pharo-project] Why was the old Editor Functionality Removed?

by Mariano Martinez Peck

On Thu, Dec 9, 2010 at 10:32 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > I guess I'm the one who made all this bad changes. > > So sorry, sorry sorry. > > I don't think so. > > > Maybe we can come back to the "old" one. > > No problem for me. > > I think the main problem is that the new editor model (which I really > like) was merged directly into the existing editor morphs, so > everything that uses more than just the morphs breaks. > > > I can make a slice in that direction. > > I am not sure if this is possible anymore, because now we have > dependencies on PluggableTextMorph and friends with the old API and > dependencies on PluggableTextMorph and friends with the new API. > > > But frankly, what a catastrophic mail for people who are trying > > to make the system cleaner. > > do you know how much of my free time I've spent to make the undo/redo > work again? > > Maybe one can just simply ask for help instead of blaming. > > I am *not criticizing* the system cleanup. I am criticizing the > changes that didn't go through a deprecation phase. I don't fully agree. We should deprecate certaing methods when it is really worth it. Deprecating each fucking method you remove its insane, overwork and I gues it will kill the process. There may be places that we didn't depreacte but should do it. But we cannot deprecate everything. Don't exagerate. > It started with > the introduction of the 'style' variable in a commonly used > superclass. The problem was discussed a long time ago and I was shut > up; today the problem turns out to be way worse. > > > OCompletion works and it includes ECompletion. Since I added a setting > > for using ECompletion instead of OCompletion (and not just as a fallback > > mechanism), ECompletion is also working with the new editors. > > I looked at the OCompletion changes and tried to merge them into > eCompletion, but as Francisco says it is only kinda working. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > >

Dec. 9, 2010