www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mainstream D Programming

reply Richard Geary <tristram dial.pipex.com> writes:
Greetings!

I've just discovered the D programming language, and I'm fascinated by it. It
has captured the essence of what I believed was wrong with the C / C++ language
evolution, and formed a practically-driven language from the best bits. Thanks
for saving me the job!

But in reality, there is no mainstream support yet for D. Whilst the D compiler
will continute to improve, it will be years before it's declared "bug free"
enough to be used by business, and games developers won't be able to D
compilers for Xbox360/PS3/Wii.

To solve this, is there a D to C++ converter? Something to parse D code, output
it in C++ and build it with existing C++ tools? Whilst this is messy, it would
provide the functionality of D to environments which are unable to use the D
compiler.
Oct 14 2007
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, Richard Geary <tristram dial.pipex.com> wrote:
 Greetings!

is there a D to C++ converter?

I'm not completely sure it could be done at all. For example, while struct A(T,int N) { /* whatever */ } maps fairly straightforwardly to template <type T, int N> struct A { /* whatever */ } the same is not true of struct A(string s) { /* whatever */ } You would have a /really/ hard time translating that to C++. Static if, compile-time functions, mixins and so on, all simply have /no/ equivalent in C++. Anyway, what would be the point?
Oct 14 2007
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Janice Caron wrote:

 I'm not completely sure it could be done at all.

If D can be translated to assembly language, it can be translated to C++. How readable the result might be is another question. However, given that C++ is a significantly higher level language than assembly, I suspect a D to C++ compiler could output C++ that is at least somewhat approachable. In any case, reading the C++ coming out of such a compiler is probably not necessary. The OP is interested in using D in environments where only a C++ compiler is available. If the D to C++ conversion was well done, the resulting C++ code should compile cleanly and never need editing or even reading. Systems like this have been created for other languages. The original C++ compiler produced output in C. There is also an Ada compiler that outputs C. In both of these cases the reasons for their creation was the same: to allow (C++, Ada) to be used in an environment where no native compiler exists. Keep in mind that these translation tools are full compilers. The conversions are not accomplished with simple macro substitutions or anything similar. I suspect, for the reasons you mentioned, that a D to C++ compiler would have to basically be a full D front end with a "code" generator that output C++. Creating such a compiler would be a significant amount of work, although as the OP suggests it would no doubt help greatly in the spread of D (just as the original C++ "cfront" compiler helped the spread of C++). Actually it probably would be even better to compile D into C if one was going to do something like this. C compilers are even more common than C++ compilers. Peter
Oct 14 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Peter C. Chapin wrote:
 Actually it probably would be even better to compile D into C if one was
 going to do something like this. C compilers are even more common than
 C++ compilers.

This came up again recently in a discussion on rewriting the D front end into D. The problem is bootstrapping gdc onto new platforms without engaging a cross compiler. It doesn't seem to be very workable.
Oct 14 2007
parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Walter Bright wrote:

 Peter C. Chapin wrote:
 Actually it probably would be even better to compile D into C if one was
 going to do something like this. C compilers are even more common than
 C++ compilers.

This came up again recently in a discussion on rewriting the D front end into D. The problem is bootstrapping gdc onto new platforms without engaging a cross compiler. It doesn't seem to be very workable.

A D2C compiler would probably have to be written in C to be effective. Peter
Oct 14 2007
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Peter C. Chapin wrote:
 Walter Bright wrote:
 
 Peter C. Chapin wrote:
 Actually it probably would be even better to compile D into C if one was
 going to do something like this. C compilers are even more common than
 C++ compilers.

into D. The problem is bootstrapping gdc onto new platforms without engaging a cross compiler. It doesn't seem to be very workable.

A D2C compiler would probably have to be written in C to be effective. Peter

No it doesn't, you just write it in D and compile it with itself, and Bob's your uncle.
Oct 14 2007
parent "Peter C. Chapin" <pchapin sover.net> writes:
Christopher Wright wrote:

 Peter C. Chapin wrote:
 A D2C compiler would probably have to be written in C to be effective.

No it doesn't, you just write it in D and compile it with itself, and Bob's your uncle.

That's a good point, although I suppose you'd still have to port the run time support libraries (which would necessarily be in C) to the new platform before you could use the freshly compiled D2C over there. So to be clear. Platform A is the development platform, and B is the place were we would like to compile D programs but can't. We have the source code for D2C, a D to C translator, written in D. 1. Compile D2C on platform A using a native D compiler. The result is a program that converts D to C on platform A. 2. On platform A, compile D2C with the result of step #1 above. The result is the C version of D2C. 3. Copy the result of step #2 to platform B. 4. Use the native C compiler on platform B to compile the C code copied in step #3. The result is an executable version of D2C on platform B. Of course the C code produced by D2C will probably need runtime support in the form of a C library (so that it can be handled by the native C compiler). This library will probably have some platform specific stuff in it, and so would need to be ported manually before step #4 could be done. That probably wouldn't be a huge deal, but I'm sure it would depend on the platforms involved. Sounds good. Who wants to write it? :-) Peter
Oct 14 2007
prev sibling parent Georg Wrede <georg nospam.org> writes:
Peter C. Chapin wrote:
 Walter Bright wrote:
 
 
Peter C. Chapin wrote:

Actually it probably would be even better to compile D into C if one was
going to do something like this. C compilers are even more common than
C++ compilers.

This came up again recently in a discussion on rewriting the D front end into D. The problem is bootstrapping gdc onto new platforms without engaging a cross compiler. It doesn't seem to be very workable.

A D2C compiler would probably have to be written in C to be effective.

We're mixing two separate things here. For one thing, the compiler might be efficient, for the other thing, the resulting program (the binary) could be efficient. Probably most users would choose the binary to be efficient, if given a choice. For that to happen, the compiler could be written in any language (including Perl, Python, even any esoteric and unpractical but maybe academically commendable language).
Oct 25 2007
prev sibling next sibling parent reply Raynor <memphis007fr yahoo.fr> writes:
Richard Geary a écrit :
 Greetings!
 
 I've just discovered the D programming language, and I'm fascinated by it. It
has captured the essence of what I believed was wrong with the C / C++ language
evolution, and formed a practically-driven language from the best bits. Thanks
for saving me the job!
 
 But in reality, there is no mainstream support yet for D. Whilst the D
