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

Re: [Pharo-dev] Problem with zinc 2.9.2

by Norbert Hartl

> Am 11.07.2018 um 20:19 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 11 Jul 2018, at 19:50, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Thank you Sven. That fixed my first problem. Sadly the other problem is more persitent than this. > > I would guess that the other problem (the ZipArchive usage) might be related to the recent file/stream changes in Pharo 7 and not related to the loading of Zinc. The bug might be a binary/text stream mixup or the usage of deprecated code. > Thatâd be my guess, too. Unfortunately it occurs where debugging is difficult. Norbert >> Norbert >> >>> Am 11.07.2018 um 16:46 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> FWIW, I created a new #stable version 2.9.3 that includes a newer Zinc-FileSystem-SvenVanCaekenberghe.16 - maybe this helps. >>> >>> === >>> Name: Zinc-FileSystem-SvenVanCaekenberghe.16 >>> Author: SvenVanCaekenberghe >>> Time: 11 July 2018, 4:30:36.923152 pm >>> UUID: 830fbcd3-1b2d-0d00-bd45-164704867404 >>> Ancestors: Zinc-FileSystem-SvenVanCaekenberghe.15 >>> >>> Force an update (class comment changed) >>> === >>> >>>> On 10 Jul 2018, at 09:17, Max Leske <maxleske(a)gmail.com> wrote: >>>> >>>> On 10 Jul 2018, at 8:48, Norbert Hartl wrote: >>>> >>>>> Max, >>>>> >>>>> thanks for taking the effort. >>>> >>>> No worries. >>>> >>>>> >>>>>> Am 10.07.2018 um 08:37 schrieb Max Leske <maxleske(a)gmail.com>: >>>>>> >>>>>> I did my best to reproduce the issue but didn't have any luck. I really need access to a Linux VM to debug this. So I'm praying that Apple fixes the access restrictions to kernel extensions in their next beta... >>>>>> >>>>>> BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is indeed a chance that something goes wrong during download of the zip archive and that something may be tied to a difference in the versions of Zinc (although I still think that's unlikely). >>>>>> >>>>> Yes there is potential but I donât see it. I take a fresh 6.1 image and load my project into. Iâm not sure but I think zinc 2.9.2 is loaded rather early in that process. So I wonder why it does not go wrong in the first phase. And also not if I load the test group within the first phase. >>>>> It must be either the second Metacello invocation or the stopping, copying and starting of the image. >>>>> I try to isolate this case more and provide a script that goes wrong on my machine. But it will take some time because I needed to stop trying to solve this as I wasted nearly two days on that already. >>>> >>>> Let me know once you have something and I'll try to help out. >>>> >>>>> >>>>> Norbert >>>>> >>>>>> Max >>>>>> >>>>>> >>>>>> On 9 Jul 2018, at 19:43, Norbert Hartl wrote: >>>>>> >>>>>> >>>>>> >>>>>>> Am 09.07.2018 um 19:10 schrieb Max Leske <maxleske(a)gmail.com>: >>>>>>> >>>>>>> I checked the Parasol Archive and it does not appear to be in Zip64 format (Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive can read the Parasol zip). So my next guess is that there's either a problem with Metacello or Pharo in the way that ZipArchive is used (e.g. endianness problem or non-binary stream data). It would therefore be helpful to find out what happens in ZipArchive>>readFrom:, i.e. what kind of stream is passed / opened, is it binary, does the file exist and is it still the correct file. >>>>>>> >>>>>>> >>>>>> I couldnât see anything obvious. The file in the debug message exists, it is a readable zip file. The way Metacello uses it it is a StandardFileStream. It switches it to binary in the code. >>>>>> But the only difference between a working and non-working build is the upgrade to zinc 2.9.2. >>>>>> >>>>>> Norbert >>>>>> >>>>>>> I'd debug it myself but I can't run VirtualBox at the moment because I'm on the macOS beta and it won't start... >>>>>>> >>>>>>> Max >>>>>>> >>>>>>> On 9 Jul 2018, at 18:31, Norbert Hartl wrote: >>>>>>> >>>>>>> Hi Max, >>>>>>> >>>>>>> >>>>>>>> Am 09.07.2018 um 18:18 schrieb Max Leske <maxleske(a)gmail.com>: >>>>>>>> >>>>>>>> Hi Norbert, >>>>>>>> >>>>>>>> This is a bit of a guess, but it's possible that the archive that is downloaded from github is in Zip64 format and that the libraries for extracting Zip64 are missing on your Linux. That would of course contradict the experience that the same operation appears to work in 6.1. >>>>>>>> >>>>>>>> >>>>>>> to be honest I donât know what Zip64 format is. I thought the Zip classes are pure smalltalk for unpacking. >>>>>>>> Try extracting the archive manually on your Linux machine with the same method that Metacello uses (I assume, Metacello uses the ZipPlugin, which will probably use the system libraries). >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I have no ZipPlugin as library in any of my vms. >>>>>>> >>>>>>> But there are zips downloaded and unpacked. I start the image the first time loading all the code of my project. Then it is saved, copied to a new name and reopened to load the tests and then it fails. I did try to load the tests in the first run and then it works. >>>>>>> >>>>>>> Iâm running out of ideas >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Norbert >>>>>>>> Cheers, >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> On 9 Jul 2018, at 17:14, Norbert Hartl wrote: >>>>>>>> >>>>>>>> With the help of Esteban I got one step further. If I do >>>>>>>> >>>>>>>> MCWorkingCopy >>>>>>>> managersForClass: ZnFileSystemUtils >>>>>>>> do: [ :each | each ancestry initialize ] >>>>>>>> >>>>>>>> before loading my project it updates Zinc-FileSystem as well. Sadly it still does not work for me because I get >>>>>>>> >>>>>>>> Loading baseline of BaselineOfMobilityMap... >>>>>>>> ...RETRY->BaselineOfParasol >>>>>>>> ...RETRY->BaselineOfParasol[31mError: can't find EOCD position >>>>>>>> >>>>>>>> and I donât know why. zip file is downloaded from github and present but it fails and only on my jenkins on linux. On my Mac this works. >>>>>>>> >>>>>>>> I try a few things but then Iâm back on pharo6.1 for the time being :( >>>>>>>> >>>>>>>> Norbert >>>>>>>> >>>>>>>> >>>>>>>>> Am 07.07.2018 um 13:28 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>>>>>> >>>>>>>>> Really? I thought the same but then I didnât believe it works like that. >>>>>>>>> >>>>>>>>> Anyway this would be very easy to solve. We just need to ask Sven if he is fine with doing an empty .16 version for Zinc-FileSystem and does an in-place version reset of 2.9.2 or a new 2.9.3. Iâm not fully convinced that will solve it but the cost wonât be very high. >>>>>>>>> >>>>>>>>> Norbert >>>>>>>>> >>>>>>>>> >>>>>>>>>>> Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Need to investigate more. There are two .15 versions but there is 1 year in between (if you didnât notice TheIntegratior.15 is from 2017). Just want to have more context information because I can only see that this is strange but lacking insight. >>>>>>>>>>> >>>>>>>>>>> Iâm trying to figure out why it does not update Zinc-FileSystem. No matter what I do I cannot get Metacello to load the newer package. That would fix the issue because Iâm loading 2.9.2 which should have Zinc-FileSystem-SVC.15 and not stay on the one included in the image. >>>>>>>>>>> >>>>>>>>>>> I think this is important for everyone that has a product based on 6.1 and that want to migrate someday to pharo7. This way it is impossible to do it step by step. >>>>>>>>>> >>>>>>>>>> If there is a package .15 in the image and a package .15 in the repo, I think Metacello will not update because it rely on the numbers to know when to update. If it find a .15 and currently have a .15 I think Metacello will think they are at the same version. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Norbert >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Cyril Ferlicot >>>>>>>>>> https://ferlicot.fr >>> >>> >> >> > >

