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

Re: [Pharo-project] Pharo 1.2 broken on Hudson due to XMLSupport changes

by laurent laffont

On Fri, Feb 25, 2011 at 5:11 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > > On Feb 25, 2011, at 2:10 PM, Torsten Bergmann wrote: > > > Markus wrote: > >> The XML package breaks the build? So let's remove it completely. Let's > ship >1.2, but without all the packages that are problematic. > > > > It's not that the package is problematic - the Configs are problematic > > Exact > But still can't Pharo Dev focuses on tools and not frameworks that we > should load by ourselves. > Because else why not loading, cassandra, coucdb, opendbx, magma.... > Because many more people are manipulating XML every day than connecting to Cassandra ? Personnally I would like support for MySQL/PostreSQL out of the box too. Laurent > > Stef > > > > Laurent wrote: > >> For XML I can fix this tonight if Otto don't want / can do it. > > > > Yes, the problematic 1.1.8 version of XMLSupport has to be fixed. > > But it is not yet used by Pharo ... so this is not the reason: > > > > What strikes me is that ConfigurationOfPharo STILL references > > the working 1.1.6 version BUT the corrupt 1.1.8 version is > > loaded instead. > > THIS is the reason why Hudson is read! > > > > If you look at ConfigurationOfPharo then it hasnt changed > > since 18 February 2011 (ConfigurationOfPharo-GuillermoPolito.134) > > and if you load "ConfigurationOfXMLSupport-DaleHenrichs.46" > > from 9 February 2011 and check what Otto Behrens changed > > then you will notice that he did'nt touch the 1.1.6 version > > of ConfigurationOfXMLSupport. > > > > He just added a baseline/version 1.1.8 and 1.1.9. > > > > So the "old" version 1.1.6 which is used by ConfigurationOfPharo > > was not touched either. > > > > To me this looks like a Metacello resolving remote project > > versions problem? (that's why I CC:ed Dale) > > > > > >> But I agree that it seems few people care about 1.2. Sad, I like it far > >> better than 1.1.1. > > > > Yes, but I think we opened 1.3 too early. I think thats > > why community does not concentrate on Pharo dev 1.2 too much > > and continues to work on 1.3 core instead. > > > > Thats good for moving Pharo forward - but not for outside > > visibility. How should others deliver software on top of Pharo > > if Pharo isnt delivered itself? > > > >> I personally thing if we ever want to release 1.2, we need to start to > be >more radical. > > > > Yes - but not by throwing out broken packages. What if Hudson > > is broken by a problem in clas Object. Would you throw out Kernel? > > > > Instead I would propose for the harvesters/integrators to stop > > integrating stuff for 1.3 until Pharo 1.2 is out of the door... > > > > Bye > > T. > > -- > > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > >

Feb. 25, 2011

Re: [Pharo-project] Pharo 1.2 broken on Hudson due to XMLSupport changes

by Esteban Lorenzano

+1 El 25/02/2011, a las 1:09p.m., StÃ©phane Ducasse escribiÃ³: > Marcus > > I would not add XML in dev. just dev tools no extra package. > So yes let us remove XML package. I already asked for that. > Now the problem encountered reveal something deeper. > > > STef > > On Feb 25, 2011, at 1:18 PM, Marcus Denker wrote: > >> I personally thing if we ever want to release 1.2, we need to start to be more radical. >> >> The XML package breaks the build? So let's remove it completely. Let's ship 1.2, but without >> all the packages that are problematic. >> >> Same for any other package that has a failing test. >> >> Marcus >> >> >> On Feb 25, 2011, at 1:12 PM, Torsten Bergmann wrote: >> >>> Still I do not understand: >>> >>> Evaluate this in an updated Pharo core 1.2: >>> >>> ------------------------------------------------------------------------ >>> Gofer new >>> squeaksource: 'MetacelloRepository'; >>> package: 'ConfigurationOfXMLSupport'; >>> load. >>> >>> (Smalltalk at: #ConfigurationOfXMLSupport) project latestVersion >>> ------------------------------------------------------------------------ >>> >>> returns 1.1.8 [ConfigurationOfXMLSupport] >>> >>> This is now broken by Otto. OK, he broke it, he has to repair it ;) >>> >>> But independent from that, the method in: >>> >>> ConfigurationOfPharo>>version12beta2: >>> >>> includes the following: >>> >>> project: 'XMLSupport' with: '1.1.6'. >>> >>> So I would have expected that for Pharo "1.2-beta2" the 1.1.6 (and not the >>> 1.1.8) of XMLSupport gets loaded and Hudson should have been green. >>> >>> Why does Metacello load the 1.1.8 when a previous project version (1.1.6) >>> is referenced? >>> >>> Dale, any comments? >>> >>> Bye >>> T. >>> >>> >>> >>> -- >>> Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir >>> belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de >>> >> >> -- >> Marcus Denker -- http://www.marcusdenker.de >> INRIA Lille -- Nord Europe. Team RMoD. >> >> > >

Feb. 25, 2011

Re: [Pharo-project] About UIManager and UITheme for MenuMorph

by Gary Chambers

Indeed, a step forward. UIManager is a quite focussed facade. Perhaps the "unusual" usages of MenuMorph can be analysed as to their main intent. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, February 25, 2011 4:27 PM Subject: Re: [Pharo-project] About UIManager and UITheme for MenuMorph Gary What I mean is that there are a lot of places where MenuMorph is hardcoded and the UIManager does not have a chance to take control. I imagine that this is for this reason that guillermo proposed this change. Stef > Not sure what you mean but I'd expect high-level interactions to not ask > for a menuClass. > Still, in headless case, with this, it is possible to provide a suitable > replacement. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" > <stephane.ducasse(a)inria.fr> > To: "pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, February 25, 2011 3:47 PM > Subject: [Pharo-project] About UIManager and UITheme for MenuMorph > > > Hi gary > > I was reading > http://code.google.com/p/pharo/issues/detail?id=3728 > which converts MenuMorph new -> UIManager default menuClass > > And I was wondering: > - UIManager regulate coarse grained interaction > > - UITheme takes into account settings > > Now UIManager does not provide handy MenuMorph creation method besides > choose.... and friends. > And now I'm looking at TEasilyThemed and it refers to MenuMorph so I'm > wondering if in headless > we could not still have popup menu raised. > > Stef >

Feb. 25, 2011

Re: [Pharo-project] Could we clean/remove some of the old themes?

by Gary Chambers

Go for it (or was that Gofer ;-) ) Regards, Gary ----- Original Message ----- From: "stephane ducasse" <stephane.ducasse(a)free.fr> To: "pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, February 25, 2011 3:30 PM Subject: [Pharo-project] Could we clean/remove some of the old themes? >I would suggest > to remove/package in a separate package StandardSqueak > to remove the Pro theme (because the fonts are broken) > to rename softSqueak into Colorful > > Stef >

Feb. 25, 2011

Re: [Pharo-project] About UIManager and UITheme for MenuMorph

by StÃ©phane Ducasse

Gary What I mean is that there are a lot of places where MenuMorph is hardcoded and the UIManager does not have a chance to take control. I imagine that this is for this reason that guillermo proposed this change. Stef > Not sure what you mean but I'd expect high-level interactions to not ask for a menuClass. > Still, in headless case, with this, it is possible to provide a suitable replacement. > > Regards, Gary > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: "pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, February 25, 2011 3:47 PM > Subject: [Pharo-project] About UIManager and UITheme for MenuMorph > > > Hi gary > > I was reading > http://code.google.com/p/pharo/issues/detail?id=3728 > which converts MenuMorph new -> UIManager default menuClass > > And I was wondering: > - UIManager regulate coarse grained interaction > > - UITheme takes into account settings > > Now UIManager does not provide handy MenuMorph creation method besides choose.... and friends. > And now I'm looking at TEasilyThemed and it refers to MenuMorph so I'm wondering if in headless > we could not still have popup menu raised. > > Stef >

Feb. 25, 2011

Re: [Pharo-project] Pharo 1.2 broken on Hudson due to XMLSupport changes

by StÃ©phane Ducasse

Hi otto no stress. :) There is no problem. Doing something implies that we can do it wrong (I do all the times mistakes and I hope that I learn to improve myself). I prefer having a community of people doing some wrong actions than just talking. Stef On Feb 25, 2011, at 4:53 PM, Otto Behrens wrote: >> - For XML I can fix this tonight if Otto don't want / can do it. > > 1.1.9 was blessed as #development and 1.1.8 as #release. I changed the > blessing 1.1.9 to #released. I do believe that the 1.1.9 version works > well. 1.1.8 is now #broken. > > Sorry about that. Thanks for the help. > > I'm doing a load in Pharo 1.2 now... >