compiler will continute to improve, it will be years before it's declared "bug
free" enough to be used by business, and games developers won't be able to D
compilers for Xbox360/PS3/Wii.
 
 To solve this, is there a D to C++ converter? Something to parse D code,
output it in C++ and build it with existing C++ tools? Whilst this is messy, it
would provide the functionality of D to environments which are unable to use
the D compiler.

I think it would be better if D had a real IDE. Business developments are always done on Visual, Eclipse or NetBeans and at this moment D has... nothing.
Oct 14 2007
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Raynor wrote:

 I think it would be better if D had a real IDE. Business developments 
 are always done on Visual, Eclipse or NetBeans and at this moment D 
 has... nothing.

There are a few IDEs that work with D, so it's not exactly zero/none. Situation is somewhat similar to GUI, there are several but no "big". http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries --anders
Oct 14 2007
parent reply Raynor <memphis007fr yahoo.fr> writes:
Anders F Björklund a écrit :
 Raynor wrote:
 
 I think it would be better if D had a real IDE. Business developments 
 are always done on Visual, Eclipse or NetBeans and at this moment D 
 has... nothing.

There are a few IDEs that work with D, so it's not exactly zero/none. Situation is somewhat similar to GUI, there are several but no "big". http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries --anders

Yes but without a good code autocompletion, a full debugger support and a easy install, no company will look at D. But as i can see with Mhrmrmrm (not sur about the spelling :) ) it can become a reality soon.
Oct 14 2007
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Raynor escribió:
 Anders F Björklund a écrit :
 Raynor wrote:

 I think it would be better if D had a real IDE. Business developments 
 are always done on Visual, Eclipse or NetBeans and at this moment D 
 has... nothing.

There are a few IDEs that work with D, so it's not exactly zero/none. Situation is somewhat similar to GUI, there are several but no "big". http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries --anders

Yes but without a good code autocompletion, a full debugger support and a easy install, no company will look at D. But as i can see with Mhrmrmrm (not sur about the spelling :) ) it can become a reality soon.

lol, that name will become official: "Mhrmrmrm (not sur about the spelling)"
Oct 14 2007
next sibling parent reply Bruce Adams <tortoise_74 yahoo.co.uk> writes:
Ary Manzana Wrote:

 Raynor escribió:
 Anders F Björklund a écrit :
 Raynor wrote:

 I think it would be better if D had a real IDE. Business developments 
 are always done on Visual, Eclipse or NetBeans and at this moment D 
 has... nothing.

There are a few IDEs that work with D, so it's not exactly zero/none. Situation is somewhat similar to GUI, there are several but no "big". http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries --anders

Yes but without a good code autocompletion, a full debugger support and a easy install, no company will look at D. But as i can see with Mhrmrmrm (not sur about the spelling :) ) it can become a reality soon.

lol, that name will become official: "Mhrmrmrm (not sur about the spelling)"

I don't know why some people get so hung about about IDEs. Added value yes but essential no. I've had (the misfortune) work in companies where they still use C++ compilers that run under DOS for some applications along side monsters in C#. There's no excuse for it but a lot of places are like that. Slow to change and haphazard in what they adopt and when. Its the availability of skills and the benefits of one language over another that seem to be the biggest drivers. Regards, Bruce. PS mrrmrmr cough cough splutter is a terrible name for anything. As a working title its fine but long term is a no no. Its bad enough as a name of a planet in a computer game.
Oct 14 2007
next sibling parent reply BLS <nanali nospam-wanadoo.fr> writes:
Bruce Adams schrieb:
 Ary Manzana Wrote:
 
 Raynor escribió:
 Anders F Björklund a écrit :
 Raynor wrote:

 I think it would be better if D had a real IDE. Business developments 
 are always done on Visual, Eclipse or NetBeans and at this moment D 
 has... nothing.

Situation is somewhat similar to GUI, there are several but no "big". http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries --anders

a easy install, no company will look at D. But as i can see with Mhrmrmrm (not sur about the spelling :) ) it can become a reality soon.


I don't know why some people get so hung about about IDEs. Added value yes but essential no. I've had (the misfortune) work in companies where they still use C++ compilers that run under DOS for some applications along side monsters in C#. There's no excuse for it but a lot of places are like that. Slow to change and haphazard in what they adopt and when. Its the availability of skills and the benefits of one language over another that seem to be the biggest drivers. Regards, Bruce. PS mrrmrmr cough cough splutter is a terrible name for anything. As a working title its fine but long term is a no no. Its bad enough as a name of a planet in a computer game.

Thta is stone age. You see I disagree... A perfect D IDE I, for example, would like to speak with my IDE (voice recognation, and text to speach) I expect rule based suggestions from my IDE. / programming/ database/ gui ... I expect an itelligent Enterprise framework (lib) managed from my IDE. Let me call it managed Business Objects I expect *realtime* developer collaboration support from my IDE I expect a code editor which is able to show me, respective enables me to plugin a learning video, a module dependency graph, a math formular, some hypertext links , or simply a graphical representation of an algo. In other word NOT just text. ( not really new, first papers appear 15 years ago) BUT I have to realize it, nobody is able to convince a command line maniac. :) Bjoern
Oct 14 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
BLS Wrote:

 Bruce Adams schrieb:
 Ary Manzana Wrote:
 
 Raynor escribió:
 Anders F Björklund a écrit :
 Raynor wrote:

 I think it would be better if D had a real IDE. Business developments 
 are always done on Visual, Eclipse or NetBeans and at this moment D 
 has... nothing.

Situation is somewhat similar to GUI, there are several but no "big". http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries --anders

a easy install, no company will look at D. But as i can see with Mhrmrmrm (not sur about the spelling :) ) it can become a reality soon.


I don't know why some people get so hung about about IDEs. Added value yes but essential no. I've had (the misfortune) work in companies where they still use C++ compilers that run under DOS for some applications along side monsters in C#. There's no excuse for it but a lot of places are like that. Slow to change and haphazard in what they adopt and when. Its the availability of skills and the benefits of one language over another that seem to be the biggest drivers. Regards, Bruce. PS mrrmrmr cough cough splutter is a terrible name for anything. As a working title its fine but long term is a no no. Its bad enough as a name of a planet in a computer game.

