www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Opinion of February 2012

reply Zachary Lund <admin computerquip.com> writes:
Here are some things I'm unhappy with currently.

1. Documentation

I find certain things, of which I will start writing down and writing 
patches for, in the documentation that are unsatisfactory. Two in 
particular is the current situation with memory management and CTFE. 
"delete" is planned for deprecation and alternative methods for custom 
de/allocators are already in place, yet most people don't even know 
about them or how to use them. I see talk on IRC about things that 
completely confuse me as to the state of things and I can generally find 
no obvious or reliable source of information. It's completely frustrating.

Documentation is much more important than feature implementation.

2. Milestones and Organization

Despite the initiative Andrei took to get the community organized and 
most people completely shutting his attitude down, D is still left in a 
a rather unorganized state. I don't mind DMD using bugzilla but 
extensive use of the simple milestone feature should be made and posted 
somewhere on the site to be made clearly visible as a semi-roadmap to 
the next release. Currently, there's no milestone for 2.058 (although 
there is one for 2.059 which makes no sense) so it seems that the 2.058 
release will be, once again, completely random. At this point, I'd say 
the state of organization is still pathetic and/or scary.

3. FAQ

I think there was a discussion somewhere (of which I can't find now 
through Thunderbird search) but the FAQ is important. When people wonder 
about a feature of D, the first thing they should do is check the FAQ to 
find the answer.

I think that each time a solution is provided that might or might not be 
obvious, the reasoning behind that solution should be posted on the FAQ. 
Nothing should be left with abstract reasoning (outside of perhaps 
philisophy-based reasoning).

The FAQ is incomplete.

4. Microsoft

Windows. I cannot stand Windows. If Microsoft suddenly went bankrupt, 
Windows was never updated, and people had to move to MacOS or Linux, I 
would be the happiest man alive. Unfortunately, this will seemingly 
never be the case and it stands that Microsoft has the highest share of 
all the OS users. Thus, it should be given higher priority to attract 
more users. When people complain about D not having large Windows 
support (or COFF support in particular and the shitty optlink), it kills 
me a little on the inside.

5. Naming

This is probably a lost cause but I've recently seen various complaints 
about the name "D". It's not distinct nor is D old enough to be known 
like C or C++ is. I remember a comment about the name "Mars" which I 
think would have been much more distinct and clearcut, and would have 
caused less issues.

It also drives me insane that dmd for D2 is not named dmd2. There's no 
reason to not have it be dmd2 and you just stupidly caused 
incompatibility with the D1 executable. Not that it matters anymore but 
the fact that that's what happened looks incredibly dumb. Software like 
DVM popped up and while I appreciate such software, I don't think such 
software should be needed in the first place. Although, I do realize DVM 
has other uses.

The .c extensions on C++ files... need I say more? That itself is a joke 
and seems to have been ignored when complaints about it came up. I've 
just recently been told that DMD was mostly implemented in C which is 
false. This situation is needlessly frustrating.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

I'm not really affected by the in-language subtleties so much nor do 
they bother me. I'll post a bug if I find one, it will eventually get 
fixed, and I continue to use D. However, I can't help but complain about 
things when they're going unnoticed or unattended. I'd like to place my 
own personal emphasis on things I think need more thought put into them 
each month. Most of these complaints should have greater reasoning 
behind them which I will state. However, please comment on where I'm 
wrong or your own opinion against mine.

I like the D language. Not so much the projects that surround D.
Feb 03 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Zachary Lund:

 The .c extensions on C++ files... need I say more? That itself is a joke 
 and seems to have been ignored when complaints about it came up. I've 
 just recently been told that DMD was mostly implemented in C which is 
 false. This situation is needlessly frustrating.

Aren't less than 10 minutes enough to fix this simple problem? I don't know why Walter likes to use ".c" as suffix for those files, I don't remember his answers on this topic, I have never appreciated this naming decision. Bye, bearophile
Feb 03 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:jght4f$2co0$1 digitalmars.com...
 I don't know why Walter likes to use ".c" as suffix for those files, I 
 don't remember his answers on this topic,

In the most recent discussion he just dodged the question and joked about the "platform nobody uses" bit.
Feb 03 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2012 4:11 PM, bearophile wrote:
 Aren't less than 10 minutes enough to fix this simple problem? I don't know
 why Walter likes to use ".c" as suffix for those files, I don't remember his
 answers on this topic, I have never appreciated this naming decision.

