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

Re: [Pharo-project] A matter with Delays

by Sven Van Caekenberghe

Yes, I think you are right: the ambiguity is plain wrong, and even then not saving and continuing them sounds reasonable. But what about the inverse: you schedule something that should happen every hour or every day, you save/restart the image and with the new approach these would all run immediately, right ? So not only would you kill delays that are too short (reasonable), but collapse the longer ones. In terms of design: I think the different behaviors should be implemented with different objects. On 21 Feb 2013, at 12:28, Igor Stasenko <siguctua(a)gmail.com> wrote: > Hi. > > There is one thing which is IMO an over-engineering artifact: > - when system goes down (image shutdown), all currently scheduled > delays are "saved" > and then when image starting up they are rescheduled again to keep > waiting what time is left for delay.. > > But the problem is that it does not takes into account the total time > an image was frozen, and the requirement is quite ambiguous: > > - if you put a process on a delay for 5 minutes, then immediately > save image, and then restart it 10 minutes (or 1 year) after, > should this delay keep waiting for 4 +x seconds which is left? Or > should we consider this delay as utterly expired? > (and as you can see, the answer is different, if we counting time > using real, physical time, or just image uptime). > > And why counting image uptime? Consider use cases, like connection > timeout.. it is all about > real time , right here , right now.. will it matter to get socket > connection timeout error when you restart some image 1 year after? > Please, give me a scenario, which will illustrate that we cannot live > without it and should count image uptime for delays, because i can't > find one. > > If not, then to my opinion, and to simplify all logic inside delay > code, i would go straight and declare following: > - when new image session starts, all delays, no matter for how long > they are scheduled to wait are considered expired (and therefore all > waiting processes > is automatically resumed). > > Because as tried to demonstrate, the meaning of delay which spans over > multiple image sessions is really fuzzy and i would be really > surprised to find a code > which relies on such behavior. > > This change will also can be helpful with terminating all processes > which were put on wait for too long (6304550344559763 milliseconds) by > mistake or such. > > > -- > Best regards, > Igor Stasenko. >

Feb. 21, 2013

[Pharo-project] A matter with Delays

by Igor Stasenko

Hi. There is one thing which is IMO an over-engineering artifact: - when system goes down (image shutdown), all currently scheduled delays are "saved" and then when image starting up they are rescheduled again to keep waiting what time is left for delay.. But the problem is that it does not takes into account the total time an image was frozen, and the requirement is quite ambiguous: - if you put a process on a delay for 5 minutes, then immediately save image, and then restart it 10 minutes (or 1 year) after, should this delay keep waiting for 4 +x seconds which is left? Or should we consider this delay as utterly expired? (and as you can see, the answer is different, if we counting time using real, physical time, or just image uptime). And why counting image uptime? Consider use cases, like connection timeout.. it is all about real time , right here , right now.. will it matter to get socket connection timeout error when you restart some image 1 year after? Please, give me a scenario, which will illustrate that we cannot live without it and should count image uptime for delays, because i can't find one. If not, then to my opinion, and to simplify all logic inside delay code, i would go straight and declare following: - when new image session starts, all delays, no matter for how long they are scheduled to wait are considered expired (and therefore all waiting processes is automatically resumed). Because as tried to demonstrate, the meaning of delay which spans over multiple image sessions is really fuzzy and i would be really surprised to find a code which relies on such behavior. This change will also can be helpful with terminating all processes which were put on wait for too long (6304550344559763 milliseconds) by mistake or such. -- Best regards, Igor Stasenko.

Feb. 21, 2013

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

by phil＠highoctane.be

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. 21, 2013

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

by Goubier Thierry

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. 21, 2013

Re: [Pharo-project] Continuing weirdness with SS3.gemstone.com and Monticello in Pharo 2.0

by phil＠highoctane.be