Thta is stone age. You see I disagree... A perfect D IDE I, for example, would like to speak with my IDE (voice recognation, and text to speach) I expect rule based suggestions from my IDE. / programming/ database/ gui ... I expect an itelligent Enterprise framework (lib) managed from my IDE. Let me call it managed Business Objects I expect *realtime* developer collaboration support from my IDE I expect a code editor which is able to show me, respective enables me to plugin a learning video, a module dependency graph, a math formular, some hypertext links , or simply a graphical representation of an algo. In other word NOT just text. ( not really new, first papers appear 15 years ago) BUT I have to realize it, nobody is able to convince a command line maniac. :) Bjoern

I would *like* those features too. I would also *like* politicians to not lie. I would not, howvever, *expect* them. Bruce.
Oct 15 2007
prev sibling next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
Does nobody refactor their code? If so, how a text editor helps?

David Brown escribió:
 On Sun, Oct 14, 2007 at 06:44:53PM +0100, Janice Caron wrote:
 
 However, Bruce's point will not be erased by any amount of hyperbole.
 When I program in D, I use a text editor, not an IDE. To be sure, it's
 a programmer's text editor, with syntax highlighting; one that knows
 how to build D, and jump to the line causing any error, but still
 ultimately just a text editor. And it is more than adequate for the
 task.

I have not, and still do not use an IDE for development. To me, once learned, the features of a good programmer's text editor far outweight any extra features an IDE might have. About the only thing missing is completion, but that's because nobody has yet taught 'vim' how to do D completion. It does a fairly good job just guessing based on what other things are in my files. None of this means that someone shouldn't get various IDEs to work with D. I'm just pointing out that there are still a large number of developers who don't use them, and don't really find them all that useful. David

Oct 14 2007
parent reply Ary Manzana <ary esperanto.org.ar> writes:
Please tell me the steps you perform to do the refactor... Say, for 
example, you are renaming the name of a method of class A, and suppose 
there is another class B with the same method name (but you don't want 
to change B's method's name).

Janice Caron escribió:
 On 10/14/07, Ary Manzana <ary esperanto.org.ar> wrote:
 Does nobody refactor their code? If so, how a text editor helps?

Why wouldn't a text editor help? I've always found it perfectly adequate to the task.

Oct 14 2007
next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron Wrote:

 On 10/14/07, Ary Manzana <ary esperanto.org.ar> wrote:
 Please tell me the steps you perform to do the refactor... Say, for
 example, you are renaming the name of a method of class A, and suppose
 there is another class B with the same method name (but you don't want
 to change B's method's name).

Change the method name, then recompile. The compiler will find all the references using the old name, because they are now compile errors. Obvious!

That works, but on an enterprise codebase where there could be 100+ references to that method, this becomes tedious. I think the point is that IDEs, while not essential, can certainly do a lot of things that are helpful. For example, * Show exactly where in a huge string mixin an error occurs * Show the particular instantiation of templates * Manage imports automatically, so whenever it comes across an undefined symbol, you just need to press a button to import the required module, not look up what module it's in, etc. Never write another import statement! This could also improve code quality, since you could make it only use selective imports and never pollute your namespace by importing an "all" module. * Mark errors instantly (and have suggested fixes for some of them), rather than having to compile every time. * Automatically implement stubs for inherited abstract methods/interfaces. * Track TODOs, etc. * Show formatted Ddoc on hover. * Integrate debuggers to visually step through code. * Format source code * Autocomplete * Go-to definition (even across files) * Additional warnings and static analysis if you want them (for example, it could warn for "x == null" or integrate Coverity-like nulll checking) * Automatically organize/sort source code * Generate an interface or abstract superclass from the intersection of one or more classes' methods. * A "use supertype where possible," where all references to a subtype are changed to references to the supertype if they can be (encourages more modular code in a highly OO system). * Change "auto" to its actual type. * Move functions/classes between modules and automatically update modules that reference them. ... Anyway, the point is not that "an IDE is essential," and for smaller projects, it's arguably overkill, but for huge projects, it can be helpful. I think one of the things stopping a lot of people from adopting IDEs is this implicit fear of having to learn something new. There is a learning curve associated with everything, and if you've been using ed for the last 30 years, an IDE can be a scary place.
Oct 14 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Robert,

 I think the point is that IDEs, while not essential, can certainly do
 a lot of things that are helpful. For example,
 
 * Show exactly where in a huge string mixin an error occurs
 

* do "code folding on mixins, it would look like a a folded up block but when expanded would show in place the actual text of the mixin. It might even be nice to have some sort of string construction trace ("this identifier was build by the concatenation of this template and this CTFE, would you like to step through either of them?") * breakpoint template debugging ** walk the tree of templates ** unroll tuple foreach and fold up unused static if blocks * compile time breakpoints on CTFE
 * Show the particular instantiation of templates
 

Oct 14 2007
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Fraser wrote:
 I think the point is that IDEs, while not essential, can certainly do
 a lot of things that are helpful. For example,
 
 * Show exactly where in a huge string mixin an error occurs * Show
 the particular instantiation of templates * Manage imports
 automatically, so whenever it comes across an undefined symbol, you
 just need to press a button to import the required module, not look
 up what module it's in, etc. Never write another import statement!
 This could also improve code quality, since you could make it only
 use selective imports and never pollute your namespace by importing
 an "all" module. * Mark errors instantly (and have suggested fixes
 for some of them), rather than having to compile every time. *
 Automatically implement stubs for inherited abstract
 methods/interfaces. * Track TODOs, etc. * Show formatted Ddoc on
 hover. * Integrate debuggers to visually step through code. * Format
 source code * Autocomplete * Go-to definition (even across files) *
 Additional warnings and static analysis if you want them (for
 example, it could warn for "x == null" or integrate Coverity-like
 nulll checking) * Automatically organize/sort source code * Generate
 an interface or abstract superclass from the intersection of one or
 more classes' methods. * A "use supertype where possible," where all
 references to a subtype are changed to references to the supertype if
 they can be (encourages more modular code in a highly OO system). *
 Change "auto" to its actual type. * Move functions/classes between
 modules and automatically update modules that reference them. ...

I think these are pretty cool features!
Oct 14 2007
prev sibling parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Robert Fraser wrote:

 * Show exactly where in a huge string mixin an error occurs
 * Show the particular instantiation of templates
 * Manage imports automatically, so whenever it comes across an undefined
