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

Re: [Pharo-dev] About method comments

by Norbert Hartl

One more reason to do reviews. Now that it is super easy with iceberg there is less reason to do so. Norbert > Am 09.02.2018 um 12:10 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> 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

[Pharo 7.0-dev] Build #516: 21258-Add-an-option-do-disable-WorldMorphs-drag-and-drop-for-deployment

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

There is a new Pharo build available! The status of the build #516 was: SUCCESS. The Pull Request #815 was integrated: "21258-Add-an-option-do-disable-WorldMorphs-drag-and-drop-for-deployment" Pull request url: https://github.com/pharo-project/pharo/pull/815 Issue Url: https://pharo.fogbugz.com/f/cases/21258 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 9, 2018

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

by Sven Van Caekenberghe

> On 9 Feb 2018, at 15:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > It seems the latest Zinc (as loaded by Seaside) does not yet contain this class. > > I'll check and come back. To fix this, for now, you can load the latest ConfigurationOfZincHTTPComponents and do ConfigurationOfZincHTTPComponents project bleedingEdge load. After which you have to do Smalltalk recompile. And save. You should now be able to restart and your image should come up normally. If CI builds succeed for older versions of Pharo, I will promote this version to #stable. Sven

Feb. 9, 2018

[Pharo 7.0-dev] Build #515: 21256-Deprecated-glmSubscriptions-is-used-in-GLMBrickPropertiesTrait

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

There is a new Pharo build available! The status of the build #515 was: FAILURE. The Pull Request #813 was integrated: "21256-Deprecated-glmSubscriptions-is-used-in-GLMBrickPropertiesTrait" Pull request url: https://github.com/pharo-project/pharo/pull/813 Issue Url: https://pharo.fogbugz.com/f/cases/21256 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Feb. 9, 2018

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

by Sven Van Caekenberghe

Hi Maximiliano, I finally managed to reproduce your situation, using get.pharo.org/70+vm on Linux (Ubuntu 16.04.3 LTS, 64bit using a 32bit VM). Indeed the second time the image comes up blank. It does however still work (I had a running server in it and I could access it via the browser). You can also interrupt Pharo (ctrl-.) and the debugger shows the process is blocked at the 'wait wait' in the following method: SessionManager>>#snapshot: save andQuit: quit | isImageStarting wait | "We do the snapshot in a separate process in maximum priority to have always a clean startup. This process will be interrupted by the fork, and will be resumed as soon as the snapshot finishes. We synchronize these processes in case both are in the same priority. When both arguments are false, do nothing and return false." (save or: [quit]) ifFalse: [ ^ false ]. wait := Semaphore new. [ isImageStarting := self launchSnapshot: save andQuit: quit. wait signal ] forkAt: Processor highestPriority. wait wait. ^ isImageStarting Now, the underlying error is ZnCrPortableWriteStream that disappeared and is used by the command line handlers. It seems the latest Zinc (as loaded by Seaside) does not yet contain this class. I'll check and come back. Sven > On 9 Feb 2018, at 00:04, 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: 9 February 2018 at 00:04:59 GMT+1 > To: pharo-dev(a)lists.pharo.org, "Sean P. DeNigris" <sean(a)clipperadams.com> > > > I can only test it in Ubuntu and Windows for the moment. > > Steps to reproduce (in Windows) > 1) Download: > http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201802072244-997e… > 2) Download: > http://files.pharo.org/image/70/Pharo-7.0.0-alpha.build.512.sha.881c01b.arc… > 3) Unzip everything to the same directory, then start Pharo.exe > 4) Execute in Workspace > Metacello new > baseline:'Seaside3'; > repository: 'github://SeasideSt/Seaside:master/repository'; > load > 5) Save and Quit > 6) Try to start Pharo.exe > > If I delete stderr, stdout and PharoDebug.log before restarting Pharo, I can see that stderr and PharoDebug.log are created at 0 bytes, there is no other log that I can find. > > As you can see, no startup scripts are involved. This is a clean Pharo installation. And this happens both in Windows and in Ubuntu, no matter in which OS I try to do the download+load. > > If it is of any help, this has been happening exactly since build 383. It worked perfectly up to build 382. > On Thursday, February 8, 2018, 4:42:36 PM GMT-3, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > > 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. 9, 2018

Re: [Pharo-dev] Calypso wishlist

by Stephane Ducasse

Yes denis this is something that we started to clean and we got distracted. On Fri, Feb 9, 2018 at 8:59 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 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

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