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

Re: [Pharo-dev] Problem with zinc 2.9.2

by Max Leske

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 10, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Norbert Hartl

Max, thanks for taking the effort. > 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. 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 10, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Max Leske

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). Cheers, 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 >>> <mailto:maxleske@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 >>>> <mailto:norbert@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 <mailto:cyril.ferlicot@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 <https://ferlicot.fr/> >>> >>

July 10, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Norbert Hartl

> 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 <mailto:maxleske@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 <mailto:norbert@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 <mailto:cyril.ferlicot@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 <https://ferlicot.fr/> >> >

July 9, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Max Leske

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'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 >>> <mailto:norbert@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 <mailto:cyril.ferlicot@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 <https://ferlicot.fr/> >>

July 9, 2018

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

by Sven Van Caekenberghe

> On 9 Jul 2018, at 17:38, Damien Pollet <damien.pollet(a)gmail.com> wrote: > > Hi all, > > I'm starting to port / reimplement existing command line handlers using Clap. There's a dozen, but I wonder which ones are the most relied upon, because it's a good opportunity for refactoring the command line API as a whole and simplifying it or at least making it more orthogonal. > > For instance I discovered there is a "perform" command, which is sort of redundant with the "eval" one. Similarly there are both a "configuration" and a "metacello" handlers which seem to have the same exact purposeâ¦ > > Since Clap can exist besides the current command-line handlers, we can have a deprecation period to minimize breakage and leave time for people to adapt before we kill old command line handlers for real. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet Most used: eval, config, st (default to run script.st) Please make sure to stay as compatible as possible, lots of CI and server deploy/run code depends on it.

July 9, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Norbert Hartl

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 <mailto:norbert@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 <mailto:cyril.ferlicot@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 <https://ferlicot.fr/> >

July 9, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Max Leske

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. 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). 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 <mailto:cyril.ferlicot@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 <https://ferlicot.fr/>

July 9, 2018

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

by Hilaire

Hi Damien, I use one custom 'drgeo' handler in Dr. Geo to load sketch and script I did not tested in P7, but it seems to break, not CommandHandler fault though, more other P7 obsoleted or removed classes/protocols. Thanks To remind me on that, I should writes tests there. Hilaire Le 09/07/2018 Ã 17:38, Damien Pollet a Ã©critÂ : > I'm starting to port / reimplement existing command line handlers > using Clap. There's a dozen, but I wonder which ones are the most > relied upon, because it's a good opportunity for refactoring the > command line API as a whole and simplifying it or at least making it > more orthogonal. > -- Dr. Geo http://drgeo.eu

July 9, 2018

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

by Santiago Bragagnolo

This are great news. Maybe you can extend Pharo launcher as a usage case for implantation! It would be really welcomed and useful. Santiago El lun., 9 de jul. de 2018 17:40, Damien Pollet <damien.pollet(a)gmail.com> escribiÃ³: > Hi all, > > I'm starting to port / reimplement existing command line handlers using > Clap. There's a dozen, but I wonder which ones are the most relied upon, > because it's a good opportunity for refactoring the command line API as a > whole and simplifying it or at least making it more orthogonal. > > For instance I discovered there is a "perform" command, which is sort of > redundant with the "eval" one. Similarly there are both a "configuration" > and a "metacello" handlers which seem to have the same exact purposeâ¦ > > Since Clap can exist besides the current command-line handlers, we can > have a deprecation period to minimize breakage and leave time for people > to adapt before we kill old command line handlers for real. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

July 9, 2018