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.


 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


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.


result is the C version of D2C.



4. Use the native C compiler on platform B to compile the C code copied


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

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

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.


 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

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.


 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

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 "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
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, 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 reply 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
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 "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
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 "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
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 next 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
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
next sibling 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.
 


 <http://vimdoc.sourceforge.net/htmldoc/if_ole.html#MSVisualStudio>  :)
 


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.


 <http://vimdoc.sourceforge.net/htmldoc/if_ole.html#MSVisualStudio>  :)


 
 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.
 


 <http://vimdoc.sourceforge.net/htmldoc/if_ole.html#MSVisualStudio>
 :)
 


 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.
 


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?
 


 I believe it's called Eclipse  ;)
 
 -- 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 parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Robert Fraser Wrote:


 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.
 


Use script foo.
 grep -l "error message" | xargs mysearchandreplacefoo.sh

mysearchandreplacefoo.sh


for FILE in $*; do
  sed -e s/<oldName>/<newName>/g < $FILE > $FILE.tmp
  cp $FILE.tmp $FILE
done

Insert favourite scripting language foo in place of ugly old-fashioned 
Bourne shell. There's not much more than that going on under the hood of a lot
of these fancy IDEs anyway. 
Okay the syntax awareness makes it a hell of a lot less ugly.


 I think the point is that IDEs, while not essential, can certainly do a lot of
things that are helpful. For example,
 


Absolutely.


 * Show exactly where in a huge string mixin an error occurs


Maybe the design would be better if the mixin were broken down
into brain size chunked chunks.


 * 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.


You still have to read the documentation to know what other functions it
interacts with. Otherwise you might end up mixing printf's
and couts using the facilities of two libraries where one might suffice.
That said. Having some kind of hypertext link to the documentation is really
helpful.


 * 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 hope the IDE writers are ticking these off on their feature request lists.

The real power of an IDE comes through being able to script it. This is what
made emacs such a success.


 
 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.


Its also about changing IDEs. When your own your own system you can usually
pick whatever IDE suits you best but even in the 21st century, though it
sickens me I occasionally find I have to use vi. I hate vi. vi is an
abomination. It just happens to be the lowest common denominator sometimes. 

Your point also gets us back on topic as using D versus using C or C++ for the
last X years is even more daunting a transition.

Regards,

Bruce
Oct 15 2007
next sibling parent reply David Brown <dlang davidb.org> writes:
On Mon, Oct 15, 2007 at 07:31:16PM -0400, Bruce Adams wrote:


Its also about changing IDEs. When your own your own system you can
usually pick whatever IDE suits you best but even in the 21st century,
though it sickens me I occasionally find I have to use vi. I hate vi. vi
is an abomination. It just happens to be the lowest common denominator
sometimes. 


Every single line of 'D' code I have ever written has been within vim.  In
fact, nearly every line of code in any language I've ever written in the
past 10 years or so has been in vim.  Before that, it was emacs, before
that vi, and before that teco.

Modern versions of VIM do many of the things people think you need an IDE
for.

Even this email is composed in vim.

All this really shows is that there is a lot more to what one is used to,
and personal preference than people give credit to.

David
Oct 15 2007
next sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
David Brown Wrote:


 On Mon, Oct 15, 2007 at 07:31:16PM -0400, Bruce Adams wrote:
 

Its also about changing IDEs. When your own your own system you can
usually pick whatever IDE suits you best but even in the 21st century,
though it sickens me I occasionally find I have to use vi. I hate vi. vi
is an abomination. It just happens to be the lowest common denominator
sometimes. 


 
 Every single line of 'D' code I have ever written has been within vim.  In
 fact, nearly every line of code in any language I've ever written in the
 past 10 years or so has been in vim.  Before that, it was emacs, before
 that vi, and before that teco.
 
 Modern versions of VIM do many of the things people think you need an IDE
 for.
 
 Even this email is composed in vim.
 
 All this really shows is that there is a lot more to what one is used to,
 and personal preference than people give credit to.
 
 David


vim is a better vi. I'm talking vanilla vi when I say I hate it. I don't really
like vim either but I appreciate the syntax highlighting. 
You did say one thing that shocked me however. You switched from emacs to vim.
I would have though the switch would be the other way around. What were the
motivating factors?

Regards,

Bruce.
Oct 15 2007
parent David Brown <dlang davidb.org> writes:
On Mon, Oct 15, 2007 at 08:16:56PM -0400, Bruce Adams wrote:


