Re: [Pharo-dev] Floating-point numbers with radix (non-decimal)?

[James Foster]

> On Sep 5, 2019, at 12:40 PM, James Foster  wrote:
> 
> So, in ‘2r1e10’ the exponent is four,
ten [I edited the example but missed this place]
> so there are ten zeros (’10’ is decimal) after the 1, not two zeros (binary). 

Re: [Pharo-dev] Floating-point numbers with radix (non-decimal)?

[James Foster]

> On Sep 5, 2019, at 9:38 AM, ducasse  wrote:
> 
> Thanks for the explanation. 
> We should pick solution one: 
>   
>> Enforce a uppercase and lowercase distinction (digit and exponent 
>> respectively);
> 
> Why would we need to have HEX in lowercase for exponent?
> Is there any adavantage. 
> I found  2r1.111eef quite unreadable 2r1.111eEF

I should have said
1. Enforce an uppercase and lower case distinction (digit and exponent 
[lead-in token] respectively)

So for option 1, ‘e’ is always a token indicating that an exponent follows, 
while ‘E’ is always the value fourteen (a ‘digit’). This would mean that 
‘16rff’ would be illegal (since lowercase is not allowed for a hex digit).

I believe exponents are always base ten, even if the primary part of the number 
is a different base. So, in ‘2r1e10’ the exponent is four, so there are ten 
zeros (’10’ is decimal) after the 1, not two zeros (binary). There would never 
be a hex exponent (‘eEF’ would be illegal, not 239 zeros!).

James

> 
>> On 5 Sep 2019, at 15:05, James Foster > > wrote:
>> 
>> Hi Stef,
>> 
>> The question is “How should it work?” How do we distinguish whether the 
>> character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or is 
>> a representation for “what follows is an exponent”? For example, it is easy 
>> to recognize that the radix-based integer literal ‘16rFF’ is the 
>> SmallInteger 255 and that the float literal ‘1.23e3’ is 1230.0 (a 
>> SmallDouble in GemStone). 
>> 
>> For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting 
>> lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be the 
>> same as ‘2r’ or 15 (permitting floating-point numbers to have a radix). 
>> This introduces an ambiguity in interpreting the character ‘e’ (or ‘E’)—is 
>> it a hexadecimal digit or is it an exponent identifier? 
>> 
>> I believe that there are the following alternatives:
>> Enforce a uppercase and lowercase distinction (digit and exponent 
>> respectively);
>> Allow exponents on decimal (base ten) numbers only;
>> Interpret ‘e’ as a hexadecimal digit if the radix is >= 15 (allowing 
>> exponents on lower bases); or
>> Develop a new syntax to introduce exponents.
>> I believe that #3 is the current approach, and could be seen as #2 relaxed 
>> to allow exponents on numbers with a radix of 2-14. 
>> 
>> It seems to me that the primary value of exponents on non-decimal (base ten) 
>> numbers is to represent binary numbers (2r1e63 is more readable than 
>> 2r1000). It 
>> seems to me that the value of exponents on numbers with a base above 10 is 
>> less pronounced (16r1E15 is better than 16r1000, but only a bit 
>> better). Mostly, I’d assert that the value of exponents for radix 16 is not 
>> worth a new syntax (excluding #4 above).
>> 
>> James
>> 
>>> On Sep 4, 2019, at 10:36 PM, ducasse >> > wrote:
>>> 
>>> Hi nicolas
>>> 
>>> let us fix this :)
>>> 
>>> why 15r1.2e1 is not working?
>>> why 15r1.2e1 is not equals to 15r1.2E1?
>>> why would we need a new syntax?
>>> 
>>> Stef
 On 5 Sep 2019, at 00:19, Nicolas Cellier 
 >>> > wrote:
 
 Once upon a time, only uppercase letters were accpeted as extra digits (in 
 base > 10) for both int and float
 
 Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E
 
 Then it was considered better to understand hexadecimal numbers with 
 lowercase too...
 and alternate-base Float became ambiguous and were never fixed :(
 
 This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 
 15r1.2#e1 ...
 Changing Smalltalk syntax is among the most difficult decisions, expect 
 outcry ;)
 Maybe because it's too easy :)
 
 
 Le jeu. 5 sept. 2019 à 00:04, James Foster >>> > a écrit :
 14r1.2e1 "16.0"
 15r1.2e1 “1.195851851851852"
 
 Does it make sense to have exponents for numbers that are not base 10? 
 There are tests that have large exponents for binary numbers and we are 
 not sure how to handle this in GemStone.
 
 James
 
>>> 
>> 
> 

[Pharo-dev] possible Windows Update "1903" Iceberg problem

[George Ganea]

Hi all,

I just tested the dlls and it looks like it’s working. I say "looks like” only 
because my internet connection is a bit dodgy as I’m on a train. 
But it did start downloading and loading the github repos, so the fix works 
from my point of view.

Cheers,
George

> Thank you both!
> 
> We will test and come back with feedback.
> 
> Cheers,
> Doru
> 
> 
> 
> > On Sep 5, 2019, at 2:47 PM, Guillermo Polito  > > wrote:
> > 
> > Hi all,
> > 
> > First, please, we would love if you can test what Pablo proposed and give 
> > us some feedback.
> > It will be super helpful to evaluate if it is worth to generate a new vm 
> > release!!!
> > 
> > Also, besides what Pablo said in the previous email, I wanted to share some 
> > more precisions.
> > 
> > === Precisions on the problem ===
> > 
> > First, just to clarify, we isolated the issue happening only on Windows10 
> > #1903 on Pharo64 bits.
> > Pharo32 bits does work well on that update number does work well.
> > 
> > The origin of the problem seems to be a bad integration between libssh2 
> > 1.7.0 and the windows CNG crypto layer, which seemingly changed in this 
> > update.
> > 
> > === The path to the solution ===
> > 
> > The solution was theoretically super straight forward (upgrade to openssh 
> > 1.9.0 + openssl for crypto instead of windows CNG).
> > 
> > It was however super time consuming.
> >  - installing the windows update #1903 to test, reproduce and understand 
> > the issue took for us a couple of hours, reconfiguring the virtual machines 
> > to enlarge disks to download it, then install it...
> >  - compiling openssl took literally the entire afternoon yesterday in 
> > Pablo’s machine.
> >  - then we found several bugs in cmake openssl integration when compiling 
> > libssh2 on Cigwin + mingw, because life cannot be easy ^^
> > 
> > And fortunately, we found no incompatibilities between the different 
> > versions of these libraries (and libgit2 too!) so it could have been more 
> > time consuming :P.
> > 
> > === Alternative solutions and workarounds ===
> > 
> > Alternatively for testing the libraries that Pablo sent in the previous 
> > email, there are some other workarounds that people could try in the 
> > meantime:
> > 
> > 1) Use Pharo32 bits, which as I said above, does not have the problem.
> > 
> > 2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello 
> > integration to HTTP by default).
> > 
> > 
> > 
> > We are also evaluating setting HTTPS by default in Iceberg as it is simpler 
> > to setup.
> > Github, Gitkraken do use HTTPS as a sensible default too.
> > 
> > Cheers

Re: [Pharo-dev] Floating-point numbers with radix (non-decimal)?

[ducasse]

Thanks for the explanation. 
We should pick solution one: 

> Enforce a uppercase and lowercase distinction (digit and exponent 
> respectively);

