Hello.

Yes. It's worked when IP not 127.0.0.1.
But is not worked whatever with NetHostDB.getByName "localhost".
Probably bug have somewhere else.

I use Poly/ML version from
commit fccf59807aea1d12f11b49f80f38b7137ad8b642
Author: David Matthews <d...@prolingua.co.uk>
Date:   Wed May 25 17:09:38 2016 +0100

It's later than

> git show  0d050ae45
commit 0d050ae450de3d5546deef873aa2b5486e64dea2
Author: David Matthews <d...@prolingua.co.uk>
Date:   Thu May 19 15:48:58 2016 +0100


P.S.

> cat 1.sml
val h0 = NetHostDB.addr(valOf(NetHostDB.getByName "localhost"))
val h1 = valOf(NetHostDB.fromString "127.0.0.1")
val _ = (if h0 = h1 then print "OK\n" else print "ERROR\n")
> poly --script 1.sml
OK


Nick.

2016-06-20 16:02 GMT+03:00 David Matthews <david.matth...@prolingua.co.uk>:

> It's not actually a bug with Socket.connectNB.  There was a bug in
> NetHostDB.scan and NetHostDB.fromString which meant that IP addresses such
> as 127.0.0.1 were not handled correctly.  This was fixed in git master in
> commit 0d050ae45.  You can work around the problem using
> NetHostDB.getByName "localhost".
>
> David
>
>
> On 20/06/2016 10:21, Kostirya wrote:
>
>> Hello, all.
>>
>> Socket.connectNB behaves oddly in Poly/ML.
>>
>> We get raise SysErr immediately after Socket.connectNB to a non-existent
>> server.
>> However, it is a nonblocking connect, so we should get information about
>> unsuccesful connecton only after socket access.
>>
>> The source code is attached and here is the results for Poly/ML:
>>
>> ./a.out
>>>
>> exc in 2 socket: SysErr ("Connection refused", SOME ECONNREFUSED)
>> exc in 3 socket: SysErr ("Connection refused", SOME ECONNREFUSED)
>> exc in 4 socket: SysErr ("Connection refused", SOME ECONNREFUSED)
>> .
>> .
>> ^C
>>
>>> ./a.out
>>>
>> exc in 1 socket: SysErr ("Connection refused", SOME ECONNREFUSED)
>> exc in 2 socket: SysErr ("Connection refused", SOME ECONNREFUSED)
>> exc in 3 socket: SysErr ("Connection refused", SOME ECONNREFUSED)
>> exc in 4 socket: SysErr ("Connection refused", SOME ECONNREFUSED)
>> .
>> .
>> ^C
>>
>> We usually get errors in this situation. I've tested on Linix and FreeBSD.
>>
>> MLton and SML/NY don't get errors in the same situation.
>>
>> NIck.
>>
>>
>>
>> _______________________________________________
>> polyml mailing list
>> polyml@inf.ed.ac.uk
>> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
>>
>> _______________________________________________
> polyml mailing list
> polyml@inf.ed.ac.uk
> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
>
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml

Reply via email to