- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] String Interpolation

by phil＠highoctane.be

We also have http://norbert.hartl.name/blog/2013/10/03/mustache-templates-for-smalltalk/ Phil On Thu, Sep 28, 2017 at 4:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I got into a little office discussion about string interpolation as it is > done in different programming languages. > > In Pharo we have String>>#format: which is pretty nice. It works as > follows: > > | x y | > x := 123. > y := #foo. > 'x={1} and y={2}' format: { x. y }. > > It is also possible to use a dictionary with keys, like this: > > | x y | > x := 123. > y := #foo. > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. > > But this is not true string interpolation as described in [ > https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to > write the value generating expressions directly inside the strings. > > Since in Pharo we add features not by extending the syntax but by adding > messages I wondered if it could be done for string interpolation. The goal > is to make the following work: > > | x y | > x := 123. > y := #foo. > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' > interpolate. > > => 'It seems x equals 123 and y equals foo while Pi is still > 3.141592653589793' > > Here is the implementation I came up with: > > String>>#interpolate > "Format the receiver by interpolating the evaluation of expressions > in between curly brackets in the context of the sender as in the > following 3 oneline examples. > 'Today is {Date today}' interpolate. > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. > 'In {#strings} you can escape \{ by prefixing it with \\' interpolate." > > | senderContext | > senderContext := thisContext sender. > ^ self class new: self size streamContents: [ :out | | stream | > stream := self readStream. > [ stream atEnd ] whileFalse: [ | currentChar | > (currentChar := stream next) == ${ > ifTrue: [ | expression result | > expression := stream upTo: $}. > result := Compiler new > evaluate: expression in: senderContext to: nil notifying: > nil ifFail: [ ^ nil ] logged: false. > out nextPutAll: result asString ] > ifFalse: [ > currentChar == $\ > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] > ] > ifFalse: [ out nextPut: currentChar ] ] ] ] > > It is a hack that could certainly be improved. And there is of course an > obvious security problem. > > Thoughts ? > > Sven > > >

Sept. 28, 2017

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

by ClÃ©ment BÃ©ra

Ok I used the other lib (libSDL2 instead of libSDL2-2.0.0) and it worked. 2017-09-28 16:07 GMT+02:00 ClÃ©ment BÃ©ra <bera.clement(a)gmail.com>: > > > 2017-09-28 15:33 GMT+02:00 Ronie Salgado <roniesalg(a)gmail.com>: > >> Hi Clement, >> >> The last time I checked, the 64 bits Mac VM version is eating the >> keyboard events, but not the mouse and other events. I guess that for the >> minheadless this is not required. The 32 bits version of Mac works by >> running the folowing script: >> >> FFIExternalStructure allSubclassesDo: #rebuildFieldAccessors >> >> I think that Pavel fixed this for Pharo 7. >> > > Ok. > > I had done that. > > But... > > I don't have any keyboard events. I have mouse and window events. I am > using Mac 32 bits. > > Ok... > > It seems that the keyboard events arrive as touch events... > > I will try to make that work. We'll see. > > Thanks > > > >> >> >> Btw for some reason in the one-click version of Pharo 32 bits on Mac >>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to >>> conflicts (the VM use randomly one lib or the other). I randomly chose one >>> that I use and deleted the other one, do you have advises on which one I >>> should prefer ? Maybe the events are working only with the other one ? >>> >> They should be a symlink. The correct one is the libSDL2-2.0. >> >> Best regards, >> Ronie >> >> 2017-09-28 15:02 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> Hi Ronie, Hi all, >>> >>> I am trying to use OSWindow/SDL2 in Pharo 6,1 stable, I successfully >>> opened the window and I can draw on it with Athens (with minor changes >>> compared to Pharo 4). However, the user events (keyboard, mouse, etc.) are >>> not working. It seems some constants are not initialized but I am not sure >>> what is the right way to initialize them. >>> >>> If I am correct Ronie you said you had a script to run to make OSWindow >>> work in the latest Pharo version. Can you give it to me so I can use it ? I >>> just need keyboard events for my use case. >>> >>> Btw for some reason in the one-click version of Pharo 32 bits on Mac >>> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to >>> conflicts (the VM use randomly one lib or the other). I randomly chose one >>> that I use and deleted the other one, do you have advises on which one I >>> should prefer ? Maybe the events are working only with the other one ? >>> >>> Thanks >>> >> >> >

