[Pharo-dev] Re: [ANN] Pharo 9 released!

2021-07-16 Thread Esteban Maringolo 
Thanks team. Impressive release.

Keep up the good work!

Esteban A. Maringolo


On Thu, Jul 15, 2021 at 6:14 AM Esteban Lorenzano  wrote:

> Dear World and dynamic language lovers:
>
> The time has come for Pharo 9  !
>
> Pharo is a pure object-oriented programming language and a powerful
> environment, focused on simplicity and immediate feedback.
>
>
> Here are the key features of Pharo 9:
>
>
>- Full redesign of the Spec UI framework (new logic, application,
>style, GTK3 back-end)
>- New tools:
>-
>   - new playground,
>   - new object centric inspector,
>   - new object centric debugger.
>   - better and new Refactorings
>   - class comments are now written in Microdown format (Markdown
>   compatible)
>   - classes now can be defined using a "fluid" api (Preview)
>   - New completion framework that adapts better to edition contexts
>and is customizable
>- Fast universal non-blocking FFI which now uses libFFI as backend.
>- Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora,
>openSUSE, Arch, Raspbian) and multiple architectures (Intel/ARM 32/64bits).
>- Virtual Machine
>-
>   - Idle VM
>   - Support for ARM 64bits
>   - Support for Apple M1
>   - More than 3000 tests
>   - Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 10,
>   Testing; Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; 
> Arch
>   - Uses SDL 2.0 as back-end by default. It supports extended event
>handling, including trackpad support.
>- General speed up due to compiler optimisations and UI simplification.
>- And many, many more tests.
>
>
> These are just the more prominent highlights, but the details are just as
> important. We have closed a massive amount of issues: around 1400 issues
> and 2150 pull requests.
>
> A more extended changelog can be found at
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90ChangeLogs.md
> .
>
> While the technical improvements are significant, still the most
> impressive fact is that the new code that got in the main Pharo 9 image was
> contributed by more than 90 people.
>
> Pharo is more than code. It is an exciting project involving a great
> community.
>
> We thank all the contributors to this release:
>
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Ale Cossio, Alexandre
> Bergel, Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano,
> Asbathou Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos
> Lopez, Carolina Hernandez, Charles A. Monteiro, Christoph Thiede,
> Christophe Demarey, Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel
> Aparicio, David Bajger, David Sánchez i Gregori, Denis Kudriashov, Ellis
> Harris, Eric Brandwein, Eric Gade, Erik Stel, ErikOnBike, Esteban
> Lorenzano, Esteban Villalobos, Evelyn Cusi Lopez, Evelyn Cusi Lopez, Ewan
> Dawson, Francis Pineda, Francis Pineda, Gabriel Omar Cotelli, Geraldine
> Galindo, Giovanni Corriga, Guille Polito, Himanshu jld, Johan Brichau,
> Jonathan van Alteren, Jordan Montt, Julien Delplanque, Kamil Kukura, Kasper
> Østerbye, Kurt Kilpela, Laurine Dargaud, Marco Rimoldi, Marcus Denker,
> Martin Dias, Martin McClure, Massimo Nocentini, Max Leske, Maximilian
> Ignacio Willembrinck Santander, Milton Mamani Torres, Moussa Saker,
> Myroslava Romaniuk, Nicolas Anquetil, Norbert Hartl, Nour Djihan, Oleksandr
> Zaitsev, Pablo Sánchez Rodríguez, Pablo Tesone, Pavel Krivanek, Philippe
> Lesueur, Pierre Misse, Rakshit P., Rob Sayers, Roland Bernard, Ronie
> Salgado, Sean DeNigris, Sebastian Jordan Montaño, Serge Stinckwich, Stephan
> Eggermont, Steven Costiou, Stéphane Ducasse, Sven Van Caekenberghe, Thomas
> Dupriez, Théo Lanord, Théo Rogliano, Todd Blanchard, Torsten Bergmann,
> Vincent Blondeau, Wéslleymberg Lisboa.
>
>
> (If you contributed with Pharo 9 development in any way and we missed your
> name, please send us an email and we will add you).
>
> Enjoy!
>
> The Pharo Team
>
> Try Pharo: http://pharo.org/download 
>
> Learn Pharo: http://pharo.org/documentation
> 
>

[Pharo-dev] Re: Serious NetNameResolver regression

2021-07-16 Thread Sven Van Caekenberghe 
thx.

