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

Re: [Pharo-project] A solution to manage units like inches and centimeters in Pharo?

by Marcus Denker

On Feb 22, 2013, at 4:45 PM, Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com> wrote: > Does something exists because I looked and don't find anything. > There is the old Units codeâ¦ http://www.squeaksource.com/Units.html I will move it to SmallatlkHub on the weekend. Marcus

Feb. 22, 2013

Re: [Pharo-project] A solution to manage units like inches and centimeters in Pharo?

by Frank Shearar

On 22 February 2013 15:45, Guillaume Larcheveque <guillaume.larcheveque(a)gmail.com> wrote: > Does something exists because I looked and don't find anything. Something like these? * http://map.squeak.org/package/b546b6af-984e-4e89-a7a5-875ce0435710 * http://map.squeak.org/package/8664cb28-916b-4e8a-8cd6-b6db73f5024c frank

Feb. 22, 2013

[Pharo-project] A solution to manage units like inches and centimeters in Pharo?

by Guillaume Larcheveque

Does something exists because I looked and don't find anything. -- *Guillaume Larcheveque*

Feb. 22, 2013

Re: [Pharo-project] Travis CI and Pharo 2.0 Was: Metacello issues on Pharo 2.0

by Tudor Girba

This is pretty cool. Doru On Wed, Feb 20, 2013 at 5:28 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi Dale: > > On 20 Feb 2013, at 16:15, Dale Henrichs wrote: > > > I have to admit that I haven't kept up with Pharo2.0 since last summer > when I couldn't use Pharo2.0 for development because of OsProcess issues. I > know that recently those issues have been cleared up, but I haven't had the > time to return to Pharo2.0 and check things out (I'm facing more issues > with getting PHaro2.0 to work with travis-ci, etc. so it will be a big > undertaking for me to fully support Pharo2.0). > > I have a working build with Travis. > Well, working in the sense that it executes my unit tests. > The tests actually fail for other reasons. > See https://travis-ci.org/smarr/LibGit > > I use basically the CI infrastructure provided by Pharo 2.0. Guess that's > Camillo's work. > https://github.com/smarr/LibGit/blob/master/.travis.yml > > > I happen to use a makefile: > > libgit.image: latest.image > $(NBCOG) -headless $< config > http://smalltalkhub.com/mc/StefanMarr/LibGit/main ConfigurationOfLibGit > --install=bleedingEdge > mv latest.image libgit.image > mv latest.changes libgit.changes > > LibGit-Core-Tests-Test.xml: libgit.image > $(NBCOG) -headless $< test --junit-xml-output LibGit-Core-Tests > > The only problem for the build status is to report the correct error code > to travis, I think. > > As I understand it, Travis doesn't actually care about parsing or > understanding test results, which is a pity. > > Best regards > Stefan > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- www.tudorgirba.com "Every thing has its own flow"

Feb. 22, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by phil＠highoctane.be