Back in the day, when most of this was started and the African continent was still attached to South America, the following extensions were in wide use for C++ files: .cpp .c++ .cxx .C (that's capital C; obviously that never worked on Windows) .c (and corresponding .h suffixes). None of them achieved any dominance. I myself used .cpp/.hpp for a while, and simply grew tired of it. The compiler sources were originally in C, and when they were converted to C++ it was easier to just keep the same file names (and yes, .c was also in wide use for C++). All the C++ compilers accepted .c files, distinguishing by using a switch (dmc -cpp) or by name (gcc/g++). It just was never any problem. For me, I find worrying about it about as productive as arguing whether tabs should be set to 4 or 8.
Feb 04 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jgk65f$c0b$1 digitalmars.com...
 .C (that's capital C; obviously that never worked on Windows)

That *can* work. Windows filenames may be case-insensitive, but they're certainly not caseless. Not from Win95 onward anyway. (Obviously I'm not saying .C is a good way to go.)
 For me, I find worrying about it about as productive as arguing whether 
 tabs should be set to 4 or 8.

Ok, so then why not just make the leap? Nobody *wants* .c (including you, apperently), and many people would find it to work better with .cpp. If you're so indifferent about it, then why keep clinging to .c?
Feb 04 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"q66" <quaker66 gmail.com> wrote in message 
news:ejygjkiyboebpginjyuc dfeed.kimsufi.thecybershadow.net...
 On Saturday, 4 February 2012 at 21:14:28 UTC, Nick Sabalausky wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:jgk65f$c0b$1 digitalmars.com...
 .C (that's capital C; obviously that never worked on Windows)

That *can* work. Windows filenames may be case-insensitive, but they're certainly not caseless. Not from Win95 onward anyway. (Obviously I'm not saying .C is a good way to go.)
 For me, I find worrying about it about as productive as arguing whether 
 tabs should be set to 4 or 8.

Ok, so then why not just make the leap? Nobody *wants* .c (including you, apperently), and many people would find it to work better with .cpp. If you're so indifferent about it, then why keep clinging to .c?

There is at least one serious issue with moving - it would break *all* dmd pull requests. That does not mean I agree with the .c extension, however. :)

I thought Git was supposed to be able to intelligently handle moved/renamed files? So shouldn't fixing those pull requests amount to "pull, possibly fix merge conflicts, push" just like with any other upstream change?
Feb 04 2012
parent "Daniel Murphy" <yebblies nospamgmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jgkar8$jon$1 digitalmars.com...
 I thought Git was supposed to be able to intelligently handle 
 moved/renamed files? So shouldn't fixing those pull requests amount to 
 "pull, possibly fix merge conflicts, push" just like with any other 
 upstream change?

Git doesn't do everything it's supposed to be able to do, at least not smoothly. Considering how minor this is, it should be done some time when there are less pull requests open.
Feb 04 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Saturday, 4 February 2012 at 20:58:23 UTC, Walter Bright wrote:
 On 2/3/2012 4:11 PM, bearophile wrote:
 Aren't less than 10 minutes enough to fix this simple problem? 
 I don't know
 why Walter likes to use ".c" as suffix for those files, I 
 don't remember his
 answers on this topic, I have never appreciated this naming 
 decision.

Back in the day, when most of this was started and the African continent was still attached to South America, the following extensions were in wide use for C++ files: .cpp .c++ .cxx .C (that's capital C; obviously that never worked on Windows) .c (and corresponding .h suffixes). None of them achieved any dominance. I myself used .cpp/.hpp for a while, and simply grew tired of it. The compiler sources were originally in C, and when they were converted to C++ it was easier to just keep the same file names (and yes, .c was also in wide use for C++). All the C++ compilers accepted .c files, distinguishing by using a switch (dmc -cpp) or by name (gcc/g++). It just was never any problem. For me, I find worrying about it about as productive as arguing whether tabs should be set to 4 or 8.

Except it consistently confuses people and tools. .cpp or .cc is all I see nowadays, and DMD should modernise. Things may have been different in the (eighteen) eighties, but get with the times!
Feb 04 2012
prev sibling parent "q66" <quaker66 gmail.com> writes:
On Saturday, 4 February 2012 at 21:14:28 UTC, Nick Sabalausky 
wrote:
 "Walter Bright" <newshound2 digitalmars.com> wrote in message 
 news:jgk65f$c0b$1 digitalmars.com...
 .C (that's capital C; obviously that never worked on Windows)

That *can* work. Windows filenames may be case-insensitive, but they're certainly not caseless. Not from Win95 onward anyway. (Obviously I'm not saying .C is a good way to go.)
 For me, I find worrying about it about as productive as 
 arguing whether tabs should be set to 4 or 8.

Ok, so then why not just make the leap? Nobody *wants* .c (including you, apperently), and many people would find it to work better with .cpp. If you're so indifferent about it, then why keep clinging to .c?

There is at least one serious issue with moving - it would break *all* dmd pull requests. That does not mean I agree with the .c extension, however. :)
Feb 04 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Feb 03, 2012 at 05:12:08PM -0600, Zachary Lund wrote:
 Here are some things I'm unhappy with currently.
 
 1. Documentation
 
 I find certain things, of which I will start writing down and
 writing patches for, in the documentation that are unsatisfactory.
 Two in particular is the current situation with memory management
 and CTFE. "delete" is planned for deprecation and alternative
 methods for custom de/allocators are already in place, yet most
 people don't even know about them or how to use them. I see talk on
 IRC about things that completely confuse me as to the state of
 things and I can generally find no obvious or reliable source of
 information. It's completely frustrating.
 
 Documentation is much more important than feature implementation.

