Re: Keeping imports clean
On 4/2/12, James Miller wrote:
> So in short, it isn't relevant at all.
It is relevant to build times. Compare the build times of this:
import std.algorithm;
import std.array;
import std.conv;
import std.file;
import std.string;
import std.stdio;
import std.typetuple;
import std.typecons;
import std.traits;
import std.range;
void main() { }
With this:
void main() { }
First:
$ timeit dmd test.d
Elapsed Time: 0:00:00.296
Second:
$ timeit dmd test.d
Elapsed Time: 0:00:00.031
That's not a lot of time wasted but it does affect compile times a
little bit. I wonder if DMD could be improved a bit in this regard.
Re: Keeping imports clean
Thanks for the quick answer. Indeed it's by far less relevant than for C++ but a build tool still needs to figure out the dependencies. I know D is very fast to compile but you still want to keep compilation at a minimum. Wouldn't it matter for a very big project ?
Re: Compiler development
Oops, I think I had a "brain fart". The compiler is written in C++, but the executable is DMD which compiles D code, which allows unit testing.
Re: Compiler development
I was not being critical of D development, I was just curious. BTW - I am the guy that started the discussion on creating a subset of D called "D-" or "embedded D", i.e. D without garbage collection. D for the low resource, 32 bit microcontroller world. I guess I was just trying to put "my 2 cents" in the discussions. Note 1: I am a D novice but I have been watching the language for several years. NOTE 2: I have been showing my support of the effort by buying Andrei's book and Walter's C++ CD
Re: Compiler development
James Miller: and most people don't have the compiler suddenly pull the rug from underneath them (unless they were relying on the buggy behaviour). Relying on "buggy behavior" (or on deprecated features) is not rare. An example: http://d.puremagic.com/issues/show_bug.cgi?id=7736 Fixing this will cause some problems, and the more we wait, the more problems it will cause (and this stuff _must_ be fixed): http://d.puremagic.com/issues/show_bug.cgi?id=3934 There are several other similar examples. Like enforcing properties and requiring override, and generally using deprecated features like complex numbers. The more we wait now, the more pain will be felt later. Walter now likes to design D features strict at first and then "loosen" them later, this has worked quite well (this has happened with inout and pure). But Walter has not applied this strategy since the beginning on "tags" as shown in issue 3934, that are managed in an very very sloppy way now, and will need to be tightened later to produce a decent enough language. Bye, bearophile
Re: Compiler development
On Mon, Apr 02, 2012 at 12:02:56AM +0200, foobar wrote: [...] > Regarding DMD - Walter has a test suite for it for the same purpose. > I don't know the specifics of it as I never looked at it and not even > sure whether it's open source or not. The core devs would be able to > provide more specifics. The source code is right here: https://github.com/D-Programming-Language/dmd It comes with an extensive set of unit tests, which can be run by specifying the 'unittest' target for the makefile. The tests range from sources that should be compilable, sources that should fail compilation, sources that can be run, and win32-specific tests. I've run the tests before; they do take quite some time to complete because they're quite exhaustive. > Please note that while Walter writes in c++ he has a unique style of > it - some claim it's very D like. Indeed. T -- People walk. Computers run.
Re: D for a Qt developer
On 1 April 2012 22:12, Davita wrote: > Well, that's what i'm talking about. D is such a wonderful language that it > should scream on different forums and sites such as stackoverflow or > codeproject, but instead it's very quite, passive. And I think this is due > to the lack of quality development tools. :( > None of the companies or organizations I know would never start development > on DWT or QtD. Shouldn't D team address those issues? I mean, only > enthusiasmic community can't do much here. I think a sponsor or some > commercial interest is a must, or as I already mentioned above, to work with > Nokia guys and bring D with QtCreator. Or maybe to work with MS and > integrate D in VS and WinRT api. If one big organization starts using D, > then more and more people will have trust in D and start using it. Otherwise > I don't think the future of D will be as bright as it should :( Please don't assume that all people using D want big IDEs and toolchains, I'm perfectly happy with Vim + dmd, and I know several people that work in similar ways (substitute Vim with another editor, dmd with gdc, ldc2 or sdc). As for the "D Team", there isn't really one. There's Walter, the creator of the language and dmd, Andrei, a signficant contributor to several key language features. There are several people that have contributed heavily, Jonathon Davis, Brad Roberts, David Simcha wrote the Garbage collector, Steven Schveighoffer does a lot, and other that I can't remember right now. But all of these people have day jobs. Walter does... whatever he does, Andrei works for Facebook. So its not like there's a dedicated team of people working hardcore on this, so they focus on what is worth focusing on, like compiler bugs and broken features (like AA's that H.S. Teoh is writing a replacement for). So IDE's and gui support isn't something that the "D Team" is working on, and it isn't what they should be working on. Other people should work on IDE's and graphics libraries, and they are. Andrej is working on wxD, somebody could pick up the QtD project and get that back up and running, there's VisualD which gives Visual Studio D support and MonoD which adds D support to MonoDevelop. As for "working with other companies", what is the reason for these people to do that? MS are focused on .NET and C#, they don't want to promote and improve D, for free. There is a business aspect to all of this, and D isn't a money making venture. It is pretty much a charity, people donate their time and don't expect anything concrete back. But businesses don't do charity, it's just not good sense. I guess I'm just concerned that there are developers that think IDEs and fancy toolchains are what makes a language, but it's the requirement of an IDE that shows a language's flaws and faults. Ideally you should be able to write code in a simple text editor without much issue, and that is what you can do in D, because that is what I do in D. -- James Miller
Re: Keeping imports clean
On 2 April 2012 10:12, Guillaume Chatelet wrote:
> In C++ it clearly matters to have very clean dependencies to keep
> compilation time as low as possible ( Google even built a tool to check
> unused #include - http://code.google.com/p/include-what-you-use ).
>
> So I was telling to myself it would be great to have the D compiler report
> about unused import because it might already have all the necessary
> information. But maybe such a tool already exists ? Or maybe this is simply
> irrelevant ?
D doesn't have includes, importing a module that you don't use doesn't
matter because D only needs the imports to find function declarations.
This is clear in the import syntax:
import std.random : uniform //import only uniform from the std.random module
so it is a symbolic import, not a textual import. Also note that while
D has .di ("D Interface") files, they are not required, and often
people don't even bother with them, merely distributing the source.
So in short, it isn't relevant at all, since there is no preprocessor
to f**k things up.
--
James Miller
Re: Compiler development
On 2 April 2012 10:02, foobar wrote: > Or in other words you did regression testing. > > Regarding DMD - Walter has a test suite for it for the same purpose. I don't > know the specifics of it as I never looked at it and not even sure whether > it's open source or not. The core devs would be able to provide more > specifics. > > Please note that while Walter writes in c++ he has a unique style of it - > some claim it's very D like. There are unit tests in D for almost all features and bug fixes. Sometimes there is a regression, if it's found a test for it is added when the fix is pushed, to make sure that it doesn't happen again. If the tests don't compile, that's very bad and all the tests have to pass before a release. D's development is pretty solid, there are very, very, few breaking changes that aren't explicit and most people don't have the compiler suddenly pull the rug from underneath them (unless they were relying on the buggy behaviour). In general, the actual output of the compiler doesn't matter that much, its the behaviour of the code that matters, so that is why the tests are in D, it doesn't matter if the codegen changes, as long as the software still functions the same. That is why we have several thousand tests for the compiler that check various behaviours. -- James Miller
Re: Keeping imports clean
On Sunday, 1 April 2012 at 22:13:00 UTC, Guillaume Chatelet wrote: In C++ it clearly matters to have very clean dependencies to keep compilation time as low as possible ( Google even built a tool to check unused #include - http://code.google.com/p/include-what-you-use ). So I was telling to myself it would be great to have the D compiler report about unused import because it might already have all the necessary information. But maybe such a tool already exists ? Or maybe this is simply irrelevant ? in c++ it's text expansion, D imports are symbolic; it's not by far as relevant
Re: traits getProtection
On 2 April 2012 06:27, Adam D. Ruppe wrote:
> I've prepared a dmd pull request to add a new __trait:
> getProtection.
>
> It is meant to be used along with getMember() to add to
> the reflection capabilities, letting us use the existing
> protection qualifiers as strings.
>
> From the test:
> ==
> class Test {
> public int a;
> private int b;
> export string c;
> protected int d;
> package void e() {}
> }
>
> void main() {
> Test t;
> static assert(__traits(getProtection, __traits(getMember, t, "a")) ==
> "public");
> static assert(__traits(getProtection, __traits(getMember, t, "b")) ==
> "private");
> static assert(__traits(getProtection, __traits(getMember, t, "c")) ==
> "export");
> static assert(__traits(getProtection, __traits(getMember, t, "d")) ==
> "protected");
> static assert(__traits(getProtection, __traits(getMember, t, "e")) ==
> "package");
> }
> ==
>
>
>
> This will help D automatically generate things like
> external interfaces that use the protections.
>
> For instance, I plan to use it in my web.d to only
> make functions marked "export" available via the
> web interface. Currently, you have to use a naming
> convention to hide functions - a leading underscore -
> even on private members. This is ok, but not great.
>
> But with the protection trait, we can mark it with
> a much more natural "private", or any of the other
> specifiers D has.
>
>
> I'm sure other uses will come up too.
Looks good, adds a lot to the compile-time reflection capabilities. My
thoughts for it are similar to yours, generating bindings from
"export"ed members, so you don't need to maintain separate lists or
use a naming convention.
--
James Miller
Re: Compiler development
On Sunday, 1 April 2012 at 21:26:44 UTC, Tim Krimm wrote: What is the process for developing the dmd compiler? Years ago, when I worked on the IBM PLX/PLAS compiler, we had a large collection of test case files. We would create two executable versions of the compiler. One executable was the "good" version and the other version was the 'GOOD' version with the developers changes. We would run a script. 1) first compiler runs the test cases. 2) second compiler runs the test cases. 3) each compiler generated its own unique directory structure of results. 4) the results can be compiler lists, assembly listings, etc 5) the two directory structures are compared with a compare utility 6) the developer looks through the compare program output 7) if the differences make sense, the changes are added to the code base. pros helps reduce breakage of existing code when adding new features cons can slow down development looking through a bunch of compare listings. Our script was very complex, it allowed us to change compiler settings and change what we wanted to compare and what was generated by the compiler. Also the compare utility had settings that allowed it to only put out differences or differences with a couple of lines before and after to help locate the cause of the differences. or the developer could just go back and rerun the particular test case if it needed further analysis. Note:The dmd compiler is written in C++ not D, so you do not have the luxury of builtin unit tests. Or in other words you did regression testing. Regarding DMD - Walter has a test suite for it for the same purpose. I don't know the specifics of it as I never looked at it and not even sure whether it's open source or not. The core devs would be able to provide more specifics. Please note that while Walter writes in c++ he has a unique style of it - some claim it's very D like.
Compiler development
What is the process for developing the dmd compiler? Years ago, when I worked on the IBM PLX/PLAS compiler, we had a large collection of test case files. We would create two executable versions of the compiler. One executable was the "good" version and the other version was the 'GOOD' version with the developers changes. We would run a script. 1) first compiler runs the test cases. 2) second compiler runs the test cases. 3) each compiler generated its own unique directory structure of results. 4) the results can be compiler lists, assembly listings, etc 5) the two directory structures are compared with a compare utility 6) the developer looks through the compare program output 7) if the differences make sense, the changes are added to the code base. pros helps reduce breakage of existing code when adding new features cons can slow down development looking through a bunch of compare listings. Our script was very complex, it allowed us to change compiler settings and change what we wanted to compare and what was generated by the compiler. Also the compare utility had settings that allowed it to only put out differences or differences with a couple of lines before and after to help locate the cause of the differences. or the developer could just go back and rerun the particular test case if it needed further analysis. Note:The dmd compiler is written in C++ not D, so you do not have the luxury of builtin unit tests.
Re: Deimos - ODE bindings
On Sunday, 1 April 2012 at 20:32:00 UTC, Walter Bright wrote: On 4/1/2012 1:12 PM, q66 wrote: Cool. I'll try to get some other lib bindings up in the future as well. :) That would be most appreciated. I'm preparing my game engine for possible migration to D. Means I need all the libs ready, they already are, some of them are supplied by the Derelict project. But, there is this thing with dynamic loading of libs at runtime. I need the possibility of static linkage so having Deimos style bindings would surely be nice. I'm also binding Enlightenment Foundation Libraries (http://enlightenment.org/p.php?p=about&l=en) to D, featuring low level (plain) and high level bindings. It's a lot of separate libraries, and E SVN has a special directory for bindings to various languages, so I'm yet unsure whether to get it into Deimos or to E SVN.
Re: Deimos - ODE bindings
On 4/1/2012 1:12 PM, q66 wrote: Cool. I'll try to get some other lib bindings up in the future as well. :) That would be most appreciated.
Re: Deimos - ODE bindings
On 4/1/2012 1:00 PM, q66 wrote: On Sunday, 1 April 2012 at 19:34:49 UTC, Walter Bright wrote: On 4/1/2012 11:35 AM, q66 wrote: Figured so. I was asking because I ported ODE D bindings from Derelict 2 to Derelict 3 and making it without comments would be basically just about some sed processing. Anyway, I've been working on it in the meantime and finished it, leaving the original comments intact, as well as complete ODE 0.12 API macros and odemath inclusive: https://github.com/quaker66/ODE-D It's structured like any other Deimos project. I've added a Deimos project. Can you do a pull request to add it in? https://github.com/D-Programming-Deimos/ODE Done. and done. Thanks!
Re: Deimos - ODE bindings
On Sunday, 1 April 2012 at 20:09:40 UTC, Walter Bright wrote: On 4/1/2012 1:00 PM, q66 wrote: On Sunday, 1 April 2012 at 19:34:49 UTC, Walter Bright wrote: On 4/1/2012 11:35 AM, q66 wrote: Figured so. I was asking because I ported ODE D bindings from Derelict 2 to Derelict 3 and making it without comments would be basically just about some sed processing. Anyway, I've been working on it in the meantime and finished it, leaving the original comments intact, as well as complete ODE 0.12 API macros and odemath inclusive: https://github.com/quaker66/ODE-D It's structured like any other Deimos project. I've added a Deimos project. Can you do a pull request to add it in? https://github.com/D-Programming-Deimos/ODE Done. and done. Thanks! Cool. I'll try to get some other lib bindings up in the future as well. :)
Re: Deimos - ODE bindings
On Sunday, 1 April 2012 at 19:34:49 UTC, Walter Bright wrote: On 4/1/2012 11:35 AM, q66 wrote: Figured so. I was asking because I ported ODE D bindings from Derelict 2 to Derelict 3 and making it without comments would be basically just about some sed processing. Anyway, I've been working on it in the meantime and finished it, leaving the original comments intact, as well as complete ODE 0.12 API macros and odemath inclusive: https://github.com/quaker66/ODE-D It's structured like any other Deimos project. I've added a Deimos project. Can you do a pull request to add it in? https://github.com/D-Programming-Deimos/ODE Done.
Re: Deimos - ODE bindings
On 4/1/2012 11:35 AM, q66 wrote: Figured so. I was asking because I ported ODE D bindings from Derelict 2 to Derelict 3 and making it without comments would be basically just about some sed processing. Anyway, I've been working on it in the meantime and finished it, leaving the original comments intact, as well as complete ODE 0.12 API macros and odemath inclusive: https://github.com/quaker66/ODE-D It's structured like any other Deimos project. I've added a Deimos project. Can you do a pull request to add it in? https://github.com/D-Programming-Deimos/ODE
Re: Deimos - ODE bindings
On Sunday, 1 April 2012 at 18:32:05 UTC, Walter Bright wrote: On 4/1/2012 7:11 AM, q66 wrote: I'm currently writing ODE plain C-D bindings and I have a question about requirements for inclusion into Deimos; is it required to keep the original documentation comments in the .d files? I see all Deimos projects include them, but IMO they are not too useful, as they are already present in the C headers, they just make it look ugly. I'd like them so that someone can easily compare the D versions with the C versions. Leaving the comments in will make that comparison easier. Figured so. I was asking because I ported ODE D bindings from Derelict 2 to Derelict 3 and making it without comments would be basically just about some sed processing. Anyway, I've been working on it in the meantime and finished it, leaving the original comments intact, as well as complete ODE 0.12 API macros and odemath inclusive: https://github.com/quaker66/ODE-D It's structured like any other Deimos project.
Re: Deimos - ODE bindings
On 4/1/2012 7:11 AM, q66 wrote: I'm currently writing ODE plain C-D bindings and I have a question about requirements for inclusion into Deimos; is it required to keep the original documentation comments in the .d files? I see all Deimos projects include them, but IMO they are not too useful, as they are already present in the C headers, they just make it look ugly. I'd like them so that someone can easily compare the D versions with the C versions. Leaving the comments in will make that comparison easier.
Re: traits getProtection
Code: https://github.com/D-Programming-Language/dmd/pull/856
traits getProtection
I've prepared a dmd pull request to add a new __trait:
getProtection.
It is meant to be used along with getMember() to add to
the reflection capabilities, letting us use the existing
protection qualifiers as strings.
From the test:
==
class Test {
public int a;
private int b;
export string c;
protected int d;
package void e() {}
}
void main() {
Test t;
static assert(__traits(getProtection, __traits(getMember, t,
"a")) == "public");
static assert(__traits(getProtection, __traits(getMember, t,
"b")) == "private");
static assert(__traits(getProtection, __traits(getMember, t,
"c")) == "export");
static assert(__traits(getProtection, __traits(getMember, t,
"d")) == "protected");
static assert(__traits(getProtection, __traits(getMember, t,
"e")) == "package");
}
==
This will help D automatically generate things like
external interfaces that use the protections.
For instance, I plan to use it in my web.d to only
make functions marked "export" available via the
web interface. Currently, you have to use a naming
convention to hide functions - a leading underscore -
even on private members. This is ok, but not great.
But with the protection trait, we can mark it with
a much more natural "private", or any of the other
specifiers D has.
I'm sure other uses will come up too.
Re: Creating a shared library in D : undefined symbol: _deh_beg
On Sunday, 1 April 2012 at 13:16:50 UTC, Jacob Carlborg wrote: On 2012-03-31 22:13, "Timo Westkämper" " wrote: I just created a shared library in D using DMD in Ubuntu and run into the following error when trying to use it undefined symbol: _deh_beg I found this old thread where it is suggested to create a dummy main method : http://lists.puremagic.com/pipermail/digitalmars-d/2007-October/026970.html I did that and it fixed the error, but it doesn't seem quite right. My DMD call looks like this dmd -shared -fPIC -I../src -ofbeep.so As far as I know the runtime is not ready for shared libraries yet. I will try something like this http://stackoverflow.com/questions/9758255/d2-calling-writefln-in-d-shared-libraries-from-c-side
Re: D for a Qt developer
On 4/1/2012 7:12 PM, Davita wrote: On Sunday, 1 April 2012 at 07:53:37 UTC, Andrej Mitrovic wrote: On 4/1/12, dsimcha wrote: I think QtD is now usable since the relevant compiler bugs were ironed out. I doubt that it even compiles. The last update was almost a year ago, and I've had access violations with D2 back then. Well, that's what i'm talking about. D is such a wonderful language that it should scream on different forums and sites such as stackoverflow or codeproject, but instead it's very quite, passive. And I think this is due to the lack of quality development tools. :( None of the companies or organizations I know would never start development on DWT or QtD. Shouldn't D team address those issues? I mean, only enthusiasmic community can't do much here. I think a sponsor or some commercial interest is a must, or as I already mentioned above, to work with Nokia guys and bring D with QtCreator. Or maybe to work with MS and integrate D in VS and WinRT api. If one big organization starts using D, then more and more people will have trust in D and start using it. Otherwise I don't think the future of D will be as bright as it should :( The core D "team" already have enough on their plates in developing the DMD compiler, DRuntime, and Phobos. There's just not enough manpower there to go off on tangents, however beneficial they may be. It's a matter of priorities. For the time being, that sort of thing has to be community-driven. The situation now is a far sight better than it used to be. Eventually, the tool chain will be there and those who can't live without all of the frilly bells and whistles will be satisfied. Until that time, those of us who *can* live without all of that can use D quite happily. And the more of us who do, the closer we get to Nirvana. Baby steps and all that.
Deimos - ODE bindings
I'm currently writing ODE plain C-D bindings and I have a question about requirements for inclusion into Deimos; is it required to keep the original documentation comments in the .d files? I see all Deimos projects include them, but IMO they are not too useful, as they are already present in the C headers, they just make it look ugly. Thx
Re: Breaking backwards compatiblity
the ABI of linux is good enough, it's based on a mature os : UNIX. forget the name of D, name is not important. There is no need for a replacement for c in OS area, because c is the best high level language match current CPU architecture Why c++ is so complexity? because the cpu architecture is not object oriented. energy save, high performance, develop effective, in the area focus on these, is the market for D : "Half" system program language. and the big point for growth, can call c/c++ binary from D source. sorry about digressing from the subject. 2012/3/10 Walter Bright > On 3/9/2012 3:09 PM, Nick Sabalausky wrote: > >> Keep in mind, too, that Linux has decades of legacy and millions of users. >> That's a *very* different situation from Phobos. Apples and oranges. >> > > Linux has had a habit of not breaking existing code from decades ago. I > think that is one reason why it has millions of users. > > Remember, every time you break existing code you reset your user base back > to zero. > > I'm *still* regularly annoyed by the writefln => writeln change in D1 to > D2, and I agreed to that change. G. >
Re: D for a Qt developer
On 2012-04-01 00:13, dsimcha wrote: On 3/31/2012 4:23 PM, Davita wrote: 3) Crypto libs for hashing and with asymmetric algorithm implementations. You would probably be best off linking to a C library for this. The headers are in Deimos. https://github.com/D-Programming-Deimos/openssl Tango has some kind of support for cryptography. 5) networking libs with several main protocol implementations such as Http, FTP and SMTP. std.net.curl was just added to the latest Phobos release. Tango also have some net related modules. 6) and of course, RAD styled IDE. Visual D might do what you want. You could also have a look at the Eclipse plugin DDT: http://code.google.com/a/eclipselabs.org/p/ddt/ -- /Jacob Carlborg
Re: Creating a shared library in D : undefined symbol: _deh_beg
On 2012-03-31 22:13, "Timo Westkämper" " wrote: I just created a shared library in D using DMD in Ubuntu and run into the following error when trying to use it undefined symbol: _deh_beg I found this old thread where it is suggested to create a dummy main method : http://lists.puremagic.com/pipermail/digitalmars-d/2007-October/026970.html I did that and it fixed the error, but it doesn't seem quite right. My DMD call looks like this dmd -shared -fPIC -I../src -ofbeep.so As far as I know the runtime is not ready for shared libraries yet. -- /Jacob Carlborg
Re: D for a Qt developer
On Sun, 01 Apr 2012 12:12:43 +0200 "Davita" wrote: > Well, that's what i'm talking about. D is such a wonderful > language that it should scream on different forums and sites such > as stackoverflow or codeproject, but instead it's very quite, > passive. And I think this is due to the lack of quality > development tools. :( Well, Andrej is heavily working on new wxD...that's definitely something for C++, although not necessarily, Qt developer. ;) Sincerely, Gour -- There is no work that affects Me; nor do I aspire for the fruits of action. One who understands this truth about Me also does not become entangled in the fruitive reactions of work. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: D for a Qt developer
On Sunday, 1 April 2012 at 07:53:37 UTC, Andrej Mitrovic wrote: On 4/1/12, dsimcha wrote: I think QtD is now usable since the relevant compiler bugs were ironed out. I doubt that it even compiles. The last update was almost a year ago, and I've had access violations with D2 back then. Well, that's what i'm talking about. D is such a wonderful language that it should scream on different forums and sites such as stackoverflow or codeproject, but instead it's very quite, passive. And I think this is due to the lack of quality development tools. :( None of the companies or organizations I know would never start development on DWT or QtD. Shouldn't D team address those issues? I mean, only enthusiasmic community can't do much here. I think a sponsor or some commercial interest is a must, or as I already mentioned above, to work with Nokia guys and bring D with QtCreator. Or maybe to work with MS and integrate D in VS and WinRT api. If one big organization starts using D, then more and more people will have trust in D and start using it. Otherwise I don't think the future of D will be as bright as it should :(
Re: Creating a shared library in D : undefined symbol: _deh_beg
The compiler is able to generater position independant code but as far as I remember, there are still some issues in druntime which make it difficult to create dynamic librarys in D. You need to somehow initialize the runtime.
Re: D for a Qt developer
On 4/1/12, dsimcha wrote: > I think QtD is now usable since the relevant compiler bugs were ironed out. I doubt that it even compiles. The last update was almost a year ago, and I've had access violations with D2 back then.