Cmd-Alt-Esc and Pharo kill is my not so welcome friend on OSX. BTW, the VM feels speedier on Windows (XP and 7 here) than on OSX. Is there anyone experiencing this as well? Phil 2013/2/21 Guillermo Polito <guillermopolito(a)gmail.com>: > > > On Thu, Feb 21, 2013 at 5:18 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> when image freezes and not responsible anymore, >> VM can still respond to >> >> kill -SIGUSR1 <vm-pid> >> > > Hmm, not in the Cocoa Vm :(. The process gets killed... > >> >> which will print the stack trace on console. >> >> this can help with determining the cause of problem. >> >> -- >> Best regards, >> Igor Stasenko. >> >

Feb. 21, 2013

Re: [Pharo-project] Continuing weirdness with SS3.gemstone.com and Monticello in Pharo 2.0

by Guillermo Polito

On Thu, Feb 21, 2013 at 5:18 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > when image freezes and not responsible anymore, > VM can still respond to > > kill -SIGUSR1 <vm-pid> > > Hmm, not in the Cocoa Vm :(. The process gets killed... > which will print the stack trace on console. > > this can help with determining the cause of problem. > > -- > Best regards, > Igor Stasenko. > >

Feb. 21, 2013

Re: [Pharo-project] Metacello issues on Pharo 2.0

by Christophe Demarey

Dale we run the tests simply rewriting runCase as runCase | original | (self doSilently) ifFalse: [ ^super runCase ]. original := MetacelloPlatform current bypassGoferLoadUpdateCategories. [ MetacelloPlatform current bypassGoferLoadUpdateCategories: true. ^ SystemAnnouncer uniqueInstance suspendAllWhile: [ super runCase ] ensure: [ MetacelloPlatform current bypassGoferLoadUpdateCategories: original ] but it seems that we do not have the same behavior between the two runCase | original | (self doSilently) ifFalse: [ ^super runCase ]. original := MetacelloPlatform current bypassGoferLoadUpdateCategories. [ MetacelloPlatform current bypassGoferLoadUpdateCategories: true. ^ super runCase ] ensure: [ MetacelloPlatform current bypassGoferLoadUpdateCategories: original ] So we will run all the tests Stef

Feb. 21, 2013

Re: [Pharo-project] Metacello issues on Pharo 2.0

by Christophe Demarey

Hi Dale Sure no problem was tired and nervous because Metacello is key for us. I'm sitting with christophe to check. Information that can interest you - on the repository of Pharo the Metacello-Core was fixed to handle FileReference Now I do not know how you want to manage it for your bootstrap. let us know how you want that we proceed. - for the tests (not version 10.32 that I cannot load - I will have a look at profStef to make it 2.0 aware I guess that this is that the problem) runCase refers to SystemNotifier we have to check how we control silently the announcement of the new announcer. Probably SystemAnnouncer uniqueInstance suspendAllWhile: For the Toolbox problem Christophe checked the version of '1.0-beta.31.1.5' since this is the latest stable version spec package: 'Metacello-Base' with: 'Metacello-Base-DaleHenrichs.19'; -> Metacello-Base-MarcusDenker.20 (no difference) package: 'Metacello-Core' with: 'Metacello-Core-dkh.492'; -> Metacello-Core-MarcusDenker.494 (handle FileSystem package: 'Metacello-MC' with: 'Metacello-MC-dkh.664'; -> Metacello-MC-StephaneDucasse.666 (apparently we remove the versions accesssor => look really suspicious) package: 'Metacello-Reference' with: 'Metacello-Reference-DaleHenrichs.31'; package: 'Metacello-Tutorial' with: 'Metacello-Tutorial-dkh.25'; package: 'OB-Metacello' with: 'OB-Metacello-dkh.82'; package: 'Metacello-TestsReference' with: 'Metacello-TestsReference-DaleHenrichs.17'; package: 'Metacello-TestsCore' with: 'Metacello-TestsCore-DaleHenrichs.14'; package: 'Metacello-TestsMC' with: 'Metacello-TestsMC-dkh.351'; package: 'Metacello-TestsTutorial' with: 'Metacello-TestsTutorial-dkh.33'; package: 'Metacello-ToolBox' with: 'Metacello-ToolBox-dkh.130' -> Metacello-ToolBox-MarcusDenker.135 here this is strange because the version of the toolbox in Pharo is based on 135 134 133 132 131 127 126 .... so should we take another version of the toolbox? May be there was a mistake from our side to take a wrong branch. In particular neither version of configurationClasses work in pharo configurationClasses "Return a set of the Metacello configuration classes that have been loaded into the image." <apiDocumentation> ^ MetacelloProjectRegistration configurationClasses configurationClasses "Return a set of the Metacello configuration classes that have been loaded into the image." <apiDocumentation> self flag: 'more work needed about MetacelloProjectRegistration'. ^ Array streamContents: [ :s| SystemNavigation default allClassesDo: [ :cls| (cls name beginsWith: 'ConfigurationOf') ifTrue: [ s nextPut: cls ]]] So this means that we do not know what to do but Christophe cannot work on 2.0 for versioner. Stef & Christophe > Stef, > > AFAIK, this is the first report of any bugs with Metacello since September... just saying.... > > Dale > > ----- Original Message ----- > | From: "stephane ducasse" <stephane.ducasse(a)free.fr> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Wednesday, February 20, 2013 11:53:28 AM > | Subject: Re: [Pharo-project] Metacello issues on Pharo 2.0 > | > | > | > Metacello is perfectly well maintained, and runs on a number of > | > Smalltalks. > | > | I do not know. If Dale did not had a look since this summer this is 8 months > | ago. > | I have no problem that this would happen. I just want to know because > | we want to build all the validation of packages on top of metacello. > | > | > It broke on Pharo 2.0 because things changed too quickly, > | > too quickly for Dale to keep up. > | > | Probably. But I do not think so. > | > | > What would be vastly more > | > constructive than implying that Dale has abandoned Metacello would be > | > applying some Pharo effort towards making it work again on 2.0. > | > | Frank I spent a lot of time pushing Metacello, christophe is working on a > | tool > | so that everybody can produce more easily configuration. > | > | Now my question is still valid. I just want to know because my time is > | counted > | and christophe is trying to understand metacello since some time and we > | should > | move forward. > | > | Stef > | > | > > | > frank > | > > | >> Stef > | >> > | >> > | >> > | >> > | >> On Feb 15, 2013, at 3:09 PM, Christophe Demarey > | >> <Christophe.Demarey(a)inria.fr> wrote: > | >> > | >> Hi all, > | >> > | >> I have issues with Metacello on Pharo 2.0 > | >> > | >> If I load and run tests for the version used in Pharo1.4, it gives: > | >> (ConfigurationOfMetacello project version: '1.0-beta.31.1.4') load: > | >> 'Tests' > | >> > | >> <Capture dâÃ©cran 2013-02-15 Ã 14.45.15.png> > | >> > | >> Metacello packages shipped with Pharo 2.0 are all packages derived from > | >> the > | >> latest stable Metacello baseline (1.0-beta.31.1.5) except the > | >> MetacelloToolBox. > | >> If I load and run tests packages with version described in the latest > | >> stable > | >> Metacello baseline (1.0-beta.31.1.5), i.e. : > | >> > | >> Metacello-TestsCore-DaleHenrichs.14 and > | >> Metacello-TestsMC-dkh.351, > | >> > | >> it gives (Pharo 2.0 #20547): > | >> <Capture dâÃ©cran 2013-02-15 Ã 14.55.36.png> > | >> > | >> So, it seems there are some problems. Do we use the rigth versions of > | >> Metacello packages? > | >> > | >> Regards, > | >> Christophe. > | >> > | >> > | >> > | > > | >

Feb. 21, 2013

[Pharo-project] projects to migrate/test on 2.0

by Christophe Demarey

Hi stef here is a list of the project we should validate for 2.0 Gofer spec project: 'Gofer Core' with: [ spec className: 'ConfigurationOfGofer'; versionString: '1.0-baseline'; loads: #('Core'); file: 'ConfigurationOfGofer'; repository: 'http://www.squeaksource.com/MetacelloRepository'; repository: 'http://seaside.gemstone.com/ss/metacello' ]; Prof Stef spec className: 'ConfigurationOfProfStef'; versionString: '1.0-baseline'; file: 'ConfigurationOfProfStef'; repository: 'http://www.squeaksource.com/MetacelloRepository'

Feb. 21, 2013

Re: [Pharo-project] please test 2.0

by Sven Van Caekenberghe

Hi Yanni, On 20 Feb 2013, at 22:23, Yanni Chiu <yanni(a)rogers.com> wrote: > On 19/02/13 12:22 PM, Esteban Lorenzano wrote: >> >> We are almost there for the release, but we still need a little >> effort more. Would be terrific if everyone of you took the latest 2.0 >> image and test it with your usual workflows (we cannot imagine all, >> they are infinite :) > > I usually keep a build tracking the upcoming Pharo release, but when I tried to do it during early Pharo-2.0 development, the code was not stable. Then I never got back to it. Here's what happened, when I tried to build with the newest version. Thanks for testing, thanks for the feedback. > First try: "Notice: Your VM is too old for this image. Please download the latest VM." > > Get latest coglinux, from http://www.mirandabanda.org/files/Cog/VM/ > > Second try: "Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for /lib/i686/cmov/libc.so.6 ..." > > Patch squeak shell script with a case for "/lib/i686/cmov/libc*" > > Third try: No complaint about LD_LIBRARY_PATH, but still says "VM is too old ..." > > Switch to a CogVM (early version of PharoVM) that was lying around. This is a bit to be expected when you use older VMs, the one-click or designated Pharo (NBCog) VMs would have prevented these issues. > More tries: > > Can't load Seaside. Update to newer seaside31.st script from https://github.com/renggli/builder/tree/master/scripts > > Magritte3/Pier3 has deprecations and undefined class. > > Revert to trying Seaside30. Get: > *** Warning: Warning: This package depends on the following classes: > BlockContext > You must resolve these dependencies before you will be able to load these definitions: > renderOn: > > Go back to trying Magritte3/Pier3 on Seaside31 again. Ignore the deprecations, find: FileSystem-Legacy, at: http://smalltalkhub.com/mc/dh83/fisleg/main > Can now load Pier3 into Pharo-20558. > > Figure out where to get the latest Zinc-Seaside. (Found at http://www.squeaksource.com/ZincHTTPComponents) Start Seaside, go to Pier link, get deprecation warnings about #includesSubString:. Try to disable warnings in System Settings. Still get warnings in webpage. Change to #includesSubString: to not call #deprecated:on:. Now, can see default Pier page. It will be a while before all third party packages are properly ported to Pharo 2.0. Many are, but that depends mostly on their authors. Now, Seaside 3.1 and friends will load and work proper on Pharo 2.0, it is just not an out-of-the-box it-just-works experience. The #includesSub[S|s]tring: issue is easy to solve, it just requires a decision on the part of the Seaside developers. See http://forum.world.st/Broken-build-because-of-use-of-includesSubstring-tt46… There also seem to be some technical reasons why a Metacello Configuration is not yet there. I guess that user pressure, once 2.0 is out, is the only thing that will make a difference. These things sometimes go slowly. This is all open source. > Next step, try to load my custom codeâ¦ Let us know how it goes ! Regards, Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Feb. 21, 2013