I agree with this. Based on current documentation, I didn't even know the GC can be replaced at compile-time until someone mentioned it. And up to now I still don't know how exactly to do this, since I couldn't find any docs for it. Some of the docs on the website are also deficient, for example std.uni (which I already filed a bug for), due to missing doc comments in the code. I'd like to help. My D coding skills are still not up to snuff for fixing the hard stuff, since I only just started learning D. But doc comments I can do. However, there's no documentation that I can find that describes the procedure for sending contributions. Such as where to upload patches, what format they should be in, how to get diffs in the right format, etc.. All this should be documented so that willing contributors can jump in immediately, instead of being put off by having to jump through unnecessary hoops (like hunting for possibly non-existent documentation on how to contribute). Another big missing with the documentation is a timestamp. The problem is that some of the docs are out-of-date, but it looks identical to the up-to-date pages, so it's very confusing for someone who doesn't already know the answer. If you try something the docs say but it doesn't work, then instead of pulling your hair out, you can look at the timestamp that says "last updated 2005" and know that perhaps the info is out of date and it isn't some bug in your code. Timestamps will also tell potential contributors which pages to work on, if they notice the info is wrong and/outdated. Of course, this doesn't replace keeping the docs up-to-date, but it's better than nothing. [...]
 3. FAQ
 
 I think there was a discussion somewhere (of which I can't find now
 through Thunderbird search) but the FAQ is important. When people
 wonder about a feature of D, the first thing they should do is check
 the FAQ to find the answer.
 
 I think that each time a solution is provided that might or might
 not be obvious, the reasoning behind that solution should be posted
 on the FAQ. Nothing should be left with abstract reasoning (outside
 of perhaps philisophy-based reasoning).
 
 The FAQ is incomplete.

Agreed. I'm thinking the FAQ should include common newbie mistakes / surprises, so that newcomers won't get overly frustrated with bugs that are actually very simple but they have no idea how to fix it.
 4. Microsoft
 
 Windows. I cannot stand Windows. If Microsoft suddenly went bankrupt,
 Windows was never updated, and people had to move to MacOS or Linux, I
 would be the happiest man alive.

Ahhhahahaha... I wish this were true too. ;-)
 Unfortunately, this will seemingly never be the case and it stands
 that Microsoft has the highest share of all the OS users. Thus, it
 should be given higher priority to attract more users. When people
 complain about D not having large Windows support (or COFF support in
 particular and the shitty optlink), it kills me a little on the
 inside.

I agree, though I can't do very much to help on this front 'cos I haven't done any serious work on windows for the last 10 years. (I almost fell out of my chair (for joy) at my interview for my current job when I found out that they used the gcc toolchain for development -- there was no indication of this on the job posting.)
 This is probably a lost cause but I've recently seen various
 complaints about the name "D". It's not distinct nor is D old enough
 to be known like C or C++ is. I remember a comment about the name
 "Mars" which I think would have been much more distinct and clearcut,
 and would have caused less issues.

I tend to agree too. The name "D" never fails to raise an eyebrow with my friends when I mention that I'm learning it -- they regard it as the next joke in the sequence C, C+, C++. (I know there is no such thing as C+, but that's what your average layperson thinks.) It's also very hard to search for online, since there are too many irrelevant matches. But yeah, it's a lost cause. Especially now that Andrei's book bears that name in print. It will be almost impossible to reverse the effects of that. [...]
 The .c extensions on C++ files... need I say more? That itself is a
 joke and seems to have been ignored when complaints about it came up.
 I've just recently been told that DMD was mostly implemented in C
 which is false. This situation is needlessly frustrating.

Now *that* is evil. [...]
 I like the D language. Not so much the projects that surround D.

I like D too. I'd like to help in whatever way I can to make it a successful language. I hope I will never have to go back to that creeping horror known as C++. T -- Guns don't kill people. Bullets do.
Feb 03 2012
next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.347.1328315188.25230.digitalmars-d puremagic.com...
 I'd like to help. My D coding skills are still not up to snuff for
 fixing the hard stuff, since I only just started learning D. But doc
 comments I can do. However, there's no documentation that I can find
 that describes the procedure for sending contributions. Such as where to
 upload patches, what format they should be in, how to get diffs in the
 right format, etc.. All this should be documented so that willing
 contributors can jump in immediately, instead of being put off by having
 to jump through unnecessary hoops (like hunting for possibly
 non-existent documentation on how to contribute).

Everything is on github these days. Eg for the website , https://github.com/D-Programming-Language/d-programming-language.org
 However, there's no documentation

We should have this, but like everything else, it requires somebody take the time to do it.
Feb 03 2012
parent Zachary Lund <admin computerquip.com> writes:
On 02/04/2012 03:02 AM, Jesse Phillips wrote:
 On Saturday, 4 February 2012 at 07:00:53 UTC, James Miller wrote:
 no point sticking
 to D1 now that support has been officially dropped.

Will be dropped. It hasn't yet.
 The community needs some organisation. Currently DSource is not
 actually that useful, Trac is all about SVN, but D and most other
 libraries use git/GitHub which makes for a clunky experience.

GitHub is very new for the development history of D. Is it one year now?
 If
 D-Programming-Language.org had a projects section, it would make it
 much easier to manage and make more sense, there is no direct link
 from the official website to any centralized project repository, which
 makes discovery a nightmare.

There isn't a centralized projects repository. Dsource was, back in the day, but that obviously has had a falling out. There is working being done on a D "CPAN" called Orbit I believe. We'll see if the community does take it up. Progress is being made on most everything listed and has already been greatly improved in the last couple years.

CPAN for D would be amazing I think.
Feb 04 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2012 4:28 PM, H. S. Teoh wrote:
 I'd like to help. My D coding skills are still not up to snuff for
 fixing the hard stuff, since I only just started learning D. But doc
 comments I can do. However, there's no documentation that I can find
 that describes the procedure for sending contributions. Such as where to
 upload patches, what format they should be in, how to get diffs in the
 right format, etc.. All this should be documented so that willing
 contributors can jump in immediately, instead of being put off by having
 to jump through unnecessary hoops (like hunting for possibly
 non-existent documentation on how to contribute).

