Usage of overloaded methods in REST interfaces + better return/parameter type string generation #104

wants to merge 8 commits into


None yet
3 participants

Dicebot commented Oct 3, 2012

NB: depends on this one-liner pull request to phobos: D-Programming-Language/phobos#826

As per discussion in this thread:

This is not proper pull request, as I need to clean up stuff a bit and add better error handling + unittests, but proof-of-concept proposal to ask for some early comments at least regarding vibe development guidelines (well, I am a newbie here!).

State of code: "works for me", tested on case similar to provided in newsgroup thread.


s-ludwig commented Oct 4, 2012

From a short skim, everything looks good. I would just change the local import to static so that I cannot introduce conflicts with other type names. It's really a much nicer solution! (I never have thought of class local imports and just dismissed global imports as impossible and function local imports as useless)

Dicebot closed this Oct 6, 2012


Dicebot commented Oct 7, 2012

Oops, beg my pardon, was experimenting with how github works, screwed everything : )


s-ludwig commented Oct 7, 2012

I get the feeling that git(+hub) has the same complexity as C++ anyway ;) At the moment I'm still a happy C+classes user in this regard.


Dicebot commented Oct 7, 2012

Well, to the contrary, I have been re-reading C++ standard just for the sake of fun getting around such complexity :) And now github. Damn, probably you are right, this is a deep-seated emotional problem :D

Regarding pull request - after some recent merges I have started to get libevent socket error all the time, trying to debug this for a few days without any success. Don't even know if this is related to vibe itself or libevent update ( bleeding edge distro, yay ). Probably you can give any good hints here?


s-ludwig commented Oct 8, 2012

What error code does it give and which libevent version is it? I could upgrade to Ubuntu 12.10 (libevent 2.0.19) and see if I get something there. I do sometimes get Handling of connection failed: Operating on closed TCPConnection., but that's more a matter of silencing it, since that's just the client closing the connection.


Dicebot commented Oct 9, 2012

Ye, got back to this and immediately realized that error is related to socket to mongoDB, not to connection from client itself. So stupid :)

Makes me wonder why connectMongoDB does not throw, though.


eldar commented Oct 14, 2012

Yep, I had it quite a few times that server silently starts when there is no MongoDB process running. connectMongoDB should indeed throw.

@s-ludwig s-ludwig added a commit that referenced this pull request Oct 14, 2012

@s-ludwig s-ludwig Establishing an explicit connection in MongoDB's constructor to force…
… an early exception for failures. See issue #104.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment