- Pharo-dev - lists.pharo.org

Re: [Pharo-project] RBSpelling errors when class has Pool Dictionary - Re: [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Lukas Renggli

>> Otherwise refactoring etc all seem good. I get the same test results as >> other Linux testers. > > Lukas, do you know if this a bug ? I removed the rule for the pool imports a while ago, they are already checked more appropriately at the place they are defined. Btw, I integrated the tests of Stan into the package: Refactoring-Tests-Spelling. Also I had to rename the tests packages of the rest of the refactoring browser to avoid conflicts. The packages are now called: AST-Tests-Core and Refactoring-Tests-Core. Can you update the Metacello definitions? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 24, 2010

Re: [Pharo-project] RBSpelling errors when class has Pool Dictionary - Re: [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2

by Mariano Martinez Peck

On Sat, Jan 23, 2010 at 4:47 PM, Stan Shepherd <stan.shepherd414(a)gmail.com>wrote: > > Hi Mariano, great job of the release. > > Thanks! > I've hit this one bug- pool dictionary spelling is checking a collection > where it expects a string. > > Here's an alternative. > > RBPoolDictionaryNamesSpellingRule>>checkClass: aContext > (aContext selectedClass isTrait or: [ aContext selectedClass isMeta > ]) > ifTrue: [ ^ self ]. > aContext selectedClass poolDictionaryNames do: > [:poolName | > > (self check: poolName) do: [ :each | > result > addSearchString: each; > addClass: aContext selectedClass ]] > > Otherwise refactoring etc all seem good. I get the same test results as > other Linux testers. > > Lukas, do you know if this a bug ? > ...Stan > > > -- > View this message in context: > http://n2.nabble.com/BetaTesting-ANN-Pharo1-0-10507-rc2dev10-01-2-tp4440307… > 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 >

Jan. 24, 2010

Re: [Pharo-project] Monticello diff between chosen revisions is broken

by Mariano Martinez Peck

On Sun, Jan 24, 2010 at 2:09 PM, Lukas Renggli <renggli(a)gmail.com> wrote: > > Yes, I could reproduce the problem. Can you open a ticket ? > > > > Maybe Lukas Monticello guru can help us ? hahaha > > I cannot reproduce the problem, I use that functionality all the time. > Looks like it's a bug in the Diff viewer of Polymorph. > Hahahahahahahahhahahahahahahhaha. > > hhahaha I have ever use that functionallity before, but just because I was not aware...I used to download another version, and then show the changes. So..today I discovered the diff :) Ok...I cc gary then.... :) > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 24, 2010

Re: [Pharo-project] Monticello diff between chosen revisions is broken

by Lukas Renggli

> Yes, I could reproduce the problem. Can you open a ticket ? > > Maybe Lukas Monticello guru can help us ? hahaha I cannot reproduce the problem, I use that functionality all the time. Looks like it's a bug in the Diff viewer of Polymorph. Hahahahahahahahhahahahahahahhaha. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 24, 2010

Re: [Pharo-project] Monticello diff between chosen revisions is broken

by Mariano Martinez Peck

On Sat, Jan 23, 2010 at 9:51 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > In the current dev image (10508), Monticello is broken with respect to > showing the differences of between chosen revisions. > > However, that seems to be broken already in 10496. (and maybe earlier) > > To reproduce: > > 1. Open Monticello Browser > 2. Select a repo > 3. click open > 4. Select a revision, not the latest one > 5. Click diff > 6. chose an ancestor from the list > Now you got a window 'Version: ...5' > Saying (Diff against ...2) > Here I would expect the changes button to open a window showing the changes > between the chosen revisions, but it always diffs against the latest > version. > > Yes, I could reproduce the problem. Can you open a ticket ? Maybe Lukas Monticello guru can help us ? hahaha Cheers Mariano > > Best > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr <http://soft.vub.ac.be/%7Esmarr> > Phone: +32 2 629 3956 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Jan. 24, 2010

Re: [Pharo-project] [Pharo-users] Is there a tool to get the diff of two different classes?

by Mariano Martinez Peck

On Sat, Jan 23, 2010 at 7:52 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > I already found the DiffMorph which looks like it takes just two strings. > So, I wondered whether there might already be something where I can just > input the classnames and get a nice view of all differences? > I really don't know, but I would love to have that too. Many times I had the same problem. > > Thanks > Stefan > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr <http://soft.vub.ac.be/%7Esmarr> > Phone: +32 2 629 3956 > Fax: +32 2 629 3525 > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >

Jan. 24, 2010

Re: [Pharo-project] Deadlock detection for testcases

by Adrian Kuhn

StÃ©phane Ducasse <stephane.ducasse@...> writes: > we should evaluate what adrian did and integrate it! In February I am back from deadline hunting and ready to help with the integration. Deadline-driven research is so ... gosh, cant we just abandon it? BTW, Lance Fortnow on why the conference model in CS is no longer sustainable, http://bit.ly/P3jfv --AA -- SUITE 2010, 2nd Workshop on search in software engineering. Extended deadline to next Friday, January 29, http://bit.ly/suite2010

Jan. 24, 2010

Re: [Pharo-project] Pharo dev image rc2 thoughts

by Mariano Martinez Peck

ok...in English: the package ImageForDevelopers is not a normal package of software. It is just to build a particular image. At the beginning Damien use this for both, Squeak and Pharo. Each project is ever time far away from the other, and thus, having the same package for that, doesn't make sense. I do care that SqueakDBX for example works in Pharo and Squeak, but for this particular package I want to clean all what it Squeak related. Squeak people would probably do the same. Even more, I don't know when was the last time Squeak has a development image using this package....and I don't even know if they will use it again. Cheers Mariano On Sun, Jan 24, 2010 at 12:20 PM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > Also, the image for developers has stuff for squeak. This refactoring >> would permit to separate them in preload/postload for each platform, in >> a cleaner way. >> >> > PerdÃ³n....pero me importa muy poco lo que pase con Squeak. Ya limpiÃ© todo > lo relacionado con Squeak de los shell scripts para crear las imÃ¡genes y > pienso hacer lo mismo con ImageForDevelopers...todo lo que sea de Squeak, > directamente lo borro. Quiero que estÃ© todo limpio. > > > >> As I said at beginning, this is only thoughts, and the current result >> image is the same as the one produced by the previous configuration, but >> maybe, with more time and less pressure, this refactoring and cleaning >> could be made. >> >> Of course, I will try to do this and contribute the code as my time >> permits, but if someone can do it sooner, the better for all of us. >> >> Thanks again for the hard work >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Jan. 24, 2010

Re: [Pharo-project] Pharo dev image rc2 thoughts

by Mariano Martinez Peck

> Also, the image for developers has stuff for squeak. This refactoring > would permit to separate them in preload/postload for each platform, in > a cleaner way. > > PerdÃ³n....pero me importa muy poco lo que pase con Squeak. Ya limpiÃ© todo lo relacionado con Squeak de los shell scripts para crear las imÃ¡genes y pienso hacer lo mismo con ImageForDevelopers...todo lo que sea de Squeak, directamente lo borro. Quiero que estÃ© todo limpio. > As I said at beginning, this is only thoughts, and the current result > image is the same as the one produced by the previous configuration, but > maybe, with more time and less pressure, this refactoring and cleaning > could be made. > > Of course, I will try to do this and contribute the code as my time > permits, but if someone can do it sooner, the better for all of us. > > Thanks again for the hard work > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 24, 2010

Re: [Pharo-project] Pharo dev image rc2 thoughts

by Mariano Martinez Peck

2010/1/24 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > First that anything, thanks to Mariano for all the effort put in order > to release a 1.0 version of Pharo. And to all the contributors also. > You are welcome :) Thanks for taking the time to look at the confs and to write this mail. > > As part of incorporating Metacello to my projects, I have gain a little > more insight in the working of it. For that I have been studying the > existing configurations. I even contributed a pair to the repository. > Tonight I was building a Pharo image using the ConfigurationOfPharo. > > yes, I noticed that :) > The announce said nothing but the inner workings of the dev image > creations changed, although the result is exactly (with a lot of fixes > included) the same that the rc1 image created with Metacello. The > changes are this: > > - in rc1, it was only necessary ConfigurationOfPharo to build a complete > Pharo dev image. That is ConfigurationOfPharo included > ImageForDevelopers. > > yes > - in rc2, ConfigurationOfPharo isn't enough to build a dev image (I > noticed this tonight because I used ConfigurationOfPharo alone to build > an image but in the end I didn't get autocompetition), it is also > necessary to run a second script to load ImageForDevelopers and install > it. This is all done in the installScript.st script included in the > pharo rc2 dev image. > > As I said before, the results are the same, but before all was done in > the ConfigurationOfPharo and now requires two steps. > exactly > > Now to the point. I understand that the separation of concerns is good, > because ImageForDevelopers is already a separated and tested package > that shouldn't be inside ConfigurationOfPharo. > I will tell you a bit the background: First, when I took the installScript from Damien, there where some stuff done in the script (like settings the preferences and the fonts) done in the installScript. It didn't have sense for me (of course I asked Damien) and I put that in ImageForDevelopers (and this is cool because it is versiones with monticello). Actually in DEVImageCreator >> install. I need also to clean that class as it has a lot of old stuff. But not time for the moment. When I create rc1, ImageForDevelopers was a dependency of ConfigurationOfPharo as you said. There was a problem installing it with the progress bar and Metacello. The image just frezze because of a sempahore and a delay....see issue: http://code.google.com/p/metacello/issues/detail?id=39 But I can even reproduce the problem....So, that quick solution (as I needed to relase the Pharo image) was to put in the installScript. And after a while I discovered that I even like more that approach. Someone may want just the packages of a dev image, but not to set preferences, fonts, cleanups, etc. And I don't have the Metacello bug. The problem I found also putting it as a dependency is that it has to be the LATEST (I think that you cannot even said that XX package has to be the last one to be loaded) package to be loaded. I can put it as postDoIt for the project, but this cannot be done because it is ONLY required for certain groups > - Shouldn't be necessary to create a ConfigurationOfImageForDevelopers > and in this configuration reference ConfigurationOfPharo and then the > installScript for the dev image use *only* > ConfigurationOfImageForDevelopers? > > It can work, but actually for me we are having a problem (maybe we need the support the post/pre doit for groupos...but dale said it was complicated). I would like to just do (ConfigurationOfPharo project version: 'XXX') load:'ImageForDeveloper' - It appears that Dale will announce project preload/postload doIts next > This was already done if I remember..... > monday. If that happens, shouldn't be better to incorporate the code > from DEVImageCreator as preload/postload do its to the > ConfigurationOfPharo? > > no, because of the problem I told you that NOT all the groups want that. > It appears to me that DEVImageCreator is a mixture of different things, > both preference tuning (setDefaultPreferences, setFonts) image fixing > (addPreferenceCategories, cleanOpenMenu) and image building stuff > (writeListOfPackages, showWelcomeWorkspaces). > > yes...and some obsolete code. > Maybe the image fixing stuff should be a change incorporated to the > PharoCore image, and the preference tuning should be a postload do it > for the ConfigurationOfImageForDevelopers, and the image building stuff > should be in the install script. > > This way, if someone wants to build a image for developers (but without > the list of packages, or welcome workspaces) it only has to use > ConfigurationOfImageForDevelopers. > > Yes, I like the idea. But I am not sure if for 1.0. I would do that for 1.1 images. At the end of this converstation, we should open a ticket. > Also, maybe after all this refactoring, the > ConfigurationOfImageForDevelopers isn't necessary because all can be > incorporated to the ConfigurationOfPharo as preload/postload do its. > That is fine. > > Yes!!! I don't want a ConfigurationOfImageForDevelop. That means we are lacking something. > > Also, the image for developers has stuff for squeak. This refactoring > would permit to separate them in preload/postload for each platform, in > a cleaner way. > > As I said at beginning, this is only thoughts, and the current result > image is the same as the one produced by the previous configuration, but > maybe, with more time and less pressure, this refactoring and cleaning > could be made. > > Of course, I will try to do this and contribute the code as my time > permits, but if someone can do it sooner, the better for all of us. > > Thanks again for the hard work > Thanks for the notes...cheers Mariano > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 24, 2010