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

Re: [Pharo-dev] Calypso wishlist

by Nicolas Cellier

Then you might have used kind of named block params like MyClass >> [foo: aFoo bar: aBar | self foo: aFoo; bar: aBar] Le 8 fÃ©vr. 2018 20:11, "Stephane Ducasse" <stepharo.self(a)gmail.com> a Ã©crit : > Hi ben > > This is not what I asked for :). In nautilus you do not have to switch > mode to define a method. > > Now about your proposal. I would like to be able the type tonel method > definition > > SomeClass >> echo: anObject [ > ^ 42 > ] > > Tonel represents what I want for methods. > This way students could just type nearly as in the books and I would > change the book to reflect this. > And people can decide either to type all the time the class or now. > > Stef > > > > > On Thu, Feb 8, 2018 at 6:28 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > > > > On 9 February 2018 at 00:45, Ben Coman <btc(a)openinworld.com> wrote: > >> On 8 February 2018 at 16:22, Stephane Ducasse <stepharo.self(a)gmail.com> > >> wrote: > >>> Hi denis > >>> > >>> - I would like to be able to define a method even in the class pane > >>> and that the system detects it automatically. > >> > >> It would be nice to do it from anywhere including Playground with > >> something like... > >> Classname >> #methodname >> [ method source here ] > >> > >> So I just tired a quick experiment... > >> > >> Object subclass: #SomeClass > >> instanceVariableNames: '' > >> classVariableNames: '' > >> package: 'MethodBuilderExperiment' > >> > >> On SomeClass defined method... > >> existingMethod > >> ^1 > >> > >> On CompiledMethod defined method... > >> >> blockClosure > >> | newSource | > >> newSource := self methodNode selector, String crlf, > >> blockClosure sourceNode newSource allButFirst allButLast. > >> self methodClass compile: newSource > >> > >> > >> Now each of the following lines can be evaluated... > >> > >> SomeClass existingMethod "==> 1" > >> SomeClass >> #existingMethod >> [ ^42]. > >> SomeClass existingMethod "==> 42" > > > > That should have been. > > > > SomeClass new existingMethod "==> 1" > > SomeClass >> #existingMethod >> [ ^42]. > > SomeClass new existingMethod "==> 42" > > > >> > >> > >> > >> And another experiment... > >> > >> Object subclass: #MethodBuilder > >> instanceVariableNames: 'methodClass methodSelector' > >> classVariableNames: '' > >> package: 'MethodBuilderExperiment' > >> > >> On MethodBuilder defined method... > >> class: aClass selector: aSelector > >> methodClass := aClass. > >> methodSelector := aSelector. > >> > >> On MethodBuilder defined method... > >> >> blockClosure > >> |newSource| > >> newSource := methodSelector, String crlf, > >> blockClosure sourceNode newSource allButFirst allButLast. > >> methodClass compile: newSource > >> > >> On Behaviour re-defined method... > >> compiledMethodAt: selector > >> ^ self methodDict at: selector ifAbsent: > >> [ MethodBuilder new class: self selector: selector > ] > >> > >> > >> Now each of the following lines can be evaluated... > >> > >> Someclass noMethod "==> error... Instance of SomeClass class did not > >> understand #noMethod" > >> SomeClass >> #noMethod >> [ ^42 ]. > >> Someclass noMethod "==> 42" > > > > And should have been... > > Someclass new noMethod "==> error... Instance of SomeClass class did not > > understand #noMethod" > > SomeClass >> #noMethod >> [ ^42 ]. > > Someclass new noMethod "==> 42" > > > > > > I see that is a bit problematic for keyword messages, but with a tweak... > > > > On MethodBuilder defined... > > >> blockClosure > > |newSource| > > methodSelector isArray > > ifFalse: [ newSource := methodSelector ] > > ifTrue: [ > > newSource := ''. > > methodSelector do: [ :token | newSource := newSource , token asString, ' > ' ] > > ]. > > newSource := newSource, String crlf, > > blockClosure sourceNode newSource allButFirst allButLast. > > methodClass compile: newSource > > > > > > now the following can be evaluated... > > > > SomeClass >>#(echo: anObject) >> [ ^anObject ]. > > SomeClass new echo: 'doyoulike'. "==> doyoulike" > > > > > > Another form to define a method might be... > > SomeClass >> [ echo: anObject > > ^anObject ] > > > > I think that looks better, but would require a loosening of block syntax. > > > > cheers -ben > > > >>> - Then we are starting to reverse engineering the ecompletion system > >>> and I'm learning it. > >>> I would like to know if Calypso can communicate with ecompletion the > >>> fact that we are defining a method. Then I have to check how the > >>> system can know that we are typing method argument when defining the > >>> signature but I think that this is not related to calypso. > >>> > >>> Stef > >>> > > > >

