March 2020 - Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #133: 5656-scanTokens-is-bogus

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #133 was: SUCCESS. The Pull Request #5821 was integrated: "5656-scanTokens-is-bogus" Pull request url: https://github.com/pharo-project/pharo/pull/5821 Issue Url: https://github.com/pharo-project/pharo/issues/5656 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2020

[Pharo 9.0] Build #132: isLiteralMethod-should-work-on-sista

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #132 was: FAILURE. The Pull Request #5857 was integrated: "isLiteralMethod-should-work-on-sista" Pull request url: https://github.com/pharo-project/pharo/pull/5857 Issue Url: https://github.com/pharo-project/pharo/issues/isLiteralMethod Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2020

[Pharo 9.0] Build #131: 5438-Finder-glitches

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #131 was: SUCCESS. The Pull Request #5813 was integrated: "5438-Finder-glitches" Pull request url: https://github.com/pharo-project/pharo/pull/5813 Issue Url: https://github.com/pharo-project/pharo/issues/5438 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2020

Re: [Pharo-dev] Mystery solved: Pharo and Unsupported 16 bit application on Windows

by ducasse

would it not be better to use the zip library of pharo? And to fix it if it does not fully work? S > On 5 Mar 2020, at 09:17, tesonep(a)gmail.com wrote: > > Thanks for the analysis. It was a really complicated issue. > > Maybe we need to add validation of the unzip files or a correct detection of the unzip to use. > > Thanks again. > > On Wed, Mar 4, 2020, 19:52 Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > Hi, > > just wanted to share this story of a Windows problem + possible cause so others could be aware: > > > As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables. > Unfortunately afterwards several things got broken: > > When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..." > leaving me with a big question mark. > > > So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7 > VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem. > > I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after > reinstalling Pharo Launcher the problem did not go away. > > What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other. > So I digged deeper in finding out. > > > Meanwhile I know the difference: > > - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM > that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe > > - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe) > > As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up. > Just evaluate > > PhLVirtualMachineManager canUseSytemZip > > in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower. > > So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of > VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader > then thinks it is an old unsupported 16 bit application. > > Checking the version on command line for unzip exe tells me: > > UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. > > When I rename that executable I found another one telling me > > GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood. > > A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false. > Slower - but the Pharo code is more reliable here. > > Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine > still unsolved or reappearing. > > Side note: > ========= > It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349 <https://github.com/pharo-project/pharo-launcher/issues/349> > but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher). > > > Have fun > T. > > >

March 5, 2020

Re: [Pharo-dev] Mystery solved: Pharo and Unsupported 16 bit application on Windows

by tesonep＠gmail.com

Thanks for the analysis. It was a really complicated issue. Maybe we need to add validation of the unzip files or a correct detection of the unzip to use. Thanks again. On Wed, Mar 4, 2020, 19:52 Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > just wanted to share this story of a Windows problem + possible cause so > others could be aware: > > > As Pablo announced a new VM version this week I used the VMManager within > PharoLauncher to update the VM executables. > Unfortunately afterwards several things got broken: > > When I started a fresh Pharo 9 image from Launcher the underlying Windows > OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..." > leaving me with a big question mark. > > > So I thought there is trouble within the new VM executable. But things got > even more crazy when I deleted and redownloaded even fresh Pharo 8 and > Pharo 7 > VMs and images using the Launcher. Same issue here - but I was totally > sure that it worked before without any problem. > > I was not able to start ANY Pharo.exe version on this Windows machine > anymore (except Launcher itself) - which was really mysterious. Even after > reinstalling Pharo Launcher the problem did not go away. > > What I found strange was that on another second Windows machine it was > working perfect - same combination of Launcher and any other. > So I digged deeper in finding out. > > > Meanwhile I know the difference: > > - on the machine where it was not working I recently installed CYGWIN > toolset to be able to compile the Pharo VM > that means in the PATH environment I have an "unzip.exe" in > d:\cygwin64\bin\unzip.exe > > - I also activated the Unix subsystem for Windows (maybe that also gives > a unzip.exe) > > As PharoLauncher typically checks if an unzip.exe is available and (if > found) it is really using it to speed things up. > Just evaluate > > PhLVirtualMachineManager canUseSytemZip > > in an PharoLauncher image. If it is not found it is using the regular > "ZipArchive" class to extract - which is slower. > > So it looks like when the external "unzip.exe" from Cygwin (or possibly > also others) are found and used then the CI built ZIPs of > VM executables are not properly extracted and this leads to such effects > of having a non-proper executable on Windows. The OS loader > then thinks it is an old unsupported 16 bit application. > > Checking the version on command line for unzip exe tells me: > > UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. > > When I rename that executable I found another one telling me > > GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood. > > A simple workaround is to enable developer mode in PharoLauncher and > switching #canUseSytemZip to return false. > Slower - but the Pharo code is more reliable here. > > Just wanted to let you know in case this problem (of which I heard several > times already) is still on other peoples machine > still unsolved or reappearing. > > Side note: > ========= > It is a little bit similar to what was found in > https://github.com/pharo-project/pharo-launcher/issues/349 > but a side effect of having Cygwin and other providers of unzip.exe on > your machine in combination with Pharo(Launcher). > > > Have fun > T. > > > >

