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

[Ben Coman]

On Mon, Sep 18, 2017 at 10:38 PM, Todd Blanchard  wrote:
> I think the asymmetry would drive me bananas.
> I prefer the original set.
>

+1. Think of it this wayun-"pinInMemory"
cheers -ben

> On Sep 18, 2017, at 7:28 AM, Tudor Girba  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  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 :
> +1 for pinInMemory
>
> It explains what it does.
>
> On 9/14/17, Eliot Miranda  wrote:
>> Hi Norbert,
>>
>>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl  wrote:
>>>
>>>
 Am 14.09.2017 um 00:09 schrieb Eliot Miranda :

 Hi Denis,

 On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov 
 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 :
>> Hi Denis,
>>
>>
>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov 
>>> 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 :
 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 
> wrote:
>
> Anybody else?
>
> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek
> :
>>
>>
>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>> :
>>> 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."
>
>
>
>
>
>

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

[Ben Coman]

On Mon, Sep 18, 2017 at 9:13 PM, Stephane Ducasse
 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

[Pharo-dev] Doubts on Garage (1st use)

[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

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

[Denis Kudriashov]

2017-09-18 16:28 GMT+02:00 Tudor Girba :

> 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 
> 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 :
> +1 for pinInMemory
>
> It explains what it does.
>
> On 9/14/17, Eliot Miranda  wrote:
> > Hi Norbert,
> >
> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl  wrote:
> >>
> >>
> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda  >:
> >>>
> >>> Hi Denis,
> >>>
> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <
> dionisi...@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 :
> > Hi Denis,
> >
> >
> >> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov  >
> >> 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 :
> >>> 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 
>  wrote:
> 
>  Anybody else?
> 
>  2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>  :
> >
> >
> > 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
> > :
> >> 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."
>
>
>
>
>

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

[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  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 > > 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 > >:
>> +1 for pinInMemory
>> 
>> It explains what it does.
>> 
>> On 9/14/17, Eliot Miranda  wrote:
>> > Hi Norbert,
>> >
>> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl  wrote:
>> >>
>> >>
>> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda :
>> >>>
>> >>> Hi Denis,
>> >>>
>> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov 
>> >>> 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 :
>> > Hi Denis,
>> >
>> >
>> >> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov 
>> >> 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 :
>> >>> 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 
>>  wrote:
>> 
>>  Anybody else?
>> 
>>  2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>>  :
>> >
>> >
>> > 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>> > :
>> >> 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
>> >
>> 
>> >>>
>> >>
>> 
>>

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

[Tudor Girba]

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  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 :
> +1 for pinInMemory
> 
> It explains what it does.
> 
> On 9/14/17, Eliot Miranda  wrote:
> > Hi Norbert,
> >
> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl  wrote:
> >>
> >>
> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda :
> >>>
> >>> Hi Denis,
> >>>
> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov 
> >>> 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 :
> > Hi Denis,
> >
> >
> >> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov 
> >> 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 :
> >>> 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 
>  wrote:
> 
>  Anybody else?
> 
>  2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>  :
> >
> >
> > 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
> > :
> >> 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."

[Pharo-dev] [Pharo 7.0-dev] Build #128: SUCCESS

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #128 was: SUCCESS.

Could not extract further issue information from commit message: Merge pull 
request #287 from 
pavel-krivanek/20428-ClassTest-Kernel-Tests-is-dependent-on-System-Changes

20428-ClassTest-Kernel-Tests-is-dependent-on-System-Changes
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/128/

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

[Stephane Ducasse]

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?

Stef

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

[Mariano Martinez Peck]

On Thu, Sep 14, 2017 at 4:29 PM, Torsten Bergmann  wrote:

> "Denis Kudriashov" wrote
> >Thank's guys for comments. And thank's Torsten for this initiative. I
> will merge your changes soon.
>
> No - we have to thank you. For Calypso, for accepting the community
> decision and (in advance) for
> merging the first Calypso pull request.
>
>
+1. I am already enjoying it since a couple of months and Denis was also
quick to incorporate my suggestions :)


BTW, RIGHT, of course.



> I'm pretty sure the next Pharo versions will rock even more ...
>
> Bye
> T.
>
>


-- 
Mariano
http://marianopeck.wordpress.com

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

[Denis Kudriashov]

I did pull request for issue 20426
.

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 :

>
> On Sep 14, 2017, at 7:07 AM, Norbert Hartl  wrote:
>
>
>
> Am 14.09.2017 um 10:17 schrieb Denis Kudriashov :
>
> 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 :
>
>> +1 for pinInMemory
>>
>> It explains what it does.
>>
>> On 9/14/17, Eliot Miranda  wrote:
>> > Hi Norbert,
>> >
>> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl  wrote:
>> >>
>> >>
>> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda > >:
>> >>>
>> >>> Hi Denis,
>> >>>
>> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <
>> dionisi...@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 :
>> > Hi Denis,
>> >
>> >
>> >> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <
>> dionisi...@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 > >:
>> >>> 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 > >
>>  wrote:
>> 
>>  Anybody else?
>> 
>>  2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>>  :
>> >
>> >
>> > 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>> > :
>> >> 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:
>> >

Re: [Pharo-dev] Esteban's ChangeLog week of 11 September 2017

[Denis Kudriashov]

>
>  But well... I'm happy to say that we have a Pharo 7.0 running 100% on
> headless mode with an SDL2 window
>  serving the world, on macOS 32bits.


This is super cool.
Interesting what the size of VM in that case?

2017-09-18 8:00 GMT+02:00 :

> Hello!
>
> This is my weekly ChangeLog, from 11 September 2017 to 17 September 2017.
> You can see it in a better format by going here:
> http://log.smallworks.eu/web/search?from=11/9/2017&to=17/9/2017
>
> ChangeLog
> =
>
> 14 September 2017:
> --
>
> *Since Ronie came to spend two weeks with us, I made a "stop the
> world" call to work with him in a couple
> of projects I want to integrate in Pharo.
>
> So, I've been working on that last two days: Ronie has a working
> implementation of a "real headless"
> VM that can chose to start a world using SDL2.
>
> Why we want this? Because of many reasons... one of them is because is
> lame to open a hidden window when
> we want to use just a command line, but also because the desition of
> opening a window (the World or
> whatever) should be responsibility of the image (the user), not the VM.
>
> Anyway, the problem is that Ronie made his VM using CMake and we use
> plain Makefiles (a very complex
> structure of makefiles), so we needed to convert that.
>
> Also, since this is experimental, a lot ot small details are missing
> and we are running to supply them.
>
> But well... I'm happy to say that we have a Pharo 7.0 running 100% on
> headless mode with an SDL2 window
> serving the world, on macOS 32bits.
>
> Tomorrow we will look to fix some remaining details and to expand the
> source to linux and windows (32bits),
> then we will jump to 64bits.
>
>
> 11 September 2017:
> --
>
> *I just released [iceberg v0.5.8](https://github.com/
> pharo-vcs/iceberg/releases/tag/v0.5.8).
>
> This version is a maintenance version, and contains this fixes:
>
> * speed up of commits by not traversing the full tree to detect staged
> files (just compare later)
> * fix refresh option in PR tool
> * do not use hardcoded colours in diffs
> * add guessing of source dirs to easy adding of local repositories
> * recategorise methods
>
> It will be integrated on Pharo 7.0 in on [case: 20406](
> https://pharo.fogbugz.com/f/cases/20406).
>
> *Last week I was at ESUG :)
>
> Anyway, I'm working on [tonel](http://github.com/pharo-vcs/tonel),
> the new fileformat made to replace
> [filetree](http://github.com/pharo-vcs/filetree) (because of many
> reasons, being the non-scalable nature of
> file-per-method strategy the most important).
>
>
> cheers!
> Esteban
>
>