September 2019 - Pharo-dev - lists.pharo.org

[Pharo 8.0] Build #701: Validating that the FFI callout forwards objects

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

There is a new Pharo build available! The status of the build #701 was: SUCCESS. The Pull Request #4503 was integrated: "Validating that the FFI callout forwards objects" Pull request url: https://github.com/pharo-project/pharo/pull/4503 Issue Url: https://github.com/pharo-project/pharo/issues/adding Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 6, 2019

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

by James Foster

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

Sept. 6, 2019

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

by James Foster

> On Sep 5, 2019, at 9:38 AM, ducasse <stepharo(a)netcourrier.com> wrote: > > Thanks for the explanation. > We should pick solution one: > >> Enforce a uppercase and lowercase distinction (digit and exponent respectively); > > Why would we need to have HEX in lowercase for exponent? > Is there any adavantage. > I found 2r1.111eef quite unreadable 2r1.111eEF I should have said 1. Enforce an uppercase and lower case distinction (digit and exponent [lead-in token] respectively) So for option 1, âeâ is always a token indicating that an exponent follows, while âEâ is always the value fourteen (a âdigitâ). This would mean that â16rffâ would be illegal (since lowercase is not allowed for a hex digit). I believe exponents are always base ten, even if the primary part of the number is a different base. So, in â2r1e10â the exponent is four, so there are ten zeros (â10â is decimal) after the 1, not two zeros (binary). There would never be a hex exponent (âeEFâ would be illegal, not 239 zeros!). James > >> On 5 Sep 2019, at 15:05, James Foster <Smalltalk(a)JGFoster.net <mailto:Smalltalk@JGFoster.net>> wrote: >> >> Hi Stef, >> >> The question is âHow should it work?â How do we distinguish whether the character âeâ (or âEâ) is a representation for the (decimal) number 14 or is a representation for âwhat follows is an exponentâ? For example, it is easy to recognize that the radix-based integer literal â16rFFâ is the SmallInteger 255 and that the float literal â1.23e3â is 1230.0 (a SmallDouble in GemStone). >> >> For some reason, Pharo allowed â16reeâ to be the number 238 (permitting lowercase for hexidecimal digits) and has also allowed â2r1.111e3â to be the same as â2r1111â or 15 (permitting floating-point numbers to have a radix). This introduces an ambiguity in interpreting the character âeâ (or âEâ)âis it a hexadecimal digit or is it an exponent identifier? >> >> I believe that there are the following alternatives: >> Enforce a uppercase and lowercase distinction (digit and exponent respectively); >> Allow exponents on decimal (base ten) numbers only; >> Interpret âeâ as a hexadecimal digit if the radix is >= 15 (allowing exponents on lower bases); or >> Develop a new syntax to introduce exponents. >> I believe that #3 is the current approach, and could be seen as #2 relaxed to allow exponents on numbers with a radix of 2-14. >> >> It seems to me that the primary value of exponents on non-decimal (base ten) numbers is to represent binary numbers (2r1e63 is more readable than 2r1000000000000000000000000000000000000000000000000000000000000000). It seems to me that the value of exponents on numbers with a base above 10 is less pronounced (16r1E15 is better than 16r1000000000000000, but only a bit better). Mostly, Iâd assert that the value of exponents for radix 16 is not worth a new syntax (excluding #4 above). >> >> James >> >>> On Sep 4, 2019, at 10:36 PM, ducasse <stepharo(a)netcourrier.com <mailto:stepharo@netcourrier.com>> wrote: >>> >>> Hi nicolas >>> >>> let us fix this :) >>> >>> why 15r1.2e1 is not working? >>> why 15r1.2e1 is not equals to 15r1.2E1? >>> why would we need a new syntax? >>> >>> Stef >>>> On 5 Sep 2019, at 00:19, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com <mailto:nicolas.cellier.aka.nice@gmail.com>> wrote: >>>> >>>> Once upon a time, only uppercase letters were accpeted as extra digits (in base > 10) for both int and float >>>> >>>> Then 15r1.2E1 was not 15r1.2e1, the later being = 15r12.E >>>> >>>> Then it was considered better to understand hexadecimal numbers with lowercase too... >>>> and alternate-base Float became ambiguous and were never fixed :( >>>> >>>> This would deserve a new syntax, I don't know what makes sense, 15r1.2_e1 15r1.2#e1 ... >>>> Changing Smalltalk syntax is among the most difficult decisions, expect outcry ;) >>>> Maybe because it's too easy :) >>>> >>>> >>>> Le jeu. 5 sept. 2019 Ã 00:04, James Foster <Smalltalk(a)jgfoster.net <mailto:Smalltalk@jgfoster.net>> a Ã©crit : >>>> 14r1.2e1 "16.0" >>>> 15r1.2e1 â1.195851851851852" >>>> >>>> Does it make sense to have exponents for numbers that are not base 10? There are tests that have large exponents for binary numbers and we are not sure how to handle this in GemStone. >>>> >>>> James >>>> >>> >> >

