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

Re: [Pharo-dev] Apparently Zodiac plugin can crash VM on Linux

by Sven Van Caekenberghe

> On 16 Jan 2019, at 16:28, Max Leske <maxleske(a)gmail.com> wrote: > > On 15 Jan 2019, at 22:59, Sven Van Caekenberghe wrote: > > Doing HTTPS client calls is part of the standard test suite, so it should work, else we would not have a green build. It works for me and for the CI. > What exactly is he doing ? Is it reproducible ? > > Yes, consistently. How ? > Can he try with a fresh downloaded image+vm ? > > I quote: > > @embee > i have tested https://files.pharo.org/get-files/70/pharo64-linux-stable.zip and https://files.pharo.org/get-files/70/pharo64-linux-latest.zip > i hope those are the right ones. both crash > > @maxleske > Thanks. I'll report that. > Was that also with a fresh image? > i.e. you can also reprocude it with a fresh image, right? > > @embee > yes > > On 15 Jan 2019, at 22:20, Max Leske maxleske(a)gmail.com wrote: > > Hi, > > I'm writing on behalf of Martin (eMBee) who's experiencing crashes when using SSL. You can find a VM crash stack trace here: http://ws.stfx.eu/AKVNLUPMPGLG. > > He says he hasn't updated openssl since December 15th but that the crashes started to happen only recently (within the last couple of days). I asked him to try HTTP only connections and those work. The VM crashes immediately when using SSL. To me it looks like the cuplrit is the Zodiac plugin, or at least the library it works with. > > His system: > linux, fedora 29, and from the system reporter i get: Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo > CoInterpreter VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 > VM: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > cheers, > Max >

Jan. 16, 2019

Re: [Pharo-dev] Apparently Zodiac plugin can crash VM on Linux

by Max Leske

On 15 Jan 2019, at 22:59, Sven Van Caekenberghe wrote: > Doing HTTPS client calls is part of the standard test suite, so it > should work, else we would not have a green build. > > What exactly is he doing ? Is it reproducible ? Yes, consistently. > > Can he try with a fresh downloaded image+vm ? I quote: @embee i have tested https://files.pharo.org/get-files/70/pharo64-linux-stable.zip and https://files.pharo.org/get-files/70/pharo64-linux-latest.zip i hope those are the right ones. both crash @maxleske Thanks. I'll report that. Was that also with a fresh image? i.e. you can also reprocude it with a fresh image, right? @embee yes > >> On 15 Jan 2019, at 22:20, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi, >> >> I'm writing on behalf of Martin (eMBee) who's experiencing crashes >> when using SSL. You can find a VM crash stack trace here: >> http://ws.stfx.eu/AKVNLUPMPGLG. >> >> He says he hasn't updated openssl since December 15th but that the >> crashes started to happen only recently (within the last couple of >> days). I asked him to try HTTP only connections and those work. The >> VM crashes immediately when using SSL. To me it looks like the >> cuplrit is the Zodiac plugin, or at least the library it works with. >> >> His system: >> linux, fedora 29, and from the system reporter i get: >> Pharo/vms/70-x64/lib/pharo/5.0-201806281256/pharo >> CoInterpreter VMMaker.oscog-eem.2401 uuid: >> 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2401 uuid: >> 29232e0e-c9e3-41d8-ae75-519db862e02c Jun 28 2018 >> VM: 201806281256 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Thu Jun >> 28 14:56:30 2018 CommitHash: a8a1dc1 Plugins: 201806281256 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git >> >> cheers, >> Max

Jan. 16, 2019

Re: [Pharo-dev] Looking for contributor names

by ducasse

> On 16 Jan 2019, at 15:30, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Is that time of the year (well, this time was more than one year) when I ask for the names of people who contributed to Pharo but didnât put their names. > I thought this was going to be fixed with the move to GitHub, but seems that also there, there are people that does not use names :) > > So, Iâm missing this names: > > - vonbecmann Von Becmann > - Karnaj Yoann Geran > - dupriezt Thomas Dupriez > - pierretsap Pierre Tsapliayeu > - akevalion Asbathou Biyalou-Sama <asbathou.biyalou-sama(a)inria.fr> > - Marmat21 > > If you are one of those, or you know the name of one of those, please tell me. > > Esteban > > Ps: Yes, that means we are very-very close of the release :)

Jan. 16, 2019

Re: [Pharo-dev] Looking for contributor names

by Esteban Lorenzano

