I noticed that Phobos didn't have a high-level networking layer for cross-platform access to networking routines. In this connectivity-driven world, I feel that is something that might come in handy. What do you think?

Brian Bober wrote:

> I noticed that Phobos didn't have a high-level networking layer for
> cross-platform access to networking routines. In this connectivity-driven
> world, I feel that is something that might come in handy. What do you think?
> 
> 
> 

Aside from using C socket functions, D could use a nice native set of net functions, or at least wrappers for the C functions. I've given some
thought to starting on these myself, but I am not very skilled at
writing network code (or much code at all! ;) ), and I'm not sure what
people are looking for in a net API, i.e. object-oriented, wrapper-functions, etc... I'm sure somebody much more skilled than me has given some thought to this or begun work on it. My current projects
are all net based, and I would love to port them to D.
-Jon

"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CFDBB0A.2020702@ece.arizona.edu...

> Aside from using C socket functions, D could use a nice native set of

You mean, Berkeley sockets?

> net functions, or at least wrappers for the C functions. I've given some thought to starting on these myself, but I am not very skilled at writing network code (or much code at all! ;) ), and I'm not sure what people are looking for in a net API, i.e. object-oriented,

See http://int19h.tamb.ru, the sockets module. I don't say it's perfect, but at least it works. =)

Pavel Minayev wrote:

> "Jonathan Andrew" <jon@ece.arizona.edu> wrote in message
> news:3CFDBB0A.2020702@ece.arizona.edu...
> 
> 
>>Aside from using C socket functions, D could use a nice native set of
>>
> 
> You mean, Berkeley sockets?
> 


Yup.


> 
>>net functions, or at least wrappers for the C functions. I've given some
>>thought to starting on these myself, but I am not very skilled at
>>writing network code (or much code at all! ;) ), and I'm not sure what
>>people are looking for in a net API, i.e. object-oriented,
>>
> 
> See http://int19h.tamb.ru, the sockets module. I don't say it's perfect,
> but at least it works. =)
>



Ah, well you are already ahead of me! I'll take a look at it! Any chance of

this being a part of phobos in the future?
-Jon

"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CFDC172.5050003@ece.arizona.edu...

> Ah, well you are already ahead of me! I'll take a look at it! Any chance
of
> this being a part of phobos in the future?

You better ask Walter... =) anyhow, this thing is currently tied to my windows.d, but, as soon as I have some more free time (in a week or two), I'll fix it to work with Walter's windows.d. Then, it could be a candidate for inclusion into Phobos.

I'm translating DirectX 8 to D and ran into some #pragma pack to control struct member alignment.  Is there any equivalent for this in DMD? (even if it's not "standard" D)

Sean

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:adlgtt$15fq$1@digitaldaemon.com...

> I'm translating DirectX 8 to D and ran into some #pragma pack to control struct member alignment.  Is there any equivalent for this in DMD? (even
if
> it's not "standard" D)

Standartized D equivalent is the align() attribute. It can be applied both to entire structures, and to their parts:

    align(1) struct foo    // align entire struct on bytes boundaries
    {
        byte a;
        int b;
    }

    struct bar
    {
    align(2):    // align on word boundaries from now on
        byte a;
        int b;
    align(4):    // align on dword boundaries from now on
        short c;
        long d;
    }

Pavel Minayev wrote:


> You better ask Walter... =) anyhow, this thing is currently tied to my
> windows.d, but, as soon as I have some more free time (in a week or
> two), I'll fix it to work with Walter's windows.d. Then, it could be
> a candidate for inclusion into Phobos.
> 


Getting it to work with Walter's windows.d wouldn't make socket.d (or
net.d or whatever it would eventually be called) dependent on windows.d,
would it? Just thinking of us Linux folks...
-Jon

"Jonathan Andrew" <jon@ece.arizona.edu> wrote in message news:3CFE7247.7050706@ece.arizona.edu...

> Getting it to work with Walter's windows.d wouldn't make socket.d (or
> net.d or whatever it would eventually be called) dependent on windows.d,
> would it? Just thinking of us Linux folks...
> -Jon

socket.d is just a wrapper over a couple of socket functions. winsock.d is the one which is tied to windows.d - it is just a straight translation of winsock.h, and there is some Win32-specific stuff there. Also functions are renamed M$-style - closesocket() instead of close() etc - I guess it's better be changed. However, if you leave only the Berkeley structs and functions there, and rename those needed, it should work fine. socket.d also uses names like closesocket()... well, I guess a simple search'n' replace would do fine, or a one-line wrapper function.

Pavel Minayev wrote:


> 
> socket.d is just a wrapper over a couple of socket functions. winsock.d
> is the one which is tied to windows.d - it is just a straight translation
> of winsock.h, and there is some Win32-specific stuff there. Also functions
> are renamed M$-style - closesocket() instead of close() etc - I guess it's
> better be changed. However, if you leave only the Berkeley structs and
> functions there, and rename those needed, it should work fine. socket.d
> also uses names like closesocket()... well, I guess a simple search'n'
> replace would do fine, or a one-line wrapper function.
> 

A wrapper function would be nice, as people could use whatever name they
are most familiar with.

How difficult do you think it would be to package up those functions
into a 'socket' or 'connection' class? I'm not much of an OO fan myself,
but net programming always seemed like an appropriate place for it.
Maybe we could have a seperate class-based interface called net.d that
is slightly higher-level than socket.d? Just a thought...
-Jon