July 11, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Sven Van Caekenberghe

> On 11 Jul 2018, at 19:50, Norbert Hartl <norbert(a)hartl.name> wrote: > > Thank you Sven. That fixed my first problem. Sadly the other problem is more persitent than this. I would guess that the other problem (the ZipArchive usage) might be related to the recent file/stream changes in Pharo 7 and not related to the loading of Zinc. The bug might be a binary/text stream mixup or the usage of deprecated code. > Norbert > >> Am 11.07.2018 um 16:46 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> FWIW, I created a new #stable version 2.9.3 that includes a newer Zinc-FileSystem-SvenVanCaekenberghe.16 - maybe this helps. >> >> === >> Name: Zinc-FileSystem-SvenVanCaekenberghe.16 >> Author: SvenVanCaekenberghe >> Time: 11 July 2018, 4:30:36.923152 pm >> UUID: 830fbcd3-1b2d-0d00-bd45-164704867404 >> Ancestors: Zinc-FileSystem-SvenVanCaekenberghe.15 >> >> Force an update (class comment changed) >> === >> >>> On 10 Jul 2018, at 09:17, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> On 10 Jul 2018, at 8:48, Norbert Hartl wrote: >>> >>>> Max, >>>> >>>> thanks for taking the effort. >>> >>> No worries. >>> >>>> >>>>> Am 10.07.2018 um 08:37 schrieb Max Leske <maxleske(a)gmail.com>: >>>>> >>>>> I did my best to reproduce the issue but didn't have any luck. I really need access to a Linux VM to debug this. So I'm praying that Apple fixes the access restrictions to kernel extensions in their next beta... >>>>> >>>>> BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is indeed a chance that something goes wrong during download of the zip archive and that something may be tied to a difference in the versions of Zinc (although I still think that's unlikely). >>>>> >>>> Yes there is potential but I donât see it. I take a fresh 6.1 image and load my project into. Iâm not sure but I think zinc 2.9.2 is loaded rather early in that process. So I wonder why it does not go wrong in the first phase. And also not if I load the test group within the first phase. >>>> It must be either the second Metacello invocation or the stopping, copying and starting of the image. >>>> I try to isolate this case more and provide a script that goes wrong on my machine. But it will take some time because I needed to stop trying to solve this as I wasted nearly two days on that already. >>> >>> Let me know once you have something and I'll try to help out. >>> >>>> >>>> Norbert >>>> >>>>> Max >>>>> >>>>> >>>>> On 9 Jul 2018, at 19:43, Norbert Hartl wrote: >>>>> >>>>> >>>>> >>>>>> Am 09.07.2018 um 19:10 schrieb Max Leske <maxleske(a)gmail.com>: >>>>>> >>>>>> I checked the Parasol Archive and it does not appear to be in Zip64 format (Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive can read the Parasol zip). So my next guess is that there's either a problem with Metacello or Pharo in the way that ZipArchive is used (e.g. endianness problem or non-binary stream data). It would therefore be helpful to find out what happens in ZipArchive>>readFrom:, i.e. what kind of stream is passed / opened, is it binary, does the file exist and is it still the correct file. >>>>>> >>>>>> >>>>> I couldnât see anything obvious. The file in the debug message exists, it is a readable zip file. The way Metacello uses it it is a StandardFileStream. It switches it to binary in the code. >>>>> But the only difference between a working and non-working build is the upgrade to zinc 2.9.2. >>>>> >>>>> Norbert >>>>> >>>>>> I'd debug it myself but I can't run VirtualBox at the moment because I'm on the macOS beta and it won't start... >>>>>> >>>>>> Max >>>>>> >>>>>> On 9 Jul 2018, at 18:31, Norbert Hartl wrote: >>>>>> >>>>>> Hi Max, >>>>>> >>>>>> >>>>>>> Am 09.07.2018 um 18:18 schrieb Max Leske <maxleske(a)gmail.com>: >>>>>>> >>>>>>> Hi Norbert, >>>>>>> >>>>>>> This is a bit of a guess, but it's possible that the archive that is downloaded from github is in Zip64 format and that the libraries for extracting Zip64 are missing on your Linux. That would of course contradict the experience that the same operation appears to work in 6.1. >>>>>>> >>>>>>> >>>>>> to be honest I donât know what Zip64 format is. I thought the Zip classes are pure smalltalk for unpacking. >>>>>>> Try extracting the archive manually on your Linux machine with the same method that Metacello uses (I assume, Metacello uses the ZipPlugin, which will probably use the system libraries). >>>>>>> >>>>>>> >>>>>> >>>>>> I have no ZipPlugin as library in any of my vms. >>>>>> >>>>>> But there are zips downloaded and unpacked. I start the image the first time loading all the code of my project. Then it is saved, copied to a new name and reopened to load the tests and then it fails. I did try to load the tests in the first run and then it works. >>>>>> >>>>>> Iâm running out of ideas >>>>>> >>>>>> thanks, >>>>>> >>>>>> Norbert >>>>>>> Cheers, >>>>>>> Max >>>>>>> >>>>>>> >>>>>>> On 9 Jul 2018, at 17:14, Norbert Hartl wrote: >>>>>>> >>>>>>> With the help of Esteban I got one step further. If I do >>>>>>> >>>>>>> MCWorkingCopy >>>>>>> managersForClass: ZnFileSystemUtils >>>>>>> do: [ :each | each ancestry initialize ] >>>>>>> >>>>>>> before loading my project it updates Zinc-FileSystem as well. Sadly it still does not work for me because I get >>>>>>> >>>>>>> Loading baseline of BaselineOfMobilityMap... >>>>>>> ...RETRY->BaselineOfParasol >>>>>>> ...RETRY->BaselineOfParasol[31mError: can't find EOCD position >>>>>>> >>>>>>> and I donât know why. zip file is downloaded from github and present but it fails and only on my jenkins on linux. On my Mac this works. >>>>>>> >>>>>>> I try a few things but then Iâm back on pharo6.1 for the time being :( >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>> >>>>>>>> Am 07.07.2018 um 13:28 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>>>>> >>>>>>>> Really? I thought the same but then I didnât believe it works like that. >>>>>>>> >>>>>>>> Anyway this would be very easy to solve. We just need to ask Sven if he is fine with doing an empty .16 version for Zinc-FileSystem and does an in-place version reset of 2.9.2 or a new 2.9.3. Iâm not fully convinced that will solve it but the cost wonât be very high. >>>>>>>> >>>>>>>> Norbert >>>>>>>> >>>>>>>> >>>>>>>>>> Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>>> Need to investigate more. There are two .15 versions but there is 1 year in between (if you didnât notice TheIntegratior.15 is from 2017). Just want to have more context information because I can only see that this is strange but lacking insight. >>>>>>>>>> >>>>>>>>>> Iâm trying to figure out why it does not update Zinc-FileSystem. No matter what I do I cannot get Metacello to load the newer package. That would fix the issue because Iâm loading 2.9.2 which should have Zinc-FileSystem-SVC.15 and not stay on the one included in the image. >>>>>>>>>> >>>>>>>>>> I think this is important for everyone that has a product based on 6.1 and that want to migrate someday to pharo7. This way it is impossible to do it step by step. >>>>>>>>> >>>>>>>>> If there is a package .15 in the image and a package .15 in the repo, I think Metacello will not update because it rely on the numbers to know when to update. If it find a .15 and currently have a .15 I think Metacello will think they are at the same version. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Norbert >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Cyril Ferlicot >>>>>>>>> https://ferlicot.fr >> >> > >