Sure, but this is not under refactorings in the menu. It is just that NautilusUI routes such requests to the NautilusRefactorings class. Maybe there is another place to store that. Or a need to refactor NautilusRefactorings into NautilusCommands (a true refactoring!) As I don't have a view on the design of that beast, I am at a loss here. Phil 2013/2/22 stephane ducasse <stephane.ducasse(a)free.fr>: > we should not put it under refactorings. > > > On Feb 21, 2013, at 10:54 AM, phil(a)highoctane.be wrote: > >> I added this one to NautilusRefactorings >> >> basicRenameMethodFor: aMethod >> >> | class selector category oldMethodName newMethodName oldSelector >> newSelector newMethod source parser | >> >> class := aMethod methodClass. >> oldSelector := aMethod selector. >> oldMethodName := oldSelector asString. >> category := aMethod category. >> >> (newMethodName := UITheme builder textEntry: 'New method name:' >> asString title: 'Rename ',oldMethodName asString, ' to...') ifNil: [ >> ^ nil ]. >> >> newSelector := newMethodName asSymbol. >> oldSelector = newSelector ifTrue: [^self]. >> source := class sourceCodeAt: oldSelector. >> >> "Replace selector in method source" >> (parser := class parserClass new) parseSelector: source. >> source := (newSelector asString), (source allButFirst: parser endOfLastToken). >> >> "Compile modified source" >> class compile: source classified: category. >> >> "Remove old selector" >> class removeSelector: oldSelector >> >> >> And changed the rename menu into the NautilusUI with >> refactoringMethodMenu: aBuilder >> <nautilusGlobalMethodMenu> >> | target | >> target := aBuilder model. >> target selectedMethod ifNil:[ ^ target ]. >> >> (aBuilder item: #'Refactoring') >> order: -100. >> >> (aBuilder item: #'Rename method (basic)') >> action: [ | scroll | >> scroll := target methodWidget vScrollValue. >> target refactor basicRenameMethodFor: target selectedMethod. >> target methodWidget vScrollValue: scroll ]; >> order: -95. >> >> (aBuilder item: #'Rename method (all)') >> keyText: 'r, m' if: Nautilus useOldStyleKeys not; >> keyText: 'r' if: Nautilus useOldStyleKeys; >> action: [ | scroll | >> scroll := target methodWidget vScrollValue. >> target refactor renameMethodFor: target selectedMethod. >> target methodWidget vScrollValue: scroll ]; >> order: -90; >> withSeparatorAfter >> >> .... >> >> I think you can get this in Slice #7560 >> >> So, I've got what I needed. Maybe someone knowing better can make this clean. >> >> Maybe there is a way to do this with the standard refactorings system, >> but it was beyond me to start understanding how to do that properly. >> (Altough it looks like pretty cool!) >> >> Phil >> >> >> 2013/2/21 Goubier Thierry <thierry.goubier(a)cea.fr>: >>> Le 20/02/2013 21:33, Benjamin a Ã©crit : >>>> >>>> On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse(a)free.fr >>>> <mailto:stephane.ducasse@free.fr>> wrote: >>>> >>>>> >>>>> On Feb 20, 2013, at 1:07 PM, Benjamin >>>>> <benjamin.vanryseghem.pharo(a)gmail.com >>>>> <mailto:benjamin.vanryseghem.pharo@gmail.com>> wrote: >>>>> >>>>>> There is actually no simple way to simply rename a method. >>>>>> We should maybe add one which keep track of the versions :) >>>>> >>>>> >>>>> sure there is: >>>>> click on the method >>>>> in the text pane change the selector of the method and compile. >>>> >>>> >>>> I am kind of aware of that :) >>>> >>>> But for a new comer, it's not obvious at all. >>>> And usually they first look in the menu and click on the first entry >>>> "matching" the need >>>> >>>> Ben >>> >>> >>> What about restricting the rename to the current package or class? With, >>> say, a box to tick to go system wide? >>> >>> (And a nice GUI, moose-like, showing on a color map how much of the system >>> the rename will impact :)) >>> >>> Thierry >>> -- >>> Thierry Goubier >>> CEA list >>> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >>> 91191 Gif sur Yvette Cedex >>> France >>> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >>> >> > >

Feb. 22, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by stephane ducasse

