- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [TODO 1.2] TODO list for releasing Pharo Full 1.2

by StÃ©phane Ducasse

+1 For me 1.2 is stable and robust now we should fix the process but in that case let us focus on 1.3 and start 1.3 dev Stef On Mar 24, 2011, at 12:40 AM, Igor Stasenko wrote: > Guys, i think you approach to the problem at wrong angle. > Pick any successful Pharo 1.2 build. Declare it as release. Milestone > passed. Done. > > Nobody cares that something gets wrong after, as result of ongoing > development. That the way it goes.. Something got broken, > something got repaired. > > My impression that you just stumbled over insignificant mercantile detail. > Make it perfect on next release. Lets just move on. > > -- > Best regards, > Igor Stasenko AKA sig. >

March 24, 2011

Re: [Pharo-project] What is the future of GUI in Pharo?

by StÃ©phane Ducasse

Here is the vision: we need it better and simpler with better widgets, better UIBuilder and better tools. if you give me some engineers I can build something clear, now this is not the case so we are exploring and multiple paths Now if you want to see the system moving faster just join and help So here is a list Frameworks ---------- First step - Integrate polymorph (move class to the right packages, remove overrides) - Reduce complexity of morphic when possible In parallel - Clean SimpleMorphic (remove preferences, PopUpChoiceMenu) - Based on SimpleMorphic, clean also Morphic Alain told me that he want to take simpleMorphic and create a kernel that can be run and debugged on the side or morphic. Then he wants to add list and tree and see if he can add a better version of polymorph. Now he can fail too. so this is why the incremental points are important. Fixing and improving announcements is important - It was done during the last sprint - We were discussing how to make anonucement faster to avoid to climbing their parent tree - but no success so far. - We evaluated signals (as used in HPI frameworks) and we do not really like it. The use of thisContext is probably a problem among others. Widgets ------- We need better widgets - accordion - better text - grid We should evaluate your widgets to integrate them. But first we should clean what is there. Stacking on top of bad foundation just make the system more complex and difficult to maintain. Low level: a new Canvas and clean event ----------------------------------- Igor started to design a new canvas called Athens and we will see where it will go Again if people want to see this coming faster, they should help. The idea is to have a canvas for - opengl - cairo - bitbl We are evaluating the event hierarchy designed by Mickael Rueger and we would like to integrate it: eliminate the floating of arrays btween eventfetcher and HandMorph the idea is that event should be emitted by eventSensor not raw array I'm starting to clean Sensor references that are using the polling behavior because we should not have polling anymore the Windows virtual machine should be fixed and get the enhancement that Igor sent more than a year ago for the input semaphore and so that all the vm are aligned. Tools ----- We are rewriting from scratch the basic tools - Browser (Nautilus soon to be announced - with groups, package browsers, refactorings, may be plugin architecture) - Finder - TestRunner (soon) - MCBrowser - Debugger (waiting for a debugger model) The idea is that we want to kill the StringHolder hierarchy alltogther so in a first phase we will probably have to keep it for the debugger but only for it. We will remove toolBuilder (we are waiting to finish the TestRunner rewriting). Glamour will probably be used as a default super IDE of the future but it depends on people We are currently working on the fall back (the tools when you have nothing). So I hope it clarifies the picture and you are welcome to help. Now an important point This is not because something is under preparation that the other should not get clean and improve. We have no problem throwing away our effort if something better come up but we should be prepared that nothing come up or is delayed this is why we have this parallel strategy. Stef > Many new things is happens this days on Pharo, and I donÂ´t understand the > status of all. > > What is the future of GUI in Pharo? what changes will happen? which is the > roadmap? Now I see SimpleMorphic. Pharo will work with it? Pharo will works > with another way of draw/render the morphs? > We will reduce the number of morph classes and hierarchy? The Morphic UI > designer will be incorporated in dev image? > > Thanks for your answers.

March 24, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Norbert Hartl