Why would we need to have HEX in lowercase for exponent?
Is there any adavantage. 
I found  2r1.111eef quite unreadable 2r1.111eEF


> On 5 Sep 2019, at 15:05, James Foster  wrote:
> 
> Hi Stef,
> 
> The question is “How should it work?” How do we distinguish whether the 
> character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or is 
> a representation for “what follows is an exponent”? For example, it is easy 
> to recognize that the radix-based integer literal ‘16rFF’ is the SmallInteger 
> 255 and that the float literal ‘1.23e3’ is 1230.0 (a SmallDouble in 
> GemStone). 
> 
> For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting 
> lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be the 
> same as ‘2r’ or 15 (permitting floating-point numbers to have a radix). 
> This introduces an ambiguity in interpreting the character ‘e’ (or ‘E’)—is it 
> a hexadecimal digit or is it an exponent identifier? 
> 
> I believe that there are the following alternatives:
> Enforce a uppercase and lowercase distinction (digit and exponent 
> respectively);
> Allow exponents on decimal (base ten) numbers only;
> Interpret ‘e’ as a hexadecimal digit if the radix is >= 15 (allowing 
> exponents on lower bases); or
> Develop a new syntax to introduce exponents.
> I believe that #3 is the current approach, and could be seen as #2 relaxed to 
> allow exponents on numbers with a radix of 2-14. 
> 
> It seems to me that the primary value of exponents on non-decimal (base ten) 
> numbers is to represent binary numbers (2r1e63 is more readable than 
> 2r1000). It seems 
> to me that the value of exponents on numbers with a base above 10 is less 
> pronounced (16r1E15 is better than 16r1000, but only a bit 
> better). Mostly, I’d assert that the value of exponents for radix 16 is not 
> worth a new syntax (excluding #4 above).
> 
> James
> 
>> On Sep 4, 2019, at 10:36 PM, ducasse > > wrote:
>> 
>> Hi nicolas
>> 
>> let us fix this :)
>> 
>> why 15r1.2e1 is not working?
>> why 15r1.2e1 is not equals to 15r1.2E1?
>> why would we need a new syntax?
>> 
>> Stef
>>> On 5 Sep 2019, at 00:19, Nicolas Cellier 
>>> >> > wrote:
>>> 
>>> Once upon a time, only uppercase letters were accpeted as extra digits (in 
>>> base > 10) for both int and float
>>> 
>>> Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E
>>> 
>>> Then it was considered better to understand hexadecimal numbers with 
>>> lowercase too...
>>> and alternate-base Float became ambiguous and were never fixed :(
>>> 
>>> This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 
>>> 15r1.2#e1 ...
>>> Changing Smalltalk syntax is among the most difficult decisions, expect 
>>> outcry ;)
>>> Maybe because it's too easy :)
>>> 
>>> 
>>> Le jeu. 5 sept. 2019 à 00:04, James Foster >> > a écrit :
>>> 14r1.2e1 "16.0"
>>> 15r1.2e1 “1.195851851851852"
>>> 
>>> Does it make sense to have exponents for numbers that are not base 10? 
>>> There are tests that have large exponents for binary numbers and we are not 
>>> sure how to handle this in GemStone.
>>> 
>>> James
>>> 
>> 
> 

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[Tudor Girba]

Thank you both!

We will test and come back with feedback.

Cheers,
Doru



> On Sep 5, 2019, at 2:47 PM, Guillermo Polito  
> wrote:
> 
> Hi all,
> 
> First, please, we would love if you can test what Pablo proposed and give us 
> some feedback.
> It will be super helpful to evaluate if it is worth to generate a new vm 
> release!!!
> 
> Also, besides what Pablo said in the previous email, I wanted to share some 
> more precisions.
> 
> === Precisions on the problem ===
> 
> First, just to clarify, we isolated the issue happening only on Windows10 
> #1903 on Pharo64 bits.
> Pharo32 bits does work well on that update number does work well.
> 
> The origin of the problem seems to be a bad integration between libssh2 1.7.0 
> and the windows CNG crypto layer, which seemingly changed in this update.
> 
> === The path to the solution ===
> 
> The solution was theoretically super straight forward (upgrade to openssh 
> 1.9.0 + openssl for crypto instead of windows CNG).
> 
> It was however super time consuming.
>  - installing the windows update #1903 to test, reproduce and understand the 
> issue took for us a couple of hours, reconfiguring the virtual machines to 
> enlarge disks to download it, then install it...
>  - compiling openssl took literally the entire afternoon yesterday in Pablo’s 
> machine.
>  - then we found several bugs in cmake openssl integration when compiling 
> libssh2 on Cigwin + mingw, because life cannot be easy ^^
> 
> And fortunately, we found no incompatibilities between the different versions 
> of these libraries (and libgit2 too!) so it could have been more time 
> consuming :P.
> 
> === Alternative solutions and workarounds ===
> 
> Alternatively for testing the libraries that Pablo sent in the previous 
> email, there are some other workarounds that people could try in the meantime:
> 
> 1) Use Pharo32 bits, which as I said above, does not have the problem.
> 
> 2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello 
> integration to HTTP by default).
> 
> 
> 
> We are also evaluating setting HTTPS by default in Iceberg as it is simpler 
> to setup.
> Github, Gitkraken do use HTTPS as a sensible default too.
> 
> Cheers
> 
> 
>> El 5 sept 2019, a las 14:28, teso...@gmail.com escribió:
>> 
>> Hi all,
>> with Guille we have been working in this issue since Monday, it
>> was a complicated issue to solve as we require to compile and test
>> different versions of the libgit2 library and its dependencies
>> (openssl and libssh2).
>> We have a workaround for using ssh in windows.
>> We have produced a new set of libraries with the correct versions.
>> These libraries are available in
>> https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1
>> The idea is to start testing them while we are working on a new
>> release of the VM.
>> 
>> Cheers,
>> Pablo
>> 
>> On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito
>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Sorry for not communicating better :).
>>> We know this is an important issue and we did move it to top priority even 
>>> prior to this email ;).
>>> Doru, to answer you, what people can do for the moment is to test what we 
>>> are going to propose in a couple of hours in your windows machines.
>>> With Pablo we have tested in several Windows 10 machines pre- and post- 
>>> update 1903. Still we would like people testing on their setups and other 
>>> windows versions
>>> 
>>> We have been working the last couple of days debugging openssh and libgit, 
>>> and building a version with a more up-to-date version of openssh.
>>> We will come back later this morning / early afternoon with
>>> - a new vm setup using up to date versions of openssh
>>> - a description of workarounds for those tied to old versions of the VM
>>> So people can test.
>>> 
>>> Cheers,
>>> Guille and Pablo
>>> 
 El 4 sept 2019, a las 8:38, ducasse  escribió:
 
 I saw everybody super busy and I imagine that they will reply soon.
 I’m travelling to give Pharo lectures.
 
> On 3 Sep 2019, at 19:23, Tudor Girba  wrote:
> 
> Hi,
> 
> Is there a way to speed the work on this one?
> 
> At this moment, people cannot load any code in Pharo on Windows 10.
> 
> Cheers,
> Doru
> 
> --
> www.feenk.com
> "Every thing has its own flow."
> 
>> On 28 Aug 2019, at 16:20, ducasse  wrote:
>> 
>> tx doru
>> 
>> Stef
>> 
>>> On 28 Aug 2019, at 16:01, Tudor Girba  wrote:
>>> 
>>> Hi
>>> 
>>> I opened an issue: https://github.com/pharo-project/pharo/issues/4437
>>> 
>>> I believe this should be treated as critical given that we cannot load 
>>> code in Pharo 7 (or 8) which makes it almost useless for users.
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
 On Aug 27, 2019, at 10:54 AM, Tudor Girba  wrote:
 
 Hi,
 
 We just encountered this on two different machines. We got this after 