we should not put it under refactorings. On Feb 21, 2013, at 10:54 AM, phil(a)highoctane.be wrote: > I added this one to NautilusRefactorings > > basicRenameMethodFor: aMethod > > | class selector category oldMethodName newMethodName oldSelector > newSelector newMethod source parser | > > class := aMethod methodClass. > oldSelector := aMethod selector. > oldMethodName := oldSelector asString. > category := aMethod category. > > (newMethodName := UITheme builder textEntry: 'New method name:' > asString title: 'Rename ',oldMethodName asString, ' to...') ifNil: [ > ^ nil ]. > > newSelector := newMethodName asSymbol. > oldSelector = newSelector ifTrue: [^self]. > source := class sourceCodeAt: oldSelector. > > "Replace selector in method source" > (parser := class parserClass new) parseSelector: source. > source := (newSelector asString), (source allButFirst: parser endOfLastToken). > > "Compile modified source" > class compile: source classified: category. > > "Remove old selector" > class removeSelector: oldSelector > > > And changed the rename menu into the NautilusUI with > refactoringMethodMenu: aBuilder > <nautilusGlobalMethodMenu> > | target | > target := aBuilder model. > target selectedMethod ifNil:[ ^ target ]. > > (aBuilder item: #'Refactoring') > order: -100. > > (aBuilder item: #'Rename method (basic)') > action: [ | scroll | > scroll := target methodWidget vScrollValue. > target refactor basicRenameMethodFor: target selectedMethod. > target methodWidget vScrollValue: scroll ]; > order: -95. > > (aBuilder item: #'Rename method (all)') > keyText: 'r, m' if: Nautilus useOldStyleKeys not; > keyText: 'r' if: Nautilus useOldStyleKeys; > action: [ | scroll | > scroll := target methodWidget vScrollValue. > target refactor renameMethodFor: target selectedMethod. > target methodWidget vScrollValue: scroll ]; > order: -90; > withSeparatorAfter > > .... > > I think you can get this in Slice #7560 > > So, I've got what I needed. Maybe someone knowing better can make this clean. > > Maybe there is a way to do this with the standard refactorings system, > but it was beyond me to start understanding how to do that properly. > (Altough it looks like pretty cool!) > > Phil > > > 2013/2/21 Goubier Thierry <thierry.goubier(a)cea.fr>: >> Le 20/02/2013 21:33, Benjamin a Ã©crit : >>> >>> On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse(a)free.fr >>> <mailto:stephane.ducasse@free.fr>> wrote: >>> >>>> >>>> On Feb 20, 2013, at 1:07 PM, Benjamin >>>> <benjamin.vanryseghem.pharo(a)gmail.com >>>> <mailto:benjamin.vanryseghem.pharo@gmail.com>> wrote: >>>> >>>>> There is actually no simple way to simply rename a method. >>>>> We should maybe add one which keep track of the versions :) >>>> >>>> >>>> sure there is: >>>> click on the method >>>> in the text pane change the selector of the method and compile. >>> >>> >>> I am kind of aware of that :) >>> >>> But for a new comer, it's not obvious at all. >>> And usually they first look in the menu and click on the first entry >>> "matching" the need >>> >>> Ben >> >> >> What about restricting the rename to the current package or class? With, >> say, a box to tick to go system wide? >> >> (And a nice GUI, moose-like, showing on a color map how much of the system >> the rename will impact :)) >> >> Thierry >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> >

Feb. 22, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by phil＠highoctane.be

7560 2013/2/22 stephane ducasse <stephane.ducasse(a)free.fr>: > > On Feb 20, 2013, at 9:33 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > > On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse(a)free.fr> > wrote: > > > On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > wrote: > > There is actually no simple way to simply rename a method. > We should maybe add one which keep track of the versions :) > > > sure there is: > click on the method > in the text pane change the selector of the method and compile. > > > I am kind of aware of that :) > > > I know :) > > Now why not adding a bad menu item that nobody will ever use :) > > > But for a new comer, it's not obvious at all. > And usually they first look in the menu and click on the first entry > "matching" the need > > > Wellâ¦. > > stef

Feb. 22, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by stephane ducasse

