ZnBufferedReadWriteStream vs SourceFileBufferedReadWriteStream/SourceFileCharacterReadWriteStream
Hi, A new implementation of ZnBufferedReadWriteStream was added to Pharo 7, which gets again (partially) overwritten by Zinc HTTP Components, breaking code loading. In Pharo 8 this was fixed by renaming these special (and now changed) class(es) to SourceFileBufferedReadWriteStream/SourceFileCharacterReadWriteStream so that they are moved out of Zinc HTTP Components and cannot be overwritten/broken. Either the last 3 commits on the Pharo 7 branch must be reversed, or the fixes/renaming/usage of Pharo 8 must be back ported as well. This is urgent. Sven
I also do not understand how this was done in Pharo 7 *before* it was finalised/fully debugged in Pharo 8. Back-porting must be done very carefully.
On 11 Oct 2019, at 14:27, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi,
A new implementation of ZnBufferedReadWriteStream was added to Pharo 7, which gets again (partially) overwritten by Zinc HTTP Components, breaking code loading.
In Pharo 8 this was fixed by renaming these special (and now changed) class(es) to SourceFileBufferedReadWriteStream/SourceFileCharacterReadWriteStream so that they are moved out of Zinc HTTP Components and cannot be overwritten/broken.
Either the last 3 commits on the Pharo 7 branch must be reversed, or the fixes/renaming/usage of Pharo 8 must be back ported as well.
This is urgent.
Sven
On Fri, Oct 11, 2019 at 2:32 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
I also do not understand how this was done in Pharo 7 *before* it was finalised/fully debugged in Pharo 8.
Back-porting must be done very carefully.
Hi Sven, One thing that must be know is that everything going in the Pharo 7 branch is not released directly. The changes you talk about are in no release currently. A release is launched manually currently when important changes are backported and stabilized.
-- Cyril Ferlicot https://ferlicot.fr
On 11 Oct 2019, at 14:49, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Fri, Oct 11, 2019 at 2:32 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
I also do not understand how this was done in Pharo 7 *before* it was finalised/fully debugged in Pharo 8.
Back-porting must be done very carefully.
Hi Sven,
One thing that must be know is that everything going in the Pharo 7 branch is not released directly. The changes you talk about are in no release currently. A release is launched manually currently when important changes are backported and stabilized.
Hmm, OK, the /64/70+vm zeroconf version is indeed Pharo 7.0.4 build: 168, commit: ccd1f64 which does still load Zn correctly, I just tested that again. But how come some users are reporting problems then ? Is there a way they can access that unreleased version, maybe via the launcher ?
-- Cyril Ferlicot https://ferlicot.fr
Hi Sven, On Fri., 11 Oct. 2019, 15:05 Sven Van Caekenberghe, <sven@stfx.eu> wrote:
On 11 Oct 2019, at 14:49, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Fri, Oct 11, 2019 at 2:32 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
I also do not understand how this was done in Pharo 7 *before* it was
finalised/fully debugged in Pharo 8.
Back-porting must be done very carefully.
Hi Sven,
One thing that must be know is that everything going in the Pharo 7 branch is not released directly. The changes you talk about are in no release currently. A release is launched manually currently when important changes are backported and stabilized.
Hmm, OK, the /64/70+vm zeroconf version is indeed Pharo 7.0.4 build: 168, commit: ccd1f64 which does still load Zn correctly, I just tested that again.
But how come some users are reporting problems then ? Is there a way they can access that unreleased version, maybe via the launcher ?
Exactly... The launcher appears to download the latest snapshot. Cheers, Alistair (on phone)
On 11 Oct 2019, at 17:03, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Sven,
On Fri., 11 Oct. 2019, 15:05 Sven Van Caekenberghe, <sven@stfx.eu> wrote:
On 11 Oct 2019, at 14:49, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On Fri, Oct 11, 2019 at 2:32 PM Sven Van Caekenberghe <sven@stfx.eu> wrote:
I also do not understand how this was done in Pharo 7 *before* it was finalised/fully debugged in Pharo 8.
Back-porting must be done very carefully.
Hi Sven,
One thing that must be know is that everything going in the Pharo 7 branch is not released directly. The changes you talk about are in no release currently. A release is launched manually currently when important changes are backported and stabilized.
Hmm, OK, the /64/70+vm zeroconf version is indeed Pharo 7.0.4 build: 168, commit: ccd1f64 which does still load Zn correctly, I just tested that again.
But how come some users are reporting problems then ? Is there a way they can access that unreleased version, maybe via the launcher ?
Exactly... The launcher appears to download the latest snapshot.
That is not good then, at least we should tell regular users *not* to do that, but pick the latest *stable* release.
Cheers, Alistair (on phone)
On 11 Oct 2019, at 14:27, Sven Van Caekenberghe <sven@stfx.eu> wrote:
or the fixes/renaming/usage of Pharo 8 must be back ported as well.
it would be the following change https://github.com/pharo-project/pharo/pull/4752 https://github.com/pharo-project/pharo/commit/0f9b7d323e87ffb957b8b638d6867b... that needs to be applied to Pharo 7 but since this is quite complex, it would be be done by the original author, tesonep also, please make sure Zn can be loaded safely on top
Sven Van Caekenberghe-2 wrote
it would be the following change
This seems to be non-backward compatible (e.g. removal of `FileReference >> binaryReadWriteStream`). That doesn't seem like a good idea on a released stable version with a new version due for release in months. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
participants (4)
-
Alistair Grant -
Cyril Ferlicot -
Sean P. DeNigris -
Sven Van Caekenberghe