- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Esteban Lorenzano

> On 24 Mar 2017, at 13:27, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > Hi! > >> Image >> ===== >> >> - Cairo surface crash. > > I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes. > > Maybe this long lasting issue is solveâ¦ Iâm aware of this, that was my âsolution to testâ :) but if you can confirm it works, I will commit the image changes Eliot gave me :) Esteban > > Alexandre

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Alexandre Bergel

Hi! > Image > ===== > > - Cairo surface crash. I may have a good news on this issue. Recently Eliot produced a new VM that prevents garbage collection while doing a bitblt. I have used this VM for a couple of days and have not experienced any crashes. Maybe this long lasting issue is solveâ¦ Alexandre

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Max Leske

> On 24 Mar 2017, at 12:04, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> >> On 24 Mar 2017, at 11:54, Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> wrote: >> >>> >>> On 24 Mar 2017, at 11:29, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> Hi, >>> >>> I wanted to share with you the list of blocking issues I see to do the release :) >>> >>> Image >>> ===== >>> >>> - Cairo surface crash. >>> Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will >>> workaround the problem by adding a (hopefully temporal) CairoPlugin. >>> - Iceberg needs to enter the system as preview before release. >>> This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux >>> (see below). >>> - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our >>> increasing sizes. Now it works and images continue growing without control, so we need to find it. >>> >>> Image 64bits >>> ============ >>> - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, >>> that's not true on 64bits (at least in windows). >>> >>> VM >>> == >>> - New VM compactor has problems when image hits a big size. >>> Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. >>> - here are still some glitches and tests do not pass completely. >>> Methods failing in travis are: >>> >>> DelayMicrosecondSchedulerTest>>#testForMilliseconds >>> MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne >>> >>> This, in linux VM. I think is important but I think we will have a solution next days >>> - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot >>> rely on linux installed versions), and there is a problem to solve the paths. >> >> Really?? I thought I had solved that. > > nope :( > at the end, the only solution is to ensure those libs are first in âresolutionâ list, and thatâs with an LD_LIBRARY_PATH :( > anyway, this is fixed, Iâm just testing it/adapting zeroconf, etc. :) > Wow, that sucks! Thanks! > Esteban > >> >>> Ultimate solution is to use a script >>> as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. >>> Iâm testing this. >>> >>> >>> VM 64bits >>> ========= >>> - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes >>> impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) >>> - No VM for windows. Again, this is a know issueâ¦ but maybe I can add a StackVM for windowsâ¦ I need to >>> see how is working.

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Esteban Lorenzano

> On 24 Mar 2017, at 11:54, Max Leske <maxleske(a)gmail.com> wrote: > >> >> On 24 Mar 2017, at 11:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hi, >> >> I wanted to share with you the list of blocking issues I see to do the release :) >> >> Image >> ===== >> >> - Cairo surface crash. >> Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will >> workaround the problem by adding a (hopefully temporal) CairoPlugin. >> - Iceberg needs to enter the system as preview before release. >> This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux >> (see below). >> - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our >> increasing sizes. Now it works and images continue growing without control, so we need to find it. >> >> Image 64bits >> ============ >> - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, >> that's not true on 64bits (at least in windows). >> >> VM >> == >> - New VM compactor has problems when image hits a big size. >> Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. >> - here are still some glitches and tests do not pass completely. >> Methods failing in travis are: >> >> DelayMicrosecondSchedulerTest>>#testForMilliseconds >> MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne >> >> This, in linux VM. I think is important but I think we will have a solution next days >> - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot >> rely on linux installed versions), and there is a problem to solve the paths. > > Really?? I thought I had solved that. nope :( at the end, the only solution is to ensure those libs are first in âresolutionâ list, and thatâs with an LD_LIBRARY_PATH :( anyway, this is fixed, Iâm just testing it/adapting zeroconf, etc. :) Esteban > >> Ultimate solution is to use a script >> as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. >> Iâm testing this. >> >> >> VM 64bits >> ========= >> - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes >> impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) >> - No VM for windows. Again, this is a know issueâ¦ but maybe I can add a StackVM for windowsâ¦ I need to >> see how is working.

March 24, 2017

Re: [Pharo-dev] Estebanâs list of blocking issues for release Pharo 6.0

by Max Leske

