View mode: basic / threaded / horizontal-split · Log in · Help
September 10, 2004
Most important issues for D (MIID)
In some delightful ways, D is a victim of its own success. There's a lot of
traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
a day goes by without new proposals for features. It's simply beyond my
capacity to give these all the attention they deserve, or even to read them
all. I probably spend a minimum of 2 hours a day reading messages, and I
could easilly spend 12 hours a day at it, and accomplish nothing else.

Hence, I inadvertently overlook important issues. I know that this has been
frustrating to some people, and I apologize for it.

So I'd like to kick off this thread as an opportunity for all to post their
two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
mean pragmatic things like:

1) compiler bugs
2) language shortcomings with no reasonable workarounds
3) issues that are fundamentally blocking projects from using or proceeding
with D
4) severe library faults

I don't mean things like:

1) D 2.0 issues
2) feature proposals like "It would be nice if ..."
3) minor irritants
4) philosophical issues
5) issues that have been beaten to death already <g>

If a thread here exists for the topic, a reference to that thread would be
nice rather than reproducing it.

It's time to prioritize and get us on a rational, sensible path for
releasing 1.0.
September 10, 2004
Re: Most important issues for D (MIID)
#1 DLL's + GC + threading. This is a sine qua non for D, and I'd hazard to suggest it may be the most important thereof. 
I'd suggest Eric and Kris write a discussion paper/proposal on this, which I'd be happy to review/slag/bemoan, but I 
think Kris is holidaying at the moment. Eric, if you want to make a start, that'd be cool, or we can wait for the return 
of our demure friend.
#2 The parlous and inconsistent state of Phobos. Phobos needs to be a killer library when 1.0 launches: lean, efficient, 
cohesive, low-coupling, discoverable, expressive, and without inconsistency. Currently it is a scrappy, crappy, 
embarassing mess (and I'm in no way exempting some of my own contributions). We're going to start with an Exceptions 
refactoring. Hopefully, that will be the start of several such reviews/refactorings, and we'll eventually end up with 
something grand.


"Walter" <newshound@digitalmars.com> wrote in message news:cht9gl$20m8$1@digitaldaemon.com...
> In some delightful ways, D is a victim of its own success. There's a lot of
> traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
> a day goes by without new proposals for features. It's simply beyond my
> capacity to give these all the attention they deserve, or even to read them
> all. I probably spend a minimum of 2 hours a day reading messages, and I
> could easilly spend 12 hours a day at it, and accomplish nothing else.
>
> Hence, I inadvertently overlook important issues. I know that this has been
> frustrating to some people, and I apologize for it.
>
> So I'd like to kick off this thread as an opportunity for all to post their
> two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
> mean pragmatic things like:
>
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or proceeding
> with D
> 4) severe library faults
>
> I don't mean things like:
>
> 1) D 2.0 issues
> 2) feature proposals like "It would be nice if ..."
> 3) minor irritants
> 4) philosophical issues
> 5) issues that have been beaten to death already <g>
>
> If a thread here exists for the topic, a reference to that thread would be
> nice rather than reproducing it.
>
> It's time to prioritize and get us on a rational, sensible path for
> releasing 1.0.
>
>
September 10, 2004
Re: Most important issues for D (MIID)
Issues that have affected me personally:

Partially broken TypeId's for pointers and structs.  Reference here:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1293

An access problem with private members in nested classes.  Reference here:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1189

Bug with stdargs used in multiple translation units.  Reference here:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1137

Beyond that, I think Eric's thread about module imports deserves some attention.
At the very least, I think it is important that every module that has a static
constructor has that constructor called on initialization (I think this was an
issue with private imports), and that module initialization order is correct
whenever appropriate.  I agree that if a module has no static constructor then
its order in initialization shouldn't matter.

Also, Matthew's mention of dlls, gc, and threading are all quite important,
though I haven't played with that stuff enough to know the issues very well.
And exceptions need to be sorted out, but Matthew is currently working on that.


Sean
September 10, 2004
Re: Most important issues for D (MIID)
I'll try to reproduce a bug.

1)

#class Array(T) {
#public:
#	T[] data;
#public:
#	void bug() {
#		printf("Why is this happening?");
#	}
#	// this seems to cause the problem, take it out and it will work
#	int opCast() {
#		return data.length;
#	}
#}
#
#class StringTemplate(T) : Array!(T) {
#public:
#	this(T[] l) {
#		data = l;
# 	}	
# 	this() { }
#}
#
#alias StringTemplate!(char) String;
#
#void main() {
#	String a = new String;
#	a.bug(); // taking this out also helps, it seems to be related to opCast
#}

