- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Problem with zinc 2.9.2

by Max Leske

On 13 Jul 2018, at 13:37, Norbert Hartl wrote: > Sven, > > for me the problem is only on linux Yes, exactly. The problem doesn't exist on macOS. I tested on Ubuntu 17.04 (32-bit). > > Norbert > >> Am 13.07.2018 um 13:26 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >> >> >> >>> On 12 Jul 2018, at 23:15, Max Leske <maxleske(a)gmail.com> wrote: >>> >>> Hi Norbert, >>> >>> I was able to reproduce the problem and then identify the culprit, >>> although what I don't yet understand is how this is related to the >>> changes in Zinc. >>> >>> Anyway, the problem is that the file stream isn't properly flushed >>> in ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as >>> the last statement fixes your problem. Apparently, >>> StandardFileStream / MultiByteFileStream perform a simple close() on >>> the file which, according to the man page on close(), does not >>> guarantee that the contents have all been written to file. In this >>> case a flush is necessary because the entire file is immediately >>> read again. >>> >>> Here's a smaller test case for you to play with Sven: >>> >>> ZnClient new >>> url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; >>> downloadTo: '/tmp/foobar.zip'. >>> bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s >>> | s contents ]. >>> Transcript open; show: bytes size; cr. >>> 5 seconds asDelay wait. >>> Transcript show: ('/tmp/foobar.zip' asFileReference >>> binaryReadStreamDo: [ :s | s contents ]) size. >>> >>> The output in the Transcript should be: >>> >>> 315392 >>> 318420 >> >> Thanks for the effort, Max, but I am confused about your runnable >> snippet. For me (macOS, Pharo 7) is gives >> >> 318420 >> 318420 >> >> as it should, reading the same file twice. Did I miss something or >> did you make a typo ? >> >> As for #close, it is my understanding that Pharo did a #flush before >> doing a #close, but maybe that is no longer true with the new >> primitive streams, we'll have to check carefully. >> >> Good catch. I'll think about your suggestion (there are already >> #flush messages sent, but indeed the last one would be missing). >> >>> Cheers, >>> Max >>> >>> On 12 Jul 2018, at 8:17, Norbert Hartl wrote: >>> >>> Am 12.07.2018 um 08:05 schrieb Max Leske maxleske(a)gmail.com: >>> >>> On 11 Jul 2018, at 22:44, Norbert Hartl wrote: >>> >>> Hi Max, >>> >>> I constructed a case that fails exactly like I experience it. Could >>> you try? Just unpack the attachment on a linux, set PHARO_VM env to >>> your executable and execute build.sh >>> >>> I will. Might take a couple of days though. >>> >>> No problem. Iâm happy if you find time. >>> >>> Norbert >>> >>> Max >>> >>> Norbert >>> >>> Am 10.07.2018 um 09:17 schrieb Max Leske maxleske(a)gmail.com: >>> >>> 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 13, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Norbert Hartl

Sven, for me the problem is only on linux Norbert > Am 13.07.2018 um 13:26 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 12 Jul 2018, at 23:15, Max Leske <maxleske(a)gmail.com> wrote: >> >> Hi Norbert, >> >> I was able to reproduce the problem and then identify the culprit, although what I don't yet understand is how this is related to the changes in Zinc. >> >> Anyway, the problem is that the file stream isn't properly flushed in ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as the last statement fixes your problem. Apparently, StandardFileStream / MultiByteFileStream perform a simple close() on the file which, according to the man page on close(), does not guarantee that the contents have all been written to file. In this case a flush is necessary because the entire file is immediately read again. >> >> Here's a smaller test case for you to play with Sven: >> >> ZnClient new >> url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; >> downloadTo: '/tmp/foobar.zip'. >> bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]. >> Transcript open; show: bytes size; cr. >> 5 seconds asDelay wait. >> Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]) size. >> >> The output in the Transcript should be: >> >> 315392 >> 318420 > > Thanks for the effort, Max, but I am confused about your runnable snippet. For me (macOS, Pharo 7) is gives > > 318420 > 318420 > > as it should, reading the same file twice. Did I miss something or did you make a typo ? > > As for #close, it is my understanding that Pharo did a #flush before doing a #close, but maybe that is no longer true with the new primitive streams, we'll have to check carefully. > > Good catch. I'll think about your suggestion (there are already #flush messages sent, but indeed the last one would be missing). > >> Cheers, >> Max >> >> On 12 Jul 2018, at 8:17, Norbert Hartl wrote: >> >> Am 12.07.2018 um 08:05 schrieb Max Leske maxleske(a)gmail.com: >> >> On 11 Jul 2018, at 22:44, Norbert Hartl wrote: >> >> Hi Max, >> >> I constructed a case that fails exactly like I experience it. Could you try? Just unpack the attachment on a linux, set PHARO_VM env to your executable and execute build.sh >> >> I will. Might take a couple of days though. >> >> No problem. Iâm happy if you find time. >> >> Norbert >> >> Max >> >> Norbert >> >> Am 10.07.2018 um 09:17 schrieb Max Leske maxleske(a)gmail.com: >> >> 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 13, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Sven Van Caekenberghe

