- Pharo-dev - lists.pharo.org

R: About method comments

by Lorenzo Schiavina

Great Stef! Lorenzo -----Messaggio originale----- Da: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] Per conto di Stephane Ducasse Inviato: venerdÃ¬ 9 febbraio 2018 12:04 A: Pharo Development List Oggetto: [Pharo-dev] About method comments Hi guys >From now on I will VETO the introduction of code where methods are not commented. I'm FEDUP FEDUP FEDUP to spend my time commenting methods that I do not know and understand, juts because the original author thought that this is obvious. NOTHING IS OBVIOUS!!!! So I will check if we can have a little process that systematically reject code without enough method comments. Pharo should grow and pharoers too. Stef PS: now you can comment that x said that method should be self-explanatory. This is bullshit. I'm not asking for stupid comments! I'm asking for respect for maintainers and other programmers.

Feb. 9, 2018

Re: [Pharo-dev] About method comments

by Sven Van Caekenberghe

> On 9 Feb 2018, at 12:04, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi guys > > From now on I will VETO the introduction of code where methods are not > commented. > I'm FEDUP FEDUP FEDUP to spend my time commenting methods that I do > not know and understand, juts because the original author thought that > this is obvious. > > NOTHING IS OBVIOUS!!!! > > So I will check if we can have a little process that systematically > reject code without enough method comments. > > Pharo should grow and pharoers too. > > Stef > > PS: now you can comment that x said that method should be > self-explanatory. This is bullshit. I'm not asking for stupid > comments! I'm asking for respect for maintainers and other > programmers. +100 The same goes for class comments too, duh. One problem is that it is hard to check the quality/meaning of the comment. "Comment later" would probably pass any check, as would "I am class XYZ". Also, name "Returns the receiver's name" ^ name Would also pass a simple test, while it is quite useless. I would say that any public, non-trivial methods need a comment. So human judgement will be needed. Sven

Feb. 9, 2018

Re: [Pharo-dev] [Vm-dev] OSVM pre-release 201802061430 ready to be tested

by Esteban Lorenzano

