RejectedSoftware Forums

On Sun, 08 Dec 2013 11:05:16 +0100, Sönke Ludwig wrote:

Am 08.12.2013 10:47, schrieb zhaopuming:

Hi,

Is there currently a postgre binding/lib that works with vibe.d? From the docs it seems that an external I/O libaray needs to support an async connection in order to be workable with vibe.d.
In the case of a sql client, we need to change its socket to an async socket right? For the case of mysql, people got an native implementation in D and modified its source code to make this happen.
But what about postgre? What do we need to do to make it happen? For the case of a biding, do we need to modify its C code?

Just in time :)

https://github.com/rejectedsoftware/vibe.d/issues/282

http://code.dlang.org/packages/ddb

I think it was written from scratch based on the public protocol
specification.

Thanks, that's great!

I'll look and see what I can help. I'm a newbie though :)

Hi Sönke,

Sorry for the repost, I incorrectly replied to myself in the last post...

There's a little problem when I tried ddb:

I want to try it with a simple project, so I

dub init hello

and then modified package.json to add "ddb" : "~master".

Then when I ran dub

it automatilly finds dependency vibe-d~master and then echos the error:

Compiling...
source/app.d(3): Error: only one main allowed

So using ddb changes the project to a vibe.d project, but I only want to do a simple void main() experiment.

I checked the source code of ddb in https://github.com/etcimon/ddb/blob/master/package.json

{
        "name": "ddb",
        "description": "Asynchronous Postgresql Binding",
        "license": "Boost License 1.0",
        "copyright": "Copyright © 2013 Piotr Szturmaj",
        "homepage": "https://github.com/pszturmaj/",
        "authors": ["Piotr Szturmaj"],
        "targetType": "sourceLibrary",
        "dependencies": {
                "vibe-d": {"version":"~master"}
        },
        "versions": ["Have_vibe_d"]
}

It seems that one should be able to NOT use vibe.d (because to use vibe.d one should use version Have_vibe_d, right?).

Is there a config value in package.json to disable the dependency for vibe.d in dub, and then tells the ddb lib that we are not using version Have_vibe_d?

On Sun, 08 Dec 2013 11:05:16 +0100, Sönke Ludwig wrote:

Am 08.12.2013 10:47, schrieb zhaopuming:

Hi,

Is there currently a postgre binding/lib that works with vibe.d? From the docs it seems that an external I/O libaray needs to support an async connection in order to be workable with vibe.d.
In the case of a sql client, we need to change its socket to an async socket right? For the case of mysql, people got an native implementation in D and modified its source code to make this happen.
But what about postgre? What do we need to do to make it happen? For the case of a biding, do we need to modify its C code?

Just in time :)

https://github.com/rejectedsoftware/vibe.d/issues/282

http://code.dlang.org/packages/ddb

I think it was written from scratch based on the public protocol
specification.

On Mon, 09 Dec 2013 11:11:35 GMT, Sönke Ludwig wrote:

Am 09.12.2013 11:38, schrieb zhaopuming:> Hi Sönke,

Sorry for the repost, I incorrectly replied to myself in the last post...

There's a little problem when I tried ddb:

I want to try it with a simple project, so I

dub init hello

and then modified package.json to add "ddb" : "~master".

Then when I ran dub

it automatilly finds dependency vibe-d~master and then echos the error:

Compiling...
source/app.d(3): Error: only one main allowed

So using ddb changes the project to a vibe.d project, but I only want to do a simple void main() experiment.

Sorry, this is still a left-over from the times when RDMD was used for building vibe.d projects. You can add a "versions": ["VibeCustomMain"] to your package.json file to fix this.

Thanks, this works!

I'll try to remove the need for this, but unfortunately it would break a lot of existing projects, including the examples on the vibe.d homepage, if just done directly. Ideally DUB should auto-detect this using dependency tracking, like RDMD. Until it does, the situation is a bit sub-optimal.

I'm fine with the aforementioned workaround. Maybe you could put it in the docs. Or even directly in the dub init generated main function.

I checked the source code of ddb in https://github.com/etcimon/ddb/blob/master/package.json

(...)

It seems that one should be able to NOT use vibe.d (because to use vibe.d one should use version Have_vibe_d, right?).

Is there a config value in package.json to disable the dependency for vibe.d in dub, and then tells the ddb lib that we are not using version Have_vibe_d?

I've made a pull request to fix this in the original repository, it should have used an "optional": true parameter for the "vibe-d" dependency:

https://github.com/pszturmaj/ddb/pull/12

So if you want to use ddb without vibe.d, you can now do "dub upgrade" followed by "dub remove vibe-d" and it should run without Have_vibe_d defined.

Thanks :-)

On Sun, 15 Dec 2013 21:07:34 +0100, Sönke Ludwig wrote:

Am 09.12.2013 14:43, schrieb zhaopuming:

On Mon, 09 Dec 2013 11:11:35 GMT, Sönke Ludwig wrote:

Am 09.12.2013 11:38, schrieb zhaopuming:

Compiling...
source/app.d(3): Error: only one main allowed

So using ddb changes the project to a vibe.d project, but I only want to do a simple void main() experiment.

Sorry, this is still a left-over from the times when RDMD was used for building vibe.d projects. You can add a "versions": ["VibeCustomMain"] to your package.json file to fix this.

Thanks, this works!

I'll try to remove the need for this, but unfortunately it would break a lot of existing projects, including the examples on the vibe.d homepage, if just done directly. Ideally DUB should auto-detect this using dependency tracking, like RDMD. Until it does, the situation is a bit sub-optimal.

I'm fine with the aforementioned workaround. Maybe you could put it in the docs. Or even directly in the dub init generated main function.

The docs are now updated and a
transition phase from opt-out to opt-in has been started:

VibeDefaultMain should now be defined when the built-in main() is to
be used. Then, at some point, VibeCustomMain will be the default
behavior, so that vibe.d behaves like a normal library if
VibeDefaultMain isn't specified.

"dub init xxx vibe-d" (in the latest DUB beta) will now also put an
explicit VibeDefaultMain in the generated package.json.

Thanks :)