> On 16 Jul 2021, at 12:18, teso...@gmail.com wrote:
> 
> I have updated the VMs, the issue should be resolved now.
> 
> On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito  
> wrote:
> Hi all,
> 
> it seems we need a new VM release.
> The issue seems fixed since ~6 months ago
> 
> https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb
> 
> Pablo is updating the stable VMs just in this moment.
> 
> G
> 
> > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe  escribió:
> > 
> > Anyway, for now, I added guards:
> > 
> > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
> > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
> > 
> > but the core problem remains.
> > 
> >> On 15 Jul 2021, at 21:35, Gabriel Cotelli  wrote:
> >> 
> >> You're right Sven. The code in the image looks exactly the same betwen 
> >> Pharo 8 and 9 but the behavior is different. 
> >> 
> >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe  wrote:
> >> 
> >> 
> >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli  wrote:
> >>> 
> >>> Just doing 
> >>> NetNameResolver 
> >>> primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult
> >>> produces the bogus result. And both methods only call primitives in the 
> >>> SocketPlugin. So I think that no image code is responsible for the 
> >>> behavior change.
> >> 
> >> I don't know, but your example is not good. You have to wait else the 
> >> result is always 0.0.0.0
> >> 
> >> Pharo 7
> >> 
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
> >> waitForCompletionUntil: 5 
> >> 
> >> false (signal exception)
> >> 
> >> Pharo 9
> >> 
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
> >> waitForCompletionUntil: 5
> >> 
> >> true (bogus 0.0.0.0 result)
> >> 
> >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe  
> >>> wrote:
> >>> Hi,
> >>> 
> >>> It seems that we have a serious NetNameResolver regression: instead of 
> >>> signalling an exception, a bogus value is returned.
> >>> 
> >>> Pharo 7:
> >>> 
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
> >>> NameLookupFailure do: [ :exception | exception ]. 
> >>> 
> >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'"
> >>> 
> >>> Pharo 9:
> >>> 
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
> >>> NameLookupFailure do: [ :exception | exception ]. 
> >>> 
> >>> "0.0.0.0"
> >>> 
> >>> This is bad. What is even worse is that the following kills your image 
> >>> without leaving any trace (on macOS):
> >>> 
> >>> ZnClient new get: 'http://unknown-stfx.eu'.
> >>> 
> >>> Because it tries to connect to 0.0.0.0
> >>> 
> >>> On linux, at least there is a backtrace:
> >>> 
> >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
> >>> NeoConsole 
> >>> Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 
> >>> Bit)
> >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10.
> >>> 
> >>> 0.0.0.0
> >>> pharo> ZnClient new get: 'http://unknown-stfx.eu'.
> >>> 
> >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80
> >>> [ConnectionTimedOut signal: 'Cannot connect to '
> >>>, (NetNameResolver 
> >>> stringFromAddress: hostAddress) , ':' , port asString] in 
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>>Receiver: a Socket[unconnected]
> >>>Arguments and temporary variables: 
> >>>hostAddress:0.0.0.0
> >>>port:   80
> >>>timeout:30
> >>>Receiver's instance variables: 
> >>>semaphore:  a Semaphore()
> >>>socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 
> >>> 0]
> >>>readSemaphore:  a Semaphore()
> >>>writeSemaphore: a Semaphore()
> >>> 
> >>> Socket>>waitForConnectionFor:ifTimedOut:
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
> >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
> >>> ZdcSocketStream class(ZdcSimpleSocketStream 
> >>> class)>>openConnectionToHost:port:timeout:
> >>> ZnNetworkingUtils>>socketStreamToUrlDirectly:
> >>> ZnNetworkingUtils>>socketStreamToUrl:
> >>> ZnNetworkingUtils class>>socketStreamToUrl:
> >>> 
> >>> I had a quick look at changes to Network-Kernel but had no luck yet. 
> >>> 
> >>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 also 
> >>> kills the image (ZnClientTest>>#testIfFailNonExistingHost).
> >>> 
> >>> Of course, NetNameResolverTest does not do enough.
> >>> 
> >>> Sven
> 
> 
> -- 
> Pablo Tesone.
> teso...@gmail.com

[Pharo-dev] Re: Serious NetNameResolver regression

2021-07-16 Thread Sven Van Caekenberghe 
Thank you!

> On 16 Jul 2021, at 12:10, Guillermo Polito  wrote:
> 
> Hi all,
> 
> it seems we need a new VM release.
> The issue seems fixed since ~6 months ago
> 
> https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb
> 
> Pablo is updating the stable VMs just in this moment.
> 
> G
> 
>> El 16 jul 2021, a las 12:07, Sven Van Caekenberghe  escribió:
>> 
>> Anyway, for now, I added guards:
>> 
>> https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
>> https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
>> 
>> but the core problem remains.
>> 
>>> On 15 Jul 2021, at 21:35, Gabriel Cotelli  wrote:
>>> 
>>> You're right Sven. The code in the image looks exactly the same betwen 
>>> Pharo 8 and 9 but the behavior is different. 
>>> 
>>> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe  wrote:
>>> 
>>> 
 On 15 Jul 2021, at 16:42, Gabriel Cotelli  wrote:
 
 Just doing 
 NetNameResolver 
 primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult
 produces the bogus result. And both methods only call primitives in the 
 SocketPlugin. So I think that no image code is responsible for the 
 behavior change.
>>> 
>>> I don't know, but your example is not good. You have to wait else the 
>>> result is always 0.0.0.0
>>> 
>>> Pharo 7
>>> 
>>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
>>> waitForCompletionUntil: 5 
>>> 
>>> false (signal exception)
>>> 
>>> Pharo 9
>>> 
>>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
>>> waitForCompletionUntil: 5
>>> 
>>> true (bogus 0.0.0.0 result)
>>> 
 On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe  
 wrote:
 Hi,
 
 It seems that we have a serious NetNameResolver regression: instead of 
 signalling an exception, a bogus value is returned.
 
 Pharo 7:
 
 [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
 NameLookupFailure do: [ :exception | exception ]. 
 
 "NameLookupFailure: cannot resolve 'unknown-stfx.eu'"
 
 Pharo 9:
 
 [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
 NameLookupFailure do: [ :exception | exception ]. 
 
 "0.0.0.0"
 
 This is bad. What is even worse is that the following kills your image 
 without leaving any trace (on macOS):
 
 ZnClient new get: 'http://unknown-stfx.eu'.
 
 Because it tries to connect to 0.0.0.0
 
 On linux, at least there is a backtrace:
 
 sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
 NeoConsole 
 Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 
 Bit)
 pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10.
 
 0.0.0.0
 pharo> ZnClient new get: 'http://unknown-stfx.eu'.
 
 ConnectionTimedOut: Cannot connect to 0.0.0.0:80
 [ConnectionTimedOut signal: 'Cannot connect to '
   , (NetNameResolver 
 stringFromAddress: hostAddress) , ':' , port asString] in 
 Socket>>connectTo:port:waitForConnectionFor:
   Receiver: a Socket[unconnected]
   Arguments and temporary variables: 
   hostAddress:0.0.0.0
   port:   80
   timeout:30
   Receiver's instance variables: 
   semaphore:  a Semaphore()
   socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0]
   readSemaphore:  a Semaphore()
   writeSemaphore: a Semaphore()
 
 Socket>>waitForConnectionFor:ifTimedOut:
 Socket>>connectTo:port:waitForConnectionFor:
 ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
 ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
 ZdcSocketStream class(ZdcSimpleSocketStream 
 class)>>openConnectionToHost:port:timeout:
 ZnNetworkingUtils>>socketStreamToUrlDirectly:
 ZnNetworkingUtils>>socketStreamToUrl:
 ZnNetworkingUtils class>>socketStreamToUrl:
 
 I had a quick look at changes to Network-Kernel but had no luck yet. 
 
 Because of this running Zinc HTTP Components tests on macOS Pharo 9 also 
 kills the image (ZnClientTest>>#testIfFailNonExistingHost).
 
 Of course, NetNameResolverTest does not do enough.
 
 Sven

[Pharo-dev] Re: Serious NetNameResolver regression

2021-07-16 Thread Tim Mackinnon 
You guys are awesome - such a great community.

> On 16 Jul 2021, at 12:18, teso...@gmail.com wrote:
> 
> I have updated the VMs, the issue should be resolved now.
> 
> On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito  > wrote:
> Hi all,
> 
> it seems we need a new VM release.
> The issue seems fixed since ~6 months ago
> 
> https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb
>  
> 
> 
> Pablo is updating the stable VMs just in this moment.
> 
> G
> 
> > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe  > > escribió:
> > 
> > Anyway, for now, I added guards:
> > 
> > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
> >  
> > 
> > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
> >  
> > 
> > 
> > but the core problem remains.
> > 
> >> On 15 Jul 2021, at 21:35, Gabriel Cotelli  >> > wrote:
> >> 
> >> You're right Sven. The code in the image looks exactly the same betwen 
> >> Pharo 8 and 9 but the behavior is different. 
> >> 
> >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe  >> > wrote:
> >> 
> >> 
> >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli  >>> > wrote:
> >>> 
> >>> Just doing 
> >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu 
> >>> ';primNameLookupResult
> >>> produces the bogus result. And both methods only call primitives in the 
> >>> SocketPlugin. So I think that no image code is responsible for the 
> >>> behavior change.
> >> 
> >> I don't know, but your example is not good. You have to wait else the 
> >> result is always 0.0.0.0
> >> 
> >> Pharo 7
> >> 
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu 
> >> '; waitForCompletionUntil: 5 
> >> 
> >> false (signal exception)
> >> 
> >> Pharo 9
> >> 
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu 
> >> '; waitForCompletionUntil: 5
> >> 
> >> true (bogus 0.0.0.0 result)
> >> 
> >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe  >>> > wrote:
> >>> Hi,
> >>> 
> >>> It seems that we have a serious NetNameResolver regression: instead of 
> >>> signalling an exception, a bogus value is returned.
> >>> 
> >>> Pharo 7:
> >>> 
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu 
> >>> ' timeout: 10 ] on: NameLookupFailure do: [ 
> >>> :exception | exception ]. 
> >>> 
> >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu 
> >>> '"
> >>> 
> >>> Pharo 9:
> >>> 
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu 
> >>> ' timeout: 10 ] on: NameLookupFailure do: [ 
> >>> :exception | exception ]. 
> >>> 
> >>> "0.0.0.0"
> >>> 
> >>> This is bad. What is even worse is that the following kills your image 
> >>> without leaving any trace (on macOS):
> >>> 
> >>> ZnClient new get: 'http://unknown-stfx.eu '.
> >>> 
> >>> Because it tries to connect to 0.0.0.0
> >>> 
> >>> On linux, at least there is a backtrace:
> >>> 
> >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
> >>> NeoConsole 
> >>> Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 
> >>> Bit)
> >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu 
> >>> ' timeout: 10.
> >>> 
> >>> 0.0.0.0
> >>> pharo> ZnClient new get: 'http://unknown-stfx.eu 
> >>> '.
> >>> 
> >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 
> >>> [ConnectionTimedOut signal: 'Cannot connect to '
> >>>, (NetNameResolver 
> >>> stringFromAddress: hostAddress) , ':' , port asString] in 
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>>Receiver: a Socket[unconnected]
> >>>Arguments and temporary variables: 
> >>>hostAddress:0.0.0.0
> >>>port:   80
> >>>timeout:30
> >>>Receiver's instance variables: 
> >>>semaphore:  a Semaphore()
> >>>socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 
> >>> 0]
> >>>readSemaphore:  a Semaphore()
> >>>writeSemaphore: a Semaphore()
> >>> 
> >>> Socket>>waitForConnectionFor:ifTimedOut:
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
> >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
> >>> ZdcSocketStream class(ZdcSimpleSocketStream 
> >>>

[Pharo-dev] Re: Serious NetNameResolver regression

2021-07-16 Thread teso...@gmail.com 
I have updated the VMs, the issue should be resolved now.

On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito 
wrote:

> Hi all,
>
> it seems we need a new VM release.
> The issue seems fixed since ~6 months ago
>
>
> https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb
>
> Pablo is updating the stable VMs just in this moment.
>
> G
>
> > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe 
> escribió:
> >
> > Anyway, for now, I added guards:
> >
> >
> https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
> >
> https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
> >
> > but the core problem remains.
> >
> >> On 15 Jul 2021, at 21:35, Gabriel Cotelli  wrote:
> >>
> >> You're right Sven. The code in the image looks exactly the same betwen
> Pharo 8 and 9 but the behavior is different.
> >>
> >> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe 
> wrote:
> >>
> >>
> >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli  wrote:
> >>>
> >>> Just doing
> >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu
> ';primNameLookupResult
> >>> produces the bogus result. And both methods only call primitives in
> the SocketPlugin. So I think that no image code is responsible for the
> behavior change.
> >>
> >> I don't know, but your example is not good. You have to wait else the
> result is always 0.0.0.0
> >>
> >> Pharo 7
> >>
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';
> waitForCompletionUntil: 5
> >>
> >> false (signal exception)
> >>
> >> Pharo 9
> >>
> >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';
> waitForCompletionUntil: 5
> >>
> >> true (bogus 0.0.0.0 result)
> >>
> >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe 
> wrote:
> >>> Hi,
> >>>
> >>> It seems that we have a serious NetNameResolver regression: instead of
> signalling an exception, a bogus value is returned.
> >>>
> >>> Pharo 7:
> >>>
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on:
> NameLookupFailure do: [ :exception | exception ].
> >>>
> >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'"
> >>>
> >>> Pharo 9:
> >>>
> >>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on:
> NameLookupFailure do: [ :exception | exception ].
> >>>
> >>> "0.0.0.0"
> >>>
> >>> This is bad. What is even worse is that the following kills your image
> without leaving any trace (on macOS):
> >>>
> >>> ZnClient new get: 'http://unknown-stfx.eu'.
> >>>
> >>> Because it tries to connect to 0.0.0.0
> >>>
> >>> On linux, at least there is a backtrace:
> >>>
> >>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
> >>> NeoConsole
> Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit)
> >>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10.
> >>>
> >>> 0.0.0.0
> >>> pharo> ZnClient new get: 'http://unknown-stfx.eu'.
> >>>
> >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80
> >>> [ConnectionTimedOut signal: 'Cannot connect to '
> >>>, (NetNameResolver
> stringFromAddress: hostAddress) , ':' , port asString] in
> Socket>>connectTo:port:waitForConnectionFor:
> >>>Receiver: a Socket[unconnected]
> >>>Arguments and temporary variables:
> >>>hostAddress:0.0.0.0
> >>>port:   80
> >>>timeout:30
> >>>Receiver's instance variables:
> >>>semaphore:  a Semaphore()
> >>>socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0
> 0 0 0]
> >>>readSemaphore:  a Semaphore()
> >>>writeSemaphore: a Semaphore()
> >>>
> >>> Socket>>waitForConnectionFor:ifTimedOut:
> >>> Socket>>connectTo:port:waitForConnectionFor:
> >>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
> >>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
> >>> ZdcSocketStream class(ZdcSimpleSocketStream
> class)>>openConnectionToHost:port:timeout:
> >>> ZnNetworkingUtils>>socketStreamToUrlDirectly:
> >>> ZnNetworkingUtils>>socketStreamToUrl:
> >>> ZnNetworkingUtils class>>socketStreamToUrl:
> >>>
> >>> I had a quick look at changes to Network-Kernel but had no luck yet.
> >>>
> >>> Because of this running Zinc HTTP Components tests on macOS Pharo 9
> also kills the image (ZnClientTest>>#testIfFailNonExistingHost).
> >>>
> >>> Of course, NetNameResolverTest does not do enough.
> >>>
> >>> Sven
>


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

[Pharo-dev] Re: Serious NetNameResolver regression

2021-07-16 Thread Guillermo Polito 
Hi all,

it seems we need a new VM release.
The issue seems fixed since ~6 months ago

https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce104d8f38d60242fa1cc2bb

Pablo is updating the stable VMs just in this moment.

G

> El 16 jul 2021, a las 12:07, Sven Van Caekenberghe  escribió:
> 
> Anyway, for now, I added guards:
> 
> https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
> https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64
> 
> but the core problem remains.
> 
>> On 15 Jul 2021, at 21:35, Gabriel Cotelli  wrote:
>> 
>> You're right Sven. The code in the image looks exactly the same betwen Pharo 
>> 8 and 9 but the behavior is different. 
>> 
>> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe  wrote:
>> 
>> 
>>> On 15 Jul 2021, at 16:42, Gabriel Cotelli  wrote:
>>> 
>>> Just doing 
>>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult
>>> produces the bogus result. And both methods only call primitives in the 
>>> SocketPlugin. So I think that no image code is responsible for the behavior 
>>> change.
>> 
>> I don't know, but your example is not good. You have to wait else the result 
>> is always 0.0.0.0
>> 
>> Pharo 7
>> 
>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
>> waitForCompletionUntil: 5 
>> 
>> false (signal exception)
>> 
>> Pharo 9
>> 
>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
>> waitForCompletionUntil: 5
>> 
>> true (bogus 0.0.0.0 result)
>> 
>>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe  wrote:
>>> Hi,
>>> 
>>> It seems that we have a serious NetNameResolver regression: instead of 
>>> signalling an exception, a bogus value is returned.
>>> 
>>> Pharo 7:
>>> 
>>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
>>> NameLookupFailure do: [ :exception | exception ]. 
>>> 
>>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu'"
>>> 
>>> Pharo 9:
>>> 
>>> [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
>>> NameLookupFailure do: [ :exception | exception ]. 
>>> 
>>> "0.0.0.0"
>>> 
>>> This is bad. What is even worse is that the following kills your image 
>>> without leaving any trace (on macOS):
>>> 
>>> ZnClient new get: 'http://unknown-stfx.eu'.
>>> 
>>> Because it tries to connect to 0.0.0.0
>>> 
>>> On linux, at least there is a backtrace:
>>> 
>>> sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
>>> NeoConsole 
>>> Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit)
>>> pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10.
>>> 
>>> 0.0.0.0
>>> pharo> ZnClient new get: 'http://unknown-stfx.eu'.
>>> 
>>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80
>>> [ConnectionTimedOut signal: 'Cannot connect to '
>>>, (NetNameResolver 
>>> stringFromAddress: hostAddress) , ':' , port asString] in 
>>> Socket>>connectTo:port:waitForConnectionFor:
>>>Receiver: a Socket[unconnected]
>>>Arguments and temporary variables: 
>>>hostAddress:0.0.0.0
>>>port:   80
>>>timeout:30
>>>Receiver's instance variables: 
>>>semaphore:  a Semaphore()
>>>socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 0]
>>>readSemaphore:  a Semaphore()
>>>writeSemaphore: a Semaphore()
>>> 
>>> Socket>>waitForConnectionFor:ifTimedOut:
>>> Socket>>connectTo:port:waitForConnectionFor:
>>> ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
>>> ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
>>> ZdcSocketStream class(ZdcSimpleSocketStream 
>>> class)>>openConnectionToHost:port:timeout:
>>> ZnNetworkingUtils>>socketStreamToUrlDirectly:
>>> ZnNetworkingUtils>>socketStreamToUrl:
>>> ZnNetworkingUtils class>>socketStreamToUrl:
>>> 
>>> I had a quick look at changes to Network-Kernel but had no luck yet. 
>>> 
>>> Because of this running Zinc HTTP Components tests on macOS Pharo 9 also 
>>> kills the image (ZnClientTest>>#testIfFailNonExistingHost).
>>> 
>>> Of course, NetNameResolverTest does not do enough.
>>> 
>>> Sven

[Pharo-dev] Re: Serious NetNameResolver regression

2021-07-16 Thread Sven Van Caekenberghe 
Anyway, for now, I added guards:

https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05deb8
https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440b2c64

but the core problem remains.

> On 15 Jul 2021, at 21:35, Gabriel Cotelli  wrote:
> 
> You're right Sven. The code in the image looks exactly the same betwen Pharo 
> 8 and 9 but the behavior is different. 
> 
> On Thu, Jul 15, 2021 at 3:40 PM Sven Van Caekenberghe  wrote:
> 
> 
> > On 15 Jul 2021, at 16:42, Gabriel Cotelli  wrote:
> > 
> > Just doing 
> > NetNameResolver primStartLookupOfName:'unknown-stfx.eu';primNameLookupResult
> > produces the bogus result. And both methods only call primitives in the 
> > SocketPlugin. So I think that no image code is responsible for the behavior 
> > change.
> 
> I don't know, but your example is not good. You have to wait else the result 
> is always 0.0.0.0
> 
> Pharo 7
> 
> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
> waitForCompletionUntil: 5 
> 
> false (signal exception)
> 
> Pharo 9
> 
> NetNameResolver primStartLookupOfName:'unknown-stfx.eu'; 
> waitForCompletionUntil: 5
> 
> true (bogus 0.0.0.0 result)
> 
> > On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe  wrote:
> > Hi,
> > 
> > It seems that we have a serious NetNameResolver regression: instead of 
> > signalling an exception, a bogus value is returned.
> > 
> > Pharo 7:
> > 
> > [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
> > NameLookupFailure do: [ :exception | exception ]. 
> > 
> > "NameLookupFailure: cannot resolve 'unknown-stfx.eu'"
> > 
> > Pharo 9:
> > 
> > [ NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10 ] on: 
> > NameLookupFailure do: [ :exception | exception ]. 
> > 
> > "0.0.0.0"
> > 
> > This is bad. What is even worse is that the following kills your image 
> > without leaving any trace (on macOS):
> > 
> > ZnClient new get: 'http://unknown-stfx.eu'.
> > 
> > Because it tries to connect to 0.0.0.0
> > 
> > On linux, at least there is a backtrace:
> > 
> > sven@stfx-1:~/pharo$ rlwrap ./pharo reddit.image NeoConsole repl
> > NeoConsole 
> > Pharo-9.0.0+build.1528.sha.29269ecfac2cbf6a56dfee232b7d3355e5cb77bd (64 Bit)
> > pharo> NetNameResolver addressForName: 'unknown-stfx.eu' timeout: 10.
> > 
> > 0.0.0.0
> > pharo> ZnClient new get: 'http://unknown-stfx.eu'.
> > 
> > ConnectionTimedOut: Cannot connect to 0.0.0.0:80
> > [ConnectionTimedOut signal: 'Cannot connect to '
> > , (NetNameResolver 
> > stringFromAddress: hostAddress) , ':' , port asString] in 
> > Socket>>connectTo:port:waitForConnectionFor:
> > Receiver: a Socket[unconnected]
> > Arguments and temporary variables: 
> > hostAddress:0.0.0.0
> > port:   80
> > timeout:30
> > Receiver's instance variables: 
> > semaphore:  a Semaphore()
> > socketHandle:   #[198 113 243 96 0 0 0 0 240 65 61 2 0 0 0 
> > 0]
> > readSemaphore:  a Semaphore()
> > writeSemaphore: a Semaphore()
> > 
> > Socket>>waitForConnectionFor:ifTimedOut:
> > Socket>>connectTo:port:waitForConnectionFor:
> > ZdcSocketStream(ZdcAbstractSocketStream)>>socketConnectTo:port:
> > ZdcSocketStream(ZdcSimpleSocketStream)>>connectTo:port:
> > ZdcSocketStream class(ZdcSimpleSocketStream 
> > class)>>openConnectionToHost:port:timeout:
> > ZnNetworkingUtils>>socketStreamToUrlDirectly:
> > ZnNetworkingUtils>>socketStreamToUrl:
> > ZnNetworkingUtils class>>socketStreamToUrl:
> > 
> > I had a quick look at changes to Network-Kernel but had no luck yet. 
> > 
> > Because of this running Zinc HTTP Components tests on macOS Pharo 9 also 
> > kills the image (ZnClientTest>>#testIfFailNonExistingHost).
> > 
> > Of course, NetNameResolverTest does not do enough.
> > 
> > Sven

[Pharo-dev] Re: [ANN] Pharo 9 released!

2021-07-16 Thread Denis Kudriashov 
Congrats!

Is Launcher updated to Pharo 9?

чт, 15 июл. 2021 г. в 10:15, Esteban Lorenzano :

> Dear World and dynamic language lovers:
>
> The time has come for Pharo 9  !
>
> Pharo is a pure object-oriented programming language and a powerful
> environment, focused on simplicity and immediate feedback.
>
>
> Here are the key features of Pharo 9:
>
>
>- Full redesign of the Spec UI framework (new logic, application,
>style, GTK3 back-end)
>- New tools:
>-
>   - new playground,
>   - new object centric inspector,
>   - new object centric debugger.
>   - better and new Refactorings
>   - class comments are now written in Microdown format (Markdown
>   compatible)
>   - classes now can be defined using a "fluid" api (Preview)
>   - New completion framework that adapts better to edition contexts
>and is customizable
>- Fast universal non-blocking FFI which now uses libFFI as backend.
>- Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora,
>openSUSE, Arch, Raspbian) and multiple architectures (Intel/ARM 32/64bits).
>- Virtual Machine
>-
>   - Idle VM
>   - Support for ARM 64bits
>   - Support for Apple M1
>   - More than 3000 tests
>   - Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 10,
>   Testing; Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; 
> Arch
>   - Uses SDL 2.0 as back-end by default. It supports extended event
>handling, including trackpad support.
>- General speed up due to compiler optimisations and UI simplification.
>- And many, many more tests.
>
>
> These are just the more prominent highlights, but the details are just as
> important. We have closed a massive amount of issues: around 1400 issues
> and 2150 pull requests.
>
> A more extended changelog can be found at
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90ChangeLogs.md
> .
>
> While the technical improvements are significant, still the most
> impressive fact is that the new code that got in the main Pharo 9 image was
> contributed by more than 90 people.
>
> Pharo is more than code. It is an exciting project involving a great
> community.
>
> We thank all the contributors to this release:
>
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Ale Cossio, Alexandre
> Bergel, Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano,
> Asbathou Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos
> Lopez, Carolina Hernandez, Charles A. Monteiro, Christoph Thiede,
> Christophe Demarey, Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel
> Aparicio, David Bajger, David Sánchez i Gregori, Denis Kudriashov, Ellis
> Harris, Eric Brandwein, Eric Gade, Erik Stel, ErikOnBike, Esteban
> Lorenzano, Esteban Villalobos, Evelyn Cusi Lopez, Evelyn Cusi Lopez, Ewan
> Dawson, Francis Pineda, Francis Pineda, Gabriel Omar Cotelli, Geraldine
> Galindo, Giovanni Corriga, Guille Polito, Himanshu jld, Johan Brichau,
> Jonathan van Alteren, Jordan Montt, Julien Delplanque, Kamil Kukura, Kasper
> Østerbye, Kurt Kilpela, Laurine Dargaud, Marco Rimoldi, Marcus Denker,
> Martin Dias, Martin McClure, Massimo Nocentini, Max Leske, Maximilian
> Ignacio Willembrinck Santander, Milton Mamani Torres, Moussa Saker,
> Myroslava Romaniuk, Nicolas Anquetil, Norbert Hartl, Nour Djihan, Oleksandr
> Zaitsev, Pablo Sánchez Rodríguez, Pablo Tesone, Pavel Krivanek, Philippe
> Lesueur, Pierre Misse, Rakshit P., Rob Sayers, Roland Bernard, Ronie
> Salgado, Sean DeNigris, Sebastian Jordan Montaño, Serge Stinckwich, Stephan
> Eggermont, Steven Costiou, Stéphane Ducasse, Sven Van Caekenberghe, Thomas
> Dupriez, Théo Lanord, Théo Rogliano, Todd Blanchard, Torsten Bergmann,
> Vincent Blondeau, Wéslleymberg Lisboa.
>
>
> (If you contributed with Pharo 9 development in any way and we missed your
> name, please send us an email and we will add you).
>
> Enjoy!
>
> The Pharo Team
>
> Try Pharo: http://pharo.org/download 
>
> Learn Pharo: http://pharo.org/documentation
> 
>

[Pharo-dev] Re: [ANN] Pharo 9 released!

2021-07-16 Thread Tudor Girba 
Congratulations!

Tudor

> On Jul 15, 2021, at 11:14 AM, Esteban Lorenzano  wrote:
> 
> Dear World and dynamic language lovers: 
> 
> The time has come for Pharo 9 !
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> 
> 
> Here are the key features of Pharo 9:   
> 
>   • Full redesign of the Spec UI framework (new logic, application, 
> style, GTK3 back-end)
>   • New tools:
>   •
>   • new playground,
>   • new object centric inspector,
>   • new object centric debugger.
>   • better and new Refactorings
>   • class comments are now written in Microdown format (Markdown 
> compatible)
>   • classes now can be defined using a "fluid" api (Preview)
>   • New completion framework that adapts better to edition contexts and 
> is customizable
>   • Fast universal non-blocking FFI which now uses libFFI as backend.
>   • Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora, 
> openSUSE, Arch, Raspbian) and multiple architectures (Intel/ARM 32/64bits).
>   • Virtual Machine
>   •
>   • Idle VM
>   • Support for ARM 64bits
>   • Support for Apple M1
>   • More than 3000 tests
>   • Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 
> 10, Testing; Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; Arch
>   • Uses SDL 2.0 as back-end by default. It supports extended event 
> handling, including trackpad support.
>   • General speed up due to compiler optimisations and UI simplification.
>   • And many, many more tests.
> 
> These are just the more prominent highlights, but the details are just as 
> important. We have closed a massive amount of issues: around 1400 issues and 
> 2150 pull requests.
> 
> A more extended changelog can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90ChangeLogs.md.
> 
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 9 image was contributed 
> by more than 90 people.
> 
> Pharo is more than code. It is an exciting project involving a great 
> community. 
> 
> We thank all the contributors to this release:
> 
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Ale Cossio, Alexandre Bergel, 
> Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano, Asbathou 
> Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos Lopez, 
> Carolina Hernandez, Charles A. Monteiro, Christoph Thiede, Christophe 
> Demarey, Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel Aparicio, 
> David Bajger, David Sánchez i Gregori, Denis Kudriashov, Ellis Harris, Eric 
> Brandwein, Eric Gade, Erik Stel, ErikOnBike, Esteban Lorenzano, Esteban 
> Villalobos, Evelyn Cusi Lopez, Evelyn Cusi Lopez, Ewan Dawson, Francis 
> Pineda, Francis Pineda, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni 
> Corriga, Guille Polito, Himanshu jld, Johan Brichau, Jonathan van Alteren, 
> Jordan Montt, Julien Delplanque, Kamil Kukura, Kasper Østerbye, Kurt Kilpela, 
> Laurine Dargaud, Marco Rimoldi, Marcus Denker, Martin Dias, Martin McClure, 
> Massimo Nocentini, Max Leske, Maximilian Ignacio Willembrinck Santander, 
> Milton Mamani Torres, Moussa Saker, Myroslava Romaniuk, Nicolas Anquetil, 
> Norbert Hartl, Nour Djihan, Oleksandr Zaitsev, Pablo Sánchez Rodríguez, Pablo 
> Tesone, Pavel Krivanek, Philippe Lesueur, Pierre Misse, Rakshit P., Rob 
> Sayers, Roland Bernard, Ronie Salgado, Sean DeNigris, Sebastian Jordan 
> Montaño, Serge Stinckwich, Stephan Eggermont, Steven Costiou, Stéphane 
> Ducasse, Sven Van Caekenberghe, Thomas Dupriez, Théo Lanord, Théo Rogliano, 
> Todd Blanchard, Torsten Bergmann, Vincent Blondeau, Wéslleymberg Lisboa.
>  
> 
> (If you contributed with Pharo 9 development in any way and we missed your 
> name, please send us an email and we will add you).
> 
> Enjoy!
> 
> The Pharo Team
> 
> Try Pharo: http://pharo.org/download
> 
> Learn Pharo: http://pharo.org/documentation

