Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | #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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | #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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | "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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | #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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | <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> |
Copyright © 1999-2021 by the D Language Foundation