July 11, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Norbert Hartl

Thank you Sven. That fixed my first problem. Sadly the other problem is more persitent than this. Norbert > Am 11.07.2018 um 16:46 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > FWIW, I created a new #stable version 2.9.3 that includes a newer Zinc-FileSystem-SvenVanCaekenberghe.16 - maybe this helps. > > === > Name: Zinc-FileSystem-SvenVanCaekenberghe.16 > Author: SvenVanCaekenberghe > Time: 11 July 2018, 4:30:36.923152 pm > UUID: 830fbcd3-1b2d-0d00-bd45-164704867404 > Ancestors: Zinc-FileSystem-SvenVanCaekenberghe.15 > > Force an update (class comment changed) > === > >> On 10 Jul 2018, at 09:17, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 10 Jul 2018, at 8:48, Norbert Hartl wrote: >> >>> Max, >>> >>> thanks for taking the effort. >> >> No worries. >> >>> >>>> Am 10.07.2018 um 08:37 schrieb Max Leske <maxleske(a)gmail.com>: >>>> >>>> I did my best to reproduce the issue but didn't have any luck. I really need access to a Linux VM to debug this. So I'm praying that Apple fixes the access restrictions to kernel extensions in their next beta... >>>> >>>> BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is indeed a chance that something goes wrong during download of the zip archive and that something may be tied to a difference in the versions of Zinc (although I still think that's unlikely). >>>> >>> Yes there is potential but I donât see it. I take a fresh 6.1 image and load my project into. Iâm not sure but I think zinc 2.9.2 is loaded rather early in that process. So I wonder why it does not go wrong in the first phase. And also not if I load the test group within the first phase. >>> It must be either the second Metacello invocation or the stopping, copying and starting of the image. >>> I try to isolate this case more and provide a script that goes wrong on my machine. But it will take some time because I needed to stop trying to solve this as I wasted nearly two days on that already. >> >> Let me know once you have something and I'll try to help out. >> >>> >>> Norbert >>> >>>> Max >>>> >>>> >>>> On 9 Jul 2018, at 19:43, Norbert Hartl wrote: >>>> >>>> >>>> >>>>> Am 09.07.2018 um 19:10 schrieb Max Leske <maxleske(a)gmail.com>: >>>>> >>>>> I checked the Parasol Archive and it does not appear to be in Zip64 format (Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive can read the Parasol zip). So my next guess is that there's either a problem with Metacello or Pharo in the way that ZipArchive is used (e.g. endianness problem or non-binary stream data). It would therefore be helpful to find out what happens in ZipArchive>>readFrom:, i.e. what kind of stream is passed / opened, is it binary, does the file exist and is it still the correct file. >>>>> >>>>> >>>> I couldnât see anything obvious. The file in the debug message exists, it is a readable zip file. The way Metacello uses it it is a StandardFileStream. It switches it to binary in the code. >>>> But the only difference between a working and non-working build is the upgrade to zinc 2.9.2. >>>> >>>> Norbert >>>> >>>>> I'd debug it myself but I can't run VirtualBox at the moment because I'm on the macOS beta and it won't start... >>>>> >>>>> Max >>>>> >>>>> On 9 Jul 2018, at 18:31, Norbert Hartl wrote: >>>>> >>>>> Hi Max, >>>>> >>>>> >>>>>> Am 09.07.2018 um 18:18 schrieb Max Leske <maxleske(a)gmail.com>: >>>>>> >>>>>> Hi Norbert, >>>>>> >>>>>> This is a bit of a guess, but it's possible that the archive that is downloaded from github is in Zip64 format and that the libraries for extracting Zip64 are missing on your Linux. That would of course contradict the experience that the same operation appears to work in 6.1. >>>>>> >>>>>> >>>>> to be honest I donât know what Zip64 format is. I thought the Zip classes are pure smalltalk for unpacking. >>>>>> Try extracting the archive manually on your Linux machine with the same method that Metacello uses (I assume, Metacello uses the ZipPlugin, which will probably use the system libraries). >>>>>> >>>>>> >>>>> >>>>> I have no ZipPlugin as library in any of my vms. >>>>> >>>>> But there are zips downloaded and unpacked. I start the image the first time loading all the code of my project. Then it is saved, copied to a new name and reopened to load the tests and then it fails. I did try to load the tests in the first run and then it works. >>>>> >>>>> Iâm running out of ideas >>>>> >>>>> thanks, >>>>> >>>>> Norbert >>>>>> Cheers, >>>>>> Max >>>>>> >>>>>> >>>>>> On 9 Jul 2018, at 17:14, Norbert Hartl wrote: >>>>>> >>>>>> With the help of Esteban I got one step further. If I do >>>>>> >>>>>> MCWorkingCopy >>>>>> managersForClass: ZnFileSystemUtils >>>>>> do: [ :each | each ancestry initialize ] >>>>>> >>>>>> before loading my project it updates Zinc-FileSystem as well. Sadly it still does not work for me because I get >>>>>> >>>>>> Loading baseline of BaselineOfMobilityMap... >>>>>> ...RETRY->BaselineOfParasol >>>>>> ...RETRY->BaselineOfParasol[31mError: can't find EOCD position >>>>>> >>>>>> and I donât know why. zip file is downloaded from github and present but it fails and only on my jenkins on linux. On my Mac this works. >>>>>> >>>>>> I try a few things but then Iâm back on pharo6.1 for the time being :( >>>>>> >>>>>> Norbert >>>>>> >>>>>> >>>>>>> Am 07.07.2018 um 13:28 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>>>> >>>>>>> Really? I thought the same but then I didnât believe it works like that. >>>>>>> >>>>>>> Anyway this would be very easy to solve. We just need to ask Sven if he is fine with doing an empty .16 version for Zinc-FileSystem and does an in-place version reset of 2.9.2 or a new 2.9.3. Iâm not fully convinced that will solve it but the cost wonât be very high. >>>>>>> >>>>>>> Norbert >>>>>>> >>>>>>> >>>>>>>>> Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>>> Need to investigate more. There are two .15 versions but there is 1 year in between (if you didnât notice TheIntegratior.15 is from 2017). Just want to have more context information because I can only see that this is strange but lacking insight. >>>>>>>>> >>>>>>>>> Iâm trying to figure out why it does not update Zinc-FileSystem. No matter what I do I cannot get Metacello to load the newer package. That would fix the issue because Iâm loading 2.9.2 which should have Zinc-FileSystem-SVC.15 and not stay on the one included in the image. >>>>>>>>> >>>>>>>>> I think this is important for everyone that has a product based on 6.1 and that want to migrate someday to pharo7. This way it is impossible to do it step by step. >>>>>>>> >>>>>>>> If there is a package .15 in the image and a package .15 in the repo, I think Metacello will not update because it rely on the numbers to know when to update. If it find a .15 and currently have a .15 I think Metacello will think they are at the same version. >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Norbert >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> Cyril Ferlicot >>>>>>>> https://ferlicot.fr > >