Am 23.03.2011 um 22:46 schrieb Miguel CobÃ¡: > I agree with the points you note. I think that are reasonable. And as > you say, maybe the rigid scheme of specific versions is not the best > solution. > > There are then a couple options: > > 1. Accept that there is no control on the packages and versions used to > build a Pharo release, and then fix the problems as soon as possible > when they show up in the hudson reports. This acknowledges the fact that > those packages are *important* for Pharo, so a level of care on them > must be put for some time after each release of Pharo. > > 2. When releasing a Pharo version, use the script to copy the > configuration and the packages loaded by them to a know blessed, read > only repository on squeaksource.com. This allows to reliably repeat > builds of any pharo core for auditing or traceability. Of course each > user in its own image can use the configuration pointing to the > upstream/original repositories, so that they can get the new > developments. This only get us a repeteable (but not very useful and > maybe not so necessary for other than auditing) build anytime in the > future. > > Of course this is not a problem of Metacello or any given packaging > system. It is a matter of policies of the project so I think that for > Pharo a policy can be stated and then applied. > IMHO a mixture of the two options before is the best for Pharo. To copy > the packages with Dale's script to a know location as part of the > release process and to keep the builds green for a given number of > release as they appear on the Hudson reports. > > What do you think? Very well put. To me a release is just (as Igor said) any succesful build on hudson. It is just a freeze in development time on which you can base documentation, books like pharo by example etc. A repeatable release build enables you to produce the smallest possible delta if you need to make a minor/patch release. Norbert > > El miÃ©, 23-03-2011 a las 13:05 -0700, Dale Henrichs escribiÃ³: >> Panu, >> >> I agree almost completely most of the project dependencies in configuration _should_ use a literal version ... I still maintain that there are use cases where using symbolic version like #stable is correct. >> >> For example, I have a project called GemTools that depends upon OB being present ... I actually do not care which version of OB is loaded, since I am _not_ tightly coupled to OB ... I just happen to have several windows that are implemented as subclasses of OBBrowser - nothing really fancy, but I want GemTools to be usable in Squeak, Pharo1.0, Pharo1.1 and Pharo1.2, etc., etc. >> >> If I am required to specify a specific version of OB to use, then I must become an expert about which versions of OB to use on which platform of Pharo or Squeak and if a new version of OB is released I have to update _my_ configuration to reflect the newly released version ... oh and I have to do this whenever a new ob is released for any one of the (5 or 6) different platforms that OB runs on ... >> >> If I specify that I want the #stable version of OB, I don't have to worry any more and I don't have to keep track of the ins and outs of OB ... >> >> If GemTools _is_ referencing a #stable version and the hudson server is loading GemTools and the tests break because the #stable version of OB has changed and introduced a bug, I say ... Hurray for hudson, since a bug has been found with the #stable version of OB . >> >> At least the poor developer who loads the #stable version OB won't be the first (or only) person to find the bug... >> >> I have proposed the "configuration signature" because I have noticed that some developers will change existing/released configurations (which could cause problems) and I think that Pharo-1.2 just might be using several versions with a #development blessing (where it is an accepted practice to change the specification for a version) so any change in version of a configuration mcz file is suspect ... >> >> I _have_ been toying with the idea that a Metacello version could include the signature of the mcz file, so that one could specify something like the following: >> >> spec project: 'OmniBrowser' with: '1.2.3:dkh.345'. >> >> or >> >> spec project: 'OmniBrowser' with: #'stable:dkh.345' >> >> If this is done, then the specification is completely locked down ... of course the ':' notion would be optional ... >> >> The problem with locking down the versions of everything is very similar to the problem of static definitions of classes (in java) ... one change to a class definition and there is a cascade of changes that must be made to the rest of the system before you can get the whole thing to compile again.... >> >> There _is_ tension between the desire to be able to guarantee reproducable results and providing enough wiggle room to avoid putting development into version grid lock ... >> >> With all of that said, there is nothing to prevent a validator rule from being written that checks (recursively) for the use of symbolic versions. >> >> But I think the hudson server is actually doing it's job by loading the configurations that a developer would be loading and finding problems that a developer would otherwise find on his or her own ... the fact that the build failed is a good thing and fixing the problem whether it be in a literal version or a symbolic version is the important thing... >> >> This _is_ an interesting discussion and I am sure that more can be said (I know that _I_ have more to say:) and I hope that it continues...my hope is that we find a balance between rigidity and flexibility ... too rigid and progress becomes tedious (too many things have to change) too flexible and everything spins out of control ... >> >> Having lots of good tests and running them regularly is one of the things that allows for more flexibility and keeps things from spinning out of control, so if you are running lots of tests on a complex system that is changing regularly ... expect the tests to fail and make sure that we have the tools that help us identify and resolve the problems as they appear... >> >> Dale >> >> On Mar 23, 2011, at 12:23 PM, Panu Suominen wrote: >> >>> I am quite sure that you already know all of this, but I just have >>> urge to make some noice. :) >>> >>> In Java world Maven handles this situation using term snapshot >>> dependency. Non-snapshot release can/should not contain any snapshot >>> dependencies. Contents of snapshot version is expected to change and >>> non-snapshot releases are supposed to remain static. To me it looks >>> like that these stable & co symbolic versions are quite the same than >>> Mavens snapshot versions. >>> >>> Thus I think it would make sense have a functionality in metacello to >>> "release" a version which would use the exact versions instead of >>> symbolic ones. At least there there should be validation agains these >>> issues. Possibly it should lock the monticello packages used to load >>> the configurations also. >>> IMHO it breaks the whole if so called stable version of project A >>> depends on some other project which uses some symbolic version of some >>> third project. When this third project advances it will eventually >>> break the project A and thus the B in between does not seem so stable >>> anymore. >>> >>> >>> 2011/3/23 Dale Henrichs <dhenrich(a)vmware.com>: >>>> Miguel, >>>> >>>> Two things: >>>> >>>> 1) there are certain conditions where #stable is the correct version to use >>>> 2) I thought the point of running hudson-based tests is to identify these types >>>> of problems as soon as they occur so that they can be fixed earlier. >>>> >>>> With that said, I'd be inclined to create some scripts that recorded the "configuration signature" of an image, something like the following: >>>> >>>> - Nile 1.2 (GuillermoPolito.19) >>>> - OCompletion 1.2.2 (GuillermePolito.39) >>>> - Pharo 1.1.1 (LaurentLaffonte.148) >>>> - .... >>>> >>>> where the parenthesized info is the author and version of the mcz file. So if an error shows up out of the blue, the first thing would be to check for changes in the "configuration signature" and go from there ... >>>> >>>> We're already doing this kind of thing for the MetacelloBrowser, so it would be very easy to whip up a script to build the signature ... I guess each image could keep/generate it's signature.... >>>> >>>> I think the "configuration signature" is very useful ... if the "configuration signature" doesn't change the exact same code should be loaded ... >>>> >>>> Dale >>>> >>>> >>>> On Mar 23, 2011, at 8:40 AM, Miguel CobÃ¡ wrote: >>>> >>>>> Maybe we should ask Dale when time permits to add functionality to >>>>> Metacello so that can check all the dependencies for a given >>>>> configuration and make sure (or raise some warning in the validation) >>>>> that some dependency is refered by a symbolic non numeric version (like >>>>> #stable, #latestVersion, #bleedingEdge) so that this validation can be >>>>> run by hudson also and verify that all the configurations are frozen to >>>>> a given number and no dependent on a symbolic version that can change >>>>> anytime after release of Pharo when a package get a new (#stable for >>>>> example) version. >>>>> >>>>> Cheers >>>>> >>>>> El miÃ©, 23-03-2011 a las 13:26 +0100, Marcus Denker escribiÃ³: >>>>>> On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: >>>>>> >>>>>>> Pharo 1.2 is red again! >>>>>>> >>>>>>> DuplicatedVariableError: stylingActive is already defined in Workspace >>>>>>> >>>>>>> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ >>>>>> >>>>>> >>>>>> We really need to make sure that the config does not load code if we don't explicitly say so. >>>>>> >>>>>> So what code was changed? Why was it loaded? >>>>>> >>>>>> >>>>>> -- >>>>>> Marcus Denker -- http://www.marcusdenker.de >>>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Miguel CobÃ¡ >>>>> http://twitter.com/MiguelCobaMtz >>>>> http://miguel.leugim.com.mx >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Panu >> >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

