- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable

by Dale Henrichs

On 04/29/2011 10:10 AM, StÃ©phane Ducasse wrote: > dale > >>> My rule of thumb for a literal version spec is that you should >>> use the #stable symbolic version if the project is loosely >>> coupled to your project and a specific version otherwise. >>> OmniBrowser tends to be loosely coupled as you are interested in >>> getting any old version of OmniBrowser as long as it functions on >>> the platform. >> >> The rule of thumb for a baseline version spec is to use #stable for >> all projects (as long as the #stable version is defined), even >> "tightly coupled" projects. When the baseline version is loaded, >> you normally don't want to load the "latest code" or all of the >> projects that you depend upon. >> >> The #bleedingEdge symbolic version should be used only when the >> referenced project is part of your project family. >> >> When I load the baseline version for Seaside30, > > when you say that "load the baseline": do you mean that you will get > all the latest versions of the seaside packages? Yes, I load the baseline version of Seaside30, to pick up the most recent checkins by the Seaside developers, so I can update the configuration, port the changes, to GemStone and make a release. And when I do that, I don't want the latest OmniBrowser packages:) > > >> I want to load the #bleedingEdge versions of Grease, Kom, and >> Swazoo, because they are part of the project family. I absolutely >> don't want to load the latest OmniBrowser code, because who knows >> what you'd get... >> >> So for the ConfigurationOfPharo, if you followed my rule of thumb, >> you would create a baseline version and use the #stable version for >> all of the projects in the baseline. In the literal version you >> would use the explicit version, so that you'd have an explicit >> repeatable specification for a set of projects that were known to >> work together. > > ok you mean that if people want the latest they load the baseline > else they can just use a literal version and access it via #stable I'm not sure what you mean here.... The pharo 1.2.2-baseline would include specs that look like this: spec project: 'OB Dev' with: [ spec className: 'ConfigurationOfOmniBrowser'; versionString: #stable; ...]; project: 'ScriptManager' with: [ spec className: 'ConfigurationOfScriptManager'; versionString: #stable; ...]; project: 'Shout' with: [ spec className: 'ConfigurationOfShout'; versionString: #stable; ...]; ....]. Loading Pharo 1.2.2-baseline would cause the #stable version for each of those projects to be loaded ... but remember over time the #stable version will change and incompatibilities between packages can creep in. By using #stable versions you will be in better shape than using #bleedingEdge because the #stable version is known to work. Pharo 1.2.2 (literal version) will have corresponding specs that look like this: spec project: 'OB Dev' with: '1.2.4'; project: 'ScriptManager' with: '1.2'; project: 'Shout' with: '1.2.2'; ....]. So that you have driven a stake into the ground stating that these versions are known to work together (have passed tests as a unit). 5 years in the future, you will be able ot load Pharo 1.2.2 and get exactly the same packages every time ... whereas the #stable versions may have drifted over time ... If I am just bringing up a PharoCore1.2 image and I'd like to load the Pharo dev code, I should load the #stable version of Pharo (which may be 1.2.2 today and 1.2.3 tomorrow). If I want to duplicate the environment that someone is working in I will ask them for th version of Pharo and load that explicit version to reproduce the bug or whatever ... Dale

April 29, 2011

Re: [Pharo-project] UndefinedObject(Object)>>doesNotUnderstand: #findNextHandlerContextStarting

by Marcus Denker

On Apr 29, 2011, at 8:18 PM, Mariano Martinez Peck wrote: > > > On Wed, Apr 27, 2011 at 8:31 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Apr 24, 2011, at 5:12 PM, Mariano Martinez Peck wrote: > > > grrrr I don't know what is happening. I am building a PharoDev 1.3 and at the end, I do: Undeclared removeUnreferencedKeys > > but this throws an error that I attach. It is a big loop of such error. > > The progress bar is showing "Clean up in DebuggerMethodMap" > > > > So I added the DebuggerMethodMap intialize (reset the cache) to Smalltalk cleanUp. > > > Thanks Marcus. I don't see this commit. Did you commit it? or we lost it with the squeaksource down ? > This was part of the cleanUp improvements... some time ago. see DebuggerMethodMap>>#cleanUp Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

April 29, 2011

Re: [Pharo-project] UndefinedObject(Object)>>doesNotUnderstand: #findNextHandlerContextStarting

by Mariano Martinez Peck