July 11, 2018

Re: [Pharo-dev] Win10/Launcher/Pharo7.1122--ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?)

by Cyril Ferlicot D.

Le 11/07/2018 Ã 19:35, Ben Coman a Ã©critÂ : > I just just downloaded and installed the latest PharoLauncher > and running build 7.1122. > > After enabling Custom SSH Keys and opening Iceberg, > doing "Repair repository" on "iceberg" repo, > clicking "Clone again this repository" > Clone from github > Owner name: pharo-vcs > Project name: iceberg > Source directory: (blank) > Protocol: SSH > > after downloading 9.4MB over 6632 files > I get an error... "ZdcPluginMissing: SSL/TLS plugin initailization > failed (VM plugin missing ? OS libraries missing ?)" > > > Can anyone corroborate or see anything obvious I've done wrong? > Hi, Can you check that you have the SqueakSSL.dll DLL with your VM? I had the problem already that Windows Defender consider it as a maleware and delete it during the unzip of the VM. > > Image > ----- > C:\PharoLauncher\images\Exercism(71122)32bit-testing\Exercism(71122)32bit-testing.image > Pharo7.0alpha > Build information: > Pharo-7.0+alpha.build.1122.sha.9d8389221ee7e9c58d664a388fae86511c02edf7 > (32 Bit) > Unnamed > > Virtual Machine > --------------- > C:\PharoLauncher\vms\70-x86\Pharo.exe > CoInterpreter VMMaker.oscog-eem.2265 uuid: > 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > > Win32 built on Aug 27 2017 20:40:46 GMT Compiler: 5.4.0 > VMMaker versionString VM: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug > 27 21:55:26 2017 +0200 $ Plugins: 201708271955 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ > CoInterpreter VMMaker.oscog-eem.2265 uuid: > 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 > StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: > 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 > > Windows 10 > > cheers -ben > > P.S. I tried deleting the the Pharo 7 VM and having it download a new one, > but I get... > Error downloading 'https://files.pharo.org/get-files/70/pharo-win-stable.zip' > I haven't looked into that yet. Got to head to bed. > -- Cyril Ferlicot https://ferlicot.fr

