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 reply 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 =




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 wond=


ers when binding to COM code in Windows. A lot of the new features of recen=
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
parent reply 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
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=




rote:

 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=








or 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 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=






onders when binding to COM code in Windows. A lot of the new features of re=
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=


, 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, bu=


t I remember having some issues writing bindings.

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 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 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 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, (...)


 I don't see how unsafe that is in this context.


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, (...)


 I don't see how unsafe that is in this context.


 
 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, (...)


 I don't see how unsafe that is in this context.


 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.


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