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

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.412.mcz]

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2086 If you publish a slice this will help :) Stef On Feb 27, 2010, at 8:30 AM, Miguel Enrique CobÃ¡ Martinez wrote: > This can be useful too. > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > From: commits(a)source.squeak.org > Date: February 26, 2010 10:27:26 PM GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Kernel-ar.412.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-ar.412.mcz > > ==================== Summary ==================== > > Name: Kernel-ar.412 > Author: ar > Time: 26 February 2010, 11:26:03.981 pm > UUID: 59fae938-7c7e-714c-8299-9d6e1ae5583b > Ancestors: Kernel-ar.411 > > Introduce a cleanUp/cleanUp: protocol based on the proposal from Mantis: > > http://bugs.squeak.org/view.php?id=7244 > > The cleanUp protocol takes an optional argument to indicate whether we're doing an aggressive cleanup (which involves deleting projects, change sets, and possibly other destructive actions) or a more gentle cleanup that's only supposed to clean out transient caches. > > > =============== Diff against Kernel-ar.411 =============== > > Item was added: > + ----- Method: Behavior>>cleanUp (in category 'initialize-release') ----- > + cleanUp > + "Clean out any caches and other state that should be flushed when trying to get an image into a pristine state. Subclasses may override #cleanUp: to provide different levels of cleanliness" > + ! > > Item was added: > + ----- Method: ClassOrganizer class>>cleanUp: (in category 'class initialization') ----- > + cleanUp: aggressive > + "Remove empty method categories when cleaning aggressively" > + > + aggressive ifTrue:[Smalltalk removeEmptyMessageCategories]. > + ! > > Item was added: > + ----- Method: MethodDictionary class>>cleanUp: (in category 'initialization') ----- > + cleanUp: aggressive > + "Compact method dictionaries when aggressively cleaning up" > + > + aggressive ifTrue:[self compactAllInstances]. > + ! > > Item was added: > + ----- Method: Behavior class>>cleanUp (in category 'class initialization') ----- > + cleanUp > + "Flush the obsolete subclasses." > + > + self flushObsoleteSubclasses! > > Item was added: > + ----- Method: Behavior>>cleanUp: (in category 'initialize-release') ----- > + cleanUp: aggressive > + "Clean out any caches and other state that should be flushed when trying to get an image into a pristine state. The argument should be used to indicate how aggressive the cleanup should be. Some subclasses may act differently depending on its value - for example, ChangeSet will only delete all unused and reinitialize the current change set if we're asking it to be aggressive." > + > + ^self cleanUp! > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] We should run + fix the tests in 1.1

by StÃ©phane Ducasse

On Feb 26, 2010, at 9:55 PM, Michael Roberts wrote: > my experience is similar to Yanni, in that I found a series of > updates, every so often, would break the build. it became a pain to > keep on checking and fixing things. So i am spending my time on > trying to script some sanity checks and logic for common errors. Given > the pace of updates, whilst human intervention is the simple solution, > i don't think it is great. One gets behind very quickly. > > Also, how many developers regularly look at the test result pages (the > first version on the wiki, the gforge /experimental, yanni's hudson > setup) for the core image and act on the implied bugs in the update? > i.e comment on the issue tracker related to the specific update just > published > > I think we need to email the delta of each test run to this mailing > list as soon as it is run. Yes I think that we should streamlined our process - fast running tests - faster tests -> we should have a look at the changes adrian kuhn sent - run and fix more often. Stef > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by StÃ©phane Ducasse

Thanks a lot miguel Stef On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: > Maybe we can add this to the cleanUpForRelease script. > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > From: commits(a)source.squeak.org > Date: February 26, 2010 6:38:01 PM GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-ar.411.mcz > > ==================== Summary ==================== > > Name: Kernel-ar.411 > Author: ar > Time: 26 February 2010, 7:36:40.257 pm > UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd > Ancestors: Kernel-ul.410 > > Add MethodDictionary class>>compactAllInstances to save space in releases. Compacting all MDs in my images saves 600k in image size which isn't bad at all. > > =============== Diff against Kernel-ul.410 =============== > > Item was added: > + ----- Method: MethodDictionary class>>compactAllInstances (in category 'initialization') ----- > + compactAllInstances "MethodDictionary compactAllInstances" > + "Compacts all MethodDictionaries to save space" > + > + | oldInstances newInstances | > + oldInstances := self allInstances. > + newInstances := oldInstances collect:[:md| > + (self new: md size) > + compactCopyFrom: md; > + yourself]. > + oldInstances elementsForwardIdentityTo: newInstances. > + ! > > Item was added: > + ----- Method: MethodDictionary>>compactCopyFrom: (in category 'private') ----- > + compactCopyFrom: sourceMD > + "Copy the contents of source dictionary without growing" > + > + sourceMD keysAndValuesDo:[:key :value| | index | > + index := self scanFor: key. > + (self basicAt: index) ifNotNil:[self error: 'Something is horribly broken']. > + self basicAt: index put: key. > + array at: index put: value. > + tally := tally + 1. > + ]. > + self size = self capacity ifTrue:[self grow]. "grow only if we reach capacity" > + ! > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by StÃ©phane Ducasse