> For me the issue is not so much whether there there is another way to rename, but that it is "an _unexpected_ refactoring in disguise" yes I hate it. Stef > > -ben > > stephane ducasse wrote: >> to rename a method without refactoring: just click on the method and in the method pan change its name and recompile >> >> Stef >> >> On Feb 20, 2013, at 11:25 AM, phil(a)highoctane.be wrote: >> >> >>> Yes, but the rename is *not* in the refactoring menu. It is *below* >>> the refactoring menu. >>> So, it is an unexpected refactoring in disguise... >>> >>> There was a simple rename in 1.4 I think. Maybe can we get that one >>> back (in 3.0 of course...) >>> >>> Phil >>> >>> 2013/2/20 Fernando Olivero <fernando.olivero(a)usi.ch>: >>> >>>> Hi, i had the same misconception once, but i recall Lukas pointed out >>>> that the refactoring engine is built on the original refactoring's >>>> from Fowler's book, and implemented in Smalltalk by Roberts and >>>> Johnson [1]. >>>> >>>> So the semantics of the refactoring are preserved in the implementation. >>>> >>>> If you just want a method rename, not a method refactoring rename, >>>> maybe is best have an option for that in the menu [2]. >>>> >>>> >>>> Fernando >>>> >>>> [1] http://st-www.cs.illinois.edu/users/droberts/tapos.pdf >>>> [2] or use a better widget for editing methods, than a simple code >>>> editor within the pane of the browser, as in Gaucho..which i'm working >>>> on. >>>> >>>> On Wed, Feb 20, 2013 at 11:03 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> and you are right, scoped browsing is a very powerful feature that can be tricky to newcomers... but at least now with nautilus it is there, as first option (in OB it was there, but more or less hidden in a submenu)... >>>>> It is a small step, but is something... and well... we can improve in next releases, one step at a time :) >>>>> >>>>> Esteban >>>>> >>>>> On Feb 20, 2013, at 10:52 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>> >>>>> >>>>>> Yes, thanks, I figured that out. A newcomer wouldn't... and renaming >>>>>> is pretty common. >>>>>> >>>>>> What will happen is that people will remove the method and recreate a new one. >>>>>> Version history will then go away. >>>>>> >>>>>> Or is the system smart enough to find out about these things? >>>>>> >>>>>> Phil >>>>>> >>>>>> 2013/2/20 Esteban Lorenzano <estebanlm(a)gmail.com>: >>>>>> >>>>>>> hi, >>>>>>> >>>>>>> yes, you are right.. but that is a "nice to have", not a bug... so it will wait to 3.0 :) >>>>>>> In the mean time, you can do a scoped rename: you select the packages you want, then right click and "browse scoped", then you apply you rename, and it will apply the refactor in the scoped selection, not all the image. >>>>>>> >>>>>>> cheers, >>>>>>> Esteban >>>>>>> >>>>>>> On Feb 20, 2013, at 10:21 AM, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>> >>>>>>> >>>>>>>> Well, look at the screenshot then tell me that this is what I want. >>>>>>>> >>>>>>>> It is definitively *not* what I want. Especially unchecking that >>>>>>>> endless list of methods. >>>>>>>> >>>>>>>> Adding a "Uncheck all" "Check all" button to the Changes Browser list >>>>>>>> would help... >>>>>>>> >>>>>>>> Regards >>>>>>>> Phil >>>>>>>> >>>>>>>> 2013/2/20 Camillo Bruni <camillobruni(a)gmail.com>: >>>>>>>> >>>>>>>>> there is 1 certain bug, that is that you cannot see the changes of the refactoring: >>>>>>>>> >>>>>>>>> https://code.google.com/p/pharo/issues/detail?id=7547 >>>>>>>>> >>>>>>>>> the rest I would consider a bug as well. But in the terms of refactoring it might >>>>>>>>> be "valid". It does preserve behavior by renaming also all implementors. >>>>>>>>> >>>>>>>>> How about this reasoning: >>>>>>>>> >>>>>>>>> Rename method >>>>>>>>> => rename all senders (since you refactor) >>>>>>>>> => you have to rename all implementors as well since you renamed all send sites >>>>>>>>> otherwise you'll run for sure into a DNU >>>>>>>>> >>>>>>>>> I think I just convinced myself :D >>>>>>>>> >>>>>>>>> On 2013-02-20, at 09:26, "phil(a)highoctane.be" <phil(a)highoctane.be> wrote: >>>>>>>>> >>>>>>>>>> I was doing a Refactoring>rename of the initialize method in Nautilus >>>>>>>>>> for the ClassMethodBrowser and then the changes browser proposed me to >>>>>>>>>> change all classes with initialize. WTF? >>>>>>>>>> >>>>>>>>>> Phil >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> <PharoScreenshot.3.png> >>>>>>>> >>>>>>> >>>>> >> >> >> >> > >

Feb. 22, 2013

Re: [Pharo-project] Weird behavior in Nautilus when doing a method rename

by stephane ducasse

