> On 12 Jul 2018, at 23:15, Max Leske <maxle...@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 maxle...@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 maxle...@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 maxle...@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 maxle...@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 maxle...@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 norb...@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.ferli...@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
>
