Change is ZnBuffered are breaking something :)

[Ducasse]

Metacello new
baseline: 'ZincHTTPComponents';
repository: 'github://svenvc/zinc/repository';
load: #(SSO)

produces may DNU

[svenvc]

Yes it does. The idea/solution is to move the special bufferer read write stream to the source code package (I am not sure this is already integrated).

The old class can then be removed from Zn.

[svenvc]

#4752

[Ducasse]

• ZnBufferedReadWriteStream should handle better the buffer. #4726
• Porting a new implementation of ZnBufferedReadWriteStream #4739
• Making the ReadWrite buffered stream to be used only by SourceFile #4752

[tesonep]

@Ducasse this is fixed with #4752.
@svenvc once loaded the tests are producing a DNU while trying to use #subStrings: on a ByteString. It should be #substrings:

[Ducasse]

Ok so I will close this.

[akgrant43]

For historical reference, the original discussion via email: http://forum.world.st/ZincHTTPComponents-SSO-breaks-ZnBufferedReadWriteStream-td5104621.html

Pharo Smalltalk Developers - ZincHTTPComponents SSO breaks ZnBufferedReadWriteStream

ZincHTTPComponents SSO breaks ZnBufferedReadWriteStream. Hi Sven, Executing: Metacello new baseline: 'ZincHTTPComponents'; repository: 'github://svenvc/zinc/repository'; load:...

[jbrichau]

@Ducasse This still breaks in Pharo 7 build 170 (which is the one you get when using the Pharolauncher). It makes loading things like Seaside impossible as they reference Zinc.

I don't find any other reference to fix this, but I might be missing something.

[svenvc]

There should be a difference (in the launcher) between Pharo 7 stable and latest.

Latest includes the bogus code (git head), stable does not (as it is a manual release).

I am not a Launcher user, so I can't say more.

[jbrichau]

Hey @svenvc
I am using the one tagged as 'stable' in my Pharolauncher. Other people reported it too.

But good to know the issue is somehow pending at least. Our builds are still working because they use the zeroconf scripts indeed.

[Ducasse]

Pablo can you have a look?

[SabineMa]

Any news on this?

[svenvc]

+1 this is a HUGE issue

[tesonep]

Hi Sven, I will put a new version today. I will scope the changes to the source files and recover the old implementation of ZnBufferedReadWrite

…

On Mon, Oct 28, 2019 at 5:01 PM Sven Van Caekenberghe < ***@***.***> wrote: +1 this is a HUGE issue — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#4764?email_source=notifications&email_token=AACWY7Y6RVGA45G5ML6FPETQQ4EEDA5CNFSM4I3NIBG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNNAPY#issuecomment-547016767>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACWY74VAVIVOYUAY3ORREDQQ4EEDANCNFSM4I3NIBGQ> .

-- Pablo Tesone. tesonep@gmail.com

[PharoProject]

Thanks Pablo, I think what you did for Pharo 8 is perfect, these streams were always very specific to changes/source access anyway, so it makes sense to keep them out of Zn.

…

On 29 Oct 2019, at 10:12, Pablo Tesone ***@***.***> wrote: Hi Sven, I will put a new version today. I will scope the changes to the source files and recover the old implementation of ZnBufferedReadWrite On Mon, Oct 28, 2019 at 5:01 PM Sven Van Caekenberghe < ***@***.***> wrote: > +1 this is a HUGE issue > > — > You are receiving this because you were assigned. > Reply to this email directly, view it on GitHub > <#4764?email_source=notifications&email_token=AACWY7Y6RVGA45G5ML6FPETQQ4EEDA5CNFSM4I3NIBG2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECNNAPY#issuecomment-547016767>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AACWY74VAVIVOYUAY3ORREDQQ4EEDANCNFSM4I3NIBGQ> > . > -- Pablo Tesone. ***@***.*** — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jvalteren]

Hi all,

First of all thanks for working on this.

I just created a new Pharo 7.0 - 64bit (stable) image using the launcher and tried to load ZincHTTPComponents from the master baseline. This still 'crashes' the image with lots of '#closed was sent to nil' and one 'Instance of ZnBufferedReadWriteStream did not understand #defaultBufferSize' exception dialogs.

I agree that this is a big issue, which is still not resolved. Any not-so-experienced Pharo user (like myself) will be put off by this.

Since Pharo version 7 is the stable version, how could something like this happen? This might hurt the reputation of the platform.

Is there anything I can do to help?

[svenvc]

The image produced by the PR 5030 check is a correct 7.0.4 with the new code (SourceCode*).

I found it here:

https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/PR-5030/2/artifact/bootstrap-cache/Pharo7.0-PR-64bit-5cba44a.zip

If you combine that with a VM like

$ curl get.pharo.org/64/vm70 | bash

you get a working image where you can load Zinc with

Metacello new
  repository: 'github://svenvc/zinc/repository';
  baseline: 'ZincHTTPComponents';
  load.

this loads successfully and all Zn/Zdc tests are green.

[jvalteren]

And the launcher now creates an Pharo 7.0 images from version Pharo7.0.4 build: 172, commit: ecc855d. This build correctly loads the Zinc baseline 👍

Thanks!

[svenvc]

Indeed it does, I checked myself as well.

What a relief.