Re: [Pharo-dev] Floating-point numbers with radix (non-decimal)?

[Nicolas Cellier]

Though base 16 is what is used elsewhere (for example %a of C/C++ printf).
It marries both compactness and exactness which is good for interchange
format.

Le jeu. 5 sept. 2019 à 15:06, James Foster  a
écrit :

> Hi Stef,
>
> The question is “How should it work?” How do we distinguish whether the
> character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or
> is a representation for “what follows is an exponent”? For example, it is
> easy to recognize that the radix-based integer literal ‘16rFF’ is the
> SmallInteger 255 and that the float literal ‘1.23e3’ is 1230.0 (a
> SmallDouble in GemStone).
>
> For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting
> lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be
> the same as ‘2r’ or 15 (permitting floating-point numbers to have a
> radix). This introduces an ambiguity in interpreting the character ‘e’ (or
> ‘E’)—is it a hexadecimal digit or is it an exponent identifier?
>
> I believe that there are the following alternatives:
>
>1. Enforce a uppercase and lowercase distinction (digit and exponent
>respectively);
>2. Allow exponents on decimal (base ten) numbers only;
>3. Interpret ‘e’ as a hexadecimal digit if the radix is >= 15
>(allowing exponents on lower bases); or
>4. Develop a new syntax to introduce exponents.
>
> I believe that #3 is the current approach, and could be seen as #2 relaxed
> to allow exponents on numbers with a radix of 2-14.
>
> It seems to me that the primary value of exponents on non-decimal (base
> ten) numbers is to represent binary numbers (2r1e63 is more readable than
> 2r1000). It
> seems to me that the value of exponents on numbers with a base above 10 is
> less pronounced (16r1E15 is better than 16r1000, but only a bit
> better). Mostly, I’d assert that the value of exponents for radix 16 is not
> worth a new syntax (excluding #4 above).
>
> James
>
> On Sep 4, 2019, at 10:36 PM, ducasse  wrote:
>
> Hi nicolas
>
> let us fix this :)
>
> why 15r1.2e1 is not working?
> why 15r1.2e1 is not equals to 15r1.2E1?
> why would we need a new syntax?
>
> Stef
>
> On 5 Sep 2019, at 00:19, Nicolas Cellier <
> nicolas.cellier.aka.n...@gmail.com> wrote:
>
> Once upon a time, only uppercase letters were accpeted as extra digits (in
> base > 10) for both int and float
>
> Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E
>
> Then it was considered better to understand hexadecimal numbers with
> lowercase too...
> and alternate-base Float became ambiguous and were never fixed :(
>
> This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1
> 15r1.2#e1 ...
> Changing Smalltalk syntax is among the most difficult decisions, expect
> outcry ;)
> Maybe because it's too easy :)
>
>
> Le jeu. 5 sept. 2019 à 00:04, James Foster  a
> écrit :
>
>> 14r1.2e1 "16.0"
>> 15r1.2e1 “1.195851851851852"
>>
>> Does it make sense to have exponents for numbers that are not base 10?
>> There are tests that have large exponents for binary numbers and we are not
>> sure how to handle this in GemStone.
>>
>> James
>>
>>
>
>

[Pharo-dev] [Pharo 8.0] Build #700: Fixes issue 3068

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #700 was: FAILURE.

The Pull Request #4502 was integrated: "Fixes issue 3068"
Pull request url: https://github.com/pharo-project/pharo/pull/4502

Issue Url: https://github.com/pharo-project/pharo/issues/3068
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/700/

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[Christopher Fuhrman]

This sounds great, Pablo.

Just to clarify on how to test, if I'm using Pharo Launcher, do I just
replace the .dll files from your .zip
in C:\Users\{me}\Documents\Pharo\vms\80-x64 (and/or \70-x64)?

On Thu, 5 Sep 2019 at 09:34, teso...@gmail.com  wrote:

> Hi all,
>  with Guille we have been working in this issue since Monday, it
> was a complicated issue to solve as we require to compile and test
> different versions of the libgit2 library and its dependencies
> (openssl and libssh2).
> We have a workaround for using ssh in windows.
> We have produced a new set of libraries with the correct versions.
> These libraries are available in
> https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1
> The idea is to start testing them while we are working on a new
> release of the VM.
>
> Cheers,
> Pablo
>
> On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito
>  wrote:
> >
> > Hi all,
> >
> > Sorry for not communicating better :).
> > We know this is an important issue and we did move it to top priority
> even prior to this email ;).
> > Doru, to answer you, what people can do for the moment is to test what
> we are going to propose in a couple of hours in your windows machines.
> > With Pablo we have tested in several Windows 10 machines pre- and post-
> update 1903. Still we would like people testing on their setups and other
> windows versions
> >
> > We have been working the last couple of days debugging openssh and
> libgit, and building a version with a more up-to-date version of openssh.
> > We will come back later this morning / early afternoon with
> >  - a new vm setup using up to date versions of openssh
> >  - a description of workarounds for those tied to old versions of the VM
> > So people can test.
> >
> > Cheers,
> > Guille and Pablo
> >
> > > El 4 sept 2019, a las 8:38, ducasse 
> escribió:
> > >
> > > I saw everybody super busy and I imagine that they will reply soon.
> > > I’m travelling to give Pharo lectures.
> > >
> > >> On 3 Sep 2019, at 19:23, Tudor Girba  wrote:
> > >>
> > >> Hi,
> > >>
> > >> Is there a way to speed the work on this one?
> > >>
> > >> At this moment, people cannot load any code in Pharo on Windows 10.
> > >>
> > >> Cheers,
> > >> Doru
> > >>
> > >> --
> > >> www.feenk.com
> > >> "Every thing has its own flow."
> > >>
> > >>> On 28 Aug 2019, at 16:20, ducasse  wrote:
> > >>>
> > >>> tx doru
> > >>>
> > >>> Stef
> > >>>
> >  On 28 Aug 2019, at 16:01, Tudor Girba  wrote:
> > 
> >  Hi
> > 
> >  I opened an issue:
> https://github.com/pharo-project/pharo/issues/4437
> > 
> >  I believe this should be treated as critical given that we cannot
> load code in Pharo 7 (or 8) which makes it almost useless for users.
> > 
> >  Cheers,
> >  Doru
> > 
> > 
> > > On Aug 27, 2019, at 10:54 AM, Tudor Girba 
> wrote:
> > >
> > > Hi,
> > >
> > > We just encountered this on two different machines. We got this
> after the update to Windows 1903. For us it’s a critical issue at this
> point. What can we do to help with this?
> > >
> > > Cheers,
> > > Doru
> > >
> > >
> > >
> > >> On Aug 17, 2019, at 12:50 PM, Ben Coman 
> wrote:
> > >>
> > >> hi Stef,
> > >> I feel you missed my point. Probably I wasn't clear this has
> already been tested with latest Pharo 8 launched by PharoLauncher.
> > >> The problem occurs with Pharo 7.0.3(64 bit) and with
> Pharo8.0-SNAPSHOT-build.635(64 bit)
> > >> after Microsoft Windows Update 1903...
> > >>
> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-1803-to-1903-forced-upgrade.html
> > >>
> > >> If indeed 1903 is the cause, with this update now being *forced*
> down on people, this will potentially soon impact more and more Windows
> users.
> > >> But my guess that 1903 is the culprit needs to be confirmed.
> > >> So I am requesting someone with access to multiple Windows
> machines directly compare a 1903 machine with a pre-1903 machine.
> > >>
> > >> cheers -ben
> > >>
> > >> On Sat, 17 Aug 2019 at 12:58, ducasse 
> wrote:
> > >> Hi ben
> > >>
> > >> in the pharo launcher if you click on P8.0 (development version)
> you get access to all the builds.
> > >>
> > >> Stef
> > >>
> > >>> On 16 Aug 2019, at 16:02, Ben Coman  wrote:
> > >>>
> > >>> IThis morning the May 2019 Windows Update "1903" forced itself
> onto my computer and now 64-bits Pharo seems to have a problem with
> git_remote_fetch() FFI callout.  I no longer have a non-1903 machine to
> directly compare behaviour before "1903".  Can someone familiar with this
> area with both "pre-1903" and "1903" machines triage whether "1903" is
> indeed the cause?
> > >>>
> > >>> A few other recent reports are noted here...
> > >>> https://github.com/pharo-project/pharo/issues/3418
> > >>>
> > >>> cheers -ben
> > >>
> > >
> > > --
> > > feenk.com
> > 

