Unix Domain Sockets

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/

On 28 July 2013 03:46, Pierce Ng <[hidden email]> wrote:
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.

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

Hi Pierce,

On 28 Jul 2013, at 03:46, Pierce Ng <[hidden email]> 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

Cool. We need to integrate this: there is VM support for it and it works with minimal additions.

Since UDP sockets are currently also in the same class, I don't see a need for a separate class in the current design.

> The NetNameResolver bits can be made more Smalltalk-ish.

Yes, the code is too cryptic/technical, a helper method or two would solve this.

> Also, I'll be looking into the minor changes needed to support SocketStream as well.

Can you elaborate on that ?

> Maybe this is the wrong list to ask, but how do I contribute this to Pharo?

To add this, I would like some minimal tests as well (to be skipped on windows).

Sven

> Cheers.
>
> --
> Pierce Ng
> http://samadhiweb.com/blog/

--
Sven Van Caekenberghe
Proudly supporting Pharo
http://pharo.org
http://association.pharo.org
http://consortium.pharo.org

On Sun, Jul 28, 2013 at 04:59:32AM +0200, Igor Stasenko wrote:
> On 28 July 2013 03:46, Pierce Ng <[hidden email]> wrote:
> > Maybe this is the wrong list to ask, but how do I contribute this to Pharo?
> http://www.pharo-project.org/community/how-to-contribute

Hi Igor,

Thanks. From there this link http://pharo.gforge.inria.fr/licenseDocuments/
throws a 404.


> 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 went for minimal change. As Socket already has newTCP and newUDP
instance creation methods, I use newICP.

Since the VM apparently also supports IPv6, I'd suggest to defer on
creating separate classes until there is more experience using Unix domain
*and* IPv6 TCP/UDP sockets, alongside current code that is using TCP/UDP
over IPv4.


> i also think that if socket creation failed, the code should throw an
> error rather than return nil.

Ditto, I followed current behaviour. Not quite Smalltalk-like, I agree.

Cheers.

--
Pierce Ng
http://samadhiweb.com/blog/

On Sun, Jul 28, 2013 at 10:12:27AM +0200, St?phane Ducasse wrote:
> 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?

Hi Stef. Yes, I'm happy for these changes to be folded into Pharo.  I'll
file an entry into the issue tracker. The license of the code is MIT, to
match Pharo's.

Cheers.

--
Pierce Ng
http://samadhiweb.com/blog/

On Sun, Jul 28, 2013 at 01:12:41PM +0200, Sven Van Caekenberghe wrote:
> Since UDP sockets are currently also in the same class, I don't see a
> need for a separate class in the current design.

Hi Sven. Agreed, as I wrote in the other mail about gaining experience with
IPv6 as well.

> Yes, the code is too cryptic/technical, a helper method or two would
> solve this.

Done as per my newest blog post. Will add that when I create the issue.

> > Also, I'll be looking into the minor changes needed to support
> > SocketStream as well.
>
> Can you elaborate on that ?

SocketStream has instance creation methods such as
openConnectionToHost:port:. To use Unix domain sockets, I imagine something
like openConnectionToIPCSocketPath:.

> To add this, I would like some minimal tests as well (to be skipped on
> windows).

I took a peek at SocketTest; the setUp method sets up a server socket, and
tests are run against this socket. This kinda like requires what is being
tested to be working in the first place?

Cheers.

--
Pierce Ng
http://samadhiweb.com/blog/

thanks for the report 

super!

Stef

On Jul 28, 2013, at 5:11 PM, Pierce Ng <[hidden email]> wrote:

I could not find it on http://pharo.gforge.inria.fr/  :(

On 28 Jul 2013, at 17:20, Pierce Ng <[hidden email]> wrote:

> On Sun, Jul 28, 2013 at 01:12:41PM +0200, Sven Van Caekenberghe wrote:
>> Since UDP sockets are currently also in the same class, I don't see a
>> need for a separate class in the current design.
>
> Hi Sven. Agreed, as I wrote in the other mail about gaining experience with
> IPv6 as well.

OK

>> Yes, the code is too cryptic/technical, a helper method or two would
>> solve this.
>
> Done as per my newest blog post. Will add that when I create the issue.

Yes, I've seen it. Good, that is what I meant.

>>> Also, I'll be looking into the minor changes needed to support
>>> SocketStream as well.
>>
>> Can you elaborate on that ?
>
> SocketStream has instance creation methods such as
> openConnectionToHost:port:. To use Unix domain sockets, I imagine something
> like openConnectionToIPCSocketPath:.

Ah, OK, I understand. But there is SocketStream class>>#on: once you have your socket. That should be enough for testing client and server side. Once you validated it works, you could indeed add the #openConnectionToIPCSocketPath: convenience method.

>> To add this, I would like some minimal tests as well (to be skipped on
>> windows).
>
> I took a peek at SocketTest; the setUp method sets up a server socket, and
> tests are run against this socket. This kinda like requires what is being
> tested to be working in the first place?

I understand your point, it is possible to have interesting theoretical discussions about unit tests, but a test that exercises the code is much better than none at all. If you don't like the setup of SocketTest, write your own test class, like DomainSocketTest. Tests are really important: they are live, validated documentation.

Regarding the last blog post, does that mean that a VM change is now necessary or not ?

Thanks for contributing !

Sven

> Cheers.
>
> --
> Pierce Ng
> http://samadhiweb.com/blog/