July 2013 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Fun with symbols

by StÃ©phane Ducasse

tx! On Jul 28, 2013, at 9:49 AM, jannik.laval <jannik.laval(a)gmail.com> wrote: > https://pharo.fogbugz.com/default.asp?11257 > > Jannik > > On Jul 27, 2013, at 10:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Jannik can you >> - write a test >> - add a bug entry >> >> This would be to align this point. And also verify it in VW, Squeak and other. >> >> Stef >> >> On Jul 26, 2013, at 9:43 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> Something I did not know and I would like to share: >>> what is the result of "#a < #9" ? DNU ! >>> >>> When I expected to compare two symbols, in fact "#9 class" returns SmallInteger. >>> So if I want to compare two symbols, I have to do "#a < #'9' ". >>> >>> Kind of small fun things ! >>> Cheers, >>> >>> Jannik >> >> >

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by StÃ©phane Ducasse

Hello This is nice to see some progress on Socket. - What is the license of the code? - Do you want to give it to the community? - I like the suggestion of igor to have a new class. Stef > Hello, > > I want to share that I wrote a blog post on using Unix domain sockets in > Pharo. > > http://samadhiweb.com/blog/2013.07.27.unixdomainsockets.html > > The NetNameResolver bits can be made more Smalltalk-ish. Also, I'll be > looking into the minor changes needed to support SocketStream as well. > > Maybe this is the wrong list to ask, but how do I contribute this to Pharo? > > > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/ > >

July 28, 2013

Re: [Pharo-users] Fun with symbols

by jannik.laval

https://pharo.fogbugz.com/default.asp?11257 Jannik On Jul 27, 2013, at 10:45 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Jannik can you > - write a test > - add a bug entry > > This would be to align this point. And also verify it in VW, Squeak and other. > > Stef > > On Jul 26, 2013, at 9:43 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: > >> Hi guys, >> >> Something I did not know and I would like to share: >> what is the result of "#a < #9" ? DNU ! >> >> When I expected to compare two symbols, in fact "#9 class" returns SmallInteger. >> So if I want to compare two symbols, I have to do "#a < #'9' ". >> >> Kind of small fun things ! >> Cheers, >> >> Jannik > >

July 28, 2013

Re: [Pharo-users] Unix Domain Sockets

by Igor Stasenko

On 28 July 2013 03:46, Pierce Ng <pierce(a)samadhiweb.com> wrote: > Hello, > > I want to share that I wrote a blog post on using Unix domain sockets in > Pharo. > > http://samadhiweb.com/blog/2013.07.27.unixdomainsockets.html > > The NetNameResolver bits can be made more Smalltalk-ish. Also, I'll be > looking into the minor changes needed to support SocketStream as well. > > Maybe this is the wrong list to ask, but how do I contribute this to Pharo? > Well, pharo-dev list is more appropriate place for discussing contributions. Because users list is mostly about 'how can i ... ' stuff, e.g. to help newcomers with pharo, or clarify things etc (at least this is how i using it). As for the rest, you can read details at this page (and link from it): http://www.pharo-project.org/community/how-to-contribute About unix sockets: i see the changes is not really big and easy to integrate. My only question regarding this, how do you think, maybe it make sense to have a separate class for it, so users can tell: UnixSocket new instead of Socket newIPC i also think that if socket creation failed, the code should throw an error rather than return nil. > > Cheers. > > -- > Pierce Ng > http://samadhiweb.com/blog/ > > -- Best regards, Igor Stasenko.

July 28, 2013

Unix Domain Sockets

by Pierce Ng

Hello, I want to share that I wrote a blog post on using Unix domain sockets in Pharo. http://samadhiweb.com/blog/2013.07.27.unixdomainsockets.html The NetNameResolver bits can be made more Smalltalk-ish. Also, I'll be looking into the minor changes needed to support SocketStream as well. Maybe this is the wrong list to ask, but how do I contribute this to Pharo? Cheers. -- Pierce Ng http://samadhiweb.com/blog/

July 28, 2013

Re: [Pharo-users] Fun with symbols

by StÃ©phane Ducasse

Jannik can you - write a test - add a bug entry This would be to align this point. And also verify it in VW, Squeak and other. Stef On Jul 26, 2013, at 9:43 PM, jannik.laval <jannik.laval(a)gmail.com> wrote: > Hi guys, > > Something I did not know and I would like to share: > what is the result of "#a < #9" ? DNU ! > > When I expected to compare two symbols, in fact "#9 class" returns SmallInteger. > So if I want to compare two symbols, I have to do "#a < #'9' ". > > Kind of small fun things ! > Cheers, > > Jannik

July 27, 2013

Re: [Pharo-users] HTTP Header field handling in Zinc

by Sven Van Caekenberghe