You did say one thing that shocked me however. You switched from emacs to
vim. I would have though the switch would be the other way around. What
were the motivating factors?


Originally carpel-tunnel.  Once I discovered that Vim could do the
important things I wanted emacs for (syntax coloring, multiple-windows,
indenting, and such), I learned the advanced features of Vim, and my wrists
recovered.

My other gripe with emacs is that there is no stable version that has
anti-aliased text rendering.  Other issues are that I could never run it
anywhere else, because I didn't have my massive customizations from my .emacs
file.

David
Oct 15 2007
prev sibling parent TomD <nospam anymo.re> writes:
David Brown Wrote:

[...]

 Every single line of 'D' code I have ever written has been within vim.  In
 fact, nearly every line of code in any language I've ever written in the
 past 10 years or so has been in vim.  Before that, it was emacs, before
 that vi, and before that teco.


Teco. On a PDP-11. Well, the assembler was not that bad then.
Man, you make me feel really old :-)

Ciao
Tom
Oct 16 2007
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruce Adams, by the way, what program are you using to post in the 
newsgroups?

:)



-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Bruno Medeiros Wrote:


 Bruce Adams, by the way, what program are you using to post in the 
 newsgroups?
  >:)
 
 
 -- 
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


The web interface. Its clunky but it works from opera.
Oct 15 2007
parent reply Regan Heath <regan netmail.co.nz> writes:
Bruce Adams wrote:

 Bruno Medeiros Wrote:
 

 Bruce Adams, by the way, what program are you using to post in the 
 newsgroups?
  >:)


 -- 
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


 
 The web interface. Its clunky but it works from opera.


But.. Opera has a news reader built in, why not use that?

Regan
Oct 16 2007
parent reply Bruce Adams <tortoise_74 yeah.who.co.yk> writes:
Regan Heath Wrote:


 Bruce Adams wrote:

 Bruno Medeiros Wrote:
 

 Bruce Adams, by the way, what program are you using to post in the 
 newsgroups?
  >:)


 -- 
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


 
 The web interface. Its clunky but it works from opera.


 
 But.. Opera has a news reader built in, why not use that?
 
 Regan


Simple answer, I haven't got around to it. I've heard the web interface has
problems but I've not actually seen them. Presumably something is wrong with my
posts or we wouldn't be having this conversation. So what is it?

Bruce.
Oct 16 2007
parent BCS <ao pathlink.com> writes:
Reply to Bruce,


 Regan Heath Wrote:
 

 Bruce Adams wrote:
 

 Bruno Medeiros Wrote:
 

 Bruce Adams, by the way, what program are you using to post in the
 newsgroups?
 

 :)
 


 --
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


 The web interface. Its clunky but it works from opera.
 


 But.. Opera has a news reader built in, why not use that?
 
 Regan
 


 Simple answer, I haven't got around to it. I've heard the web
 interface has problems but I've not actually seen them. Presumably
 something is wrong with my posts or we wouldn't be having this
 conversation. So what is it?
 
 Bruce.
 


the web interface has a habit of not getting the reply to stuff correct and 
then news readers see posts as a new thread, not a reply.
Oct 16 2007
prev sibling parent reply Uno <unodgs tlen.pl> writes:
 The real power of an IDE comes through being able to script it. This 


is what made emacs such a success.

Please stop claiming vi, emacs, grep (etc) are so great. Without any 
doubt D needs "normal" IDE. It's much easier for average user to work 
with. Debugging, compiling and running must work out of the box (for 
example press F5 to debug, ctrl-f5 to run, and you can see it in main 
menu/toolbar, no need to browse editor documentation to find esc, x,y,z 
combination ;) ). Good graphical IDE is one of the main key to make D 
more popular.
Oct 16 2007
parent Bruce Adams <tortoise_74 yeah.who.co.yk> writes:
Uno Wrote:


  > The real power of an IDE comes through being able to script it. This 
 is what made emacs such a success.
 
 Please stop claiming vi, emacs, grep (etc) are so great. Without any 
 doubt D needs "normal" IDE. It's much easier for average user to work 
 with. Debugging, compiling and running must work out of the box (for 
 example press F5 to debug, ctrl-f5 to run, and you can see it in main 
 menu/toolbar, no need to browse editor documentation to find esc, x,y,z 
 combination ;) ). Good graphical IDE is one of the main key to make D 
 more popular


I can see this thread is running out of steam.
F5 is no more standard than esc x,y,z. Most editors let you alter the key
bindings. I think even VC++ has this. Emacs of course had it all along.

