July 2021 - Pharo-dev - lists.pharo.org

Re: Metacello / Iceberg / GitHub master to main renaming

by Tim Mackinnon

Maybe itâs worth putting something in an faq - that we support the intent of the master to main naming convention, but that as we are a small community trying to improve many aspects of 50 years of development, this one had to unfortunately take a back seat for the moment while we simplify other things to make this an easier change? Tim > On 19 Jul 2021, at 12:26, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > ï»¿Sven > > From that perspective this master to main change will cost us a lot of problem. > I decided to continue to configure all my repositories to use master and I will do it for any repository that is related to > pharo and that people may use. Just to remove such kind of friction. > I would encourage people to do the same like that we do not have to think. > > S > >> On 12 Jul 2021, at 14:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> For new GitHub projects the default branch is now main instead of master. >> >> There is however code in Metacello / Iceberg / ... that tries a number of options if no branch is specified, but it is not yet aware of this change. >> >> Specifically: >> >> This does not work >> >> ./pharo reddit.image metacello install github://svenvc/Reddit BaselineOfReddit >> >> instead you have to say >> >> ./pharo reddit.image metacello install github://svenvc/Reddit:main/ BaselineOfReddit >> >> It took me half an hour to figure this out ;-) >> >> Sven >>

July 19, 2021

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

by Torsten Bergmann

July 19, 2021

Re: Metacello / Iceberg / GitHub master to main renaming

by stephane ducasse

Sven >From that perspective this master to main change will cost us a lot of problem. I decided to continue to configure all my repositories to use master and I will do it for any repository that is related to pharo and that people may use. Just to remove such kind of friction. I would encourage people to do the same like that we do not have to think. S > On 12 Jul 2021, at 14:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > For new GitHub projects the default branch is now main instead of master. > > There is however code in Metacello / Iceberg / ... that tries a number of options if no branch is specified, but it is not yet aware of this change. > > Specifically: > > This does not work > > ./pharo reddit.image metacello install github://svenvc/Reddit BaselineOfReddit > > instead you have to say > > ./pharo reddit.image metacello install github://svenvc/Reddit:main/ BaselineOfReddit > > It took me half an hour to figure this out ;-) > > Sven >

July 19, 2021

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

by tesonep＠gmail.com

Thanks, yes it is true, the version name is a mess. We need to improve the version display. I will take note of that and I will fix it. Cheers, Pablo On Mon, Jul 19, 2021 at 11:08 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Pablo, > > prometheus:2021-07-16 sven$ ./pharo --version > Pharo 9.0.0 built on Jul 6 2021 10:36:56 Compiler: 4.2.1 Compatible Apple > LLVM 11.0.3 (clang-1103.0.32.29) > Built from: ea8a3bfc - Commit: ea8a3bfc - Date: 2021-07-06 10:23:13 +0200 > prometheus:2021-07-16 sven$ ./pharo Pharo.image printVersion > [version] 'Pharo9.0.0' > 'Pharo-9.0.0+build.1532.sha.e58ef49051bf06cad56a2dda174b8e091a45d5df (64 > Bit)' > prometheus:2021-07-16 sven$ ./pharo Pharo.image eval "(ZdcSocketStream > openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo" > > I have said this before, but the VM version is incomprehensible for normal > people, why can't it just be something like 10.1 like the rest of the world > ? > > Also, for mere mortals it is impossible to find out if something changed > about the VM, let alone what, and how that all relates to specific versions. > > I know that you guys have a lot of work, and we are very grateful for it, > but this is how it looks from the outside. > > Thx, > > Sven > > > On 19 Jul 2021, at 10:56, tesonep(a)gmail.com wrote: > > > > Hi, > > with the new VM I could not reproduce it. I think it was related with > the issue of the NetNameResolver. > > Which VM version are you using? > > > > Thanks > > > > On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > 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 > > > > > > -- > > Pablo Tesone. > > tesonep(a)gmail.com > -- Pablo Tesone. tesonep(a)gmail.com

July 19, 2021

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

by Sven Van Caekenberghe

Hi Pablo, prometheus:2021-07-16 sven$ ./pharo --version Pharo 9.0.0 built on Jul 6 2021 10:36:56 Compiler: 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.32.29) Built from: ea8a3bfc - Commit: ea8a3bfc - Date: 2021-07-06 10:23:13 +0200 prometheus:2021-07-16 sven$ ./pharo Pharo.image printVersion [version] 'Pharo9.0.0' 'Pharo-9.0.0+build.1532.sha.e58ef49051bf06cad56a2dda174b8e091a45d5df (64 Bit)' prometheus:2021-07-16 sven$ ./pharo Pharo.image eval "(ZdcSocketStream openConnectionToHostNamed: 'localhost' port: 12335) nextPut: 0; close. #foo" I have said this before, but the VM version is incomprehensible for normal people, why can't it just be something like 10.1 like the rest of the world ? Also, for mere mortals it is impossible to find out if something changed about the VM, let alone what, and how that all relates to specific versions. I know that you guys have a lot of work, and we are very grateful for it, but this is how it looks from the outside. Thx, Sven > On 19 Jul 2021, at 10:56, tesonep(a)gmail.com wrote: > > Hi, > with the new VM I could not reproduce it. I think it was related with the issue of the NetNameResolver. > Which VM version are you using? > > Thanks > > On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 > > > -- > Pablo Tesone. > tesonep(a)gmail.com

July 19, 2021

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

by tesonep＠gmail.com

Hi, with the new VM I could not reproduce it. I think it was related with the issue of the NetNameResolver. Which VM version are you using? Thanks On Sun, Jul 18, 2021 at 3:51 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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 > -- Pablo Tesone. tesonep(a)gmail.com

July 19, 2021

Progress Report -> Refactoring Project - ( July 12 - July 16)

by Evelyn Cusi Lopez

Hi everyone, Last week I did these tasks: - Improve parametrized tests. - Clean up previous tests of Refactoring1 and Refactoring2 classes. Check these changes in the: PR #9599 <https://github.com/pharo-project/pharo/pull/9599> - Update scope manager to integrate. Check changes here: Scope branch <https://github.com/pharo-project/pharo/compare/Pharo10...Lin777:ScopeManage…> - Split migration from tests to integrate into Pharo. Check changes here: Migration branch. <https://github.com/pharo-project/pharo/compare/Pharo10...Lin777:MigrateRefa…> It will integrate after parametrized tests. - Migrate new refactorings, these changes are in the previous branch Tasks for this week: <https://github.com/pharo-project/pharo/issues/9142> - Continue migrating refactorings. Some of them are: - RBExtractMethodRefactoring - RBFindAndReplaceRefactoring - RBExtractMethodAndOccurrences - RBExtractSetUpRefactoring - RBRenameMethodRefactoring - RBReplaceMethodRefactoring - RBInlineParameterRefactoring Best regards, Evelyn Cusi Lopez

July 19, 2021

[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