July 11, 2018

Win10/Launcher/Pharo7.1122--ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?)

by Ben Coman

I just just downloaded and installed the latest PharoLauncher and running build 7.1122. After enabling Custom SSH Keys and opening Iceberg, doing "Repair repository" on "iceberg" repo, clicking "Clone again this repository" Clone from github Owner name: pharo-vcs Project name: iceberg Source directory: (blank) Protocol: SSH after downloading 9.4MB over 6632 files I get an error... "ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?)" Can anyone corroborate or see anything obvious I've done wrong? Image ----- C:\PharoLauncher\images\Exercism(71122)32bit-testing\Exercism(71122)32bit-testing.image Pharo7.0alpha Build information: Pharo-7.0+alpha.build.1122.sha.9d8389221ee7e9c58d664a388fae86511c02edf7 (32 Bit) Unnamed Virtual Machine --------------- C:\PharoLauncher\vms\70-x86\Pharo.exe CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Win32 built on Aug 27 2017 20:40:46 GMT Compiler: 5.4.0 VMMaker versionString VM: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Sun Aug 27 21:55:26 2017 +0200 $ Plugins: 201708271955 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ CoInterpreter VMMaker.oscog-eem.2265 uuid: 76b62109-629a-4c39-9641-67b53321df9a Aug 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2262 uuid: 8b531242-de02-48aa-b418-8d2dde0bec6c Aug 27 2017 Windows 10 cheers -ben P.S. I tried deleting the the Pharo 7 VM and having it download a new one, but I get... Error downloading 'https://files.pharo.org/get-files/70/pharo-win-stable.zip' I haven't looked into that yet. Got to head to bed.