It seems base classes don't like cast overloading so well. It doesn't crash the
compiler, it doesn't even output an error, it just happily quits. (actually I'm
not that high on what kind of emotions compilers have)

2)

This is more some kind of a feature request. I've found more bugs though I can't
seem to isolate them, so that would be pointles. Anyway, what I'd like to see is
that something like this would be possible:

#class Array(T) {
#public:
#   ...
#   Array!(typeof(this)) split(T by) {
#       ...
#   }
#}

I can see it would be hard to add since it would be recursive. Though, maybe it
would be useful (especially for making a stl make sense) to somehow make it that
when the compiler finds a return type similar to a template construction, it
doesn't create the class from the template yet, rather he only does that once it
finds the function being called, keeping it from doing pointles recursion.

It's minor though ;) But it would make sense. You could make things like:

new String("file.exe").split('.').top();

more easily (actually that would be the only way, if you want to maintain
concistancy (?)). Whereas now you have to (from a more developed point of view):

String[] a = new String("file.exe").split('.');
String ext = a[a.length - 1];

or when you're smart, you could make split in the template, so you'd call it
String.split(new String()).top(), but that would look, I don't know, weirdish.
It's like making OO modular, where every member function of a class is also
member of the global namespace, but with left side arguments (bar from Foo can
be using in global as bar(foo_object)). Though this sometimes is a good thing,
you'd often want to be able to do both.

Anyway, not important ;)

3) I'm a rebel ;)

I agree that phobos should be better. A lot better. Maybe it should even be
recoded from scratch. I'm currently working on my own stl, dragonstl, which also
provides a minor wrapper around phobos. I mean, wrapping D in D? They should
totally drop things like printf, and they should try writing the whole thing in
pure D (it's capable). I would like to help with phobos but I don't think I'm
good enough, I can be volunteer idiot though.

-Joey

>
>In some delightful ways, D is a victim of its own success. There's a lot of
>traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
>a day goes by without new proposals for features. It's simply beyond my
>capacity to give these all the attention they deserve, or even to read them
>all. I probably spend a minimum of 2 hours a day reading messages, and I
>could easilly spend 12 hours a day at it, and accomplish nothing else.
>
>Hence, I inadvertently overlook important issues. I know that this has been
>frustrating to some people, and I apologize for it.
>
>So I'd like to kick off this thread as an opportunity for all to post their
>two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
>mean pragmatic things like:
>
>1) compiler bugs
>2) language shortcomings with no reasonable workarounds
>3) issues that are fundamentally blocking projects from using or proceeding
>with D
>4) severe library faults
>
>I don't mean things like:
>
>1) D 2.0 issues
>2) feature proposals like "It would be nice if ..."
>3) minor irritants
>4) philosophical issues
>5) issues that have been beaten to death already <g>
>
>If a thread here exists for the topic, a reference to that thread would be
>nice rather than reproducing it.
>
>It's time to prioritize and get us on a rational, sensible path for
>releasing 1.0.
>
>
September 11, 2004
Re: Most important issues for D (MIID)
#1:

<snip>
void foo()
{
    class Foo
    {
        int x;
    }
}

void bar()
{
    class Foo
    {
        int y;
    }

    Foo f = new Foo;
    f.y = 5;
}

void main()
{
}
</snip>

<result>
foo.d(17): no property 'y' for type 'Foo'
</result>

<comment>
the class Foo declared in function foo somehow obscures the Foo class in 
function bar. This should not be the case ;)
</comment>



#2:

it would be nice if array arithmetic operations were implemented in ANY 
way so we can start using them



Keep up the good work !
Tom
September 11, 2004
Re: Most important issues for D (MIID)
"Sean Kelly" <sean@f4.ca> wrote in message
news:chtckm$21uv$1@digitaldaemon.com...
> Beyond that, I think Eric's thread about module imports deserves some
attention.
> At the very least, I think it is important that every module that has a
static
> constructor has that constructor called on initialization (I think this
was an
> issue with private imports), and that module initialization order is
correct
> whenever appropriate.  I agree that if a module has no static constructor
then
> its order in initialization shouldn't matter.

This is fixed, will go out in next update.
September 11, 2004
Re: Most important issues for D (MIID)
#1) compile loader.d into libphobos.a on linux

