www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Compiled dmd2.032 in VC++ 2009!

reply Jeremie Pelletier <jeremiep gmail.com> writes:
Well I've decided to get a look at the dmd2 source and see what I can
contribute to it, only to notice it is very VC++ unfriendly. After a few hours
of work, I finally got it to compile, and it works great, for the most part.

VC++ has no real support for long double; it supports the syntax as distinct
types but they are implemented as double precision, not extended precision.
There are no stdint.h and fenv.h headers, I found isnan() in float.h but I had
to leave out backend/strtold.c for now, there was no unresolved references from
this. alloca() was also found in malloc.h, not stdlib.h. The joys of not using
a C99 compliant compiler heh. I also couldn't get the compiler to compile *.c
as C++, even with the /TP switch (Compile as C++), I had to rename every file
to *.cpp.

Other than that, it was standard compilation, I disabled a few warnings to not
get my output flooded, defined MARS, __I86__ and _DH, generated the different
table files, and compiled, all from within the IDE.

Jumping back in C++ reminded me why I loved D so much, I will definitely start
working on, or help developing it if already planned, a D port of dmd once the
spec gets stable.

In any ways, I am wondering where I can submit my changes for review, since I
doubt there is any public access to the repository on dsource, and I would very
much like to contribute to the D programming language.
Sep 03 2009
next sibling parent reply Don <nospam nospam.com> writes:
Jeremie Pelletier wrote:
 Well I've decided to get a look at the dmd2 source and see what I can
 contribute to it, only to notice it is very VC++ unfriendly. After a
 few hours of work, I finally got it to compile, and it works great,
 for the most part.
 
 VC++ has no real support for long double; it supports the syntax as
 distinct types but they are implemented as double precision, not
 extended precision. There are no stdint.h and fenv.h headers, I found
 isnan() in float.h but I had to leave out backend/strtold.c for now,
 there was no unresolved references from this. alloca() was also found
 in malloc.h, not stdlib.h. The joys of not using a C99 compliant
 compiler heh. I also couldn't get the compiler to compile *.c as C++,
 even with the /TP switch (Compile as C++), I had to rename every file
 to *.cpp.
 
 Other than that, it was standard compilation, I disabled a few
 warnings to not get my output flooded, defined MARS, __I86__ and _DH,
 generated the different table files, and compiled, all from within
 the IDE.

What are the advantages of VC++? Just the browsing?
 Jumping back in C++ reminded me why I loved D so much, I will
 definitely start working on, or help developing it if already
 planned, a D port of dmd once the spec gets stable.

Oh yeah. Looking at the source, I keep thinking, "this would be SO much easier in D!". Interestingly since DMD has extern(C++), it ought to be possible to convert a single module to D, and still link it in...
 In any ways, I am wondering where I can submit my changes for review,
 since I doubt there is any public access to the repository on
 dsource, and I would very much like to contribute to the D
 programming language.

It'd be fantastic if you could help. I've just been submitting my patches to Bugzilla. Walter sends me his source from time to time. If you get active enough with patches we'll make a better arrangement. It's only yesterday that Walter made a commit to the repository for the first time, so at least he has it set up now <g>. I suggest that to start off, you look at the .stringof bugs. .stringof has a reputation as one of the most buggy features in the compiler, but I think it's only because of neglect rather than being particularly complicated.
Sep 04 2009
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Don Wrote:

 Interestingly since DMD has extern(C++), it ought to be possible to 
 convert a single module to D, and still link it in...

extern(C++) support in D is nearly a joke. There are some big areas for improvement, such as support for non-virtual functions, or allowing use of new, ... It's unusable to the point that I can't connect D code to existing C++ or even write efficient wrappers. I've resorted to simply using extern(C) code in C++ and then wrappers in D to use those functions...
Sep 04 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Jason House Wrote:

 Don Wrote:
 
 Interestingly since DMD has extern(C++), it ought to be possible to 
 convert a single module to D, and still link it in...

extern(C++) support in D is nearly a joke. There are some big areas for improvement, such as support for non-virtual functions, or allowing use of new, ... It's unusable to the point that I can't connect D code to existing C++ or even write efficient wrappers. I've resorted to simply using extern(C) code in C++ and then wrappers in D to use those functions...

From what I know it was mostly intended for interfaces, and it works wonders when binding to COM code in Windows. A lot of the new features of recent windows versions are only available through COM, extern(C++) makes it dead easy to write their bindings.
Sep 04 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
Jarrett Billingsley Wrote:

 On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier<jeremiep gmail.com> wrote:
 Jason House Wrote:

 Don Wrote:

 Interestingly since DMD has extern(C++), it ought to be possible to
 convert a single module to D, and still link it in...