March 24, 2011

Re: [Pharo-project] [TODO 1.2] TODO list for releasing Pharo Full 1.2

by Norbert Hartl

I think the broken build is good. It shows that the process of building releases is not stable. Not stable in this case means you don't have control over what is going on. Building releases with x.y.z version numbers forces you to have control over it to some extent. I think a main point of having the configurations is not to have to check every individiual version of every package everytime. If you don't have the control and you care about release 1.2.1 is not significantly different than 1.2.2 wouldn't have to check each version of each package every time afterwards- I would agree that this can be considered a "no show stopper" but I would be cautious to make a habit out of it. Norbert Am 24.03.2011 um 00:40 schrieb Igor Stasenko: > Guys, i think you approach to the problem at wrong angle. > Pick any successful Pharo 1.2 build. Declare it as release. Milestone > passed. Done. > > Nobody cares that something gets wrong after, as result of ongoing > development. That the way it goes.. Something got broken, > something got repaired. > > My impression that you just stumbled over insignificant mercantile detail. > Make it perfect on next release. Lets just move on. >

March 24, 2011

[Pharo-project] Issue 3856 in pharo: ActionSequence is unused

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com New issue 3856 by marcus.d...(a)gmail.com: ActionSequence is unused http://code.google.com/p/pharo/issues/detail?id=3856 ActionSequence is not used by the system notifications (or other users of that event system). Deprecate or remove. Attachments: CleanupActionSequence.1.cs 141 bytes