> On 24 Mar 2017, at 11:29, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > I wanted to share with you the list of blocking issues I see to do the release :) > > Image > ===== > > - Cairo surface crash. > Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will > workaround the problem by adding a (hopefully temporal) CairoPlugin. > - Iceberg needs to enter the system as preview before release. > This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux > (see below). > - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our > increasing sizes. Now it works and images continue growing without control, so we need to find it. > > Image 64bits > ============ > - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, > that's not true on 64bits (at least in windows). > > VM > == > - New VM compactor has problems when image hits a big size. > Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. > - here are still some glitches and tests do not pass completely. > Methods failing in travis are: > > DelayMicrosecondSchedulerTest>>#testForMilliseconds > MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne > > This, in linux VM. I think is important but I think we will have a solution next days > - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot > rely on linux installed versions), and there is a problem to solve the paths. Really?? I thought I had solved that. > Ultimate solution is to use a script > as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. > Iâm testing this. > > > VM 64bits > ========= > - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes > impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) > - No VM for windows. Again, this is a know issueâ¦ but maybe I can add a StackVM for windowsâ¦ I need to > see how is working. > >

March 24, 2017

Estebanâs list of blocking issues for release Pharo 6.0

by Esteban Lorenzano

Hi, I wanted to share with you the list of blocking issues I see to do the release :) Image ===== - Cairo surface crash. Of course, as it is now is unnaceptable... I have some solution to test but if that does not work, I will workaround the problem by adding a (hopefully temporal) CairoPlugin. - Iceberg needs to enter the system as preview before release. This is needed to use the new process, and it was almost ready but we get blocked for a problem in VM for linux (see below). - I'm quite sure there is still a leak. During too much time we had the compactor problem so we blame it for our increasing sizes. Now it works and images continue growing without control, so we need to find it. Image 64bits ============ - Athens is working in general, but there are still some places where it uses a `long` as a pointer and of course, that's not true on 64bits (at least in windows). VM == - New VM compactor has problems when image hits a big size. Eliot is working on it, but we cannot release with VM as it is now... I hope it will be fixed next days too. - here are still some glitches and tests do not pass completely. Methods failing in travis are: DelayMicrosecondSchedulerTest>>#testForMilliseconds MutexTest>>#testFailedCriticalSectionShouldUnblockWaitingOne This, in linux VM. I think is important but I think we will have a solution next days - Dependency libraries problem. Again, in linux... we distribute libgit2, libssh2 and libssl (because we cannot rely on linux installed versions), and there is a problem to solve the paths. Ultimate solution is to use a script as entry point (not the binary), and do a LD_LIBRARY_PATH to solve it. Iâm testing this. VM 64bits ========= - Is incredibly hard to compile a 64bits version of libgit2 0.23 (the one we are using) for macOS, which makes impossible to use Iceberg. Not sure this is blocking, but well... I needed to point it :) - No VM for windows. Again, this is a know issueâ¦ but maybe I can add a StackVM for windowsâ¦ I need to see how is working.

March 24, 2017

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/60451 Home: https://github.com/pharo-project/pharo-core

March 24, 2017

[pharo-project/pharo-core] 6f7772: 60451

by GitHub

Branch: refs/heads/6.0 Home: https://github.com/pharo-project/pharo-core Commit: 6f7772a796bf7238b33ebcaca3263b10a7cc591e https://github.com/pharo-project/pharo-core/commit/6f7772a796bf7238b33ebcac… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2017-03-24 (Fri, 24 Mar 2017) Changed paths: M Refactoring-Core.package/RBMoveMethodToClassRefactoring.class/instance/transforming/transform.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60450.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - scripts/script60451.st R ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60450.st A ScriptLoader60.package/ScriptLoader.class/instance/pharo - updates/update60451.st M ScriptLoader60.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 60451 19863 RBMoveMethodToClassRefactoring reset method protocol https://pharo.fogbugz.com/f/cases/19863 http://files.pharo.org/image/60/60451.zip

March 24, 2017

Re: [Pharo-dev] ZnEasy problem?

by Ben Coman

