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

Thanks for the fix of line selection in playground...

by Stephane Ducasse

Now no need to select the line to execute it.... a pain and time saver Tx!

Feb. 10, 2018

Ring2

by Martin Dias

Hello Pavel and all, I wonder what's the best way to try Ring2 and maybe do some experiment on top of it. Is it ok if I load master branch of https://github.com/pavel-krivanek/Ring2 in Pharo 6.1? or should I load it in Pharo 7? I also see there are several branches in the repo. I'd like to load as ring2 objects a specific Pharo version. More concretely, I wonder how to load all classes and methods in a commit on https://github.com/pharo-project/pharo. I guess the image bootstrap does that, no? Thanks in advance, MartÃn

Feb. 10, 2018

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

by Alistair Grant

Hi Esteban, Thanks for your reply. On 9 February 2018 at 22:08, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Yes, thatâs because it does not found the proper dependencies. > I will need to check the healthy of that installation. OK. There doesn't appear to be anything obvious missing: $ ldd libssl.so.1.0.0 linux-gate.so.1 => (0xf7f91000) libcrypto.so.1.0.0 => /tmp/phcogspurlinuxht/lib/pharo/5.0-201802061430/libcrypto.so.1.0.0 (0xf7d3d000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7b78000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7b73000) /lib/ld-linux.so.2 (0xf7f93000) $ ldd libcrypto.so.1.0.0 linux-gate.so.1 => (0xf7f9c000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7d9d000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7be7000) /lib/ld-linux.so.2 (0xf7f9e000) Cheers, Alistair > 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. 10, 2018

Re: [Pharo-dev] About method comments

by Stephane Ducasse

A method comment should tell - what it is doing, what are the preconditions - then some concerns about the implementation You can give a try to document methods of fileSystem or SUnit as Katas. Stef On Sat, Feb 10, 2018 at 5:54 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Esteban A. Maringolo wrote >> Commenting an accesor is redundant, IMO. > > Typically, yes, and there are other examples. > > > Esteban A. Maringolo wrote >> I think that having a public guideline on how to comment >> methods would be positive for the community > > Interesting idea. Any suggestions? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Feb. 10, 2018

Re: [Pharo-dev] About method comments

by Sean P. DeNigris

Esteban A. Maringolo wrote > Commenting an accesor is redundant, IMO. Typically, yes, and there are other examples. Esteban A. Maringolo wrote > I think that having a public guideline on how to comment > methods would be positive for the community Interesting idea. Any suggestions? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Feb. 10, 2018

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

by Maximiliano Tabacman

I can confirm that Ctrl + DOT unlocks the image in Ubuntu. Then by loading the latest Zinc packages and evaluating "Smalltalk recompile" the issue is fixed. Many many thanks for your time and for pointing me in the right direction. On Friday, February 9, 2018, 1:16:15 PM GMT-3, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. 10, 2018

Re: [Pharo-dev] About method comments

by Stephane Ducasse

You see I take some core classes and I read the code and I comment when I understand what a method does. And I do that 15 min from time to time. And just doing this will improve Pharo. When I learn something I take 2 min to add a comment. Stef On Fri, Feb 9, 2018 at 9:13 PM, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > Hi Esteban, > > On Fri, 2018-02-09 at 15:17 -0300, Esteban A. Maringolo wrote: >> >> And rename refactorings usually don't rename the comments >> (hopefully). >> > Why hopefully? Java IDEs rename references to the method also > in comments, I found it very nice. Why it should not? I'm just curious. > > Best, Jan >

Feb. 9, 2018

Re: [Pharo-dev] Calypso wishlist

by Stephane Ducasse

Denis I thought that we can see class comments and class definition/ method definition. This is super annoying not to be able to see the class comments especially when we have large screens. Did I missed something? Stef On Fri, Feb 9, 2018 at 1:33 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > 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

Re: [Pharo-dev] About method comments

by Jan Vrany

Hi Esteban, On Fri, 2018-02-09 at 15:17 -0300, Esteban A. Maringolo wrote: > > And rename refactorings usually don't rename the comments > (hopefully). > Why hopefully? Java IDEs rename references to the method also in comments, I found it very nice. Why it should not? I'm just curious. Best, Jan

Feb. 9, 2018

Re: [Pharo-dev] About method comments

by Esteban A. Maringolo

2018-02-09 8:10 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > 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. Commenting an accesor is redundant, IMO. And rename refactorings usually don't rename the comments (hopefully). However I think that having a public guideline on how to comment methods would be positive for the community (if these rules are consensual). After that some tools can use these guidelines to generate comments on their own, or if you don't know how to comment, simply copy the templates from the guide. E.g. Private methods in Dolphin always start with "Private - ...", if you remove the "private" category from the method (methods can belong to multiple categories), then it removes the "Private - " prefix from the comment as well. Regards, -- Esteban.

Feb. 9, 2018