extern(C++) support in D is nearly a joke. There are some big areas for improvement, such as support for non-virtual functions, or allowing use of new, ... It's unusable to the point that I can't connect D code to existing C++ or even write efficient wrappers. I've resorted to simply using extern(C) code in C++ and then wrappers in D to use those functions...

From what I know it was mostly intended for interfaces, and it works wonders when binding to COM code in Windows. A lot of the new features of recent windows versions are only available through COM, extern(C++) makes it dead easy to write their bindings.

You've been able to bind to COM interfaces in D for years. extern(C++) hasn't changed that, as far as I know.

True, but it has not always been that simple, now I can take the IDL file, run it through a few regular expressions and I got my D binding :) extern(C++): interface ID2D1Factory : IUnknown { ... } I don't remember what the syntax in D1 looks like for COM interfacing, but I remember having some issues writing bindings.
Sep 04 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 04 Sep 2009 13:40:02 +0400, Don <nospam nospam.com> wrote:

 Jeremie Pelletier wrote:
 Well I've decided to get a look at the dmd2 source and see what I can
 contribute to it, only to notice it is very VC++ unfriendly. After a
 few hours of work, I finally got it to compile, and it works great,
 for the most part.
  VC++ has no real support for long double; it supports the syntax as
 distinct types but they are implemented as double precision, not
 extended precision. There are no stdint.h and fenv.h headers, I found
 isnan() in float.h but I had to leave out backend/strtold.c for now,
 there was no unresolved references from this. alloca() was also found
 in malloc.h, not stdlib.h. The joys of not using a C99 compliant
 compiler heh. I also couldn't get the compiler to compile *.c as C++,
 even with the /TP switch (Compile as C++), I had to rename every file
 to *.cpp.
  Other than that, it was standard compilation, I disabled a few
 warnings to not get my output flooded, defined MARS, __I86__ and _DH,
 generated the different table files, and compiled, all from within
 the IDE.

What are the advantages of VC++? Just the browsing?

Wonderful debugging capabilities. That's a *huge* advantage.
Sep 04 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier<jeremiep gmail.com> wrot=
e:
 Jason House Wrote:

 Don Wrote:

 Interestingly since DMD has extern(C++), it ought to be possible to
 convert a single module to D, and still link it in...

extern(C++) support in D is nearly a joke. There are some big areas for =


new, ... It's unusable to the point that I can't connect D code to existing= C++ or even write efficient wrappers. I've resorted to simply using extern= (C) code in C++ and then wrappers in D to use those functions...
 From what I know it was mostly intended for interfaces, and it works wond=

t windows versions are only available through COM, extern(C++) makes it dea= d easy to write their bindings. You've been able to bind to COM interfaces in D for years. extern(C++) hasn't changed that, as far as I know.
Sep 04 2009
prev sibling next sibling parent Jeremie Pelletier <jeremiep gmail.com> writes:
Don Wrote:

 Jeremie Pelletier wrote:
 Well I've decided to get a look at the dmd2 source and see what I can
 contribute to it, only to notice it is very VC++ unfriendly. After a
 few hours of work, I finally got it to compile, and it works great,
 for the most part.
 
 VC++ has no real support for long double; it supports the syntax as
 distinct types but they are implemented as double precision, not
 extended precision. There are no stdint.h and fenv.h headers, I found
 isnan() in float.h but I had to leave out backend/strtold.c for now,
 there was no unresolved references from this. alloca() was also found
 in malloc.h, not stdlib.h. The joys of not using a C99 compliant
 compiler heh. I also couldn't get the compiler to compile *.c as C++,
 even with the /TP switch (Compile as C++), I had to rename every file
 to *.cpp.
 
 Other than that, it was standard compilation, I disabled a few
 warnings to not get my output flooded, defined MARS, __I86__ and _DH,
 generated the different table files, and compiled, all from within
 the IDE.

What are the advantages of VC++? Just the browsing?

It has one of the most powerful IDEs I have seen so far, and its debugging support is amazing. I also think its a good idea to make the dmd source compilable on a few different compilers, it will allow a wider range of developers to contribute to it in the long run.
 Jumping back in C++ reminded me why I loved D so much, I will
 definitely start working on, or help developing it if already
 planned, a D port of dmd once the spec gets stable.

Oh yeah. Looking at the source, I keep thinking, "this would be SO much easier in D!". Interestingly since DMD has extern(C++), it ought to be possible to convert a single module to D, and still link it in...
 In any ways, I am wondering where I can submit my changes for review,
 since I doubt there is any public access to the repository on
 dsource, and I would very much like to contribute to the D
 programming language.

It'd be fantastic if you could help. I've just been submitting my patches to Bugzilla. Walter sends me his source from time to time. If you get active enough with patches we'll make a better arrangement. It's only yesterday that Walter made a commit to the repository for the first time, so at least he has it set up now <g>. I suggest that to start off, you look at the .stringof bugs. .stringof has a reputation as one of the most buggy features in the compiler, but I think it's only because of neglect rather than being particularly complicated.

