- Pharo-dev - lists.pharo.org

Re: [Pharo-project] How to contribute [WAS] lukas-renggli.ch down, mirrors exists ?
by laurent laffont Dec. 3, 2009

Dec. 3, 2009

> > > > >> About the bugs (Slime-lr.24,current pharo rc1 web image), when I > select refactor > code critics: > > >> > > >> - it seems that ParserTreeSearcher has been renamed to > RBParserTreeSearcher. Thus there's several errors like > WAChangesStateWhileRenderingRule>>initialize (ParseTreeSearcher is > Undeclared) > Hi. As I've fixed above problems, I have a good opportunity to publish my first contribution to Pharo (heart beating ;). I've followed http://code.google.com/p/pharo/wiki/HowToContribute. Saving my Slime package create Slime-LaurentLaffont.25 package. Then I load it in a fresh image, it works. So I open Monticello, select Slime-LaurentLaffont.25, add PharoInBox repository, click Save. The "Edit Version Name and Log Message" dialog opens but the name of package is now Slime-LaurentLaffont.26, whithout my log message of version 25. How to publish version 25 and not create a version 26 ? Laurent Laffont

3 7

[Pharo-project] Fwd: [Moose-dev] Re: Re: duplication between default: and version40beta2:?
by StÃ©phane Ducasse Dec. 3, 2009

Dec. 3, 2009

> From: stephane ducasse <stephane.ducasse(a)gmail.com> > Date: December 3, 2009 8:27:27 PM GMT+01:00 > To: metacello(a)googlegroups.com > Cc: Pharo-project(a)lists.gforge.inria.fr, Related to the development of Moose and other related tools <moose-dev(a)iam.unibe.ch> > Subject: Re: [Pharo-project] [Moose-dev] Re: Re: duplication between default: and version40beta2:? > > > apparently we had a differetn definition of map. > my point is that we need map with exact numbers of component to be able to reload and build more. > Now I like the baseline idea. > > On Dec 3, 2009, at 8:14 PM, Dale Henrichs wrote: > >> >> In a Metacello context. >> >> The map of packages and their relationships is called a #baseline version. If one loads a #baseline version the latest version of each package is loaded. The "structure" is stable but loading a #baseline version is a risky proposition for everyone except project developers themselves who are prepared to address load-time conflicts/bugs. >> >> A #development version, imports structure from the #baseline, but a specific package version is supplied for each Monticello package or project. When a development version is loaded, the explicit list of package versions are loaded. IN a #development version, the package versions are not finalized and may change over time. When a #development version is saved, there is an presumption that some level of testing has gone on and that the package versions are expected to work together. One can go to a particular version of the package in which the configuration is saved and expect to load the same packages....However, the list of package versions will change over time. >> >> For all other 'released' versions, (beta, release, alpha, stable, etc.) it is expected that the list of package versions will never change - the code base may still be alpha, but it is a stable known point with respect to package versions. >> >> (BTW, I've added the metacello group to this cross-posted message:) >> >> Dale >> ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: >> >> | Still still still you can always have a map (a map of all the >> | components you loaded that they work or not). >> | This is orthogonal to a release or just publications. This is a >> | sofware artefact. I know that you know it. >> | The fact to have map is orthogonal of the choice latest or one >> | version. >> | I just write that for others following our discussion.... >> | >> | Stef >> | >> | >> | >> | On Dec 3, 2009, at 3:59 PM, Tudor Girba wrote: >> | >> | > Hi, >> | > >> | > Not every loading strategy have the same goal or the same context. >> | > >> | > Sub projects will be developed and published in their own context >> | > without taking into account the overall project. However, when >> | > maintaining the overall project, I want to be able to say "load >> | > latest" so that I can easily load everything and check whether >> | > everything still holds together. >> | > >> | > For overall release management, I do not want to rely on "load >> | > latest". Instead I will release a coherent version when I see that >> | it >> | > works. This will be a fixed set of packages with exact versions that >> | >> | > will work together. >> | > >> | > Cheers, >> | > Doru >> | > >> | > >> | > On 3 Dec 2009, at 14:21, Marcus Denker wrote: >> | > >> | >> >> | >> On Dec 3, 2009, at 1:40 PM, Laval Jannik wrote: >> | >> >> | >>> Yeh, >> | >>> >> | >>> Now, I understand the process... (I am slow :) ) >> | >>> >> | >>> But, in this process we must specify versions and maintain it. >> | >>> Is there a solution (in monticello maybe) to say a version of a >> | >>> package is stable. >> | >>> So in this case, we can say "I want last stable version of my >> | >>> package" and we do not need to maintain ConfigurationOf. >> | >>> >> | >> >> | >> The problem is that it's not one package... your system will be 20 >> | >> | >> packges. You can say " load the latest of all, that works". >> | >> But: now I want to load the version that worked so great last >> | month. >> | >> Which set of packages exactly where that? >> | >> >> | >> Tagging single packages as "release" will not help, as you don't >> | >> have the info which released package works with which other >> | >> released package. >> | >> >> | >> >> | >> Marcus >> | >> _______________________________________________ >> | >> Moose-dev mailing list >> | >> Moose-dev(a)iam.unibe.ch >> | >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> | > >> | > -- >> | > www.tudorgirba.com >> | > >> | > "Obvious things are difficult to teach." >> | > >> | > >> | > >> | > >> | > _______________________________________________ >> | > Pharo-project mailing list >> | > Pharo-project(a)lists.gforge.inria.fr >> | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> | >> | >> | _______________________________________________ >> | Pharo-project mailing list >> | Pharo-project(a)lists.gforge.inria.fr >> | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > >

1 0

[Pharo-project] [ann 1.1] pre-built #11068
by Marcus Denker Dec. 3, 2009

Dec. 3, 2009

http://gforge.inria.fr/frs/download.php/24963/PharoCore-1.1-11068-alpha.zip

8 11

Re: [Pharo-project] [Moose-dev] Re: duplication between default: and version40beta2:?
by Laval Jannik Dec. 3, 2009

Dec. 3, 2009

Yeh, Now, I understand the process... (I am slow :) ) But, in this process we must specify versions and maintain it. Is there a solution (in monticello maybe) to say a version of a package is stable. So in this case, we can say "I want last stable version of my package" and we do not need to maintain ConfigurationOf. Maybe this discussion is more global than moose community, So I copy it in pharo mailing list. Jannik On Dec 3, 2009, at 13:15 , Tudor Girba wrote: > Hi Stef, > > As I mentioned before, default represents the work in progress. It can happen that the work in progress is the same as the previously released version, and that is why you will see duplication. > > Another possibility would be to reuse the previous configuration and just mention the delta (of adding new packages), but I am not sure this would scale in the long run. > > So, the current process is: > - work on default > - when we release, we copy the method in a new baselineXXX > - we create a hardcoded version in versionXXX > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "We cannot reach the flow of things unless we let go." > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

6 5

[Pharo-project] Slime at work
by laurent laffont Dec. 3, 2009

Dec. 3, 2009

Hi, I'm reading Dynamic Web Development with Seaside. I'm lost on how to open Slime on a specific package in Pharo, as described here: http://book.seaside.st/book/components/slime/at-work Regards, Laurent

3 3

[Pharo-project] Why some packages are rejected from Test Coverage?
by Mariano Martinez Peck Dec. 3, 2009

Dec. 3, 2009

Ok, I see that there are some packages that are not able to be selected to run test coverage. I noticed that they were big packages and then I saw the method: TestRunner >> promptForPackages where you can see it rejects packages like Kernel, Collections, System, etc. I guess because Test Coverage may take long time in those big packages....but I don't know if that's a good reason to disable them. Maybe a popup saying "Are you sure you want to run Test Coverage over this package? It will take a lot of time" is better. At least VisualWorks does something similar. What do you think ? Cheers, Mariano

4 5

[Pharo-project] Issue 1541: Settings integration part3
by Alain Plantec Dec. 3, 2009

Dec. 3, 2009

in InBox: SLICE-SettingsMigrationPart3-AlainPlantec.2 *added a menu entry in the world menu for the new setting browser. * added double-click handling in MorphTreeMorph * SystemSettingBrowser, double clicking on a row open a class browser on the method which declares the selected setting * do not update a SystemSettingBrowser if it is not viewed by an opened window (prevents updating of a closed but not yet garbaged window) * improved gradient background rendering (radial direction) * added System-Support-SystemSettings, Network-SystemSettings, Polymorph-SystemSettings and Monticello-SystemSettings packages * migrate all preferences from the old 'Browsing' preferences group * migrate existing http proxy preferences * migrate existing media preferences * add settings for network user name, password, blab email, author fullname * deprecation of some old preference methods Alain

1 0

[Pharo-project] small pharo success story
by Marcus Denker Dec. 3, 2009

Dec. 3, 2009

Hi, 2Denker now has it's first iPhone app deployed and in the store that uses a Pharo backend: http://2denker.de/findabike (german only) The app shows the bikes of DB (German Railway Company): http://en.wikipedia.org/wiki/Call_a_Bike On the phone, we use a standard Objective-C frontend. It gets the data via http from a pharo server. Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de 2denker UG (haftungsbeschrÃ¤nkt) Sitz KÃ¶ln Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker

2 2

[Pharo-project] StandardFonts vs Preferences
by Henrik Johansen Dec. 3, 2009

Dec. 3, 2009

Alain, could you deprecate (and remove entires from Parameters) all the set... and get... font-messages in Preferences? Would make it somewhat easier to make the transition from codebits using the Preferences methods for setting, which currently (in most cases) gives no feedback except not changing the fonts. (Like, say, the System Fonts-menu) Also, consider if the setDefaultFonts: / restoreDefaultFonts methods would be useful. Cheers, Henry

2 1

[Pharo-project] Very tiny fonts
by Marcus Denker Dec. 3, 2009

Dec. 3, 2009

Hi, While discussing Visualisations, we realized we want *really* tiny fonts... Here is a hand-drawn sub-pixel font that is just 5 pixels high... http://typophile.com/node/61920 Now we need to make a font for Pharo... Marcus

4 6