symbol, you just need to press a button to import the required module, not look
up what module it's in, etc. Never write another import statement! This could
also improve code quality, since you could make it only use selective imports
and never pollute your namespace by importing an "all" module.
 * Mark errors instantly (and have suggested fixes for some of them), rather
than having to compile every time.
 * Automatically implement stubs for inherited abstract methods/interfaces.
 * Track TODOs, etc.
 * Show formatted Ddoc on hover.
 * Integrate debuggers to visually step through code.
 * Format source code
 * Autocomplete
 * Go-to definition (even across files)
 * Additional warnings and static analysis if you want them (for example, it
could warn for "x == null" or integrate Coverity-like nulll checking)
 * Automatically organize/sort source code
 * Generate an interface or abstract superclass from the intersection of one or
more classes' methods.
 * A "use supertype where possible," where all references to a subtype are
changed to references to the supertype if they can be (encourages more modular
code in a highly OO system).
 * Change "auto" to its actual type.
 * Move functions/classes between modules and automatically update modules that
reference them.

Some of these features can be accomplished with a powerful text editor, especially with the addition of suitable macros, plug-ins, or third party tools (that are invoked from inside the editor, of course). For example, Emacs together with the etags program can implement the "Go-to definition (even across files)." I actually do this quite regularly. Considering how programmable high end editors are, I suppose in the long run there isn't necessarily much difference between an IDE and a text editor. For example: jEdit has a plug-in that will do XML validation. Who needs an XML development IDE? Except that jEdit really *is* a kind of XML development IDE (with the plug-in added). My $0.02... IDEs are cool and I use them. But strangely at the end of the day I find myself doing most of my editing in Emacs. Why? Because Emacs works the same on all platforms, works on all text files, and can be extended to do all sorts of interesting things when and necessary. As weird as this sounds, I sometimes use Visual Studio to manage the build of my C++ programs while editing their source in Emacs in a separate window. (I do this because out-of-the-box Emacs knows how to word wrap comments in C++ comment blocks... a feature I can't live without). Peter
Oct 14 2007
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Peter,

 Some of these features can be accomplished with a powerful text
 editor, especially with the addition of suitable macros, plug-ins, or
 third party tools (that are invoked from inside the editor, of
 course). For example, Emacs together with the etags program can
 implement the "Go-to definition (even across files)." I actually do
 this quite regularly.
 
 Considering how programmable high end editors are, I suppose in the
 long run there isn't necessarily much difference between an IDE and a
 text editor. For example: jEdit has a plug-in that will do XML
 validation. Who needs an XML development IDE? Except that jEdit really
 *is* a kind of XML development IDE (with the plug-in added).
 
 My $0.02... IDEs are cool and I use them. But strangely at the end of
 the day I find myself doing most of my editing in Emacs. Why? Because
 Emacs works the same on all platforms, works on all text files, and
 can be extended to do all sorts of interesting things when and
 necessary. As weird as this sounds, I sometimes use Visual Studio to
 manage the build of my C++ programs while editing their source in
 Emacs in a separate window. (I do this because out-of-the-box Emacs
 knows how to word wrap comments in C++ comment blocks... a feature I
 can't live without).
 
 Peter
 

I once saw a screen shot of IRSSI (an IRC chat app) running in a VS tab. I wonder what it would take to run emacs/vi as a VS plugin.
Oct 14 2007
parent Matti Niemenmaa <see_signature for.real.address> writes:
BCS wrote:
 I once saw a screen shot of IRSSI (an IRC chat app) running in a VS tab.
 I wonder what it would take to run emacs/vi as a VS plugin.

If you're referring to http://www.irssi.org/themefiles/c0ders.png it's just a theme for irssi to make it look like an IDE. -- E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi
Oct 15 2007
prev sibling parent reply Jan Claeys <usenet janc.be> writes:
Op Sun, 14 Oct 2007 22:58:47 +0000 (UTC)
schreef BCS <ao pathlink.com>:

  I once saw a screen shot of IRSSI (an IRC chat app) running in a VS
 tab. I wonder what it would take to run emacs/vi as a VS plugin.

<http://vimdoc.sourceforge.net/htmldoc/if_ole.html#MSVisualStudio> :) -- JanC
Oct 16 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Jan,

 Op Sun, 14 Oct 2007 22:58:47 +0000 (UTC)
 schreef BCS <ao pathlink.com>:
 I once saw a screen shot of IRSSI (an IRC chat app) running in a VS
 tab. I wonder what it would take to run emacs/vi as a VS plugin.
 


any idea what it ends up looking like? Does it pop a new window or does it just take over a tab?
Oct 16 2007
parent reply Christopher Wright <dhasenan gmail.com> writes:
BCS wrote:
 Reply to Jan,
 
 Op Sun, 14 Oct 2007 22:58:47 +0000 (UTC)
 schreef BCS <ao pathlink.com>:
 I once saw a screen shot of IRSSI (an IRC chat app) running in a VS
 tab. I wonder what it would take to run emacs/vi as a VS plugin.


any idea what it ends up looking like? Does it pop a new window or does it just take over a tab?

New window. If you want combined features of VS and Vim, use viemu (www.viemu.com), which costs $70 for a permanent copy.
Oct 18 2007
parent reply BCS <ao pathlink.com> writes:
Reply to Christopher,

 BCS wrote:
 
 Reply to Jan,
 
 Op Sun, 14 Oct 2007 22:58:47 +0000 (UTC)
 schreef BCS <ao pathlink.com>:
 I once saw a screen shot of IRSSI (an IRC chat app) running in a VS
 tab. I wonder what it would take to run emacs/vi as a VS plugin.
 

:)

does it just take over a tab?

(www.viemu.com), which costs $70 for a permanent copy.

Now that's an IDE model I like. Editor? why should I wright an editor? here's an plugin API, embed your own editor. For that matter; syntax highlighting? same thing. Code completion, refactoring, code search? Same thing again. Heck, how about a IDE that's nothing but am open/close menu that looks for a plugin to generate a tab for whatever you open?
Oct 18 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
BCS wrote:
 Heck, how about a IDE that's nothing but am open/close menu that looks
 for a plugin to generate a tab for whatever you open?