Sure, I'll give it a look, I need to get familiar with the code structure anyways :)
Sep 04 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Fri, Sep 4, 2009 at 3:19 PM, Jeremie Pelletier<jeremiep gmail.com> wrote=
:
 Jarrett Billingsley Wrote:

 On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier<jeremiep gmail.com> w=


 Jason House Wrote:

 Don Wrote:

 Interestingly since DMD has extern(C++), it ought to be possible to
 convert a single module to D, and still link it in...

extern(C++) support in D is nearly a joke. There are some big areas f=




of new, ... It's unusable to the point that I can't connect D code to exist= ing C++ or even write efficient wrappers. I've resorted to simply using ext= ern(C) code in C++ and then wrappers in D to use those functions...
 From what I know it was mostly intended for interfaces, and it works w=



cent windows versions are only available through COM, extern(C++) makes it = dead easy to write their bindings.
 You've been able to bind to COM interfaces in D for years. extern(C++)
 hasn't changed that, as far as I know.

True, but it has not always been that simple, now I can take the IDL file=

 extern(C++):
 interface ID2D1Factory : IUnknown { ... }

 I don't remember what the syntax in D1 looks like for COM interfacing, bu=

It's basically the same. I think you just have to put extern(Windows): inside each interface, but that's it.
Sep 04 2009
prev sibling parent BLS <windevguy hotmail.de> writes:
Don wrote:

 Oh yeah. Looking at the source, I keep thinking, "this would be SO much 
 easier in D!".

May I add : more reliable, more readable, more IDE friendly, more "eat your own dog food inside (tm)" ? ... and NO, don't want to hear anything about bootstrapping :)
Sep 04 2009
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jeremie Pelletier:

VC++ has no real support for long double; it supports the syntax as distinct
types but they are implemented as double precision, not extended precision.<

This is true in GDC (with GCC backend) too, that's why real in D are as large as possible and not fixed-sized as the other types.
I also couldn't get the compiler to compile *.c as C++, even with the /TP
switch (Compile as C++), I had to rename every file to *.cpp.<

This looks like a change good to be folded back into DMD sources.
Jumping back in C++ reminded me why I loved D so much, I will definitely start
working on, or help developing it if already planned, a D port of dmd once the
spec gets stable.<

This is a good idea. There are the DIL (and Dlang?) projects, but the idea of just porting DMD sources to D sounds nice. Do you want to use D1 or D2 to write such code? A good starting point for this idea of yours is to (eventually, probably not in the beginning) use the D bindings for LLVM, use the LDC front-end and slowly translate it to D1, using LDC itself to compile the modules written in D: http://svn.dsource.org/projects/llvmdc/binding/ If you do that to do that I think other people will help you. This LDC version has to work correctly first, even if its code looks a little like C++ still here and there, and to be slowly refractored when possible later. Having a real and large enough program written in D (this dLDC compiler) is also a way to test the D1 language and see where it can be improved. ---------------------------- Don:
What are the advantages of VC++? Just the browsing?<

The resulting compiler is probably quite faster, so it compiles faster. And generally it's good to be able to compile some C/C++ code with different compilers, because they spot different troubles in the code (with warnings too), and they are strict (regarding the language specs) in different ways, so they help make the code more standard and long lasting. Bye, bearophile
Sep 04 2009
parent reply Leandro Lucarella <llucax gmail.com> writes:
bearophile, el  4 de septiembre a las 08:15 me escribiste:
 Jeremie Pelletier:
 
VC++ has no real support for long double; it supports the syntax as distinct
types but they are implemented as double precision, not extended precision.<

This is true in GDC (with GCC backend) too, that's why real in D are as large as possible and not fixed-sized as the other types.
I also couldn't get the compiler to compile *.c as C++, even with the /TP
switch (Compile as C++), I had to rename every file to *.cpp.<

This looks like a change good to be folded back into DMD sources.

I offered myself to do such a change in the past, but Walter didn't liked it. I did it for purely aesthetic reasons, though, maybe if that is useful in some way he'll accept the change. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA. -- Crónica TV
Sep 04 2009
parent reply Brad Roberts <braddr bellevue.puremagic.com> writes:
On Fri, 4 Sep 2009, Leandro Lucarella wrote:

 bearophile, el  4 de septiembre a las 08:15 me escribiste:
 Jeremie Pelletier:
 
VC++ has no real support for long double; it supports the syntax as distinct
types but they are implemented as double precision, not extended precision.<

This is true in GDC (with GCC backend) too, that's why real in D are as large as possible and not fixed-sized as the other types.
I also couldn't get the compiler to compile *.c as C++, even with the /TP
switch (Compile as C++), I had to rename every file to *.cpp.<

This looks like a change good to be folded back into DMD sources.

