Re: meson and d
On Sunday, 9 June 2019 at 13:13:28 UTC, dkd wrote: hi, i need some meson configuration that works with dmd and ldc my setting don't work. because meson complains it cannot find the d compiler. d compiler can be invoked on command line. i use : set dmd_path="path/to/d/base" set PATH=%dmd_path%\bin;%PATH%; mingw can be detected by setting GCC_HOME i use win7 and x86 meson 0.50.1 Are you using Windows? Meson's D support has never been tested there. In theory though you can point it at any D compiler by setting the "DC" environment variable.
Re: D need an ORM library!
On Monday, 20 August 2018 at 15:58:37 UTC, Jesse Phillips wrote: [...] There are a number of things out there, but personally don't know there state or simplicity. 2016 there was a talk: http://dconf.org/2016/talks/nowak.html But personally I preferred this one: http://dconf.org/2016/talks/smith.html https://github.com/cruisercoder/dstddb This all looks very dead. Is there any project still alive? The only effort that still seems to be actively developed as far as I can see is hunt-entity... And I agree, SQLAlchemy is pretty great!
Re: GDC on Travis-CI
On Saturday, 2 June 2018 at 16:27:38 UTC, Seb wrote: On Saturday, 2 June 2018 at 16:04:09 UTC, Matthias Klumpp wrote: On Saturday, 2 June 2018 at 03:15:56 UTC, crimaniak wrote: I started to work with Travis-CI, building packages using all three main compilers, and noticed that I have problems with gdc every time and need to tweak code because of many things missing. For example: https://travis-ci.org/crimaniak/json-patch/jobs/386963340 Why this situation with gdc and how best to deal with it? The build log seems to indicate it uses gdc 4.8, while the current version of GDC is 8.1 which is based on the 2.076 frontend. Maybe just updating GDC on Travis will fix this. Sadly that's not so easy as 1) the GDC download path changed and we are still waiting on feedback from Ian on this (since more than, see https://github.com/dlang/installer/pull/251) 2) AFAICT there are no public binaries that use anything later than 2.068.2 could be used (see https://gdcproject.org/downloads) That's unfortunate. I hope Iain comments on this soon, because it means GDC will receive much less testing by other projects. For getting up-to-date binaries, in theory those could be extracted from GDC's Debian packages, which are usually very up-to-date (even Git snapshots are occasionally packaged) - problem there is that I am not sure whether they will work standalone and with the older GLibc on Travis. @crimaniak: If you really want to build with all compilers, there is a workaround for this issue that does not involve you supporting ancient D versions, and that is to actually use Debian's GDC on Travis. I use this excessively for my own projects, mostly though because I need newer system libraries and because I explicitly want to build with the packaged compilers as well. You can use a similar approach and limit it to GDC only, I created a PR for that: https://github.com/crimaniak/json-patch/pull/1 As you can see on https://travis-ci.org/crimaniak/json-patch/jobs/387197216 , your code builds fine with the latest GDC. So, if you want that workaround, please take it, if not it may serve as a reference for others facing the same problem.
Re: GDC on Travis-CI
On Saturday, 2 June 2018 at 03:15:56 UTC, crimaniak wrote: I started to work with Travis-CI, building packages using all three main compilers, and noticed that I have problems with gdc every time and need to tweak code because of many things missing. For example: https://travis-ci.org/crimaniak/json-patch/jobs/386963340 Why this situation with gdc and how best to deal with it? The build log seems to indicate it uses gdc 4.8, while the current version of GDC is 8.1 which is based on the 2.076 frontend. Maybe just updating GDC on Travis will fix this.
Re: Is HibernateD dead?
On Monday, 7 May 2018 at 18:10:14 UTC, Matthias Klumpp wrote: On Saturday, 5 May 2018 at 09:32:32 UTC, Brian wrote: On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: Last commit on https://github.com/buggins/hibernated was almost a year ago So what is the status of HibernateD?Should I use it if I need an ORM? Or would I risk unpatched security risks? You can use Entity & Database library: https://github.com/huntlabs/entity https://github.com/huntlabs/database I've tried both a while back, and they are still inferior to Hibernated (no surprise there, both projects are very new). [...] I've looked at this again today, end Entity now seems to have OneToMany/ManyToMany relations (for 18 days), which is great news! I might need to play with this a little again. In any case, if I do port my D code to another ORM, I want the next port to be the last time I ever do that, because it's a lot of work with quite some risk of breakage. It's also really sad that the existing ORMs don't share a common database abstraction library, but well, different people do things differently. In any case, many thanks to Vadim Lopatin for merging the existing PRs into ddbc and Hibernated for now! That makes life easier already :-)
Re: Is HibernateD dead?
On Monday, 7 May 2018 at 08:26:15 UTC, bauss wrote: On Monday, 7 May 2018 at 06:12:19 UTC, Vadim Lopatin wrote: On Thursday, 3 May 2018 at 20:49:35 UTC, Matthias Klumpp wrote: On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote: On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: [...] If someone is ready to maintain these projects, I can grant privileges for github repositories ddbc, hibernated. Best regards, Buggins I wouldn't mind attempting maintaining them I would help out as much as I can as well (but I lack the skill and time to properly maintain it, especially since I mostly care about my Postgres usecase, and not much about MySQL or ODBC). Having ddbc in dlang-community might actually be a neat thing, to make it very easy for other contributors to merge stuff and easy the maintenance of it. But ultimately that's Bauss' call, as potential future maintainer :-) P.S: @Bauss: While you definitely will want ddbc as solid database abstraction, for Hibernated you might want to change it to be less Java-esque and maybe fit your existing ORM better.
Re: Is HibernateD dead?
On Saturday, 5 May 2018 at 09:32:32 UTC, Brian wrote: On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: Last commit on https://github.com/buggins/hibernated was almost a year ago So what is the status of HibernateD?Should I use it if I need an ORM? Or would I risk unpatched security risks? You can use Entity & Database library: https://github.com/huntlabs/entity https://github.com/huntlabs/database I've tried both a while back, and they are still inferior to Hibernated (no surprise there, both projects are very new). There was even a "fun" SQL injection issue initially. So, while in the long run Entity might be a great option, if you want an ORM that is as complete as Hibernated is today, it's not a solution (I have high hopes for it though).
Re: Is HibernateD dead?
I've written an email to Vadim, maybe we get a reply on the
status of both projects.
On Friday, 4 May 2018 at 07:18:09 UTC, bauss wrote:
[...]
Would it maybe be easier for you to base on ddbc[1] or another
existing abstraction layer for database abstraction?
Ddbc is pretty neat, and even has support for reading structs
directly from the database.
Perhaps, but it'd have to be a forked version as I don't really
want to depend on something that isn't updated regularly.
ddbc's last commit was a year ago.
Yes, at the moment using ddbc and relying on it would mean taking
over some maintenance of it. Ddbc is fairly complete though and
might save you a lot of work, because it already abstracts a lot
of (relational) database systems.
I can't seem to find a license for it though?
It's Boost licensed (BSL-1.0), but probably needs an explicit
LICENSE file.
Maybe we can move ddbc to dlang-community, so more people can
easily commit changes to it (provided it gets accepted there, and
Vadim agrees with that move as well).
Perhaps I will end up having another "optional" dependency to
it as a temporary until I can have a better implementation or
something.
Taking over maintenance of it might be easier than reimplementing
the database abstraction again though.
For Postgres, ddbc worked really well for me, and I assume its
SQLite, MySQL and ODBC drivers are also still working well,
meaning less work for you.
Without ddbc, you'd have to write new abstraction on top of some
other libraries, like dpq2.
The frontend part of postgresql is almost finished, it's just
having the postgresql driver working properly, which is where
it's frozen right now.
Hmm... Does any public code for that exist already that I
could play around with?
Unfortunately, I have a few more unusual requirements for
Postgres, like:
* UUIDs as primary keys, instead of integers
As far as I remember the implementation of @DbId in Diamond,
then it supports whatever type.
Native support for std.uuid.UUID would be neat :-) For Hibernated
I use a mixin to convert a UUID into strings transparently, for
database insertion.
Diamond doesn't care much about what type your primary key is.
I will make sure that's how it function of course, if it
currently doesn't behave like it, but I'm pretty sure it does.
* Ability to register custom datatypes with the ORM (version
numbers in this case, the ORM can view them as text, but the
database has a special type for them)
That could be done with some attribute that lets you handle
columns yourself.
Do you have a good name for it?
I was thinking @DbProxy and then the function would be
something like:
[...]
Registering a new type with Postgres yields a new OID to identify
the type, so I would need a function to tell the Postgres backend
to treat OIDs of a certain number like "text" types. Ideally, I
would also need to annotate entity to set a specific column type,
like:
```
class Entity {
UUID uuid;
@ColumType("versionnumber")
string _version;
}
```
(With the result of CREATE TABLE not setting a "text" type for
the new version column, but a "versionnumber" type instead)
That would do it. For Hibernated, I have Hibernated create the
table initially, and then fire an ALTER TABLE at it afterwards to
change the column type, while at the same time registering the
new type OID with ddbc to be treated as text.
As said, this is a very specific requirement very few people will
have ^^
Much more frequently people will ask for JSONB and JSON type
support for a postgres driver though, I guess. For that,
specifying the column type explicitly could be quite helpful as
well, so switch between JSONB and JSON.
* Obviously the usual ORM stuff, one-to-many, many-to-many,
etc. relations
Yes, relations is one thing I haven't added and I have been
wanting to do it for a while.
I will definitely look into having it added as well.
That's kind of key for an ORM :-) Handling relations manually was
what made me abandon my "I just write raw SQL for everything"
ways, because it gets quite complex and annoying in the long run.
(Obviously not a must-have list, I added support for custom
datatypes to my ddbc fork as well, because it's not really a
feature many people need)
Well, that's kind of the key to most of the development in
Diamond.
I usually add functionality that isn't widely used and in most
cases people implement it themselves ex. the whole diamond.seo
is not usually something a framework has.
I keep an eye on it - at the moment, Vibe.d satisfies all
requirements I have on a web framework, but that might change.
A well integrated ORM would certainly be a game changer, since
Vibe.d is limited to Mongo and Redis only.
Diamond is a neat project, I played around with it about half
a year ago, but didn't test the ORM part at all back then.
It wasn't that good back then and has improved a lot since, as
well many other
Re: Is HibernateD dead?
On Thursday, 3 May 2018 at 21:28:18 UTC, bauss wrote: On Thursday, 3 May 2018 at 18:01:07 UTC, Matthias Klumpp wrote: DiamondMVC looks nice, but I would need PostgreSQL support for sure. Therefore, I think there are three options: 1) Extend the DiamondMVC ORM to support missing features that Hibernated has (maybe make it use ddbc as backend?) 2) Revive Hibernated - contacting Vadim Lopatin would be key for that, and maybe the project could be maintained in the dlang-community organization (although there are competing projects for it...) 3) Find a different D ORM that does the job and expand it to include missing features. Yes, I completely agree with PostgreSQL support. It's really important to me getting that working, as well MSSQL. I was hoping I could find time this weekend to actually do that. Would it maybe be easier for you to base on ddbc[1] or another existing abstraction layer for database abstraction? Ddbc is pretty neat, and even has support for reading structs directly from the database. [1]: https://github.com/buggins/ddbc Perhaps I will end up having another "optional" dependency to it as a temporary until I can have a better implementation or something. The frontend part of postgresql is almost finished, it's just having the postgresql driver working properly, which is where it's frozen right now. Hmm... Does any public code for that exist already that I could play around with? Unfortunately, I have a few more unusual requirements for Postgres, like: * UUIDs as primary keys, instead of integers * Ability to register custom datatypes with the ORM (version numbers in this case, the ORM can view them as text, but the database has a special type for them) * Obviously the usual ORM stuff, one-to-many, many-to-many, etc. relations (Obviously not a must-have list, I added support for custom datatypes to my ddbc fork as well, because it's not really a feature many people need) Diamond is a neat project, I played around with it about half a year ago, but didn't test the ORM part at all back then.
Re: Is HibernateD dead?
On Thursday, 3 May 2018 at 18:52:34 UTC, singingbush wrote: On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: Last commit on https://github.com/buggins/hibernated was almost a year ago So what is the status of HibernateD?Should I use it if I need an ORM? Or would I risk unpatched security risks? Both hibernated and ddbc have had open pull requests for months. It's really frustrating. Oh hey :-) I applied your patches for ddbc and hibernated a to my copy while back, because they weren't merged and fix real issues. There are also other patches floating around, for example people will really want https://github.com/KrzaQ/hibernated/commit/efa38c50effdd77e973b174feea89016b8d1fa1f applied when using hibernated. If there is enough interest, we can maybe provide at least some basic level of maintenance for these projects together, maybe under the dlang-community umbrella or similar. Per adoption guidelines[1], I think the projects are popular enough, but Hibernated is of course not the only D ORM (although a pretty complete one), and the continued maintenance is also not sure, even when PRs finally get reviewed and accepted faster (but that really depends on the library users). In any case, we need to get in contact with buggins. I asked him ages ago about Hibernated on Gitter, but that was probably the worst way to contact him (as he is active on Github, but probably never read that message). [1]: https://github.com/dlang-community/discussions
Re: Is HibernateD dead?
On Thursday, 3 May 2018 at 10:27:47 UTC, Pasqui23 wrote: Last commit on https://github.com/buggins/hibernated was almost a year ago So what is the status of HibernateD?Should I use it if I need an ORM? Or would I risk unpatched security risks? Hah! I was just browsing the forums thinking about the same issue and whether I should ask a question about it. I am using Hibernated in one bigger project, ripping it out at this point would be quite painful and I only ever want to do that if there is a sustainable and actively developed alternative that is comparable in features[1]. Truth is, so far I haven't found any D ORM that compares to Hibernated in terms of supported features and databases. Hibernated also has issues though, at the time I maintain a forked version with changes that I hope to upstream soon - unfortunately, the trivial open pull-request on the project doesn't look promising. DiamondMVC looks nice, but I would need PostgreSQL support for sure. Therefore, I think there are three options: 1) Extend the DiamondMVC ORM to support missing features that Hibernated has (maybe make it use ddbc as backend?) 2) Revive Hibernated - contacting Vadim Lopatin would be key for that, and maybe the project could be maintained in the dlang-community organization (although there are competing projects for it...) 3) Find a different D ORM that does the job and expand it to include missing features. I really don't want to write ORMs in D and I actually lack the skills to do it properly, but I rely pretty heavily on Hibernated and ddbc. So, if anyone has a solution for this, I would help with it for sure. Asking Vadim (buggins) on the state of Hibernated would be the first thing to do, I think. Cheers, Matthias [1]: In fact, when I switched the database backend once in the past from an attempt to not use an ORM to using Hibernated, I was very close to rewriting the whole thing in Python - in D, there are tons of ORMs and database abstraction layers written, but not a single one compares even remotely to the likes of SQLAlchemy. It would be awesome if instead of 5 70% completed projects, we had one 90% complete one.
Re: Using Postgres connection functions
On Saturday, 13 January 2018 at 17:58:14 UTC, Joe wrote: On Saturday, 13 January 2018 at 10:10:41 UTC, Jacob Carlborg wrote: There's a native D library, ddb [1], for connecting to Postgres. Then you don't have to worry about null-terminated strings. There are several D libraries that I would consider "native": derelict-pq, dpq, dpq2 and ddb. The latter perhaps has the distinction that it doesn't use libpq, but rather implements the Postgres FE/BE protocol. That's a bit *too* native for my taste. It means the library maintainer has to keep up with changes to the internal protocol, which although published, the Postgres group doesn't have to maintain compatibility from version to version. For example, they haven't dropped the PQsetdbLogin function even though the PQconnectdb and PQconnectdbParams functions are obviously preferred. OTOH, there used to be an AsciiRow message format in the protocol, that was dropped, unceremoniously (not even mentioned in the release notes). If you are after a good way to use Postgres in a real-world application, I highly recommend ddbc[1] (which also supports other backends). There are a lot of D Postgres bindings out there, and all of them are about 70% completed, but nobody really bothered to make one finished and really good (and well maintained) binding. DDBC is really close to being complete, and contains a few convenience features that make it nice to use in an application. It also is used by Hibernated[2] in case you want an ORM for your app at some point. Both libraries aren't up to tools like SQLAlchemy & Co. from other programming languages, but they are decent. For simple cases, dpq2 & Co. might work well enough as well. In any case, please don't start another Postgres library and consider contributing to one of the existing ones, so that we maybe have one really awesome, 100% complete library at some point. If, on the other hand, your goal is to learn about the low-level Postgres interface and not just to have a Postgres interface for an application you develop, by all means, play with it :-) Cheers, Matthias [1]: https://github.com/buggins/ddbc [2]: https://github.com/buggins/hibernated
Re: Persistent key-value-store for D?
On Wednesday, 26 April 2017 at 17:06:52 UTC, krylon wrote: [...] If I understand what I have read so far correctly, it is possible to access libraries written in C or C++ from D - in that case, I could just use Tokyocabinet directly, but I have not found any pointers on how to do this. Is this a feasible option, and if so, where can I find documentation on how to do this? I can recommend using LMDB[1] which likely does all you want. It also has D bindings[2]. We use it in the AppStream generator with multithreaded parallelization and it is working great so far (although for the usecase of asgen it's not an ideal database choice, but one which makes deployments of the generator really simple). I explored other solutions including Tokyokabinet and LevelDB and LMDB was by far the fastest. Cheers, Matthias [1]: https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database [2]: https://github.com/ximion/appstream-generator/blob/master/src/asgen/bindings/lmdb.d
Re: htod for linux
You may also want to try dstep - I just recently used that tool for the first time, and it worked really well (required a bit of tweaking of the source and result files though, but nothing major). => https://github.com/jacob-carlborg/dstep
Re: GDC options
On Wednesday, 22 March 2017 at 05:47:59 UTC, Sebastien Alaiwan wrote: On Monday, 13 March 2017 at 11:06:53 UTC, Russel Winder wrote: It is a shame that dmd and ldc do not just use the standard GCC option set. Totally agreed. Moreover, funny stuff like "dmd -of" (instead of standard "-o ") breaks automatic Msys path conversion hack (the code translates Unix paths from the command line to Windows paths before the invocation of a non-msys program), which makes it impossible to use dmd under Msys without wrapping it first. pkg-config also is a real pain to use with dmd (the pkg-config's output needs to be post-processed so it has the form "-L-lstuff" instead of "-lstuff"). This is an issue, because it makes it very hard to use write portable makefiles for programs containing D code. Too bad, because the D code is actually platform-independent, and there's been a lot of work in Phobos to make it easy to write such code. D was designed to be binary compatible with the C ABI ; however, having a compiler whose command-line behaves so different from gcc makes it harder to actually work with existing C libs. This is actually the main reason why I almost exclusively use gdc: to have one Makefile, for all platforms, allowing native and cross-compilation with no platform-specific special cases. This is why most of my work in Meson to get D supported is adding weird hacks to translate compiler flags between GNU <-> non-GNU <-> DMD. It sucks quite badly, and every now and then I hit a weird corner case where things break. For example: https://github.com/mesonbuild/meson/commit/d9cabe9f0ca6fb06808c1d5cf5206a7c5158517e Would be amazing if all D compilers would support the GCC flags, like Clang does for C - that would help in removing a lot of hacks (and making Makefiles which work with all compilers). The reason for not using a dmd wrapper is that one might want to use flags specific to a certain compiler.
Re: fPIC Error
On Saturday, 19 November 2016 at 21:14:47 UTC, Charles Hixson wrote: [...] IIRC, LDC didn't have that problem. I don't remember testing gdc. But, yes, it is quite annoying. That's because we can maintain those compilers with the distribution and configure them appropriately to compile with hardening flags and integrate properly with the distro. GDC is an issue here, since AFAIK it doesn't support PIC yet, so for GDC - if it works - there will be some kind of workaround in place (telling the linker to not assume PIC code, I guess). DMD has issues because it's a 3rd-party product - ideally, the compiler should be adjusted to output PIC code by default. You can find more information on this change at https://wiki.debian.org/Hardening/PIEByDefaultTransition
Re: Cannot link with libphobos2.a with GCC 6.2 on Ubuntu 16.10
On Thursday, 13 October 2016 at 17:07:19 UTC, Nordlöw wrote: On Thursday, 13 October 2016 at 17:02:32 UTC, Nordlöw wrote: Am I using the wrong GCC version? Should I use GCC 5 instead? GCC 6.2 is default on 16.10. Compiling DMD with GCC 5 as make -f posix.mak HOST_CXX=g++-5 also fails with same errors. The new toolchains of Ubuntu (and Debian soon too) default to PIE code, so in order to link correctly, the project needs to be compiled with PIE/PIC to work.
How to debug (potential) GC bugs?
Hello! I am working together with others on the D-based appstream-generator[1] project, which is generating software metadata for "software centers" and other package-manager functionality on Linux distributions, and is used by default on Debian, Ubuntu and Arch Linux. For Ubuntu, some modifications on the code were needed, and apparently for them the code is currently crashing in the GC collection thread: http://paste.debian.net/840490/ The project is running a lot of stuff in parallel and is using the GC (if the extraction is a few seconds slower due to the GC being active, it doesn't matter much). We also link against a lot of 3rd-party libraries and use a big amount of existing C code in the project. So, I would like to know the following things: 1) Is there any caveat when linking to C libraries and using the GC in a project? So far, it seems to be working well, but there have been a few cases where I was suspicious about the GC actually doing something to malloc'ed stuff or C structs present in the bindings. 2) How can one debug issues like the one mentioned above properly? Since it seems to happen in the GC and doesn't give me information on where to start searching for the issue, I am a bit lost. 3) The tool seems to leak memory somewhere and OOMs pretty quickly on some machines. All the stuff using C code frees resources properly though, and using Valgrind on the project is a pain due to large amounts of data being mmapped. I worked around this a while back, but then the GC interfered with Valgrind, making information less useful. Is there any information on how to find memory leaks, or e.g. large structs the GC cannot free because something is still having a needless reference on it? Unfortunately I can't reproduce the crash from 2) myself, it only seems to happen at Ubuntu (but Ubuntu is using some different codepaths too). Any insights would be highly appreciated! Cheers, Matthias [1[: https://github.com/ximion/appstream-generator
Proper way to work around `Invalid memory operation`?
Hello!
I have a class similar to this one:
```
class Dummy
{
private:
string tmpDir;
public:
this (string fname)
{
tmpDir = buildPath ("/tmp", fname.baseName);
std.file.mkdirRecurse (tmpDir);
}
~this ()
{
close ();
}
void close ()
{
if (std.file.exists (tmpDir))
std.file.rmdirRecurse (tmpDir);
}
}
```
When the GC calls the classes destructor, I get a
`core.exception.InvalidMemoryOperationError@/<...>/ldc/runtime/druntime/src/core/exception.d(693):
Invalid memory operation`
Looks like rmdirRecurse tries to allocate with the GC, and the GC
doesn't like that.
Is there any good way to get the temporary directory deletet
automatically when the object is freed?
At time, I work around this bug by calling close() manually at
the appropriate time, but this feel like a rather poor solution.
Cheers,
Matthias