Feb. 8, 2018

Re: [Pharo-dev] [Seaside-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by Sean P. DeNigris

Pharo Smalltalk Developers mailing list wrote > I have no idea why this is happening I had a similar situation due to a deprecation warning generated by my startup script. I aborted from the debugger, and the image worked normally, but when I saved, quit and tried to restart the image, it wouldn't open (VM icon in list of active apps, but window never appeared macOS high Sierra). ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 8, 2018

Re: [Pharo-dev] Calypso wishlist

by Stephane Ducasse

Hi ben This is not what I asked for :). In nautilus you do not have to switch mode to define a method. Now about your proposal. I would like to be able the type tonel method definition SomeClass >> echo: anObject [ ^ 42 ] Tonel represents what I want for methods. This way students could just type nearly as in the books and I would change the book to reflect this. And people can decide either to type all the time the class or now. Stef On Thu, Feb 8, 2018 at 6:28 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 9 February 2018 at 00:45, Ben Coman <btc(a)openinworld.com> wrote: >> On 8 February 2018 at 16:22, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >>> Hi denis >>> >>> - I would like to be able to define a method even in the class pane >>> and that the system detects it automatically. >> >> It would be nice to do it from anywhere including Playground with >> something like... >> Classname >> #methodname >> [ method source here ] >> >> So I just tired a quick experiment... >> >> Object subclass: #SomeClass >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'MethodBuilderExperiment' >> >> On SomeClass defined method... >> existingMethod >> ^1 >> >> On CompiledMethod defined method... >> >> blockClosure >> | newSource | >> newSource := self methodNode selector, String crlf, >> blockClosure sourceNode newSource allButFirst allButLast. >> self methodClass compile: newSource >> >> >> Now each of the following lines can be evaluated... >> >> SomeClass existingMethod "==> 1" >> SomeClass >> #existingMethod >> [ ^42]. >> SomeClass existingMethod "==> 42" > > That should have been. > > SomeClass new existingMethod "==> 1" > SomeClass >> #existingMethod >> [ ^42]. > SomeClass new existingMethod "==> 42" > >> >> >> >> And another experiment... >> >> Object subclass: #MethodBuilder >> instanceVariableNames: 'methodClass methodSelector' >> classVariableNames: '' >> package: 'MethodBuilderExperiment' >> >> On MethodBuilder defined method... >> class: aClass selector: aSelector >> methodClass := aClass. >> methodSelector := aSelector. >> >> On MethodBuilder defined method... >> >> blockClosure >> |newSource| >> newSource := methodSelector, String crlf, >> blockClosure sourceNode newSource allButFirst allButLast. >> methodClass compile: newSource >> >> On Behaviour re-defined method... >> compiledMethodAt: selector >> ^ self methodDict at: selector ifAbsent: >> [ MethodBuilder new class: self selector: selector ] >> >> >> Now each of the following lines can be evaluated... >> >> Someclass noMethod "==> error... Instance of SomeClass class did not >> understand #noMethod" >> SomeClass >> #noMethod >> [ ^42 ]. >> Someclass noMethod "==> 42" > > And should have been... > Someclass new noMethod "==> error... Instance of SomeClass class did not > understand #noMethod" > SomeClass >> #noMethod >> [ ^42 ]. > Someclass new noMethod "==> 42" > > > I see that is a bit problematic for keyword messages, but with a tweak... > > On MethodBuilder defined... > >> blockClosure > |newSource| > methodSelector isArray > ifFalse: [ newSource := methodSelector ] > ifTrue: [ > newSource := ''. > methodSelector do: [ :token | newSource := newSource , token asString, ' ' ] > ]. > newSource := newSource, String crlf, > blockClosure sourceNode newSource allButFirst allButLast. > methodClass compile: newSource > > > now the following can be evaluated... > > SomeClass >>#(echo: anObject) >> [ ^anObject ]. > SomeClass new echo: 'doyoulike'. "==> doyoulike" > > > Another form to define a method might be... > SomeClass >> [ echo: anObject > ^anObject ] > > I think that looks better, but would require a loosening of block syntax. > > cheers -ben > >>> - Then we are starting to reverse engineering the ecompletion system >>> and I'm learning it. >>> I would like to know if Calypso can communicate with ecompletion the >>> fact that we are defining a method. Then I have to check how the >>> system can know that we are typing method argument when defining the >>> signature but I think that this is not related to calypso. >>> >>> Stef >>> >