I offered myself to do such a change in the past, but Walter didn't liked it. I did it for purely aesthetic reasons, though, maybe if that is useful in some way he'll accept the change. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- ASALTAN, GOLPEAN SALVAJEMENTE A ANCIANA Y LE COMEN LA PASTAFROLA. -- Cr?nica TV

Don't consider it an all or nothing exercise. I'll bet there are parts that are easy to agree are generally useful and worth folding in. That can at least make life easier by keeping the unmerged parts smaller and hopefully less painful to deal with. Later, Brad
Sep 04 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Brad Roberts wrote:
 Don't consider it an all or nothing exercise.  I'll bet there are 
 parts that are easy to agree are generally useful and worth folding in.  
 That can at least make life easier by keeping the unmerged parts smaller 
 and hopefully less painful to deal with.

Yup.
Sep 04 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jeremie Pelletier wrote:
 Well I've decided to get a look at the dmd2 source and see what I can
 contribute to it, only to notice it is very VC++ unfriendly. After a
 few hours of work, I finally got it to compile, and it works great,
 for the most part.

Can you send me the diffs?
 
 VC++ has no real support for long double; it supports the syntax as
 distinct types but they are implemented as double precision, not
 extended precision.

There are two routes to go here, one is to just make a D that uses only double precision for real precision, the other is to write a simple emulator for 80 bit reals so the compiler can still generate 80 bit real code despite the shortcomings in VC++.
 In any ways, I am wondering where I can submit my changes for review,
 since I doubt there is any public access to the repository on
 dsource, and I would very much like to contribute to the D
 programming language.

Bugzilla is a good place to start.
Sep 04 2009
next sibling parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Walter Bright Wrote:

 Jeremie Pelletier wrote:
 Well I've decided to get a look at the dmd2 source and see what I can
 contribute to it, only to notice it is very VC++ unfriendly. After a
 few hours of work, I finally got it to compile, and it works great,
 for the most part.

Can you send me the diffs?

Sure, as soon as I figure out why my dmd produces different object code than yours. I ran a simple hello world executable and the "hello world" string is not properly aligned in the resulting executable, causing garbage to be appended by printf. The bug is somewhere between the parsing, which works fine, and the object generation (the call to obj_bytes() has the proper data pointer, but incorrect nbytes count).
 
 VC++ has no real support for long double; it supports the syntax as
 distinct types but they are implemented as double precision, not
 extended precision.

There are two routes to go here, one is to just make a D that uses only double precision for real precision, the other is to write a simple emulator for 80 bit reals so the compiler can still generate 80 bit real code despite the shortcomings in VC++.
 In any ways, I am wondering where I can submit my changes for review,
 since I doubt there is any public access to the repository on
 dsource, and I would very much like to contribute to the D
 programming language.

Bugzilla is a good place to start.

Sep 05 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Jeremie Pelletier Wrote:

 Walter Bright Wrote:
 
 Jeremie Pelletier wrote:
 Well I've decided to get a look at the dmd2 source and see what I can
 contribute to it, only to notice it is very VC++ unfriendly. After a
 few hours of work, I finally got it to compile, and it works great,
 for the most part.

Can you send me the diffs?

Sure, as soon as I figure out why my dmd produces different object code than yours. I ran a simple hello world executable and the "hello world" string is not properly aligned in the resulting executable, causing garbage to be appended by printf. The bug is somewhere between the parsing, which works fine, and the object generation (the call to obj_bytes() has the proper data pointer, but incorrect nbytes count).

Finally found the bug, which was within a change I made in obj_bytes() to get it to compile under VC++, but didn't take in account the goto statement :x At least this little debugging session got me familiar with how dmd and dmc works. Anywho, the patch file is about 1000 lines long, where should I mail it? I also made a simple D script to rename all c files to cpp: --- module conv; import core.stdc.stdlib, core.stdc.stdio, std.file; int main(string[] args) { if(args.length != 2) goto Error; bool isDir = void; try isDir = isdir(args[1]); catch(FileException) {} if(!isDir) goto Error; char[256] newpath = void; bool delegate(DirEntry*) dg = void; bool rename(DirEntry* de) { if(de.name[$-2 .. $] == ".c") { newpath[0 .. de.name.length] = de.name[]; newpath[de.name.length .. de.name.length + 2] = "pp"; .rename(de.name, newpath[0 .. de.name.length + 2]); } else if(de.isdir() && de.name[$-2 .. $] != "tk") listdir(de.name, dg); return true; } dg = &rename; listdir(args[1], dg); return 0; Error: printf("Usage: %.*s <path>", args[0]); return 1; } ---
Sep 05 2009
next sibling parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremie Pelletier wrote:
<snip>