[Pharo-dev] [Pharo 8.0] Build #699: 4401-bis-ZipArchive-should-not-convert-FileReference-to-paths

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!
  
The status of the build #699 was: FAILURE.

The Pull Request #4473 was integrated: 
"4401-bis-ZipArchive-should-not-convert-FileReference-to-paths"
Pull request url: https://github.com/pharo-project/pharo/pull/4473

Issue Url: https://github.com/pharo-project/pharo/issues/4401
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo8.0/699/

Re: [Pharo-dev] Floating-point numbers with radix (non-decimal)?

[James Foster]

Hi Stef,

The question is “How should it work?” How do we distinguish whether the 
character ‘e’ (or ‘E’) is a representation for the (decimal) number 14 or is a 
representation for “what follows is an exponent”? For example, it is easy to 
recognize that the radix-based integer literal ‘16rFF’ is the SmallInteger 255 
and that the float literal ‘1.23e3’ is 1230.0 (a SmallDouble in GemStone). 

For some reason, Pharo allowed ‘16ree’ to be the number 238 (permitting 
lowercase for hexidecimal digits) and has also allowed ‘2r1.111e3’ to be the 
same as ‘2r’ or 15 (permitting floating-point numbers to have a radix). 
This introduces an ambiguity in interpreting the character ‘e’ (or ‘E’)—is it a 
hexadecimal digit or is it an exponent identifier? 

I believe that there are the following alternatives:
Enforce a uppercase and lowercase distinction (digit and exponent respectively);
Allow exponents on decimal (base ten) numbers only;
Interpret ‘e’ as a hexadecimal digit if the radix is >= 15 (allowing exponents 
on lower bases); or
Develop a new syntax to introduce exponents.
I believe that #3 is the current approach, and could be seen as #2 relaxed to 
allow exponents on numbers with a radix of 2-14. 

It seems to me that the primary value of exponents on non-decimal (base ten) 
numbers is to represent binary numbers (2r1e63 is more readable than 
2r1000). It seems 
to me that the value of exponents on numbers with a base above 10 is less 
pronounced (16r1E15 is better than 16r1000, but only a bit better). 
Mostly, I’d assert that the value of exponents for radix 16 is not worth a new 
syntax (excluding #4 above).

James

> On Sep 4, 2019, at 10:36 PM, ducasse  wrote:
> 
> Hi nicolas
> 
> let us fix this :)
> 
> why 15r1.2e1 is not working?
> why 15r1.2e1 is not equals to 15r1.2E1?
> why would we need a new syntax?
> 
> Stef
>> On 5 Sep 2019, at 00:19, Nicolas Cellier > > wrote:
>> 
>> Once upon a time, only uppercase letters were accpeted as extra digits (in 
>> base > 10) for both int and float
>> 
>> Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E
>> 
>> Then it was considered better to understand hexadecimal numbers with 
>> lowercase too...
>> and alternate-base Float became ambiguous and were never fixed :(
>> 
>> This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 
>> 15r1.2#e1 ...
>> Changing Smalltalk syntax is among the most difficult decisions, expect 
>> outcry ;)
>> Maybe because it's too easy :)
>> 
>> 
>> Le jeu. 5 sept. 2019 à 00:04, James Foster > > a écrit :
>> 14r1.2e1 "16.0"
>> 15r1.2e1 “1.195851851851852"
>> 
>> Does it make sense to have exponents for numbers that are not base 10? There 
>> are tests that have large exponents for binary numbers and we are not sure 
>> how to handle this in GemStone.
>> 
>> James
>> 
> 

Re: [Pharo-dev] [Pharo-users] Pharo Branding Organization on GitHub

[Torsten Bergmann]

stepharo wrote:
> thanks for the initiative.
> I think that we have more material around, like alternate logo.
> It would be nice to collect also the svg versions?
>
> I know that lusy did also design for mugs

The SVG versions for the logo and flat-logo are in already. If you have more
then just send it around or put it in directly. I added you to the organization.

Unfortunately I do not know who lusy is ... maybe you could contact here
so we can also collect here media stuff for the repos.

Thanks
T.

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[Guillermo Polito]

Hi all,

First, please, we would love if you can test what Pablo proposed and give us 
some feedback.
It will be super helpful to evaluate if it is worth to generate a new vm 
release!!!

Also, besides what Pablo said in the previous email, I wanted to share some 
more precisions.

=== Precisions on the problem ===

First, just to clarify, we isolated the issue happening only on Windows10 #1903 
on Pharo64 bits.
Pharo32 bits does work well on that update number does work well.

The origin of the problem seems to be a bad integration between libssh2 1.7.0 
and the windows CNG crypto layer, which seemingly changed in this update.

=== The path to the solution ===

The solution was theoretically super straight forward (upgrade to openssh 1.9.0 
+ openssl for crypto instead of windows CNG).

It was however super time consuming.
 - installing the windows update #1903 to test, reproduce and understand the 
issue took for us a couple of hours, reconfiguring the virtual machines to 
enlarge disks to download it, then install it...
 - compiling openssl took literally the entire afternoon yesterday in Pablo’s 
machine.
 - then we found several bugs in cmake openssl integration when compiling 
libssh2 on Cigwin + mingw, because life cannot be easy ^^

And fortunately, we found no incompatibilities between the different versions 
of these libraries (and libgit2 too!) so it could have been more time consuming 
:P.

=== Alternative solutions and workarounds ===

Alternatively for testing the libraries that Pablo sent in the previous email, 
there are some other workarounds that people could try in the meantime:

1) Use Pharo32 bits, which as I said above, does not have the problem.

2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello integration 
to HTTP by default).



We are also evaluating setting HTTPS by default in Iceberg as it is simpler to 
setup.
Github, Gitkraken do use HTTPS as a sensible default too.

Cheers


