October 12, 2009
language_fan wrote:
> Another point not mentioned here is that modern IDEs use incremental and interactive compilation model. The compiler should be run as a persistent background process and parsing should happen perhaps on the level of the current scope. Re-compiling a million line project after each key stroke simply makes no sense.

This would not require recompiling a million lines with every key stroke, unless you are editing a million line module.

> Even compiling the current module once per key stroke is too slow.

As you say, it should be done as a background process.

> Specifying an intermediate json/xml file format is a huge task considering the amount of language constructs, types etc. available in D.

It isn't. It's far less work than ddoc is, for example.

> I'm all for good tool support but as many have already mentioned, the support would only bring marginal improvements to small scale tools like vim and emacs. Usually small scale D projects (< 10000 lines of code) are written with those tools (feel free to prove me wrong). These are not the kinds of projects large enterprises would use D for, they use scripting languages for smaller tasks. Thus the overall improvement is minimal.

I think the bang for the buck on this is large.


> Spending the time on critical compiler bugs on the other hand would help everyone in the community.

That hasn't been shorted, look at the changelog!
October 12, 2009
Denis Koroskin wrote:
> I just believe rewriting it from scratch will be plain faster. I can also test the code much easier - if it produces exact same binary then it works correct.

The dmd front end is also written in a "D-ish" style which should make translation to D easier.
October 12, 2009
language_fan wrote:
> Mon, 12 Oct 2009 13:54:53 -0400, Jeremie Pelletier thusly wrote:
> 
>> language_fan wrote:
>> I get an entirely different file dialog on win7, and my gnome dialog on
>> ubuntu looks nothing like the screenshot you linked.
>>
>> This is the win7 dialog:
>> http://i.msdn.microsoft.com/Dd758094.Libraries_CommonFileDialog%28en-
> us,VS.85%29.png
> 
> This is pretty good in my book.
> 
>> This is close to what I have on ubuntu:
>> http://blogs.gnome.org/mortenw/wp-content/blogs.dir/26/files/2009/02/
> file-dialog2.png
> 
> Yuck.
> 
>> I have no Qt or KDE on both my linux installs (ubuntu 9 and a cross
>> linux from scratch), the GUI looks smooth and works great, using the
>> latest gnome 2.6 libraries.
>>
>> Why don't you install GTK+? You can't whine about applications built for
>> gnome looking ugly if you don't have gtk installed, it can live pretty
>> well alongside Qt, I used to do that until i switched to gnome after 2.6
>> was released.
> 
> I have little desire to embrace inferior technologies. Attempting OOP on C is ridiculous, it should be called POOP. It is a personal choice. Besides FLTK2/Qt work pays well enough. I also have no time for desktop environment wars, tyvm. GTK+ != Gnome, as you well might know. I simply have no reason to install libgtk* since no package depends on them.

I don't know if you're talking about gtk 1 or 2, I don't have gtk1 installed but gtk2 is always one of the first package i build when I create a linux from scratch, so many things depend on it.

I never had any issues using gnome without qt, yet I had plenty using KDE without gtk. Its just a matter of what software you build, I usually don't like the feel of KDE applications, its a matter of preferences there.

I agree that gnome being coded in C is plain ugly in the code, but the results are still very convenient to use. Oh and I know gtk != gnome, but its been a while since it left gimp to become part of the gnome set of libraries.
October 12, 2009
Walter Bright wrote:
> Denis Koroskin wrote:
>> I just believe rewriting it from scratch will be plain faster. I can also test the code much easier - if it produces exact same binary then it works correct.
> 
> The dmd front end is also written in a "D-ish" style which should make translation to D easier.

But some stuff doesn't quite match: for example, Expression is declared in expression.h. But not all methods are implemented in expression.c. There's at least the interpret() method, which is in interpret.c.

How would you translate this into D? Just mash everything into a single .d source file?
October 12, 2009
Hello Walter,

> Ellery Newcomer wrote:
> 
>> In the xml, will we see ct stuff and other transformations that DMD
>> performs on the source expanded?
>> 
> ct stuff? What is that? Won't see dmd operations on the source
> expanded. What you'll see is basically what ddoc generates, but in a
> machine readable format. I.e. you'll see function names, with their
> types, line number, comment, etc. Essentially what intellisense would
> pop up.
> 

template Foo (T) { T map(T[]) { ... } }

class Bar { mixin Foo!(int); }

void main()
{
  Bar bar;
  bar. /// will the IDE have to do anything special to see 'map' or will it just be listed as another function?
}

>> If your ide can't see or doesn't have compiler, it won't be able to
>> do much (erm duh)
>> 
> Yeah, but without a compiler why edit D source? <g>
> 

My normal setup is running eclipse on a windows box to edit files on a linux box (via file share) where I compile things (I need some other stuff from linux). For this, I have no need for a compiler on the box with the IDE unless the IDE needs it solely for the auto-complete.


October 12, 2009
language_fan wrote:
> I have little desire to embrace inferior technologies. Attempting OOP on C is ridiculous, it should be called POOP. It is a personal choice. 

They're also developing a C# like language, that uses the GTK object model as base: http://live.gnome.org/Vala
October 12, 2009
Hello Walter,

> 
> Think of what it provides as very similar to what ddoc does, except
> that instead of being in a human-readable format it would be a
> machine-readable one.

If that's what you are planning, I can tell you right now it's not enough. Much of the things IDEs need is not present in ddoc. Just off hand, I'd say more than 50% of the IDE features I use from C#/VS would need (much) more than ddoc has. What would be better is a dump of a fully annotated AST from just before it's passed off for optimization and code gen.


October 12, 2009
Hello Walter,

> Jérôme M. Berger wrote:
> 
>>> . all the symbols in that module, and the members of those symbols
>>> (recursively)
>>> 
>> Including local variables for functions?
>> 
> That seems pointless, as they'll be inaccessible outside of the scope
> of the function.
> 

Good auto compleat needs a list of *Every* allowed identifier at any point in the code. Basicly the full symbol table.


October 12, 2009
Hello Walter,

> Robert Clipsham wrote:
> 
>> How well will this work with partially parsable files?
>> 
> Probably not very well. This would work best with getting information
> from modules other than the one being edited.
> 

Ouch. There goes about half of what people will want.


October 12, 2009
On Mon, Oct 12, 2009 at 11:32 AM, Walter Bright <newshound1@digitalmars.com> wrote:

>> Specifying an intermediate json/xml file format is a huge task considering the amount of language constructs, types etc. available in D.
>
> It isn't. It's far less work than ddoc is, for example.
>
>> I'm all for good tool support but as many have already mentioned, the support would only bring marginal improvements to small scale tools like vim and emacs. Usually small scale D projects (< 10000 lines of code) are written with those tools (feel free to prove me wrong). These are not the kinds of projects large enterprises would use D for, they use scripting languages for smaller tasks. Thus the overall improvement is minimal.
>
> I think the bang for the buck on this is large.

Even if this turns out to be useless for IDEs, it'll still be good for creating external documentation generators that go beyond what DDoc is capable of providing.   I think the subject of DDoc's limitations has come up more than once here.   Put in another light, it sounds like this would basically be the D equivalent of GCC-XML.  Which I think has been found to have many interesting uses.   For instance Gregor used GCC-XML to put together a D bindings generator for C code.   With this XML/JSON output, someone could do similar and write a <your language here> bindings generator for D code.   That could be handy if you want to call your D code from C or C# or whatever.

But it doesn't sound to me like it will be that much use to serious IDEs.

--bb