Sweet. If dmd can compile w/ VS outa the box, I'll start poking around
in it. Hey you can knock mirco-soft all you like, but VS is the nuts.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFKowrzT9LetA9XoXwRAvK+AJ95PuQklaqIz2Xxrx+uIF93ZyuiwgCfTgAH
Z696k57Jmwak++Kd+yayN2U=
=tw8D
-----END PGP SIGNATURE-----
Sep 05 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
div0 Wrote:
 Jeremie Pelletier wrote:
 <snip>
 
 Sweet. If dmd can compile w/ VS outa the box, I'll start poking around
 in it. Hey you can knock mirco-soft all you like, but VS is the nuts.

Yeah, I side with you here. I may not be a fan of the business model Microsoft uses, but their IDE is oh so sweet. I wish D had such a powerful and full-featured IDE. I use Descent on Ubuntu and Poseidon on Windows; both have their pros and cons yet I don't feel at home like I do in VS in either of them. Poseidon is simple, light and fast, but doesn't have that many features, although the customizable syntax highlighter, project manager and very simple build process are awesome. Descent on the other hand has a very nice syntax analyzer and tons of features, but requires eclipse which is too heavy for my tastes (thanks to java), has no syntax customization so new keywords are marked as errors, and the build process is a pain to setup, even with ant. Anywho, I've sent my patch for VC++ compatibility to Walter, hopefully the changes will get into the next dmd release.
 - --
 My enormous talent is exceeded only by my outrageous laziness.
 http://www.ssTk.co.uk

I've seen that quote in a comment on slashdot a few weeks ago!
Sep 05 2009
parent reply div0 <div0 users.sourceforge.net> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeremie Pelletier wrote:
 div0 Wrote:
 Jeremie Pelletier wrote:
 <snip>

 Sweet. If dmd can compile w/ VS outa the box, I'll start poking around
 in it. Hey you can knock mirco-soft all you like, but VS is the nuts.

Yeah, I side with you here. I may not be a fan of the business model Microsoft uses, but their IDE is oh so sweet. I wish D had such a powerful and full-featured IDE. I use Descent on Ubuntu and Poseidon on Windows; both have their pros and cons yet I don't feel at home like I do in VS in either of them. Poseidon is simple, light and fast, but doesn't have that many features, although the customizable syntax highlighter, project manager and very simple build process are awesome. Descent on the other hand has a very nice syntax analyzer and tons of features, but requires eclipse which is too heavy for my tastes (thanks to java), has no syntax customization so new keywords are marked as errors, and the build process is a pain to setup, even with ant. Anywho, I've sent my patch for VC++ compatibility to Walter, hopefully the changes will get into the next dmd release.

Nice. How about the project files? They going to be in as well or at least dl-able from somewhere?
 - --
 My enormous talent is exceeded only by my outrageous laziness.
 http://www.ssTk.co.uk

I've seen that quote in a comment on slashdot a few weeks ago!

It's not a quote. It's original to myself; I've only ever used it in this NG from a couple of years back. Though it wouldn't surprise me if somebody else came up with it as well. Seems like an obvious one... I staring reading slashdot back when it was called Chips and technology, but the signal to noise ratio dropped too low for my liking. It started going downhill the day they added user comments and accelerated once that open source company got involved. I had a div0 account there, but I don't recall ever making a comment. Haven't been back there in years. Nick Sabalausky asked if he could appropriate it a while back, maybe he posts on slashdot. - -- My enormous talent is exceeded only by my outrageous laziness. http://www.ssTk.co.uk -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFKo7fdT9LetA9XoXwRAq/1AKCB50IWA64eUN4QNXsWW5GKNNGsNACfSdLQ xrnIzw6PjGLnrTriH5Viq6o= =AClk -----END PGP SIGNATURE-----
Sep 06 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
div0 Wrote:
 Jeremie Pelletier wrote:
 div0 Wrote:
 Jeremie Pelletier wrote:
 <snip>

 Sweet. If dmd can compile w/ VS outa the box, I'll start poking around
 in it. Hey you can knock mirco-soft all you like, but VS is the nuts.

Yeah, I side with you here. I may not be a fan of the business model Microsoft uses, but their IDE is oh so sweet. I wish D had such a powerful and full-featured IDE. I use Descent on Ubuntu and Poseidon on Windows; both have their pros and cons yet I don't feel at home like I do in VS in either of them. Poseidon is simple, light and fast, but doesn't have that many features, although the customizable syntax highlighter, project manager and very simple build process are awesome. Descent on the other hand has a very nice syntax analyzer and tons of features, but requires eclipse which is too heavy for my tastes (thanks to java), has no syntax customization so new keywords are marked as errors, and the build process is a pain to setup, even with ant. Anywho, I've sent my patch for VC++ compatibility to Walter, hopefully the changes will get into the next dmd release.

Nice. How about the project files? They going to be in as well or at least dl-able from somewhere?

I also mailed them to Walter.
 - --
 My enormous talent is exceeded only by my outrageous laziness.
 http://www.ssTk.co.uk

