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 <pierce@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.
On Sun, Jul 28, 2013 at 04:59:32AM +0200, Igor Stasenko wrote:
On 28 July 2013 03:46, Pierce Ng <pierce@samadhiweb.com> 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/
thanks for the report apparently it got lost somewhere. On Jul 28, 2013, at 5:03 PM, Pierce Ng <pierce@samadhiweb.com> wrote:
Hi Igor,
Thanks. From there this link http://pharo.gforge.inria.fr/licenseDocuments/ throws a 404.
I could not find it on http://pharo.gforge.inria.fr/ :(
Thanks. From there this link http://pharo.gforge.inria.fr/licenseDocuments/ throws a 404.
Stef
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/
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/
super! Stef On Jul 28, 2013, at 5:11 PM, Pierce Ng <pierce@samadhiweb.com> wrote:
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/
Hi Pierce, On 28 Jul 2013, at 03:46, Pierce Ng <pierce@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
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 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/
On 28 Jul 2013, at 17:20, Pierce Ng <pierce@samadhiweb.com> 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/
participants (4)
-
Igor Stasenko -
Pierce Ng -
Stéphane Ducasse -
Sven Van Caekenberghe