Bruce.
Oct 16 2007
prev sibling next sibling parent reply 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
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 "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
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 reply 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
parent reply 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
parent David Brown <dlang davidb.org> writes:
On Mon, Oct 15, 2007 at 07:37:59PM -0400, Bruce Adams wrote:


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.


Doesn't work terribly well on a laptop connected via a 3G data connection.
The X connection needs several orders more magnitude to be useful.

That said, I usually prefer synchronizing the projects to the local
machine, using something like 'unison'.

When working with DSL, my ssh/vim editing is indistinguishable from local,
where a forwarded X11 connection is painful.

David
Oct 15 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.
 


 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.
 


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 parent reply "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
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 reply "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
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.


well, that's a view created by using a MS product.
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?
 


i've installed the eclipse distribution from yoxos, witch gave me a long 
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 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 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 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 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 next 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
prev sibling next sibling parent reply Jussi Jumppanen <jussij zeusedit.com> writes:
Ary Manzana Wrote:


 Does nobody refactor their code? 


I do have to admit the refactoring rename feature found in the MS 
Visual Studio IDE is very nice, but I'm not going to change my text 
editor just for one feature.


 If so, how a text editor helps?


Refactoring is still possible in a text editor:

 Syep 1) Run a grep to find all the instances of text
 Syep 2) Load up all the files found 
 Syep 3) Change each name one at a time or all in one hit
 Syep 4) Run a build to check your changes

This might take an extra minute or two, but it's still pretty 
easy todo.
Oct 14 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jussi Jumppanen wrote:

 Ary Manzana Wrote:
 

 Does nobody refactor their code? 


 
 I do have to admit the refactoring rename feature found in the MS 
 Visual Studio IDE is very nice, but I'm not going to change my text 
 editor just for one feature.
 

 If so, how a text editor helps?


 
 Refactoring is still possible in a text editor:
 
  Syep 1) Run a grep to find all the instances of text
  Syep 2) Load up all the files found 
  Syep 3) Change each name one at a time or all in one hit
  Syep 4) Run a build to check your changes
 
 This might take an extra minute or two, but it's still pretty 
 easy todo.


Where grep doesn't work so well is when you want to rename a variable 
called 's' to something else.  Or a better example is changing the name 
of a member of one class only.  Say we want to change the "name" member 
of one class.   That's likely to have a lot of false hits that grep, 
without any semantic knowledge, won't be able to help you with.  A good 
refactoring IDE can (I think!) distinguish between things called 'name' 
that are referring to the member of the class in question and those that 
aren't.

--bb
Oct 14 2007
next sibling parent BCS <ao pathlink.com> writes:
Reply to Bill,


 Jussi Jumppanen wrote:
 

 Ary Manzana Wrote:
 

 Does nobody refactor their code?
 


 I do have to admit the refactoring rename feature found in the MS
 Visual Studio IDE is very nice, but I'm not going to change my text
 editor just for one feature.
 

 If so, how a text editor helps?
 


 Refactoring is still possible in a text editor:
 
 Syep 1) Run a grep to find all the instances of text
 Syep 2) Load up all the files found
 Syep 3) Change each name one at a time or all in one hit
 Syep 4) Run a build to check your changes
 This might take an extra minute or two, but it's still pretty easy
 todo.
 


 Where grep doesn't work so well is when you want to rename a variable
 called 's' to something else.  Or a better example is changing the
 name of a member of one class only.  Say we want to change the "name"
 member of one class.   That's likely to have a lot of false hits that
 grep, without any semantic knowledge, won't be able to help you with.
 A good refactoring IDE can (I think!) distinguish between things
 called 'name' that are referring to the member of the class in
 question and those that aren't.
 
 --bb
 


how about a Refactoring primitives tool set:

tool1: runs like DMD but dumps the name of the symbol at a given location

tool2: same as tool1 but in reverse, lists the location of every reference 
to symbol "____"

a few more tools along this line (and a lib of the code behind them) and 
you could whip out a lot of refactoring stuff really quick
Oct 14 2007
prev sibling next sibling parent Jussi Jumppanen <jussij zeusedit.com> writes:
Bill Baxter Wrote:


 A good refactoring IDE can (I think!) distinguish between 
 things called 'name' that are referring to the member of 
 the class in question and those that aren't.


The MS Visual Studio name refactoring feature does 
exactly that.
Oct 14 2007
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Where grep doesn't work so well is when you want to rename a variable 
 called 's' to something else.