I believe it's called Eclipse ;) -- Daniel
Oct 18 2007
parent BCS <ao pathlink.com> writes:
Reply to Daniel,

 BCS wrote:
 
 Heck, how about a IDE that's nothing but am open/close menu that
 looks for a plugin to generate a tab for whatever you open?
 

-- Daniel

No, Eclipse also is (ok "has" to be totally correct) a JVM and a pile of Java code. </sarcasm>
Oct 18 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
David Brown Wrote:

 The problem is that when one uses a specific-focus refactoring tool, they
 are limited to the transformations that the authors of the tools have
 thought of (which is still a very useful set), but without the
 general-purpose text transformations available in a good programmer's
 editor, one can easily miss other types of refactoring that are also quite
 useful.

Most IDEs have regular expressions, etc. -- the features available in a good "programmer's editor" are a subset of the features available in a good IDE.
Oct 14 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:
 On 10/14/07, Robert Fraser <fraserofthenight gmail.com> wrote:
 Most IDEs have regular expressions, etc.

My text editor has regular expressions. What's the big deal there?

Yeh, and last I checked my Visual Studio IDE did *not* have regular expressions! --bb
Oct 14 2007
parent Nathan Reed <nathaniel.reed gmail.com> writes:
Bill Baxter wrote:
 Yeh, and last I checked my Visual Studio IDE did *not* have regular 
 expressions!
 
 --bb

It has regular expressions, they just don't use the same syntax as the rest of the world. Thanks, Nathan Reed
Oct 14 2007
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to Robert,

 David Brown Wrote:
 
 The problem is that when one uses a specific-focus refactoring tool,
 they are limited to the transformations that the authors of the tools
 have thought of (which is still a very useful set), but without the
 general-purpose text transformations available in a good programmer's
 editor, one can easily miss other types of refactoring that are also
 quite useful.
 

a good "programmer's editor" are a subset of the features available in a good IDE.

Maybe what is needed is a pure refractor. A library intended to be built into plugins or standalone tools that does refactoring. It would not be intended to be an editor, attached to an editor, yes, part of it, no. It would be interesting to build it such that it can take plugins (a plugin for a plugin :) that doe the actual work. I'm betting it has been done somewhere. Maybe we should try it with D.
Oct 14 2007
prev sibling next sibling parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
Janice Caron wrote:
 If IDEs were so great, there would be no talk of making an IDE "for
 D". Rather, your existing IDE would already be capable of doing the
 job.

Wow! I appreciate the new heights to which exaggeration has now reached. ;) I certainly appreciate a good general-purpose text editor in which I can define syntax highlighting, macros, and so forth for working with languages the original text editor developer never thought of. However, take a look at the list of features posted by Robert above. There is just no way I can see that an IDE could be designed to be sufficiently general that all these features could be done through customization, without making the "customization" a complete programming language in itself. (Of course, that is exactly what emacs does...) Languages differ enough that it actually does make sense to have language-specific IDEs rather than totally general-purpose IDEs. (And the time/effort needed to develop a hypothetical emacs d-mode would be pretty much equivalent with that needed to develop a D-specific IDE.) Thanks, Nathan Reed
Oct 14 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Janice Caron Wrote:

 On 10/14/07, Nathan Reed <nathaniel.reed gmail.com> wrote:
 Languages differ enough that it actually does make sense to have
 language-specific IDEs rather than totally general-purpose IDEs.  (And
 the time/effort needed to develop a hypothetical emacs d-mode would be
 pretty much equivalent with that needed to develop a D-specific IDE.)

Yeah I know. I do agree. (And like I said, I use Visual Studio at work). This conversation began when someone said that using a text editor was "stone age". I kinda felt it was reasonable to point out that many people still use them, and are likely to for the forseeable future, because they do have some advantages. Maybe they can't do all that a language-specific IDE can do, but they do have some advantages. That's worth noting.

I'm pretty sure emacs could in theory be made to do all the things these fancy new IDEs do. The problem is the code would have to be developed in LISP. Large scale deveopment in lisp is challenging. Did you know that LISP in fact stands for Lots of Spurious and Iterating Parentheses? Its surprising how poor the scripting interface of some of these modern IDEs can be. Here's a question for IDE developers and users. What scripting language would your ideal D IDE use? I suppose some will say none, just publish an API for developing plug-ins. Maybe even a plug-in to give you the scripting interface in the language of your choice. Bruce.
Oct 15 2007
prev sibling next sibling parent reply Yigal Chripun <yigal100 gmail.com> writes:
Janice Caron wrote:
 On 10/14/07, David Brown <dlang davidb.org> wrote:
 Also, I tend to deal with lots of code in lots of different projects,
 rather than a single project.  I find it better to have powerful, but more
 general functionality, than a tool that often doesn't even know the
 languages that I'm working with.

That's a very good point, and one with which I must concur. While I do use Visual Studio at work, I never bother with it at home because it doesn't know about all the languages I use. Sure it can do (a microsoft dialect of) C and C++, but it knows diddly squat about PHP, Javascript, or D. A powerful text editor, on the other hand, can easily be equipt to deal with any language whatsoever, and therein lies its true power. It is infinitely upgradable, and can be retooled for any new purpose just by editing text files ... for which of course, it serves as its own tool. If IDEs were so great, there would be no talk of making an IDE "for D". Rather, your existing IDE would already be capable of doing the job.

good IDEs (and i don't consider anything that comes from MS to be good, or standard or usfull or .. well you get what i mean... ) are based on a plug-in infrastructure. actually eclipse doesn't provide any functionally by itself, rather it works as a piece of software to manage plug-ins and their dependencies, everything else is a plug-in. for example, my installation of eclipse could be called "Hyperpolyglot" (http://en.wikipedia.org/wiki/Hyperpolyglot) because i have plug-ins for sevral languages: c/c++/D, java, scala, php, perl, javascript, ruby, scheme, .. also most good ides use plug-ins to implement refactorings, (intellij IDEA, eclipse and netbeans come to mind) i even have VI plugin when i need it's keyboard style editing. so if you want you really can enjoy both worlds - use a very advanced text editor [ vi :) ] and also have the power of an IDE. so at least for me, it's easier to equip my eclipse with another plug-in for a different language or a new feature, rather than search the web for a way to add D support for my favorite text-editor (currently it's notepad++ on windows)
Oct 14 2007
next sibling parent reply "Peter C. Chapin" <pchapin sover.net> writes:
Yigal Chripun wrote:

 i even have VI plugin when i need it's keyboard style editing.
 so if you want you really can enjoy both worlds - use a very advanced
 text editor [ vi :) ] and also have the power of an IDE.

I think there's an Emacs plug-in for Eclipse as well. I'm not sure how well it works, though. Peter
Oct 14 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Peter C. Chapin Wrote:

 Yigal Chripun wrote:
 
 i even have VI plugin when i need it's keyboard style editing.
 so if you want you really can enjoy both worlds - use a very advanced
 text editor [ vi :) ] and also have the power of an IDE.