Sept. 28, 2017

String Interpolation

by Sven Van Caekenberghe

Hi, I got into a little office discussion about string interpolation as it is done in different programming languages. In Pharo we have String>>#format: which is pretty nice. It works as follows: | x y | x := 123. y := #foo. 'x={1} and y={2}' format: { x. y }. It is also possible to use a dictionary with keys, like this: | x y | x := 123. y := #foo. 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings. Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work: | x y | x := 123. y := #foo. 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate. => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793' Here is the implementation I came up with: String>>#interpolate "Format the receiver by interpolating the evaluation of expressions in between curly brackets in the context of the sender as in the following 3 oneline examples. 'Today is {Date today}' interpolate. | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. 'In {#strings} you can escape \{ by prefixing it with \\' interpolate." | senderContext | senderContext := thisContext sender. ^ self class new: self size streamContents: [ :out | | stream | stream := self readStream. [ stream atEnd ] whileFalse: [ | currentChar | (currentChar := stream next) == ${ ifTrue: [ | expression result | expression := stream upTo: $}. result := Compiler new evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false. out nextPutAll: result asString ] ifFalse: [ currentChar == $\ ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ] ifFalse: [ out nextPut: currentChar ] ] ] ] It is a hack that could certainly be improved. And there is of course an obvious security problem. Thoughts ? Sven

Sept. 28, 2017

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

by ClÃ©ment BÃ©ra

2017-09-28 15:33 GMT+02:00 Ronie Salgado <roniesalg(a)gmail.com>: > Hi Clement, > > The last time I checked, the 64 bits Mac VM version is eating the keyboard > events, but not the mouse and other events. I guess that for the > minheadless this is not required. The 32 bits version of Mac works by > running the folowing script: > > FFIExternalStructure allSubclassesDo: #rebuildFieldAccessors > > I think that Pavel fixed this for Pharo 7. > Ok. I had done that. But... I don't have any keyboard events. I have mouse and window events. I am using Mac 32 bits. Ok... It seems that the keyboard events arrive as touch events... I will try to make that work. We'll see. Thanks > > > Btw for some reason in the one-click version of Pharo 32 bits on Mac there >> is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to conflicts (the >> VM use randomly one lib or the other). I randomly chose one that I use and >> deleted the other one, do you have advises on which one I should prefer ? >> Maybe the events are working only with the other one ? >> > They should be a symlink. The correct one is the libSDL2-2.0. > > Best regards, > Ronie > > 2017-09-28 15:02 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Hi Ronie, Hi all, >> >> I am trying to use OSWindow/SDL2 in Pharo 6,1 stable, I successfully >> opened the window and I can draw on it with Athens (with minor changes >> compared to Pharo 4). However, the user events (keyboard, mouse, etc.) are >> not working. It seems some constants are not initialized but I am not sure >> what is the right way to initialize them. >> >> If I am correct Ronie you said you had a script to run to make OSWindow >> work in the latest Pharo version. Can you give it to me so I can use it ? I >> just need keyboard events for my use case. >> >> Btw for some reason in the one-click version of Pharo 32 bits on Mac >> there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to >> conflicts (the VM use randomly one lib or the other). I randomly chose one >> that I use and deleted the other one, do you have advises on which one I >> should prefer ? Maybe the events are working only with the other one ? >> >> Thanks >> > >

Sept. 28, 2017

Re: [Pharo-dev] OSWindow in Pharo 6.1 stable

by Ronie Salgado