It's all up on https://github.com/D-Programming-Language which is where anyone can make contributions via forking and doing "pull" requests. The instructions/tutorials on how to do that are on github.
 This is probably a lost cause but I've recently seen various
 complaints about the name "D".


You're right that searching for "D" is hopeless. But searching for "D programming" works great.
Feb 04 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2012 4:28 PM, H. S. Teoh wrote:
 I agree with this. Based on current documentation, I didn't even know
 the GC can be replaced at compile-time until someone mentioned it. And
 up to now I still don't know how exactly to do this, since I couldn't
 find any docs for it.

The documentation for that is in the source files for the GC, the GC is even in its own subdirectory, src/gc. It stands to reason that to replace the GC, that's where to look. Doing a replacement GC is pretty advanced work. If one is ready for that, it isn't unreasonable to expect one to peruse those files. It's a bit beyond the scope of D to provide a tutorial on how to write a replacement GC, though you're welcome to do it and contribute it.
Feb 05 2012
parent Zachary Lund <admin computerquip.com> writes:
On 02/05/2012 09:18 AM, H. S. Teoh wrote:
 On Sun, Feb 05, 2012 at 12:10:33AM -0800, Walter Bright wrote:
 On 2/3/2012 4:28 PM, H. S. Teoh wrote:
 I agree with this. Based on current documentation, I didn't even know
 the GC can be replaced at compile-time until someone mentioned it.
 And up to now I still don't know how exactly to do this, since I
 couldn't find any docs for it.

The documentation for that is in the source files for the GC, the GC is even in its own subdirectory, src/gc. It stands to reason that to replace the GC, that's where to look. Doing a replacement GC is pretty advanced work. If one is ready for that, it isn't unreasonable to expect one to peruse those files. It's a bit beyond the scope of D to provide a tutorial on how to write a replacement GC, though you're welcome to do it and contribute it.

I was just referring to how to switch between different GCs at compile-time. I'm sure somebody documented this somewhere, the point was that there isn't a central place where someone unfamiliar with the system can go to find the answers. T

There's a gc stub inside of the druntime get repo. You can literally include that and link it into your project and it will replace the GC as long as you statically link the rest of the druntime (I'm not sure what it does if you dynamically link it).
Feb 05 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
 Documentation is much more important than feature implementation.

https://github.com/D-Programming-Language/d-programming-language.org
Feb 03 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 02/04/12 01:28, H. S. Teoh wrote:
 I agree with this. Based on current documentation, I didn't even know
 the GC can be replaced at compile-time until someone mentioned it. And
 up to now I still don't know how exactly to do this, since I couldn't
 find any docs for it.

There's nothing special about the GC, you just need to link to your implementation. Or take the one from druntime, modify it and make sure the object containing the necessary symbols is found before the std library, eg by compiling MyGCImpl.d together with the other D source files. That's all. artur
Feb 03 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Zachary Lund" <admin computerquip.com> wrote in message 
news:jghpk4$26uk$1 digitalmars.com...
 2. Milestones and Organization

This is non-corporate-backed OSS. People are free to work on what they choose. We're not Bill Lumberg Waterfall Nazis here.
 I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows was 
 never updated, and people had to move to MacOS or Linux, I would be the 
 happiest man alive.