March 5, 2020

[Pharo 9.0] Build #130: CircularMemoryLogger is missing #basicRecordings:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #130 was: FAILURE. The Pull Request #5846 was integrated: "CircularMemoryLogger is missing #basicRecordings:" Pull request url: https://github.com/pharo-project/pharo/pull/5846 Issue Url: https://github.com/pharo-project/pharo/issues/5845 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 5, 2020

Re: [Pharo-dev] Mystery solved: Pharo and Unsupported 16 bit application on Windows

by ducasse

Thanks for your analysis. > On 4 Mar 2020, at 19:51, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > just wanted to share this story of a Windows problem + possible cause so others could be aware: > > > As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables. > Unfortunately afterwards several things got broken: > > When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..." > leaving me with a big question mark. > > > So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7 > VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem. > > I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after > reinstalling Pharo Launcher the problem did not go away. > > What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other. > So I digged deeper in finding out. > > > Meanwhile I know the difference: > > - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM > that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe > > - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe) > > As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up. > Just evaluate > > PhLVirtualMachineManager canUseSytemZip > > in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower. > > So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of > VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader > then thinks it is an old unsupported 16 bit application. > > Checking the version on command line for unzip exe tells me: > > UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. > > When I rename that executable I found another one telling me > > GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood. > > A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false. > Slower - but the Pharo code is more reliable here. > > Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine > still unsolved or reappearing. > > Side note: > ========= > It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349 > but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher). > > > Have fun > T. > > >

March 4, 2020

Re: [Pharo-dev] Mystery solved: Pharo and Unsupported 16 bit application on Windows

by phil＠highoctane.be

Ah may be what happened to me.... Phil On Wed, 4 Mar 2020, 19:52 Torsten Bergmann, <astares(a)gmx.de> wrote: > Hi, > > just wanted to share this story of a Windows problem + possible cause so > others could be aware: > > > As Pablo announced a new VM version this week I used the VMManager within > PharoLauncher to update the VM executables. > Unfortunately afterwards several things got broken: > > When I started a fresh Pharo 9 image from Launcher the underlying Windows > OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..." > leaving me with a big question mark. > > > So I thought there is trouble within the new VM executable. But things got > even more crazy when I deleted and redownloaded even fresh Pharo 8 and > Pharo 7 > VMs and images using the Launcher. Same issue here - but I was totally > sure that it worked before without any problem. > > I was not able to start ANY Pharo.exe version on this Windows machine > anymore (except Launcher itself) - which was really mysterious. Even after > reinstalling Pharo Launcher the problem did not go away. > > What I found strange was that on another second Windows machine it was > working perfect - same combination of Launcher and any other. > So I digged deeper in finding out. > > > Meanwhile I know the difference: > > - on the machine where it was not working I recently installed CYGWIN > toolset to be able to compile the Pharo VM > that means in the PATH environment I have an "unzip.exe" in > d:\cygwin64\bin\unzip.exe > > - I also activated the Unix subsystem for Windows (maybe that also gives > a unzip.exe) > > As PharoLauncher typically checks if an unzip.exe is available and (if > found) it is really using it to speed things up. > Just evaluate > > PhLVirtualMachineManager canUseSytemZip > > in an PharoLauncher image. If it is not found it is using the regular > "ZipArchive" class to extract - which is slower. > > So it looks like when the external "unzip.exe" from Cygwin (or possibly > also others) are found and used then the CI built ZIPs of > VM executables are not properly extracted and this leads to such effects > of having a non-proper executable on Windows. The OS loader > then thinks it is an old unsupported 16 bit application. > > Checking the version on command line for unzip exe tells me: > > UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. > > When I rename that executable I found another one telling me > > GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood. > > A simple workaround is to enable developer mode in PharoLauncher and > switching #canUseSytemZip to return false. > Slower - but the Pharo code is more reliable here. > > Just wanted to let you know in case this problem (of which I heard several > times already) is still on other peoples machine > still unsolved or reappearing. > > Side note: > ========= > It is a little bit similar to what was found in > https://github.com/pharo-project/pharo-launcher/issues/349 > but a side effect of having Cygwin and other providers of unzip.exe on > your machine in combination with Pharo(Launcher). > > > Have fun > T. > > > >