I've seen that quote in a comment on slashdot a few weeks ago!

It's not a quote. It's original to myself; I've only ever used it in this NG from a couple of years back. Though it wouldn't surprise me if somebody else came up with it as well. Seems like an obvious one... I staring reading slashdot back when it was called Chips and technology, but the signal to noise ratio dropped too low for my liking. It started going downhill the day they added user comments and accelerated once that open source company got involved. I had a div0 account there, but I don't recall ever making a comment. Haven't been back there in years. Nick Sabalausky asked if he could appropriate it a while back, maybe he posts on slashdot.

Well it's a great quote, made me laugh out loud the first time I saw it :)
Sep 06 2009
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jeremie Pelletier:
 I also made a simple D script to rename all c files to cpp:

Generally I suggest to use a scripting language to do a similar task (or a simper linux shell script, probably one or two lines), but I agree that doing this I can't see possible faults/troubles of the same D code. So in the end writing it in D is a good experiment. You are probably an expert programmer, yet in your script I see some things that in my opinion are better done in other ways: - Don't init things to void unless your performance experiment tells you to, and do it with care. This is explained in D documentation too. The speed gain is very limited and the risk of giving false pointers to the conservative GC is present, because currently it's not very precise. - Gotos aren't evil, but it's better to use them only as performance optimization or for tricky flows of the code. Generally in D there are better ways to solve such problems. For example you can just throw an exception if args.length!=2, and the uncaught exception will show an error message to the user and the code will stop. - try ... catch(FileException) {} looks not nice. - if(de.name[$-2 .. $] == ".c") is a bit unsafe, because unlike Python D slices aren't saturating (and in the meantime I have asked to the Python developers, they have told me that this design is desired in Python, it's not a design mistake left for backward compatibility as someone here told me. And it's a very handy thing. The only advantage of the way D slices are done is that D ones are a bit faster. But their unsafety unnerves me and forces me to write uglier and longer code). Generally it's better to use string functions, that are safer. Python has endswith() and startwith() string methods that in D (as functions) are even more important. - In D the main doesn't need to return an int in an explicit way. If your program stops because you have thrown and exception, I think the return value is not zero. - Generally don't use this: printf("Usage: %.*s <path>", args[0]); printf() is good mostly to speed up output if you have to print tons of things, or in debugging write* functions, or for a simple compatibility with Tango. Generally use writeln or writefln. - Unless performance is critical, it's generally better to write script-like D programs in a high-level style, because in such kind of programs the purpose is to write the code quickly, to have readable code, and most of all to have the most reliable code as possible. In such small programs saving microseconds is usually not positive. - Note for D developers, listdir() desiged like that isn't good. Python too used to have something similar (os.path.walk()), but it's better to invent its design, and give an interable that instead yields the nodes of the tree (os.walk() from Python 2.3). Bye, bearophile
Sep 05 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
bearophile Wrote:

 Jeremie Pelletier:
 I also made a simple D script to rename all c files to cpp:

Generally I suggest to use a scripting language to do a similar task (or a simper linux shell script, probably one or two lines), but I agree that doing this I can't see possible faults/troubles of the same D code. So in the end writing it in D is a good experiment.

D can be used as a scripting language too, and it's cross platform, plus it was a good test for my newly compiled dmd.
 You are probably an expert programmer, yet in your script I see some things
that in my opinion are better done in other ways:
 - Don't init things to void unless your performance experiment tells you to,
and do it with care. This is explained in D documentation too. The speed gain
is very limited and the risk of giving false pointers to the conservative GC is
present, because currently it's not very precise.

I am well aware of what =void implies, I had this habit ever since my first steps into D. The only times I don't use =void on variable declarations is when i want them to be initialized to their default values.
 - Gotos aren't evil, but it's better to use them only as performance
optimization or for tricky flows of the code. Generally in D there are better
ways to solve such problems. For example you can just throw an exception if
args.length!=2, and the uncaught exception will show an error message to the
user and the code will stop.

I generally don't use them a lot except to move error handling to the footer of a function or replace for(;;) loops. The dmd and druntime sources (I think phobos too) are full of such gotos anyways!
 - try ... catch(FileException) {} looks not nice.

Agreed, but it does what I want it to; redirect the exception to the Error label.
 - if(de.name[$-2 .. $] == ".c") is a bit unsafe, because unlike Python D
slices aren't saturating (and in the meantime I have asked to the Python
developers, they have told me that this design is desired in Python, it's not a
design mistake left for backward compatibility as someone here told me. And
it's a very handy thing. The only advantage of the way D slices are done is
that D ones are a bit faster. But their unsafety unnerves me and forces me to
write uglier and longer code). Generally it's better to use string functions,
that are safer. Python has endswith() and startwith() string methods that in D
(as functions) are even more important.