March 24, 2011

[Pharo-project] Issue 3855 in pharo: Clean up Imports

by pharo＠googlecode.com

Status: FixProposed Owner: marcus.d...(a)gmail.com Labels: Milestone-1.3 New issue 3855 by marcus.d...(a)gmail.com: Clean up Imports http://code.google.com/p/pharo/issues/detail?id=3855 "Imports" was a global dictionary for Images, not used anywhere (etoys used it) The attached changeset removed it. Attachments: CleanImports.1.cs 12.2 KB

March 24, 2011

Re: [Pharo-project] TFLogin Recaptcha component error

by Tony Fleig

Hi Dario, This probably means you do not have the latest BowWave-Recaptcha package, which contains the BWRecaptchaComponent class>>#ajax method. 1. Make sure you have the latest reCaptcha version from http://www.squeaksource.com/BowWave.html. (27 Feb 2011) 2. Make sure you have the latest TF-Login from http://www.squeaksource.com/TFLogin.html. (21 Mar 2011) You can see the above code working here: http://www.ensurete.com/LoginTestApp. Let me know if this does not solve the problem at tony.fleig(a)gmail.com. Regards, TF On Wed, Mar 23, 2011 at 9:38 AM, Dario Trussardi <dario.trussardi(a)tiscali.it > wrote: > Hi Tony, > > i hope this is right reference for signal the problem. > > I have load the TFLogin into Pharo1.1.1. > > > After i set the captcha key and register the TLTestApp > > When open in the browser the LoginTestApp > > the system erase the error: > > MessageNotUnderstood: BWRecaptchaComponent class>>ajax > > setRecaptchaComponent > | recaptchaClass | > captchaComponent := > ((recaptchaClass := (Smalltalk at: #BWRecaptchaComponent > ifAbsent: [ nil ])) isNil > ifFalse: [ captchaComponent ifNil: [ recaptchaClass ajax ]] > ifTrue: [ nil ]) > > I answer proced. > > > Now the standard register option work fine and show the captcha > component. > > > When i open the AJAX rendering and do the register option the > captcha component is not render. > > Thank, > > Dario > > > >

