Re: Compiled dmd2.032 in VC++ 2009!
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 :-)
Re: Compiled dmd2.032 in VC++ 2009!
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.
Re: Compiled dmd2.032 in VC++ 2009!
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?
Re: Compiled dmd2.032 in VC++ 2009!
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 #endif You don't need this header on VS.
Re: Compiled dmd2.032 in VC++ 2009!
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?
Re: Compiled dmd2.032 in VC++ 2009!
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 ?
Re: Compiled dmd2.032 in VC++ 2009!
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
Re: Compiled dmd2.032 in VC++ 2009!
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.
Re: Compiled dmd2.032 in VC++ 2009!
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
Re: Compiled dmd2.032 in VC++ 2009!
div0 Wrote: > Jeremie Pelletier wrote: > > div0 Wrote: > >> Jeremie Pelletier wrote: > >> > >> > >> 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 :)
Re: Compiled dmd2.032 in VC++ 2009!
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 - rain...@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
Re: Compiled dmd2.032 in VC++ 2009!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremie Pelletier wrote: > div0 Wrote: >> Jeremie Pelletier wrote: >> >> >> 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-
Re: Compiled dmd2.032 in VC++ 2009!
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
Re: Compiled dmd2.032 in VC++ 2009!
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 - rain...@eldwood.com Oh yeah, didn't think about that one here. I usually test for the string length before slicing it.
Re: Compiled dmd2.032 in VC++ 2009!
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 - rain...@eldwood.com
Re: Compiled dmd2.032 in VC++ 2009!
div0 Wrote: > Jeremie Pelletier wrote: > > > 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!
Re: Compiled dmd2.032 in VC++ 2009!
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 ", 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
Re: Compiled dmd2.032 in VC++ 2009!
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 ", 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
Re: Compiled dmd2.032 in VC++ 2009!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremie Pelletier wrote: 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-
Re: Compiled dmd2.032 in VC++ 2009!
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 ", args[0]);
return 1;
}
---
Re: Compiled dmd2.032 in VC++ 2009!
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.
Re: Compiled dmd2.032 in VC++ 2009!
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 :)
Re: Compiled dmd2.032 in VC++ 2009!
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.
Re: Compiled dmd2.032 in VC++ 2009!
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
Re: Compiled dmd2.032 in VC++ 2009!
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.
Re: Compiled dmd2.032 in VC++ 2009!
On Fri, Sep 4, 2009 at 3:19 PM, Jeremie Pelletier wrote:
> Jarrett Billingsley Wrote:
>
>> On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier 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.
It's basically the same. I think you just have to put extern(Windows):
inside each interface, but that's it.
Re: Compiled dmd2.032 in VC++ 2009!
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 . > > 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 :)
Re: Compiled dmd2.032 in VC++ 2009!
Jarrett Billingsley Wrote:
> On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier 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.
Re: Compiled dmd2.032 in VC++ 2009!
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
Re: Compiled dmd2.032 in VC++ 2009!
On Fri, Sep 4, 2009 at 10:22 AM, Jeremie Pelletier 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.
Re: Compiled dmd2.032 in VC++ 2009!
On Fri, 04 Sep 2009 13:40:02 +0400, 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? Wonderful debugging capabilities. That's a *huge* advantage.
Re: Compiled dmd2.032 in VC++ 2009!
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.
Re: Compiled dmd2.032 in VC++ 2009!
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
Re: Compiled dmd2.032 in VC++ 2009!
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...
Re: Compiled dmd2.032 in VC++ 2009!
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 . 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.
Compiled dmd2.032 in VC++ 2009!
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.