#2) when you use goto label; and there is no label "label," it spits out 
 this horrid error message "Error: undefined label bob" that doesn't 
give filename or line number.

Walter wrote:
> In some delightful ways, D is a victim of its own success. There's a lot of
> traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
> a day goes by without new proposals for features. It's simply beyond my
> capacity to give these all the attention they deserve, or even to read them
> all. I probably spend a minimum of 2 hours a day reading messages, and I
> could easilly spend 12 hours a day at it, and accomplish nothing else.
> 
> Hence, I inadvertently overlook important issues. I know that this has been
> frustrating to some people, and I apologize for it.
> 
> So I'd like to kick off this thread as an opportunity for all to post their
> two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
> mean pragmatic things like:
> 
> 1) compiler bugs
> 2) language shortcomings with no reasonable workarounds
> 3) issues that are fundamentally blocking projects from using or proceeding
> with D
> 4) severe library faults
> 
> I don't mean things like:
> 
> 1) D 2.0 issues
> 2) feature proposals like "It would be nice if ..."
> 3) minor irritants
> 4) philosophical issues
> 5) issues that have been beaten to death already <g>
> 
> If a thread here exists for the topic, a reference to that thread would be
> nice rather than reproducing it.
> 
> It's time to prioritize and get us on a rational, sensible path for
> releasing 1.0.
> 
>
September 11, 2004
Re: Most important issues for D (MIID)
On Fri, 10 Sep 2004 15:18:03 -0700, "Walter"
<newshound@digitalmars.com> wrote:

>In some delightful ways, D is a victim of its own success. There's a lot of
>traffic in the D newsgroups, sometimes getting to 100 messages per day. Not
>a day goes by without new proposals for features. It's simply beyond my
>capacity to give these all the attention they deserve, or even to read them
>all. I probably spend a minimum of 2 hours a day reading messages, and I
>could easilly spend 12 hours a day at it, and accomplish nothing else.
>
>Hence, I inadvertently overlook important issues. I know that this has been
>frustrating to some people, and I apologize for it.
>
>So I'd like to kick off this thread as an opportunity for all to post their
>two Most Important Issues for D with respect to getting 1.0 done. By MIID, I
>mean pragmatic things like:
>
>1) compiler bugs
>2) language shortcomings with no reasonable workarounds
>3) issues that are fundamentally blocking projects from using or proceeding
>with D
>4) severe library faults
>
>I don't mean things like:
>
>1) D 2.0 issues
>2) feature proposals like "It would be nice if ..."
>3) minor irritants
>4) philosophical issues
>5) issues that have been beaten to death already <g>
>
>If a thread here exists for the topic, a reference to that thread would be
>nice rather than reproducing it.
>
>It's time to prioritize and get us on a rational, sensible path for
>releasing 1.0.
>

* compiler bug with volatile statements and templates:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/1668

* any writef bug or stdarg bug. Is the following still a problem?
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/5757
I can't reproduce it on Windows. I've started shying away from writef
because I don't trust it.

Also I'd like to make sure the Linux support is on par with the
Windows support. Last time I tried I had troubles recompiling phobos
on Linux. Walter have you recompiled phobos from scratch with
unittests on Linux recently? Does it pass? I seem to always have to
clean up phobos before it gets close to working. See, for example,
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/9119
September 11, 2004
Re: Most important issues for D (MIID)
On Fri, 10 Sep 2004 15:18:03 -0700, Walter wrote:

> In some delightful ways, D is a victim of its own success.
[...]
> I inadvertently overlook important issues. I know that this has been
> frustrating to some people, and I apologize for it.

no need to appologize, we thank you for your efford!

here is a quote from a post on slashdot:

"
When a volunteer gives you a product for free and it is defective, you let
the person know what's wrong, offer to retest it if they try to fix it,
and if you have any time & talent to draw on, you offer to fix the problem
and send in a patch. You NEVER, EVER complain. The worst you have the
right to say is "I hope they take care of it in the next release".
"

http://developers.slashdot.org/developers/04/09/08/125208.shtml?tid=104&tid=152&tid=8

> two Most Important Issues

1) ability to generate shared libraries on linux.
2) add symbolic debug info on linux.

Ant
September 11, 2004
Re: Most important issues for D (MIID)
<alert comment="newbie">

Reasonably stable and mature "official" gui library with enough widgets to
put simple non-console apps together (may or may not be all that portable)

Reasonably stable and mature ide with symbolic debugger and step-into and
step-over. If already available, documentation for it.

</alert>
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home