www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Learning asynchronous sockets in D (well actually C...)

reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
The learning curve has been from like zero to "something". I am 
still grasping for some fundamental knowledge that I need to 
fully "get" whats going on. Had to read documentation for sockets 
in C to understand anything at all. That says a lot. Coming from 
BufferedReader hell in Java and did never "get" Java nio.

Looking at the Splat library, it was crude, and I didn't like the 
fact that it was D1. So I converted it to D2. Happy now, it 
works. My plan is to implement splat in the background inside of 
my simple socket server library. At this moment I have made a 
simple parrot server that currently replaces my old server in 
echoserver.d. So a bit of testing going on there atm.

I have learned the pattern "one person that runs back and forth 
with a bucket and fills it up and dumps it accordingly for each 
socket" is actually very effective. This is not very different 
from how i have implemented my simple socket server, except in my 
version i spawned threads that communicated and waited directly 
on the sockets. The parent thread only accepts sockets, I had 
Socket.select(sset,null,null); that in effect allows my spawned 
threads to do anything they wish for. Think I'll replace the 
inner contents of my old simple server with splat code.

Any pointers to what I should do next? Vibed is not an option. I 
do not like the approach. To much hassle for same result. I thnk 
the main reason for not using Vibed is that it is tightly 
connected to a toolchain. I like to have software that is 
independent.

https://github.com/jarlah/d2-simple-socket-server
Jun 23 2012
parent reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
I have now completely and totally replaced the inner contents of 
my server library with modified Splat code. It ran so much faster 
that I was actually afraid I had got it wrong. It seemed not be 
any wrong with it, so adding Splat actually made it super kidding 
me fast. I have now learned a few valuable lessons:

* add -g and -debug=splat (or any other keywords) to the build 
command
* gdb bin/SimpleServer
* continue (on breakpoints)
* run (to run the program)
* bt (for backtrace)

But of course, you all knew this before. But for a new D 
developer that has never done anything in C or C++ this was 
difficult as horses arse to understand.

Is it wrong to badge myself with asynchronous sockets? :)

https://github.com/jarlah/d2-simple-socket-server
Jun 24 2012
next sibling parent reply "Tobias Pankrath" <tobias pankrath.net> writes:
 * add -g and -debug=splat (or any other keywords) to the build 
 command



You don't need a keyword -debug is sufficient. To make the binary 
work with a debugger you does not even need -debug, only -g. 
-debug only includes code that's in a debug-block.


 * gdb bin/SimpleServer
 * continue (on breakpoints)
 * run (to run the program)
 * bt (for backtrace)

 But of course, you all knew this before. But for a new D 
 developer that has never done anything in C or C++ this was 
 difficult as horses arse to understand.

 Is it wrong to badge myself with asynchronous sockets? :)

 https://github.com/jarlah/d2-simple-socket-server


I conclude from this, that you don't have any (much) experience 
with a unix c toolchain. May I ask what languages you come from? 
What are your biggest issues with learning D? I've got the 
feeling that many in the D community expect a C++ background from 
newcomers and we might need some material that lowers the barrier 
for people coming from say python.

And I'd advice you to get a good frontend for gdb :-) It really 
makes a difference.
Jun 24 2012
parent reply "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Sunday, 24 June 2012 at 19:10:55 UTC, Tobias Pankrath wrote:

 * add -g and -debug=splat (or any other keywords) to the build 
 command



 You don't need a keyword -debug is sufficient. To make the 
 binary work with a debugger you does not even need -debug, only 
 -g. -debug only includes code that's in a debug-block.


 * gdb bin/SimpleServer
 * continue (on breakpoints)
 * run (to run the program)
 * bt (for backtrace)

 But of course, you all knew this before. But for a new D 
 developer that has never done anything in C or C++ this was 
 difficult as horses arse to understand.

 Is it wrong to badge myself with asynchronous sockets? :)

 https://github.com/jarlah/d2-simple-socket-server


 I conclude from this, that you don't have any (much) experience 
 with a unix c toolchain. May I ask what languages you come 
 from? What are your biggest issues with learning D? I've got 
 the feeling that many in the D community expect a C++ 
 background from newcomers and we might need some material that 
 lowers the barrier for people coming from say python.

 And I'd advice you to get a good frontend for gdb :-) It really 
 makes a difference.


You are absolutely right. I have no valuable experience with unix 
c toolchains. I have compiled c applications before, like hello 
world examples with gcc, and I have compiled packages in linux 
manually and know generally how c code compile. But I am 
practically foolish on old school programming in C and C++ (well 
C++ is actually totally different from C.. so I am less familiar 
with that compared to C).

I am coming from an expert Java EE background. Currently sitting 
everyday updating and adding new functionality in Java 6 
applications. I know that in Java 8 we get lambdas, hopefully it 
passes acceptance, yey! I have also done some hacking with 
Scala/Liftweb, Groovy/Grails and have touched on Ruby and other 
scripted languages. I was very interested before diving into D to 
learn a native language. D suited this requirement plus being 
almost Java like.

The thing that developers should come from a C/C++ background is 
totally not acceptable. So we need to add a "Introduction to D 
for Java developers" etc, that makes it easier to start hacking 
right away. It took me frickin two to three weeks to get familiar 
with the language, and now I am talking about the whole process. 
The language syntax in it self was so easy to understand that I 
got it straight away.
Jun 24 2012
parent "Tobias Pankrath" <tobias pankrath.net> writes:
 The thing that developers should come from a C/C++ background 
 is totally not acceptable.


Yes. I also think the documentation shouldn't assume familiarity 
with C++.


 So we need to add a "Introduction to D for Java developers" 
 etc, that makes it easier to start hacking right away.


My question aimed at figuring out, what such a introduction 
should include. When I started D, I found many things that were 
unclear and needed better documentation, especially in phobos.

But now that I fix the documentation with regard to these things, 
I don't recognize them anymore.
Jun 24 2012
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Jun 24, 2012, at 11:40 AM, "Jarl Andr=E9" =
<jarl.andre gmail.com>" puremagic.com <jarl.andre gmail.com> wrote:

=20
 Is it wrong to badge myself with asynchronous sockets? :)


Nope.  It's pretty weird stuff if you've never done event-based =
programming before.=
Jun 24 2012
parent "Jarl =?UTF-8?B?QW5kcsOpIg==?= <jarl.andre gmail.com> writes:
On Sunday, 24 June 2012 at 23:04:14 UTC, Sean Kelly wrote:

 On Jun 24, 2012, at 11:40 AM, "Jarl André" 
 <jarl.andre gmail.com>" puremagic.com <jarl.andre gmail.com> 
 wrote:

 
 Is it wrong to badge myself with asynchronous sockets? :)


 Nope.  It's pretty weird stuff if you've never done event-based 
 programming before.


I shouldn't glorify myself in any case. My first synchronous 
version was copy pasted from the socket listener example and then 
modified. When i figured that it was not accepted by folks that 
only want async stuff I found splat and updated it to d2. So the 
great feat must be that i managed to integrate splat and fix the 
segfaults following the d2 upgrade.
Jun 24 2012