April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Do you want the option to copy a stacktrace to clipboard?

by Mariano Martinez Peck

So...I only let the option from the context menu: http://code.google.com/p/pharo/issues/detail?id=4125 ready to review and integrate On Tue, Apr 26, 2011 at 10:11 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Tue, Apr 26, 2011 at 11:10 PM, Alexandre Bergel < > alexandre.bergel(a)me.com> wrote: > >> I support the idea. However, I am not sure I want this from the >> PreDebugger. >> >> > Yes, exactly. For the context menu I am sure I want it :) > The question is in the pre debugger...and I am not quite sure... > > >> Alexandre >> >> >> >> On 26 Apr 2011, at 15:59, Mariano Martinez Peck wrote: >> >> > Hi guys...with just 2 little methods, I am able to add a button to the >> debuger and a button to the context of the debugger, to copy the stakctrace >> to clipboard. >> > Going to PharoDebug.log is anoying: >> > >> > 1) I never know where my image is, so I first need to do print Smalltlak >> imagePharo >> > 2) then I need to go to such folder, and open the PharoDebug.log >> > 3) most of the times, PharoDebug has appended a lot of other (un) issues >> so it is quite confusing to use such file for a bug report. Hence I need to: >> > 4) remove PharoDebug.log and >> > 5) Reproduce my problem again, so that to generate a new PharoDebug.log >> > 6) finally search it again, open, and do the copy paste :) >> > >> > So....I think it should be muuuch easier from the debugger. So I added >> two possibilities >> > >> > 1) copy to clipboard from the "pre debugger windows" >> > See attached screenshot. >> > >> > 2) copy to clipboard from the debugger context menu. >> > See attached screenshot. >> > >> > So...do you like it? which one do you want of them ? both ? >> > >> > Cheers >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> > <pre debugger .png><debugger context menu.png> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

April 29, 2011

[Pharo-project] DBXTalk (SqueakDBX) goes to Pharo 1.3

by Mariano Martinez Peck

Hi. This is just to let you know that SqueakDBX (soon DBXTalk) has 100% green tests in Pharo 1.3 without chaning one single line of code. In addition, half of the team is using Pharo 1.3 and the other one 1.2. We updated ConfigurationOfSquealDBX >> #stable Cheers -- Mariano http://marianopeck.wordpress.com

April 29, 2011

Re: [Pharo-project] DBXTalk (SqueakDBX) goes to Pharo 1.3

by StÃ©phane Ducasse

+1 > Excellent! Keep going! > > Alexandre > > > On 29 Apr 2011, at 16:41, Mariano Martinez Peck wrote: > >> Hi. This is just to let you know that SqueakDBX (soon DBXTalk) has 100% green tests in Pharo 1.3 without chaning one single line of code. In addition, half of the team is using Pharo 1.3 and the other one 1.2. >> >> We updated ConfigurationOfSquealDBX >> #stable

April 29, 2011

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

by StÃ©phane Ducasse

> But there is in Behavior: > > 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 > > So it calls cleanUp even when you do Smalltlak cleanUp: true. > > Now I wonder if we should remove the displayingProgress and do the call to #cleanUp (the non-agressive one) on image save.... yes this could be a good idea. Stef

April 29, 2011

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