> On 12 Jul 2018, at 23:15, Max Leske <maxleske(a)gmail.com> wrote: > > Hi Norbert, > > I was able to reproduce the problem and then identify the culprit, although what I don't yet understand is how this is related to the changes in Zinc. > > Anyway, the problem is that the file stream isn't properly flushed in ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as the last statement fixes your problem. Apparently, StandardFileStream / MultiByteFileStream perform a simple close() on the file which, according to the man page on close(), does not guarantee that the contents have all been written to file. In this case a flush is necessary because the entire file is immediately read again. > > Here's a smaller test case for you to play with Sven: > > ZnClient new > url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; > downloadTo: '/tmp/foobar.zip'. > bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]. > Transcript open; show: bytes size; cr. > 5 seconds asDelay wait. > Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]) size. > > The output in the Transcript should be: > > 315392 > 318420 Thanks for the effort, Max, but I am confused about your runnable snippet. For me (macOS, Pharo 7) is gives 318420 318420 as it should, reading the same file twice. Did I miss something or did you make a typo ? As for #close, it is my understanding that Pharo did a #flush before doing a #close, but maybe that is no longer true with the new primitive streams, we'll have to check carefully. Good catch. I'll think about your suggestion (there are already #flush messages sent, but indeed the last one would be missing). > Cheers, > Max > > On 12 Jul 2018, at 8:17, Norbert Hartl wrote: > > Am 12.07.2018 um 08:05 schrieb Max Leske maxleske(a)gmail.com: > > On 11 Jul 2018, at 22:44, Norbert Hartl wrote: > > Hi Max, > > I constructed a case that fails exactly like I experience it. Could you try? Just unpack the attachment on a linux, set PHARO_VM env to your executable and execute build.sh > > I will. Might take a couple of days though. > > No problem. Iâm happy if you find time. > > Norbert > > Max > > Norbert > > Am 10.07.2018 um 09:17 schrieb Max Leske maxleske(a)gmail.com: > > 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 13, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Tim Mackinnon

Gosh , Iâm always impressed how you guys figure this stuff out. Many thanks to all of you for coming up with a test case and solution(s). Itâs a great community. Tim Sent from my iPhone > On 13 Jul 2018, at 00:19, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Isn't there a recent PR on opensmalltalk that address just this? > >> Le jeu. 12 juil. 2018 Ã 23:16, Max Leske <maxleske(a)gmail.com> a Ã©crit : >> Hi Norbert, >> >> I was able to reproduce the problem and then identify the culprit, although what I don't yet understand is how this is related to the changes in Zinc. >> >> Anyway, the problem is that the file stream isn't properly flushed in ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as the last statement fixes your problem. Apparently, StandardFileStream / MultiByteFileStream perform a simple close() on the file which, according to the man page on close(), does not guarantee that the contents have all been written to file. In this case a flush is necessary because the entire file is immediately read again. >> >> Here's a smaller test case for you to play with Sven: >> >> ZnClient new >> url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; >> downloadTo: '/tmp/foobar.zip'. >> bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]. >> Transcript open; show: bytes size; cr. >> 5 seconds asDelay wait. >> Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]) size. >> The output in the Transcript should be: >> >> 315392 >> 318420 >> Cheers, >> Max >> >> On 12 Jul 2018, at 8:17, Norbert Hartl wrote: >> >> Am 12.07.2018 um 08:05 schrieb Max Leske maxleske(a)gmail.com: >> >> On 11 Jul 2018, at 22:44, Norbert Hartl wrote: >> >> Hi Max, >> >> I constructed a case that fails exactly like I experience it. Could you try? Just unpack the attachment on a linux, set PHARO_VM env to your executable and execute build.sh >> >> I will. Might take a couple of days though. >> >> No problem. Iâm happy if you find time. >> >> Norbert >> >> Max >> >> Norbert >> >> Am 10.07.2018 um 09:17 schrieb Max Leske maxleske(a)gmail.com: >> >> 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 13, 2018