Hi Clement, The last time I checked, the 64 bits Mac VM version is eating the keyboard events, but not the mouse and other events. I guess that for the minheadless this is not required. The 32 bits version of Mac works by running the folowing script: FFIExternalStructure allSubclassesDo: #rebuildFieldAccessors I think that Pavel fixed this for Pharo 7. Btw for some reason in the one-click version of Pharo 32 bits on Mac there > is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to conflicts (the > VM use randomly one lib or the other). I randomly chose one that I use and > deleted the other one, do you have advises on which one I should prefer ? > Maybe the events are working only with the other one ? > They should be a symlink. The correct one is the libSDL2-2.0. Best regards, Ronie 2017-09-28 15:02 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi Ronie, Hi all, > > I am trying to use OSWindow/SDL2 in Pharo 6,1 stable, I successfully > opened the window and I can draw on it with Athens (with minor changes > compared to Pharo 4). However, the user events (keyboard, mouse, etc.) are > not working. It seems some constants are not initialized but I am not sure > what is the right way to initialize them. > > If I am correct Ronie you said you had a script to run to make OSWindow > work in the latest Pharo version. Can you give it to me so I can use it ? I > just need keyboard events for my use case. > > Btw for some reason in the one-click version of Pharo 32 bits on Mac there > is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to conflicts (the > VM use randomly one lib or the other). I randomly chose one that I use and > deleted the other one, do you have advises on which one I should prefer ? > Maybe the events are working only with the other one ? > > Thanks >

Sept. 28, 2017

OSWindow in Pharo 6.1 stable

by ClÃ©ment Bera

Hi Ronie, Hi all, I am trying to use OSWindow/SDL2 in Pharo 6,1 stable, I successfully opened the window and I can draw on it with Athens (with minor changes compared to Pharo 4). However, the user events (keyboard, mouse, etc.) are not working. It seems some constants are not initialized but I am not sure what is the right way to initialize them. If I am correct Ronie you said you had a script to run to make OSWindow work in the latest Pharo version. Can you give it to me so I can use it ? I just need keyboard events for my use case. Btw for some reason in the one-click version of Pharo 32 bits on Mac there is 2 SDL plugins (libSDL2-2.0.0 and libSDL2), which leads to conflicts (the VM use randomly one lib or the other). I randomly chose one that I use and deleted the other one, do you have advises on which one I should prefer ? Maybe the events are working only with the other one ? Thanks

Sept. 28, 2017

Re: [Pharo-dev] Iceberg Contribution Barrier

by Esteban Lorenzano

because that script is for 6.1 in Pharo 7 you do not need to update Iceberg (in fact, you do not need it in Pharo 6.1 either, this was for Pharo 6.0, when Iceberg was 0.4) please, take the instructions from Guilleâs place as your guide: https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… <https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to…> the only difference is that before creating your branch you need to do a fetch from origin/developent (I didnât submit the change because I donât know how to fork the wiki :P), cheers, Esteban > On 28 Sep 2017, at 04:45, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I wanted to make a fix to Iceberg. I downloaded a fresh Pharo 7.0 image via > Launcher, and pasted the Iceberg updating script from the GH readme [1]: > #('Iceberg-UI' 'Iceberg-Plugin-GitHub' 'Iceberg-Plugin' > 'Iceberg-Metacello-Integration' 'Iceberg-Libgit' > 'Iceberg' 'BaselineOfIceberg' 'LibGit-Core' 'BaselineOfLibGit') > do: [ :each | each asPackage removeFromSystem ]. > > Metacello new > baseline: 'Iceberg'; > repository: 'github://pharo-vcs/iceberg'; > load. > > I got "Instance of AnObsoleteIceMetacelloRepositoryAdapter did not > understand #isValid" > > 1. https://github.com/seandenigris/iceberg > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 28, 2017

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

by Torsten Bergmann

