Hello, I am using FTP Client to save xml file. Some of these files may be WideString, in that case the FTP Client fails. I got a ByteArray(Object)>>errorImproperStore The code snippet to save is like this (client is ftp client) readonlyStream := ReadStream on: stream contents. client putFileStreamContents: readonlyStream as: aFilename If I convert the content to ByteArray, in that case file is x4 times greater, which should not be the case. Enclosed PharoDebug Thanks Hilaire -- Dr. Geo http://drgeo.eu
I had a similar problem when using Monticello with regular HTTP repository....I was not able to write literal widestrings as part of the source. In other words, if the compiled method would get a WideString as part of its literals, there was a problem with Monticello.... I can search the thread if you want... best, On Sun, May 12, 2013 at 11:03 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
Hello,
I am using FTP Client to save xml file. Some of these files may be WideString, in that case the FTP Client fails. I got a ByteArray(Object)>>errorImproperStore
The code snippet to save is like this (client is ftp client) readonlyStream := ReadStream on: stream contents. client putFileStreamContents: readonlyStream as: aFilename
If I convert the content to ByteArray, in that case file is x4 times greater, which should not be the case.
Enclosed PharoDebug
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
-- Mariano http://marianopeck.wordpress.com
We fixed it by added a proper fuelNextWordsInto: but it's all a bit a mess there. And IMO there are quite random conversion going on between word and byte objects which are far from obvious. Furthermore I think it would be nice (and efficient) to replace the endianness conversion with some little nativeboost code. Relying on BitMap/Form and BitBlt to get that job done is highly confusing :/ On 2013-05-13, at 17:05, Mariano Martinez Peck <marianopeck@gmail.com> wrote:
I had a similar problem when using Monticello with regular HTTP repository....I was not able to write literal widestrings as part of the source. In other words, if the compiled method would get a WideString as part of its literals, there was a problem with Monticello.... I can search the thread if you want...
best,
On Sun, May 12, 2013 at 11:03 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
Hello,
I am using FTP Client to save xml file. Some of these files may be WideString, in that case the FTP Client fails. I got a ByteArray(Object)>>errorImproperStore
The code snippet to save is like this (client is ftp client) readonlyStream := ReadStream on: stream contents. client putFileStreamContents: readonlyStream as: aFilename
If I convert the content to ByteArray, in that case file is x4 times greater, which should not be the case.
Enclosed PharoDebug
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu
-- Mariano http://marianopeck.wordpress.com
Thanks for the feedback. I want to keep an eye open on the issue. Hilaire Le 13/05/2013 17:11, Camillo Bruni a écrit :
We fixed it by added a proper fuelNextWordsInto: but it's all a bit a mess there. And IMO there are quite random conversion going on between word and byte objects which are far from obvious.
Furthermore I think it would be nice (and efficient) to replace the endianness conversion with some little nativeboost code. Relying on BitMap/Form and BitBlt to get that job done is highly confusing :/
Hilaire, On 12 May 2013, at 16:03, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Hello,
I am using FTP Client to save xml file. Some of these files may be WideString, in that case the FTP Client fails. I got a ByteArray(Object)>>errorImproperStore
The code snippet to save is like this (client is ftp client) readonlyStream := ReadStream on: stream contents. client putFileStreamContents: readonlyStream as: aFilename
If I convert the content to ByteArray, in that case file is x4 times greater, which should not be the case.
Enclosed PharoDebug
Thanks
Hilaire
-- Dr. Geo http://drgeo.eu <PharoDebug.log>
I am not using FTP anymore, but from looking at the Smalltalk code of FTPClient it is clear that was written / expects binary data when doing uploads (hence you have to send it #binary as well), which js logical. That it worked before with Strings is because of a lucky accident in the SocketStream/VM internals (basically, it is as if #asByteArray is sent to it), but that comes down to a Latin1 encoding, more or less. If you send #asByteArray to a WideString, it does the wrong thing (just encode each Unicode code point as 32 bit integers). You need to do proper encoding. For example, to do UTF8 encoding, try: ZnUTF8Encoder new encodeString: 'élève en Français'. HTH, Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
participants (4)
-
Camillo Bruni -
Hilaire Fernandes -
Mariano Martinez Peck -
Sven Van Caekenberghe