--
feenk.com

"No matter how many recipes we know, we still value a chef."

[Pharo-dev] Re: [Pharo-users] [ANN] Pharo 9 released!

2021-07-16 Thread Norbert Hartl 
Great news! Finally it arrived. Big changes happened and this release might 
feel a bit rough. But that is expected. And we should not underestimate the 
value of moving all tools to spec. That makes all of it (yet again) less 
dependent in morphic. Having an idle vm is also highly appreciated for peole 
like me that do a lot of server installations.

Well done and thanks for the hard work!

Norbert

> Am 15.07.2021 um 11:15 schrieb Esteban Lorenzano :
> 
> 
> Dear World and dynamic language lovers: 
> 
> The time has come for Pharo 9 !
> 
> Pharo is a pure object-oriented programming language and a powerful 
> environment, focused on simplicity and immediate feedback.
> 
> 
> 
> Here are the key features of Pharo 9:   
> 
> Full redesign of the Spec UI framework (new logic, application, style, GTK3 
> back-end)
> New tools:
> new playground,
> new object centric inspector,
> new object centric debugger.
> better and new Refactorings
> class comments are now written in Microdown format (Markdown compatible)
> classes now can be defined using a "fluid" api (Preview)
> New completion framework that adapts better to edition contexts and is 
> customizable
> Fast universal non-blocking FFI which now uses libFFI as backend.
> Pharo now supports Windows, OSX, Linux (Ubuntu, Debian, Fedora, openSUSE, 
> Arch, Raspbian) and multiple architectures (Intel/ARM 32/64bits).
> Virtual Machine
> Idle VM
> Support for ARM 64bits
> Support for Apple M1
> More than 3000 tests
> Built for Ubuntu 18.04, 19.04, 20.04, 21.04, 21.10; Debian 9, 10, Testing; 
> Fedora 32, 32, 34; openSUSE 15.1, 15.2, Tumbleweed; Manjaro; Arch
> Uses SDL 2.0 as back-end by default. It supports extended event handling, 
> including trackpad support.
> General speed up due to compiler optimisations and UI simplification.
> And many, many more tests.
> 
> These are just the more prominent highlights, but the details are just as 
> important. We have closed a massive amount of issues: around 1400 issues and 
> 2150 pull requests.
> 
> A more extended changelog can be found at 
> https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo90ChangeLogs.md.
> 
> While the technical improvements are significant, still the most impressive 
> fact is that the new code that got in the main Pharo 9 image was contributed 
> by more than 90 people.
> 
> Pharo is more than code. It is an exciting project involving a great 
> community. 
> 
> We thank all the contributors to this release:
> 
> Aaron Bieber, Ackerley Tng, Alban Benmouffek, Ale Cossio, Alexandre Bergel, 
> Alistair Grant, Allex Oliveira, Angela Chia-Ling, Arturo Zambrano, Asbathou 
> Biyalou-Sama, Ben Coman, Benoit Verhaegue, Carlo Teixeira, Carlos Lopez, 
> Carolina Hernandez, Charles A. Monteiro, Christoph Thiede, Christophe 
> Demarey, Clotilde Toullec, Cyril Ferlicot, Damien Pollet, Daniel Aparicio, 
> David Bajger, David Sánchez i Gregori, Denis Kudriashov, Ellis Harris, Eric 
> Brandwein, Eric Gade, Erik Stel, ErikOnBike, Esteban Lorenzano, Esteban 
> Villalobos, Evelyn Cusi Lopez, Evelyn Cusi Lopez, Ewan Dawson, Francis 
> Pineda, Francis Pineda, Gabriel Omar Cotelli, Geraldine Galindo, Giovanni 
> Corriga, Guille Polito, Himanshu jld, Johan Brichau, Jonathan van Alteren, 
> Jordan Montt, Julien Delplanque, Kamil Kukura, Kasper Østerbye, Kurt Kilpela, 
> Laurine Dargaud, Marco Rimoldi, Marcus Denker, Martin Dias, Martin McClure, 
> Massimo Nocentini, Max Leske, Maximilian Ignacio Willembrinck Santander, 
> Milton Mamani Torres, Moussa Saker, Myroslava Romaniuk, Nicolas Anquetil, 
> Norbert Hartl, Nour Djihan, Oleksandr Zaitsev, Pablo Sánchez Rodríguez, Pablo 
> Tesone, Pavel Krivanek, Philippe Lesueur, Pierre Misse, Rakshit P., Rob 
> Sayers, Roland Bernard, Ronie Salgado, Sean DeNigris, Sebastian Jordan 
> Montaño, Serge Stinckwich, Stephan Eggermont, Steven Costiou, Stéphane 
> Ducasse, Sven Van Caekenberghe, Thomas Dupriez, Théo Lanord, Théo Rogliano, 
> Todd Blanchard, Torsten Bergmann, Vincent Blondeau, Wéslleymberg Lisboa.
>  
> 
> (If you contributed with Pharo 9 development in any way and we missed your 
> name, please send us an email and we will add you).
> 
> Enjoy!
> 
> The Pharo Team
> 
> Try Pharo: http://pharo.org/download
> 
> Learn Pharo: http://pharo.org/documentation