December 2012 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20446

by StÃ©phane Ducasse

Dec. 20, 2012

[Pharo-project] [update 2.0] #20445

by StÃ©phane Ducasse

Dec. 20, 2012

Re: [Pharo-project] KeyChain/UsersManager

by Pavel Krivanek

It broke following Pharo Kernel jobs because the image crashes when a directory is changed. So how to fix that. We have several options: - make simple ugly fix that will check presence of this class, it will generate unimplemented calls - remove it and add it back fixed in 3.0 - rewrite the Author change mechanism to Announcements (in 3.0?) What do you propose? -- Pavel On Sat, Dec 15, 2012 at 3:01 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > it was in the list of things to integrate :) > but we should check to clean the dependence, because is not good. > > Esteban > > On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> Hi, >> >> what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-) >> >> Cheers, >> -- Pavel > >

Dec. 20, 2012

Re: [Pharo-project] Small mini howto on moving a project to SmalltalkHub

by Igor Stasenko

On 19 December 2012 23:16, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > abergel wrote >> No no. This can not work > > Can you please provide the rationale behind that statement? :) > Because then a single person seen as a responsible for the whole project, which is not correct model for team-driven development. Projects, which developed by teams, deserve having own canonical repository, while it developers are free to commit into own local copy before committing to 'official' repo. > DISCLAIMER: Since I'm not actively participating in any alternative, I will > happily receive whatever gets done. > > Regards! > -- Best regards, Igor Stasenko.

Dec. 20, 2012

Re: [Pharo-project] Small mini howto on moving a project to SmalltalkHub

by StÃ©phane Ducasse

We spent a lot of time with nicolas talking about it. So let us focus on something else :) Stef On Dec 19, 2012, at 11:16 PM, Esteban A. Maringolo wrote: > abergel wrote >> No no. This can not work > > Can you please provide the rationale behind that statement? :) > > DISCLAIMER: Since I'm not actively participating in any alternative, I will > happily receive whatever gets done. > > Regards! > > > > -- > View this message in context: http://forum.world.st/Feature-requests-and-a-tip-for-SmalltalkHub-tp4659760… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Dec. 20, 2012

[Pharo-project] wrong ci download scripts

by Pavel Krivanek

Hi, the Pharo 2.0 job is broken because the new script name contains uppercase typo: ciNBCOgVM.sh -- Pavel

Dec. 20, 2012

Re: [Pharo-project] [Issue Tracker] issues tagged 2.0

by Marcus Denker

130 to goâ¦ (down from nearly 170 yesterday). On Dec 19, 2012, at 1:56 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone%3D2.0&colspec=… > > We need to look at each one and decide > -> is this a show stopper for releasing 2.0? > - Hint: a bug that was already in 1.4 is *not* > - A "nice to have" improvement is not, either. > - Same for cleanups. > > Marcus

Dec. 20, 2012

[Pharo-project] [update 2.0] #20444

by Marcus Denker

20444 ----- Issue 7154: Better tab naming in config browser http://code.google.com/p/pharo/issues/detail?id=7154 Issue 7153: DNU on a deprecated String progress display method http://code.google.com/p/pharo/issues/detail?id=7153 Issue 7152: DNU when searching a Change Set in Change Sorter http://code.google.com/p/pharo/issues/detail?id=7152 Issue 7145: simplify MethodContext>>#tempNamed: http://code.google.com/p/pharo/issues/detail?id=7145 Diff information: http://ss3.gemstone.com/ss/Pharo20/UIManager-MarcusDenker.93.diff http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.1003.diff http://ss3.gemstone.com/ss/Pharo20/Spec-Tools-MarcusDenker.73.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1272.diff

Dec. 20, 2012

[Pharo-project] Configuration Browser tab naming

by Torsten Bergmann

>I thought the distinction you wanted to make was >identifying which Configurations the Inria Pharo Team took direct >responsibility for supporting, which I thought was a reasonable >distinction and I would find useful. No - I justed wanted to have all the Configs that worked in a specific Pharo version easily accessible to new user right from a menu. The ideas is simple: If someone downloads Pharo he usually does not know magic Gofer/Metacello scripts. He also did'nt follow the mailinglist for years to know about all the nice things that are available in Pharo world and on so many different servers (SqS, SS3, SmalltalkHub, ...) On the other side ACCESSIBILITY of packages and informations is CRUCIAL for ADOPTION. Otherwise people turn away after a short look. Thats why I created the Pharo help browser, the config browser and now work on an Pharo online help (which is alpha but accessible from the config browser already). And I'm not Inria ;) >So anyone (having done the necessary validation for 2.0) can copy into >the MetaRepoForPharo20 ? Yes - for now we do it manually. In the future I would like to see a mechanism that loads the config for a specific Pharo version and validates by running all the tests. If broken the author/community can be informed. If OK it should appear in the config browser... Bye T.

Dec. 20, 2012

Re: [Pharo-project] Configuration Browser tab naming

by Ben Coman

Torsten Bergmann wrote: > I think the naming is more related to historic > development: my original implementation just had one tab > named "Configurations". > > Esteban later added "Untrusted" since these are the ones > that are not (yet) tested in the according Pharo version. > It's a nice addition since it makes them easily accessible > as well. > > However I now changed the tab names to "Core" and "Community" > in > > http://code.google.com/p/pharo/issues/detail?id=7154 > > > Reminder: > ========= > It is still required that people try out the "Community" > ones and if they are working fine in Pharo 2.0 copy them to > > http://ss3.gemstone.com/ss/MetaRepoForPharo20 > > so they appear in "Core" > > So anyone (having done the necessary validation for 2.0) can copy into the MetaRepoForPharo20 ? I had misunderstood. I thought the distinction you wanted to make was identifying which Configurations the Inria Pharo Team took direct responsibility for supporting, which I thought was a reasonable distinction and I would find useful. If the idea was to gather all Configurations that worked in Pharo 1.4 to make it easier to jumpstart testing them in 2.0, then I was incorrect to suggest renaming that to "Community". I was thinking a "Community" tab would be packages validated for 2.0 but those outside the Core Pharo Team. Rethinking this, perhaps having a "Consortium" tab would be useful. This would be an additional benefit for members to populate, giving a higher profile for any of the packages they provide or the products depend on. The side benefit for members is that wider usage of the packages they depend on means more eyeballs and hands improving those packages. The benefit for me as an end user would be a list of packages that are likely used somewhere in a real customer facing product with attendant professional level of care and maintenance by others. Along the same lines there might be an "Association" tab for members of the PUA to use. The benefit to me as an end-user is seeing which packages are liked/supported by those with a higher level of commitment to Pharo. This doesn't necessarily need the main developer to be a member, just that a member finds it of use to themselves. To avoid needing to manage multiple MetaRepoForXXXX on squeaksource server side, perhaps the Configuration Browser can pull a status file from the PC & PUA websites. On the websites members could see a list of Configurations in the MetaRepoForPharo20 and "Like" the ones they want. ConfigurationBrowser could continue to pull the Configurations from just one location, and the categorization done on the basis of these status files. A "Backward Compatibility" tab might be useful to segregate out things like ConfigurationOfFileDirectory, clearing identifying it as deprecated so as not to confuse newcomers, and also provide a jumpstart for anyone wanting to port old pre-Pharo code to Pharo. "Consortium" might be inclusive of "Core" to avoid having too many tabs, and also since maybe many Consortium projects might be private/commercial and this list might remain lightly populated. anyway, just random thoughts bubbling over, cheers -ben

Dec. 20, 2012