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

Re: [Pharo-project] World Menu (was [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2)

by laurent laffont

2010/2/5 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2010/2/4 laurent laffont <laurent.laffont(a)gmail.com> > > Hi, >> >> I was thinking that there's no entry in the world menu to re-open the >> welcome workspace. For beginners it may be useful ? >> > > Yes, I agree. I also though about that but I didn't know where to put it in > the menu neither how to code it. Ok, I have several examples to look how to > do it, but nil time for the last week :( > > Where exactly do you think is the best place to put it in the menu ? I said > several times about the issue: > > http://code.google.com/p/pharo/issues/detail?id=1042 > > (search in mailing list also) > > It is OBVIOUS that we are missing a "help menu". > I agree > > There we can put also this thing to reopen the welcome workspace. > > Now....do we have time to do this for 1.0 ? someone ? > I will take a look. No promise. In World > Tools: >> - duplicated entries: Class Browser, Workspace, Test Runner, Monticello >> Browser >> > > These are the most common used tools, that's why they are there. > I prefer one thing at one place :) Laurent > > >> >> In World > Tools > More: >> - Language editor / language editor for.... these tools look strange :) >> > > And I don't know if they are even working, > > >> - duplicated entries: Monticello Browser, Preference Browser, Test Runner >> - someone use Search Browser and Services Browser ? >> - MCConfigurationBrowser: what is the purpose of this tool ? >> (may be we can remove this "Other tools" menu, merging it with tools) >> >> >> Cheers, >> >> Laurent Laffont >> >> >>

Feb. 5, 2010

Re: [Pharo-project] Diff morphs

by Mariano Martinez Peck

On Fri, Feb 5, 2010 at 12:44 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > So, which layout style would be prefered? I'll wait for answers before > versioning... > > This is cool Gary. I like both :) Maybe a bit more the first one. > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, February 04, 2010 8:12 PM > Subject: Re: [Pharo-project] Diff morphs > > > > this is excellent > > I'm nearly mixing left and right so ..... > > > > Stef > > On Feb 4, 2010, at 6:42 PM, GARY CHAMBERS wrote: > > > >> Or, an alternative layout... > >> > >> From: GARY CHAMBERS <gazzaguru2(a)btinternet.com> > >> To: Pharo-project(a)lists.gforge.inria.fr > >> Sent: Thursday, 4 February, 2010 17:06:49 > >> Subject: [Pharo-project] Diff morphs > >> > >> Hi, having though about "labelling" this is likely the best that can be > >> managed for the Diff tools UI without refactoring some large chunks of > >> Monticello. > >> > >> Comments/ideas welcome... > >> > >> See attached: > >> <alternative-layout.png>_______________________________________________ > >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 5, 2010

Re: [Pharo-project] World Menu (was [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2)

by Mariano Martinez Peck

2010/2/4 laurent laffont <laurent.laffont(a)gmail.com> > Hi, > > I was thinking that there's no entry in the world menu to re-open the > welcome workspace. For beginners it may be useful ? > Yes, I agree. I also though about that but I didn't know where to put it in the menu neither how to code it. Ok, I have several examples to look how to do it, but nil time for the last week :( Where exactly do you think is the best place to put it in the menu ? I said several times about the issue: http://code.google.com/p/pharo/issues/detail?id=1042 (search in mailing list also) It is OBVIOUS that we are missing a "help menu". There we can put also this thing to reopen the welcome workspace. Now....do we have time to do this for 1.0 ? someone ? > > In World > Tools: > - duplicated entries: Class Browser, Workspace, Test Runner, Monticello > Browser > These are the most common used tools, that's why they are there. > > In World > Tools > More: > - Language editor / language editor for.... these tools look strange :) > And I don't know if they are even working, > - duplicated entries: Monticello Browser, Preference Browser, Test Runner > - someone use Search Browser and Services Browser ? > - MCConfigurationBrowser: what is the purpose of this tool ? > (may be we can remove this "Other tools" menu, merging it with tools) > > > Cheers, > > Laurent Laffont > > > 2010/1/22 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Hi folks. This is 1.0 RC2. Please, look at this image in a nice way >> because it is very likely that if there is no big issue, it will be 1.0 >> official. We need to release 1.0. >> * >> Issues fixed*: In addition to the fixes from the PharoCore, we have: >> 1033, 1182, 1826, 1862. >> >> *Big changes*: >> >> - Now we use OB from Lukas Renggli repository and we have ALL TESTS >> GREEN!!! Thanks Lukas! >> - O2 loads again in the image without breaking OB. Read the workspace to >> see how to install it. Thanks David and Alexandre! >> - We have almost (only one failing here) ALL TESTS of the PharoDev image >> in green. They are more than 8800. >> >> *Smaller changes: >> * >> - Fixed the problem with Metacello and OCompletion. No more overrides. >> - System -> About now shows the real Pharo name, not the core. I am also >> being "compatible" with the new SystemVersion that we have in 1.1 :) >> Thanks Michael and Miguel! >> - I didn't left again my proxy settings. I fixed this in my build scripts. >> It should be clean :) >> - Mercury bar is back again. If you want to disable: Preferences disable: >> #mercuryPanel. >> - Added a lot of cleanups after creating the image, including condensing >> .changes >> - Added Refactoring-Spelling again. Thanks Stan! >> - I wrote a ConfigurationOfNile instead of Nile-All and depends on >> Monticello dependencies. >> - New welcome workspaces. Also getting started workspace and another >> workspace explaining how to load external packages like Seaside (2.8 and 3), >> Magritte, Pier, Moose, GetTools, O2, etc. Finally it is also added a link to >> the new ProfStef :) >> Do you think that with this we are able to close issue1479 ? >> - Background with Pharo picture. This was a joke. It looked nice :) I >> promise I don't put it again if you don't like. To remove it evaluate: >> World color: Color white. >> - Enable the preference fastDragWindowForMorphic. Sorry, but it most >> computers this works REALLY slow. If you want them back, just disable it. >> - When installing Seaside now doesn't ask for user and password ( >> admin/seaside ). In addition, the Seaside Control Panel is only isntalled if >> OB is installed. This means that yu can install it in core or dev. Thanks >> Dale! >> - Disable of System Update for Dev images as it is not working properly. >> >> >> The link is: >> https://gforge.inria.fr/frs/download.php/25397/Pharo1.0-10508-rc2dev10.01.2… >> >> Cheers >> >> Mariano >> >> >> >> _______________________________________________ >> 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 >

Feb. 5, 2010

Re: [Pharo-project] Diff morphs

by Tudor Girba

Hi Gary, I like the first one especially if it would be part of the Diff morph. This morph could then be used in another context as well. There would be two things I would maybe change: 1. Right now, you color both in the same way, but you distinguish the labels via a background color. Perhaps, if the panes would be colored in the same way as the labels, it would be better. Also, I would rather opt for a white background because text is better readable in this context. 2. I would decrease the thickness of the divider Cheers, Doru On 5 Feb 2010, at 00:44, Gary Chambers wrote: > So, which layout style would be prefered? I'll wait for answers before > versioning... > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Thursday, February 04, 2010 8:12 PM > Subject: Re: [Pharo-project] Diff morphs > > >> this is excellent >> I'm nearly mixing left and right so ..... >> >> Stef >> On Feb 4, 2010, at 6:42 PM, GARY CHAMBERS wrote: >> >>> Or, an alternative layout... >>> >>> From: GARY CHAMBERS <gazzaguru2(a)btinternet.com> >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Sent: Thursday, 4 February, 2010 17:06:49 >>> Subject: [Pharo-project] Diff morphs >>> >>> Hi, having though about "labelling" this is likely the best that >>> can be >>> managed for the Diff tools UI without refactoring some large >>> chunks of >>> Monticello. >>> >>> Comments/ideas welcome... >>> >>> See attached: >>> <alternative- >>> layout.png>_______________________________________________ >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "In a world where everything is moving ever faster, one might have better chances to win by moving slower."

Feb. 5, 2010

Re: [Pharo-project] Diff morphs

by Gary Chambers

So, which layout style would be prefered? I'll wait for answers before versioning... Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, February 04, 2010 8:12 PM Subject: Re: [Pharo-project] Diff morphs > this is excellent > I'm nearly mixing left and right so ..... > > Stef > On Feb 4, 2010, at 6:42 PM, GARY CHAMBERS wrote: > >> Or, an alternative layout... >> >> From: GARY CHAMBERS <gazzaguru2(a)btinternet.com> >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Thursday, 4 February, 2010 17:06:49 >> Subject: [Pharo-project] Diff morphs >> >> Hi, having though about "labelling" this is likely the best that can be >> managed for the Diff tools UI without refactoring some large chunks of >> Monticello. >> >> Comments/ideas welcome... >> >> See attached: >> <alternative-layout.png>_______________________________________________ >> 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

Feb. 4, 2010

Re: [Pharo-project] Fwd: October 2006 Agreement from Apple to VPRI regarding License changes

by John M McIntosh

Great to see the original. Now if anyone asks about Apple fonts... I won't comment. You all can look in the archives for the fact we *removed* the Apple fonts from the Squeak image, which took a bit of time.. The first note starts in the squeak list on or about: July 7, 2000 12:14:17 AM PDT The last note on or about: February 24, 2005 12:32:37 PM PST On 2010-02-04, at 12:44 PM, Torsten Bergmann wrote: > see > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144099… > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

Feb. 4, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by StÃ©phane Ducasse

Thanks henrik. I'm in the process of integrating the changes :) I was just systematically converting. So I will create a new issue for these remarks. Stef On Feb 4, 2010, at 10:02 PM, Henrik Sperre Johansen wrote: > On 03.02.2010 10:26, StÃ©phane Ducasse wrote: >> Hi henrik >> >> if you get a chance to have a look at the slice I uploaded it would be good. >> I like the idea that people have a look at other code, which is what we do when we integrate >> now for my own code I always feel nervous :) >> >> Stef >> > Got time tonight, here's my comments: > > DigitalSignatureAlgorithm class >> testExamplesFromDisk > May be better as a real test than as a class-side method? The method > usage change seems fine though ;) > > FilePackage >> fromFileNamed: > Should be inlined in the class-side method called the same, and removed. > Only this method is ever called anyways, and it makes less sense to > accept from... style initialization methods on the instances. > > > MCVersionReader class >> file:streamDo: > Could instead be inlined in versionFromFile which is the only sender, > then removed. > The way it's now, it's really only a MCVersionReader-specific alias for > the exact same method :) > > MCVersionReader class >> versionFromFile: > ^FileStream readOnlyFileNamed: fileName do: [:fileStream | self > versionFromStream: fileStream] > > > UUIDGenerator>>makeUnixSeed > You set the stream to binary, there should be no need to set the > converter as well (it won't be used in binary mode). > > Other than that, the changes look ok to me, and make the methods easier > to read (imo) > > Cheers, > Henry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 4, 2010

Re: [Pharo-project] Fwd: October 2006 Agreement from Apple to VPRI regarding License changes

by StÃ©phane Ducasse

Thanks I added it in the svn repository and pass it to INRIA experts for feedback. Stef On Feb 4, 2010, at 9:44 PM, Torsten Bergmann wrote: > see > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144099… > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 4, 2010

Re: [Pharo-project] readOnlyFileNamed:do: vs. ...

by Henrik Sperre Johansen

On 03.02.2010 10:26, StÃ©phane Ducasse wrote: > Hi henrik > > if you get a chance to have a look at the slice I uploaded it would be good. > I like the idea that people have a look at other code, which is what we do when we integrate > now for my own code I always feel nervous :) > > Stef > Got time tonight, here's my comments: DigitalSignatureAlgorithm class >> testExamplesFromDisk May be better as a real test than as a class-side method? The method usage change seems fine though ;) FilePackage >> fromFileNamed: Should be inlined in the class-side method called the same, and removed. Only this method is ever called anyways, and it makes less sense to accept from... style initialization methods on the instances. MCVersionReader class >> file:streamDo: Could instead be inlined in versionFromFile which is the only sender, then removed. The way it's now, it's really only a MCVersionReader-specific alias for the exact same method :) MCVersionReader class >> versionFromFile: ^FileStream readOnlyFileNamed: fileName do: [:fileStream | self versionFromStream: fileStream] UUIDGenerator>>makeUnixSeed You set the stream to binary, there should be no need to set the converter as well (it won't be used in binary mode). Other than that, the changes look ok to me, and make the methods easier to read (imo) Cheers, Henry

Feb. 4, 2010

[Pharo-project] Fwd: October 2006 Agreement from Apple to VPRI regarding License changes

by Torsten Bergmann

see http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-February/144099… -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

Feb. 4, 2010