Feb. 8, 2018

Re: [Pharo-dev] Calypso wishlist

by Ben Coman

On 9 February 2018 at 00:45, Ben Coman <btc(a)openinworld.com> wrote: > On 8 February 2018 at 16:22, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> Hi denis >> >> - I would like to be able to define a method even in the class pane >> and that the system detects it automatically. > > It would be nice to do it from anywhere including Playground with > something like... > Classname >> #methodname >> [ method source here ] > > So I just tired a quick experiment... > > Object subclass: #SomeClass > instanceVariableNames: '' > classVariableNames: '' > package: 'MethodBuilderExperiment' > > On SomeClass defined method... > existingMethod > ^1 > > On CompiledMethod defined method... > >> blockClosure > | newSource | > newSource := self methodNode selector, String crlf, > blockClosure sourceNode newSource allButFirst allButLast. > self methodClass compile: newSource > > > Now each of the following lines can be evaluated... > > SomeClass existingMethod "==> 1" > SomeClass >> #existingMethod >> [ ^42]. > SomeClass existingMethod "==> 42" That should have been. SomeClass new existingMethod "==> 1" SomeClass >> #existingMethod >> [ ^42]. SomeClass new existingMethod "==> 42" > > > > And another experiment... > > Object subclass: #MethodBuilder > instanceVariableNames: 'methodClass methodSelector' > classVariableNames: '' > package: 'MethodBuilderExperiment' > > On MethodBuilder defined method... > class: aClass selector: aSelector > methodClass := aClass. > methodSelector := aSelector. > > On MethodBuilder defined method... > >> blockClosure > |newSource| > newSource := methodSelector, String crlf, > blockClosure sourceNode newSource allButFirst allButLast. > methodClass compile: newSource > > On Behaviour re-defined method... > compiledMethodAt: selector > ^ self methodDict at: selector ifAbsent: > [ MethodBuilder new class: self selector: selector ] > > > Now each of the following lines can be evaluated... > > Someclass noMethod "==> error... Instance of SomeClass class did not > understand #noMethod" > SomeClass >> #noMethod >> [ ^42 ]. > Someclass noMethod "==> 42" And should have been... Someclass new noMethod "==> error... Instance of SomeClass class did not understand #noMethod" SomeClass >> #noMethod >> [ ^42 ]. Someclass new noMethod "==> 42" I see that is a bit problematic for keyword messages, but with a tweak... On MethodBuilder defined... >> blockClosure |newSource| methodSelector isArray ifFalse: [ newSource := methodSelector ] ifTrue: [ newSource := ''. methodSelector do: [ :token | newSource := newSource , token asString, ' ' ] ]. newSource := newSource, String crlf, blockClosure sourceNode newSource allButFirst allButLast. methodClass compile: newSource now the following can be evaluated... SomeClass >>#(echo: anObject) >> [ ^anObject ]. SomeClass new echo: 'doyoulike'. "==> doyoulike" Another form to define a method might be... SomeClass >> [ echo: anObject ^anObject ] I think that looks better, but would require a loosening of block syntax. cheers -ben >> - Then we are starting to reverse engineering the ecompletion system >> and I'm learning it. >> I would like to know if Calypso can communicate with ecompletion the >> fact that we are defining a method. Then I have to check how the >> system can know that we are typing method argument when defining the >> signature but I think that this is not related to calypso. >> >> Stef >>