On Fri, Mar 24, 2017 at 4:11 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Fri, Mar 24, 2017 at 3:48 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse < stepharo.self(a)gmail.com> wrote: >>> >>> Hi guys >>> >>> in the mooc (first example) we have the following expression >>> >>> (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') >>> >>> and it does not work anymore. I'm pair programming with Amal in Rennes >>> from the university in italy and from her univ in Rennes >>> we both get on 60 and 50 >>> >>> and time out https >>> >>> sslException: text code: code >>> self error: >>> (String streamContents: [ :stream | >>> stream << 'SSL Exception: ' << text << ' [code:'. >>> stream print: code. >>> stream << ']' ]) >>> >>> Any idea. >>> >>> Tx in advance >> >> >> What platform are you on. >> >> On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT Compiler: 4.9.2 VMMaker versionString VM: 201703091627 >> I can confirm the same error with this... >> (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png'). >> >> but picking some random SSL PNG, this works fine... >> (ZnEasy getPng: ' https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png' ). >> >> It is strange that you are getting an SSL error using http rather than https. >> It seems the server is redirecting to http to https and maybe this is not handled? >> https://geekflare.com/http-to-https-redirection/ >> > > Nope. Thats not it. Same problem with... > ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' > > Now if I put this hack in ZdcSecureSocketStream>>connect.... > [ (result := self sslSession connect: in from: 1 to: count into: out). > Transcript crShow: result. > result = 0 ] whileFalse: [ .... > > ZnEasy getPng: ' https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png'. > ==> > 99 > 134 > 0 > > while... > ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' > ==> > 99 > -5 > > If I try the same in Pharo5.0-ReleaseWin32, build 50761, VM built on May 4 2016 12:17:02 Compiler: 4.6.2 > VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 > > ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' > ==> > 292 > -1 In Chrome, after opening each of the following and going... More Tools > Developer Tools > Security I see a difference... * https://pharo.org:443/web/files/pharo.png The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_ECDSA with P-256), and a strong cipher (AES_128_GCM). * https://blog.keycdn.com/blog/wp-content/uploads/2015/10/http1-vs-http2.png The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA with P-256), and a strong cipher (AES_256_GCM). I haven't parsed this properly, but maybe related https://github.com/openssl/openssl/issues/2658 This server itself seems okay... https://www.thesslstore.com/ssltools/ssl-checker.php?hostname=pharo.org#res… cheers -ben

March 24, 2017

Re: [Pharo-dev] ZnEasy problem?

by Ben Coman

On Fri, Mar 24, 2017 at 3:48 PM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Fri, Mar 24, 2017 at 3:02 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi guys >> >> in the mooc (first example) we have the following expression >> >> (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png') >> >> and it does not work anymore. I'm pair programming with Amal in Rennes >> from the university in italy and from her univ in Rennes >> we both get on 60 and 50 >> >> and time out https >> >> sslException: text code: code >> self error: >> (String streamContents: [ :stream | >> stream << 'SSL Exception: ' << text << ' [code:'. >> stream print: code. >> stream << ']' ]) >> >> Any idea. >> >> Tx in advance >> > > What platform are you on. > > On Windows 7, Pharo 60447, Win32 VM built on Mar 9 2017 16:38:45 CUT > Compiler: 4.9.2 VMMaker versionString VM: 201703091627 > I can confirm the same error with this... > (ZnEasy getPng: 'http://pharo.org/web/files/pharo.png'). > > but picking some random SSL PNG, this works fine... > (ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/ > http1-vs-http2.png'). > > It is strange that you are getting an SSL error using http rather than > https. > It seems the server is redirecting to http to https and maybe this is not > handled? > https://geekflare.com/http-to-https-redirection/ > > Nope. Thats not it. Same problem with... ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' Now if I put this hack in ZdcSecureSocketStream>>connect.... [ (result := self sslSession connect: in from: 1 to: count into: out). Transcript crShow: result. result = 0 ] whileFalse: [ .... ZnEasy getPng: 'https://blog.keycdn.com/blog/wp-content/uploads/2015/10/ http1-vs-http2.png'. ==> 99 134 0 while... ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' ==> 99 -5 If I try the same in Pharo5.0-ReleaseWin32, build 50761, VM built on May 4 2016 12:17:02 Compiler: 4.6.2 VMMaker versionString https://github.com/pharo-project/pharo-vm.git Commit: b8ec25a570d7539653e1d793e97609adb509aaed Date: 2016-05-04 11:14:22 +0200 By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #589 ZnEasy getPng: 'https://pharo.org:443/web/files/pharo.png' ==> 292 -1

March 24, 2017