Sept. 5, 2019

possible Windows Update "1903" Iceberg problem

by George Ganea

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

Sept. 5, 2019

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

by ducasse

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

Sept. 5, 2019

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

by Tudor Girba

Thank you both! We will test and come back with feedback. Cheers, Doru > On Sep 5, 2019, at 2:47 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi all, > > First, please, we would love if you can test what Pablo proposed and give us some feedback. > It will be super helpful to evaluate if it is worth to generate a new vm release!!! > > Also, besides what Pablo said in the previous email, I wanted to share some more precisions. > > === Precisions on the problem === > > First, just to clarify, we isolated the issue happening only on Windows10 #1903 on Pharo64 bits. > Pharo32 bits does work well on that update number does work well. > > The origin of the problem seems to be a bad integration between libssh2 1.7.0 and the windows CNG crypto layer, which seemingly changed in this update. > > === The path to the solution === > > The solution was theoretically super straight forward (upgrade to openssh 1.9.0 + openssl for crypto instead of windows CNG). > > It was however super time consuming. > - installing the windows update #1903 to test, reproduce and understand the issue took for us a couple of hours, reconfiguring the virtual machines to enlarge disks to download it, then install it... > - compiling openssl took literally the entire afternoon yesterday in Pabloâs machine. > - then we found several bugs in cmake openssl integration when compiling libssh2 on Cigwin + mingw, because life cannot be easy ^^ > > And fortunately, we found no incompatibilities between the different versions of these libraries (and libgit2 too!) so it could have been more time consuming :P. > > === Alternative solutions and workarounds === > > Alternatively for testing the libraries that Pablo sent in the previous email, there are some other workarounds that people could try in the meantime: > > 1) Use Pharo32 bits, which as I said above, does not have the problem. > > 2) Use Iceberg in HTTPS (and specifically set the Iceberg-Metacello integration to HTTP by default). > > <PastedGraphic-3.png> > > We are also evaluating setting HTTPS by default in Iceberg as it is simpler to setup. > Github, Gitkraken do use HTTPS as a sensible default too. > > Cheers > > >> El 5 sept 2019, a las 14:28, tesonep(a)gmail.com escribiÃ³: >> >> Hi all, >> with Guille we have been working in this issue since Monday, it >> was a complicated issue to solve as we require to compile and test >> different versions of the libgit2 library and its dependencies >> (openssl and libssh2). >> We have a workaround for using ssh in windows. >> We have produced a new set of libraries with the correct versions. >> These libraries are available in >> https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1 >> The idea is to start testing them while we are working on a new >> release of the VM. >> >> Cheers, >> Pablo >> >> On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito >> <guillermopolito(a)gmail.com> wrote: >>> >>> Hi all, >>> >>> Sorry for not communicating better :). >>> We know this is an important issue and we did move it to top priority even prior to this email ;). >>> Doru, to answer you, what people can do for the moment is to test what we are going to propose in a couple of hours in your windows machines. >>> With Pablo we have tested in several Windows 10 machines pre- and post- update 1903. Still we would like people testing on their setups and other windows versions >>> >>> We have been working the last couple of days debugging openssh and libgit, and building a version with a more up-to-date version of openssh. >>> We will come back later this morning / early afternoon with >>> - a new vm setup using up to date versions of openssh >>> - a description of workarounds for those tied to old versions of the VM >>> So people can test. >>> >>> Cheers, >>> Guille and Pablo >>> >>>> El 4 sept 2019, a las 8:38, ducasse <stepharo(a)netcourrier.com> escribiÃ³: >>>> >>>> I saw everybody super busy and I imagine that they will reply soon. >>>> Iâm travelling to give Pharo lectures. >>>> >>>>> On 3 Sep 2019, at 19:23, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Is there a way to speed the work on this one? >>>>> >>>>> At this moment, people cannot load any code in Pharo on Windows 10. >>>>> >>>>> Cheers, >>>>> Doru >>>>> >>>>> -- >>>>> www.feenk.com >>>>> "Every thing has its own flow." >>>>> >>>>>> On 28 Aug 2019, at 16:20, ducasse <stepharo(a)netcourrier.com> wrote: >>>>>> >>>>>> tx doru >>>>>> >>>>>> Stef >>>>>> >>>>>>> On 28 Aug 2019, at 16:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> I opened an issue: https://github.com/pharo-project/pharo/issues/4437 >>>>>>> >>>>>>> I believe this should be treated as critical given that we cannot load code in Pharo 7 (or 8) which makes it almost useless for users. >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>>> On Aug 27, 2019, at 10:54 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We just encountered this on two different machines. We got this after the update to Windows 1903. For us itâs a critical issue at this point. What can we do to help with this? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Doru >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 17, 2019, at 12:50 PM, Ben Coman <btc(a)openInWorld.com> wrote: >>>>>>>>> >>>>>>>>> hi Stef, >>>>>>>>> I feel you missed my point. Probably I wasn't clear this has already been tested with latest Pharo 8 launched by PharoLauncher. >>>>>>>>> The problem occurs with Pharo 7.0.3(64 bit) and with Pharo8.0-SNAPSHOT-build.635(64 bit) >>>>>>>>> after Microsoft Windows Update 1903... >>>>>>>>> https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-… >>>>>>>>> >>>>>>>>> If indeed 1903 is the cause, with this update now being *forced* down on people, this will potentially soon impact more and more Windows users. >>>>>>>>> But my guess that 1903 is the culprit needs to be confirmed. >>>>>>>>> So I am requesting someone with access to multiple Windows machines directly compare a 1903 machine with a pre-1903 machine. >>>>>>>>> >>>>>>>>> cheers -ben >>>>>>>>> >>>>>>>>> On Sat, 17 Aug 2019 at 12:58, ducasse <stepharo(a)netcourrier.com> wrote: >>>>>>>>> Hi ben >>>>>>>>> >>>>>>>>> in the pharo launcher if you click on P8.0 (development version) you get access to all the builds. >>>>>>>>> >>>>>>>>> Stef >>>>>>>>> >>>>>>>>>> On 16 Aug 2019, at 16:02, Ben Coman <btc(a)openinworld.com> wrote: >>>>>>>>>> >>>>>>>>>> IThis morning the May 2019 Windows Update "1903" forced itself onto my computer and now 64-bits Pharo seems to have a problem with git_remote_fetch() FFI callout. I no longer have a non-1903 machine to directly compare behaviour before "1903". Can someone familiar with this area with both "pre-1903" and "1903" machines triage whether "1903" is indeed the cause? >>>>>>>>>> >>>>>>>>>> A few other recent reports are noted here... >>>>>>>>>> https://github.com/pharo-project/pharo/issues/3418 >>>>>>>>>> >>>>>>>>>> cheers -ben >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> feenk.com >>>>>>>> >>>>>>>> "Not knowing how to do something is not an argument for how it cannot be done." >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> feenk.com >>>>>>> >>>>>>> âLive like you mean it." >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >> -- >> Pablo Tesone. >> tesonep(a)gmail.com >> > -- feenk.com "Being happy is a matter of choice."