Feb. 25, 2011

Re: [Pharo-project] Issue 3743 in pharo: Fix Finder UI (add shortcuts and more commands)

by pharo＠googlecode.com

Comment #9 on issue 3743 by Benjamin...(a)gmail.com: Fix Finder UI (add shortcuts and more commands) http://code.google.com/p/pharo/issues/detail?id=3743 Merge done in Finder-BenjaminVanRyseghem.26 in PharoInbox

Feb. 25, 2011

Re: [Pharo-project] Pharo 1.2 broken on Hudson due to XMLSupport changes

by StÃ©phane Ducasse

On Feb 25, 2011, at 2:10 PM, Torsten Bergmann wrote: > Markus wrote: >> The XML package breaks the build? So let's remove it completely. Let's ship >1.2, but without all the packages that are problematic. > > It's not that the package is problematic - the Configs are problematic Exact But still can't Pharo Dev focuses on tools and not frameworks that we should load by ourselves. Because else why not loading, cassandra, coucdb, opendbx, magma.... Stef > > Laurent wrote: >> For XML I can fix this tonight if Otto don't want / can do it. > > Yes, the problematic 1.1.8 version of XMLSupport has to be fixed. > But it is not yet used by Pharo ... so this is not the reason: > > What strikes me is that ConfigurationOfPharo STILL references > the working 1.1.6 version BUT the corrupt 1.1.8 version is > loaded instead. > THIS is the reason why Hudson is read! > > If you look at ConfigurationOfPharo then it hasnt changed > since 18 February 2011 (ConfigurationOfPharo-GuillermoPolito.134) > and if you load "ConfigurationOfXMLSupport-DaleHenrichs.46" > from 9 February 2011 and check what Otto Behrens changed > then you will notice that he did'nt touch the 1.1.6 version > of ConfigurationOfXMLSupport. > > He just added a baseline/version 1.1.8 and 1.1.9. > > So the "old" version 1.1.6 which is used by ConfigurationOfPharo > was not touched either. > > To me this looks like a Metacello resolving remote project > versions problem? (that's why I CC:ed Dale) > > >> But I agree that it seems few people care about 1.2. Sad, I like it far >> better than 1.1.1. > > Yes, but I think we opened 1.3 too early. I think thats > why community does not concentrate on Pharo dev 1.2 too much > and continues to work on 1.3 core instead. > > Thats good for moving Pharo forward - but not for outside > visibility. How should others deliver software on top of Pharo > if Pharo isnt delivered itself? > >> I personally thing if we ever want to release 1.2, we need to start to be >more radical. > > Yes - but not by throwing out broken packages. What if Hudson > is broken by a problem in clas Object. Would you throw out Kernel? > > Instead I would propose for the harvesters/integrators to stop > integrating stuff for 1.3 until Pharo 1.2 is out of the door... > > Bye > T. > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

Feb. 25, 2011

Re: [Pharo-project] Pharo 1.2 broken on Hudson due to XMLSupport changes

by Otto Behrens

It loaded and XML-Tests-Parser reports: 361 run, 361 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes Running all tests now (11240) ... On Fri, Feb 25, 2011 at 6:04 PM, Otto Behrens <otto(a)finworks.biz> wrote: > I've downloaded the PharoOneClick1.2.zip file and am evaluating > > Â (ConfigurationOfPharo project version: '1.2-beta2') load > > now. This is the best "entry point" that I could determine from the > console output. Please let me know if this is OK. My bandwidth is not > amazing, but it's running. > > On Fri, Feb 25, 2011 at 5:53 PM, Otto Behrens <otto(a)finworks.biz> wrote: >>> - For XML I can fix this tonight if Otto don't want / can do it. >> >> 1.1.9 was blessed as #development and 1.1.8 as #release. I changed the >> blessing 1.1.9 to #released. I do believe that the 1.1.9 version works >> well. 1.1.8 is now #broken. >> >> Sorry about that. Thanks for the help. >> >> I'm doing a load in Pharo 1.2 now... >> >

Feb. 25, 2011

Re: [Pharo-project] About UIManager and UITheme for MenuMorph

by Gary Chambers

Not sure what you mean but I'd expect high-level interactions to not ask for a menuClass. Still, in headless case, with this, it is possible to provide a suitable replacement. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Friday, February 25, 2011 3:47 PM Subject: [Pharo-project] About UIManager and UITheme for MenuMorph Hi gary I was reading http://code.google.com/p/pharo/issues/detail?id=3728 which converts MenuMorph new -> UIManager default menuClass And I was wondering: - UIManager regulate coarse grained interaction - UITheme takes into account settings Now UIManager does not provide handy MenuMorph creation method besides choose.... and friends. And now I'm looking at TEasilyThemed and it refers to MenuMorph so I'm wondering if in headless we could not still have popup menu raised. Stef

Feb. 25, 2011