> El 5 sept 2019, a las 14:28, teso...@gmail.com escribió:
> 
> Hi all,
> with Guille we have been working in this issue since Monday, it
> was a complicated issue to solve as we require to compile and test
> different versions of the libgit2 library and its dependencies
> (openssl and libssh2).
> We have a workaround for using ssh in windows.
> We have produced a new set of libraries with the correct versions.
> These libraries are available in
> https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1
> The idea is to start testing them while we are working on a new
> release of the VM.
> 
> Cheers,
> Pablo
> 
> On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito
>  wrote:
>> 
>> Hi all,
>> 
>> Sorry for not communicating better :).
>> We know this is an important issue and we did move it to top priority even 
>> prior to this email ;).
>> Doru, to answer you, what people can do for the moment is to test what we 
>> are going to propose in a couple of hours in your windows machines.
>> With Pablo we have tested in several Windows 10 machines pre- and post- 
>> update 1903. Still we would like people testing on their setups and other 
>> windows versions
>> 
>> We have been working the last couple of days debugging openssh and libgit, 
>> and building a version with a more up-to-date version of openssh.
>> We will come back later this morning / early afternoon with
>> - a new vm setup using up to date versions of openssh
>> - a description of workarounds for those tied to old versions of the VM
>> So people can test.
>> 
>> Cheers,
>> Guille and Pablo
>> 
>>> El 4 sept 2019, a las 8:38, ducasse  escribió:
>>> 
>>> I saw everybody super busy and I imagine that they will reply soon.
>>> I’m travelling to give Pharo lectures.
>>> 
 On 3 Sep 2019, at 19:23, Tudor Girba  wrote:
 
 Hi,
 
 Is there a way to speed the work on this one?
 
 At this moment, people cannot load any code in Pharo on Windows 10.
 
 Cheers,
 Doru
 
 --
 www.feenk.com
 "Every thing has its own flow."
 
> On 28 Aug 2019, at 16:20, ducasse  wrote:
> 
> tx doru
> 
> Stef
> 
>> On 28 Aug 2019, at 16:01, Tudor Girba  wrote:
>> 
>> Hi
>> 
>> I opened an issue: https://github.com/pharo-project/pharo/issues/4437
>> 
>> I believe this should be treated as critical given that we cannot load 
>> code in Pharo 7 (or 8) which makes it almost useless for users.
>> 
>> Cheers,
>> Doru
>> 
>> 
>>> On Aug 27, 2019, at 10:54 AM, Tudor Girba  wrote:
>>> 
>>> Hi,
>>> 
>>> We just encountered this on two different machines. We got this after 
>>> the update to Windows 1903. For us it’s a critical issue at this point. 
>>> What can we do to help with this?
>>> 
>>> Cheers,
>>> Doru
>>> 
>>> 
>>> 
 On Aug 17, 2019, at 12:50 PM, Ben Coman  wrote:
 
 hi Stef,
 I feel you missed my point. Probably I wasn't clear this 

Re: [Pharo-dev] [Pharo 8.0] Build #698: Improving performance of athens

[Henrik Sperre Johansen]

Currently only cacheAt:ifAbsentPut: exists on Canvas, but wouldn't it be
nicer to expand it to expose/generalize for:at:ifAbsentPut: from
CairoBackendCache, rather than create two new class variables?

When most of the asAthensPaintOn: dispatch through surface, that seems a
nicer place to do the lookup (even though it rarely/ever change in
practice), no?

Cheers,
Henry



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] possible Windows Update "1903" Iceberg problem

[teso...@gmail.com]

Hi all,
 with Guille we have been working in this issue since Monday, it
was a complicated issue to solve as we require to compile and test
different versions of the libgit2 library and its dependencies
(openssl and libssh2).
We have a workaround for using ssh in windows.
We have produced a new set of libraries with the correct versions.
These libraries are available in
https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1
The idea is to start testing them while we are working on a new
release of the VM.

Cheers,
Pablo

On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito
 wrote:
>
> Hi all,
>
> Sorry for not communicating better :).
> We know this is an important issue and we did move it to top priority even 
> prior to this email ;).
> Doru, to answer you, what people can do for the moment is to test what we are 
> going to propose in a couple of hours in your windows machines.
> With Pablo we have tested in several Windows 10 machines pre- and post- 
> update 1903. Still we would like people testing on their setups and other 
> windows versions
>
> We have been working the last couple of days debugging openssh and libgit, 
> and building a version with a more up-to-date version of openssh.
> We will come back later this morning / early afternoon with
>  - a new vm setup using up to date versions of openssh
>  - a description of workarounds for those tied to old versions of the VM
> So people can test.
>
> Cheers,
> Guille and Pablo
>
> > El 4 sept 2019, a las 8:38, ducasse  escribió:
> >
> > I saw everybody super busy and I imagine that they will reply soon.
> > I’m travelling to give Pharo lectures.
> >
> >> On 3 Sep 2019, at 19:23, Tudor Girba  wrote:
> >>
> >> Hi,
> >>
> >> Is there a way to speed the work on this one?
> >>
> >> At this moment, people cannot load any code in Pharo on Windows 10.
> >>
> >> Cheers,
> >> Doru
> >>
> >> --
> >> www.feenk.com
> >> "Every thing has its own flow."
> >>
> >>> On 28 Aug 2019, at 16:20, ducasse  wrote:
> >>>
> >>> tx doru
> >>>
> >>> Stef
> >>>
>  On 28 Aug 2019, at 16:01, Tudor Girba  wrote:
> 
>  Hi
> 
>  I opened an issue: https://github.com/pharo-project/pharo/issues/4437
> 
>  I believe this should be treated as critical given that we cannot load 
>  code in Pharo 7 (or 8) which makes it almost useless for users.
> 
>  Cheers,
>  Doru
> 
> 
> > On Aug 27, 2019, at 10:54 AM, Tudor Girba  wrote:
> >
> > Hi,
> >
> > We just encountered this on two different machines. We got this after 
> > the update to Windows 1903. For us it’s a critical issue at this point. 
> > What can we do to help with this?
> >
> > Cheers,
> > Doru
> >
> >
> >
> >> On Aug 17, 2019, at 12:50 PM, Ben Coman  wrote:
> >>
> >> hi Stef,
> >> I feel you missed my point. Probably I wasn't clear this has already 
> >> been tested with latest Pharo 8 launched by PharoLauncher.
> >> The problem occurs with Pharo 7.0.3(64 bit) and with 
> >> Pharo8.0-SNAPSHOT-build.635(64 bit)
> >> after Microsoft Windows Update 1903...
> >> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-1803-to-1903-forced-upgrade.html
> >>
> >> If indeed 1903 is the cause, with this update now being *forced* down 
> >> on people, this will potentially soon impact more and more Windows 
> >> users.
> >> But my guess that 1903 is the culprit needs to be confirmed.
> >> So I am requesting someone with access to multiple Windows machines 
> >> directly compare a 1903 machine with a pre-1903 machine.
> >>
> >> cheers -ben
> >>
> >> On Sat, 17 Aug 2019 at 12:58, ducasse  wrote:
> >> Hi ben
> >>
> >> in the pharo launcher if you click on P8.0 (development version) you 
> >> get access to all the builds.
> >>
> >> Stef
> >>
> >>> On 16 Aug 2019, at 16:02, Ben Coman  wrote:
> >>>
> >>> IThis morning the May 2019 Windows Update "1903" forced itself onto 
> >>> my computer and now 64-bits Pharo seems to have a problem with 
> >>> git_remote_fetch() FFI callout.  I no longer have a non-1903 machine 
> >>> to directly compare behaviour before "1903".  Can someone familiar 
> >>> with this area with both "pre-1903" and "1903" machines triage 
> >>> whether "1903" is indeed the cause?
> >>>
> >>> A few other recent reports are noted here...
> >>> https://github.com/pharo-project/pharo/issues/3418
> >>>
> >>> cheers -ben
> >>
> >
> > --
> > feenk.com
> >
> > "Not knowing how to do something is not an argument for how it cannot 
> > be done."
> >
> 
>  --
>  feenk.com
> 
>  “Live like you mean it."
> 
> 
> >>>
> >>>
> >>>
> >>
> >
> >
> >
>
>