Smalltalks 2018 registration and talk submissions is now open!

by Gabriel Cotelli

We invite you to join us at Smalltalks 2018 <https://smalltalks2018.fast.org.ar/> in Salta, for the 12th free conference on Smalltalk based technologies, research and industry applications. Registration CLICK HERE TO REGISTER <https://docs.google.com/forms/d/e/1FAIpQLSei4VFOeoC-GSZR2ygLJaGelOvoqX6th5l…> No payment is required to attend nor to present a talk. We do accept donations from willing individuals and companies to keep our activities free. When & Where The conference will be held from October 31 to November 2 at Universidad Nacional de Salta <http://di.unsa.edu.ar/>, in Salta, Argentina. Workshops are also planned at the same site on October 29 and 30. Participation For the talks this year, weâd like to offer a wide range of subjects of interest to our attendees. Weâd like to encourage students, researchers and industry experts to share with us their stories and expertise on different Smalltalk inspired languages, frameworks and methodologies. Whether you have developed or researched an architecture, component or product, that is based on Smalltalk, or that could offer new insights to Smalltalk developers, we invite you to speak at this yearâs conference. We are also interested in hearing about your experiences with the newest technologies and how they compare to Smalltalk equivalents. Is it easier to implement a Blockchain in Smalltalk than in Scala? Is Pharo offering the required tools to work with Deep Learning? Can Gemstone outperform SQL when working with image processing? SUBMIT YOUR TALK HERE <https://docs.google.com/forms/d/e/1FAIpQLSd9dW7M3GZJHIpbIGclmoQs9Z8QgDUAqXf…> Traveling During 2018, AerolÃneas Argentinas <https://www.aerolineas.com.ar> is the official transporter for Smalltalks 2018. A 10% discount is available for airplane tickets to attend the conference: 1. Go to Aerolineas Argentinas conferences <http://ww1.aerolineas.com.ar/arg/main.asp?idSitio=AR&idPagina=161&idIdioma=…> site 2. Choose your origin and use SMTKS as promo code 3. Follow the instructions on the page This discount is valid for all tickets (tourist or executive class) with destination to Salta, arriving on or after October 24, and departing on or before November 7. The origin city can be any in Argentina, and also Madrid, Miami, New York, Rome, AsunciÃ³n, BogotÃ¡, CancÃºn, Curitiba, Florianopolis, Lima, Montevideo, Porto Alegre, Punta Cana, Punta del Este, RÃo de Janeiro, San Pablo, Salvador de BahÃa, Santa Cruz de la Sierra or Santiago de Chile. Legal disclaimer: AerolÃneas Argentinas as official transporter is not responsible for the organization, execution nor any other activity related to the conference. Scholarships As part of our vision, we aim to support people interested in participating in Smalltalk-related conferences, to generate a stronger community that can continue our work in the future. If you are a university student and require financial assistance to attend the conference, we encourage you to contact us <info(a)fast.org.ar>. We can offer travel and lodging funds to help you be part of this yearâs conference.. Support FAST FAST is a non-profit organization, funded by the donations of organizations and individuals. This support allows us to keep the conference free, every year, and to help students and distinguished speakers to attend. You can show your support at: https://smalltalks2018.fast.org.ar/donations Exclusive conference T-Shirts will be provided to those who donate before September 27th. Join us with your assistance, your presentations and your support. Help us continue to build this great community. See you in Salta! Follow us on Twitter (@fast_arg <https://twitter.com/search?f=tweets&vertical=default&q=%40fast_arg>) and Facebook (/fundacionargentinadesmalltalk <https://www.facebook.com/fundacionargentinadesmalltalk/>) to keep up to date with news and announcements.

July 13, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Nicolas Cellier