That'll teach anyone not to use single letter names for non-locals <g>.
Oct 15 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:

 Bill Baxter wrote:

 Where grep doesn't work so well is when you want to rename a variable 
 called 's' to something else.


 
 That'll teach anyone not to use single letter names for non-locals <g>.


But the same scenario is true of local variables too.
A refactoring tool can help you rename every 's' within a function 
without messing up other symbols that just happen to contain that letter.

--bb
Oct 15 2007
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:

 Walter Bright wrote:

 Bill Baxter wrote:

 Where grep doesn't work so well is when you want to rename a variable 
 called 's' to something else.


 That'll teach anyone not to use single letter names for non-locals <g>.


 
 But the same scenario is true of local variables too.
 A refactoring tool can help you rename every 's' within a function 
 without messing up other symbols that just happen to contain that letter.


True, that'd be nice, but it isn't compelling by itself. With the other 
features Robert mentioned, the aggregate becomes compelling.
Oct 15 2007
prev sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Mon, 15 Oct 2007 18:30:18 +0900
Bill Baxter <dnewsgroup billbaxter.com> wrote:

 But the same scenario is true of local variables too.
 A refactoring tool can help you rename every 's' within a function 
 without messing up other symbols that just happen to contain that
 letter.


How great, that my text editor can work with regex on ranges. :)

-- 
Alexander Panek <alexander.panek brainsware.org>
Oct 15 2007
prev sibling next sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
BLS Wrote:


 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


Its not in dispute that a good IDE can improve your productivity. It is in
dispute that its the best way. Clearly a lot of us are here because we believe
improving the language is a better solution than simply using a better IDE for
C++.

Bruce.
Oct 15 2007
prev sibling next sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Chad J Wrote:


 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 ;)


Recently there was a thread about creating a D cross compiler. It sounds like
you've been there and got the T-shirt. Perhaps you could upload some of your
experiences and hints to the/a wiki? 

Regards,

Bruce.
Oct 15 2007
prev sibling next sibling parent reply Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Bruno Medeiros Wrote:


 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


I fear your hopes of the one true IDE are just as misguided as hopes for one
true programming language, one true OS, one true GUI library and the holy grail
but good luck.The red-queen effect of competition is an important stimulus to
innovation.

Regards,

Bruce.
Oct 15 2007
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Bruce Adams wrote:

 Bruno Medeiros Wrote:
 

 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


 
 I fear your hopes of the one true IDE are just as misguided as hopes for one
true programming language, one true OS, one true GUI library and the holy grail
but good luck.The red-queen effect of competition is an important stimulus to
innovation.
 
 Regards,
 
 Bruce.
 


By "one definite D Eclipse IDE" I meant one true Eclipse-based D IDE in 
the universe of all Eclipse-based D IDEs, not in the universe of all D IDEs.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Oct 15 2007
parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
Bruno Medeiros Wrote:


 Bruce Adams wrote:

 Bruno Medeiros Wrote:
 

 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


 
 I fear your hopes of the one true IDE are just as misguided as hopes for one
true programming language, one true OS, one true GUI library and the holy grail
but good luck.The red-queen effect of competition is an important stimulus to
innovation.
 
 Regards,
 
 Bruce.
 


 
 By "one definite D Eclipse IDE" I meant one true Eclipse-based D IDE in 
 the universe of all Eclipse-based D IDEs, not in the universe of all D IDEs.
 
 -- 
 Bruno Medeiros - MSc in CS/E student
 http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D


Ah. That makes much more sense to me now. Yes I agree. One D for eclipse and no
forking until its forking ready.

Regards,

Bruce.
Oct 15 2007
prev sibling parent Bruce Adams <tortoise_74 yeah.who.co.uk> writes:
David Brown Wrote:


 On Mon, Oct 15, 2007 at 07:37:59PM -0400, Bruce Adams wrote:
 

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.


 
 Doesn't work terribly well on a laptop connected via a 3G data connection.


Ouch! 


 The X connection needs several orders more magnitude to be useful.


Yes the protocol is long overdue a complete overhaul.
 

 That said, I usually prefer synchronizing the projects to the local
 machine, using something like 'unison'.
 
 When working with DSL, my ssh/vim editing is indistinguishable from local,
 where a forwarded X11 connection is painful.
 
 David


I see. I prefer the forwarding solution because emacs in an xterm is not as
nice.
Oct 15 2007