-- 
Pablo Tesone.
teso...@gmail.com

Re: [Pharo-dev] About tweets

[ducasse]

Indeed so we removed everything. 
A clear win. 

Stef

> So now I should complain why my twitter account is not in this list? ;)
> 
> All pharoers are equal ….
> 
> Norbert
> 
>> Am 05.09.2019 um 12:25 schrieb ducasse :
>> 
>> We are in sync. So I updated the web site to list the main pharo project
>> and I put a list of other accounts with a disclaimer. 
>> 
>> I can do the same with the blog posts.
>> 
>> Stef
>> 
>>> On 5 Sep 2019, at 10:54, Torsten Bergmann  wrote:
>>> 
>>> Hi Stef,
>>> 
>>> I understand - but before we focus the discussion too much on the mentioned 
>>> #abortionismurder let's bring #4491 into perspective:
>>> 
>>> 1. Important: I guess we all agree that we would like to tweet and inform 
>>> as much on technical topics about Smalltalk in general and
>>>  Pharo in particular and not correlate our activities to single peoples 
>>> personal habits, politics, religion or beliefs.
>>> 
>>> 2. The aggregator that I suggested in the issue 
>>> (https://twitter.com/WorldDotSt) is related to the website world.st - which 
>>> is
>>>  a really useful technical resource on Smalltalk, Pharo and ESUG infos 
>>> already throughout the years:
>>> 
>>>   - The forum page http://forum.world.st is summarizing various ST 
>>> Mailinglists including ESUG list
>>>   - https://twitter.com/WorldDotSt aggregates most of the Pharo and 
>>> Smalltalker Tweets in existence
>>> 
>>> 3. You are referring in this thread here to the following tweet: 
>>> https://twitter.com/AmberSmalltalk/status/1169239145530761217
>>>  which is associating @esugsmalltalk @SergeStinckwich @stephaneducasse 
>>> #smalltalk for whatever reason with the hash tag #abortionismurder
>>> 
>>>  I understand your reaction and post - but this was done outside our 
>>> boundaries by twitter user "AmberSmalltalk" - also not by the aggregator
>>>  itself. And yes - this "AmberSmalltalk" owner seems to mix sometimes 
>>> personal beliefs into technical infos. I share your doubts and dislike
>>>  this as well.
>>> 
>>>  It's a problem that existed before and is a problem of tweeting and social 
>>> media in general. Something that is IMHO independent from described
>>>  issue #4491 - and you and Serge definitely need to sort out this 
>>> #abortionismurder thing with the owner of this specific account.
>>> 
>>> 4. The issue #4491 mentions that currently the Pharo community page 
>>> (http://www.pharo.org/community)
>>> 
>>>  for Twitter ONLY PROMOTES
>>>  a) the offical tweet account @pharoproject
>>>  b) your personal @stephaneducasse account
>>>  as the ones to follow.
>>> 
>>>  But we have many more interesting community members tweeting on Pharo as 
>>> you see on the list in the referred issue. So we should either
>>>  extend the community page with either more personal accounts, just use the 
>>> offical one or use an external or own aggregator
>>>  including hashtags like #pharo, #pharoproject, ...
>>> 
>>> 
>>> 5. As you might have noticed I also opened a second issue #4490 
>>> (https://github.com/pharo-project/pharo/issues/4490) as for the blogs 
>>> mentioned
>>>  on the community page we have something similar:
>>> 
>>>  For Blogs WE ONLY PROMOTE on that page:
>>>  a) the official pharo weekly
>>>  b) my personal astares blog
>>>  c) the personal blog of clement
>>> 
>>>  But my blog is not special either - so an aggregator of the various 
>>> Smalltalks blogs (as the one suggested from planet smalltalk)
>>>  made initially sense to me as it would include more blogs of members of 
>>> the community and we would not have to adopt the community page all
>>>  the time a new blog appears.
>>> 
>>>  There are nice Pharo blogs out there like https://www.samadhiweb.com/blog, 
>>> http://humane-assessment.com/blog and many other.
>>> 
>>>  Same applies here: either we just include the offical blog that we 
>>> control, a list of more blogs of the various members or an aggregator
>>> 
>>> 6. Yes - the community is unable to control what people write on Twitter, 
>>> Blogs or other social media. Even our mailinglist "pharo-users_lists"
>>>  is not free from personal habits as yesterdays disussion about "guns" 
>>> showed.
>>>  
>>> (http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)
>>> 
>>>  And maybe linking to these aggregators or promoting them is not a good 
>>> idea. If we take the discussion (over)serious we should then
>>>  really only link to official twitter account and official pharo blog that 
>>> the community can control.
>>> 
>>>  In such a case we need to remove my blog and your personal twitter account 
>>> from the community page as you sometimes tweet about
>>>  politics on your personal account too and I can potentially write on other 
>>> non-technical topics on my blog as well (which I do not plan).
>>> 
>>> 
>>> Basically we have four options:
>>> a) we only link to the official twitter account 
>>> (https://twitter.com/pharoproject) and blog 
>>> 

Re: [Pharo-dev] Fund rising for the new Spec20 book.

[Sean P. DeNigris]

ducasse wrote
> Thanks and sorry for the burden.

No problem at all.


ducasse wrote
> Could you tell me your bank and I can ask the platform?

Chase



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] About tweets

[Norbert Hartl]

So now I should complain why my twitter account is not in this list? ;)

All pharoers are equal ….

Norbert

