- Pharo-users - lists.pharo.org

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

HTTP Header field handling in Zinc

by Udo Schneider

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

July 26, 2013

Fun with symbols

by jannik.laval

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 26, 2013

[Smalltalks 2013] --- Invitation

by Andres Valloud

The FundaciÃ³n Argentina de Smalltalk (FAST, http://www.fast.org.ar) invites you to the 7th International Conference on Smalltalk Technologies (Smalltalks), to be held from October 30th through November 1st at the Universidad TecnolÃ³gica Nacional, Facultad Regional Rosario, located in Rosario, Argentina. Everyone, including teachers, students, researchers, developers and entrepreneurs, are welcome as speakers or attendees. Registration is free and now open at http://www.fast.org.ar/smalltalks2013. This year we are accepting donations from participants to help fund the conference's costs. Please see the Donate section at FAST's website, http://www.fast.org.ar/smalltalks2013/donate. Contributions are greatly appreciated, and can be received both in pesos for local attendees, as well as via Paypal for those coming from abroad. Donors will receive a set of thank you gifts as well as the conference's shirt. The goal of the Conference is to strengthen the bonds between the Argentine and the international Smalltalk community through the exchange of works, experiences and anecdotes connected with this technology and related matters. As in the previous editions, renowned members of the international Smalltalk community will visit us, and like last year we will have a Research Session with publications reviewed by an international committee. Also, the traditional Industry Track will be available for those who prefer a more practical environment. You can submit papers or talks now through our website at http://www.fast.org.ar/smalltalks2013/technical-session The Industry Track's submission deadline is October 7th. For more information about related events, such as a Pharo Sprint or talks and presentations around the dates of the conference, please visit http://www.fast.org.ar/smalltalks2013/events We will update related event information as we get closer to the conference, so please check for updates. As in previous years, we will have a social dinner during the conference. If you are planning to attend, please reply to this email with a subject of "[Social Dinner]" and indicate how many people will be coming in your party. We will have a variety of dishes available for everyone. If you have special needs other than vegetarian dishes, please let us know. For any additional questions please contact us at info(a)fast.org.ar. See you there!

July 26, 2013