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

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

> * 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.

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.

> 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.

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.

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.