March 4, 2020

Mystery solved: Pharo and Unsupported 16 bit application on Windows

by Torsten Bergmann

Hi, just wanted to share this story of a Windows problem + possible cause so others could be aware: As Pablo announced a new VM version this week I used the VMManager within PharoLauncher to update the VM executables. Unfortunately afterwards several things got broken: When I started a fresh Pharo 9 image from Launcher the underlying Windows OS lamented about Pharo.exe being an "Unsupported 16 Bit application ..." leaving me with a big question mark. So I thought there is trouble within the new VM executable. But things got even more crazy when I deleted and redownloaded even fresh Pharo 8 and Pharo 7 VMs and images using the Launcher. Same issue here - but I was totally sure that it worked before without any problem. I was not able to start ANY Pharo.exe version on this Windows machine anymore (except Launcher itself) - which was really mysterious. Even after reinstalling Pharo Launcher the problem did not go away. What I found strange was that on another second Windows machine it was working perfect - same combination of Launcher and any other. So I digged deeper in finding out. Meanwhile I know the difference: - on the machine where it was not working I recently installed CYGWIN toolset to be able to compile the Pharo VM that means in the PATH environment I have an "unzip.exe" in d:\cygwin64\bin\unzip.exe - I also activated the Unix subsystem for Windows (maybe that also gives a unzip.exe) As PharoLauncher typically checks if an unzip.exe is available and (if found) it is really using it to speed things up. Just evaluate PhLVirtualMachineManager canUseSytemZip in an PharoLauncher image. If it is not found it is using the regular "ZipArchive" class to extract - which is slower. So it looks like when the external "unzip.exe" from Cygwin (or possibly also others) are found and used then the CI built ZIPs of VM executables are not properly extracted and this leads to such effects of having a non-proper executable on Windows. The OS loader then thinks it is an old unsupported 16 bit application. Checking the version on command line for unzip exe tells me: UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. When I rename that executable I found another one telling me GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood. A simple workaround is to enable developer mode in PharoLauncher and switching #canUseSytemZip to return false. Slower - but the Pharo code is more reliable here. Just wanted to let you know in case this problem (of which I heard several times already) is still on other peoples machine still unsolved or reappearing. Side note: ========= It is a little bit similar to what was found in https://github.com/pharo-project/pharo-launcher/issues/349 but a side effect of having Cygwin and other providers of unzip.exe on your machine in combination with Pharo(Launcher). Have fun T.

March 4, 2020

[Pharo 9.0] Build #129: ReadStream optimization for #upToAll:

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #129 was: FAILURE. The Pull Request #5831 was integrated: "ReadStream optimization for #upToAll:" Pull request url: https://github.com/pharo-project/pharo/pull/5831 Issue Url: https://github.com/pharo-project/pharo/issues/optimizedUpToAll Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 4, 2020