- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #517: 21266 Cleanup testAddMCPackageForCategoryAlreadyExistingDoesNotCreateAPackage

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

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

Feb. 10, 2018

Re: [Pharo-dev] interactive method definition (was Re: Calypso wishlist)

by Stephane Ducasse

In fact I'm stupid because I already coded it by extending the parser and I lost the code. I should look around or redo it. On Sat, Feb 10, 2018 at 7:10 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> 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. > > Not only. We decided that the methods syntax in tonel could be used in browser > and in email. I have this proposal since before ESUG in lugano (2005) > so I really thought about it > a lot. This is not by accident that the code in all my book follow > nearly this shape. > The tonel structure is nice because it mimics also other languages. > > fooSignature { > > } > > >> 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 > > Yes but we are really busy > And yes we want this. So we should do it. > >> 2. Named block parameters for interactive method definition > > 2 mega sucks. > And we will not do it. Sorry. > > >> to determine practically which one is preferred and easier to support. > > I will veto 2. And I will be really strong on it. > I'm teaching Pharo and this is enough. > >> 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. > > Tonel method definition will not change. > > >> 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) > > This is not because they look the same that in the conceptual model > they should. > Now I would like to have optional parameter value (but it can be a bit > touchy since there > are many design decision to take and it impacts senders and the rest. > > > >> >> 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. > > Tonel has a property file that encodes metadata.

Feb. 10, 2018

Re: [Pharo-dev] Iceberg experience report - synchronising README change made on github

by Stephane Ducasse

> > P.P.S. I think more thought needs to be given to whether mixing > updates from both the remote and disk working directory in the one > pane is beneficial? > As an alternative, perhaps some side-scrolling GTInspector-like panes > Image <--> Working Directory <--> Remote <--> Server(github) > would better represent the git model. > Or maybe statically position those panes in one window with buttons on > directed lines showing which way and how far a commit moves when that > button is pushed. I was saying to esteban that the UI should let the user understand where the code is so I like you > Image <--> Working Directory <--> Remote <--> Server(github) Mine was > Image <--> Local repository <--> Remote Stef

Feb. 10, 2018

Re: [Pharo-dev] interactive method definition (was Re: Calypso wishlist)

by Stephane Ducasse

> 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. Not only. We decided that the methods syntax in tonel could be used in browser and in email. I have this proposal since before ESUG in lugano (2005) so I really thought about it a lot. This is not by accident that the code in all my book follow nearly this shape. The tonel structure is nice because it mimics also other languages. fooSignature { } > 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 Yes but we are really busy And yes we want this. So we should do it. > 2. Named block parameters for interactive method definition 2 mega sucks. And we will not do it. Sorry. > to determine practically which one is preferred and easier to support. I will veto 2. And I will be really strong on it. I'm teaching Pharo and this is enough. > 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. Tonel method definition will not change. > 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) This is not because they look the same that in the conceptual model they should. Now I would like to have optional parameter value (but it can be a bit touchy since there are many design decision to take and it impacts senders and the rest. > > 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. Tonel has a property file that encodes metadata.

Feb. 10, 2018

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