- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About a discord channel for the mooc?

by Esteban Lorenzano

> On 18 Sep 2017, at 15:13, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi guys > > The students of the lectures at Prague and the forthcoming mooc will > be strongly > suggested to use discord. > So now how can we organise it? > How do we create a channel? I just created a channel #mooc Esteban > > Stef >

Sept. 19, 2017

TechTalk today, 17h UTC "Free talk Pharo 7"

by Esteban Lorenzano

Hi, Today we have the montly TechTalk at 17hs UTC. x So far, I think this is something I would like to talk: - new development process status - tonel 1.0/iceberg 0.6 status butâ¦ subject is âfree talkâ so prepare your questions/opinions :) Esteban

Sept. 19, 2017

[Pharo 7.0-dev] Build #129: SUCCESS

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

There is a new Pharo build available! The status of the build #129 was: SUCCESS. Could not extract further issue information from commit message: Merge pull request #288 from pavel-krivanek/20429-ContextTesttestSetUp-is-dependent-on-Opal 20429-ContextTesttestSetUp-is-dependent-on-Opal Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 19, 2017

Re: [Pharo-dev] About a discord channel for the mooc?

by Peter UhnÃ¡k

I wonder whether it would be nice to have a localized channel... e.g. #learning-cz , #learning-fr so people could feel more at home and discuss with their peers in their native language. Also please do not call it newbies... Peter On Tue, Sep 19, 2017 at 9:04 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Yes may be mooc or newbies > I checked learning help and it can be intimidating for noobs > > stef > > On Tue, Sep 19, 2017 at 4:08 AM, Ben Coman <btc(a)openinworld.com> wrote: > > On Mon, Sep 18, 2017 at 9:13 PM, Stephane Ducasse > > <stepharo.self(a)gmail.com> wrote: > >> Hi guys > >> > >> The students of the lectures at Prague and the forthcoming mooc will > >> be strongly > >> suggested to use discord. > >> So now how can we organise it? > >> How do we create a channel? > > > > I've added you to @channel-admins so you can create it yourself. You > > should see a plus sign above the channel list. > > > > btw, I had originally set up #learning-help for questions related to > > mooc and documentation, > > but its drifted to broader topics (I think the tagline is not > > prominent enough). > > Maybe you want something more targeted like simply #mooc ? > > > > cheers -ben > > > >

Sept. 19, 2017

Re: [Pharo-dev] About a discord channel for the mooc?

by Stephane Ducasse

Yes may be mooc or newbies I checked learning help and it can be intimidating for noobs stef On Tue, Sep 19, 2017 at 4:08 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Mon, Sep 18, 2017 at 9:13 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: >> Hi guys >> >> The students of the lectures at Prague and the forthcoming mooc will >> be strongly >> suggested to use discord. >> So now how can we organise it? >> How do we create a channel? > > I've added you to @channel-admins so you can create it yourself. You > should see a plus sign above the channel list. > > btw, I had originally set up #learning-help for questions related to > mooc and documentation, > but its drifted to broader topics (I think the tagline is not > prominent enough). > Maybe you want something more targeted like simply #mooc ? > > cheers -ben >

Sept. 19, 2017

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

by Ben Coman

On Mon, Sep 18, 2017 at 10:38 PM, Todd Blanchard <tblanchard(a)mac.com> wrote: > I think the asymmetry would drive me bananas. > I prefer the original set. > +1. Think of it this way.... un-"pinInMemory" cheers -ben > On Sep 18, 2017, at 7:28 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > In this case, it would sound better to have: > - pinInMemory > - unpinFromMemory > - isPinnedInMemory > - setPinnedInMemory: > > Cheers, > Doru > > > On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 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? > > 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 >>> >> > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > >

Sept. 19, 2017

Re: [Pharo-dev] About a discord channel for the mooc?

by Ben Coman

On Mon, Sep 18, 2017 at 9:13 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guys > > The students of the lectures at Prague and the forthcoming mooc will > be strongly > suggested to use discord. > So now how can we organise it? > How do we create a channel? I've added you to @channel-admins so you can create it yourself. You should see a plus sign above the channel list. btw, I had originally set up #learning-help for questions related to mooc and documentation, but its drifted to broader topics (I think the tagline is not prominent enough). Maybe you want something more targeted like simply #mooc ? cheers -ben

Sept. 19, 2017

Doubts on Garage (1st use)

by Casimiro de Almeida Barreto

Good evening, I was trying to sanitize statements, but something went awkward. The following non sanitized codelet works ok: Â Â Â str := 'INSERT INTO chaves_de_encriptacao ( Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â numero_funcional, Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â chave_privada, Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â chave_publica) VALUES (''', Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self personId leaId asString,''', ''', Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self keyPair privateKey asAsn1DerBytes asByteArray hex,''', ''', Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â self keyPair publicKey asAsn1DerBytes asByteArray hex,''')'. Â Â Â [ dbConnection execute: str ] on: Exception do: [ ^ false ]. But sanitized one: Â Â Â str := dbConnection createStatement: 'INSERT INTO chaves_de_encriptacao ( numero_funcional, chave_privada, chave_publica) VALUES (''?'', ''?'', ''?'')'. Â Â Â str prepare. Â Â Â str at: 1 bind: self personId leaId asString. Â Â Â str at: 2 bind: self keyPair privateKey asAsn1DerBytes asByteArray hex. Â Â Â str at: 3 bind: self keyPair publicKey asAsn1DerBytes asByteArray hex. Â Â Â str execute. returns exception mysqld_stmt_send_long_data (obviously same thing happens with the shorthand str := dbConnection prepare: ... And I inspect most things but could not understand what's going bad. As SQL is not my field, I wonder if someone could help to elucidate what's going on. Best regards, Casimiro Barreto

Sept. 18, 2017

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

by Denis Kudriashov

2017-09-18 16:28 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi, > > In this case, it would sound better to have: > - pinInMemory > - unpin*From*Memory > Then first message can be named #pinToMemory. But I prefer simple InMemory for both cases. > - isPinnedInMemory > - setPinnedInMemory: > > Cheers, > Doru > > > On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > 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? > > 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 > >> > > > > > > -- > www.tudorgirba.com > www.feenk.com > > "Every thing has its own flow." > > > > > >

Sept. 18, 2017

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

by Todd Blanchard

I think the asymmetry would drive me bananas. I prefer the original set. > On Sep 18, 2017, at 7:28 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > In this case, it would sound better to have: > - pinInMemory > - unpinFromMemory > - isPinnedInMemory > - setPinnedInMemory: > > Cheers, > Doru > > >> On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> 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? >> >> 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> 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 >> >> >> > >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Every thing has its own flow." > > > > >

Sept. 18, 2017