Feb. 8, 2018

Re: [Pharo-dev] Calypso wishlist

by Ben Coman

On 8 February 2018 at 16:22, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi denis > > - I would like to be able to define a method even in the class pane > and that the system detects it automatically. It would be nice to do it from anywhere including Playground with something like... Classname >> #methodname >> [ method source here ] So I just tired a quick experiment... Object subclass: #SomeClass instanceVariableNames: '' classVariableNames: '' package: 'MethodBuilderExperiment' On SomeClass defined method... existingMethod ^1 On CompiledMethod defined method... >> blockClosure | newSource | newSource := self methodNode selector, String crlf, blockClosure sourceNode newSource allButFirst allButLast. self methodClass compile: newSource Now each of the following lines can be evaluated... SomeClass existingMethod "==> 1" SomeClass >> #existingMethod >> [ ^42]. SomeClass existingMethod "==> 42" And another experiment... Object subclass: #MethodBuilder instanceVariableNames: 'methodClass methodSelector' classVariableNames: '' package: 'MethodBuilderExperiment' On MethodBuilder defined method... class: aClass selector: aSelector methodClass := aClass. methodSelector := aSelector. On MethodBuilder defined method... >> blockClosure |newSource| newSource := methodSelector, String crlf, blockClosure sourceNode newSource allButFirst allButLast. methodClass compile: newSource On Behaviour re-defined method... compiledMethodAt: selector ^ self methodDict at: selector ifAbsent: [ MethodBuilder new class: self selector: selector ] Now each of the following lines can be evaluated... Someclass noMethod "==> error... Instance of SomeClass class did not understand #noMethod" SomeClass >> #noMethod >> [ ^42 ]. Someclass noMethod "==> 42" cheers -ben > > - Then we are starting to reverse engineering the ecompletion system > and I'm learning it. > I would like to know if Calypso can communicate with ecompletion the > fact that we are defining a method. Then I have to check how the > system can know that we are typing method argument when defining the > signature but I think that this is not related to calypso. > > Stef >

Feb. 8, 2018

[Pharo 7.0-dev] Build #511: 21246-Store-main-window-title

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #511 was: SUCCESS. The Pull Request #809 was integrated: "21246-Store-main-window-title" Pull request url: https://github.com/pharo-project/pharo/pull/809 Issue Url: https://pharo.fogbugz.com/f/cases/21246 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 8, 2018

Re: [Pharo-dev] VMs build process restored

by Cyril Ferlicot