I think there's an Emacs plug-in for Eclipse as well. I'm not sure how well it works, though. Peter

I looked it up a while ago (thought I didn't try it). Its dead (or at least resting and pining for the fjords). It doesn't work with eclipses 3.X only something much older which means no CDT refactorings and stuff like that for C++ nevermind D (forgive this blashphemy) or anything else. For what its worth the link is here: http://people.csail.mit.edu/adonovan/hacks/eclipse-emacs.html Regards, Bruce.
Oct 15 2007
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Yigal Chripun wrote:
 Janice Caron wrote:
 for example, my installation of eclipse could be called "Hyperpolyglot" 
 (http://en.wikipedia.org/wiki/Hyperpolyglot) because i have plug-ins for 
 sevral languages: c/c++/D, java, scala, php, perl, javascript, ruby, 
 scheme, ..

Out of curiosity, which plugins are you using for Ruby and Javascript? -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2007
parent Yigal Chripun <yigal100 gmail.com> writes:
Bruno Medeiros wrote:
 Yigal Chripun wrote:
 Janice Caron wrote:
 for example, my installation of eclipse could be called 
 "Hyperpolyglot" (http://en.wikipedia.org/wiki/Hyperpolyglot) because i 
 have plug-ins for sevral languages: c/c++/D, java, scala, php, perl, 
 javascript, ruby, scheme, ..

Out of curiosity, which plugins are you using for Ruby and Javascript?

list of plug-ins to choose from. i've got aptana for web development, and also the flex builder beta trial (for flex and java script). for ruby there's RDT (ruby development tools) there's also additional support for rails development :)
Oct 15 2007
prev sibling next sibling parent Raynor <memphis007fr yahoo.fr> writes:
Janice Caron a écrit :
 On 10/14/07, David Brown <dlang davidb.org> wrote:
 Also, I tend to deal with lots of code in lots of different projects,
 rather than a single project.  I find it better to have powerful, but more
 general functionality, than a tool that often doesn't even know the
 languages that I'm working with.

That's a very good point, and one with which I must concur. While I do use Visual Studio at work, I never bother with it at home because it doesn't know about all the languages I use. Sure it can do (a microsoft dialect of) C and C++, but it knows diddly squat about PHP, Javascript, or D. A powerful text editor, on the other hand, can easily be equipt to deal with any language whatsoever, and therein lies its true power. It is infinitely upgradable, and can be retooled for any new purpose just by editing text files ... for which of course, it serves as its own tool. If IDEs were so great, there would be no talk of making an IDE "for D". Rather, your existing IDE would already be capable of doing the job.

Have you seen how IDE's like visual and netbeans are everywhere in companies? Its not a fight IDE vs TextEditor, its the reality of the market!!! And we need to do everything to put D on the market. ps : i have learned to program in C and C++ on emacs and NetBSD so i know both sides :)
Oct 14 2007
prev sibling next sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
David Brown Wrote:

 I also work a lot in situations where I don't have a gui available.  Vim
 gives me all of its functionality over an ssh connection.
 
 Dave

I have the same problem. I trust you are familar with ssh -Y for X11 forwarding. Makes things a lot less painful when its allowed. Bruce.
Oct 15 2007
prev sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Janice Caron Wrote:

 On 10/14/07, David Brown <dlang davidb.org> wrote:
 Also, I tend to deal with lots of code in lots of different projects,
 rather than a single project.  I find it better to have powerful, but more
 general functionality, than a tool that often doesn't even know the
 languages that I'm working with.

That's a very good point, and one with which I must concur. While I do use Visual Studio at work, I never bother with it at home because it doesn't know about all the languages I use. Sure it can do (a microsoft dialect of) C and C++, but it knows diddly squat about PHP, Javascript, or D. A powerful text editor, on the other hand, can easily be equipt to deal with any language whatsoever, and therein lies its true power. It is infinitely upgradable, and can be retooled for any new purpose just by editing text files ... for which of course, it serves as its own tool. If IDEs were so great, there would be no talk of making an IDE "for D". Rather, your existing IDE would already be capable of doing the job.

It is :). [speaking for both emacs and eclipse]
Oct 15 2007
prev sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Ary Manzana Wrote:

 Please tell me the steps you perform to do the refactor... Say, for 
 example, you are renaming the name of a method of class A, and suppose 
 there is another class B with the same method name (but you don't want 
 to change B's method's name).
 
 Janice Caron escribió:
 On 10/14/07, Ary Manzana <ary esperanto.org.ar> wrote:
 Does nobody refactor their code? If so, how a text editor helps?

Why wouldn't a text editor help? I've always found it perfectly adequate to the task.


It is surprsing how much refactoring can be performed using good old fashioned cut and paste and search and replace. The context sensitivity problem you describe is actually surprisingly rare in my experience. That's not to say having tools to do it for you isn't useful. When they aren't available you have to knock out a five minute one use script or do the job manually. There is a flip side to the coin though. Too many people become reliant on particular tools and ways of working without understanding what's going on under the hood. This can lead to bad habits. My example generator is offline at the moment but why don't I name all my member variables X Y & Z in each class and let the tools sort it out from the context. A better example might be all the copying that goes on when returning by value. Unless you know its expensive your superfast box will prevent you realising how inefficient your code is until you get a bottleneck there out of the blue. Bruce.
Oct 15 2007
prev sibling next sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Janice Caron schrieb:
 On 10/14/07, BLS <nanali nospam-wanadoo.fr> wrote:
 Bruce Adams schrieb:
 That is simply said : stone age.


Well it was BLS who said ... instead of Bruce.
 Wow! I appreciate the new heights to which exaggeration has now
 reached. It's cool to know that our cave-dwelling ancestors were
 familiar with DOS!
 
 However, Bruce's point will not be erased by any amount of hyperbole.
 When I program in D, I use a text editor, not an IDE. To be sure, it's
 a programmer's text editor, with syntax highlighting; one that knows
 how to build D, and jump to the line causing any error, but still
 ultimately just a text editor. And it is more than adequate for the
 task.
 
 Not everyone uses an IDE. Neolithic jibes notwithstanding, that's just a fact.

If guess a lot of you folks still prefer to write letters instead of emails. just kidding :) However the architecture of current IDE's is allready ~15 years old. It is time to give 'em a cozy home on your 386 farm, guess they like to see the kids grow. Bjoern
Oct 14 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, Robert Fraser <fraserofthenight gmail.com> wrote:
 Most IDEs have regular expressions, etc.

My text editor has regular expressions. What's the big deal there?
Oct 14 2007
prev sibling next sibling parent David Brown <dlang davidb.org> writes:
On Sun, Oct 14, 2007 at 04:00:01PM -0400, Robert Fraser wrote:
David Brown Wrote:

 The problem is that when one uses a specific-focus refactoring tool, they
 are limited to the transformations that the authors of the tools have
 thought of (which is still a very useful set), but without the
 general-purpose text transformations available in a good programmer's
 editor, one can easily miss other types of refactoring that are also quite
 useful.

Most IDEs have regular expressions, etc. -- the features available in a good "programmer's editor" are a subset of the features available in a good IDE.

Boy, this is starting to get very off topic :-) Regexps are a rather minor (but important) feature of an editor. I suspect a lot of it is just the fact that I've been programming in 'vi' for more than 20 years. Something like 'vim' with it's incremental IDE-like features is a much better improvement for me than an IDE with a completely different underlying editor model. If there was _an_ IDE that I could learn, it might be worth the effort, and eclipse might be on the way to becoming that. But, we're talking a learning curve on a similar order to learning to type on a Dvorak keyboard. Also, I tend to deal with lots of code in lots of different projects, rather than a single project. I find it better to have powerful, but more general functionality, than a tool that often doesn't even know the languages that I'm working with. I also work a lot in situations where I don't have a gui available. Vim gives me all of its functionality over an ssh connection. Dave
Oct 14 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruce Adams wrote:
 
 PS mrrmrmr cough cough splutter is a terrible name for anything. As a working