On Feb 20, 2013, at 9:33 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On Feb 20, 2013, at 8:43 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> >> On Feb 20, 2013, at 1:07 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >> >>> There is actually no simple way to simply rename a method. >>> We should maybe add one which keep track of the versions :) >> >> sure there is: >> click on the method >> in the text pane change the selector of the method and compile. > > I am kind of aware of that :) I know :) Now why not adding a bad menu item that nobody will ever use :) > But for a new comer, it's not obvious at all. > And usually they first look in the menu and click on the first entry "matching" the need Wellâ¦. stef

Feb. 22, 2013

Re: [Pharo-project] Does ZnHTTPSTests>>#testGetPharoVersion actually run on the CI servers ?

by Sven Van Caekenberghe

On 22 Feb 2013, at 13:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > On 22 Feb 2013, at 12:13, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> OK, good ;-) >> >> What about the URL ? >> >> It is now >> >> https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… >> >> it used to be >> >> https://ci.lille.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?x… >> >> Is this call/URL still possible or has it changed ? > > Without the /text() the URL https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… works, with it there is a security exception: > > $ curl https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… > <description>2.0 #20563</description> > > $ curl "https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/…" > <html><head><title>Error 403</title></head><body bgcolor="#ffffff"><h1>Status Code: 403</h1>Exception: primitive XPath result sets forbidden; can use -Dhudson.model.Api.INSECURE=true if you run without security<br>Stacktrace: <pre>(none) > </pre><br><hr size="1" width="90%"><i>Generated by Winstone Servlet Engine v0.9.10 at Fri Feb 22 13:06:16 CET 2013</i></body></html> > > I guess the test can run without /text() unless someone can explain what is going onâ¦ --- Name: Zinc-Zodiac-SvenVanCaekenberghe.25 Author: SvenVanCaekenberghe Time: 22 February 2013, 3:04:30.18 pm UUID: b52e2249-16bc-46af-9c11-688fda41ac6d Ancestors: Zinc-Zodiac-SvenVanCaekenberghe.24 Patch ZnHTTPSTests>>#testGetPharoVersion again because the underlying semantics of the URL being tested have changed - no longer use /text() in the XPath query --- ZnHTTPSTests>>#testGetPharoVersion | client lastBuildVersion version | self ensureSocketStreamFactory. self isNativeSSLPluginPresent ifFalse: [ ^ self ]. lastBuildVersion := (client := ZnClient new) beOneShot; get: 'https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/…'. self assert: client isSuccess. self assert: client response contentType equals: ZnMimeType applicationXml. self assert: client response contentLength > 0. self assert: lastBuildVersion notNil. self assert: lastBuildVersion isString. self assert: lastBuildVersion size > 0. version := (lastBuildVersion copyAfter: $>) copyUpTo: $<. self deny: version isEmpty Over the WE I'll add an issue to update some Zn packages. >> Sven >> >> On 22 Feb 2013, at 12:07, Camillo Bruni <camillobruni(a)gmail.com> wrote: >> >>> It is failing (only now?) >>> >>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/lastCompletedBuild/testReport/ >>> >>> ;) >>> >>> On 2013-02-22, at 12:04, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> Hi, >>>> >>>> When testing in #20561 I noticed that ZnHTTPSTests>>#testGetPharoVersion consistently fails for me (Mac OS X, NBCog VM), probably because the URL is wrong - this is a function/regression test on https://ci.inria.fr/pharo/job/Pharo-2.0/lastSuccessfulBuild/api/xml?xpath=/… >>>> >>>> My point is that I don't see that failing on the CI servers, but maybe I looked in the wrong places. >>>> >>>> The test code does contain a >>>> >>>> self isNativeSSLPluginPresent ifFalse: [ ^ self ]. >>>> >>>> so it is possible that the test is skipped. >>>> >>>> But if that test is skipped, many more are skipped as well, and that would be not-goodâ¢. >>>> >>>> Sven >>>> >>>> -- >>>> Sven Van Caekenberghe >>>> http://stfx.eu >>>> Smalltalk is the Red Pill >>>> >>> >> >

Feb. 22, 2013