Mocking framework mockeD
I'm happy to announce a new mocking library developed at Funkwerk. Funkwerk maintained dmocks for some time, but dmocks had some design limitations, among others, that it relies on dynamic casts and runtime type information (by use of typeid). It was possible to construct expectations that aren’t really well-typed. And if dmocks doesn’t catch such problems internally, they cause runtime errors that are difficult to track. Over time we fixed a bunch of related bugs, but the question raised, whether we can generate more code since the most information needed to build a mock is given at compile-time. After the initial draft and some internal testing, I finished the first full-featured version and am releasing mockeD 1.x. - mockeD catches type errors at compile-time. - has almost the same API as dmocks - supports only mocking by inheritance. Structs, final classes, final methods aren’t mockable. - mockeD provides a separate stub API. Stubs can everything mocks can, but the calls on stubs aren’t verified at the end. https://github.com/funkwerk/mocked
Re: Beta 2.090.0
On Sunday, 22 December 2019 at 18:51:45 UTC, berni44 wrote: On Sunday, 22 December 2019 at 15:23:32 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.090.0 release, ♥ to the 48 contributors. I'm wondering, why I'm listed twice there (as Bernhard Seckinger and as berni44). IMHO berni44 should not have been listed there... Do I have to change something in my git settings to get this right? Probably differen email addresses. You can set an email address locally for the repository in .git/config. Or just add an alias: https://github.com/dlang/tools/blob/master/.mailmap
Re: Redis client hunt-redis RC1 released
On Saturday, 27 July 2019 at 09:07:13 UTC, Eugene Wissner wrote: On Saturday, 27 July 2019 at 06:08:34 UTC, zoujiaqing wrote: On Thursday, 25 July 2019 at 20:19:53 UTC, ag0aep6g wrote: [...] Thanks. But we use other language to implementation. It doesn't matter. It is all about intellectual property, algorithms and the structure. The language is the least important factor. If you translate "The Good Person of Szechwan" into English, you can't just claim to be the author.
Re: Redis client hunt-redis RC1 released
On Saturday, 27 July 2019 at 06:08:34 UTC, zoujiaqing wrote: On Thursday, 25 July 2019 at 20:19:53 UTC, ag0aep6g wrote: [...] Thanks. But we use other language to implementation. It doesn't matter. It is all about intellectual property, algorithms and the structure. The language is the least important factor.
Re: Release Candidate [was: Re: Beta 2.087.0]
On Wednesday, 3 July 2019 at 05:13:34 UTC, Andre Pany wrote:
Hi,
for this coding
```
import std;
void main()
{
assert("abc123".all!(c => (c.isAlpha && c.isUpper == false)
|| c.isDigit));
}
```
2.087.0 RC throws an error:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\searching.d(123): Error: static
assert: "_lambda isn't a unary predicate function for range.front"
unary.d(5):instantiated from here: all!string
Is this a bug?
Kind regards
André
Both, std.uni and std.ascii have isAlpha and isUpper.
Re: Release Candidate [was: Re: Beta 2.087.0]
On Wednesday, 3 July 2019 at 05:13:34 UTC, Andre Pany wrote:
Hi,
for this coding
```
import std;
void main()
{
assert("abc123".all!(c => (c.isAlpha && c.isUpper == false)
|| c.isDigit));
}
```
2.087.0 RC throws an error:
C:\D\dmd2\windows\bin\..\..\src\phobos\std\algorithm\searching.d(123): Error: static
assert: "_lambda isn't a unary predicate function for range.front"
unary.d(5):instantiated from here: all!string
Is this a bug?
Kind regards
André
import std.ascii;
import std.algorithm;
void main()
{
assert("abc123".all!(c => (c.isAlpha && c.isUpper == false)
|| c.isDigit));
}
Re: Beta 2.086.1
On Thursday, 13 June 2019 at 09:06:30 UTC, Seb wrote: On Thursday, 13 June 2019 at 03:48:05 UTC, Eugene Wissner wrote: On Wednesday, 12 June 2019 at 23:51:39 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.086.1 point release, ♥ to the 20 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.086.1.html As usual please report any bugs at https://issues.dlang.org -Martin Mathis Beer and FeepingCreature are the same person. PRs are welcome to: https://github.com/dlang/tools/blob/master/.mailmap I always forget where is the alias list :) Mea culpa
Re: Beta 2.086.1
On Thursday, 13 June 2019 at 03:48:05 UTC, Eugene Wissner wrote: On Wednesday, 12 June 2019 at 23:51:39 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.086.1 point release, ♥ to the 20 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.086.1.html As usual please report any bugs at https://issues.dlang.org -Martin Mathis Beer and FeepingCreature are the same person. And "Suleyman Sahmi" is listed twice.
Re: Beta 2.086.1
On Wednesday, 12 June 2019 at 23:51:39 UTC, Martin Nowak wrote: Glad to announce the first beta for the 2.086.1 point release, ♥ to the 20 contributors. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.086.1.html As usual please report any bugs at https://issues.dlang.org -Martin Mathis Beer and FeepingCreature are the same person.
Re: dlang.ru is updated
On Saturday, 18 May 2019 at 01:24:35 UTC, Vladimir Panteleev wrote: On Friday, 17 May 2019 at 06:25:23 UTC, Suliman wrote: Waterfox 56.2.9 Oh! I used on my site new js future. It will work after updating browser. Waterfox 56.2.9 is currently the latest version of Waterfox. There is no newer version to update to. Waterfox uses an older version of Gecko (because it is a Firefox fork), but it's not THAT old. Did you check browser support at caniuse.com ? And, what feature is so necessary to display a HTML web page? I get "Uncaught ReferenceError: globalThis is not defined" in an older Chrome. globalThis isn't standard yet and it has really bad browser support: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/globalThis
Re: dlang.ru is updated
On Friday, 17 May 2019 at 06:46:06 UTC, DanielG wrote: On Thursday, 16 May 2019 at 12:25:52 UTC, Suliman wrote: P.S. site is blocked by most of russian internet-providers by RKN Why is that? https://en.wikipedia.org/wiki/Federal_Service_for_Supervision_of_Communications,_Information_Technology_and_Mass_Media
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
- Memcmp, memcpy, memmove and memset are named equal, copy, copyBackward and fill respectively. I just wanted to create native implementations that are bit safer than their C counterparts. So they do the same job, but accept void[] instead of pointers. There are also templated functions with the same names, that work with ranges. I‘m not very comfortable with GCC‘s inline asm and it doesn‘t support naked asm as DMD does, so I put asm in the .S files and compile them separately. But I‘m fine with inline asm too. A problem with the inline asm is that it should be written in several versions since DMD uses different calling conventions (unless we use extern(C)) and GDC and LDC use different asm syntax. Tanya contains pretty much stuff now and I‘m just thinking to split it in a smaller parts (of a reasonable size), that are probably interesting for other people, who is ready to contribute, so I don‘t have to maintain everything myself. I don‘t know exactly what goes into this more „low-level“ library, we can always talk about it. - OS API Not sure if it belongs to the scope of utilD. Some time ago it became clear to me, that while C has functions for dynamic memory management, it uses them internally very seldom. Instead it lets the user to allocate the memory. So there functions like: char *if_indextoname(unsigned int ifindex, char *ifname); that take an output buffer as the last argument. The same can be done with output ranges in D, so these system functions can be rewritten in D with a better interface. Whereby I should say that tanya‘s range definitions differ from Phobos. - meta Another thing probably interesting for utilD library is meta-programming. Tanya has „tanya.meta“ package which contains templates similar to to std.traits and std.meta + some nice extras like Union/Intersection/Difference working on sets of types, that are inspired by Boost Hana. This part is completely independent (from Phobos and the rest of tanya) and can even be a separate library.
Re: utiliD: A library with absolutely no dependencies for bare-metal programming and bootstrapping other D libraries
On Sunday, 5 May 2019 at 03:45:41 UTC, Mike Franklin wrote: In an attempt to put some impetus behind an idea that I've proposed multiple times on the forum, I've resurrected my utiliD repository: https://github.com/JinShil/utiliD I decided to resurrect the repository after this brief discussion: https://forum.dlang.org/post/bjycwgrifumsfrhpr...@forum.dlang.org The idea behind the library is that it would not depend on druntime, phobos, C standard library, or anything else but would still offer many of the features that those libraries provide. To utilize the library, one would only need a D compiler. It could be used in bare-metal programming, -betterC builds, or as a fundamental utility library for implementing DMD, druntime, and phobos themselves. It's what I envision as a potential seed for Andrei's opt-in continuum (https://forum.dlang.org/post/q7j4sl$17pe$1...@digitalmars.com). I don't know what will ultimately happen with this library, if anything, but even if all it does is facilitate brainstorming of ideas, or as the genesis of some better idea, it will be a success. I don't have much time to work on it right now, as I'm currently preoccupied fixing the compiler and the druntime to make something like utiliD possible, but if others grok the idea and want to help make it a reality, your help is most welcome. Also, if any of you have already started something with the same goals, I'll be happy to drop this repository and join you. You can find me on Slack and Discord using the handle JinShil if you wish to have a dialog about this. Mike Hi Mike, you may remember that I'm working on a library named "tanya" (https://github.com/caraus-ecms/tanya). It is now almost phobos-free and I reimplemented some routines from libc for x86-64 linux. Ideally I'd like to get rid of libc for some platforms. While the library isn't interesting for you since it's too high-level, it could be based on something like utilD. So, as for me, I'd be very much interested in collective effort in this direction and can contribute.
Blog post: Memory management in containers
https://www.caraus.io/posts/2019-03-23-memory-in-containers.html The article doesn't pretend to be complete in any way, but attempts to answer some questions I had a few years ago since I was unable to find the anwers at one place.
Re: Add D front-end, libphobos library, and D2 testsuite... to GCC
On Monday, 29 October 2018 at 04:57:50 UTC, Neia Neutuladh wrote: On Mon, 29 Oct 2018 03:43:49 +, Mike Parker wrote: Congratulations are in order for Iain Buclaw. His efforts have been rewarded in a big way. Last Friday, he got the greenlight to move forward with submitting his changes into GCC: Awesome! What frontend version is this, out of curiosity? 2.076. Note that this is not the latest GDC version; GDC is up to date and follows DMD master. A newer frontend should get into GDC 10.
GCC: Submission of D Front End, next round
Just reposting here two links Johannes left in the Slack: https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00931.html "The D Language Front-End Is Trying Now To Get Into GCC 9 Going on for a while now have been D language front-end patches for GCC to allow this programming language to be supported by the GNU Compiler Collection. It's been a long battle getting to this state but it looks like it soon might be mainlined. Last June was the approval by the GCC Steering Committee to allow D support in GCC. While the committee approved of its addition, the D language front-end didn't end up getting merged in time for the GCC 8 stable release that took place earlier this year." [1] [1] https://www.phoronix.com/scan.php?page=news_item=GCC-9-D-Language-Patches phoronix.comphoronix.com
Re: GDC with D frontend 2.081.2
On Tuesday, 28 August 2018 at 06:18:28 UTC, Daniel Kozak wrote: On Mon, Aug 27, 2018 at 7:55 PM Eugene Wissner via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: On Monday, 27 August 2018 at 17:23:04 UTC, Arun Chandrasekaran wrote: > 1. It would be good to print the DMD frontend version with > `gdc --version`. It is helpful in reporting bugs. LDC does > this. > Unfortunately it doesn't seem to be possible. GCC doesn't allow to change --version output: https://bugzilla.gdcproject.org/show_bug.cgi?id=89 This is not true, right now on archlinux if you type gdc --version it will display d frontend version https://bugzilla.gdcproject.org/show_bug.cgi?id=89#c1 Is it set with --with-pkgversion? The same information will be displayed for gcc and g++ then. It is not always desirable if you ship the compiler as a whole (with libtool etc).
Re: GDC with D frontend 2.081.2
On Monday, 27 August 2018 at 17:23:04 UTC, Arun Chandrasekaran
wrote:
1. It would be good to print the DMD frontend version with `gdc
--version`. It is helpful in reporting bugs. LDC does this.
Unfortunately it doesn't seem to be possible. GCC doesn't allow
to change --version output:
https://bugzilla.gdcproject.org/show_bug.cgi?id=89
Other compilers like gccgo print the same. It can be probably
useful to introduce an additional frontend command line option.
2. I see a file dub_platform_probe-UUID.s getting created in
the root dir when building with GDC and not with DMD/LDC.
Partially looks like a dub bug:
https://github.com/dlang/dub/issues/576
But anyway it is wrong that they are created in the project
directory; I suppose I miss some build options.
3. Multiple definition error. Logs:
https://bpaste.net/show/7b12dfccceb1 This doesn't seem to be a
problem when building with DMD (v2.081.1) / LDC (1.9.0)
"dependencies" : {
"darg": "~>0.0.4",
"painlessjson": "~>1.3.5",
"requests": "~>0.8.3"
}
Have to test it first. Thanks.
Re: GDC with D frontend 2.081.2
On Saturday, 25 August 2018 at 20:59:56 [...] Thanks for supporting us on Arch, Daniel!
GDC with D frontend 2.081.2
As some of you may know D frontend was merged into GDC some time ago and is up to date. D version currently supported by GDC is 2.081.2 and it can be found in "gdc-7" and "gdc-8" branches. I will say a bit more about GDC development and development plans later. I prepared GDC/GCC 7.3.0 binaries for x86-64 Linux built on Ubuntu 18.04: https://download.dlackware.com/gdc/gdc-7.3.0_2.081.2-linux-x86_64.tar.xz I’m not a regular Ubuntu user, and built GDC in a VM, so don't blame me (too much) if something doesn’t work, but let me know anyway. For testing I've used a minimal Ubuntu installation and had to install only "libc-dev" package. The package includes gcc, g++, gdc and standard GNU tools, but no D tools like dub. I still need some time to automate the building, then I can build for more platforms and provide some core tools. We support several GCC versions and we still support C++-frontend (D version: 2.076). The reason for this is that C++-frontend should be merged into the next GCC version (GCC 9), then it can be built without another D compiler. D frontend goes into GCC 10 and can be built with GCC 9, so GCC can be bootstrapped without external compilers and can be used to bootstrap other D compilers. Current branch model. There are 2 "master" branches: master and stable. master contains D frontend and follows DMD master (we'll see if we can update every week or every two weeks). stable contains C++ frontend which doesn't get new D features anymore but of course we merge bug fixes from master. Both follow GCC master (master is updated weekly to GCC snapshots, stable from time to time). stable has 4 derivates: gdc-8-stable, gdc-7-stable, gdc-6-stable and gdc-5-stable. It seems to be a lot, but the last merge from stable was really trivial, so the most work is done on the master derivates: "gdc-8" and "gdc-7" branches. These two follow DMD stable and contain stable D releases.
Re: Beta 2.079.0
On Wednesday, 21 February 2018 at 10:24:41 UTC, Paolo Invernizzi wrote: On Wednesday, 21 February 2018 at 10:15:48 UTC, Jonathan M Davis wrote: On Wednesday, February 21, 2018 10:04:01 Kagamin via Digitalmars-d-announce wrote: On Tuesday, 20 February 2018 at 22:54:43 UTC, H. S. Teoh wrote: > Yeah, personally I'd avoid writing it that way too. There's no other way to use this feature though. Some of us think that it's a bad feature and have no intention of ever using it, though once it's in the language, we all have to worry about dealing with code that does use it. - Jonathan M Davis Was there a DIP for that? /Paolo https://issues.dlang.org/show_bug.cgi?id=13855 https://github.com/dlang/dmd/pull/6589
Re: Release D 2.078.2
On Monday, 19 February 2018 at 10:08:37 UTC, Martin Nowak wrote: On 02/17/2018 06:52 AM, Eugene Wissner wrote: On Friday, 16 February 2018 at 11:25:42 UTC, Martin Nowak wrote: On 02/10/2018 09:17 AM, Thomas Mader wrote: https://github.com/dlang/dub/releases/latest doesn't point to 1.7.2. Out of curiosity, do you have a strong use-case to install/update dub separately of the compiler? I'm shipping dub (as a part of d-tools package) separately from the compiler for Slackware Linux. This way it can be built with the compiler of choice: dmd, gdc or ldc. It doesn't always make sense to ship dub with every compiler since you can use --compiler option. And the compiler dub is built with, is the default compiler to build dub projects. You have any idea for a more sensible default compiler? IIRC dub now supports any compiler out of the box, but indeed the search order depends on it's host compiler. The main goal of shipping dub with the compiler was to simplify distribution and increase it's usage. Would you say this goal is met, or should we consider to release dub binaries separately but in sync with dlang releases. It would be great if dub had some global configuration file /etc/dub.conf (or dub.json) for example, where the defaults can be set (I don't know if something like this already exists), or maybe /etc/d/ where dub.conf and dmd.conf can be put - it seems a bit cleaner to me. I think that shipping dub and dmd together is generally a good thing. I'm using Ubuntu at work and I'm pretty happy that I can just download one package and get the main d tools installed together. One of the things I hate about the most deb/rpm based distributions, is that the most programs are split in a lot of small packages. As for Slackware I want to switch to building dmd from source anyway, so I think it doesn't matter a lot for maintainers that binary packages have dub as well. And for normal people it's just simpler to install everything together as you said.
Re: Beta 2.079.0
fold is added to std.parallelism.TaskPool std.parallelism.TaskPool.fold and reduce point to https://dlang.org/phobos-prerelease/std_parallelism_TaskPool.html#.fold and https://dlang.org/phobos-prerelease/std_parallelism_TaskPool.html#.reduce respectively, that can't be found, 404.
Re: Release D 2.078.2
On Friday, 16 February 2018 at 11:25:42 UTC, Martin Nowak wrote: On 02/10/2018 09:17 AM, Thomas Mader wrote: https://github.com/dlang/dub/releases/latest doesn't point to 1.7.2. Out of curiosity, do you have a strong use-case to install/update dub separately of the compiler? I'm shipping dub (as a part of d-tools package) separately from the compiler for Slackware Linux. This way it can be built with the compiler of choice: dmd, gdc or ldc. It doesn't always make sense to ship dub with every compiler since you can use --compiler option. And the compiler dub is built with, is the default compiler to build dub projects.
Re: Beta 2.076.1
On Monday, 9 October 2017 at 18:56:13 UTC, Martin Nowak wrote: On 10/07/2017 03:20 PM, Eugene Wissner wrote: But please consider something different than github as alternative. GitHub doesn't guarantee that it always generates the same tarball for the same commit/release, so the checksum can change and the downloaded tarball looks corrupted, though it has absolutely the same content. Ah good to know, indeed seems to be a problem for GH's archive endpoints? Would of course be a nogo for distro build receipts. https://github.com/libgit2/libgit2/issues/4343#issuecomment-328631745 I had this problem about two weeks ago. As an example.. Slackware is a half-binary, half-source based Linux. The core system is provided as binary packages and the most users build other programs from slackbuilds.org which provides a huge collection of third-party packages as automated build scripts (but they don't keep the sources, only scripts that build a package from the source). There are also automation tools to compile all the dependencies if needed. It is slightly similar to how freebsd ports work. Such a tool has to verify that the downloaded source is not corrupted and it is done with md5. Actually I think that it can be a problem for many smaller linux distributions that are community-driven and not backed by commercial organizations and don't have the power to keep all sources themselves like debian does. GitHub breaks the archives very very seldom but if it happens it is very painful
Re: GDC in Slackware and a bit about GDC development
On Monday, 9 October 2017 at 08:10:41 UTC, Iain Buclaw wrote: On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote: On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote: That would almost certainly only happen if you were using a different druntime. Check where your import modules are coming from, they probably aren't gdc's. Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: importobject(/usr/include/d/object.d) importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) importcore.stdc.config (/usr/include/d/core/stdc/config.d) importcore.stdc.stddef (/usr/include/d/core/stdc/stddef.d) semantic test entry main test.d import__entrypoint (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) "/usr/include/d/core" is the druntime of dmd. gdc's one is in: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, then the example above compiles. I wasn't able to find how to change it. I'll probably change the runtime and phobos paths for dmd and move gcc's D directories into their old place. It might be a configure flag to change that. Though I think at least Archlinux just applies local patches to all compilers to point the system directory explicitly to different locations. I'd say it's a dmd package bug for putting dmd sources in /usr/include/d, when this should be reserved for more general D application libraries. I've chosen "/usr/include/d" for dmd since freebsd seems to use it and IIRC the debian-family aswell (I'm maintaining dmd package aswell). I compared installation directories for c/c++ and gcc include files are in "/usr/include/c++/5.3.0/", llvm: "/usr/include/llvm". So the appropriate way would be probably just to put dmd stuff in "/usr/include/dmd". Maybe I'll look into it later again. At least I have a quick solution for now to get both compilers work on one system.
Re: GDC in Slackware and a bit about GDC development
On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote: That would almost certainly only happen if you were using a different druntime. Check where your import modules are coming from, they probably aren't gdc's. Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got: importobject(/usr/include/d/object.d) importcore.stdc.stdarg (/usr/include/d/core/stdc/stdarg.d) importcore.stdc.stdlib (/usr/include/d/core/stdc/stdlib.d) importcore.stdc.config (/usr/include/d/core/stdc/config.d) importcore.stdc.stddef (/usr/include/d/core/stdc/stddef.d) semantic test entry main test.d import __entrypoint (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di) "/usr/include/d/core" is the druntime of dmd. gdc's one is in: /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd, then the example above compiles. I wasn't able to find how to change it. I'll probably change the runtime and phobos paths for dmd and move gcc's D directories into their old place.
Re: Beta 2.076.1
On Saturday, 7 October 2017 at 12:45:30 UTC, Martin Nowak wrote: On Sunday, 1 October 2017 at 17:36:12 UTC, Marco Leise wrote: Other than that I'm happy with the package, as it provides the man pages, pre-built HTML documentation and a binary to bootstrap dmd on systems that lack a D compiler. (The use case being compilation from source for Gentoo Linux.) I won't reorganize the folder structure in a point release. But thanks for pointing out that this needs a fix. Would getting the sources as a separate download (or just from github) be a feasible alternative. But please consider something different than github as alternative. GitHub doesn't guarantee that it always generates the same tarball for the same commit/release, so the checksum can change and the downloaded tarball looks corrupted, though it has absolutely the same content.
Re: GDC in Slackware and a bit about GDC development
On Saturday, 23 September 2017 at 20:34:51 UTC, Iain Buclaw wrote:
On 23 September 2017 at 21:45, Eugene Wissner via
Digitalmars-d-announce <digitalmars-d-announce@puremagic.com>
wrote:
GDC looks pretty nice. I had only one problem: I got a linking
error if I
use core.stdc.stdarg; not sure if it is my failure or a bug.
But I could
build my library and run tests. Pretty nice.
What's the linker error?
Here is the code, test.d:
import core.stdc.stdarg;
void format(char[] buf, ...)
{
va_list va;
va_start(va, buf);
va_end(va);
}
void main()
{
}
$ gdc test.d
/tmp/ccwm5f8o.o: In function `_D4test6formatFAaYv':
test.d:(.text+0x114): undefined reference to
`_D4core4stdc6stdarg6va_endFNbPS4core4stdc6stdarg13__va_list_tagZv'
collect2: ld returned 1 exit status
Looks good. A simpler GCC frontend would be
https://github.com/giuseppe/gccbrainfuck
But without the great explanations :)
GDC in Slackware and a bit about GDC development
Hi, lately I finally got some time to create GDC package for Slackware Linux [1]. Slackware ships gcc 5.3.0, therefore GDC package is the latest version from "gcc5" branch. It has phobos and druntime 2.076.0-b1 and the frontend somewhere between 2.075 and 2.076. Since Slackware packages are built by plain shell scripts, I thought I make an announce, because it can be used as a reference by people, who whant to build the latest GDC from source. The only difference between Slackware and mainstream Linux distributions (Ubuntu, Debian) I'm aware of, is that x86-64 Slackware isn't multiarch by default. The package is on slackbuilds.org [2]. The direct link to the build script is [3]. GDC looks pretty nice. I had only one problem: I got a linking error if I use core.stdc.stdarg; not sure if it is my failure or a bug. But I could build my library and run tests. Pretty nice. I also would like to point to the "GCC tiny" tutorial [4]. The tutorial tells how to create a GCC frontend for a Pascal-like language, tiny. And it is a great thing to learn about GCC internals for someone who wants to help with GDC development, the best one I could find in the last months. [1] http://www.slackware.com/ [2] https://slackbuilds.org/repository/14.2/development/gcc-d/ [3] https://slackbuilds.org/slackbuilds/14.2/development/gcc-d/gcc-d.SlackBuild [4] http://thinkingeek.com/gcc-tiny/
Re: New library: open multi-methods
On Sunday, 16 July 2017 at 17:24:17 UTC, Jean-Louis Leroy wrote: Hello, TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md for an explanation of what open multi-methods are, if you are not familiar with the idea.You may also want to read my article on Code Project https://www.codeproject.com/Articles/635264/Open-Multi-Methods-for-Cplusplus11-Part-1 Earlier this year I attended Ali Çehreli's talk at C++ Now. He did a good job: I walked out with the desire to learn about D and see how it measures up against C++, especially in terms of meta-programming and language extensibility. The first programming language I learned is Forth and I did some Lisp programming, so as you can imagine, my expectations are high. As an experiment, I decided to try to port parts of my yomm11 library to D. The experience turned out to be pleasant and I ended up writing a full implementation, with some friendly help from Ali and others in the Learn forum. I think that what I have now is good enough to show. The git repo is here https://github.com/jll63/methods.d and I will post a package to the registry soon. If you have the inclination, feel free to review and comment. This is my very first D project and I certainly have missed some idioms and been clumsy at times. Jean-Louis Leroy You may want to use ```d in your code samples in the README to highlight it.
Re: Beta 2.075.0-b4
On Monday, 10 July 2017 at 13:44:22 UTC, Martin Nowak wrote: Fourth beta for the 2.075.0 release. Comes with more fixes for dmd, phobos, and installer: https://github.com/dlang/dmd/compare/v2.075.0-b2...v2.075.0-b4 https://github.com/dlang/phobos/compare/v2.075.0-b2...v2.075.0-b4 https://github.com/dlang/installer/compare/v2.075.0-b2...v2.075.0-b4 Due to the amount of changes the beta was prolonged, new targeted release date is Jul 16. Downloads and changelog here: http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.075.0.html Please report any bugs at https://issues.dlang.org. - -Martin The ChangeLog link is: http://dlang.org/changelog/2.075.0_pre.html
Re: Life in the Fast Lane (@nogc blog post)
On Saturday, 17 June 2017 at 08:51:04 UTC, Mike Parker wrote: On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov [ZombineDev] wrote: The right answer is three fold: A) Examples of idiomatic D code - generic functions agnostic about the memory management strategy like range algorithms; B) Having solid tools at the language-level for implementing correct and relatively easy-to-use library primitives like smart pointers and containers - @safe + pure + scope. C) Maintaining a list of functions/modules/third-party libraries that are usable in @nogc land. But most of all, the focus should be on productivity and ease-of-use, because otherwise people tend to get the impression: TL;DR this is too complicated for me -> I can't use D without the GC -> Using D without the GC is not feasible. Thanks! I agree that we need a range of posts on the GC. That's the whole point of the series. I have a set of posts I can write on topics within my current realm of knowledge, or that I can beef up on when the time comes, but beyond that I'm not the right guy to author some of the posts that need to be written. I haven't familiarized myself with all the corners, nor have I written any code that required me to push the boundaries or explore the possibilities. A while back, I posted an announcement here explaining my goals with the GC series and asking for contributors. Aside from Atila's automem post, I haven't gotten any takers yet. I can, if need be, eventually write many of the posts I'd like to have, but that requires making time to familiarize myself with the topics. Such posts will also compete with those I plan to write on other topics. So, in the interest of saving me a bit of time, I invite you and anyone who's willing to share their experiences and expertise with the GC. I'll happily publish any post that demonstrates allocation strategies, lifetime management, optimizations, or just generally helps to clear up misconceptions. Hm. In my personal projects I'm using D exclusively as a high-level C, so without the GC. I have also Unique and RefCounted, that are very new and not so well tested. On the other hand I've written a good set of containers, that are completely @nogc and are different from std and EMSI containers. I would be interested to write a few lines about container usage, why not built-in arrays and so on. But I should say I need some time, I have currently enough to write at the semester's end :)
Re: The DLang Tour translated into Russian
On Thursday, 15 June 2017 at 18:19:35 UTC, Murzistor wrote: On Thursday, 15 June 2017 at 16:42:08 UTC, Eugene Wissner wrote: Здесь английская версия с описанием процесса: https://github.com/dlang-tour/english/blob/master/README.md русская: https://github.com/dlang-tour/russian/blob/master/README.md Английскую правку приняли, а для русской написано: This branch has no conflicts with the base branch Ну как просмотрят, думаю, примут :)
Re: The DLang Tour translated into Russian
On Thursday, 15 June 2017 at 16:22:53 UTC, Murzistor wrote: On Thursday, 15 June 2017 at 09:46:14 UTC, Dmitry wrote: Создайте pull request'ы к английской и русскоязычной версии, пожалуйста. Понятия не имею, как это делается. Если что, по-английски читаю, вроде... Здесь английская версия с описанием процесса: https://github.com/dlang-tour/english/blob/master/README.md русская: https://github.com/dlang-tour/russian/blob/master/README.md И еще дополнительная информация: https://github.com/dlang-tour/core/blob/master/CONTRIBUTING.md
Re: Getters/setters generator
On Tuesday, 13 June 2017 at 21:49:53 UTC, jmh530 wrote:
On Tuesday, 13 June 2017 at 20:45:34 UTC, jmh530 wrote:
Fair point. I just was playing around with it today and was
like, oh that's pretty easy. It was only when I was trying to
see if anyone else had done anything like this that I came
across your project.
I was just looking at the code in the package. There was an
earlier discussion on predicates. If you changed the
Read/RefRead/etc structs to be something like below, then the
user could add in a string of the assert. It's not really all
that elegant, but I think you should be able to get it to work.
struct Read
{
string visibility = "public";
string constraint = void;
}
My ideal was to get something working where the lower and upper
bounds were actual values, so you didn't have to pass the
string, but I can see how that gets complicated. One problem I
ran into is that you can't really make a struct templated in an
optional way. For instance, the following won't compile
(ignoring the complexity of making the asserts > or >=):
struct Read(T = void)
{
string visibility = "public";
static if (!is(T == void)) {
T lower;
T upper;
}
}
void main()
{
Read read;
}
I think that predicates aren't predicates for specific types
(like lower/upper for arithmetic types), but generic predicates
that could replace in/out constraints. For example lower/upper
boundaries could be expressed then as "x >= a && x < b".
Now it isn't clear what should happen if the predicate doesn't
hold (do we use enforce and throw an exception or assert and
throw an error). Ok, it can be solved with template parameter for
the GenerateFieldAccessors mixin).
String constraints are imho ugly and error prone. For example I
personally don't use alogrithms like sort with string predicates,
but only with lambdas.
Maybe it is possible to pass a lambda to the struct that gets a
value of the member and evaluetes to a boolean - I haven't tested
it. But even with a lambda it doesn't look that cool:
@ConstRead @Write(ref x => x > 0 && x < 10)
Re: Getters/setters generator
On Tuesday, 13 June 2017 at 19:31:28 UTC, jmh530 wrote:
On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote:
What are properties if not "getters" and "setters"? From the
original post: "It would generate 2 methods "num": one to set
num_ and one to get its value."
Two methods named "num". No "get" or "set" in sight.
Sorry to bump, but it also isn't hard to use mixins to write
more generic get/set.
import std.stdio : writeln;
struct Foo
{
private int a;
private int b;
void set(string variable)(int x) @property
{
mixin(variable ~ " = x;");
}
int get(string variable)() @property
{
return mixin(variable);
}
}
void main()
{
Foo foo;
foo.set!("a")(1);
foo.set!("b")(2);
writeln(foo.get!("a"));
writeln(foo.get!("b"));
}
I suppose the errors will be more cryptic, since you don't check
if the string referers to an existing member.
You provide only get/set that return by value. So you may need to
generate getters/setters for const values, for ref values, for
const ref values... And it would result in much more code for
every object.
Re: The DLang Tour translated into Russian
On Sunday, 11 June 2017 at 04:50:55 UTC, Dmitry wrote: On Saturday, 10 June 2017 at 17:50:52 UTC, Eugene Wissner wrote: Может быть: "В стандартной поставке D есть компилятор dmd, инструмент для запуска D программ "на лету", rdmd, и пакетный менеджер dub. ? Лично мне "на лету" не говорит ничего, только куча вопросов появляется. P.S. Точку добавил Возможно. Меня по большей части беспокоило словосочетание "скрипт-подобный инструмент". Насколько я понимаю речь идет о инструменте для запуска скрипт-подобных D программ. Но и в английской версии говорится "a script-like run tool", поэтому перевод точный. Может я читаю неправильно.. В любом случае, выглядит солидной работой. Спасибо за труд!
Re: The DLang Tour translated into Russian
On Saturday, 10 June 2017 at 17:20:14 UTC, Stanislav Blinov wrote: Hi everyone! We're happy to announce that as of today, the Russian translation of the DLang Tour chapters is available here: https://tour.dlang.org/tour/ru/welcome/welcome-to-d , and of course via the language selection page: https://tour.dlang.org/tour/en/welcome/languages Hopefully, this small step helps spread D to a wider audience. If you can read Russian, please take a peek yourselves and tell your friends. And of course, critique, suggestions and fixes are welcome. From myself, I'd like to say a huge Thank You to the DLang Tour team, all the authors involved with the original chapters and examples; Sebastian Wilzbach for a warm welcome and support; El-lin for solid advice; and Dmitry, for his keen eye, patience, and thoroughness during review. И еще вот это предложение мне кажется слишком сложным: "В стандартной поставке D есть компилятор dmd, скрипт-подобный инструмент для запуска rdmd и пакетный менеджер dub." Может быть: "В стандартной поставке D есть компилятор dmd, инструмент для запуска D программ "на лету", rdmd, и пакетный менеджер dub. ?
Re: The DLang Tour translated into Russian
On Saturday, 10 June 2017 at 17:20:14 UTC, Stanislav Blinov wrote: Hi everyone! We're happy to announce that as of today, the Russian translation of the DLang Tour chapters is available here: https://tour.dlang.org/tour/ru/welcome/welcome-to-d , and of course via the language selection page: https://tour.dlang.org/tour/en/welcome/languages Hopefully, this small step helps spread D to a wider audience. If you can read Russian, please take a peek yourselves and tell your friends. And of course, critique, suggestions and fixes are welcome. From myself, I'd like to say a huge Thank You to the DLang Tour team, all the authors involved with the original chapters and examples; Sebastian Wilzbach for a warm welcome and support; El-lin for solid advice; and Dmitry, for his keen eye, patience, and thoroughness during review. На второй странице, после последнего предложения "Подробности о компиляторах можно узнать из вики" не хватает точки. https://tour.dlang.org/tour/ru/welcome/install-d-locally
Re: tanya 0.6.0, new containers
On Saturday, 10 June 2017 at 07:33:33 UTC, Mike B Johnson wrote: On Friday, 9 June 2017 at 18:54:12 UTC, Eugene Wissner wrote: Dear community, there is a new release of my gc-free library, tanya. I don't announce each release, so I want to tell short about the latest development and plans for the next releases. [...] Thanks! I'll check it out.. we need this sort of stuff for D. Do you have any plans for a circular/ring buffer? I have already one, working only with scalar types: tanya.container.buffer.WriteBuffer. It was designed to be used with C-functions like read/send. In this module is also ReadBuffer, an asynchronous buffer. It locks one part of the buffer waiting for an asynchronous operation, while the other part can be used by the application.
tanya 0.6.0, new containers
Dear community, there is a new release of my gc-free library, tanya. I don't announce each release, so I want to tell short about the latest development and plans for the next releases. The most work in the last time was done on containers. These were added: - DList - Doubly-linked list. - String - UTF-8 string. - Set - The first version of hash based container that holds unique values without a particular order. Currently supports only integral values. Support for more types comes in the next release. - Vector was renamed to Array. The containers support ranges. tanya.memory.types: - Some bug fixes in RefCounted - New Scoped - allocator-aware object wrapper, that destroys the owned object at the end of the scope. The work on the containers will be continued. I also started to rethink the networking and the event loop parts of my library. Trying to extend it I discovered some flaws. So it is a further area, I'm working to provide a more complete networking solution. And it can be that multi-threading will come sooner than I planned originally. And I introduced a short release cycle for the first time: 3 weeks (But I won't flood the forum each time :)). And from now on I'm trying to deprecate features at least for one release before breaking the code to stabilize the code base a bit. https://github.com/caraus-ecms/tanya http://code.dlang.org/packages/tanya https://docs.caraus.io/tanya/
Re: Invitation to review new DIP PR
On Monday, 15 May 2017 at 06:03:27 UTC, Mike Parker wrote: There's a PR for a new DIP titled "Delegatable Functions" [1]. If you have time, I invite you to review the PR to make sure it's in the best state possible for moving forward to a merge and preliminary review. At this stage, we're looking for copy edits (grammar, spelling, vocabulary), line edits (rephrasing sentences, restructuring paragraphs) and content (are there any major holes in the proposal, unanswered questions). Thanks in advance to any and all who participate. [1] https://github.com/dlang/DIPs/pull/61 Abstract: "It is therefore proposed to add sematics to define functions" "n" is missing in "semantics".
Re: tanya library 0.2.0
On Wednesday, 22 February 2017 at 13:00:19 UTC, Kagamin wrote:
On Sunday, 19 February 2017 at 11:41:44 UTC, Eugene Wissner
wrote:
realloc() can move memory and if an object of type A has
references to other objects in the array, the objects will be
corrupted. "A" should be a POD-type. Otherwise you have to
allocate new memory, initialize it, copy the objects by one
and deallocate the old memory. Now there is
IAllocator.expand().
What's the difference between realloc+postblit and copy one by
one? Postblit is called only after copy, it's not a constructor.
The difference is that realloc will deallocate the old memory
before postblit.
For the sake of example:
struct Sample
{
Sample* sample;
this(this)
{
sample.sample =
}
}
void main()
{
auto s = new Sample[2];
s[0].sample = [1];
s[1].sample = [0];
}
Now suppose s[0] has the address 7fc8d2717000, s[1]: 7fc8d2717008.
Realloc cannot reallocate in place and after the call to realloc
s[0] has the address 7f27771e and s[1]: 7f27771e. It is
too late to call the postblit here, Sample.sample refers to
invalid memory.
Re: tanya library 0.2.0
On Saturday, 18 February 2017 at 23:08:52 UTC, Seb wrote:
Do you know about eventcore [1] (event loop abstraction)?
I hope that this will soon be submitted to Phobos as everyone
seems to be brewing their own solution and I am _not_ looking
forward to manage to find a way to run five event loops when I
want to use fix different libraries.
[1] https://github.com/vibe-d/eventcore
Yes. The event loop is the oldest part of tanya. At the time I
began to work on it, eventcore was very young and got very seldom
updates. I only heard it is the new fast and native event loop
for the new generation of vibe.d. There was libasync aswell which
was written as a native replacement for libevent, but was never
adopted more than just as an option; instead eventcore was
written from the ground up. Botan suffered an even worse fate. So
I wasn't sure what direction eventcore would take. No of the
event loops, I was aware of, had IOCP support on Windows. For me
windows wasn't that important, but I implemented it to ensure
that the same API can work with both, Posix-style events and the
asynchronous Windows completion ports; and I could really fix
some design flaws implementing IOCP. I don't know if I really
want to have such an abstraction included in phobos, since there
are bindings for C event loops and a few native ones, and maybe
they will continue to exist, regardless whether there is
something in Phobos or not. But yes, if Phobos would have
something for asynchronous programming, I would take a look into
it again.
However I would be very interested in hearing your reasons for
not using it.
Keep in mind that std.experimental.allocator is supposed to be
a general purpose library exactly to avoid everyone writing
their own, incompatible Allocators ;-)
So please raise your voice as long as it's still in
experimental!
[2] https://github.com/bloomberg/bde/wiki/BDE-Allocator-model
Thanks for the question. I had to describe it from the beginning
or in the README, but didn't want to blow my message up.
BDE allocators implement an interface, other allocators normally
not. It is the main point. It is not about a concrete interface.
Phobos allocators are structs, they can't implement anything and
there is a CAllocatorImpl, that implements IAllocator and wraps
other allocators, so structs can behave as if they would
implement IAllocator too. But these structs can be used directly
without CallocatorImpl in the templated code.
So if you have a container, you can do:
auto arr = Array!(int, Mallocator)(Mallocator.instance);
EMSIContainers do that and it is the way Phobos allocators and
containers will go.
(https://github.com/economicmodeling/containers)
If you don't want to template your code or you use phobos default
allocator, you do the following (because theAllocator should have
some type):
theAllocator = allocatorObject(Mallocator.instance);
Contras of my allocators:
1) they are slower (because of virtual function calls)
2) If the allocator is passed as template parameter, functions
that rely on the allocator can infer the attributes like @safe,
@nogc, pure (yes, there was a discussion to make malloc pure).
Pros:
1) "is-a" relation. Mallocator "is-a" allocator, MmapAllocator
"is-a" allocator. In your code if you use allocators as a
template parameter (the faster way), you can't rely that the
allocator implements some method. So your code will look like:
static if (allocator has method "expand")
{
if (allocator.expand(arr, 8))
{
}
}
2) Less code bloat. With phobos allocators you would make as much
as possible to templates.
3) I see absolute no reason, why Array!(int, Mallocator) and
Array!(int, GCAllocator) has different types. Do you want a
function that accepts an array:
void myFunc(Array!int arr);
you have to make a template function from it (with a long "if
check" that ensures that an Array!int is passed). Code bloat.
4) It just works everywhere. Phobos allocators are structs but
there is still IAllocator interface, because the model isn't
universal enough.
5) I started by implementing IAllocator and the reason I dropped
it then, is IAllocator.expand. If you have an array of type A
where A is a struct with a postblit constructor, you can't just
call realloc() to resize the array. realloc() can move memory and
if an object of type A has references to other objects in the
array, the objects will be corrupted. "A" should be a POD-type.
Otherwise you have to allocate new memory, initialize it, copy
the objects by one and deallocate the old memory. Now there is
IAllocator.expand(). If IAllocator.expand() can expand the memory
in place, everything is fine, you haven't to copy the objects
because the addresses don't change. But libc realloc for example
doesn't guarantee that the address doesn't change if you shrink
the memory. But IAllocator doesn't have a shrink() method.
And anyway I find this separation expand/shrink or
tanya library 0.2.0
It isn't really a release announce, maybe a pre-release. tanya is a general purpose library, used mostly for networking by me. It is an attempt to develop an alternative memory model for D; 100% of the library are usable in @nogc code. I previously announced that I want to merge my code with another project and that I would stop the development. But it didn't happen. I'm sorry that I wanted to abandon it. It won't happen anymore. I'll continue the development. tanya contains an event loop, containers, an URL parsing routine and alternative TCP sockets implementation, multiple precision integer. The library is cross plattform, but not thread-safe yet. The memory management is based on allocators. The allocators are one-way compatible with std.experimental.allocator, it means my allocators can be used with std.exeperimental.allocator but the std.experimental.allocator isn't usable with my lbirary (though it is pretty straightforward to write a wrapper for phobos allocators). tanya's allocators follow Bloomberg Allocator Model, see discussions on BDE Allocator Model for pro and contra. And sorry once again for a long post... What's new: - Bug fixes and performance improvements in the main allocator: MmapPool. - Container redesign: There is a new container, Vector (similar to std.container.array) with the support of ranges and all the cool stuff. I also started to experiment with the "move" semantics in D based on the D conf talk of Ali Çehreli. There are also a singly linked list, circular buffer and a queue. SList will get range support soon, and some time later the buffers. - Bug fixes in the epoll event loop and a few new features. - RefCounted: more similar to C++ shared_ptr than to phobos' RefCounted, but more primitive. Future plans: I still need a few more containers: UTF-8 string and a hash table. The string won't be the same as RCString. I'm thinking of a not templated string with UTF-8 support only (with a possibility to initialize it from a string, dstring and wstring). Big integer bug fixing and optimization has a priority aswell for me. I'm also planning to add streams but it won't happen very soon since it is a lot of work. I plan to start a small blog in April based on the library (university project). It will be a SCGI-server, serving only static pages, behind Apache. It will be the first try-out :). From there I can move to a http-server. The library is still under permanent development. I begin to care about the API stability and proper deprecations, but it isn't always possible. I intend to make releases regularly, maybe all the 6 weeks and to prepare some new features for each of the releases. The API docs for the latest version can be found on https://docs.caraus.io/tanya/ If you have questions, need some examples, let me know. I'll write something up and publish it somewhere. https://github.com/caraus-ecms/tanya http://code.dlang.org/packages/tanya https://docs.caraus.io/tanya/
Re: D Compiler as Docker Image
On Tuesday, 14 February 2017 at 23:24:03 UTC, Stefan wrote: Want to share the outcome of a vivid discussion today at the Munich D Meetup with you. Installation of a D Compiler is ok-ish. But sometime you don't want to install it. Sometimes you want a very clean compiler-environment. Sometimes you want to compile your projects in the cloud and not on your local PC. To ease this a bit I drafted Docker Images for the Compilers (dmd, ldc, gdc, sdc) [1]. Based on this you have a clean compilation environment. And you even could use dub with it. No installation anymore. Seems to be very useful for testing. I have mostly only the latest stable dmd installed in the system. But need to test against elder versions and other compilers before travis reports that the build fails.
Re: Getters/setters generator
On Tuesday, 17 January 2017 at 07:06:05 UTC, Stefan Koch wrote:
On Tuesday, 17 January 2017 at 06:26:35 UTC, Eugene Wissner
wrote:
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei
Alexandrescu wrote:
Love it, and was toying with similar ideas too. One good
extension is to add a predicate to the setter, which guards
the assignment. -- Andrei
What kind of predicate do you mean? Can you give an example
please?
setValue(uint _under24)
{
assert(_under24 < 24);
under24 = _under24;
}
Ah, well thanks. I don't think it makes much sense since it would
be easier to write a complete setter if the user needs extra
checks. Accessors are there only for the generation of the
standard methods, that just get or set some object property.
Re: Getters/setters generator
On Friday, 9 December 2016 at 18:53:55 UTC, Andrei Alexandrescu wrote: Love it, and was toying with similar ideas too. One good extension is to add a predicate to the setter, which guards the assignment. -- Andrei What kind of predicate do you mean? Can you give an example please?
Re: Getters/setters generator
On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote:
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example
would be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to
get its value. Of cause you can generate only @Read without
@Write and vice versa. There are some more features, you can
find the full documentation in the README.
"GenerateFieldAccessors" mixin should be added into each
class/struct that wants to use auto generated accessors.
We just released the next version of the accessors: v1.1.0
- One problem with inheritance was fixed.
- And the generated accessors are always properties know.
Re: Release 2.072.2
On Saturday, 31 December 2016 at 21:28:43 UTC, Martin Nowak wrote: Glad to announce D 2.072.2. http://dlang.org/download.html This version resolves a number of regressions and bugs in the 2.072.1 release. Most prominently scope classes work again in @safe code, various rdmd bugs were fixed, and -fPIC became default for all linux 64-bit binaries and packages in order to support PIE (default on Ubuntu 16.10 and hardened Gentoo). Also see the changelog for more details. http://dlang.org/changelog/2.072.2.html -Martin Can it be that freebsd64 dub is linked against wrong phobos? I get: Shared object "libphobos2.so.0.71" not found, reuired by "dub". The same was with 2.072.1.
Re: Getters/setters generator
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Here is the pull request to add @property to the generated methods: https://github.com/funkwerk/accessors/pull/4
Re: Getters/setters generator
On Sunday, 11 December 2016 at 03:15:55 UTC, Mike Bierlee wrote: On Sunday, 11 December 2016 at 02:17:18 UTC, Mike Parker wrote: On Saturday, 10 December 2016 at 20:25:05 UTC, Mike Bierlee wrote: On Friday, 9 December 2016 at 10:27:05 UTC, Eugene Wissner wrote: It would generate 2 methods "num": one to set num_ and one to get its value. It would be great if you could generate @properties instead. I like the more natural way of accessing those instead of getters/setters. What are properties if not "getters" and "setters"? From the original post: "It would generate 2 methods "num": one to set num_ and one to get its value." Two methods named "num". No "get" or "set" in sight. I was under the impression that you could only access methods as if they were fields using the @property attribute. After carefully reading the documentation I see this is not the case (UFCS does this). Still there are some added benefits from using @property to completely threat them as fields. It would be nice if you could add @property to the generated getters/setters. Yeah, I see, @property seems to bring some additional features. Will think about it. Thanks.
Re: Getters/setters generator
On Saturday, 10 December 2016 at 16:37:53 UTC, Iakh wrote: On Friday, 9 December 2016 at 16:30:55 UTC, Eugene Wissner wrote: On Friday, 9 December 2016 at 12:37:58 UTC, Iakh wrote: Is there possibility to remove affixes in generated accessor names? No, there is no way to manipulate the accessor names. What affixes do you mean? You can remove suffix "_" so "name_" becomes "name". But I like to see genarated accessors "name" for field "m_name" no, it isn't possible. we just hard coded the most simple and the most "d-style" convention.
Re: Getters/setters generator
On Friday, 9 December 2016 at 12:37:58 UTC, Iakh wrote: Is there possibility to remove affixes in generated accessor names? No, there is no way to manipulate the accessor names. What affixes do you mean?
Getters/setters generator
Hello,
we've just open sourced a small module ("accessors") that helps
to generate getters and setters automatically:
https://github.com/funkwerk/accessors
http://code.dlang.org/packages/accessors
It takes advantage of the UDAs and mixins. A simple example would
be:
import accessors;
class WithAccessors
{
@Read @Write
private int num_;
mixin(GenerateFieldAccessors);
}
It would generate 2 methods "num": one to set num_ and one to get
its value. Of cause you can generate only @Read without @Write
and vice versa. There are some more features, you can find the
full documentation in the README.
"GenerateFieldAccessors" mixin should be added into each
class/struct that wants to use auto generated accessors.
tanya event loop v0.1.0
A month ago I announced the first pre-alpha release of tanya, a
general purpose library with an event loop. After a month of
almost every day work, I think I can make a second announcement.
https://github.com/caraus-ecms/tanya
The bad news is that most probably I'm stopping my development of
the library. The good news is that almost everything is now
merged into dlib by Timur Gafarov:
https://github.com/gecko0307/dlib.
My first contribution to dlib was in May 2016 and I decided that
I would profit from extending an existing library and I can say
that I had only positive experience from the work with Timur.
* dlib uses manual memory management aswell.
* there containers I can use without developing my own.
* there are some modules like zlib and huffman algorithm
implementation I will need later for a web server.
You can find the event loop in dlib.async. The most noticeable
change since the first release is that I think I can say now that
the event loop is now cross-platform. dlib.memory.mmappool
(memory.ullocator before) works now under Windows as well. The
event loop itself supports epoll (linux), kqueue (developed and
tested on FreeBSD) and IOCP (Windows). Because I need for Windows
different sockets, I created own socket implementation. Anyway
the work with the event loop and the sockets is now much easier
than in the first version. UDP is still isn't supported.
Basic error handling was added.
dlib has now a "crypto" branch aswell, where I'm working on a
light weight TLS package.
Another thing is that I changed my mind about @nogc. I still
don't rely on the GC, but I think now that my understanding of
@nogc was completely wrong. I thought that the missing @nogc
means "it uses GC". But it seems to mean only "it can use GC" and
@nogc means "it never uses GC". So I go now with allocators and
give the user of the library the chance to decide if he wants to
use the GC or not.
Please understand that the async package is still very simple.
But I'm working hard on it in my free time. In the next step I
want ot adapt it to a web framework I've started before
(https://github.com/caraus-ecms/caraus).
Echo server example with the new version:
import dlib.async;
import dlib.network.socket;
class EchoProtocol : TransmissionControlProtocol
{
private DuplexTransport transport;
void received(ubyte[] data)
{
transport.write(data);
}
void connected(DuplexTransport transport)
{
this.transport = transport;
}
void disconnected(SocketException exception = null)
{
}
}
void main()
{
auto address = new InternetAddress("127.0.0.1", cast(ushort)
8192);
version (Windows)
{
auto sock = new
OverlappedStreamSocket(AddressFamily.INET);
}
else
{
auto sock = new StreamSocket(AddressFamily.INET);
sock.blocking = false;
}
sock.bind(address);
sock.listen(5);
auto io = new ConnectionWatcher(sock);
io.setProtocol!EchoProtocol;
defaultLoop.start(io);
defaultLoop.run();
sock.shutdown();
}
There is still no online documentation. But I almost ready to
begin to test the event loop and publish "self-hosted"
documentation based on it.
Like always I welcome any feedback ).
Re: SQLite-D goes beta!
On Tuesday, 20 September 2016 at 16:53:23 UTC, Stefan Koch wrote: On Monday, 30 May 2016 at 18:07:09 UTC, Stefan Koch wrote: It is my pleasure to announce that I now consider SQLite-D to be in Beta stage. The reader is now stable enough to read all the test tables I have been given. The fact that it took around 20 minutes to complete index-tree support convinced mt that I have chosen a solid design. I have received the request to add examples and documentation to sqlite-d. And I will do so as time permits. This project will be boost licensed. So don't be shy :) https://github.com/UplinkCoder/sqlite-d It took a few months for me to get to the point, but now it is officially boost licensed. I want just let you know that native sqlite is absolute great. I maintain a packagekit backend for slackware linux and it takes advantage of sqlite. It is currently written in C with glib but i want to add some D later. So many thanks for your work!
Re: yet another event loop
On Friday, 26 August 2016 at 15:02:42 UTC, Jack Stouffer wrote: On Wednesday, 24 August 2016 at 18:03:39 UTC, Eugene Wissner wrote: https://github.com/caraus-ecms/tanya Please make documentation easily available for your library. I wish to use event loops in D, but I have no desire to wade though someone else's code in order to figure out how use the library. Sure. I will try then that it appears as soon as possible either as a few web pages or github-wiki. Thanks for this note
Re: yet another event loop
On Friday, 26 August 2016 at 10:03:22 UTC, Robert M. Münch wrote: On 2016-08-24 18:03:39 +, Eugene Wissner said: I want it to become not an event loop only but a general purpose library that has an event loop. Hi, well, I would re-think this since the danger is, that everything is so connected that I can use either all or nothing at all. I'm searching for a configurable (network, timer, GUI) stand-alone event-loop library, that abstracts away platform differences for years. Those that I found are so tighly deep coupled with the rest, that you can't get them out. IMO general purpose libraries building their own context and world-view are waste of time... Do you mean that the library can have different modules but they should be independent of each other as much as possible (like phobos) or that every part that can be separated belongs to its own repository? I absolutely agree with the first but not sure about the second point.
Re: yet another event loop
On Friday, 26 August 2016 at 10:54:17 UTC, bachmeier wrote: The person you responded to is a troll that has been cluttering the forum. No need to even read what they are posting. Didn't know it, thanks
Re: yet another event loop
On Friday, 26 August 2016 at 02:22:54 UTC, Bill Hicks wrote: On Wednesday, 24 August 2016 at 18:03:39 UTC, Eugene Wissner wrote: https://github.com/caraus-ecms/tanya Ok there are not so many event loops in D and here an another one and its name is "tanya". Could you change the name to something more recognizable to help with D's popularity? Something like 'kardashian' might be better. Nobody really knows 'tanya', do you know what I mean? Maybe even 'madonna', so people will know that D is just as talented as others languages. Marketing is going to be key for D, so let's do our best. I think I disagree. For example I didn't know who is kardashian and the name is pretty difficult. And I think neither kardashian nor madonna are worth to name something after them. I also doubt that naming after famous people gave more popularity to kafka, picasa, ada, pascal and so on
Re: yet another event loop
On Thursday, 25 August 2016 at 00:24:59 UTC, mogu wrote: On Wednesday, 24 August 2016 at 18:03:39 UTC, Eugene Wissner wrote: https://github.com/caraus-ecms/tanya Ok there are not so many event loops in D and here an another one and its name is "tanya". ... Nice works, thanks. Hey, Thanks for your feedback. I'm very interested if someone would like the idea and maybe participate. It would be also nice to have some benchmarking but I couldn't find an appropriate tool for this. I found some small programs but everything in languages I don't know, so I couldn't find out if my implementation doesn't work in some cases or the benchmarking tool. Writing an own bencmarking suite would take some time that I would better spend writing the library. Maybe I should have first a simple http server. There a lot of matured tools for testing http.
yet another event loop
https://github.com/caraus-ecms/tanya Ok there are not so many event loops in D and here an another one and its name is "tanya". I want it to become not an event loop only but a general purpose library that has an event loop. What once started as a libev rewrite, hasn't much common with libev now except some general concepts like watchers. Regarding libev: 1) tanya is very, very basic and it hasn't a lot of important features yet like signals, UDP, threads and so on. I had to begin somewhere and stripped out everything that isn't relevant for a basic event loop. Features will be added with the time. 2) Only epoll is currently supported. But I tried to create an API that can be easily extended, so you have to extend one class and implement a few methods to add other backends. 3) In another thread chmike (many thanks again!) pointed me to Windows IOCP. I'm not completely sure I understand how the completion ports work, but I implemented the loop in the way that you haven't to care about file descriptors and sockets but get notified if the data are really available. And you write aswell not to a socket but into a buffer, and the event loop takes care of passing it then to the socket. I hope it can make the work with the loop more pleasant and can make it possible to create a performant Windows implementation. Other points: 1) The library is 100% @nogc. I know there were some discussions that this @nogc is pure marketing thing, but I find it helpful that the compiler can say if you allocate somewhere in a language where GC allocations can happen behind the scenes. 2) The loop throws a few exceptions that should be freed, but I'm thinking to switch to some data type "either exception or return value" and make the loop nothrow. It has nothing to do with @nogc. It is just kind of not very cool if an exception can kill the event loop if something goes wrong. 3) The library isn't thread safe. I will work on it later. 4) libev wasn't the only source of inspiration. tanya is a mix of libev and asyncio and asynchronous. I took over the concept of protocols and transports from asyncio/asynchronous since I believe they make the writing of applications really pleasant. The difference is that they aren't a kind of "wrapper" around the actual event loop, but are first-class citizens. It could make it difficult to write such wrappers like that ones that exist for libasync, but on the other side it kills some unneeded abstractions and makes the code structure simplier, that could also give some additional performance. 5) I tried to write unittests and short descriptions everywhere, so there is some documentation and examples. For an usage example skip the crap I'm writing here and look at the end of this message. There are already some "extras": tanya.memory: has a simple allocator (Ullocator) that uses mmap/munmap (tested on Linux, will theoretically work on other platforms aswell). "allocator" package has some functions like "finalize" that can be used in @nogc code instead of dispose or "resizeArray" that is similar to shrinkArray/expandArray from std.experimental.allocator, but doesn't take a delta as argument but just the length, that the array should have. The allocator was the most difficult part of the library for me, but very interesting. I had to rewrite it 3 times till I got something working. I just advice everyone to write their own malloc/free implementaion, it is a frustrating, but awsome experience! tanya.container: Queue, Singly-linked list and In-/Output Buffer (useful in C-style functions that take a void pointer and the length as argument and return bytes read/written). I wrote them for the event loop, not sure they are good as general-purpose containers, but I would be anyway interested to make them suitable for other use-cases. They are also differently concepted than phobos containers. Phobos containers as far as I've seen are containers that implement ranges functionality in substructs/subclasses. tanya's containers are a mix of containers and ranges. tanya.math: has "pow" function that calculates x**y mod z. The algorithm is similar to the one used by phobos. The return type and arguments are currently ulong but it will change, I will need larger numbers probably. tanya.random: has an "Entropy" class that can generate 64-byte blocks of random data (uses getrandom syscall). The generic logic is stolen from mbedtls. tanya.crypto.padding: implements some algorithms to pad 128/192/258-byte blocks of data. But you cannot remove the padding :) Sorry, it will be added soon. Just started. I made some tests with an echo-client written in Go (just found one benchmarking one-page Go echo-client in the internet). Here is an usage example, just to give some feeling how the library works (Examples and description will be added to the repository soon): import tanya.memory; import tanya.event.loop; import
Re: Aedi - a dependency injection library
On Tuesday, 16 August 2016 at 09:41:27 UTC, Alexandru Ermicioi wrote: Good day. I'd like to show my library aedi (v0.0.1), which implements dependency injection pattern. They key features of aedi are: 1) Simple api through which a container can be configured with objects. 2) Ability to extend the library with custom logic required by your code. 3) Ability to inject already instantiated data (not only objects). 4) Possibility to build a hierarchy of containers that will be used to resolve dependencies. (for ex. if there is a need of a container that ships prototype objects along with singleton ones). For more information about common usage of library, check readme.md on github. Most of library is documented (functions, classes, interfaces, etc.). If there is some unclarity in docs, please tell about it. https://github.com/aermicioi/aedi https://github.com/aermicioi/aedi/blob/master/readme.md The library is still in development, and I'd like to see some comments, on library's usability, as well possible improvements of it. Thank you. How does it compare to poodinis?
Re: mimeapps - finding association between MIME types and applications
On Saturday, 16 April 2016 at 18:48:36 UTC, FreeSlave wrote: mimeapps is a library for detection of which applications can be used to open files of given MIME type. Note: this is essential only for systems that follow Freedesktop specifications, i.e. Linux, BSD and some others. MS Windows and OS X have their own file type associations systems. github repo: https://github.com/MyLittleRobo/mimeapps (examples included) dub package: http://code.dlang.org/packages/mimeapps Specification: https://www.freedesktop.org/wiki/Specifications/mime-apps-spec/ Use cases: 1. Building "Open with" menu. 2. Finding user preferred application for specific file type, e.g. text editor for text/plain or file manager for inode/directory. 3. Finding user preferred application to open uri, e.g. user preferred web browser for http and https links. Related libraries: https://github.com/MyLittleRobo/desktopfile - reading and executing .desktop files. https://github.com/MyLittleRobo/mime - parsing shared MIME type database and detecting MIME types of files. Wow. I just wanted to port libmagic since need it. Can you write a short introduction how I can work with the magic database (defining mime type of a file based on its content)?
Re: futures and related asynchronous combinators
On Sunday, 27 March 2016 at 07:16:53 UTC, Vlad Levenfeld wrote: https://github.com/evenex/future/ I've been having to do a lot of complicated async work lately (sometimes multithreaded, sometimes not), and I decided to abstract a some patterns out and unify them with a little bit of formalism borrowed from functional languages. I've aimed to keep things as simple as possible while providing a full spread of functionality. This has worked well for me under a variety of use-cases, but YMMV of course. Anyway I've occasionally seen people on IRC asking about futures, so I thought I'd share and make this announcement. This lib depends on another lib of mine (for tagged unions and related things) which might not appeal to some but if there is demand for futures sans dependencies I can always go back and manually inline some of the templates. TL;DR: auto x = async!((y,z) => y + z)(1,2); x.await; assert(x.result.success = 3); Hi Vlad, Are you intend to open source other parts of your work? Can I ask what are you using for your async stuff: libasync, vibe, asynchronous or something self written?
Re: Event Dispatcher
On Wednesday, 16 March 2016 at 15:14:57 UTC, Kagamin wrote: On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: Why not just extend the HelloWorld class and override the hello()? Imagine you write an apllication that should support plugins. And two independent plugins extend the HelloWorld. One plugin would conflict with the another. EventDispatcher make it possible to register the events that can be used by application plugins. How about something like MEF? I didn't know about MEF before, I've just read an article about it, so correct me if I'm wrong. I think that MEF and such event dispatcher aren't comparable. Event dispatching is one of the principles how to extend the application. MEF as Wikipeda states "aims to solve the runtime extensibility problem". The important word is "runtime". So it is a higher level, it is about binding different parts of application at runtime. (As I understand it). Now Symfony, I'm inspired by, has a thing called Bundles. Bundles are just application plugins. And event dispatching can be used inside this bundles aswell. And it is the level where something like MEF would be really great. I think it should be really done, because it would make it possible for example to write closed source plugins for open source applications (it is very common in ecommerce, for example online shops, even for PHP, where you can decode your plugins with something like ioncube). Another area, where it could be used, is routing (already because plugins should be able to add routes to the application at runtime). So concepts like MEF are anyway something very useful for compiled applications/languages and I'll have to find a way to implement it on some stage. Thanks for mentioning it.
Re: Hotfix release vibe.d 0.7.28
On Monday, 29 February 2016 at 07:54:09 UTC, Sönke Ludwig wrote: Am 29.02.2016 um 00:47 schrieb sigod: On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig wrote: This is a small bugfix release that mainly fixes two critical regressions: - FreeListRef!T, which is used heavily in the HTTP server code, stored its reference count in an unallocated memory region, leading to possible memory leaks or memory corruption - A TCP connection with a non-empty write buffer that got closed by the remote peer and locally at the same time could result in the calling task to starve (i.e. it got never resumed after yielding execution). In particular, this could happen when accessing HTTPS servers with the HTTP client in conjunction with "Connection: close". http://vibed.org/blog/posts/vibe-release-0.7.28 You forgot to update site header. Thanks, also forgot the documentation (even if nothing has changed). Is there any plans on when big split will happen? It will be a step-by-step process. I'm currently working on a new version of the `vibe.core` package that contains some large changes under the hood. Once that is in a functional state, I'll look into how to enable optional replacement of the existing vibe:core package by this new, separately hosted vibe-core package. vibe:core, at that point, will only receive bug fixes and continues to live for a while (let's say a year or one and a half). The same procedure will then happen for vibe:http (the new package will include HTTP/2 support) and the other sub packages. All of the new packages will get a version number of 1.0.0, once they can be considered reasonably stable. One unfortunate aspect of my current work on vibe-core is that I'm building on a new event loop abstraction that I built as a prototype to see where the performance bottlenecks of the current system are. libasync was too slow and it had a too complicated structure to make quick tests for improving performance. Now I'm leaning towards finalizing the new prototype library and proposing it for Phobos inclusion at some point. Sönke, is your current work on core available somewhere? Since my vibe.d related work isn't stable it wouldn't a problem to use unstable core-component. It is better than rewriting later if a lot of things change.
Re: Event Dispatcher
On Thursday, 10 March 2016 at 18:15:21 UTC, Adam D. Ruppe wrote: On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote: I haven't used vibe.d myself but I did write CGI and SCGI (and fastcgi with the help of a C lib, and an embedded http server) in my cgi.d file: https://github.com/adamdruppe/arsd/blob/master/cgi.d some dox: http://dpldocs.info/experimental-docs/arsd.cgi.html It is written in a traditional manner - no vibe, no fibers, no async. This makes a lot of things easier but it isn't as sexy. Yes, I'm aware of your code, Adam. I'm using it for reference and looking if I don't how to implement something better. Thank you for this work!
Event Dispatcher
Hey,
I wrote some time ago I'm working on the rewriting some parts of
Symfony web framework from PHP to D. One component is pretty
small and is already ready. It is an Event Dispatcher:
https://github.com/caraus-ecms/caraus (submodule
caraus:eventdispatcher).
Event dispatchers make it possible to write extensible
applications. You can register events in different places of your
application and attach callbacks to them. It is similar to
signals, but you have a central instance aware of all events and
callbacks (Mediator pattern:
https://en.wikipedia.org/wiki/Mediator_pattern).
It isn't very useful on its own, since the event dispatcher
should be passed everywhere but it can be used, for example,
with a DI container like poodinis. Since frameworks like
https://github.com/Skadi-d/Skadi.d had "Event Dispatcher" in its
TODO, I decided to write this Announce if something finds it
useful.
In the following lines I will only describe how it works and what
is for. You can find the example I describe here:
https://github.com/caraus-ecms/caraus/blob/master/examples/eventdispatcher/source/app.d
We want to extend a hello world program:
import std.stdio;
class HelloWorld
{
void hello()
{
writeln("Hello world!");
}
}
void main()
{
auto helloWorld = new HelloWorld;
helloWorld.hello();
}
We want that people can attach their own messages before "Hello
world!" or after it. We initialize the EventDispatcher in the
class using it:
dispatcher = new EventDispatcher;
and then attach events like this:
dispatcher.dispatch("postHello");
The last step is to register callbacks to this event:
dispatcher.addListener("postHello", delegate(Event e, string
eventName, EventDispatcher dispatcher) {
writeln("Bye!");
});
Everything together:
import caraus.eventdispatcher.dispatcher;
import caraus.eventdispatcher.event;
import std.functional;
import std.stdio;
class HelloWorld
{
EventDispatcher dispatcher;
this()
{
dispatcher = new EventDispatcher;
}
void hello()
{
writeln("Hello world!");
dispatcher.dispatch("postHello");
}
}
void main()
{
auto helloWorld = new HelloWorld;
helloWorld.dispatcher.addListener("postHello", delegate(Event e,
string eventName, EventDispatcher dispatcher) {
writeln("Bye!");
});
helloWorld.hello();
}
Now you should get:
Hello world!
Bye!
Why not just extend the HelloWorld class and override the
hello()? Imagine you write an apllication that should support
plugins. And two independent plugins extend the HelloWorld. One
plugin would conflict with the another. EventDispatcher make it
possible to register the events that can be used by application
plugins.
Note: If someone wonder about the whole web framework I
mentioned. In the last week I looked a lot into the vibe.d and I
moved to its core for handling the requests instead of my own
CGI-handling. I'm currently working on implementing SCGI based on
vibe.d IO. And I already have a simple web page of a customer
running on it (ok, it is a single page website, but it is already
something :))
Enjoy. Or like people say on this forum: Destroy.
Re: Ddb needs a maintainer
On Sunday, 14 February 2016 at 16:53:31 UTC, Piotr Szturmaj wrote: On 2016-02-14 12:48, Jacob Carlborg wrote: It seems both ddb and ddbc had the same idea, building a library accessing databases independently of the kind of database. The difference is that ddb does not seem to have the abstraction making it database independent and only works for Postgres. ddbc on the other hand does support multiple databases and have the abstraction layer. So at this point ddb is basically a Postgres driver and nothing more. ddb was written with multiple databases in mind, mostly postgres, mysql and sqlite. db.d (DBRow definition) is database independent. postgres.d contains PGConnection, PGCommand, etc. Other backends should provide their own classes like MySqlConnection, MySqlCommand and so on. Then it's trivial to add an abstraction layer that chooses between different backends depending on the connection string for example. Regarding ddb maintainability, thank you for your interest, I can add you both (Jacob and Eugene) to my repository as collaborators, you will have full access to repo, pull requests and issues. If I will ever need ddb in some of my project I would still have access to my repo to make some changes. If the project will grow bigger than expected we could move it to the new repo later. Is that okay for you? yes, it is for sure ok for me. It can be a good start. I think may be we should discuss if we can/should change something in ddb. I think there were some interesting and promising ideas in this discussion. Maybe split the PostgreSQL driver and develop it seperately and use an interface more similar to JDBC. Maybe some kind of coworking with ddbc is possible to get more developers together; maybe Suliman has some thoughts on it.
Re: Ddb needs a maintainer
my five cents on that topic... @Eugene: From my point of view, it would be great if you could bring in all your ideas, wishes, changes, additions and new stuff into vibe_d and help to grow and extend it and make it more usable... Don't get me wrong, I thinks it's great if developers have various choices in general to pick from, but especially in Dlang "core tools" some of the existing stuff needs more contributors/help... like vibe_d, dub (both from Sönke & team) dfmt, ... You and Sönke share the same native language (German) and also the same time zone (Munich/Berlin)... and as it seems also the same interest in "Web stuff/Frameworks", right? It shouldn't be that difficult for you guys to alighn and team-up to build an even better "Dlang Web tools/Framework development team"... My native language is Russian, but my German is anyway better than my English, it's true :) Yes, I actually understand your point. I thought about it already and it could be really more productive. I think I have to look in vibe more closely. Maybe I'll just look into open issues on github, maybe I'll be able to find a few easy issues, I could try to fix - it could be the best way for me to get know vibe.d internally better.
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: 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
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: 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: Poodinis (DI framework) 6.1.0 released
On Tuesday, 9 February 2016 at 23:16:34 UTC, Mike Bierlee wrote: Poodinis 6.1.0 has been released! Poodinis is a dependency injection framework for the D programming language. It is heavily inspired by the Spring Framework. Most notable in this release is the ability to autowire private and protected members. Now you can have proper encapsulation again. Thanks to Extrawurst for implementing this! (Other) notable changes in this release: - Added ability to register a type while resolving it. - Added ability to autowire private fields (Thanks to Extrawurst). - Fixed registration of application contexts with non-public members More can be found in the changelog. You can find the project at: Github: https://github.com/mbierlee/poodinis D package registry: http://code.dlang.org/packages/poodinis Thanks. It looks very nice! I most probably will need a DI for my web applications.
Re: Do D need a popular framework? like ruby's rails? or java 's ssh?
On Thursday, 4 February 2016 at 15:37:21 UTC, sigod wrote: On Tuesday, 19 January 2016 at 13:22:48 UTC, beck wrote: Do D need a popular framework? in china ,a little peopel use dlang. i just use it do some simple work for myself. yet,i have learn d for a week .. i ask so many friends ,they don't use D at all.we use golang more than dlang. Oh, I thought I'll see here a suggestion to port some popular and useful libraries/frameworks from other languages... Seriously, it might be an interesting idea. I want to port some parts of PHP Symfony: https://github.com/caraus-ecms/caraus I've just started and it is kind of "learning project", I haven't written anything in D before. On the other hand I'm writting a personal project (kind of CMS/Blog) and this Symfony port is the base for this project. Don't know yet if I'll open source everything later.