March 24, 2011

Re: [Pharo-project] [TODO 1.2] TODO list for releasing Pharo Full 1.2

by Igor Stasenko

Guys, i think you approach to the problem at wrong angle. Pick any successful Pharo 1.2 build. Declare it as release. Milestone passed. Done. Nobody cares that something gets wrong after, as result of ongoing development. That the way it goes.. Something got broken, something got repaired. My impression that you just stumbled over insignificant mercantile detail. Make it perfect on next release. Lets just move on. -- Best regards, Igor Stasenko AKA sig.

March 23, 2011

Re: [Pharo-project] [TODO 1.2] TODO list for releasing Pharo Full 1.2

by Mariano Martinez Peck

On Wed, Mar 23, 2011 at 4:45 PM, Miguel CobÃ¡ <miguel.coba(a)gmail.com> wrote: > El miÃ©, 23-03-2011 a las 14:41 +0100, Marcus Denker escribiÃ³: > > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.2-DevImage > > > > 1. 1.2 Build is broken > > 2. 1.2 Config needs to load latest code from OB Repository > > (or not. Maybe we should just release 1.2.1 and do that in 1.2.2) > > No. This is the reason the build is sometimes green some times red in > hudson. The versions refered by configuration should be frozen to a > given version number forever. That is, #stable, #latestVersion, > #bleedingEdge and so should be banned from Pharo configurations when > building a release. They are ok for end users that just want a version > that works in the image they have in front of them, but not for > releases, that should be repeteable! > > I have already said my opinion here: http://forum.world.st/Pharo-1-2-and-test-failures-tp3337119p3338014.html If you do what you said, you will have people agians because they need to modify ConfigurationOfXXX and ConfigurationOfPharo each time a new MONTICELLO version of a package of XXX is commited. There is no magic. You have to choose: 1) always use the latest, and every time the build may be differnet. But we don't need to update configs all the time 2) use a frozen version, and when there are new commits, modify and commits by hand all the confs Of course, there can be much better solutions, but there is no one offering himself to do it. People do not want to even do 2) so... > > > > maybe these we push to 1.2.2: > > > > 3. Omnibrowser's an extra horizontal scrollbar > > 4. In OB: Text in comment pane of Browser uses syntax highlighting > > > > 5. Update Hudson One-Click build files for 1.2 > > > > > > Marcus > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > >

March 23, 2011

Re: [Pharo-project] Pharo 1.2 red again

by Dale Henrichs