Isn't there a recent PR on opensmalltalk that address just this? Le jeu. 12 juil. 2018 Ã 23:16, Max Leske <maxleske(a)gmail.com> a Ã©crit : > Hi Norbert, > > I was able to reproduce the problem and then identify the culprit, > although what I don't yet understand is how this is related to the changes > in Zinc. > > Anyway, the problem is that the file stream isn't properly flushed in > ZnUtils class>>streamFrom:to:size:. Adding outputStream flush as the last > statement fixes your problem. Apparently, StandardFileStream / > MultiByteFileStream perform a simple close() on the file which, according > to the man page on close(), does *not* guarantee that the contents have > all been written to file. In this case a flush is necessary because the > entire file is immediately read again. > > Here's a smaller test case for you to play with Sven: > > ZnClient new > url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; > downloadTo: '/tmp/foobar.zip'. > bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]. > Transcript open; show: bytes size; cr. > 5 seconds asDelay wait. > Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]) size. > > The output in the Transcript should be: > > 315392 > 318420 > > Cheers, > Max > > On 12 Jul 2018, at 8:17, Norbert Hartl wrote: > > Am 12.07.2018 um 08:05 schrieb Max Leske maxleske(a)gmail.com: > > On 11 Jul 2018, at 22:44, Norbert Hartl wrote: > > Hi Max, > > I constructed a case that fails exactly like I experience it. Could you > try? Just unpack the attachment on a linux, set PHARO_VM env to your > executable and execute build.sh > > I will. Might take a couple of days though. > > No problem. Iâm happy if you find time. > > Norbert > > Max > > Norbert > > Am 10.07.2018 um 09:17 schrieb Max Leske maxleske(a)gmail.com: > > 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 12, 2018

Re: [Pharo-dev] Problem with zinc 2.9.2

by Max Leske

Hi Norbert, I was able to reproduce the problem and then identify the culprit, although what I don't yet understand is how this is related to the changes in Zinc. Anyway, the problem is that the file stream isn't properly flushed in ZnUtils class>>streamFrom:to:size:. Adding `outputStream flush` as the last statement fixes your problem. Apparently, StandardFileStream / MultiByteFileStream perform a simple `close()` on the file which, according to the man page on `close()`, does *not* guarantee that the contents have all been written to file. In this case a flush is necessary because the entire file is immediately read again. Here's a smaller test case for you to play with Sven: ``` ZnClient new url: 'https://github.com/zweidenker/Parasol/archive/master.zip'; downloadTo: '/tmp/foobar.zip'. bytes := '/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]. Transcript open; show: bytes size; cr. 5 seconds asDelay wait. Transcript show: ('/tmp/foobar.zip' asFileReference binaryReadStreamDo: [ :s | s contents ]) size. ``` The output in the Transcript should be: ``` 315392 318420 ``` Cheers, Max On 12 Jul 2018, at 8:17, Norbert Hartl wrote: >> Am 12.07.2018 um 08:05 schrieb Max Leske <maxleske(a)gmail.com>: >> >>> On 11 Jul 2018, at 22:44, Norbert Hartl wrote: >>> >>> Hi Max, >>> >>> I constructed a case that fails exactly like I experience it. Could >>> you try? Just unpack the attachment on a linux, set PHARO_VM env to >>> your executable and execute build.sh >> >> I will. Might take a couple of days though. >> > No problem. Iâm happy if you find time. > > Norbert >> Max >> >>> >>> Norbert >>> >>>> Am 10.07.2018 um 09:17 schrieb Max Leske <maxleske(a)gmail.com>: >>>> >>>> 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 12, 2018

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

by Ben Coman

So the quicker test is evaluating... ZnClient new get: 'https://files.pharo.org/get-files/70/pharo-win-stable.zip'. which results in... ZdcPluginMissing: SSL/TLS plugin initailization failed (VM plugin missing ? OS libraries missing ?) # Debug console # To close: F2 -> 'debug options' -> 'show output console' # To disable: F2 -> 'debug options' -> 'show console on errors' LoadLibrary(SqueakSSL) (998: Invalid access to memory location.) LoadLibrary(SqueakSSL.dll) (998: Invalid access to memory location.) LoadLibrary(C:\Apps\pharo-win-stable\SqueakSSL) (998: Invalid access to memory location.) LoadLibrary(C:\Apps\pharo-win-stable\SqueakSSL.dll) (998: Invalid access to memory location.) I disabled Defender "Check apps and files" per... https://www.itsupportguides.com/knowledge-base/windows-10/windows-defender-… although I still got a similar message presented in a differently formattted dialog "The publisher could not be verified. Are you sure that you want to run this software?" and the Image opened after clicking <Run>. cheers -ben

July 12, 2018

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

by Ben Coman