On Thu, Feb 8, 2018 at 4:29 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Cyril, > Hi :) > > Why do you need to back port? Why can't you use the 7.x VM with 6.x images? The VM is intended to be backwards compatible. > For each Pharo release, Pharo defines stable vms. For example, in a Jenkins bash script if we execute this: wget -O- https://get.pharo.org/64/61+vm | bash It will download a fresh Pharo 6.1 image, a source file and a vm of the right OS marked as stable for Pharo 6.1. With this, we ensure that a certain Pharo release will not have a different vm too often because if changes are intended to be backwards compatible, there is always the possibility a problem get through (for example one time OSProcess stopped to work on OSX because of a problem with the system version). So, I *can* use the vm for Pharo 7 if I get it myself but through hacks in our scripts instead of using official distribution ways of Pharo. I would prefer to only use official distribution ways in order to reduce the complexity of our scripts. In conclusion what I mean by "backport" is that Pharo officially marks the current vm as stable for Pharo 6.1 to get it via zeroconf. -- Cyril Ferlicot https://ferlicot.fr

Feb. 8, 2018

Re: [Pharo-dev] Reviewing Changes ?

by Sven Van Caekenberghe

> On 8 Feb 2018, at 13:41, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 7 Feb 2018, at 11:45, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> I made notes and will add a page with all the infos later today. (for http://pharo.org/contribute ) >> > > I added a simple page as a first step: > > http://pharo.org/review-fix > > > Marcus Already quite good, thank you.

Feb. 8, 2018

Re: [Pharo-dev] [Seaside-dev] How should I load Seaside/Bootstrap in Pharo 7 ?

by Sven Van Caekenberghe

Starting/restarting with a running server in the image works OK for me (macOS) and recent Pharo 7. What is different for you ? > On 8 Feb 2018, at 12:51, Maximiliano Tabacman via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Maximiliano Tabacman <mtabacman(a)yahoo.com> > Subject: Re: [Pharo-dev] [Seaside-dev] How should I load Seaside/Bootstrap in Pharo 7 ? > Date: 8 February 2018 at 12:51:15 GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Up until Pharo build 382 (sha 115e95c) you could load Seaside by using: > Metacello new > > > baseline:'Seaside3' > ; > > repository: 'github://SeasideSt/Seaside:master/repository' > ; > load > > If you adapt the baselineOf to include Pharo 7.x > > BUT, from build 383 onwards, and tested again just now with 509 (sha 1276a3f) the following happens: > - Download Pharo -- OK > - Load Seaside master -- OK > - Save and quit image -- OK > - Start image again -- Hangs and never completes starting > > In Ubuntu, this manifests as the main Pharo window opening, but never displaying anything inside it. > In Windows, the VM starts and closes without any warning, and no logs are created. > > I have no idea why this is happening, and I am not sure if the tests in Travis cover this scenario. > On Wednesday, February 7, 2018, 4:14:24 PM GMT-3, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > Thanks for pushing this. > I plan to work on migrating the seaside book to pillar when I'm done > with the moose book and the magritte booklet. > > Stef > > On Wed, Feb 7, 2018 at 1:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > > > Using [ https://github.com/SeasideSt/Seaside/pull/979 ] (I attach a manually modified BaselineOfSeaside3 that I used), I managed to load Seaside 3.2 (GitHub.1516790362) in Pharo 7 (Pharo-7.0+alpha.build.493.sha.d53a70bc946ed83b046f61ac35f00c67fa77269a (32 Bit)) and at least the load and some quick testing with ZnZincSeasideAdaptor (via the spec based Seaside Control Panel) seems to indicate no direct problems. > > > > Metacello new > > baseline:'Seaside3'; > > repository: 'github://SeasideSt/Seaside:master/repository'; > > load. > > > > Why don't we integrate this so that others can load Seaside 3.2 in Pharo 7 too ? > > > > This is _really_ important to make progress, IMHO. > > > > I changed WABrowser>>#updateUrl: to send #name instead of #fullName to the selected class of the model. I am not sure that is entirely correct, but it seemed to work. Apart from that, the WAImageStatus web app worked fine. > > > > Sven > > > >> On 6 Nov 2017, at 09:49, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> OK, Max, thanks for the reply. > >> > >> I will ask on the Pharo ML as well. > >> > >> I think it is important that Seaside works on Pharo 7, it is an important use case and test during development, and very necessary as well. > >> > >>> On 6 Nov 2017, at 09:40, Max Leske <maxleske(a)gmail.com> wrote: > >>> > >>> Hi Sven, > >>> > >>> We don't have a build for Pharo 7 yet. Loading from github would be the recommended way. A quick look makes me think that it will require a bit of work to get the baseline set up correctly. I can't promise anything before next weekend. > >>> > >>> How urgent is the situation for you? > >>> > >>> Cheers, > >>> Max > >>> > >>> > >>> On 5 November 2017 at 19:22:03, Sven Van Caekenberghe (sven(a)stfx.eu) wrote: > >>> > >>>> Hi, > >>>> > >>>> I am stuck trying to move my main development to Pharo 7 because I have trouble loading Seaside (which I normally do indirectly by loading the Bootstrap project). Here is my dependency: > >>>> > >>>> project: 'Bootstrap' with: [ > >>>> spec > >>>> className: 'ConfigurationOfBootstrap'; > >>>> repository: 'http://smalltalkhub.com/mc/TorstenBergmann/Bootstrap/main/'; > >>>> versionString: #stable ] > >>>> > >>>> I also tried the following: > >>>> > >>>> Metacello new > >>>> baseline:'Seaside3'; > >>>> repository: 'github://SeasideSt/Seaside:master/repository'; > >>>> load. > >>>> > >>>> What is the right/recommended way to do it ? > >>>> > >>>> Thx, > >>>> > >>>> Sven > >>>> > >>>> _______________________________________________ > >>>> seaside-dev mailing list > >>>> seaside-dev(a)lists.squeakfoundation.org > >>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > >>> _______________________________________________ > >>> seaside-dev mailing list > >>> seaside-dev(a)lists.squeakfoundation.org > >>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev > >> > > > > > >

Feb. 8, 2018

Re: [Pharo-dev] VMs build process restored

by Eliot Miranda

Hi Cyril, > On Feb 8, 2018, at 2:49 AM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > >> On Tue, Feb 6, 2018 at 5:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> (it was broken since december) >> >> Which means latest vm versions are latest builds from OSVM: >> >> 64bit >> >> â¢ http://files.pharo.org/get-files/70/pharo64-mac-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo64-linux-threaded-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo64-linux-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo64-win-latest.zip >> 32bit >> >> â¢ http://files.pharo.org/get-files/70/pharo-linux-threaded-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo-linux-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo-mac-latest.zip >> â¢ http://files.pharo.org/get-files/70/pharo-win-latest.zip >> >> Hints >> >> â¢ MacOS VMs now are signed! This should fix a lot of problems we had before. >> â¢ Please take note that win64 build lacks all library dependencies, and many things will not work (working on that). >> Thanks to Fabio to help me put all the pieces together. >> >> > ) > cheers, >> Esteban > > Hi! > > Just a little feedback. > > Currently, at Synectique, we added Pharo 61 64bits build to our > Jenkins. Those builds failed **a lot** because of segmentation faults. > We added a mechanism to retry two times when there was a segfault and > even like that we have failing builds. > > Since the restoration of the vms I removed the retry mechanism and I > added a hack to use the latest Pharo 70 vm > (http://files.pharo.org/get-files/70/pharo64-linux-latest.zip) instead > of the stable pharo 61 vm. Since then, there was no crash due to the > VM. > This is a great improvement. > Then I have a question: Is it plan to release new stable 64bit vms for > Pharo 61? Currently, our builds are based on hacks and if no problem > is detected with the latest vm it would greatly help stability-wise to > have official vms that does not crash 3/5times when we load a project. > Also, I understand it can be hard to backport vms with the resources > of the community. :) Why do you need to back port? Why can't you use the 7.x VM with 6.x images? The VM is intended to be backwards compatible. > > -- > Cyril Ferlicot > https://ferlicot.fr >

Feb. 8, 2018