- Pharo-dev - lists.pharo.org

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

by Sean P. DeNigris

Noury Bouraqadi-2 wrote: > > 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! > Aha, okay now I understand: Object subclasses detect: [ :c | c name = #AClassForTesting ]. "Returns: AClassForTesting" Thanks again, Noury. Sean -- View this message in context: http://forum.world.st/Creating-temporary-classes-for-testing-tp3080408p3082… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 10, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Diogenes Moreira

Hi.. Ring will be good improvement.. Thank for you effort But some comments about your propousal (i may be wrong in some concepts but, may be this commets will be a guide ) classSymbol vs className, in y opnion classSymbol define better because this message return a Symbol.. in case className I would expect for this message return a String sourceString and sourceCode in some case can be different,,in most cases are the same category may by usefful. i'm use this by example for iterate on the accessors Best Regards On Fri, Dec 10, 2010 at 10:32 AM, Veronica Isabel Uquillas Gomez < vuquilla(a)vub.ac.be> wrote: > Dear all, > > I am currently working on the *Ring*, an unifying and foundational model > infrastructure for Pharo. > The goals are: > - Provide a common API at structural and runtime level > - Allow tools to interact and integrate directly with the host environment > (Pharo) > - Support history analysis > > I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, > Smalltalk itself and Ginsu, as a basic to build the Ring. > So far I have implemented the main classes including the ones that should > replace MethodReference and the Pseudo classes. > > An unified API will imply changes in most of the ones mentioned above (as > most of them are non-polymorphic). > As a first step, I would like to have your opinion about the proposal for > replacing MethodReference (attached file). > > > Best Regards, > Veronica Uquillas > > > > > > > > > >

Dec. 10, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by Igor Stasenko

WoW. That's quite ambitious project and will require the huge overhaul of existing code. I really hope that you will succeed with it. Do not hesitate asking for help of advice. I will try to comment proposal a bit later. On 10 December 2010 14:32, Veronica Isabel Uquillas Gomez <vuquilla(a)vub.ac.be> wrote: > Dear all, > I am currently working on the Ring, an unifying and foundational model > infrastructure for Pharo. > The goals are: > - Provide a common API at structural and runtime level > - Allow tools to interact and integrate directly with the host environment > (Pharo) > - Support history analysis > I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, > Smalltalk itself and Ginsu, as a basic to build the Ring. > So far I have implemented the main classes including the ones that should > replace MethodReference and the Pseudo classes. > An unified API will imply changes in most of the ones mentioned above (as > most of them are non-polymorphic). > As a first step,Â I would like to have your opinion about the proposal for > replacing MethodReference (attached file). > > Best Regards, > Veronica Uquillas > > > > > > > > > -- Best regards, Igor Stasenko AKA sig.

Dec. 10, 2010

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

by Martin Dias

Hi Colin Another thing to consider are the clusters. I think they are good because they avoid a lot of overhead. Following the example used in the slides, for serializing N rectangles, it writes: - in vertexes section: 'Rectangle' 'origin' 'corner' N - in edges section: 2*N indexes (references to the origin and corner points) Without clustering, I think each rectangle stored should have some header to say that its an instance of Rectangle. Martin On Fri, Dec 10, 2010 at 11:03 AM, Tristan Bourgois <tristan.bourgois(a)gmail.com> wrote: > >> Hi Martin, >> >> Looks very interesting. Reading the material you posted, the question >> that jumps out at me is this: from the benchmarks, it's clear that >> materializing is faster than serializing, but it's not clear why. How >> does separating the nodes from the edges of the object graph make >> materializing faster? >> >> Thanks, >> >> Colin > > Hi! > > Separate the nodes from the edges of the object permit during the > serialization > to pass only one time on the byte code. > So first we pass on the node so we recreate the objects/nodes and second > when > we pass on the edges we recreate the links between the objects. > > I hope I answered your question :) > > Tristan >

Dec. 10, 2010

Re: [Pharo-project] Ring - model infrastructure for Pharo

by StÃ©phane Ducasse

Thanks veronica I hope that people will react and yes having a nice API for most of the tools is important. Stef > Dear all, > > I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. > The goals are: > - Provide a common API at structural and runtime level > - Allow tools to interact and integrate directly with the host environment (Pharo) > - Support history analysis > > I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. > So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes. > > An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). > As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file). > > > Best Regards, > Veronica Uquillas > > <Ring-forMethodReference.pdf> > > > > > >

Dec. 10, 2010

Re: [Pharo-project] A suggestion.

by Diogenes Moreira

Thank Stef.. Actually im using chalten in my application, my suggestion was oriented to replace the hardcode to use the same way such as other chronologycs constants.. Best On Fri, Dec 10, 2010 at 10:58 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > The problem is that we should not change kernel methods. > I suggest that we use chronos or chalten for localized applications. > > Stef > > > > Hi folks. > > > > First make a question, in this list. > > > > String>>asDate message assume(harcode way) english date format.. may be.. > > may be better if the date format to take it to a context variable as with > the names of the months? > > > > Best.. > > >

Dec. 10, 2010

Re: [Pharo-project] A suggestion.

by StÃ©phane Ducasse

The problem is that we should not change kernel methods. I suggest that we use chronos or chalten for localized applications. Stef > Hi folks. > > First make a question, in this list. > > String>>asDate message assume(harcode way) english date format.. may be.. > may be better if the date format to take it to a context variable as with the names of the months? > > Best..

Dec. 10, 2010

[Pharo-project] Ring - model infrastructure for Pharo

by Veronica Isabel Uquillas Gomez

Dear all, I am currently working on the Ring, an unifying and foundational model infrastructure for Pharo. The goals are: - Provide a common API at structural and runtime level - Allow tools to interact and integrate directly with the host environment (Pharo) - Support history analysis I started comparing the APIs of RB, MethodReference, Pseudo classes, MC, Smalltalk itself and Ginsu, as a basic to build the Ring. So far I have implemented the main classes including the ones that should replace MethodReference and the Pseudo classes. An unified API will imply changes in most of the ones mentioned above (as most of them are non-polymorphic). As a first step, I would like to have your opinion about the proposal for replacing MethodReference (attached file). Best Regards, Veronica Uquillas

Dec. 10, 2010

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

by Lukas Renggli

No, don't waste time on reverting. I almost got it working. My comment was ment for the future :-) Lukas On 10 December 2010 13:02, Alain Plantec <alain.plantec(a)free.fr> wrote: > so, concerning the new editor changes, I would like to help because this > messy situation is partly my fault. > would it be helpful if I rename current TextEditor as TextEditor2, (give me > another name please ...), > current SmalltalkEditor as SmalltalkEditor2 and reintroduce the previous > implementation > for TextEditor and SmalltalkEditor ? > Cheers > Alain > > Le 10/12/2010 00:32, Lukas Renggli a Ã©crit : >>> >>> 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. 10, 2010

Re: [Pharo-project] A suggestion.

by Diogenes Moreira

One data more... may be, can be definied un ChronologyConstants class On Fri, Dec 10, 2010 at 9:27 AM, Diogenes Moreira < diogenes.moreira(a)gmail.com> wrote: > Hi folks. > > First make a question, in this list. > > String>>asDate message assume(harcode way) english date format.. may be.. > may be better if the date format to take it to a context variable as with > the names of the months? > > Best.. >

Dec. 10, 2010