September 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by David T. Lewis

On Thu, Sep 14, 2017 at 12:18:34AM +0200, Norbert Hartl wrote: > > > Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > > > Hi Denis, > > > > On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > > Hi Eliot. > > > > I know and I only talk about new messages. I am not trying to rethink full meta model of Smalltalk. > > By the way #class is very common message and it is handy to use short name. But pinning messages will be used rarely in very specific applications. So no much sense to preserve them in short version. > > > > Agreed. So we have to decide whether to go with pinInMemory or pinObject, pinObject being suggested by Norbert because it matched isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel strongly about pinObject et al? > > > No I don't. It feels only good to me if there is a requirement not to implement selectors that are likely to be used in user code. I'm ok with pinInMemory although I asked myself where can it be pinned elsewhere if not in memory. So the suffix in memory doesn't add anything but also moves the selector out of user space. > +1 I also like pinInMemory because it is easy to read and it describes exactly what the method does. It pins the object to some location in the object memory. Once you stick a pin in it, the object stops moving around in the object memory. Nice. Dave

Sept. 13, 2017

Pharo 6.1 32bit/64bit on CentOS 7 with Iceberg

by Andrei Chis

Hi, Does anybody use Pharo 6.1 (32 or 64 bit) on CentOS 7? I am getting randomly the following crash when trying to clone a repository from github. While this might suggest some kind of of out memory error there should be enough memory. PrimitiveFailed: primitive #allocateExecutablePage in FFICallbackThunk class failed FFICallbackThunk class(Object)>>primitiveFailed: FFICallbackThunk class(Object)>>primitiveFailed FFICallbackThunk class>>allocateExecutablePage [ ExecutablePages add: self allocateExecutablePage ] in FFICallbackThunk class>>unusedBlockInExecutablePage in Block: [ ExecutablePages add: self allocateExecutablePage...etc... [ caught := true. self wait. blockValue := mutuallyExcludedBlock value ] in Semaphore>>critical: in Block: [ caught := true.... BlockClosure>>ensure: Semaphore>>critical: FFICallbackThunk class>>unusedBlockInExecutablePage FFICallbackThunk class>>privateFinalizingNew FFICallbackThunk class>>newCCall CallbackForIA32(Callback)>>callbackEvaluator: Callback class>>forCallbackEvaluator: LGitTransportCertificateCheckCallback(FFICallback)>>signature:block: LGitTransportCertificateCheckCallback class(FFICallback class)>>signature:block: LGitTransportCertificateCheckCallback class(LGitCallback class)>>on: LGitRemoteCallbacks class>>newCertificateCheckCallback LGitRemoteCallbacks class>>defaults LGitRemoteCallbacks class>>withProvider: LGitCloneOptions class>>withCredentialsProvider: [ | repo cloneOptions | repo := LGitRepository on: self location. cloneOptions := LGitCloneOptions withCredentialsProvider: IceCredentialsProvider default. repo clone: url options: cloneOptions. aBranchName ifNotNil: [ repo checkout: aBranchName ]. (LGitRemote of: repo named: 'origin') lookup; setUrl: url ] in IceLibgitLocalRepository>>cloneRepositoryFrom:branch: in Block: [ | repo cloneOptions |... [ 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>>cloneRepositoryFrom:branch: IceRepositoryCreator>>createRepository [ (IceRepositoryCreator new url: remoteUrl; subdirectory: repoPath; branchName: self projectVersion; createRepository) register ] in MCGitHubRepository>>getOrCreateIcebergRepository in Block: [ (IceRepositoryCreator new... OrderedCollection(Collection)>>detect:ifFound:ifNone: Cheers, Andrei

Sept. 13, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Norbert Hartl

> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > Hi Denis, > > On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > Hi Eliot. > > I know and I only talk about new messages. I am not trying to rethink full meta model of Smalltalk. > By the way #class is very common message and it is handy to use short name. But pinning messages will be used rarely in very specific applications. So no much sense to preserve them in short version. > > Agreed. So we have to decide whether to go with pinInMemory or pinObject, pinObject being suggested by Norbert because it matched isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel strongly about pinObject et al? > No I don't. It feels only good to me if there is a requirement not to implement selectors that are likely to be used in user code. I'm ok with pinInMemory although I asked myself where can it be pinned elsewhere if not in memory. So the suffix in memory doesn't add anything but also moves the selector out of user space. Norbert > > 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > Hi Denis, > > > On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: > >> I am really wonder guys. I thought you are not big funs of Object protocol. >> Current pinning messages are a new set of very generic messages in the Object. > > Yes, and that's because this is a fundamental property of all non-immediate objects. Do you object to the #class message? Should it be #classObject because it might conflict with #class used in an educational or socioeconomic model? All objects other than immediates can move. Pinning stops that movement. It applies generally. So the protocol belongs in Object. > > >> >> About Norbert idea. >> - bePinnedObject is not bad convention. But I would prefer the memory suffix because it reflects the low level behaviour. >> >> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: >> yes, me :) >> >> I do not see a reason to change them, tbh. >> for me they are comprensible as they are now and it does not adds more information pinInMemory or pinMemory. >> >> Esteban >> >> >>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >>> >>> Anybody else? >>> >>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>>: >>> >>> >>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >>> Hi. >>> >>> We now have very generic message names: >>> - pin >>> - unpin >>> - setPinned: >>> - isPinned >>> >>> Problem that they collide with possible domain related names. >>> For example I implemented pinning of tabs in Calypso and I found that I overrides #pin and #isPinned messages. Then I fix it with different names. >>> Probably menus also uses pin word but without overrides >>> >>> What you think about renaming pinning messages? Something like: >>> - pinMemory >>> >>> I would use pinInMemory >>> >>> -- Pavel >>> >>> - unpinMemory >>> - isMemoryPinned >>> - setPinnedMemory: >>> - pinMemoryDuring: (if we will introduce it) >>> >>> I think it is easy to do now because not much code uses pinning >>> >>> >> >> > > > > > -- > _,,,^..^,,,_ > best, Eliot

Sept. 13, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Eliot Miranda

Hi Denis, On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi Eliot. > > I know and I only talk about new messages. I am not trying to rethink full > meta model of Smalltalk. > By the way #class is very common message and it is handy to use short > name. But pinning messages will be used rarely in very specific > applications. So no much sense to preserve them in short version. > Agreed. So we have to decide whether to go with pinInMemory or pinObject, pinObject being suggested by Norbert because it matched isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel strongly about pinObject et al? > > 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Denis, >> >> >> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk(a)gmail.com> >> wrote: >> >> I am really wonder guys. I thought you are not big funs of Object >> protocol. >> Current pinning messages are a new set of very generic messages in the >> Object. >> >> >> Yes, and that's because this is a fundamental property of all >> non-immediate objects. Do you object to the #class message? Should it be >> #classObject because it might conflict with #class used in an educational >> or socioeconomic model? All objects other than immediates can move. >> Pinning stops that movement. It applies generally. So the protocol >> belongs in Object. >> >> >> >> About Norbert idea. >> - bePinnedObject is not bad convention. But I would prefer the memory >> suffix because it reflects the low level behaviour. >> >> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> yes, me :) >>> >>> I do not see a reason to change them, tbh. >>> for me they are comprensible as they are now and it does not adds more >>> information pinInMemory or pinMemory. >>> >>> Esteban >>> >>> >>> On 11 Sep 2017, at 11:56, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >>> >>> Anybody else? >>> >>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: >>> >>>> >>>> >>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>>> >>>>> Hi. >>>>> >>>>> We now have very generic message names: >>>>> - pin >>>>> - unpin >>>>> - setPinned: >>>>> - isPinned >>>>> >>>>> Problem that they collide with possible domain related names. >>>>> For example I implemented pinning of tabs in Calypso and I found that >>>>> I overrides #pin and #isPinned messages. Then I fix it with different names. >>>>> Probably menus also uses pin word but without overrides >>>>> >>>>> What you think about renaming pinning messages? Something like: >>>>> - pinMemory >>>>> >>>> >>>> I would use pinInMemory >>>> >>>> -- Pavel >>>> >>>> >>>>> - unpinMemory >>>>> - isMemoryPinned >>>>> - setPinnedMemory: >>>>> - pinMemoryDuring: (if we will introduce it) >>>>> >>>>> I think it is easy to do now because not much code uses pinning >>>>> >>>> >>>> >>> >>> >> > -- _,,,^..^,,,_ best, Eliot

Sept. 13, 2017

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Esteban Lorenzano