Udo, On 27 Jul 2013, at 12:50, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > Hi Sven, > > On 27.07.13 00:57, Sven Van Caekenberghe wrote: >> Be sure to tell the websocketpp guys about this issue ;-) > Already did. Good. > The fact that websocketpp based apps return with 500 is even "funnier" IMHOâ¦ :-) >> A quick hack from our side would be to bypass the normal protocol of ZnHeader (specifically #normalizeHeaderKey:) and access its internal dictionary directly, using a private selector (named #headers) like this: >> >> | request | >> request := ZnRequest get: 'http://foo.com/bar?x=1'. >> request headers headers at: 'FUNy-headER' put: 'test'. >> request writeToTranscript >> >> which would go on the wire like >> >> GET /bar?x=1 HTTP/1.1 >> Accept: */* >> User-Agent: Zinc HTTP Components 1.0 >> FUNy-headER: test >> Host: foo.com >> >> >> It is not perfect, but I guess it would do. > I stumbled about #normalizeHeaderKey: as well and took another route (which is IMHO nicer ... to remove once websocketpp is fixed). > > ZnHeaders class>>#addWebSocketHeaders > CommonHeaders addAll: #('Sec-WebSocket-Version' 'Sec-WebSocket-Key') > > ZnWebSocket already uses these strings with the exact same capitilization - and being in CommonHeaders bypasses #normalizeHeaderKey: for "known" headers. Still a hack but works. Yes, that is an excellent hack. I introduced CommonHeaders quite recently as a performance improvement. But is is no solution either, like you said. >> Thanks for the feedback, make sure to tell me how it goes. > After finding out about this everything else just works fine - Zinc is simply amazing when working with HTTP. For me it's the first framework (not only in Smalltalk) which really models HTTP in an OOP way without being too complicated. > Simple things are easy - hard things possible :-) Thanks a lot ! >> PS: You do know about Zinc-WebSockets, I guess ? > Yep - using them. I wasn't mentioning this explicitly as the headers "problem" applies to ZnClient and might thus be affecting all HTTP based stuff. OK, I thought so, but I wasn't sure. > Best Regards, > > Udo Keep the feedback coming, it is really important. Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

July 27, 2013

GitHub

by phil＠highoctane.be

What exactly is https://github.com/pharo-project about ? It is to test the Monticello Git integration? Give visibility to Pharo? I also see Pharo-VM. Is this the reference repository for the VM? (which used to on Gitorious for the OSX code I know about). Thanks. Phil

July 27, 2013

Re: [Pharo-users] HTTP Header field handling in Zinc

by Udo Schneider

Hi Sven, On 27.07.13 00:57, Sven Van Caekenberghe wrote: > Be sure to tell the websocketpp guys about this issue ;-) Already did. The fact that websocketpp based apps return with 500 is even "funnier" IMHO... > A quick hack from our side would be to bypass the normal protocol of ZnHeader (specifically #normalizeHeaderKey:) and access its internal dictionary directly, using a private selector (named #headers) like this: > > | request | > request := ZnRequest get: 'http://foo.com/bar?x=1'. > request headers headers at: 'FUNy-headER' put: 'test'. > request writeToTranscript > > which would go on the wire like > > GET /bar?x=1 HTTP/1.1 > Accept: */* > User-Agent: Zinc HTTP Components 1.0 > FUNy-headER: test > Host: foo.com > > > It is not perfect, but I guess it would do. I stumbled about #normalizeHeaderKey: as well and took another route (which is IMHO nicer ... to remove once websocketpp is fixed). ZnHeaders class>>#addWebSocketHeaders CommonHeaders addAll: #('Sec-WebSocket-Version' 'Sec-WebSocket-Key') ZnWebSocket already uses these strings with the exact same capitilization - and being in CommonHeaders bypasses #normalizeHeaderKey: for "known" headers. Still a hack but works. > Thanks for the feedback, make sure to tell me how it goes. After finding out about this everything else just works fine - Zinc is simply amazing when working with HTTP. For me it's the first framework (not only in Smalltalk) which really models HTTP in an OOP way without being too complicated. Simple things are easy - hard things possible :-) > PS: You do know about Zinc-WebSockets, I guess ? Yep - using them. I wasn't mentioning this explicitly as the headers "problem" applies to ZnClient and might thus be affecting all HTTP based stuff. Best Regards, Udo

July 27, 2013

Re: [Pharo-users] HTTP Header field handling in Zinc

by Sven Van Caekenberghe

Hi Udo, On 26 Jul 2013, at 22:54, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > All, > > Is there a supported way to change the capitalization of HTTP header fields in Zinc? I'm currently running into problems with a websocketpp (https://github.com/zaphoyd/websocketpp) based backend which expects a specifically capitalized Sec-WebSocket-* header field. E.g. Sec-WebSocket-* works, Sec-Websocket-* does not. > > As far as as I can see Zinc nicely capitalizes HTTP header fields. E.g. even if you provide "Sec-WebSocket-Key" the actual transmitted header is "Sec-Websocket-Key". > > I know that HTTP specified that header fields are case-insensitive. So problem is clearly on the websocketpp side. I just want to know if I can somehow instruct Zinc to not touch the capitalization to make working with non-compliant backends easier. > > Thanks, > > Udo Good analysis: you are completely right. Be sure to tell the websocketpp guys about this issue ;-) A quick hack from our side would be to bypass the normal protocol of ZnHeader (specifically #normalizeHeaderKey:) and access its internal dictionary directly, using a private selector (named #headers) like this: | request | request := ZnRequest get: 'http://foo.com/bar?x=1'. request headers headers at: 'FUNy-headER' put: 'test'. request writeToTranscript which would go on the wire like GET /bar?x=1 HTTP/1.1 Accept: */* User-Agent: Zinc HTTP Components 1.0 FUNy-headER: test Host: foo.com It is not perfect, but I guess it would do. Thanks for the feedback, make sure to tell me how it goes. Sven PS: You do know about Zinc-WebSockets, I guess ? -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org

July 26, 2013