> Am 05.09.2019 um 12:25 schrieb ducasse :
> 
> We are in sync. So I updated the web site to list the main pharo project
> and I put a list of other accounts with a disclaimer. 
> 
> I can do the same with the blog posts.
> 
> Stef
> 
>> On 5 Sep 2019, at 10:54, Torsten Bergmann  wrote:
>> 
>> Hi Stef,
>> 
>> I understand - but before we focus the discussion too much on the mentioned 
>> #abortionismurder let's bring #4491 into perspective:
>> 
>> 1. Important: I guess we all agree that we would like to tweet and inform as 
>> much on technical topics about Smalltalk in general and
>>   Pharo in particular and not correlate our activities to single peoples 
>> personal habits, politics, religion or beliefs.
>> 
>> 2. The aggregator that I suggested in the issue 
>> (https://twitter.com/WorldDotSt) is related to the website world.st - which 
>> is
>>   a really useful technical resource on Smalltalk, Pharo and ESUG infos 
>> already throughout the years:
>> 
>>- The forum page http://forum.world.st is summarizing various ST 
>> Mailinglists including ESUG list
>>- https://twitter.com/WorldDotSt aggregates most of the Pharo and 
>> Smalltalker Tweets in existence
>> 
>> 3. You are referring in this thread here to the following tweet: 
>> https://twitter.com/AmberSmalltalk/status/1169239145530761217
>>   which is associating @esugsmalltalk @SergeStinckwich @stephaneducasse 
>> #smalltalk for whatever reason with the hash tag #abortionismurder
>> 
>>   I understand your reaction and post - but this was done outside our 
>> boundaries by twitter user "AmberSmalltalk" - also not by the aggregator
>>   itself. And yes - this "AmberSmalltalk" owner seems to mix sometimes 
>> personal beliefs into technical infos. I share your doubts and dislike
>>   this as well.
>> 
>>   It's a problem that existed before and is a problem of tweeting and social 
>> media in general. Something that is IMHO independent from described
>>   issue #4491 - and you and Serge definitely need to sort out this 
>> #abortionismurder thing with the owner of this specific account.
>> 
>> 4. The issue #4491 mentions that currently the Pharo community page 
>> (http://www.pharo.org/community)
>> 
>>   for Twitter ONLY PROMOTES
>>   a) the offical tweet account @pharoproject
>>   b) your personal @stephaneducasse account
>>   as the ones to follow.
>> 
>>   But we have many more interesting community members tweeting on Pharo as 
>> you see on the list in the referred issue. So we should either
>>   extend the community page with either more personal accounts, just use the 
>> offical one or use an external or own aggregator
>>   including hashtags like #pharo, #pharoproject, ...
>> 
>> 
>> 5. As you might have noticed I also opened a second issue #4490 
>> (https://github.com/pharo-project/pharo/issues/4490) as for the blogs 
>> mentioned
>>   on the community page we have something similar:
>> 
>>   For Blogs WE ONLY PROMOTE on that page:
>>   a) the official pharo weekly
>>   b) my personal astares blog
>>   c) the personal blog of clement
>> 
>>   But my blog is not special either - so an aggregator of the various 
>> Smalltalks blogs (as the one suggested from planet smalltalk)
>>   made initially sense to me as it would include more blogs of members of 
>> the community and we would not have to adopt the community page all
>>   the time a new blog appears.
>> 
>>   There are nice Pharo blogs out there like https://www.samadhiweb.com/blog, 
>> http://humane-assessment.com/blog and many other.
>> 
>>   Same applies here: either we just include the offical blog that we 
>> control, a list of more blogs of the various members or an aggregator
>> 
>> 6. Yes - the community is unable to control what people write on Twitter, 
>> Blogs or other social media. Even our mailinglist "pharo-users_lists"
>>   is not free from personal habits as yesterdays disussion about "guns" 
>> showed.
>>   
>> (http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)
>> 
>>   And maybe linking to these aggregators or promoting them is not a good 
>> idea. If we take the discussion (over)serious we should then
>>   really only link to official twitter account and official pharo blog that 
>> the community can control.
>> 
>>   In such a case we need to remove my blog and your personal twitter account 
>> from the community page as you sometimes tweet about
>>   politics on your personal account too and I can potentially write on other 
>> non-technical topics on my blog as well (which I do not plan).
>> 
>> 
>> Basically we have four options:
>> a) we only link to the official twitter account 
>> (https://twitter.com/pharoproject) and blog 
>> (https://pharoweekly.wordpress.com/)
>> b) extend the list with personal twitter accounts as mentioned in issue 
>> #4491 and blogs like mentioned in #4490
>> 

Re: [Pharo-dev] About tweets

[ducasse]

We are in sync. So I updated the web site to list the main pharo project
and I put a list of other accounts with a disclaimer. 

I can do the same with the blog posts.

Stef

> On 5 Sep 2019, at 10:54, Torsten Bergmann  wrote:
> 
> Hi Stef,
> 
> I understand - but before we focus the discussion too much on the mentioned 
> #abortionismurder let's bring #4491 into perspective:
> 
> 1. Important: I guess we all agree that we would like to tweet and inform as 
> much on technical topics about Smalltalk in general and
>Pharo in particular and not correlate our activities to single peoples 
> personal habits, politics, religion or beliefs.
> 
> 2. The aggregator that I suggested in the issue 
> (https://twitter.com/WorldDotSt) is related to the website world.st - which is
>a really useful technical resource on Smalltalk, Pharo and ESUG infos 
> already throughout the years:
> 
> - The forum page http://forum.world.st is summarizing various ST 
> Mailinglists including ESUG list
> - https://twitter.com/WorldDotSt aggregates most of the Pharo and 
> Smalltalker Tweets in existence
> 
> 3. You are referring in this thread here to the following tweet: 
> https://twitter.com/AmberSmalltalk/status/1169239145530761217
>which is associating @esugsmalltalk @SergeStinckwich @stephaneducasse 
> #smalltalk for whatever reason with the hash tag #abortionismurder
> 
>I understand your reaction and post - but this was done outside our 
> boundaries by twitter user "AmberSmalltalk" - also not by the aggregator
>itself. And yes - this "AmberSmalltalk" owner seems to mix sometimes 
> personal beliefs into technical infos. I share your doubts and dislike
>this as well.
> 
>It's a problem that existed before and is a problem of tweeting and social 
> media in general. Something that is IMHO independent from described
>issue #4491 - and you and Serge definitely need to sort out this 
> #abortionismurder thing with the owner of this specific account.
> 
> 4. The issue #4491 mentions that currently the Pharo community page 
> (http://www.pharo.org/community)
> 
>for Twitter ONLY PROMOTES
>a) the offical tweet account @pharoproject
>b) your personal @stephaneducasse account
>as the ones to follow.
> 
>But we have many more interesting community members tweeting on Pharo as 
> you see on the list in the referred issue. So we should either
>extend the community page with either more personal accounts, just use the 
> offical one or use an external or own aggregator
>including hashtags like #pharo, #pharoproject, ...
> 
> 
> 5. As you might have noticed I also opened a second issue #4490 
> (https://github.com/pharo-project/pharo/issues/4490) as for the blogs 
> mentioned
>on the community page we have something similar:
> 
>For Blogs WE ONLY PROMOTE on that page:
>a) the official pharo weekly
>b) my personal astares blog
>c) the personal blog of clement
> 
>But my blog is not special either - so an aggregator of the various 
> Smalltalks blogs (as the one suggested from planet smalltalk)
>made initially sense to me as it would include more blogs of members of 
> the community and we would not have to adopt the community page all
>the time a new blog appears.
> 
>There are nice Pharo blogs out there like https://www.samadhiweb.com/blog, 
> http://humane-assessment.com/blog and many other.
> 
>Same applies here: either we just include the offical blog that we 
> control, a list of more blogs of the various members or an aggregator
> 
> 6. Yes - the community is unable to control what people write on Twitter, 
> Blogs or other social media. Even our mailinglist "pharo-users_lists"
>is not free from personal habits as yesterdays disussion about "guns" 
> showed.
>
> (http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)
> 
>And maybe linking to these aggregators or promoting them is not a good 
> idea. If we take the discussion (over)serious we should then
>really only link to official twitter account and official pharo blog that 
> the community can control.
> 
>In such a case we need to remove my blog and your personal twitter account 
> from the community page as you sometimes tweet about
>politics on your personal account too and I can potentially write on other 
> non-technical topics on my blog as well (which I do not plan).
> 
> 
> Basically we have four options:
>  a) we only link to the official twitter account 
> (https://twitter.com/pharoproject) and blog 
> (https://pharoweekly.wordpress.com/)
>  b) extend the list with personal twitter accounts as mentioned in issue 
> #4491 and blogs like mentioned in #4490
>  c) Link and rely on external aggregators
>  d) Setup an own aggregator on sources we trust
> 
> Maybe as a valid solution an official "disclaimer" could help - that opinions 
> shared on these PROMOTED sources are not controlled by
> us 