Sept. 5, 2019

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

by Nicolas Cellier

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

Sept. 5, 2019

[Pharo 8.0] Build #700: Fixes issue 3068

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

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

Sept. 5, 2019

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

by Christopher Fuhrman

This sounds great, Pablo. Just to clarify on how to test, if I'm using Pharo Launcher, do I just replace the .dll files from your .zip in C:\Users\{me}\Documents\Pharo\vms\80-x64 (and/or \70-x64)? On Thu, 5 Sep 2019 at 09:34, tesonep(a)gmail.com <tesonep(a)gmail.com> wrote: > Hi all, > with Guille we have been working in this issue since Monday, it > was a complicated issue to solve as we require to compile and test > different versions of the libgit2 library and its dependencies > (openssl and libssh2). > We have a workaround for using ssh in windows. > We have produced a new set of libraries with the correct versions. > These libraries are available in > https://drive.google.com/open?id=1fwAVyrEEXkGOAuyAh1wASRRSv3SjZ3R1 > The idea is to start testing them while we are working on a new > release of the VM. > > Cheers, > Pablo > > On Wed, Sep 4, 2019 at 10:05 AM Guillermo Polito > <guillermopolito(a)gmail.com> wrote: > > > > Hi all, > > > > Sorry for not communicating better :). > > We know this is an important issue and we did move it to top priority > even prior to this email ;). > > Doru, to answer you, what people can do for the moment is to test what > we are going to propose in a couple of hours in your windows machines. > > With Pablo we have tested in several Windows 10 machines pre- and post- > update 1903. Still we would like people testing on their setups and other > windows versions > > > > We have been working the last couple of days debugging openssh and > libgit, and building a version with a more up-to-date version of openssh. > > We will come back later this morning / early afternoon with > > - a new vm setup using up to date versions of openssh > > - a description of workarounds for those tied to old versions of the VM > > So people can test. > > > > Cheers, > > Guille and Pablo > > > > > El 4 sept 2019, a las 8:38, ducasse <stepharo(a)netcourrier.com> > escribiÃ³: > > > > > > I saw everybody super busy and I imagine that they will reply soon. > > > Iâm travelling to give Pharo lectures. > > > > > >> On 3 Sep 2019, at 19:23, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > >> > > >> Hi, > > >> > > >> Is there a way to speed the work on this one? > > >> > > >> At this moment, people cannot load any code in Pharo on Windows 10. > > >> > > >> Cheers, > > >> Doru > > >> > > >> -- > > >> www.feenk.com > > >> "Every thing has its own flow." > > >> > > >>> On 28 Aug 2019, at 16:20, ducasse <stepharo(a)netcourrier.com> wrote: > > >>> > > >>> tx doru > > >>> > > >>> Stef > > >>> > > >>>> On 28 Aug 2019, at 16:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > >>>> > > >>>> Hi > > >>>> > > >>>> I opened an issue: > https://github.com/pharo-project/pharo/issues/4437 > > >>>> > > >>>> I believe this should be treated as critical given that we cannot > load code in Pharo 7 (or 8) which makes it almost useless for users. > > >>>> > > >>>> Cheers, > > >>>> Doru > > >>>> > > >>>> > > >>>>> On Aug 27, 2019, at 10:54 AM, Tudor Girba <tudor(a)tudorgirba.com> > wrote: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> We just encountered this on two different machines. We got this > after the update to Windows 1903. For us itâs a critical issue at this > point. What can we do to help with this? > > >>>>> > > >>>>> Cheers, > > >>>>> Doru > > >>>>> > > >>>>> > > >>>>> > > >>>>>> On Aug 17, 2019, at 12:50 PM, Ben Coman <btc(a)openInWorld.com> > wrote: > > >>>>>> > > >>>>>> hi Stef, > > >>>>>> I feel you missed my point. Probably I wasn't clear this has > already been tested with latest Pharo 8 launched by PharoLauncher. > > >>>>>> The problem occurs with Pharo 7.0.3(64 bit) and with > Pharo8.0-SNAPSHOT-build.635(64 bit) > > >>>>>> after Microsoft Windows Update 1903... > > >>>>>> > https://www.computerworld.com/article/3409621/microsoft-starts-windows-10s-… > > >>>>>> > > >>>>>> If indeed 1903 is the cause, with this update now being *forced* > down on people, this will potentially soon impact more and more Windows > users. > > >>>>>> But my guess that 1903 is the culprit needs to be confirmed. > > >>>>>> So I am requesting someone with access to multiple Windows > machines directly compare a 1903 machine with a pre-1903 machine. > > >>>>>> > > >>>>>> cheers -ben > > >>>>>> > > >>>>>> On Sat, 17 Aug 2019 at 12:58, ducasse <stepharo(a)netcourrier.com> > wrote: > > >>>>>> Hi ben > > >>>>>> > > >>>>>> in the pharo launcher if you click on P8.0 (development version) > you get access to all the builds. > > >>>>>> > > >>>>>> Stef > > >>>>>> > > >>>>>>> On 16 Aug 2019, at 16:02, Ben Coman <btc(a)openinworld.com> wrote: > > >>>>>>> > > >>>>>>> IThis morning the May 2019 Windows Update "1903" forced itself > onto my computer and now 64-bits Pharo seems to have a problem with > git_remote_fetch() FFI callout. I no longer have a non-1903 machine to > directly compare behaviour before "1903". Can someone familiar with this > area with both "pre-1903" and "1903" machines triage whether "1903" is > indeed the cause? > > >>>>>>> > > >>>>>>> A few other recent reports are noted here... > > >>>>>>> https://github.com/pharo-project/pharo/issues/3418 > > >>>>>>> > > >>>>>>> cheers -ben > > >>>>>> > > >>>>> > > >>>>> -- > > >>>>> feenk.com > > >>>>> > > >>>>> "Not knowing how to do something is not an argument for how it > cannot be done." > > >>>>> > > >>>> > > >>>> -- > > >>>> feenk.com > > >>>> > > >>>> âLive like you mean it." > > >>>> > > >>>> > > >>> > > >>> > > >>> > > >> > > > > > > > > > > > > > > > > -- > Pablo Tesone. > tesonep(a)gmail.com > > -- Christopher Fuhrman, P.Eng., PhD *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de l'informationÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Sept. 5, 2019

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

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

There is a new Pharo build available! The status of the build #699 was: FAILURE. The Pull Request #4473 was integrated: "4401-bis-ZipArchive-should-not-convert-FileReference-to-paths" Pull request url: https://github.com/pharo-project/pharo/pull/4473 Issue Url: https://github.com/pharo-project/pharo/issues/4401 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 5, 2019