July 11, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Sven Van Caekenberghe

FWIW, I created a new #stable version 2.9.3 that includes a newer Zinc-FileSystem-SvenVanCaekenberghe.16 - maybe this helps. === Name: Zinc-FileSystem-SvenVanCaekenberghe.16 Author: SvenVanCaekenberghe Time: 11 July 2018, 4:30:36.923152 pm UUID: 830fbcd3-1b2d-0d00-bd45-164704867404 Ancestors: Zinc-FileSystem-SvenVanCaekenberghe.15 Force an update (class comment changed) === > On 10 Jul 2018, at 09:17, Max Leske <maxleske(a)gmail.com> wrote: > > On 10 Jul 2018, at 8:48, Norbert Hartl wrote: > >> Max, >> >> thanks for taking the effort. > > No worries. > >> >>> Am 10.07.2018 um 08:37 schrieb Max Leske <maxleske(a)gmail.com>: >>> >>> I did my best to reproduce the issue but didn't have any luck. I really need access to a Linux VM to debug this. So I'm praying that Apple fixes the access restrictions to kernel extensions in their next beta... >>> >>> BTW, Metacello uses ZnClient, which uses ZnFileSystemUtils, so there is indeed a chance that something goes wrong during download of the zip archive and that something may be tied to a difference in the versions of Zinc (although I still think that's unlikely). >>> >> Yes there is potential but I donât see it. I take a fresh 6.1 image and load my project into. Iâm not sure but I think zinc 2.9.2 is loaded rather early in that process. So I wonder why it does not go wrong in the first phase. And also not if I load the test group within the first phase. >> It must be either the second Metacello invocation or the stopping, copying and starting of the image. >> I try to isolate this case more and provide a script that goes wrong on my machine. But it will take some time because I needed to stop trying to solve this as I wasted nearly two days on that already. > > Let me know once you have something and I'll try to help out. > >> >> Norbert >> >>> Max >>> >>> >>> On 9 Jul 2018, at 19:43, Norbert Hartl wrote: >>> >>> >>> >>>> Am 09.07.2018 um 19:10 schrieb Max Leske <maxleske(a)gmail.com>: >>>> >>>> I checked the Parasol Archive and it does not appear to be in Zip64 format (Metacello uses ZipArchive which can't cope with Zip64 but ZipArchive can read the Parasol zip). So my next guess is that there's either a problem with Metacello or Pharo in the way that ZipArchive is used (e.g. endianness problem or non-binary stream data). It would therefore be helpful to find out what happens in ZipArchive>>readFrom:, i.e. what kind of stream is passed / opened, is it binary, does the file exist and is it still the correct file. >>>> >>>> >>> I couldnât see anything obvious. The file in the debug message exists, it is a readable zip file. The way Metacello uses it it is a StandardFileStream. It switches it to binary in the code. >>> But the only difference between a working and non-working build is the upgrade to zinc 2.9.2. >>> >>> Norbert >>> >>>> I'd debug it myself but I can't run VirtualBox at the moment because I'm on the macOS beta and it won't start... >>>> >>>> Max >>>> >>>> On 9 Jul 2018, at 18:31, Norbert Hartl wrote: >>>> >>>> Hi Max, >>>> >>>> >>>>> Am 09.07.2018 um 18:18 schrieb Max Leske <maxleske(a)gmail.com>: >>>>> >>>>> Hi Norbert, >>>>> >>>>> This is a bit of a guess, but it's possible that the archive that is downloaded from github is in Zip64 format and that the libraries for extracting Zip64 are missing on your Linux. That would of course contradict the experience that the same operation appears to work in 6.1. >>>>> >>>>> >>>> to be honest I donât know what Zip64 format is. I thought the Zip classes are pure smalltalk for unpacking. >>>>> Try extracting the archive manually on your Linux machine with the same method that Metacello uses (I assume, Metacello uses the ZipPlugin, which will probably use the system libraries). >>>>> >>>>> >>>> >>>> I have no ZipPlugin as library in any of my vms. >>>> >>>> But there are zips downloaded and unpacked. I start the image the first time loading all the code of my project. Then it is saved, copied to a new name and reopened to load the tests and then it fails. I did try to load the tests in the first run and then it works. >>>> >>>> Iâm running out of ideas >>>> >>>> thanks, >>>> >>>> Norbert >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> On 9 Jul 2018, at 17:14, Norbert Hartl wrote: >>>>> >>>>> With the help of Esteban I got one step further. If I do >>>>> >>>>> MCWorkingCopy >>>>> managersForClass: ZnFileSystemUtils >>>>> do: [ :each | each ancestry initialize ] >>>>> >>>>> before loading my project it updates Zinc-FileSystem as well. Sadly it still does not work for me because I get >>>>> >>>>> Loading baseline of BaselineOfMobilityMap... >>>>> ...RETRY->BaselineOfParasol >>>>> ...RETRY->BaselineOfParasol[31mError: can't find EOCD position >>>>> >>>>> and I donât know why. zip file is downloaded from github and present but it fails and only on my jenkins on linux. On my Mac this works. >>>>> >>>>> I try a few things but then Iâm back on pharo6.1 for the time being :( >>>>> >>>>> Norbert >>>>> >>>>> >>>>>> Am 07.07.2018 um 13:28 schrieb Norbert Hartl <norbert(a)hartl.name>: >>>>>> >>>>>> Really? I thought the same but then I didnât believe it works like that. >>>>>> >>>>>> Anyway this would be very easy to solve. We just need to ask Sven if he is fine with doing an empty .16 version for Zinc-FileSystem and does an in-place version reset of 2.9.2 or a new 2.9.3. Iâm not fully convinced that will solve it but the cost wonât be very high. >>>>>> >>>>>> Norbert >>>>>> >>>>>> >>>>>>>> Am 07.07.2018 um 13:22 schrieb Cyril Ferlicot <cyril.ferlicot(a)gmail.com>: >>>>>>>> >>>>>>>> >>>>>>> >>>>>>>> Need to investigate more. There are two .15 versions but there is 1 year in between (if you didnât notice TheIntegratior.15 is from 2017). Just want to have more context information because I can only see that this is strange but lacking insight. >>>>>>>> >>>>>>>> Iâm trying to figure out why it does not update Zinc-FileSystem. No matter what I do I cannot get Metacello to load the newer package. That would fix the issue because Iâm loading 2.9.2 which should have Zinc-FileSystem-SVC.15 and not stay on the one included in the image. >>>>>>>> >>>>>>>> I think this is important for everyone that has a product based on 6.1 and that want to migrate someday to pharo7. This way it is impossible to do it step by step. >>>>>>> >>>>>>> If there is a package .15 in the image and a package .15 in the repo, I think Metacello will not update because it rely on the numbers to know when to update. If it find a .15 and currently have a .15 I think Metacello will think they are at the same version. >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Norbert >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Cyril Ferlicot >>>>>>> https://ferlicot.fr