Yes, thatâs because it does not found the proper dependencies. I will need to check the healthy of that installation. Esteban > On 9 Feb 2018, at 08:41, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > On 8 February 2018 at 21:40, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> Has anyone else run the pharo.cog.spur_linux32x86_201802061430.tar.gz >> VM successfully? >> >> If I try to Fetch or Pull incoming commits from Iceberg I get a >> "LGit_GIT_ERROR: Unsupported URL protocol" error. This also occurred >> with the first pre-release VM Fabio made available. The same Pharo >> image works without any problems in my current VM (Wed Jan 10 23:39:30 >> 2018 -0800). > > My guess is that it is caused by missing version information in > libssl.so.1.0.0 and libcrypto.so.1.0.0: > > > $ ldd libgit2.so > ./libgit2.so: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libssl.so.1.0.0: > no version information available (required by ./libgit2.so) > ./libgit2.so: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libcrypto.so.1.0.0: > no version information available (required by ./libgit2.so) > linux-gate.so.1 => (0xf7f35000) > libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7ddd000) > libssl.so.1.0.0 => > /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libssl.so.1.0.0 > (0xf7d74000) > libcrypto.so.1.0.0 => > /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libcrypto.so.1.0.0 > (0xf7b8d000) > librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7b84000) > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7b66000) > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf79b0000) > libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf79ab000) > /lib/ld-linux.so.2 (0xf7f37000) > > > Cheers, > Alistair > > >> OS: Ubuntu 16.04 >> VM: >> 5.0-201802061430 Tue Feb 6 17:16:07 UTC 2018 gcc 4.8.4 [Production Spur VM] >> CoInterpreter VMMaker.oscog-eem.2320 uuid: >> e2692e35-5fc8-4623-95d0-b445b3329f75 Feb 6 2018 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2324 uuid: >> 904abc56-e5a8-467e-a337-880211e33805 Feb 6 2018 >> VM: 201802061430 https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> $ Date: Tue Feb 6 15:30:09 2018 +0100 $ >> Plugins: 201802061430 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Linux travis-job-a0b5a72e-f64c-4657-8f31-f66a35a88881 >> 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 >> i686 i686 i686 GNU/Linux >> plugin path: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430 >> [default: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/] >> >> >> >> Thanks, >> Alistair >> >> >> >> Stack: >> LGitReturnCodeEnum>>handleLGitReturnCode >> LGitRemote(LGitExternalObject)>>withReturnHandlerDo: >> LGitRemote>>fetchWithCredentials: >> [ :repo | >> | gitRemote myCommit theirCommit mergeBase | >> "Fetch" >> gitRemote := (LGitRemote of: repo named: aRemote remoteName) lookup. >> gitRemote fetchWithCredentials: IceCredentialsProvider default. >> >> "Decide if we can fast-forward or we must do a real merge" >> myCommit := repo head object. >> theirCommit := repo head upstream object. >> mergeBase := repo mergeBaseBetween: myCommit id and: theirCommit id. >> mergeBase = myCommit id >> ifTrue: [ self pullRepositoryFastForward: repo ] >> ifFalse: [ self pullRepository: repo merge: myCommit with: theirCommit >> ] ] in IceLibgitLocalRepository>>pullFrom: in Block: [ :repo | ... >> [ | repo | >> repo := (LGitRepository on: self location) open. >> aBlock value: repo ] in IceLibgitLocalRepository>>withRepoDo: in >> Block: [ | repo |... >> [ self checkInitialized. >> aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self >> checkInitialized.... >> [ activeProcess psValueAt: index put: anObject. >> aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: >> in Block: [ activeProcess psValueAt: index put: anObject.... >> BlockClosure>>ensure: >> LGitActionSequence(DynamicVariable)>>value:during: >> LGitActionSequence class(DynamicVariable class)>>value:during: >> LGitGlobal class>>runSequence: >> IceLibgitLocalRepository>>withRepoDo: >> IceLibgitLocalRepository>>pullFrom: >> IceRepository>>pullFrom: >> IceRepository>>pull >> [ self repository pull ] in IceRepositoryModel>>pull in Block: [ self >> repository pull ] >> BlockClosure>>on:do: >> IceRepositoryModel>>pull >> MessageSend>>value >> MessageSend>>cull: >> [ :presentation | >> presentation selection >> ifNotNil: [ :sel | >> (MessageSend receiver: sel selector: actionSelector) >> cull: presentation ] ] in GLMGenericAction>>selectionAction: in Block: >> [ :presentation | ... >> BlockClosure>>glamourValueWithArgs: >> GLMGenericAction(GLMAction)>>actOn: >> GLMGenericAction(GLMAction)>>morphicActOn: >> [ :ann | ann action morphicActOn: aPresentation ] in >> GLMMorphicFastTableRenderer(GLMMorphicWidgetRenderer)>>installActionsOnModel:fromPresentation: >> in Block: [ :ann | ann action morphicActOn: aPresentation ] >> BlockClosure>>cull: >> BlockClosure>>cull:cull: >> [ action cull: anAnnouncement cull: announcer ] in >> AnnouncementSubscription>>deliver: in Block: [ action cull: >> anAnnouncement cull: announcer ] >> BlockClosure>>on:do: >> BlockClosure>>on:fork: >> >> >> >> >> On 7 February 2018 at 08:22, Fabio Niephaus <lists(a)fniephaus.com> wrote: >>> >>> Dear all, >>> >>> We were able to fix all build problems today, so here is the OpenSmalltalkVM pre-release 201802061430 [1]. >>> The Pharo VMs for macOS are now correctly signed. More importantly, they come with a fix for "Crashes while typing on macOS Sierra" [2]. >>> >>> Please give the VMs a try if you have some time and report any bugs at [3]. >>> >>> Best, >>> Fabio >>> >>> [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201802061430 >>> [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 >>> [3] https://github.com/OpenSmalltalk/opensmalltalk-vm/issues >>>

Feb. 9, 2018

About method comments

by Stephane Ducasse

Hi guys >From now on I will VETO the introduction of code where methods are not commented. I'm FEDUP FEDUP FEDUP to spend my time commenting methods that I do not know and understand, juts because the original author thought that this is obvious. NOTHING IS OBVIOUS!!!! So I will check if we can have a little process that systematically reject code without enough method comments. Pharo should grow and pharoers too. Stef PS: now you can comment that x said that method should be self-explanatory. This is bullshit. I'm not asking for stupid comments! I'm asking for respect for maintainers and other programmers.

Feb. 9, 2018

[Pharo 7.0-dev] Build #514: 21252-Add-method-comments-to-SUnit

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

There is a new Pharo build available! The status of the build #514 was: FAILURE. The Pull Request #812 was integrated: "21252-Add-method-comments-to-SUnit" Pull request url: https://github.com/pharo-project/pharo/pull/812 Issue Url: https://pharo.fogbugz.com/f/cases/21252 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 9, 2018

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

by Marcus Denker

Thanks! I added https://pharo.fogbugz.com/f/cases/21255/Zeroconf-script-should-re-use-exist… > On 8 Feb 2018, at 21:38, Henrik-Nergaard <draagren(a)outlook.com> wrote: > > man mkdir | grep -A 2 parents > -p, --parents > no error if existing, make parent directories as needed

Feb. 9, 2018

Re: [Pharo-dev] Calypso wishlist

by Denis Kudriashov

Hi Stef. There is no problem to add extra logic in class editor. Give me the code and I will add it. But I guess you saw how class definition is evaluated in the browser. It is big mess with many "if statements" and manual parsing of definition parts. I wish we will clean it with proper class compiler. 2018-02-08 11:22 GMT+03:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi denis > > - I would like to be able to define a method even in the class pane > and that the system detects it automatically. > > - 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. 9, 2018

Re: [Pharo-dev] [Vm-dev] OSVM pre-release 201802061430 ready to be tested

by Alistair Grant

On 8 February 2018 at 21:40, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Has anyone else run the pharo.cog.spur_linux32x86_201802061430.tar.gz > VM successfully? > > If I try to Fetch or Pull incoming commits from Iceberg I get a > "LGit_GIT_ERROR: Unsupported URL protocol" error. This also occurred > with the first pre-release VM Fabio made available. The same Pharo > image works without any problems in my current VM (Wed Jan 10 23:39:30 > 2018 -0800). My guess is that it is caused by missing version information in libssl.so.1.0.0 and libcrypto.so.1.0.0: $ ldd libgit2.so ./libgit2.so: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libssl.so.1.0.0: no version information available (required by ./libgit2.so) ./libgit2.so: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libcrypto.so.1.0.0: no version information available (required by ./libgit2.so) linux-gate.so.1 => (0xf7f35000) libz.so.1 => /lib/i386-linux-gnu/libz.so.1 (0xf7ddd000) libssl.so.1.0.0 => /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libssl.so.1.0.0 (0xf7d74000) libcrypto.so.1.0.0 => /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libcrypto.so.1.0.0 (0xf7b8d000) librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xf7b84000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7b66000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf79b0000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf79ab000) /lib/ld-linux.so.2 (0xf7f37000) Cheers, Alistair > OS: Ubuntu 16.04 > VM: > 5.0-201802061430 Tue Feb 6 17:16:07 UTC 2018 gcc 4.8.4 [Production Spur VM] > CoInterpreter VMMaker.oscog-eem.2320 uuid: > e2692e35-5fc8-4623-95d0-b445b3329f75 Feb 6 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2324 uuid: > 904abc56-e5a8-467e-a337-880211e33805 Feb 6 2018 > VM: 201802061430 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Tue Feb 6 15:30:09 2018 +0100 $ > Plugins: 201802061430 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > Linux travis-job-a0b5a72e-f64c-4657-8f31-f66a35a88881 > 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 > i686 i686 i686 GNU/Linux > plugin path: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430 > [default: /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/] > > > > Thanks, > Alistair > > > > Stack: > LGitReturnCodeEnum>>handleLGitReturnCode > LGitRemote(LGitExternalObject)>>withReturnHandlerDo: > LGitRemote>>fetchWithCredentials: > [ :repo | > | gitRemote myCommit theirCommit mergeBase | > "Fetch" > gitRemote := (LGitRemote of: repo named: aRemote remoteName) lookup. > gitRemote fetchWithCredentials: IceCredentialsProvider default. > > "Decide if we can fast-forward or we must do a real merge" > myCommit := repo head object. > theirCommit := repo head upstream object. > mergeBase := repo mergeBaseBetween: myCommit id and: theirCommit id. > mergeBase = myCommit id > ifTrue: [ self pullRepositoryFastForward: repo ] > ifFalse: [ self pullRepository: repo merge: myCommit with: theirCommit > ] ] in IceLibgitLocalRepository>>pullFrom: in Block: [ :repo | ... > [ | repo | > repo := (LGitRepository on: self location) open. > aBlock value: repo ] in IceLibgitLocalRepository>>withRepoDo: in > Block: [ | repo |... > [ self checkInitialized. > aBlock value ] in LGitGlobal class>>runSequence: in Block: [ self > checkInitialized.... > [ activeProcess psValueAt: index put: anObject. > aBlock value ] in LGitActionSequence(DynamicVariable)>>value:during: > in Block: [ activeProcess psValueAt: index put: anObject.... > BlockClosure>>ensure: > LGitActionSequence(DynamicVariable)>>value:during: > LGitActionSequence class(DynamicVariable class)>>value:during: > LGitGlobal class>>runSequence: > IceLibgitLocalRepository>>withRepoDo: > IceLibgitLocalRepository>>pullFrom: > IceRepository>>pullFrom: > IceRepository>>pull > [ self repository pull ] in IceRepositoryModel>>pull in Block: [ self > repository pull ] > BlockClosure>>on:do: > IceRepositoryModel>>pull > MessageSend>>value > MessageSend>>cull: > [ :presentation | > presentation selection > ifNotNil: [ :sel | > (MessageSend receiver: sel selector: actionSelector) > cull: presentation ] ] in GLMGenericAction>>selectionAction: in Block: > [ :presentation | ... > BlockClosure>>glamourValueWithArgs: > GLMGenericAction(GLMAction)>>actOn: > GLMGenericAction(GLMAction)>>morphicActOn: > [ :ann | ann action morphicActOn: aPresentation ] in > GLMMorphicFastTableRenderer(GLMMorphicWidgetRenderer)>>installActionsOnModel:fromPresentation: > in Block: [ :ann | ann action morphicActOn: aPresentation ] > BlockClosure>>cull: > BlockClosure>>cull:cull: > [ action cull: anAnnouncement cull: announcer ] in > AnnouncementSubscription>>deliver: in Block: [ action cull: > anAnnouncement cull: announcer ] > BlockClosure>>on:do: > BlockClosure>>on:fork: > > > > > On 7 February 2018 at 08:22, Fabio Niephaus <lists(a)fniephaus.com> wrote: >> >> Dear all, >> >> We were able to fix all build problems today, so here is the OpenSmalltalkVM pre-release 201802061430 [1]. >> The Pharo VMs for macOS are now correctly signed. More importantly, they come with a fix for "Crashes while typing on macOS Sierra" [2]. >> >> Please give the VMs a try if you have some time and report any bugs at [3]. >> >> Best, >> Fabio >> >> [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201802061430 >> [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/141 >> [3] https://github.com/OpenSmalltalk/opensmalltalk-vm/issues >>

Feb. 9, 2018

interactive method definition (was Re: Calypso wishlist)

by Ben Coman

On 9 February 2018 at 03:43, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > 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. >> > Ahh, cool. I change the subject. > >> 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. >> > Is this your ideal, or mainly to align with Tonel? Because it seems Tonel was developed without much consideration of interactive method definition -- which is fine in as much as Tonel was designed to quickly overcome a specific problem with Windows+Git, but it Tonel shouldn't be set in stone since its introduction changes the environment and stimulates further thinking on requirements. Amongst your many priorities, could you ask someone familiar with changing compiler syntax have a serious look at implementing both ways: 1. Tonel syntax for interactive method definition 2. Named block parameters for interactive method definition to determine practically which one is preferred and easier to support. And feed that into determining whether syntax should adapt to Tonel or whether Tonel should adapt to the latter. It would be better to do this earlier while Tonel is young before it becomes more widely used by other dialects. Also btw, would having named block parameters possibly unify more methods and blocks? (only a random thought, I'm not familiar with the low level distinction) cheers -ben P.S. should Tonel include a format-version field on the first line? Its seems a good practice even if the format never does change for a long time. > 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 not. >> >> 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. 9, 2018

[Pharo 7.0-dev] Build #513: 21251-Improve-Senders-of

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

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

Feb. 8, 2018