I don't see how unsafe that is in this context. I know it can be unsafe sometimes to send a slice to be saved somewhere, and later modify the original array. I only use slices to pass data around. As soon as a slice leaves the scope it is in (ie, assigning it to a property) or the original array is shared between threads, I use copies. Besides, with the upcoming T[new] arrays, we're gonna see a major change in how arrays are used in D which should solve a lot of the current issues with slices. And once the shared qualifier is fully operational, its gonna solve even more issues.
 - In D the main doesn't need to return an int in an explicit way. If your
program stops because you have thrown and exception, I think the return value
is not zero.

Oh yeah, forgot about that one. Old habits again :)
 - Generally don't use this: printf("Usage: %.*s <path>", args[0]); printf() is
good mostly to speed up output if you have to print tons of things, or in
debugging write* functions, or for a simple compatibility with Tango. Generally
use writeln or writefln.

printf isn't that fast, in fact it is quite slow, anything that has to parse the format string on every call is gonna be slow. In this case, writefln caused an unresolved toUTF8 reference which I was too lazy to look into.
 - Unless performance is critical, it's generally better to write script-like D
programs in a high-level style, because in such kind of programs the purpose is
to write the code quickly, to have readable code, and most of all to have the
most reliable code as possible. In such small programs saving microseconds is
usually not positive.

I also agree here, however I'm not all that familiar with higher level concepts, even the PHP code I do at work looks a lot more like systems programming than web scripting, but it runs fast.
 - Note for D developers, listdir() desiged like that isn't good. Python too
used to have something similar (os.path.walk()), but it's better to invent its
design, and give an interable that instead yields the nodes of the tree
(os.walk() from Python 2.3).

 Bye,
 bearophile

Thanks for the comments though, I may argue a lot but I will remember what you said :) J
Sep 05 2009
parent reply Rainer Deyke <rainerd eldwood.com> writes:
Jeremie Pelletier wrote:
 bearophile Wrote:
 - if(de.name[$-2 .. $] == ".c") is a bit unsafe, (...)


Potential buffer underrun. http://www.digitalmars.com/d/1.0/arrays.html: "A program may not rely on array bounds checking happening" -- Rainer Deyke - rainerd eldwood.com
Sep 05 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
Rainer Deyke Wrote:

 Jeremie Pelletier wrote:
 bearophile Wrote:
 - if(de.name[$-2 .. $] == ".c") is a bit unsafe, (...)


Potential buffer underrun. http://www.digitalmars.com/d/1.0/arrays.html: "A program may not rely on array bounds checking happening" -- Rainer Deyke - rainerd eldwood.com

Oh yeah, didn't think about that one here. I usually test for the string length before slicing it.
Sep 05 2009
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Jeremie Pelletier:
I usually test for the string length before slicing it.<

Me too, but: - mammals aren't perfect, and sometimes they forget things, etc. A compiler, once well programmed, will not forget such tests. - such tests added by me and you slow down code a little (but a good compiler can remove some of them, GCC and LLVM are able to). This may mean that the time saved by D slices being non-saturating (unlike Python ones) may be spent anyway by tests added manually by the programmer. If this is true (and I think it may be true, I'd like to instrument LDC to run a slicing-heavy D program with and without saturation in slice bounds to test if I am right here) then the saturating nature of Python slices is better under all points of view, nearly efficiency-neutral too :-) Bye, bearophile
Sep 06 2009
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Jeremie Pelletier wrote:
 Rainer Deyke Wrote:
 
 Jeremie Pelletier wrote:
 bearophile Wrote:
 - if(de.name[$-2 .. $] == ".c") is a bit unsafe, (...)


http://www.digitalmars.com/d/1.0/arrays.html: "A program may not rely on array bounds checking happening" -- Rainer Deyke - rainerd eldwood.com

Oh yeah, didn't think about that one here. I usually test for the string length before slicing it.

Probably the way I'd recommend to carry the test is de.name.endsWith(".c"). Andrei
Sep 06 2009
prev sibling parent reply Don <nospam nospam.com> writes:
Walter Bright wrote:
 Jeremie Pelletier wrote:
 Well I've decided to get a look at the dmd2 source and see what I can
 contribute to it, only to notice it is very VC++ unfriendly. After a
 few hours of work, I finally got it to compile, and it works great,
 for the most part.

Can you send me the diffs?
 VC++ has no real support for long double; it supports the syntax as
 distinct types but they are implemented as double precision, not
 extended precision.

There are two routes to go here, one is to just make a D that uses only double precision for real precision, the other is to write a simple emulator for 80 bit reals so the compiler can still generate 80 bit real code despite the shortcomings in VC++.

Actually I think that even DMD should be using a 128-bit emulator for internal constants, regardless of the machine precision. That's a way off, still, but I think emulator is the way to go, long-term. Likewise, the compiler should not depend on NaNs being handled correctly in the C++ compiler.
Sep 07 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Don:

 I think that even DMD should be using a 128-bit emulator for 
 internal constants, regardless of the machine precision.