right. > On 13 Sep 2017, at 19:01, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > I agree Right is a lot better and I would love to get FastTable or > related fixed so that we can see the filter input field at the end of > the left pane. > > On Wed, Sep 13, 2017 at 6:32 PM, Brad Selfridge <bsselfridge(a)gmail.com> wrote: >> "RIGHT" (window color) >> >> >> -- >> Brad Selfridge >> 913-269-2385 >> >> >

Sept. 13, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Denis Kudriashov

Yes 13 ÑÐµÐ½Ñ. 2017 Ð³. 18:59 Ð¿Ð¾Ð»ÑÐ·Ð¾Ð²Ð°ÑÐµÐ»Ñ "Stephane Ducasse" < stepharo.self(a)gmail.com> Ð½Ð°Ð¿Ð¸ÑÐ°Ð»: > I imagine that you imply keeping the cGlobalVariable binding for the > real global variable. > > On Wed, Sep 13, 2017 at 4:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > So after discussion the solution would be: > > - ClassBinding for instance side method literals and globals dictionary > > (instead of GlobalVariable) > > - MetaclassBinding for the last literal of class side methods. It will > > include proper comment about where it is used and how, with description > of > > current trick > > > > 2017-09-13 16:45 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: > >> > >> > >> > On 12 Sep 2017, at 17:33, Guillermo Polito <guillermopolito(a)gmail.com > > > >> > wrote: > >> > > >> > I don't know... I found the idea of having a Metaclass binding > >> > strange... > >> > > >> > I mean, > >> > - metaclasses are not stored in any name dictionary such as Smalltalk > >> > - nobody references them directly in source code but by their direct > >> > classes > >> > > >> > The metaclass binding is there just for one thing really: methods need > >> > an association to know their class in case they have to do a super > send. And > >> > transitively this is a compiler problem also. But anybody else > accesses > >> > metaclasses' bindings. > >> > > >> yes, we need it just for the last literal. > >> > >> We added the âif there is a method, get the binding from thereâ we adde > as > >> else > >> we would compiler every class side method with a new Association > instance, > >> which > >> wastes lots of space. > >> > >> Marcus > > > > > >

Sept. 13, 2017

Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

by Todd Blanchard

+1 > On Aug 31, 2017, at 1:29 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > I would use pinInMemory

Sept. 13, 2017

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Stephane Ducasse

I agree Right is a lot better and I would love to get FastTable or related fixed so that we can see the filter input field at the end of the left pane. On Wed, Sep 13, 2017 at 6:32 PM, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > "RIGHT" (window color) > > > -- > Brad Selfridge > 913-269-2385 > >

Sept. 13, 2017

Re: [Pharo-dev] [Calypso] Toolbar and Statusbar Look - voting time

by Sven Van Caekenberghe

> On 13 Sep 2017, at 18:32, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > > "RIGHT" (window color) Yes, right seems better.

Sept. 13, 2017

Re: [Pharo-dev] Tricky Metaclass>>binding

by Stephane Ducasse

I imagine that you imply keeping the cGlobalVariable binding for the real global variable. On Wed, Sep 13, 2017 at 4:52 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > So after discussion the solution would be: > - ClassBinding for instance side method literals and globals dictionary > (instead of GlobalVariable) > - MetaclassBinding for the last literal of class side methods. It will > include proper comment about where it is used and how, with description of > current trick > > 2017-09-13 16:45 GMT+02:00 Marcus Denker <marcus.denker(a)inria.fr>: >> >> >> > On 12 Sep 2017, at 17:33, Guillermo Polito <guillermopolito(a)gmail.com> >> > wrote: >> > >> > I don't know... I found the idea of having a Metaclass binding >> > strange... >> > >> > I mean, >> > - metaclasses are not stored in any name dictionary such as Smalltalk >> > - nobody references them directly in source code but by their direct >> > classes >> > >> > The metaclass binding is there just for one thing really: methods need >> > an association to know their class in case they have to do a super send. And >> > transitively this is a compiler problem also. But anybody else accesses >> > metaclasses' bindings. >> > >> yes, we need it just for the last literal. >> >> We added the âif there is a method, get the binding from thereâ we adde as >> else >> we would compiler every class side method with a new Association instance, >> which >> wastes lots of space. >> >> Marcus > >

Sept. 13, 2017