July 11, 2018

Tonel class comments

by Guillermo Polito

Hi all, Since people have been asking how to use Tonel, I've took a look at it and have written down two class comments for both the reader and the writer. I'll push them to Tonel and schedule soon a patch release with it. Here are the class comments so people can see them/discusses them. Please, report any enhancements as pull requests in git@github.com:pharo-vcs/tonel.git ! TonelReader I'm a monticello reader for tonel format repositories. I read - a package per directory - a class per file - a set of extensions to a single class per file (for example, all extensions of a package to String will be in a single file) I'm created on a file reference to a directory where the package will be read and the name of the package to read. [[[ TonelReader on: 'someDirectoryWithTonelPackages' asFileReference filename: 'MyPackageName' ]]] My main method is - ==#definitions== reads and parses the tonel file, returns a list of monticello definitions. - ==#snapshot== returns a monticello snapshot with the read definitions. - ==#version== returns a monticello version with the read snapshot. !! Implementation details The monticello versions I return do have artificial information. Since I'm just meant to read versions from a directory, this directory has no information such as commit message, commit time, author, or ancestors. Check the method ==#loadVersionInfo== for more information. ! TonelWriter I'm a monticello writer for tonel format, writing - a package per directory - a class per file - a set of extensions to a single class per file (for example, all extensions of a package to String will be in a single file) I'm created on a file reference to a directory where the package will be written. [[[ TonelWriter on: ('someDirectory' asFileReference ensureCreateDirectory) ]]] My main methods are - ==#writeVersion:== that receives as argument a monticello version to write, from where I'll extract the corresponding monticello snapshot. - ==#writeSnapshot:== that receives as argument a monticello snapshot to write, from where I'll write all the contained definitions. !! Implementation details Notice that while writing, if the written package/snapshot already exists in the directory I'll overwrite it (i.e., remove it and recreate it). -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

