- Pharo-dev - lists.pharo.org

[Zdc]SocketStream>>#openConnectionToHostNamed:port: no longer signals am exception on macOS

by Sven Van Caekenberghe

Hi, It seems that the following consistently crashes a recent/latest Pharo 9 image/vm on macOS: (ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. Command line, you can try it as follows: $ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo" You can replace ZdcSocketStream by SocketStream, same result. Before, trying to connect to a non-existing host:port resulted in a ConnectionTimedOut: Cannot connect to 127.0.0.1:12335. Now, the code just returns and the bad stream is then used as if it is OK, which results in a hard crash. Furthermore, there is no backtrace nor log. Sven

July 18, 2021

Re: [ANN] Pharo 9 released!

by 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 <estebanlm(a)netc.eu> wrote: > Dear World and dynamic language lovers: > > The time has come for Pharo 9 <https://pharo.org/> ! > > 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/Pharo90Change… > . > > 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 <https://pharo.org/download> > > Learn Pharo: http://pharo.org/documentation > <https://pharo.org/documentation> >

July 16, 2021

Re: Serious NetNameResolver regression

by Sven Van Caekenberghe

thx. > On 16 Jul 2021, at 12:18, tesonep(a)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 <guillermopolito(a)gmail.com> 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/bff77946691617acce… > > Pablo is updating the stable VMs just in this moment. > > G > > > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > > > Anyway, for now, I added guards: > > > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… > > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… > > > > but the core problem remains. > > > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> wrote: > >> > >> > >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> 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. > tesonep(a)gmail.com

July 16, 2021

Re: Serious NetNameResolver regression

by Sven Van Caekenberghe

Thank you! > On 16 Jul 2021, at 12:10, Guillermo Polito <guillermopolito(a)gmail.com> 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/bff77946691617acce… > > Pablo is updating the stable VMs just in this moment. > > G > >> El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: >> >> Anyway, for now, I added guards: >> >> https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… >> https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… >> >> but the core problem remains. >> >>> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> wrote: >>> >>> >>>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> 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

July 16, 2021

Re: Serious NetNameResolver regression

by Tim Mackinnon

You guys are awesome - such a great community. > On 16 Jul 2021, at 12:18, tesonep(a)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 <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> 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/bff77946691617acce… <https://github.com/pharo-project/opensmalltalk-vm/commit/bff77946691617acce…> > > Pablo is updating the stable VMs just in this moment. > > G > > > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> escribiÃ³: > > > > Anyway, for now, I added guards: > > > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… <https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d…> > > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… <https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440…> > > > > but the core problem remains. > > > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> 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 <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: > >> > >> > >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>> wrote: > >>> > >>> Just doing > >>> NetNameResolver primStartLookupOfName:'unknown-stfx.eu <http://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 <http://unknown-stfx.eu/>'; waitForCompletionUntil: 5 > >> > >> false (signal exception) > >> > >> Pharo 9 > >> > >> NetNameResolver primStartLookupOfName:'unknown-stfx.eu <http://unknown-stfx.eu/>'; waitForCompletionUntil: 5 > >> > >> true (bogus 0.0.0.0 result) > >> > >>> On Thu, Jul 15, 2021 at 11:36 AM Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> 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 <http://unknown-stfx.eu/>' timeout: 10 ] on: NameLookupFailure do: [ :exception | exception ]. > >>> > >>> "NameLookupFailure: cannot resolve 'unknown-stfx.eu <http://unknown-stfx.eu/>'" > >>> > >>> Pharo 9: > >>> > >>> [ NetNameResolver addressForName: 'unknown-stfx.eu <http://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 <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 <http://unknown-stfx.eu/>' timeout: 10. > >>> > >>> 0.0.0.0 > >>> pharo> ZnClient new get: 'http://unknown-stfx.eu <http://unknown-stfx.eu/>'. > >>> > >>> ConnectionTimedOut: Cannot connect to 0.0.0.0:80 <http://0.0.0.0/> > >>> [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. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

July 16, 2021

Re: Serious NetNameResolver regression

by tesonep＠gmail.com

I have updated the VMs, the issue should be resolved now. On Fri, Jul 16, 2021 at 12:10 PM Guillermo Polito <guillermopolito(a)gmail.com> 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/bff77946691617acce… > > Pablo is updating the stable VMs just in this moment. > > G > > > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> > escribiÃ³: > > > > Anyway, for now, I added guards: > > > > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… > > > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… > > > > but the core problem remains. > > > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> > wrote: > >> > >> > >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> > 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. tesonep(a)gmail.com

July 16, 2021

Re: Serious NetNameResolver regression

by 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/bff77946691617acce… Pablo is updating the stable VMs just in this moment. G > El 16 jul 2021, a las 12:07, Sven Van Caekenberghe <sven(a)stfx.eu> escribiÃ³: > > Anyway, for now, I added guards: > > https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… > https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… > > but the core problem remains. > >> On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> wrote: >> >> >>> On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> 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

July 16, 2021

Re: Serious NetNameResolver regression

by Sven Van Caekenberghe

Anyway, for now, I added guards: https://github.com/svenvc/zinc/commit/cac2cb36410c24e9070f850b641e0cd02a05d… https://github.com/svenvc/zodiac/commit/b12ba07f93ab73afad2523d75149c8b5440… but the core problem remains. > On 15 Jul 2021, at 21:35, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> wrote: > > > > On 15 Jul 2021, at 16:42, Gabriel Cotelli <g.cotelli(a)gmail.com> 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 <sven(a)stfx.eu> 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

July 16, 2021

Re: [ANN] Pharo 9 released!

by Denis Kudriashov

Congrats! Is Launcher updated to Pharo 9? ÑÑ, 15 Ð¸ÑÐ». 2021 Ð³. Ð² 10:15, Esteban Lorenzano <estebanlm(a)netc.eu>: > Dear World and dynamic language lovers: > > The time has come for Pharo 9 <https://pharo.org/> ! > > 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/Pharo90Change… > . > > 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 <https://pharo.org/download> > > Learn Pharo: http://pharo.org/documentation > <https://pharo.org/documentation> >

July 16, 2021

Re: [ANN] Pharo 9 released!

by Tudor Girba

Congratulations! Tudor > On Jul 15, 2021, at 11:14 AM, Esteban Lorenzano <estebanlm(a)netc.eu> 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/Pharo90Change…. > > 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."

July 16, 2021