On Wed, Apr 27, 2011 at 8:31 PM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Apr 24, 2011, at 5:12 PM, Mariano Martinez Peck wrote: > > > grrrr I don't know what is happening. I am building a PharoDev 1.3 and at > the end, I do: Undeclared removeUnreferencedKeys > > but this throws an error that I attach. It is a big loop of such error. > > The progress bar is showing "Clean up in DebuggerMethodMap" > > > > So I added the DebuggerMethodMap intialize (reset the cache) to Smalltalk > cleanUp. > > Thanks Marcus. I don't see this commit. Did you commit it? or we lost it with the squeaksource down ? cheers mariano > But why is that called when calling "Undeclared removeUnreferencedKeys"? > > > > > In addition Undeclared ->>>> a Dictionary(#NoSuchElementError->nil ) > > I checked http://code.google.com/p/pharo/issues/detail?id=4043 but > there is no such method. > > NoSuchElementError looks like an exception subclass to me. Is it references > somewhere? > > > Now...if I execute Undeclared removeUnreferencedKeys again, it works. > > > > The bad news is that this prevents the PharoDev 1.3 to be build.... > > > > I have no clue of what can be happening, but the only way I found so far > to reproduce it is to: > > > > Gofer new > > squeaksource: 'PharoTaskForces'; > > pacakge: 'ConfigurationOfPharo'; > > load. > > > > And then: > > > > (ConfigurationOfPharo project version: '1.3-beta') load > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Mariano http://marianopeck.wordpress.com

April 29, 2011

Re: [Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable

by StÃ©phane Ducasse

>>> >> >> when you say that "load the baseline": do you mean that you will get >> all the latest versions of the seaside packages? > > Yes, I load the baseline version of Seaside30, to pick up the most > recent checkins by the Seaside developers, so I can update the > configuration, port the changes, to GemStone and make a release. > > And when I do that, I don't want the latest OmniBrowser packages:) >> >> >>> I want to load the #bleedingEdge versions of Grease, Kom, and >>> Swazoo, because they are part of the project family. I absolutely >>> don't want to load the latest OmniBrowser code, because who knows >>> what you'd get... >>> >>> So for the ConfigurationOfPharo, if you followed my rule of thumb, >>> you would create a baseline version and use the #stable version for >>> all of the projects in the baseline. In the literal version you >>> would use the explicit version, so that you'd have an explicit >>> repeatable specification for a set of projects that were known to >>> work together. >> >> ok you mean that if people want the latest they load the baseline >> else they can just use a literal version and access it via #stable > > > I'm not sure what you mean here.... > > The pharo 1.2.2-baseline would include specs that look like this: > > spec > project: 'OB Dev' with: [ > spec > className: 'ConfigurationOfOmniBrowser'; > versionString: #stable; > ...]; > project: 'ScriptManager' with: [ > spec > className: 'ConfigurationOfScriptManager'; > versionString: #stable; > ...]; > project: 'Shout' with: [ > spec > className: 'ConfigurationOfShout'; > versionString: #stable; > ...]; > ....]. > > Loading Pharo 1.2.2-baseline would cause the #stable version for each of those projects to be loaded ... but remember over time the #stable version will change and incompatibilities between packages can creep in. By using #stable versions you will be in better shape than using #bleedingEdge because the #stable version is known to work. > > Pharo 1.2.2 (literal version) will have corresponding specs that look like this: > > spec > project: 'OB Dev' with: '1.2.4'; > project: 'ScriptManager' with: '1.2'; > project: 'Shout' with: '1.2.2'; > ....]. > > So that you have driven a stake into the ground stating that these versions are known to work together (have passed tests as a unit). 5 years in the future, you will be able ot load Pharo 1.2.2 and get exactly the same packages every time ... whereas the #stable versions may have drifted over time ... Excellent point. I should add that to the book chapter! > If I am just bringing up a PharoCore1.2 image and I'd like to load the Pharo dev code, I should load the #stable version of Pharo (which may be 1.2.2 today and 1.2.3 tomorrow). > > If I want to duplicate the environment that someone is working in I will ask them for th version of Pharo and load that explicit version to reproduce the bug or whatever ... > > Dale

April 29, 2011

Re: [Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable

by Dale Henrichs

On 04/29/2011 01:07 AM, Mariano Martinez Peck wrote: > Hi Dale. For Pharo 1.3 I want to (try) to use all #stable, i.e, I want > that ConfigurationOfPharo doesn't explicitly load a specific version of > every project but instead, the #stable. > First step I need to do (I will try to do it during the weekend) is to > update #stable in each of the ConfigurationOf used by > ConfuigurationOfPharo. That's an easy part. > > Now, my question is...I don't really understand how the confs would look > like after. I mean, 99% of the cases (in fact, at the beginning it will > be 100% until I find a problem), the version I use will be #stable. > So,the version of ConfgiruationOfPharo AND all the Configurations used > by ConfgiruationOfPharo would look something like this: > > spec > project: 'Autotest' with: #stable; > project: 'Autotest Help Tests' with: #stable; > project: 'MemoryMonitor' with: #stable; > project: 'XMLSupport' with: #stable; > > I mean...every single project reference will have #stable instead of a > specific version. So...is this expected? is this the way I should do it ? > > Finally...is there a query I can do to Metacello saying "which are the > ConfigurationsOf needed for this version for this group of this Conf" ? > > Thanks > > -- > Mariano > http://marianopeck.wordpress.com > Mariano, My rule of thumb for a literal version spec is that you should use the #stable symbolic version if the project is loosely coupled to your project and a specific version otherwise. OmniBrowser tends to be loosely coupled as you are interested in getting any old version of OmniBrowser as long as it functions on the platform. The rule of thumb for a baseline version spec is to use #stable for all projects (as long as the #stable version is defined), even "tightly coupled" projects. When the baseline version is loaded, you normally don't want to load the "latest code" or all of the projects that you depend upon. The #bleedingEdge symbolic version should be used only when the referenced project is part of your project family. When I load the baseline version for Seaside30, I want to load the #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get... So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together. Developers interested in getting the "latest released version for all projects" in ConfigurationOfPharo would load the baseline version and then get the #stable version of all the projects for their platform ... each of the projects was know to work by itself in an image (that's what the #stable designation means), but the unknown is whether all of the projects work together in image ... When you know that, you create a literal version of ConfigurationOfPharo to commemorate that set of versions.... Without looking at the list of projects, it might still make sense to use #stable in the literal version, but it would be the exception to the rule ... Does this make sense to you? Dale

April 29, 2011

Re: [Pharo-project] [Metacello] Best strategy for ConfigurationOfPharo using #stable

by StÃ©phane Ducasse

dale >> My rule of thumb for a literal version spec is that you should use the #stable symbolic version if the project is loosely coupled to your project and a specific version otherwise. OmniBrowser tends to be loosely coupled as you are interested in getting any old version of OmniBrowser as long as it functions on the platform. > > The rule of thumb for a baseline version spec is to use #stable for all projects (as long as the #stable version is defined), even "tightly coupled" projects. When the baseline version is loaded, you normally don't want to load the "latest code" or all of the projects that you depend upon. > > The #bleedingEdge symbolic version should be used only when the referenced project is part of your project family. > > When I load the baseline version for Seaside30, when you say that "load the baseline": do you mean that you will get all the latest versions of the seaside packages? > I want to load the #bleedingEdge versions of Grease, Kom, and Swazoo, because they are part of the project family. I absolutely don't want to load the latest OmniBrowser code, because who knows what you'd get... > > So for the ConfigurationOfPharo, if you followed my rule of thumb, you would create a baseline version and use the #stable version for all of the projects in the baseline. In the literal version you would use the explicit version, so that you'd have an explicit repeatable specification for a set of projects that were known to work together. ok you mean that if people want the latest they load the baseline else they can just use a literal version and access it via #stable ? > > Developers interested in getting the "latest released version for all projects" in ConfigurationOfPharo would load the baseline version and then get the #stable version of all the projects for their platform ... each of the projects was know to work by itself in an image (that's what the #stable designation means), but the unknown is whether all of the projects work together in image ... When you know that, you create a literal version of ConfigurationOfPharo to commemorate that set of versions.... > > Without looking at the list of projects, it might still make sense to use #stable in the literal version, but it would be the exception to the rule ... > > Does this make sense to you? > > Dale > >

April 29, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Eliot Miranda

On Fri, Apr 29, 2011 at 9:04 AM, Philippe Marschall <kustos(a)gmx.net> wrote: > On 27.04.2011 19:23, Eliot Miranda wrote: > > Philippe, > > > > can you please profile before and after? This could very well be to > > do with the additional cost of shallowCopy for contexts, but it is > > inevitable that a correct implementation is going to be more expensive > > than the simple block-copy. The new implementation can be optimized, > > but we need to profile first to be sure we're tilting at the relevant > > windmill. > > > What kind of profiling do you have in mind, MessageTally? > Yes, that would be fine. Thanks! best, Eliot > > Cheers > Philippe > > >

April 29, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Philippe Marschall

On 27.04.2011 19:23, Eliot Miranda wrote: > Philippe, > > can you please profile before and after? This could very well be to > do with the additional cost of shallowCopy for contexts, but it is > inevitable that a correct implementation is going to be more expensive > than the simple block-copy. The new implementation can be optimized, > but we need to profile first to be sure we're tilting at the relevant > windmill. What kind of profiling do you have in mind, MessageTally? Cheers Philippe

April 29, 2011

Re: [Pharo-project] new Cog VMs uploaded

by Philippe Marschall

On 27.04.2011 19:24, Eliot Miranda wrote: > > > > > can you post a stack trace from gdb? Also, what linux system and what > image are you using? r2382 fixed it Cheers Philippe

April 29, 2011

Re: [Pharo-project] Counting Messages as a Proxy for Average Execution Time in Pharo

by Igor Stasenko

On 29 April 2011 01:03, Stefan Marr <pharo(a)stefan-marr.de> wrote: > > On 29 Apr 2011, at 00:32, Nicolas Cellier wrote: > >> >> However, as I understand it, it's entirely up to user to write code >> exploiting parallel Process explicitly right ? > Sure, you have to do: n times: [ [ 1 expensiveComputation. ] fork ]. > > I don't belief in holy grails or silver bullets. > Automatic parallelization is something nice for the kids, like Santa Clause or the Easter Bunny... > Indeed :) People tend to forget that parallel algorithms are different by nature, and there is no way to automatically convert arbitrary single-threaded algorithm to parallel one, without thinking about rearranging data structures and control flow. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: Â +32 2 629 3525 > > > -- Best regards, Igor Stasenko AKA sig.

April 29, 2011