On Feb 27, 2010, at 4:13 AM, Igor Stasenko wrote: > On a second thought, i think this is not really necessary. > > Traits can be reformulated to be purely a method source holders, not > holders of compiled methods. > (And btw, this is actually true, due to the latest changes in traits, > because of super sends issues and > #methodClass), we only need to push it a little further and get rid of > useless limitations. > > The point is, that all trait methods should _always_ be compiled in > the scope of the class to which it applied. Yes this was implied in what I said but I did not want to say it explictly :) > Because, for any variable name, which not declared explicitly in the > method's scope, we can't tell anything about it, > until we apply this method to the real class (See the Class>>bindingOf: ) > This means that, even if you having the trait method: > > foo > ^ Array new: 10 > > the binding of 'Array' variable may be different, depending on class > where its installed. > To check it, you can try following at home: > > Object subclass: #ZZZZ > instanceVariableNames: '' > classVariableNames: 'DD' > poolDictionaries: '' > category: 'ZZZZ' > > "add new pool variable" > ZZZZ classPool at: #Array put: 10. > > "now add the method" > array > ^ Array > > and now evaluate the following: > ZZZZ new array > > ------------- > But what makes > array > ^ Array > > method any better than > > array > ^ array := 10. > > in this regard? > > Nothing. So, why not drop the limitation, and instead of punishing > developer for use undeclared vars in trait methods, > punish him for use of undeclared variables, when he tries to apply the > trait to concrete class, where all such var names should obtain > meaning? > > Then, ultimately, what is the point in storing compiling methods in > Trait (not for classes, where it applied). We could just check the > syntax, but should not produce any CompiledMethod instances at all. > > What other problems i don't see here? I do not see. I think that this is nice to do another iteration around traits. > > > On 27 February 2010 02:10, Stan Shepherd <stan.shepherd414(a)gmail.com> wrote: >> >> >> Igor Stasenko wrote: >>> >>> One of the ways of introducing a stateful traits is changing the VM >>> object format. >>> >> Sounds like it could be very powerful. >> >> As it happens, in the fork healing example, it's the very statelessness of >> the traits that make it work so simply. By taking out the check for >> statefulness when the method is moved to a trait, the trait will quite >> happily address the several variables in its user classes. This then removes >> any need for accessors, helper classes for state, initialization, or other >> attempts to tame the beast. >> >> I wouldn't want to rely on it continuing to work in all conditions, but as a >> step in a refactoring it seems very handy. >> >> ..Stan >> -- >> View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571553.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by StÃ©phane Ducasse

orthogonally to traits I sometimes would like python like hash based (but class and not object) semantics ie Object dictionaryVariable: #MyClass Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code when a method add a property extension to a morph, another tests for its value and the third one remove it. You get code that is really difficult to understand. > <key1><value1> > <key2><value2> On Feb 27, 2010, at 12:39 AM, Igor Stasenko wrote: > One of the ways of introducing a stateful traits is changing the VM > object format. > There is a bits in object's header reserved for identity hash. > Instead of putting the identify hash value there, we could use it to > indicate if given object has additional arbitrary slots following the > object contents: > > <header> > <ivar1> > ... > <ivarN> > <variableVar1> > ... > <variableVarM> > <key1><value1> > <key2><value2> > ... > <keyK><valueK> > > so, these keyN->valueN forming a dictionary of key/value pairs, which > can be accessed using new primitives #slotAt: and #sloatAt:put: > > slot allocaiton can be expressed as: > > newObject := object copyWithSlot: key value: value. > object becomeForward: newObject. > > (except that this is done by VM primitively). > > Once slots is allocated, object size is not grows anymore (so there > are no overhead) and as bonus, you getting a way to attach any > additional state to virtually any objects (except smallints) , for any > purposes. > Identity hash is become slower, but only at first hashing attempt. > (slotAt: #identityHash put: value) > But as benefit, we could use any object (or just 31 bit small integer) > for hash values, which will increase the hashing quality considerably. > So, it is a question, what will be faster, especially for large > dictionaries. > > Obviously, then traits free to use this to keep own state, without any > extra demands from classes where it installed: > > foo > ^ self slotAt: #foo > foo: value > self slotAt: #foo put: value > > Also, I think that with such extension, we might expect a considerable > speed boost for Magma OODB, which can use additional slot for marking > objects by own ids, as well as for marking object dirty, instead of > maintaining a huge and ineffective IdentityDictionaries to track the > objects state. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] Developing morphic apps with pharo - sorting wheat from chaff

by StÃ©phane Ducasse

Yes but somebody has to do it. We are quite open but time is an important factor :) The idea with the architectural changes at the event system was that we should be able to have multiple solutions without having the isMorphic/isMVC tests everywhere in the code. Stef On Feb 27, 2010, at 12:57 AM, Richard Durr wrote: > Maybe the Brazil part of Newspeak is an option? > > On Fri, Feb 26, 2010 at 4:34 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Why can't this stuff be *simple* and *beautiful*? >> >> Marcus >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

[Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.412.mcz]

by Miguel Enrique CobÃ¡ Martinez

This can be useful too. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 27, 2010

[Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by Miguel Enrique CobÃ¡ Martinez

Maybe we can add this to the cleanUpForRelease script. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 27, 2010

Re: [Pharo-project] Scamper revival

by laurent laffont

The goal is to use it for the new HelpSystem, to display images, layout easily, some colors. For browsing the web it's crap. Laurent Laffont 2010/2/27 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > I would much rather see a robust interface to an external browser, for > two reasons: (1) scamper was never terribly impressive; (2) Seaside testing. > > Bill > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *laurent > laffont > *Sent:* Friday, February 26, 2010 4:45 PM > *To:* An open mailing list to discuss any topics related to an open-source > Smalltalk > *Subject:* [Pharo-project] Scamper revival > > Hi, > > It's not stable, but it loads google :) > > Gofer new > squeaksource: 'LaurentLSandbox'; > package:'HTML'; > package:'Scamper'; > load. > Then: > > Scamper openOnUrl: 'http://www.google.com'. > > > I suppose there's a technique to replace all _ by := > > Laurent Laffont > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by Igor Stasenko

On a second thought, i think this is not really necessary. Traits can be reformulated to be purely a method source holders, not holders of compiled methods. (And btw, this is actually true, due to the latest changes in traits, because of super sends issues and #methodClass), we only need to push it a little further and get rid of useless limitations. The point is, that all trait methods should _always_ be compiled in the scope of the class to which it applied. Because, for any variable name, which not declared explicitly in the method's scope, we can't tell anything about it, until we apply this method to the real class (See the Class>>bindingOf: ) This means that, even if you having the trait method: foo ^ Array new: 10 the binding of 'Array' variable may be different, depending on class where its installed. To check it, you can try following at home: Object subclass: #ZZZZ instanceVariableNames: '' classVariableNames: 'DD' poolDictionaries: '' category: 'ZZZZ' "add new pool variable" ZZZZ classPool at: #Array put: 10. "now add the method" array ^ Array and now evaluate the following: ZZZZ new array ------------- But what makes array ^ Array method any better than array ^ array := 10. in this regard? Nothing. So, why not drop the limitation, and instead of punishing developer for use undeclared vars in trait methods, punish him for use of undeclared variables, when he tries to apply the trait to concrete class, where all such var names should obtain meaning? Then, ultimately, what is the point in storing compiling methods in Trait (not for classes, where it applied). We could just check the syntax, but should not produce any CompiledMethod instances at all. What other problems i don't see here? On 27 February 2010 02:10, Stan Shepherd <stan.shepherd414(a)gmail.com> wrote: > > > Igor Stasenko wrote: >> >> One of the ways of introducing a stateful traits is changing the VM >> object format. >> > Sounds like it could be very powerful. > > As it happens, in the fork healing example, it's the very statelessness of > the traits that make it work so simply. By taking out the Â check for > statefulness when the method is moved to a trait, the trait will quite > happily address the several variables in its user classes. This then removes > any need for accessors, helper classes for state, initialization, or other > attempts to tame the beast. > > I wouldn't want to rely on it continuing to work in all conditions, but as a > step in a refactoring it seems very handy. > > ..Stan > -- > View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571553.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 27, 2010