title its fine but long term is a no no. Its bad enough as a name of a planet
in a computer game.

It's the name of race, not of a planet. :P But yes, I agree it's a bad name. In the long run there should be a better name. But in the long run there should also be only one definite D Eclipse IDE. And ideally, it should be called DDT (even though that was the name of a previous now-defunct D Eclipse IDE), just as JDT, CDT, PDT, etc.. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, David Brown <dlang davidb.org> wrote:
 Also, I tend to deal with lots of code in lots of different projects,
 rather than a single project.  I find it better to have powerful, but more
 general functionality, than a tool that often doesn't even know the
 languages that I'm working with.

That's a very good point, and one with which I must concur. While I do use Visual Studio at work, I never bother with it at home because it doesn't know about all the languages I use. Sure it can do (a microsoft dialect of) C and C++, but it knows diddly squat about PHP, Javascript, or D. A powerful text editor, on the other hand, can easily be equipt to deal with any language whatsoever, and therein lies its true power. It is infinitely upgradable, and can be retooled for any new purpose just by editing text files ... for which of course, it serves as its own tool. If IDEs were so great, there would be no talk of making an IDE "for D". Rather, your existing IDE would already be capable of doing the job.
Oct 14 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, Nathan Reed <nathaniel.reed gmail.com> wrote:
 Languages differ enough that it actually does make sense to have
 language-specific IDEs rather than totally general-purpose IDEs.  (And
 the time/effort needed to develop a hypothetical emacs d-mode would be
 pretty much equivalent with that needed to develop a D-specific IDE.)

Yeah I know. I do agree. (And like I said, I use Visual Studio at work). This conversation began when someone said that using a text editor was "stone age". I kinda felt it was reasonable to point out that many people still use them, and are likely to for the forseeable future, because they do have some advantages. Maybe they can't do all that a language-specific IDE can do, but they do have some advantages. That's worth noting.
Oct 14 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, Ary Manzana <ary esperanto.org.ar> wrote:
 Please tell me the steps you perform to do the refactor... Say, for
 example, you are renaming the name of a method of class A, and suppose
 there is another class B with the same method name (but you don't want
 to change B's method's name).

Change the method name, then recompile. The compiler will find all the references using the old name, because they are now compile errors. Obvious!
Oct 14 2007
prev sibling next sibling parent David Brown <dlang davidb.org> writes:
On Sun, Oct 14, 2007 at 03:25:22PM -0200, Ary Manzana wrote:

 Please tell me the steps you perform to do the refactor... Say, for 
 example, you are renaming the name of a method of class A, and suppose 
 there is another class B with the same method name (but you don't want to 
 change B's method's name).

I'd change the method name, and let the compiler tell me where the method invocations are. That's why I use a strongly typed language, and things like the 'override' keyboard are useful. My editor will then take me to each erroneous invocation where a simple keypress will perform the rename. My general experience is that people who use refactoring tools overestimate how beneficial they are, and people who don't underestimate how useful they are. The problem is that when one uses a specific-focus refactoring tool, they are limited to the transformations that the authors of the tools have thought of (which is still a very useful set), but without the general-purpose text transformations available in a good programmer's editor, one can easily miss other types of refactoring that are also quite useful. BTW, I do this kind of refactoring all of the time. Having to look at each change has caught many other things to clean up as well, that I would have missed if a tool automatically renamed everything. I think reviews should be looking at each change anyway. Dave
Oct 14 2007
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Raynor wrote:
 Anders F Björklund a écrit :
 Raynor wrote:

 I think it would be better if D had a real IDE. Business developments 
 are always done on Visual, Eclipse or NetBeans and at this moment D 
 has... nothing.

There are a few IDEs that work with D, so it's not exactly zero/none. Situation is somewhat similar to GUI, there are several but no "big". http://www.prowiki.org/wiki4d/wiki.cgi?EditorSupport http://www.prowiki.org/wiki4d/wiki.cgi?GuiLibraries --anders

