Re: Ddb needs a maintainer
On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj wrote: Ddb is a relational database client for D [1]. Currently it only supports PostgreSQL but is not limited to it. It could be extended to support other backends. Built-in postgres client is a native implementation, that is it does not depend on libpq. Instead it communicates directly with the server avoiding text serialization and parsing overhead (PostgreSQL protocol is stable and well documented). I don't use it and I don't work on it anymore. Simply because I'm busy with other things and that things don't involve any RDBMS support. It has some user base, few contributors and 22 forks on github. Unfortunately, I could not handle pull requests and issues in a reasonable time and that's why I'm posting this here. I hope someone could take over this project and improve it. If you are interested, please either respond here or email me. [1] https://github.com/pszturmaj/ddb Hey. I'm interested. I'm a web developer and PostgreSQL is my database of choice. I also like the idea of a native implementation. The only problem is that I'm currently a beginner in D programming (but not a beginner in PostgreSQL). But since I'll need some kind of D <-> PostgreSQL bindings for my new project, I would be glad if I could help.
Re: unit-threaded v0.5.7 - advanced multi-threaded unit testing library
On 9/02/2016 12:23 AM, Atila Neves wrote:
What's new:
Built-in unittest blocks can now have a name with just a string UDA:
@("test that does stuff") unittest {... }
I feel obliged to point out that this is going to be a disaster as soon
as any other library decides that means something else.
Re: Ddb needs a maintainer
Am 13.02.2016 um 11:03 schrieb Eugene Wissner: On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj wrote: Ddb is a relational database client for D [1]. Currently it only supports PostgreSQL but is not limited to it. It could be extended to support other backends. Built-in postgres client is a native implementation, that is it does not depend on libpq. Instead it communicates directly with the server avoiding text serialization and parsing overhead (PostgreSQL protocol is stable and well documented). I don't use it and I don't work on it anymore. Simply because I'm busy with other things and that things don't involve any RDBMS support. It has some user base, few contributors and 22 forks on github. Unfortunately, I could not handle pull requests and issues in a reasonable time and that's why I'm posting this here. I hope someone could take over this project and improve it. If you are interested, please either respond here or email me. [1] https://github.com/pszturmaj/ddb Hey. I'm interested. I'm a web developer and PostgreSQL is my database of choice. I also like the idea of a native implementation. The only problem is that I'm currently a beginner in D programming (but not a beginner in PostgreSQL). But since I'll need some kind of D <-> PostgreSQL bindings for my new project, I would be glad if I could help. BTW, I'd recommend to start a new organization on GitHub for this, which makes it much easier to manage ownership changes later on, if necessary. It also gives the main repository a more official appearance.
Re: Ddb needs a maintainer
On Saturday, 13 February 2016 at 12:57:50 UTC, Sönke Ludwig wrote: Am 13.02.2016 um 11:03 schrieb Eugene Wissner: On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj wrote: Ddb is a relational database client for D [1]. Currently it only supports PostgreSQL but is not limited to it. It could be extended to support other backends. Built-in postgres client is a native implementation, that is it does not depend on libpq. Instead it communicates directly with the server avoiding text serialization and parsing overhead (PostgreSQL protocol is stable and well documented). I don't use it and I don't work on it anymore. Simply because I'm busy with other things and that things don't involve any RDBMS support. It has some user base, few contributors and 22 forks on github. Unfortunately, I could not handle pull requests and issues in a reasonable time and that's why I'm posting this here. I hope someone could take over this project and improve it. If you are interested, please either respond here or email me. [1] https://github.com/pszturmaj/ddb Hey. I'm interested. I'm a web developer and PostgreSQL is my database of choice. I also like the idea of a native implementation. The only problem is that I'm currently a beginner in D programming (but not a beginner in PostgreSQL). But since I'll need some kind of D <-> PostgreSQL bindings for my new project, I would be glad if I could help. BTW, I'd recommend to start a new organization on GitHub for this, which makes it much easier to manage ownership changes later on, if necessary. It also gives the main repository a more official appearance. Indeed. I have a fresh organization where I maintain D code: https://github.com/caraus-ecms. I could move it there and add pszturmaj to the organization.
Re: Ddb needs a maintainer
Hey Eugene, Caraus seems like an interesting project. How do you plan to build it out and differentiate it from vibe.d? On Sat, Feb 13, 2016 at 5:11 PM, Eugene Wissner via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > On Saturday, 13 February 2016 at 12:57:50 UTC, Sönke Ludwig wrote: > >> Am 13.02.2016 um 11:03 schrieb Eugene Wissner: >> >>> On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj wrote: >>> Ddb is a relational database client for D [1]. Currently it only supports PostgreSQL but is not limited to it. It could be extended to support other backends. Built-in postgres client is a native implementation, that is it does not depend on libpq. Instead it communicates directly with the server avoiding text serialization and parsing overhead (PostgreSQL protocol is stable and well documented). I don't use it and I don't work on it anymore. Simply because I'm busy with other things and that things don't involve any RDBMS support. It has some user base, few contributors and 22 forks on github. Unfortunately, I could not handle pull requests and issues in a reasonable time and that's why I'm posting this here. I hope someone could take over this project and improve it. If you are interested, please either respond here or email me. [1] https://github.com/pszturmaj/ddb >>> >>> Hey. I'm interested. I'm a web developer and PostgreSQL is my database >>> of choice. I also like the idea of a native implementation. >>> The only problem is that I'm currently a beginner in D programming (but >>> not a beginner in PostgreSQL). >>> But since I'll need some kind of D <-> PostgreSQL bindings for my new >>> project, I would be glad if I could help. >>> >> >> BTW, I'd recommend to start a new organization on GitHub for this, which >> makes it much easier to manage ownership changes later on, if necessary. It >> also gives the main repository a more official appearance. >> > > Indeed. I have a fresh organization where I maintain D code: > https://github.com/caraus-ecms. I could move it there and add pszturmaj > to the organization. >
Re: Ddb needs a maintainer
On Saturday, 13 February 2016 at 05:02:07 UTC, Piotr Szturmaj wrote: Ddb is a relational database client for D [1]. Currently it only supports PostgreSQL but is not limited to it. It could be extended to support other backends. Built-in postgres client is a native implementation, that is it does not depend on libpq. Instead it communicates directly with the server avoiding text serialization and parsing overhead (PostgreSQL protocol is stable and well documented). I don't use it and I don't work on it anymore. Simply because I'm busy with other things and that things don't involve any RDBMS support. It has some user base, few contributors and 22 forks on github. Unfortunately, I could not handle pull requests and issues in a reasonable time and that's why I'm posting this here. I hope someone could take over this project and improve it. If you are interested, please either respond here or email me. [1] https://github.com/pszturmaj/ddb But we already have ddbc, that work pretty fine. Its better to force developing of it
Re: Ddb needs a maintainer
On 2016-02-13 16:20, Suliman wrote: But we already have ddbc, that work pretty fine. Its better to force developing of it ddb is a Postgres client completely written in D. It does not use libpg, which ddbc does. It's also compatible with the IO model of vibe.d. I would say that any database library that is not compatible with vibe.d is not interesting. -- /Jacob Carlborg
Re: Ddb needs a maintainer
On 2016-02-13 06:02, Piotr Szturmaj wrote: Ddb is a relational database client for D [1]. Currently it only supports PostgreSQL but is not limited to it. It could be extended to support other backends. Built-in postgres client is a native implementation, that is it does not depend on libpq. Instead it communicates directly with the server avoiding text serialization and parsing overhead (PostgreSQL protocol is stable and well documented). I don't use it and I don't work on it anymore. Simply because I'm busy with other things and that things don't involve any RDBMS support. It has some user base, few contributors and 22 forks on github. Unfortunately, I could not handle pull requests and issues in a reasonable time and that's why I'm posting this here. I hope someone could take over this project and improve it. If you are interested, please either respond here or email me. [1] https://github.com/pszturmaj/ddb I'm very interested in ddb, not sure if I can be the maintainer. It depends if I can use D for a project that needs to access Postgres. If I can't use D for that project I don't have so much interest. -- /Jacob Carlborg
DigitalWhip
Dear Community, I've prepared a valentine for you;) It's a project I've been working for the last few months in my free time. DigitalWhip is a performance benchmark of statically typed programming languages that compile to native code: https://github.com/artemalive/DigitalWhip D is fast;) Thanks, Artem
Re: Ddb needs a maintainer
On Saturday, 13 February 2016 at 14:52:46 UTC, Adil Baig wrote:
Hey Eugene,
Caraus seems like an interesting project. How do you plan to
build it out and differentiate it from vibe.d?
Difficult to explain it in a few sentences in a foreign language,
but I'll try. Just don't hesitate to ask if you have any
questions. I'm also not very familiar with vibe.d, I've just seen
a few examples and read about it a bit; so Sönke should excuse or
correct me if I say nonsense :).
It should be a framework for easy building and maintaining of
websites. The applications built on it would follow MVC (or
MVC-like) pattern by default, but since the framework is thought
as a set of reusable components/modules it should be possible to
use it for everything else like micro-webframework for small
projects with custom structure. The whole framework should ship
an abstraction over HTTP(S), mail sending (sendmail, smtp),
session handling with a possibility to implement an own storage
(file system, redis, memcached, PostgreSQL...), dependency
injection, router and so on.
It is a very common description. Now I make a few examples
showing what I think the framework should be able to do.
1) Creating a website should be as simple as creating a
Controller and a router configuration (YAML or database for
example), that assigns some route to this controller. Think of
something like this:
class IndexController
{
indexAction(Request request)
{
int contentId =
this.getDatabase().getContentModel().getPageById(5);
this.render("myTemplate.tpl", ["content": contentId]);
}
}
2) Form handling. You create a register form. So you create a
class User:
class User
{
int username;
string password;
}
and that class with some additional information should be
rendered to a web form. There are should be also routins to help
to verify the form (helpers for checking for email, length of the
input, phone number) and persist it to a database. Whereby I
don't think on ORM here, I'm not a big fan of ORMs. For my
projects I would implement a rich domain model with domain
objects, mappers... But it should be possible to use ORM as well
if this is available. Dependency Injection would make such
freedom possible. Btw. I think I won't write a DIc,
https://github.com/mbierlee/poodinis looks very promissing for
me. I would use any tools that meet requirements.
So it should help web developers in their daily job and should
make the web development pleasant.
It doesn't mean that I implement 10 session handlers from the
beginning. I will slowly implement things that I need for my
projects and will accept contributions if there are some
contributers one day.
And I can't promise that everything will be ready tomorrow. It is
very time consuming. But I got a new project last week that may
grow in the future. So I will begin to use these tools for my
work (I'm pretty free what I'm writing in and how I do it).
It can overlap with vibe.d here and there, but I think it is more
a continuation of vibe.d's http submodule. There were already few
attempts to create a similar framework on top of vibe.d, see:
https://github.com/CarbonComputed/carb.d or
https://github.com/Skadi-d/Skadi.d for example. But I want to
make it independent of the underlying platform (vibe.d, SCGI,
FastCGI).
So far
Re: DigitalWhip
On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: DigitalWhip is a performance benchmark of statically typed programming languages that compile to native code: https://github.com/artemalive/DigitalWhip Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it)
Re: DigitalWhip
On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen wrote: On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: DigitalWhip is a performance benchmark of statically typed programming languages that compile to native code: https://github.com/artemalive/DigitalWhip Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it) These files are just for demonstration of expected output. The benchmark should work fine with the latest versions of D compilers. No guarantee for older versions;) I tested with dmd v2.069.2.
Re: Ddb needs a maintainer
On Saturday, 13 February 2016 at 15:20:26 UTC, Suliman wrote: But we already have ddbc, that work pretty fine. Its better to force developing of it I also looked into ddbc before. And it is a great thing since it is similar to the well known jdbc. I didn't like that it just wraps C-functions to access the postgresql. But I don't see the vibe.d incompatibility as a problem. Would be really greate to merge ddbc and ddb ;)
Re: DigitalWhip
Hi Artem, On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: https://github.com/artemalive/DigitalWhip Your scripts had bounds checking enabled for LDC but not the other two D compilers. I posted a pull request with the fix. LDC isn't unreasonably slow any longer on a random EC2 box I used for a quick test: --- Compiler relative times: clang 1.00 gcc 1.02 ldc 1.07 dmd 2.07 --- — David
Re: IDE - Coedit 2
On Friday, 12 February 2016 at 16:09:36 UTC, Basile Burg wrote: see https://github.com/BBasile/Coedit/releases/tag/2_gold Are you planning to support osx too someday ? --Stephan
Re: DigitalWhip
On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote: Your scripts had bounds checking enabled for LDC but not the other two D compilers. I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. Specific parts of the code might disable it via `.ptr`, but the command line switch is dangerous and I can't recommend anyone to use it... ever. We should run benchmarks with bounds checking enabled to better reflect real world results. Yes, it might "lose" to C, but we'll be the ones laughing when the C program crashes with yet another buffer overrun or when it's milliseconds in execution time lead to days of debug time and a multi-million dollar business loss when an unchecked pointer leads to a security breech.
Re: DigitalWhip
On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote: Dear Community, I've prepared a valentine for you;) It's a project I've been working for the last few months in my free time. DigitalWhip is a performance benchmark of statically typed programming languages that compile to native code: https://github.com/artemalive/DigitalWhip D is fast;) Thanks, Artem latest LDC beta + -singleobj flag puts LDC back into a competitive spot. Compiler relative times: gcc 1.00 ldc 1.10 btw, LDC beta sped up the ray intersection by 100%+, wonder what commit caused that.
Re: Ddb needs a maintainer
On 02/13/2016 09:33 PM, Eugene Wissner wrote: > On Saturday, 13 February 2016 at 15:20:26 UTC, Suliman wrote: >> >> But we already have ddbc, that work pretty fine. Its better to force >> developing of it > > I also looked into ddbc before. And it is a great thing since it is > similar to the well known jdbc. I didn't like that it just wraps > C-functions to access the postgresql. But I don't see the vibe.d > incompatibility as a problem. Would be really greate to merge ddbc and > ddb ;) It isn't specifically vibe.d incompatibility that is a problem but general lack of support of async I/O model which is a showstopper for using such solution in any serious network application. Ideally ddb should be built on top of ddbc wrapping it into fiber-friendly async API but I don't know if this is possible with ddbc design.