Re: [Pharo-dev] About tweets

[Torsten Bergmann]

Hi Stef,

I understand - but before we focus the discussion too much on the mentioned 
#abortionismurder let's bring #4491 into perspective:

 1. Important: I guess we all agree that we would like to tweet and inform as 
much on technical topics about Smalltalk in general and
Pharo in particular and not correlate our activities to single peoples 
personal habits, politics, religion or beliefs.

 2. The aggregator that I suggested in the issue 
(https://twitter.com/WorldDotSt) is related to the website world.st - which is
a really useful technical resource on Smalltalk, Pharo and ESUG infos 
already throughout the years:

 - The forum page http://forum.world.st is summarizing various ST 
Mailinglists including ESUG list
 - https://twitter.com/WorldDotSt aggregates most of the Pharo and 
Smalltalker Tweets in existence

 3. You are referring in this thread here to the following tweet: 
https://twitter.com/AmberSmalltalk/status/1169239145530761217
which is associating @esugsmalltalk @SergeStinckwich @stephaneducasse 
#smalltalk for whatever reason with the hash tag #abortionismurder

I understand your reaction and post - but this was done outside our 
boundaries by twitter user "AmberSmalltalk" - also not by the aggregator
itself. And yes - this "AmberSmalltalk" owner seems to mix sometimes 
personal beliefs into technical infos. I share your doubts and dislike
this as well.

It's a problem that existed before and is a problem of tweeting and social 
media in general. Something that is IMHO independent from described
issue #4491 - and you and Serge definitely need to sort out this 
#abortionismurder thing with the owner of this specific account.

 4. The issue #4491 mentions that currently the Pharo community page 
(http://www.pharo.org/community)

for Twitter ONLY PROMOTES
a) the offical tweet account @pharoproject
b) your personal @stephaneducasse account
as the ones to follow.

But we have many more interesting community members tweeting on Pharo as 
you see on the list in the referred issue. So we should either
extend the community page with either more personal accounts, just use the 
offical one or use an external or own aggregator
including hashtags like #pharo, #pharoproject, ...


 5. As you might have noticed I also opened a second issue #4490 
(https://github.com/pharo-project/pharo/issues/4490) as for the blogs mentioned
on the community page we have something similar:

For Blogs WE ONLY PROMOTE on that page:
a) the official pharo weekly
b) my personal astares blog
c) the personal blog of clement

But my blog is not special either - so an aggregator of the various 
Smalltalks blogs (as the one suggested from planet smalltalk)
made initially sense to me as it would include more blogs of members of the 
community and we would not have to adopt the community page all
the time a new blog appears.

There are nice Pharo blogs out there like https://www.samadhiweb.com/blog, 
http://humane-assessment.com/blog and many other.

Same applies here: either we just include the offical blog that we control, 
a list of more blogs of the various members or an aggregator

 6. Yes - the community is unable to control what people write on Twitter, 
Blogs or other social media. Even our mailinglist "pharo-users_lists"
is not free from personal habits as yesterdays disussion about "guns" 
showed.

(http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/2019-September/044168.html)

And maybe linking to these aggregators or promoting them is not a good 
idea. If we take the discussion (over)serious we should then
really only link to official twitter account and official pharo blog that 
the community can control.

In such a case we need to remove my blog and your personal twitter account 
from the community page as you sometimes tweet about
politics on your personal account too and I can potentially write on other 
non-technical topics on my blog as well (which I do not plan).


Basically we have four options:
  a) we only link to the official twitter account 
(https://twitter.com/pharoproject) and blog (https://pharoweekly.wordpress.com/)
  b) extend the list with personal twitter accounts as mentioned in issue #4491 
and blogs like mentioned in #4490
  c) Link and rely on external aggregators
  d) Setup an own aggregator on sources we trust

Maybe as a valid solution an official "disclaimer" could help - that opinions 
shared on these PROMOTED sources are not controlled by
us and do not necessarily reflect the opinion of the Pharo community

And yes - the board should discuss, check and decide what to put or link to 
from the community page.

Thanks
T.

> Gesendet: Donnerstag, 05. September 2019 um 08:03 Uhr
> Von: "ducasse" 
> An: "Pharo Development List" 
> Cc: "The Pharo Project" 
> Betreff: [Pharo-dev] About tweets
>
> Hi guys
>
> I encourage everybody to 

Re: [Pharo-dev] About tweets

[Norbert Hartl]

Ok, there seems to be some agreeable sense. Dealing with accounts of people 
tends to collect opinions and things not related to pharo. We are not 
interested in these.
There are hashtags and mentions for things related to a topic. But a few (!) 
want to have more control. So using the @pharoproject account should be ok 
because we can like things to be includef from that account. Well at least the 
ones that have access to. 

Is this a proper summary?

Norbert

> Am 05.09.2019 um 08:48 schrieb Esteban Lorenzano :
> 
> Yes, I closed that issue. 
> 
> This is not going to happen, sorry :)
> 
> Esteban
> 
>> On 5 Sep 2019, at 08:03, ducasse  wrote:
>> 
>> Hi guys 
>> 
>> I encourage everybody to read this issue until the last conversation.
>>https://github.com/pharo-project/pharo/issues/4491
>> 
>> I have problem to promote an aggregator that can contain tweets containing 
>> #abortionismurder inside.!
>> And I have even more problem that this is in a tweet on Amber Weekly 
>> 
>> I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
>> impossible to read this
>> on a tweet that Pharo supports. 
>> 
>> I also have a problem to promote an aggregator account
>> We can provide a list and people what they want. 
>> I do not like the idea of aggregation. So I vote against and I will ask the 
>> board to decide. 
>> 
>> Stef
> 
> 

Re: [Pharo-dev] About tweets

[Esteban Lorenzano]

Yes, I closed that issue. 

This is not going to happen, sorry :)

Esteban

> On 5 Sep 2019, at 08:03, ducasse  wrote:
> 
> Hi guys 
> 
> I encourage everybody to read this issue until the last conversation.
>   https://github.com/pharo-project/pharo/issues/4491
> 
> I have problem to promote an aggregator that can contain tweets containing 
> #abortionismurder inside.!
> And I have even more problem that this is in a tweet on Amber Weekly 
> 
> I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
> impossible to read this
> on a tweet that Pharo supports. 
> 
> I also have a problem to promote an aggregator account
> We can provide a list and people what they want. 
> I do not like the idea of aggregation. So I vote against and I will ask the 
> board to decide. 
> 
> Stef

[Pharo-dev] About tweets

[ducasse]

Hi guys 

I encourage everybody to read this issue until the last conversation.
https://github.com/pharo-project/pharo/issues/4491

I have problem to promote an aggregator that can contain tweets containing 
#abortionismurder inside.!
And I have even more problem that this is in a tweet on Amber Weekly 

I do not know who is behind AmberSmalltalk tweets but for me this is clearly 
impossible to read this
on a tweet that Pharo supports. 

I also have a problem to promote an aggregator account
We can provide a list and people what they want. 
I do not like the idea of aggregation. So I vote against and I will ask the 
board to decide. 

Stef