- Pharo-users - lists.pharo.org

Re: [Pharo-users] WideString and FTP Client

by Hilaire Fernandes

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 :/ >

May 13, 2013

Re: [Pharo-users] please update your mail addresses

by btc＠openinworld.com

I don't understand this post. What needs to be done? cheers -ben Camillo Bruni wrote: > pharo-users(a)lists.pharo.org > > >

May 13, 2013

Nabble is back online

by DeNigris Sean

Nabble is again mirroring the (now new) dev and user lists :)

May 13, 2013

please update your mail addresses

by Camillo Bruni

pharo-users(a)lists.pharo.org

May 13, 2013

Re: [Pharo-users] WideString and FTP Client

by Sven Van Caekenberghe

Hilaire, On 12 May 2013, at 16:03, Hilaire Fernandes <hilaire.fernandes(a)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

May 13, 2013

Re: [Pharo-users] WideString and FTP Client

by Camillo Bruni

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(a)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(a)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

May 13, 2013

Re: [Pharo-users] Zn maximumEntitySize

by Sven Van Caekenberghe

Hi Pierce, On 13 May 2013, at 14:35, Pierce Ng <pierce(a)samadhiweb.com> wrote: > Hi, > > (Second try. Seems my first attempt went out at just around the time the > previous list died.) > > I'm writing (what should become) a series of blog posts on fuzzing. My blog > runs as a Zinc server delegate on Pharo. From source code, I see > ZnMaximumEntitySize, ZnServer>>maximumEntitySize:, > ZnConstants class>>defaultMaximumEntitySize, etc. > > Seems the setting doesn't? The following is my server: > > | s | > s := ZnSingleThreadedServer on: 8082. > s maximumEntitySize: 128. > s delegate: (ZnValueDelegate > with: [ :req | > ZnResponse ok: (ZnEntity html: ZnConstants welcomePageHtml) ]). > s logToTranscript. > s start. > > I expected the following client to raise ZnEntityTooLarge, but it doesn't. > Instead it works, and I see in the Transcript the request with all the $a > in it. Am I reading the source wrong? > > ZnEasy get: ('http://127.0.0.1:8082/', (String new: 200 withAll: $a) asString) ZnEntityTooLarge is a condition that is signaled by the server when it is receiving (reading) an incoming entity that is too large. This is done to protect the server. This condition is only applicable to ZnEntity and subclasses. A ZnRequest consists of other parts as well (request line and headers). For these other conditions apply: ZnLineTooLong and ZnTooManyDictionaryEntries. In the above example, you could try to add 4096 $a's to trigger a ZnLineTooLong. To trigger ZnEntityTooLarge you should PUT or POST data. > Incidentally, when I did the following on another machine, both client and > server threw time-out exceptions: > > ZnEasy get: ('http://192.168.x.x:8082/', > (String new: (16 * 1024 * 1024) withAll: $a) asString) Yes, the reaction of the server to these condition is rather hard: I should check, but I think it just aborts. I will see if I can write some high level tests. Regards, Sven > -- > Pierce Ng > http://samadhiweb.com/blog/ > > > _______________________________________________ > Pharo-users mailing list > Pharo-users(a)lists.pharo.org > http://lists.pharo.org/mailman/listinfo/pharo-users_lists.pharo.org -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

May 13, 2013

Re: [Pharo-users] New list(s)

by Marcus Denker

On May 13, 2013, at 2:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I've updated nabble to work with the new users list. I'm not exactly sure > what's going on with the dev list... is there a new url / email address? I > tried http://lists.pharo.org/mailman/listinfo/pharo-project_lists.pharo.org, > but got "No such listâ¦" http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org I am still waiting for the list of subscribers to set up the listâ¦ Marcus

May 13, 2013

Re: [Pharo-users] WideString and FTP Client

by Mariano Martinez Peck

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(a)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

May 13, 2013

Zn maximumEntitySize

by Pierce Ng

Hi, (Second try. Seems my first attempt went out at just around the time the previous list died.) I'm writing (what should become) a series of blog posts on fuzzing. My blog runs as a Zinc server delegate on Pharo. From source code, I see ZnMaximumEntitySize, ZnServer>>maximumEntitySize:, ZnConstants class>>defaultMaximumEntitySize, etc. Seems the setting doesn't? The following is my server: | s | s := ZnSingleThreadedServer on: 8082. s maximumEntitySize: 128. s delegate: (ZnValueDelegate with: [ :req | ZnResponse ok: (ZnEntity html: ZnConstants welcomePageHtml) ]). s logToTranscript. s start. I expected the following client to raise ZnEntityTooLarge, but it doesn't. Instead it works, and I see in the Transcript the request with all the $a in it. Am I reading the source wrong? ZnEasy get: ('http://127.0.0.1:8082/', (String new: 200 withAll: $a) asString) Incidentally, when I did the following on another machine, both client and server threw time-out exceptions: ZnEasy get: ('http://192.168.x.x:8082/', (String new: (16 * 1024 * 1024) withAll: $a) asString) -- Pierce Ng http://samadhiweb.com/blog/

May 13, 2013