Honestly, I haven't followed recent developments - git for example - so I'm not going to go spout off unfounded opinions.

But, from experience writing a CVS/RCS web viewer I would say a relational storage system would make things a lot more logical...

-[Unknown]


Bjoern wrote:
> Unknown W. Brackets schrieb:
>> Sorry, didn't mean to be patronizing, thought you might've skimmed the rest.
> No problem, even if you mean it :)
>>
>> Actually, you're right.  I've had experience managing developers (as that's my current job in fact), and currently SCMs all seem to have their flaws.  At the same time, all of them make things easier than nothing at all.
>>
>> -[Unknown]
>>
> 
> It is not my intention to waste your time but I'm curious (enough) about your opinion regarding using a RDBMS as SCM working-horse.
> Bjoern

Daniel Lewis wrote:
> I'm volunteering to head up a web development project to revamp the
> 'site, should you be interested.  I'm sure a shiny new website would
> certainly give D a toe up in the external appeal department.

That would be great! Would you like to start with a revamped style.css ?

On 2008-01-23 06:09:54 -0500, Walter Bright <newshound1@digitalmars.com> said:

> Converting the site to Ddoc was a huge productivity booster for me, and also made the site much more consistent. Ddoc for phobos probably produced well over an order of magnitude improvement in the quality of the phobos documentation.

Have you thought about publishing all these pages in Ddoc format too? If one could replace the overview.html file in the URL with overview.d to get the Ddoc source, it'd be a great way to learn about Ddoc. Perhaps there could be a link to that source file beside "Page generated by Ddoc" in the footer of Ddoc-generated pages.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:
> On 2008-01-23 06:09:54 -0500, Walter Bright <newshound1@digitalmars.com> said:
> 
>> Converting the site to Ddoc was a huge productivity booster for me, and also made the site much more consistent. Ddoc for phobos probably produced well over an order of magnitude improvement in the quality of the phobos documentation.
> 
> Have you thought about publishing all these pages in Ddoc format too?

Yes, I've just never gotten around to it.

You mentioned IDEs a couple times, specifically in that they should be able to access DMD via some sort of API. While this would be great, Descent (in trunk, sadly the kinks are still being worked out...) takes a different approach. We have a full Java port of the DMD semantic front-end, which we are using to do things like display errors inline as the user types. From working with Descent, I can say that having programatic access to the AST would be nice, but since most advanced IDEs would want to extend it anyway, it's a lot of work for a small gain.

Robert Fraser Wrote:

> You mentioned IDEs a couple times, specifically in that they should be able to access DMD via some sort of API. While this would be great, Descent (in trunk, sadly the kinks are still being worked out...) takes a different approach. We have a full Java port of the DMD semantic front-end, which we are using to do things like display errors inline as the user types. From working with Descent, I can say that having programatic access to the AST would be nice, but since most advanced IDEs would want to extend it anyway, it's a lot of work for a small gain.

Yeah, D exposing the AST would be a *huge* benefit to modifying the compiler, and allowing things like third party profilers and optimizers.

For profiling, I've always argued that I want this:

~~~

I can't rightly find out all the things that modify my variable 'x' without an AST; so how am I supposed to notice when I write

if(x < 0)
   x = Math_bla(x);

before the only three places calling a function, and then inside the function deep in another file it's already got

int Math_bla(x) {
  if(x > 0)
    do something
  if(x == 0)
    do something else
  if(x == double.nan)
...
}

~~~

This really should be noticed by a profiler/optimizer, so that the programmer can detect impossible branch cases.  There's more.  We really ought to have a "potential range filter" for numbers; so when we do this:

x ^= 1;

And later we go:

switch(x) {
   case 1:
   case 2:
   case 3:
   case 4:
}

When we look at x in that switch, we see that it's inherently even.

The problem is intractable without an AST; and even then, the optimizer/profiler will be a grand project.

Actually, I'm much more interested in basic things: proper highlighting that stays up to date with the language, basic syntax checking that really works, proper error file/line integration that doesn't suffer from pretty printing, etc.

This is from my experience trying to write a D highlighter/language service using the VSIP package for Visual Studio.

But really that's just a thought.  I would like to see D do something else "cool" other than just the language itself, but the other things I noted are (imho) much bigger issues.

-[Unknown]


Robert Fraser wrote:
> You mentioned IDEs a couple times, specifically in that they should be able to access DMD via some sort of API. While this would be great, Descent (in trunk, sadly the kinks are still being worked out...) takes a different approach. We have a full Java port of the DMD semantic front-end, which we are using to do things like display errors inline as the user types. From working with Descent, I can say that having programatic access to the AST would be nice, but since most advanced IDEs would want to extend it anyway, it's a lot of work for a small gain.