On 12 July 2018 at 12:06, Ben Coman <btc(a)openinworld.com> wrote: > On 12 July 2018 at 11:18, Ben Coman <btc(a)openinworld.com> wrote: >> On 12 July 2018 at 01:41, Cyril Ferlicot D. <cyril.ferlicot(a)gmail.com> wrote: >>> 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. >> >> Thx for the tip. I see that SqueakSSL.dll is in position, >> and the same size as in the zip file. >> In the zip file all files are dated 2017. >> >> I the same as above after downloading into a new folder... >> http://files.pharo.org/get-files/70/pharo-win-stable.zip (2018-07-10 >> 11:04 18.0 MB) >> http://files.pharo.org/get-files/70/pharo.zip (2018-06-28 15:17 8.3 MB) >> >> and get the same error. This time I also saw some additional info in >> the debug console... >> # Debug console >> # To close: F2 -> 'debug options' -> 'show output console' >> # To disable: F2 -> 'debug options' -> 'show console on errors' >> LoadLibrary(SqueakSSL) (998: Invalid access to memory location.) >> LoadLibrary(SqueakSSL.dll) (998: Invalid access to memory location.) >> LoadLibrary(C:\Apps\pharo-win-stable\SqueakSSL) (998: Invalid access >> to memory location.) >> LoadLibrary(C:\Apps\pharo-win-stable\SqueakSSL.dll) (998: Invalid >> access to memory location.) >> >> On first run Defender complained about it being an "Unknown Application" >> but it seems fine to just "Run Anyway". >> >> SqueakSSLL.dll exists in the VM folder. >> btw, I see its last code update is 28 May. >> https://github.com/OpenSmalltalk/opensmalltalk-vm/commits/Cog/platforms/win… >> >> and this VM was built 28 June, >> so this should be in the general vicinity of the error... >> https://github.com/OpenSmalltalk/opensmalltalk-vm/blame/Cog/platforms/win32… >> >> >> I looked for some change at github disabling SSL, TLS v1 & v1.1, >> but that seems to have been back in February... >> https://githubengineering.com/crypto-removal-notice/ >> >> >> Version info: >> Windows 10... >> Image >> ----- >> C:\Apps\pharo-win-stable\Pharo7.0-32bit-9d83892.image >> Pharo7.0alpha >> Build information: >> Pharo-7.0+alpha.build.1122.sha.9d8389221ee7e9c58d664a388fae86511c02edf7 >> (32 Bit) >> Unnamed >> >> Virtual Machine >> --------------- >> C:\Apps\pharo-win-stable\Pharo.exe >> 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 >> >> Win32 built on Jun 28 2018 13:16:43 GMT Compiler: 6.4.0 >> VMMaker versionString 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 >> 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 >> >> >> >> >> >> >>> 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. >> >> This morning PharoLauncher VM downloading is still not working out of the box, >> but it works if I hack the following change to use HTTP instead of HTTPS... >> PhLVirtualMachineManager>>vmUrlTemplate >> - ^ 'https://files.pharo.org/get-files/{1}/pharo{2}-{3}-{4}.zip' >> + ^ 'http://files.pharo.org/get-files/{1}/pharo{2}-{3}-{4}.zip' >> >> So maybe its a common root cause with my Iceberg problem. > > A thin lead, but... > I rarely reboot my laptop (usually just send it to sleep closing the lid) > and recently in the morning it seemed to have rebooted as part of an update. > In my Windows Update history I noticed KB4338819 installed recently > which at the bottom of... > https://support.microsoft.com/en-us/help/4338819/windows-10-update-kb4338819 > is a link "file information for cumulative update 4338819" > which lists the following file was updated... > Ncryptsslp.dll 10.0.17134.137 105,376 15-Jun-18 > > I've limited time to dig much further right now. > Main thing is whether some Windows users can report their experience > "repairing" the "iceberg" repo > using... > http://files.pharo.org/get-files/70/pharo-win-stable.zip (2018-07-11 > 11:04 18.0 MB) > http://files.pharo.org/get-files/70/pharo.zip (2018-06-28 15:17 8.3 MB) > > cheers -ben I bumped into the following on Discord, so probably its not the updated Ncryptsslp.dll dated 15-Jun-18 .... May 22nd 2018 [4:44 PM] lpellefi: Hi, I'm new to Pharo. I try to do the facial recognition tutorial and when doing a web request on https, I have an error stating that ZdCPlugin missing (SSL/TLS) any idea on how I can solve that ?(edited) [4:46 PM] lpellefi: I use Pharo 6.1 on windows 10(edited) [4:55 PM] lpellefi: I hgave the SqueakSSL.dll in the image directory cheers -ben

July 12, 2018

Pharo TechTalk at 5pm (UTC+2)

by Serge Stinckwich

I will start my techtalk at 5pm (UTC+2) about Pharo&Tensorflow: https://association.pharo.org/event-2973748 on Youtube live: https://www.youtube.com/channel/UCtelfhEzvzvsNjXrGesm2fA Questions on Discord, channel #techtalk: http://discord.gg/Sj2rhxn Thank you. -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

July 12, 2018