July 11, 2018

Re: [Pharo-dev] [Pharo-users] Which command-line handlers do you use most?

by Tim Mackinnon

Does the metacello cmd line option work for git based projects? I could never work it out and always reverted to a script, but would be handy if it does work. Tim Sent from my iPhone > On 10 Jul 2018, at 16:24, Damien Pollet <damien.pollet(a)gmail.com> wrote: > >> On Mon, 9 Jul 2018 at 18:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> Most used: eval, config, st (default to run script.st) > > Do you ever use the metacello one instead of config? > >> Please make sure to stay as compatible as possible, lots of CI and server deploy/run code depends on it. > > > I intend to provide similar features and a path for migrating with minimal headaches, but there are several idiosyncrasies that I hope to get rid of as well. > I guess the big users of deploy/run code will come see me at ESUG and we can see what's best ;-) > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet

July 10, 2018

Re: [Pharo-dev] [Pharo-users] Which command-line handlers do you use most?

by Damien Pollet

On Mon, 9 Jul 2018 at 18:48, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Most used: eval, config, st (default to run script.st) > Do you ever use the metacello one instead of config? > Please make sure to stay as compatible as possible, lots of CI and server > deploy/run code depends on it. > I intend to provide similar features and a path for migrating with minimal headaches, but there are several idiosyncrasies that I hope to get rid of as well. I guess the big users of deploy/run code will come see me at ESUG and we can see what's best ;-) -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

July 10, 2018

[Pharo 7.0-dev] Build #1122: Fix reference to old classname

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

There is a new Pharo build available! The status of the build #1122 was: FAILURE. The Pull Request #1632 was integrated: "Fix reference to old classname" Pull request url: https://github.com/pharo-project/pharo/pull/1632 Issue Url: https://pharo.fogbugz.com/f/cases/patch Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

July 10, 2018