Miguel, Well put ... I think that both options have their place during the whole development cycle ... there are points in time where it is appropriate to "checkpoint the configurations and packages" for reproducible results as well as to distribute the source so that a single server outage doesn't shut everything down ... In the interim it makes sense to use hudson to validate verify the ongoing development... Dale On Mar 23, 2011, at 2:46 PM, Miguel CobÃ¡ wrote: > I agree with the points you note. I think that are reasonable. And as > you say, maybe the rigid scheme of specific versions is not the best > solution. > > There are then a couple options: > > 1. Accept that there is no control on the packages and versions used to > build a Pharo release, and then fix the problems as soon as possible > when they show up in the hudson reports. This acknowledges the fact that > those packages are *important* for Pharo, so a level of care on them > must be put for some time after each release of Pharo. > > 2. When releasing a Pharo version, use the script to copy the > configuration and the packages loaded by them to a know blessed, read > only repository on squeaksource.com. This allows to reliably repeat > builds of any pharo core for auditing or traceability. Of course each > user in its own image can use the configuration pointing to the > upstream/original repositories, so that they can get the new > developments. This only get us a repeteable (but not very useful and > maybe not so necessary for other than auditing) build anytime in the > future. > > Of course this is not a problem of Metacello or any given packaging > system. It is a matter of policies of the project so I think that for > Pharo a policy can be stated and then applied. > IMHO a mixture of the two options before is the best for Pharo. To copy > the packages with Dale's script to a know location as part of the > release process and to keep the builds green for a given number of > release as they appear on the Hudson reports. > > What do you think? > > El miÃ©, 23-03-2011 a las 13:05 -0700, Dale Henrichs escribiÃ³: >> Panu, >> >> I agree almost completely most of the project dependencies in configuration _should_ use a literal version ... I still maintain that there are use cases where using symbolic version like #stable is correct. >> >> For example, I have a project called GemTools that depends upon OB being present ... I actually do not care which version of OB is loaded, since I am _not_ tightly coupled to OB ... I just happen to have several windows that are implemented as subclasses of OBBrowser - nothing really fancy, but I want GemTools to be usable in Squeak, Pharo1.0, Pharo1.1 and Pharo1.2, etc., etc. >> >> If I am required to specify a specific version of OB to use, then I must become an expert about which versions of OB to use on which platform of Pharo or Squeak and if a new version of OB is released I have to update _my_ configuration to reflect the newly released version ... oh and I have to do this whenever a new ob is released for any one of the (5 or 6) different platforms that OB runs on ... >> >> If I specify that I want the #stable version of OB, I don't have to worry any more and I don't have to keep track of the ins and outs of OB ... >> >> If GemTools _is_ referencing a #stable version and the hudson server is loading GemTools and the tests break because the #stable version of OB has changed and introduced a bug, I say ... Hurray for hudson, since a bug has been found with the #stable version of OB . >> >> At least the poor developer who loads the #stable version OB won't be the first (or only) person to find the bug... >> >> I have proposed the "configuration signature" because I have noticed that some developers will change existing/released configurations (which could cause problems) and I think that Pharo-1.2 just might be using several versions with a #development blessing (where it is an accepted practice to change the specification for a version) so any change in version of a configuration mcz file is suspect ... >> >> I _have_ been toying with the idea that a Metacello version could include the signature of the mcz file, so that one could specify something like the following: >> >> spec project: 'OmniBrowser' with: '1.2.3:dkh.345'. >> >> or >> >> spec project: 'OmniBrowser' with: #'stable:dkh.345' >> >> If this is done, then the specification is completely locked down ... of course the ':' notion would be optional ... >> >> The problem with locking down the versions of everything is very similar to the problem of static definitions of classes (in java) ... one change to a class definition and there is a cascade of changes that must be made to the rest of the system before you can get the whole thing to compile again.... >> >> There _is_ tension between the desire to be able to guarantee reproducable results and providing enough wiggle room to avoid putting development into version grid lock ... >> >> With all of that said, there is nothing to prevent a validator rule from being written that checks (recursively) for the use of symbolic versions. >> >> But I think the hudson server is actually doing it's job by loading the configurations that a developer would be loading and finding problems that a developer would otherwise find on his or her own ... the fact that the build failed is a good thing and fixing the problem whether it be in a literal version or a symbolic version is the important thing... >> >> This _is_ an interesting discussion and I am sure that more can be said (I know that _I_ have more to say:) and I hope that it continues...my hope is that we find a balance between rigidity and flexibility ... too rigid and progress becomes tedious (too many things have to change) too flexible and everything spins out of control ... >> >> Having lots of good tests and running them regularly is one of the things that allows for more flexibility and keeps things from spinning out of control, so if you are running lots of tests on a complex system that is changing regularly ... expect the tests to fail and make sure that we have the tools that help us identify and resolve the problems as they appear... >> >> Dale >> >> On Mar 23, 2011, at 12:23 PM, Panu Suominen wrote: >> >>> I am quite sure that you already know all of this, but I just have >>> urge to make some noice. :) >>> >>> In Java world Maven handles this situation using term snapshot >>> dependency. Non-snapshot release can/should not contain any snapshot >>> dependencies. Contents of snapshot version is expected to change and >>> non-snapshot releases are supposed to remain static. To me it looks >>> like that these stable & co symbolic versions are quite the same than >>> Mavens snapshot versions. >>> >>> Thus I think it would make sense have a functionality in metacello to >>> "release" a version which would use the exact versions instead of >>> symbolic ones. At least there there should be validation agains these >>> issues. Possibly it should lock the monticello packages used to load >>> the configurations also. >>> IMHO it breaks the whole if so called stable version of project A >>> depends on some other project which uses some symbolic version of some >>> third project. When this third project advances it will eventually >>> break the project A and thus the B in between does not seem so stable >>> anymore. >>> >>> >>> 2011/3/23 Dale Henrichs <dhenrich(a)vmware.com>: >>>> Miguel, >>>> >>>> Two things: >>>> >>>> 1) there are certain conditions where #stable is the correct version to use >>>> 2) I thought the point of running hudson-based tests is to identify these types >>>> of problems as soon as they occur so that they can be fixed earlier. >>>> >>>> With that said, I'd be inclined to create some scripts that recorded the "configuration signature" of an image, something like the following: >>>> >>>> - Nile 1.2 (GuillermoPolito.19) >>>> - OCompletion 1.2.2 (GuillermePolito.39) >>>> - Pharo 1.1.1 (LaurentLaffonte.148) >>>> - .... >>>> >>>> where the parenthesized info is the author and version of the mcz file. So if an error shows up out of the blue, the first thing would be to check for changes in the "configuration signature" and go from there ... >>>> >>>> We're already doing this kind of thing for the MetacelloBrowser, so it would be very easy to whip up a script to build the signature ... I guess each image could keep/generate it's signature.... >>>> >>>> I think the "configuration signature" is very useful ... if the "configuration signature" doesn't change the exact same code should be loaded ... >>>> >>>> Dale >>>> >>>> >>>> On Mar 23, 2011, at 8:40 AM, Miguel CobÃ¡ wrote: >>>> >>>>> Maybe we should ask Dale when time permits to add functionality to >>>>> Metacello so that can check all the dependencies for a given >>>>> configuration and make sure (or raise some warning in the validation) >>>>> that some dependency is refered by a symbolic non numeric version (like >>>>> #stable, #latestVersion, #bleedingEdge) so that this validation can be >>>>> run by hudson also and verify that all the configurations are frozen to >>>>> a given number and no dependent on a symbolic version that can change >>>>> anytime after release of Pharo when a package get a new (#stable for >>>>> example) version. >>>>> >>>>> Cheers >>>>> >>>>> El miÃ©, 23-03-2011 a las 13:26 +0100, Marcus Denker escribiÃ³: >>>>>> On Mar 23, 2011, at 12:52 PM, Torsten Bergmann wrote: >>>>>> >>>>>>> Pharo 1.2 is red again! >>>>>>> >>>>>>> DuplicatedVariableError: stylingActive is already defined in Workspace >>>>>>> >>>>>>> https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.2/195/ >>>>>> >>>>>> >>>>>> We really need to make sure that the config does not load code if we don't explicitly say so. >>>>>> >>>>>> So what code was changed? Why was it loaded? >>>>>> >>>>>> >>>>>> -- >>>>>> Marcus Denker -- http://www.marcusdenker.de >>>>>> INRIA Lille -- Nord Europe. Team RMoD. >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Miguel CobÃ¡ >>>>> http://twitter.com/MiguelCobaMtz >>>>> http://miguel.leugim.com.mx >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> >>> -- >>> Panu >> >> > > -- > Miguel CobÃ¡ > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > >

March 23, 2011