libaio

2020-07-16 Thread Boris-Barboris via Digitalmars-d-announce
https://github.com/Boris-Barboris/libaio/blob/master/source/libaio/package.d https://code.dlang.org/packages/libaio If you need to write some shady block-level stuff for Linux libaio this thin Derelict loader can save a day of your time.

Re: dpeq - native PSQL extended query protocol client

2017-09-05 Thread Boris-Barboris via Digitalmars-d-announce
On Tuesday, 5 September 2017 at 03:22:37 UTC, denizzzka wrote: On Monday, 4 September 2017 at 17:56:04 UTC, Boris-Barboris wrote: On Monday, 4 September 2017 at 16:05:17 UTC, denizzzka wrote: Sorry fot duplicate answer Ok, just FYI, I guess what I described was implemented in libpq for

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 16:05:17 UTC, denizzzka wrote: Sorry fot duplicate answer Ok, just FYI, I guess what I described was implemented in libpq for version 9.6 (but works on any PSQL since 8.4, since they all implement extended query protocol i wrote the client for) in a form of

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 15:53:30 UTC, denizzzka wrote: I dare say that you are engaged in premature optimization. Quite possible, but it took tolerable amount of time. I definetly will play with dpq2 more some day, maybe there is indeed no need to reinvent libpq. But what's done is

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 15:45:23 UTC, denizzzka wrote: Also, ORM is typical architecturial error. https://en.m.wikipedia.org/wiki/Object-relational_impedance_mismatch It's a tool. Error is when you use wrong tool for your job. ORMs surely help many people, and do a lot of good.

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 15:40:47 UTC, denizzzka wrote: This is just internal function. Don't try to call it from your application. I guess it's the Python curse Oh... What is it: PARSE + BIND + EXEC + SYNC ? Yeah, that's what I do currently, just write the whole command chain (same

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 15:28:11 UTC, denizzzka wrote: What do you mean? It seems like a very generic method way to send batched messages, wich would give a lot of freedom. Possible without any src modify. Will linux socket get a send called between them, or it will be buffered by

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 14:42:31 UTC, denizzzka wrote: https://github.com/denizzzka/vibe.d.db.postgresql uses dpq2 backend https://github.com/denizzzka/vibe.d.db.postgresql/blob/master/source/vibe/db/postgresql/package.d#L92 Very interesting read, thank you. Making this:

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 12:07:29 UTC, Jacob Carlborg wrote: Ah, ok. I didn't know about hb-ddb until you started this thread. I'm currently one of the maintainers of ddb and I haven't seen anything upstreamed there. Haha, yeah, I guess I've developed a habit of looking at github

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 09:30:06 UTC, Suliman wrote: Could you give an example how to make connection object if I need access to it from several classes? Should it be global? """Good way""" is probably to wrap it into some ConnectionPool (at least that's what I did). Snipper from

Re: dpeq - native PSQL extended query protocol client

2017-09-04 Thread Boris-Barboris via Digitalmars-d-announce
On Monday, 4 September 2017 at 06:40:09 UTC, Jacob Carlborg wrote: If would be great if you want to upstream your improvements. I think it's a bit unfortunate that everyone is rolling their own implementations in this community instead of working together. I would say that it's rare to need

dpeq - native PSQL extended query protocol client

2017-09-03 Thread Boris-Barboris via Digitalmars-d-announce
Hi! Couple of weeks ago I was approached with a task of writing simple microservice, and I decided to give D a chance. The problem with performance became apparent very soon, and I started to look for the cause. I tried all existing libraries, and noted pretty mature dpq2 and ddb (and it's

Re: daii - allocator-friendly closures and raii

2017-06-23 Thread Boris-Barboris via Digitalmars-d-announce
On Friday, 23 June 2017 at 20:13:07 UTC, ag0aep6g wrote: You've got bad `@trusted`s: Ty, I misunderstood the concept. I guess in a code like this it's mostly @system anyways, too many indirections to control safety level. I'm probably gonna remove most of the attributes.

daii - allocator-friendly closures and raii

2017-06-23 Thread Boris-Barboris via Digitalmars-d-announce
Hi, I wrote a small library, inspired by atilaneves automem. I didn't like some things, especially that smart pointers proxied underlying types, also I wanted class upcasting. https://github.com/Boris-Barboris/daii https://code.dlang.org/packages/daii What do you think about the