30205 ----- 10951 Debugger add new Method class choice dialog should show traits https://pharo.fogbugz.com/f/cases/10951 10958 Tabs model https://pharo.fogbugz.com/f/cases/10958 10959 metacelloPlatformAttributes not updated for Pharo3 https://pharo.fogbugz.com/f/cases/10959 10960 Pass on Tabs https://pharo.fogbugz.com/f/cases/10960 10961 Fix pluggableTextMorphWithLimits color https://pharo.fogbugz.com/f/cases/10961 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1147.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.16.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.85... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.199.... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.132.dif... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.15.d... http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.39....
Hello, Since the update #30205, Pharo 3.0 will not be recognized anymore as a Pharo 2.0 platform (from the metacello point of view). It means that if you have specific pharo 2.0 instructions in your configurations and you want to work on Pharo 3.0, you should add pharo 3.0 support in the configuration. For example: spec for: #'pharo1.4.x' version: '1.9'. spec for: #'pharo2.x' version: '1.10'. spec for: #'pharo3.x' version: '1.11'. or : spec for: #'pharo2.x' do: [ ... ] spec for: #'pharo3.x' do: [ ... ] Regards, Christophe. Le 19 juin 2013 à 07:49, Marcus Denker a écrit :
30205 -----
10951 Debugger add new Method class choice dialog should show traits https://pharo.fogbugz.com/f/cases/10951
10958 Tabs model https://pharo.fogbugz.com/f/cases/10958
10959 metacelloPlatformAttributes not updated for Pharo3 https://pharo.fogbugz.com/f/cases/10959
10960 Pass on Tabs https://pharo.fogbugz.com/f/cases/10960
10961 Fix pluggableTextMorphWithLimits color https://pharo.fogbugz.com/f/cases/10961
Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1147.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.16.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.85... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.199.... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.132.dif... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.15.d... http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.39....
Cool. Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive. Thierry Le 19/06/2013 13:53, Christophe Demarey a écrit :
Hello,
Since the update #30205, Pharo 3.0 will not be recognized anymore as a Pharo 2.0 platform (from the metacello point of view). It means that if you have specific pharo 2.0 instructions in your configurations and you want to work on Pharo 3.0, you should add pharo 3.0 support in the configuration.
For example: spec for: #'pharo1.4.x' version: '1.9'. spec for: #'pharo2.x' version: '1.10'. spec for: #'pharo3.x' version: '1.11'. or : spec for: #'pharo2.x' do: [ ... ] spec for: #'pharo3.x' do: [ ... ] Regards, Christophe.
Le 19 juin 2013 à 07:49, Marcus Denker a écrit :
30205 -----
10951 Debugger add new Method class choice dialog should show traits https://pharo.fogbugz.com/f/cases/10951
10958 Tabs model https://pharo.fogbugz.com/f/cases/10958
10959 metacelloPlatformAttributes not updated for Pharo3 https://pharo.fogbugz.com/f/cases/10959
10960 Pass on Tabs https://pharo.fogbugz.com/f/cases/10960
10961 Fix pluggableTextMorphWithLimits color https://pharo.fogbugz.com/f/cases/10961
Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tools-MarcusDenker.1147.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/Tabs-MarcusDenker.16.diff http://smalltalkhub.com/mc/Pharo/Pharo30/main/System-Support-MarcusDenker.85... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Widgets-MarcusDenker.199.... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Spec-Core-MarcusDenker.132.dif... http://smalltalkhub.com/mc/Pharo/Pharo30/main/Morphic-Base-MarcusDenker.15.d... http://smalltalkhub.com/mc/Pharo/Pharo30/main/DebuggerModel-MarcusDenker.39....
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 19 juin 2013 à 14:45, Goubier Thierry a écrit :
Cool.
Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive.
Not at all. There is some work from Nicolas integrated [1] but I'm not aware of other work on utf8 support. Christophe. [1] https://pharo.fogbugz.com/default.asp?10801
Le 19/06/2013 16:17, Christophe Demarey a écrit :
Le 19 juin 2013 à 14:45, Goubier Thierry a écrit :
Cool.
Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive.
Not at all. There is some work from Nicolas integrated [1] but I'm not aware of other work on utf8 support.
Ok. Looks nice :)
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0. I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way. The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait. By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
important bugfixes can be integrated in 2.0, is not all white and black :) On Jun 19, 2013, at 4:36 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/06/2013 16:17, Christophe Demarey a écrit :
Le 19 juin 2013 à 14:45, Goubier Thierry a écrit :
Cool.
Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive.
Not at all. There is some work from Nicolas integrated [1] but I'm not aware of other work on utf8 support.
Ok. Looks nice :)
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 19/06/2013 16:46, Esteban Lorenzano a écrit :
important bugfixes can be integrated in 2.0, is not all white and black :)
Thanks, you're right of course :) Thierry
On Jun 19, 2013, at 4:36 PM, Goubier Thierry <thierry.goubier@cea.fr> wrote:
Le 19/06/2013 16:17, Christophe Demarey a écrit :
Le 19 juin 2013 à 14:45, Goubier Thierry a écrit :
Cool.
Side question: Christophe, are you working on utf8 support for the Monticello tools? I encountered encoding problems with ZipArchive.
Not at all. There is some work from Nicolas integrated [1] but I'm not aware of other work on utf8 support.
Ok. Looks nice :)
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Le 19 juin 2013 à 16:36, Goubier Thierry a écrit :
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Because this change comes from the FileTree branch used fro Pharo3 [1]. This small change avoid to use a deprecated method in Pharo3. It should not be used in Pharo2. [1] https://github.com/demarey/filetree/commit/dbdbf30a00bc1f8816773dc18888abe0b...
Le 19/06/2013 17:01, Christophe Demarey a écrit :
Le 19 juin 2013 à 16:36, Goubier Thierry a écrit :
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Because this change comes from the FileTree branch used fro Pharo3 [1]. This small change avoid to use a deprecated method in Pharo3. It should not be used in Pharo2.
[1] https://github.com/demarey/filetree/commit/dbdbf30a00bc1f8816773dc18888abe0b...
Thanks. It's just that the latest filetree-core-pharo20 package has MonticelloFileTree-Core-ChristopheDemarey.97 as ancestor :) Probably me messing a merge in my filetree fork. I'm supposed to branch from the pharo20 branch, and I can see your version as well... Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
Thierry, File names are not necessarily unique in the Monticello universe, if the UUIDs match then they are the same ancestor... Dale ----- Original Message ----- | From: "Goubier Thierry" <thierry.goubier@cea.fr> | To: "Pharo Development List" <pharo-dev@lists.pharo.org> | Sent: Wednesday, June 19, 2013 8:15:48 AM | Subject: Re: [Pharo-dev] you may need to update your configurations | | | | Le 19/06/2013 17:01, Christophe Demarey a écrit : | > | > Le 19 juin 2013 à 16:36, Goubier Thierry a écrit : | > | >> By the way, why the change in | >> MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ? | > | > Because this change comes from the FileTree branch used fro Pharo3 | > [1]. | > This small change avoid to use a deprecated method in Pharo3. | > It should not be used in Pharo2. | > | > [1] | > https://github.com/demarey/filetree/commit/dbdbf30a00bc1f8816773dc18888abe0b... | | Thanks. It's just that the latest filetree-core-pharo20 package has | MonticelloFileTree-Core-ChristopheDemarey.97 as ancestor :) | | Probably me messing a merge in my filetree fork. I'm supposed to | branch | from the pharo20 branch, and I can see your version as well... | | Thierry | -- | Thierry Goubier | CEA list | Laboratoire des Fondations des Systèmes Temps Réel Embarqués | 91191 Gif sur Yvette Cedex | France | Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 | |
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will). BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Stéphane, I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members). If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice. Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-) Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will). BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
On Jun 19, 2013, at 9:28 PM, GOUBIER Thierry <thierry.goubier@cea.fr> wrote:
Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Yes that I can confirm it is wiser.
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error. Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception. But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc. Nicolas 2013/6/19 GOUBIER Thierry <thierry.goubier@cea.fr>
Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or
so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
On 19 Jun 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error.
Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception.
But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc.
Well ZnInvalidUTF8 is now a full part of Zinc itself (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, that is correct. Anyway, we have to double check.
Nicolas
2013/6/19 GOUBIER Thierry <thierry.goubier@cea.fr> Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Yes, this part is perfectly correct. It's just that I used ZnInvalidUTF8 in TextConverter which introduces a dependency of TextConverter on Zinc. This only make sense if in the long term we replace those TextConverters by cleaner Zinc encoders/decoders. 2013/6/19 Sven Van Caekenberghe <sven@stfx.eu>
On 19 Jun 2013, at 22:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error.
Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception.
But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc.
Well ZnInvalidUTF8 is now a full part of Zinc itself (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, that is correct.
Anyway, we have to double check.
Nicolas
2013/6/19 GOUBIER Thierry <thierry.goubier@cea.fr> Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or
so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
On 19 Jun 2013, at 22:55, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Yes, this part is perfectly correct. It's just that I used ZnInvalidUTF8 in TextConverter which introduces a dependency of TextConverter on Zinc.
OK, but technically, it is a dependency on Zinc-Character-Encoding-Core, which is independent of the Zinc HTTP code itself. Just like Zinc-Resource-Meta-Core (containing ZnUrl and ZnMimeType) is independent of the HTTP code proper. These sub packages where created specifically to break unwanted dependencies, as requested by Pavel et al.
This only make sense if in the long term we replace those TextConverters by cleaner Zinc encoders/decoders.
Yes, that is the idea, eventually. But never in 2.0.
2013/6/19 Sven Van Caekenberghe <sven@stfx.eu>
On 19 Jun 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error.
Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception.
But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc.
Well ZnInvalidUTF8 is now a full part of Zinc itself (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, that is correct.
Anyway, we have to double check.
Nicolas
2013/6/19 GOUBIER Thierry <thierry.goubier@cea.fr> Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Certainly not in 2.0 Even in 3.0, this will be hard because this mean a big clean-up of Stream mess (Xtreams?) 2013/6/19 Sven Van Caekenberghe <sven@stfx.eu>
On 19 Jun 2013, at 22:55, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
Yes, this part is perfectly correct. It's just that I used ZnInvalidUTF8 in TextConverter which introduces a dependency of TextConverter on Zinc.
OK, but technically, it is a dependency on Zinc-Character-Encoding-Core, which is independent of the Zinc HTTP code itself. Just like Zinc-Resource-Meta-Core (containing ZnUrl and ZnMimeType) is independent of the HTTP code proper. These sub packages where created specifically to break unwanted dependencies, as requested by Pavel et al.
This only make sense if in the long term we replace those TextConverters by cleaner Zinc encoders/decoders.
Yes, that is the idea, eventually. But never in 2.0.
2013/6/19 Sven Van Caekenberghe <sven@stfx.eu>
On 19 Jun 2013, at 22:33, Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com> wrote:
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error.
Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception.
But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc.
Well ZnInvalidUTF8 is now a full part of Zinc itself (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, that is correct.
Anyway, we have to double check.
Nicolas
2013/6/19 GOUBIER Thierry <thierry.goubier@cea.fr> Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year
or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
On Jun 19, 2013, at 11:03 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Certainly not in 2.0 Even in 3.0, this will be hard because this mean a big clean-up of Stream mess (Xtreams?)
I would love that. Any progress in that direction is welcome.
2013/6/19 Sven Van Caekenberghe <sven@stfx.eu>
On 19 Jun 2013, at 22:55, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Yes, this part is perfectly correct. It's just that I used ZnInvalidUTF8 in TextConverter which introduces a dependency of TextConverter on Zinc.
OK, but technically, it is a dependency on Zinc-Character-Encoding-Core, which is independent of the Zinc HTTP code itself. Just like Zinc-Resource-Meta-Core (containing ZnUrl and ZnMimeType) is independent of the HTTP code proper. These sub packages where created specifically to break unwanted dependencies, as requested by Pavel et al.
This only make sense if in the long term we replace those TextConverters by cleaner Zinc encoders/decoders.
Yes, that is the idea, eventually. But never in 2.0.
2013/6/19 Sven Van Caekenberghe <sven@stfx.eu>
On 19 Jun 2013, at 22:33, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error.
Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception.
But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc.
Well ZnInvalidUTF8 is now a full part of Zinc itself (Zinc-Character-Encoding-Core to be exact). It is already in 3.0 (with your code) and I guess we'll upgrade Zinc in 2.0 as well. But is is a dependency, that is correct.
Anyway, we have to double check.
Nicolas
2013/6/19 GOUBIER Thierry <thierry.goubier@cea.fr> Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
Christophe.
Ouch. Does not bode too well for backporting that to Pharo 2.0.
I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait.
By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
Hi Nicholas, I think I'll backport your ZipArchiveMember>>contentStreamFromEncoding: and I also have to backport UTF8TextConverter>>errorMalformedInput as well. It will solve my encoding problem on git archive loading. Nice. Thierry Le 19/06/2013 22:33, Nicolas Cellier a écrit :
The change is very light, I applied it almost unchanged on Squeak (can't remember which version was the first). The only thing we neeed is to catch an UTF8Error.
Since in Pharo there are two encoder/decoder hierarchies, and since that of Zinc is cleaner, I made a bet on future and chose to make UTF8Error a subclass of existing already Zn Encoding/Decoding exception.
But we still use the old TextConverter hierarchy in MC, even in Pharo 3.0. So the dependency on Zinc is totally arbitrary and un-necessary right now; it does not exist in Smalltalk version. It's just a bet on the future. For a backport to 2.0, I would just use an UTF8Error like in Squeak and avoid any dependency on Zinc.
Nicolas
2013/6/19 GOUBIER Thierry <thierry.goubier@cea.fr <mailto:thierry.goubier@cea.fr>>
Stéphane,
I'll probably have a look at Nicolas fix anyway, but as it required also a change to Zinc... then I started to worry. But it may be better than trying to fix ZipArchive incorrect encoding issues from the outside (by forcing an utf8 conversion out of the contents of the ZipArchive members).
If I manage to make sense of it, I'll put a enhancement request in FogBuz with a slice.
Yes, I think 30 is not that unstable, like 2.0 was before ... except that I'm fairly dependent on the RPackage infrastructure, and I prefer to wait until the RPackage refactoring is done ;-)
Thierry
________________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org <mailto:pharo-dev-bounces@lists.pharo.org>] de la part de Stéphane Ducasse [stephane.ducasse@inria.fr <mailto:stephane.ducasse@inria.fr>] Date d'envoi : mercredi 19 juin 2013 21:21 à : Pharo Development List Objet : Re: [Pharo-dev] you may need to update your configurations
> > >> Christophe. >> >> [1] https://pharo.fogbugz.com/default.asp?10801 > > Ouch. Does not bode too well for backporting that to Pharo 2.0. > > I'm feeling a bit down. It's either enduring bugs in 2.0 for a year or so or fighting every few days with 3.0 and knowing that anyway it's not production ready. I had to cope with 1.4 not being able to handle utf8 in the same way.
Thierry what we can do is the following: have a look at the fix of nicolas and we can try to add to th 2.0 batch but we should pay attention not to introduce other bugs (because I'm afraid it will).
BTW 30 is not that instable.
> The window for my next serious developpement with Pharo is around 2014, so I guess I could just sit and wait. > > By the way, why the change in MonticelloFileTree-Core-ChristopheDemarey.97 breaks Pharo 2.0 ?
-- Thierry Goubier CEA list Laboratoire des Fondations des Systèmes Temps Réel Embarqués 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95
participants (9)
-
Christophe Demarey -
Dale K. Henrichs -
Esteban Lorenzano -
GOUBIER Thierry -
Goubier Thierry
-
Marcus Denker -
Nicolas Cellier -
Stéphane Ducasse -
Sven Van Caekenberghe