Why not make a backport to Pharo 6.1 with the new pinned message and provide it in a 60511 (last update is 60510 as of today). I know it is effort but that way you can be compatible and use the new methods. Â Thanks T. Â Gesendet:Â Donnerstag, 28. September 2017 um 10:19 Uhr Von:Â "Esteban Lorenzano" <estebanlm(a)gmail.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org> Betreff:Â Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo]) Â On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote:Â So it is integrated it Pharo 7Â Â 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: I did pull request for issueÂ 20426[https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages]. Â Interesting that Iceberg uses pinning in couple of places. I not touch it because it would not be single commit. And I have no idea how contribute in that case. I thing we are still in process to decide it.Â Anyway old messages are deprecated and users will continue work with auto transformation. Â and we cannot just change it right now because for the moment we want iceberg to be loadable in Pharo 6.1.Â so we will continue using deprecated messages until we drop compatibility. Â EstebanÂ Â 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: Â On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: Â Â Â Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: Â Hello. Â I guess we are agree to rename. I will prepare pull request for Pharo. And Squeak is up to you. Â Here is the new messages: - pinInMemory - unpinInMemory - isPinnedInMemory - setPinnedInMemory: Â What was decision about #pinInMemoryDuring: ? Do we need it? Â I understand Eliot in a way that there is no real point in unpinning objects. Hence pinDuring: is basically never useful and therefor adding a selectir has rather a negative impact Â +1 Â Â Norbert 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com[mailto:hannes.hirzel@gmail.com]>:+1 for pinInMemory It explains what it does. On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]> wrote: > Hi Norbert, > >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: >> >> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: >>> >>> Hi Denis, >>> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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. > > Well I think Denis' point is that pinInMemory removes ambiguity with pin for > other uses and I agree.Â So I for one am happy to change it to pinInMemory > et al. > >> >> Norbert >> >>>> >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: >>>>> Hi Denis, >>>>> >>>>> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@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@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@gmail.com[mailto:dionisiydk@gmail.com]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Anybody else? >>>>>>>> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >>>>>>>> <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]>: >>>>>>>>> >>>>>>>>> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >>>>>>>>> <dionisiydk@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. 28, 2017

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

by Esteban Lorenzano

> On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > So it is integrated it Pharo 7 > > 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: > I did pull request for issue 20426 <https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages>. > > Interesting that Iceberg uses pinning in couple of places. I not touch it because it would not be single commit. And I have no idea how contribute in that case. I thing we are still in process to decide it. > Anyway old messages are deprecated and users will continue work with auto transformation. and we cannot just change it right now because for the moment we want iceberg to be loadable in Pharo 6.1. so we will continue using deprecated messages until we drop compatibility. Esteban > > 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > > On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: > >> >> >> Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> >>> Hello. >>> >>> I guess we are agree to rename. I will prepare pull request for Pharo. And Squeak is up to you. >>> >>> Here is the new messages: >>> - pinInMemory >>> - unpinInMemory >>> - isPinnedInMemory >>> - setPinnedInMemory: >>> >>> What was decision about #pinInMemoryDuring: ? Do we need it? >>> >> I understand Eliot in a way that there is no real point in unpinning objects. Hence pinDuring: is basically never useful and therefor adding a selectir has rather a negative impact > > +1 > >> >> Norbert >>> 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com <mailto:hannes.hirzel@gmail.com>>: >>> +1 for pinInMemory >>> >>> It explains what it does. >>> >>> On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>> > Hi Norbert, >>> > >>> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>> >> >>> >> >>> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@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. >>> > >>> > Well I think Denis' point is that pinInMemory removes ambiguity with pin for >>> > other uses and I agree. So I for one am happy to change it to pinInMemory >>> > et al. >>> > >>> >> >>> >> 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. 28, 2017

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

by Denis Kudriashov

So it is integrated it Pharo 7 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > I did pull request for issue 20426 > <https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages>. > > Interesting that Iceberg uses pinning in couple of places. I not touch it > because it would not be single commit. And I have no idea how contribute in > that case. I thing we are still in process to decide it. > Anyway old messages are deprecated and users will continue work with auto > transformation. > > 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >> Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk(a)gmail.com>: >> >> Hello. >> >> I guess we are agree to rename. I will prepare pull request for Pharo. >> And Squeak is up to you. >> >> Here is the new messages: >> - pinInMemory >> - unpinInMemory >> - isPinnedInMemory >> - setPinnedInMemory: >> >> What was decision about #pinInMemoryDuring: ? Do we need it? >> >> I understand Eliot in a way that there is no real point in unpinning >> objects. Hence pinDuring: is basically never useful and therefor adding a >> selectir has rather a negative impact >> >> >> +1 >> >> >> Norbert >> >> 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: >> >>> +1 for pinInMemory >>> >>> It explains what it does. >>> >>> On 9/14/17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> > Hi Norbert, >>> > >>> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert(a)hartl.name> >>> 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> >>> >>> 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. >>> > >>> > Well I think Denis' point is that pinInMemory removes ambiguity with >>> pin for >>> > other uses and I agree. So I for one am happy to change it to >>> pinInMemory >>> > et al. >>> > >>> >> >>> >> Norbert >>> >> >>> >>>> >>> >>>> 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. 28, 2017