Can you tell me why? (Note: LDC supports 128 bit integers too. Maybe even 128 bit floating points).
 the compiler should not depend on NaNs being handled correctly in the 
 C++ compiler.

By "C++ compiler" do you mean the back-end? I think GCC, LLVM, ICC and DMD support NaNs well enough (LLVM supports signaling NaNs too, they say me). Sorry for not understanding your post fully, bye, bearophile
Sep 07 2009
parent Don <nospam nospam.com> writes:
bearophile wrote:
 Don:
 
 I think that even DMD should be using a 128-bit emulator for 
 internal constants, regardless of the machine precision.

Can you tell me why? (Note: LDC supports 128 bit integers too. Maybe even 128 bit floating points).

Because it'd be nice if the language gave a guarantee for how much precision is used in literals. The more of those machine-specific things can be removed, the better.
 the compiler should not depend on NaNs being handled correctly in the 
 C++ compiler.

By "C++ compiler" do you mean the back-end? I think GCC, LLVM, ICC and DMD support NaNs well enough (LLVM supports signaling NaNs too, they say me).

No. I meant the constant folding which the compiler performs. If you write (a==b) in the compiler source code, does it work correctly if a or b is a NaN ?
Sep 08 2009
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Don wrote:
 Actually I think that even DMD should be using a 128-bit emulator for 
 internal constants, regardless of the machine precision. That's a way 
 off, still, but I think emulator is the way to go, long-term. Likewise, 
 the compiler should not depend on NaNs being handled correctly in the 
 C++ compiler.

An emulator wouldn't be hard, I just have to get around to it :-)
Sep 09 2009
prev sibling next sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
For those who like to stick with the DMC compiler to build DMD, but 
still want the bells and whistles of the Visual Studio IDE, here's what 
I do:

- setup a makefile project that builds DMD using win32.mak
- add the source-files to the project to get intellisense support (don't 
forget to add preprocessor-defines MARS,DEBUG,etc. to the project settings)
- add the line
   cv2pdb -C dmd.exe
somewhere appropriate (e.g. the debdmd target) in win32.mak to get 
source level debugging on dmd.exe

You'll need cv2pdb from http://www.dsource.org/projects/cv2pdb

(sorry for the advertisement, but I could not resist ;-) ).

Rainer
Sep 07 2009
prev sibling parent reply negerns <negerns gmail.com> writes:
Jeremie,

I tried compiling the sources using VS2008 SP1. I did run into some of 
what you mentioned but got stuck midway. Could you elaborate on how you 
dealt with the missing header complex.h?
Sep 08 2009
parent reply Jeremie Pelletier <jeremiep gmail.com> writes:
negerns Wrote:

 Jeremie,
 
 I tried compiling the sources using VS2008 SP1. I did run into some of 
 what you mentioned but got stuck midway. Could you elaborate on how you 
 dealt with the missing header

#ifndef _MSC_VER #include <complex.h> #endif You don't need this header on VS.
Sep 08 2009
parent reply negerns <negerns gmail.com> writes:
I ran into the __pascal calling convention. VS2008 no longer support

The __pascal calling convention is no longer supported in VS2008. How 
did you resolve this?
Sep 09 2009
parent Jeremie Pelletier <jeremiep gmail.com> writes:
negerns Wrote:

 I ran into the __pascal calling convention. VS2008 no longer support
 
 The __pascal calling convention is no longer supported in VS2008. How 
 did you resolve this?

I assumed these were remainders of older code, and removed the __pascal from both the prototypes and declarations. You're gonna hit a few other issues, mostly unresolved symbols. In backend/cc.h there's a prototype for cpp_prettyident but no declaration, I hacked it away: inline char *cpp_prettyident (Symbol *s) { return s->Sident; } In cg87.cpp the compiler will whine about not having the M_*_L symbols, just define them as aliases of the * symbols (#define M_PI_L PI). VS has no long double support other than knowing its a different type. In cgobj.cpp the compiler also whines about a few char arrays being out of bounds. I exploded the strings into array literals: "SMCLV" -> {'S','M','C','L','V'}. There are a few of them in the file. In the same file, the compiler string has a hex character in it and VS is too dumb to notice it should be 8 bytes, fix it by breaking the string in two parts: "\0\xDB" "Digital Mars C/C++". Again in the same file, in the function obj_bytes(), VS whines about ((char *)p)++; not being a l-value, just add a local char* variable to use as the pointer, be careful about the goto here, you have to replace p with your variable everywhere in the function, not just the first half. In backend/cod3.cpp, the FLUSH() macro should be the same as the one for ELFOBJ. That's about it, these were the few tricky issues I had, there are plenty more but they are trivial to solve.
Sep 09 2009