Yes but without a good code autocompletion, a full debugger support and a easy install, no company will look at D. But as i can see with Mhrmrmrm (not sur about the spelling :) ) it can become a reality soon.

I'd recommend installing both Mmrnmhrm and Descent. You can use Mmrnmhrm for source editing (with autocomplete, find def, find refs, etc.), and Descent for debugging. I've made some changes in the development stream of Mmrnmhrm to make this simbiose work better, namely you can now add and remove breakpoints in the Mmrnmhrm editor which will work with Descent, but there are still some other downsides. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, BLS <nanali nospam-wanadoo.fr> wrote:
 Bruce Adams schrieb:
 That is simply said : stone age.

Wow! I appreciate the new heights to which exaggeration has now reached. It's cool to know that our cave-dwelling ancestors were familiar with DOS! However, Bruce's point will not be erased by any amount of hyperbole. When I program in D, I use a text editor, not an IDE. To be sure, it's a programmer's text editor, with syntax highlighting; one that knows how to build D, and jump to the line causing any error, but still ultimately just a text editor. And it is more than adequate for the task. Not everyone uses an IDE. Neolithic jibes notwithstanding, that's just a fact.
Oct 14 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, Janice Caron <caron800 googlemail.com> wrote:
 On 10/14/07, BLS <nanali nospam-wanadoo.fr> wrote:
 That is simply said : stone age.


I hope everyone followed the attribution there. (I should have chopped out one more line). Bruce said not everyone uses an IDE; BLS said that was stone age; I agreed with Bruce. Apologies for misattribution if anyone misread that.
Oct 14 2007
prev sibling next sibling parent David Brown <dlang davidb.org> writes:
On Sun, Oct 14, 2007 at 06:44:53PM +0100, Janice Caron wrote:

However, Bruce's point will not be erased by any amount of hyperbole.
When I program in D, I use a text editor, not an IDE. To be sure, it's
a programmer's text editor, with syntax highlighting; one that knows
how to build D, and jump to the line causing any error, but still
ultimately just a text editor. And it is more than adequate for the
task.

I have not, and still do not use an IDE for development. To me, once learned, the features of a good programmer's text editor far outweight any extra features an IDE might have. About the only thing missing is completion, but that's because nobody has yet taught 'vim' how to do D completion. It does a fairly good job just guessing based on what other things are in my files. None of this means that someone shouldn't get various IDEs to work with D. I'm just pointing out that there are still a large number of developers who don't use them, and don't really find them all that useful. David
Oct 14 2007
prev sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 10/14/07, Ary Manzana <ary esperanto.org.ar> wrote:
 Does nobody refactor their code? If so, how a text editor helps?

Why wouldn't a text editor help? I've always found it perfectly adequate to the task.
Oct 14 2007
prev sibling next sibling parent reply Henning Hasemann <hhasemann web.de> writes:
Since lots of things work differently in D and C++ it might be even
easier to compile D code into C like opendylan does for example.
(Note that you cant simple translate it to another language anyway. You
*will* have to "compile" it ie instantiate templates etc... Maybe that
would not even be *that* hard since there are a handful D code parsers
underway already)

I dont know if you are aware of it but there is already a gcc frontend
for D (called dgcc aka gdc) ie its possible to compile D code nearly
everywhere where a gcc runs, so getting D code to run on an xbox or
whatever shouldnt really be a problem I think.

Henning

-- 
GPG Public Key:
http://gpg-keyserver.de/pks/lookup?op=get&search=0xDDD6D36D41911851
Oct 14 2007
next sibling parent Raynor <memphis007fr yahoo.fr> writes:
Henning Hasemann a écrit :
 Since lots of things work differently in D and C++ it might be even
 easier to compile D code into C like opendylan does for example.
 (Note that you cant simple translate it to another language anyway. You
 *will* have to "compile" it ie instantiate templates etc... Maybe that
 would not even be *that* hard since there are a handful D code parsers
 underway already)
 
 I dont know if you are aware of it but there is already a gcc frontend
 for D (called dgcc aka gdc) ie its possible to compile D code nearly
 everywhere where a gcc runs, so getting D code to run on an xbox or
 whatever shouldnt really be a problem I think.
 
 Henning
 

And for the bug free problem : - If you compile some D code with gdc, then it just use a D parser and the common GCC native code generator. - If you make a compiler to translate D code to C or C++ it also uses a D parser so it isnt less "bug free". Moreover, Walter has already done some amazing C/C++ compiler and i think he reuses some code for D. So i think the majority of the problems is not on the native code generator.
Oct 14 2007
prev sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
Henning Hasemann wrote:
 Since lots of things work differently in D and C++ it might be even
 easier to compile D code into C like opendylan does for example.
 (Note that you cant simple translate it to another language anyway. You
 *will* have to "compile" it ie instantiate templates etc... Maybe that
 would not even be *that* hard since there are a handful D code parsers
 underway already)
 
 I dont know if you are aware of it but there is already a gcc frontend
 for D (called dgcc aka gdc) ie its possible to compile D code nearly
 everywhere where a gcc runs, so getting D code to run on an xbox or
 whatever shouldnt really be a problem I think.
 
 Henning
 

While gcc supports a lot of targets, some may be very proprietary and not have a gcc backend for them. You can probably get a C compiler for just about anything though. Also, and probably more importantly, getting gdc to cross compile isn't always that easy. I've been there with arm-wince-pe-gdc. It might be if you have a team of engineers, but on a volunteer basis - not so much. I'd love to see a D to C compiler. It seems to me like it would be a good temporary measure to use until D has the mega resources that the more popular languages now possess. Unfortunately, I don't have the time to spend on such an endeavor, so someone else will have to do this ;)
Oct 14 2007
prev sibling parent "Anders Bergh" <anders1 gmail.com> writes:
On 10/14/07, Richard Geary <tristram dial.pipex.com> wrote:
 To solve this, is there a D to C++ converter? Something to parse D code,
output it in C++ and build it with existing C++ tools? Whilst this is messy, it
would provide the functionality of D to environments which are unable to use
the D compiler.

There are 2 options: TDC, this is Gregor's D compiler which compiles to C... and then there's llvmdc which you can use together with one of the llvm tools to compile it to C. http://dsource.org/projects/tdc http://dsource.org/projects/llvmdc No idea how complete these are though Anders
Oct 14 2007