Bleh. Apple makes MS look like the EFF. (And I'd sooner switch to a graphing calculator as my primary PC than go back to OSX.) MS may be no better than any other corporation, but Jobs's demise was the #1 best thing to happen to technology since Win2K/XP. ('Course they couldn't get me to use that Vista/Win7 trash if they paid me.)
 It also drives me insane that dmd for D2 is not named dmd2. There's no 
 reason to not have it be dmd2 and you just stupidly caused incompatibility 
 with the D1 executable.

https://bitbucket.org/doob/dvm $dvm use 1.069 $dvm use 2.057 etc... Trivial problem trivially solved.
 The .c extensions on C++ files... need I say more? That itself is a joke 
 and seems to have been ignored when complaints about it came up.

Everyone already knows and agrees.
Feb 03 2012
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jgij59$hc2$1 digitalmars.com...
 "Zachary Lund" <admin computerquip.com> wrote in message 
 news:jghpk4$26uk$1 digitalmars.com...
 2. Milestones and Organization

This is non-corporate-backed OSS. People are free to work on what they choose. We're not Bill Lumberg Waterfall Nazis here.
 I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows was 
 never updated, and people had to move to MacOS or Linux, I would be the 
 happiest man alive.

Bleh. Apple makes MS look like the EFF. (And I'd sooner switch to a graphing calculator as my primary PC than go back to OSX.) MS may be no better than any other corporation, but Jobs's demise was the #1 best thing to happen to technology since Win2K/XP. ('Course they couldn't get me to use that Vista/Win7 trash if they paid me.)
 It also drives me insane that dmd for D2 is not named dmd2. There's no 
 reason to not have it be dmd2 and you just stupidly caused 
 incompatibility with the D1 executable.

https://bitbucket.org/doob/dvm $dvm use 1.069 $dvm use 2.057 etc... Trivial problem trivially solved.
 The .c extensions on C++ files... need I say more? That itself is a joke 
 and seems to have been ignored when complaints about it came up.

Everyone already knows and agrees.

I don't mean to be an ass about it, I know how infuriating it is to come into a group and get immediately lynched. It's just that every couple months we inevitably get yet another first-time (or nearly-first-time) poster who gives us a big essay on everything we're doing wrong and how they're going to swoop in and save us from ourselves with their basic observations, all of which inevitably fall into: A. Things everyone already knows, agrees on, and is being worked on. B. Things they can easily contribute to themselves. C. Things that are already taken care of. D. Things that have already been brought up, discussed, and are never going to happen (and have *then* been discussed a couple more times). E. Things that are just plain false. It's a pattern that just gets very old very quickly.
Feb 03 2012
parent reply Zachary Lund <admin computerquip.com> writes:
On 02/04/2012 01:02 AM, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jgij59$hc2$1 digitalmars.com...
 "Zachary Lund"<admin computerquip.com>  wrote in message
 news:jghpk4$26uk$1 digitalmars.com...
 2. Milestones and Organization

This is non-corporate-backed OSS. People are free to work on what they choose. We're not Bill Lumberg Waterfall Nazis here.
 I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows was
 never updated, and people had to move to MacOS or Linux, I would be the
 happiest man alive.

Bleh. Apple makes MS look like the EFF. (And I'd sooner switch to a graphing calculator as my primary PC than go back to OSX.) MS may be no better than any other corporation, but Jobs's demise was the #1 best thing to happen to technology since Win2K/XP. ('Course they couldn't get me to use that Vista/Win7 trash if they paid me.)
 It also drives me insane that dmd for D2 is not named dmd2. There's no
 reason to not have it be dmd2 and you just stupidly caused
 incompatibility with the D1 executable.

https://bitbucket.org/doob/dvm $dvm use 1.069 $dvm use 2.057 etc... Trivial problem trivially solved.
 The .c extensions on C++ files... need I say more? That itself is a joke
 and seems to have been ignored when complaints about it came up.

Everyone already knows and agrees.

I don't mean to be an ass about it, I know how infuriating it is to come into a group and get immediately lynched. It's just that every couple months we inevitably get yet another first-time (or nearly-first-time) poster who gives us a big essay on everything we're doing wrong and how they're going to swoop in and save us from ourselves with their basic observations, all of which inevitably fall into: A. Things everyone already knows, agrees on, and is being worked on. B. Things they can easily contribute to themselves. C. Things that are already taken care of. D. Things that have already been brought up, discussed, and are never going to happen (and have *then* been discussed a couple more times). E. Things that are just plain false. It's a pattern that just gets very old very quickly.

You seem to have ignored parts of my post. I said I would start contributing. I even mentioned DVM and why DVM shouldn't exist. And while you are not "Bill Lumberg Waterfall Nazis", I'm not sure why stating your short-term goals is such a problem. It creates the basics of organization and of itself would probably make several people happy at the cost of almost nothing. Organization? What are we, "Bill Lumberg Waterfall Nazis"? Also, I don't really care if things I brought up have been repeated, there is known knowledge as to why you chose the "solution" to the problem I stated. I even discussed this when I talked about the FAQ. If a question constantly comes up, it brings up an obvious unproductive problem and thus should be taken care of ahead of time in the FAQ.
Feb 04 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Zachary Lund" <admin computerquip.com> wrote in message 
news:jgipp1$u8r$1 digitalmars.com...
 On 02/04/2012 01:02 AM, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jgij59$hc2$1 digitalmars.com...
 "Zachary Lund"<admin computerquip.com>  wrote in message
 news:jghpk4$26uk$1 digitalmars.com...
 2. Milestones and Organization

This is non-corporate-backed OSS. People are free to work on what they choose. We're not Bill Lumberg Waterfall Nazis here.
 I cannot stand Windows. If Microsoft suddenly went bankrupt, Windows 
 was
 never updated, and people had to move to MacOS or Linux, I would be the
 happiest man alive.

Bleh. Apple makes MS look like the EFF. (And I'd sooner switch to a graphing calculator as my primary PC than go back to OSX.) MS may be no better than any other corporation, but Jobs's demise was the #1 best thing to happen to technology since Win2K/XP. ('Course they couldn't get me to use that Vista/Win7 trash if they paid me.)
 It also drives me insane that dmd for D2 is not named dmd2. There's no
 reason to not have it be dmd2 and you just stupidly caused
 incompatibility with the D1 executable.

https://bitbucket.org/doob/dvm $dvm use 1.069 $dvm use 2.057 etc... Trivial problem trivially solved.
 The .c extensions on C++ files... need I say more? That itself is a 
 joke
 and seems to have been ignored when complaints about it came up.

Everyone already knows and agrees.

I don't mean to be an ass about it, I know how infuriating it is to come into a group and get immediately lynched. It's just that every couple months we inevitably get yet another first-time (or nearly-first-time) poster who gives us a big essay on everything we're doing wrong and how they're going to swoop in and save us from ourselves with their basic observations, all of which inevitably fall into: A. Things everyone already knows, agrees on, and is being worked on. B. Things they can easily contribute to themselves. C. Things that are already taken care of. D. Things that have already been brought up, discussed, and are never going to happen (and have *then* been discussed a couple more times). E. Things that are just plain false. It's a pattern that just gets very old very quickly.

You seem to have ignored parts of my post. I said I would start contributing. I even mentioned DVM and why DVM shouldn't exist. And while you are not "Bill Lumberg Waterfall Nazis", I'm not sure why stating your short-term goals is such a problem. It creates the basics of organization and of itself would probably make several people happy at the cost of almost nothing. Organization? What are we, "Bill Lumberg Waterfall Nazis"? Also, I don't really care if things I brought up have been repeated, there is known knowledge as to why you chose the "solution" to the problem I stated. I even discussed this when I talked about the FAQ. If a question constantly comes up, it brings up an obvious unproductive problem and thus should be taken care of ahead of time in the FAQ.

I just don't see why you seem to care so incredibly much about such trivial matters as "dmd" vs "dmd2" and releases not limiting themselves to some sort of pre-determined "theme".
Feb 04 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/4/2012 8:52 AM, Zachary Lund wrote:
 1. I don't care about such trivial things since it doesn't make sense to change
 them currently. However, it was an obvious problem when the name was first set
 and other than D1 being deprecated, it's still a problem now (sort of). Arch
 Linux chose to remove the D1 package and add the D2 package and not keep both
 simply because of the retarded name incompatibilities.

The problem is more global than that. Many people have multiple versions of dmd on their system - from one release to the next. It's not going to work to keep renaming dmd for every release. dmd keeps a dmd.conf in the directory where it resides, which tells it where to find the right version of the library, etc. That means that all your makefile needs to do is pick the right dmd, either by setting the path, an environment variable, or hardcoding it in the makefile.
Feb 04 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-02-04 22:11, Walter Bright wrote:
 On 2/4/2012 8:52 AM, Zachary Lund wrote:
 1. I don't care about such trivial things since it doesn't make sense
 to change
 them currently. However, it was an obvious problem when the name was
 first set
 and other than D1 being deprecated, it's still a problem now (sort
 of). Arch
 Linux chose to remove the D1 package and add the D2 package and not
 keep both
 simply because of the retarded name incompatibilities.

The problem is more global than that. Many people have multiple versions of dmd on their system - from one release to the next. It's not going to work to keep renaming dmd for every release.

This is just the case DVM is made for. It will fix most of these problems. https://bitbucket.org/doob/dvm
 dmd keeps a dmd.conf in the directory where it resides, which tells it
 where to find the right version of the library, etc. That means that all
 your makefile needs to do is pick the right dmd, either by setting the
 path, an environment variable, or hardcoding it in the makefile.

-- /Jacob Carlborg
Feb 04 2012
prev sibling next sibling parent "Zachary Lund" <admin computerquip.com> writes:
On Saturday, 4 February 2012 at 16:36:23 UTC, Nick Sabalausky 
wrote:
 "Zachary Lund" <admin computerquip.com> wrote in message 
 news:jgipp1$u8r$1 digitalmars.com...
 On 02/04/2012 01:02 AM, Nick Sabalausky wrote:
 "Nick Sabalausky"<a a.a>  wrote in message
 news:jgij59$hc2$1 digitalmars.com...
 "Zachary Lund"<admin computerquip.com>  wrote in message
 news:jghpk4$26uk$1 digitalmars.com...
 2. Milestones and Organization

This is non-corporate-backed OSS. People are free to work on what they choose. We're not Bill Lumberg Waterfall Nazis here.
 I cannot stand Windows. If Microsoft suddenly went 
 bankrupt, Windows was
 never updated, and people had to move to MacOS or Linux, I 
 would be the
 happiest man alive.

Bleh. Apple makes MS look like the EFF. (And I'd sooner switch to a graphing calculator as my primary PC than go back to OSX.) MS may be no better than any other corporation, but Jobs's demise was the #1 best thing to happen to technology since Win2K/XP. ('Course they couldn't get me to use that Vista/Win7 trash if they paid me.)
 It also drives me insane that dmd for D2 is not named dmd2. 
 There's no
 reason to not have it be dmd2 and you just stupidly caused
 incompatibility with the D1 executable.

https://bitbucket.org/doob/dvm $dvm use 1.069 $dvm use 2.057 etc... Trivial problem trivially solved.
 The .c extensions on C++ files... need I say more? That 
 itself is a joke
 and seems to have been ignored when complaints about it 
 came up.

Everyone already knows and agrees.

I don't mean to be an ass about it, I know how infuriating it is to come into a group and get immediately lynched. It's just that every couple months we inevitably get yet another first-time (or nearly-first-time) poster who gives us a big essay on everything we're doing wrong and how they're going to swoop in and save us from ourselves with their basic observations, all of which inevitably fall into: A. Things everyone already knows, agrees on, and is being worked on. B. Things they can easily contribute to themselves. C. Things that are already taken care of. D. Things that have already been brought up, discussed, and are never going to happen (and have *then* been discussed a couple more times). E. Things that are just plain false. It's a pattern that just gets very old very quickly.

You seem to have ignored parts of my post. I said I would start contributing. I even mentioned DVM and why DVM shouldn't exist. And while you are not "Bill Lumberg Waterfall Nazis", I'm not sure why stating your short-term goals is such a problem. It creates the basics of organization and of itself would probably make several people happy at the cost of almost nothing. Organization? What are we, "Bill Lumberg Waterfall Nazis"? Also, I don't really care if things I brought up have been repeated, there is known knowledge as to why you chose the "solution" to the problem I stated. I even discussed this when I talked about the FAQ. If a question constantly comes up, it brings up an obvious unproductive problem and thus should be taken care of ahead of time in the FAQ.

I just don't see why you seem to care so incredibly much about such trivial matters as "dmd" vs "dmd2" and releases not limiting themselves to some sort of pre-determined "theme".

1. I don't care about such trivial things since it doesn't make sense to change them currently. However, it was an obvious problem when the name was first set and other than D1 being deprecated, it's still a problem now (sort of). Arch Linux chose to remove the D1 package and add the D2 package and not keep both simply because of the retarded name incompatibilities. 2. How is that in any way limiting? It's not like people will work on bugs and someone else will come along and say, "Wait, that's not in our milestones! Shame on you!" It does help people focus on prioritized bugs. However, that doesn't force them to work on a bug just because its in the milestone. If you want a community driven project, the community has to have some goal to work towards in order to be efficient or it's just a blob of random fixes and features that are randomly implemented, regardless of priority. Bugzilla has a terrible system for emphasizing priority because a level of priority can mean a good amount of things. Github, I think, has a better system which uses labels and is much more specific while colors can give emphasis on how important that label is.
Feb 04 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Saturday, 4 February 2012 at 16:52:04 UTC, Zachary Lund wrote:

 Arch Linux chose to remove the D1 package and add the D2 
 package and not keep both simply because of the retarded name 
 incompatibilities.

That just seems silly. The package builder can make the binary name whatever they choose. And from the Linux side it makes even less sense because it is extremely common. gcc, is it GCC 4.7, 3.2, 8.5, 967, clang? No, it is a symbolic link to whatever you want. This is what hive have DDebber[1] doing, though because of your previous post I see that I got the version naming of libphobos2 wrong. I was going to develop it further to package Tango and allow v1 and 2 to install together, but such effort appears less and less important.
Feb 04 2012
prev sibling parent "Zachary Lund" <admin computerquip.com> writes:
On Saturday, 4 February 2012 at 17:14:41 UTC, Jesse Phillips 
wrote:
 On Saturday, 4 February 2012 at 16:52:04 UTC, Zachary Lund 
 wrote:

 Arch Linux chose to remove the D1 package and add the D2 
 package and not keep both simply because of the retarded name 
 incompatibilities.

That just seems silly. The package builder can make the binary name whatever they choose. And from the Linux side it makes even less sense because it is extremely common. gcc, is it GCC 4.7, 3.2, 8.5, 967, clang? No, it is a symbolic link to whatever you want. This is what hive have DDebber[1] doing, though because of your previous post I see that I got the version naming of libphobos2 wrong. I was going to develop it further to package Tango and allow v1 and 2 to install together, but such effort appears less and less important.

The difference is that gcc is supposed to be interchangeable. The same can't be said for dmd1 and dmd2. While the results are sometimes different with different binaries of gcc, the idea is that it shouldn't be. Basically, what happened was D said, "dmd isn't similar to dmd, but keeping the name dmd makes sense".
Feb 04 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
 However, there's no documentation

We should have this, but like everything else, it requires somebody take the time to do it.

So true, I spent literally 5 hours writing documentation for a project I was releasing. It wasn't even that big. And I didn't write any reference documentation. I maybe could have done it faster, cut it down to 3-3.5 hrs, but it takes so long to do properly. Not only do you need reference materials, you need example usage, explanations of what to use when (and ideally why). Each example needs to be tested, made sure that it is concise without being opaque and documented itself. You paradoxically need somebody who knows exactly what the code does, but knows what is unobvious and what is "advanced use" only.
 I like the D language. Not so much the projects that surround D.

Same, having essentially 2 incompatible languages and 2 incompatible "standard" libraries has been devastating. My personal opinion is that Phobos, being maintained by the creators of the language, should be the defacto library and everybody should be encouraged to use it for most purposes. Tango shouldn't be a replacement for Phobos but work alongside it, (a goal that the Tango-D2 team seem to be aiming for) because having to change libraries to compile different programs is a nightmare. And all new development should be in D2, no point sticking to D1 now that support has been officially dropped. So many projects simply don't work. Some have had underlying libraries do breaking changes from under them, others rely on Tango D1 which makes trying to port them to D2 effectively impossible (though it should be easier now that most of Tango-D2 is done), and some haven't had any development for years and just aren't useful. The community needs some organisation. Currently DSource is not actually that useful, Trac is all about SVN, but D and most other libraries use git/GitHub which makes for a clunky experience. If D-Programming-Language.org had a projects section, it would make it much easier to manage and make more sense, there is no direct link from the official website to any centralized project repository, which makes discovery a nightmare. Many people do not want to join a mailing list or ask in IRC just to find if a library or program exists. -- James Miller
Feb 03 2012
prev sibling next sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
On Saturday, 4 February 2012 at 07:00:53 UTC, James Miller wrote:
 no point sticking
 to D1 now that support has been officially dropped.

Will be dropped. It hasn't yet.
 The community needs some organisation. Currently DSource is not
 actually that useful, Trac is all about SVN, but D and most 
 other
 libraries use git/GitHub which makes for a clunky experience.

GitHub is very new for the development history of D. Is it one year now?
 If
 D-Programming-Language.org had a projects section, it would 
 make it
 much easier to manage and make more sense, there is no direct 
 link
 from the official website to any centralized project 
 repository, which
 makes discovery a nightmare.

There isn't a centralized projects repository. Dsource was, back in the day, but that obviously has had a falling out. There is working being done on a D "CPAN" called Orbit I believe. We'll see if the community does take it up. Progress is being made on most everything listed and has already been greatly improved in the last couple years.
Feb 04 2012
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/3/2012 3:12 PM, Zachary Lund wrote:
 Here are some things I'm unhappy with currently.

Thanks for taking the time to post this. I agree with most of it, and we are working hard to try to improve things. For more specifics, such as a list of things the FAQ should cover, can you please post a bug report for it?
Feb 04 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 04, 2012 at 03:08:42AM -0600, Zachary Lund wrote:
 On 02/04/2012 03:02 AM, Jesse Phillips wrote:
On Saturday, 4 February 2012 at 07:00:53 UTC, James Miller wrote:


There isn't a centralized projects repository. Dsource was, back in the
day, but that obviously has had a falling out. There is working being
done on a D "CPAN" called Orbit I believe. We'll see if the community
does take it up.

Progress is being made on most everything listed and has already been
greatly improved in the last couple years.

CPAN for D would be amazing I think.

It would be CDAN? :-) T -- WINDOWS = Will Install Needless Data On Whole System -- CompuMan
Feb 04 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Feb 04, 2012 at 01:02:39PM -0800, Walter Bright wrote:
[...]
 You're right that searching for "D" is hopeless. But searching for "D
 programming" works great.

Actually, to Google's credit, it seems to have adapted to my repeatedly clicking only on D programming related pages in the search results page, and now all I have to do is to add "d" to my search queries and it will
50% of the time actually return relevant results.

Doesn't help newcomers, though. T -- Never trust an operating system you don't have source for! -- Martin Schulze
Feb 04 2012
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Sat, 4 Feb 2012 17:17:28 -0500
"Nick Sabalausky" <a a.a> wrote:

 I thought Git was supposed to be able to intelligently handle
 moved/renamed files? So shouldn't fixing those pull requests amount
 to "pull, possibly fix merge conflicts, push" just like with any
 other upstream change?

I thought the same and believe that Hg can do it properly. Sincerely, Gour --=20 One who is not connected with the Supreme can have neither=20 transcendental intelligence nor a steady mind, without which=20 there is no possibility of peace. And how can there be any=20 happiness without peace? http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Feb 04 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 05, 2012 at 12:10:33AM -0800, Walter Bright wrote:
 On 2/3/2012 4:28 PM, H. S. Teoh wrote:
I agree with this. Based on current documentation, I didn't even know
the GC can be replaced at compile-time until someone mentioned it.
And up to now I still don't know how exactly to do this, since I
couldn't find any docs for it.

The documentation for that is in the source files for the GC, the GC is even in its own subdirectory, src/gc. It stands to reason that to replace the GC, that's where to look. Doing a replacement GC is pretty advanced work. If one is ready for that, it isn't unreasonable to expect one to peruse those files. It's a bit beyond the scope of D to provide a tutorial on how to write a replacement GC, though you're welcome to do it and contribute it.

I was just referring to how to switch between different GCs at compile-time. I'm sure somebody documented this somewhere, the point was that there isn't a central place where someone unfamiliar with the system can go to find the answers. T -- If you look at a thing nine hundred and ninety-nine times, you are perfectly safe; if you look at it the thousandth time, you are in frightful danger of seeing it for the first time. -- G. K. Chesterton
Feb 05 2012
prev sibling parent reply Don <nospam nospam.com> writes:
On 04.02.2012 00:12, Zachary Lund wrote:
 Here are some things I'm unhappy with currently.

 1. Documentation

 I find certain things, of which I will start writing down and writing
 patches for, in the documentation that are unsatisfactory. Two in
 particular is the current situation with memory management and CTFE.

Could you please explain what you mean about CTFE? I'm not aware of any problems with the documentation. (I gave the docs a complete rewrite a couple of releases ago).
Feb 05 2012
next sibling parent reply Zachary Lund <admin computerquip.com> writes:
On 02/05/2012 09:27 AM, Don wrote:
 On 04.02.2012 00:12, Zachary Lund wrote:
 Here are some things I'm unhappy with currently.

 1. Documentation

 I find certain things, of which I will start writing down and writing
 patches for, in the documentation that are unsatisfactory. Two in
 particular is the current situation with memory management and CTFE.

Could you please explain what you mean about CTFE? I'm not aware of any problems with the documentation. (I gave the docs a complete rewrite a couple of releases ago).

I didn't see this documentation (under the Functions section none the less). I revoke my statement.
Feb 05 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/5/2012 9:13 AM, Zachary Lund wrote:
 On 02/05/2012 09:27 AM, Don wrote:
 Could you please explain what you mean about CTFE? I'm not aware of any
 problems with the documentation. (I gave the docs a complete rewrite a
 couple of releases ago).

I didn't see this documentation (under the Functions section none the less). I revoke my statement.

Perhaps CTFE should have its own page.
Feb 05 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Feb 05, 2012 at 10:44:37AM -0800, Walter Bright wrote:
[...]
 Perhaps CTFE should have its own page.

That's an excellent idea. A centralized place where we can put all CTFE-related stuff, current limitations, CTFE-specific quirks, etc.. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Feb 05 2012