Got them, thanks ! > On 16 Jan 2019, at 15:30, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Is that time of the year (well, this time was more than one year) when I ask for the names of people who contributed to Pharo but didnât put their names. > I thought this was going to be fixed with the move to GitHub, but seems that also there, there are people that does not use names :) > > So, Iâm missing this names: > > - vonbecmann > - Karnaj > - dupriezt > - pierretsap > - akevalion > - Marmat21 > > If you are one of those, or you know the name of one of those, please tell me. > > Esteban > > Ps: Yes, that means we are very-very close of the release :)

Jan. 16, 2019

Looking for contributor names

by Esteban Lorenzano

Hi, Is that time of the year (well, this time was more than one year) when I ask for the names of people who contributed to Pharo but didnât put their names. I thought this was going to be fixed with the move to GitHub, but seems that also there, there are people that does not use names :) So, Iâm missing this names: - vonbecmann - Karnaj - dupriezt - pierretsap - akevalion - Marmat21 If you are one of those, or you know the name of one of those, please tell me. Esteban Ps: Yes, that means we are very-very close of the release :)

Jan. 16, 2019

[Pharo 7.0] Build #124: 22737-The-changelog-for-Pharo-7-needs-update

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

There is a new Pharo build available! The status of the build #124 was: FAILURE. The Pull Request #2251 was integrated: "22737-The-changelog-for-Pharo-7-needs-update" Pull request url: https://github.com/pharo-project/pharo/pull/2251 Issue Url: https://pharo.fogbugz.com/f/cases/22737 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 16, 2019

[Pharo 7.0] Build #123: 22890-IconListModelbackgroundColorBlock-does-not-work

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

There is a new Pharo build available! The status of the build #123 was: FAILURE. The Pull Request #2217 was integrated: "22890-IconListModelbackgroundColorBlock-does-not-work" Pull request url: https://github.com/pharo-project/pharo/pull/2217 Issue Url: https://pharo.fogbugz.com/f/cases/22890 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Sven Van Caekenberghe

Still, one of the conclusions of previous discussions about the encoding of environment variables was/is that there is no single correct solution. OS's are not consistent in how the encoding is done in all (historical) contexts (like sometimes, 1 env var defines the encoding to use for others, different applications do different things, and other such nice stuff), and certainly not across platforms. So this is really complex. Do we want to hide this in some obscure VM C code that very few people can see, read, let alone help with ? The image side is perfectly capable of dealing with platform differences in a clean/clear way, and at least we can then use the full power of our language and our tools. > On 16 Jan 2019, at 10:59, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Nicolas, > > On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because the purpose of a VM is to provide an OS independant faÃ§ade. > I made progress recently in this area, but we should finish the job/test/consolidate. > > I'm following your changes for windows from the shadows and I think they are awesome :). > > If someone bypass the VM and use direct windows API thru FFI, then he takes the responsibility, but uniformity doesn't hurt. > > So far we are using FFI for this, as you say we create first Win32WideStrings from utf8 strings and then we use ffi calls to the *W functions. > I don't think we can make it for Pharo7.0.0. The cycle to build, do some acceptance tests, and then bless a new VM as stable is far too long for our inminent release :). > > But this could be for a 7.1.0, and if you like I can surely give a hand on this. > > Guille

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Guillermo Polito

Hi Nicolas, On Wed, Jan 16, 2019 at 10:25 AM Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion > because the purpose of a VM is to provide an OS independant faÃ§ade. > I made progress recently in this area, but we should finish the > job/test/consolidate. > I'm following your changes for windows from the shadows and I think they are awesome :). > If someone bypass the VM and use direct windows API thru FFI, then he > takes the responsibility, but uniformity doesn't hurt. > So far we are using FFI for this, as you say we create first Win32WideStrings from utf8 strings and then we use ffi calls to the *W functions. I don't think we can make it for Pharo7.0.0. The cycle to build, do some acceptance tests, and then bless a new VM as stable is far too long for our inminent release :). But this could be for a 7.1.0, and if you like I can surely give a hand on this. Guille

Jan. 16, 2019

Re: [Pharo-dev] Better management of encoding of environment variables

by Stephan Eggermont

Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > IMO, windows VM (and plugins) should do the UCS2 -> UTF8 conversion because > the purpose of a VM is to provide an OS independant faÃ§ade. > I made progress recently in this area, but we should finish the > job/test/consolidate. > If someone bypass the VM and use direct windows API thru FFI, then he takes > the responsibility, but uniformity doesn't hurt. That sounds like a very good idea. Do you suggest to do that after the Pharo 7 release? Or is it simple enough that it can be done in time? On the unix side, do I need the explicit encoding or can I ask the OSEnvironment for the one I need? Before the Pharo 7 release we need at least a #getEnv: back and a class comment corresponding to what is expected. If we want to change to the new API it needs to be deprecated. Stephan

Jan. 16, 2019