www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Start of dmd 2.064 beta program

reply Walter Bright <newshound2 digitalmars.com> writes:
http://ftp.digitalmars.com/dmd2beta.zip

Current list of regressions:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

This isn't a release candidate, in particular the documentation needs work, but 
we need to shake the tree for any undetected regressions.

Further beta announcements go in the dmd-beta mailing list.

Note that this release contains:

29 enhancements
307 dmd bugs fixed
14 druntime bugs fixed
73 phobos bugs fixed
Oct 12 2013
next sibling parent reply "Tourist" <gravatar gravatar.com> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

 This isn't a release candidate, in particular the documentation 
 needs work, but we need to shake the tree for any undetected 
 regressions.

 Further beta announcements go in the dmd-beta mailing list.

 Note that this release contains:

 29 enhancements
 307 dmd bugs fixed
 14 druntime bugs fixed
 73 phobos bugs fixed
Great! I'm wondering whether there will be the nifty changelog like it was for 2.063? Andrej? :D
Oct 12 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/12/2013 3:20 PM, Tourist wrote:
 I'm wondering whether there will be the nifty changelog like it was for 2.063?
It only awaits someone to write it! I started on it here: https://github.com/D-Programming-Language/dlang.org/pull/391 Here are the relevant links: http://d.puremagic.com/issues/buglist.cgi?chfieldto=2013-10-12&query_format=advanced&chfield=resolution&chfieldfrom=2013-05-29&chfieldvalue=FIXED&bug_severity=enhancement&bug_status=RESOLVED&version=D2&version=D1%20%26%20D2&resolution=FIXED&product=D http://d.puremagic.com/issues/buglist.cgi?chfieldto=2013-10-12&query_format=advanced&chfield=resolution&chfieldfrom=2013-05-29&chfieldvalue=FIXED&bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=RESOLVED&version=D2&version=D1%20%26%20D2&component=DMD&resolution=FIXED&product=D http://d.puremagic.com/issues/buglist.cgi?chfieldto=2013-10-12&query_format=advanced&chfield=resolution&chfieldfrom=2013-05-29&chfieldvalue=FIXED&bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=RESOLVED&version=D2&version=D1%20%26%20D2&component=druntime&resolution=FIXED&product=D http://d.puremagic.com/issues/buglist.cgi?chfieldto=2013-10-12&query_format=advanced&chfield=resolution&chfieldfrom=2013-05-29&chfieldvalue=FIXED&bug_severity=regression&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&bug_status=RESOLVED&version=D2&version=D1%20%26%20D2&component=Phobos&resolution=FIXED&product=D
Oct 12 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/13/13, Tourist <gravatar gravatar.com> wrote:
 I'm wondering whether there will be the nifty changelog like it
 was for 2.063?
 Andrej? :D
We'll see if someone else volunteers to do it. I'm not doing it out of protest.
Oct 15 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/15/13 7:15 PM, Andrej Mitrovic wrote:
 On 10/13/13, Tourist <gravatar gravatar.com> wrote:
 I'm wondering whether there will be the nifty changelog like it
 was for 2.063?
 Andrej? :D
We'll see if someone else volunteers to do it. I'm not doing it out of protest.
What are you protesting against? Andrei
Oct 15 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/16/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 What are you protesting against?
Walter.
Oct 16 2013
next sibling parent "Anthony Goins" <neontotem gmail.com> writes:
On Wednesday, 16 October 2013 at 13:34:04 UTC, Andrej Mitrovic 
wrote:
 On 10/16/13, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 What are you protesting against?
Walter.
The last change log was awesome. I vote to get rid of Walter. :)
Oct 16 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/16/2013 6:33 AM, Andrej Mitrovic wrote:
 On 10/16/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 What are you protesting against?
Walter.
I'll go have myself flogged, then.
Oct 16 2013
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:

 I'll go have myself flogged, then.
But please be gentle and use something soft, like a fake snow leopard tail: http://img.photobucket.com/albums/v310/musta.surma/Hpim4850.jpg Bye, bearophile
Oct 16 2013
parent Rory McGuire <rjmcguire gmail.com> writes:
On 17 Oct 2013 00:40, "bearophile" <bearophileHUGS lycos.com> wrote:
 Walter Bright:


 I'll go have myself flogged, then.
But please be gentle and use something soft, like a fake snow leopard
tail: Surely having to deal with c++ whenever Walter works on dmd is punishment enough :D.
Oct 16 2013
prev sibling next sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 10/16/13 6:33 AM, Andrej Mitrovic wrote:
 On 10/16/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 What are you protesting against?
Walter.
That's not a what, that's a who. Would you please elaborate on the what and why? I haven't seen any obstructionism coming from anyone in terms of repeating the previous style for this releases notes.
Oct 16 2013
parent reply "Jacob Carlborg" <doob me.com> writes:
On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote:

 That's not a what, that's a who.  Would you please elaborate on 
 the what and why?  I haven't seen any obstructionism coming 
 from anyone in terms of repeating the previous style for this 
 releases notes.
Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg
Oct 16 2013
next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 16 October 2013 at 20:28:42 UTC, Jacob Carlborg 
wrote:
 On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts 
 wrote:

 That's not a what, that's a who.  Would you please elaborate 
 on the what and why?  I haven't seen any obstructionism coming 
 from anyone in terms of repeating the previous style for this 
 releases notes.
Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg
He was proved wrong and IIRC correctly quite graciously admitted defeat.
Oct 16 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Wednesday, October 16, 2013 22:28:41 Jacob Carlborg wrote:
 On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote:
 That's not a what, that's a who. Would you please elaborate on
 the what and why? I haven't seen any obstructionism coming
 from anyone in terms of repeating the previous style for this
 releases notes.
Originally Walter thought it was enough to just list the bugzilla issues.
Yes, but after Andej did the great changelog for 2.063, Walter publicly admitted that he had been wrong about the changelog. Andrej showed Walter that it _is_ worth doing something more than just a list of bugzilla issues. So, I would assume that whatever Andrej is unhappy with Walter for is something else. - Jonathan M Davis
Oct 16 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/16/13 2:16 PM, Jonathan M Davis wrote:
 On Wednesday, October 16, 2013 22:28:41 Jacob Carlborg wrote:
 On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts wrote:
 That's not a what, that's a who. Would you please elaborate on
 the what and why? I haven't seen any obstructionism coming
 from anyone in terms of repeating the previous style for this
 releases notes.
Originally Walter thought it was enough to just list the bugzilla issues.
Yes, but after Andej did the great changelog for 2.063, Walter publicly admitted that he had been wrong about the changelog. Andrej showed Walter that it _is_ worth doing something more than just a list of bugzilla issues. So, I would assume that whatever Andrej is unhappy with Walter for is something else.
Oh that was it? I recall Walter and I discussing two unrelated issue (null pointers and VMs) where I sort of reversed my view and admitted I considered my previous opinions wrong. He mentioned the changelog, and said "boy was I wrong about that!" So Andrej consider yourself vindicated, in public and in private. Andrei
Oct 16 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-10-16 23:16, Jonathan M Davis wrote:

 Yes, but after Andej did the great changelog for 2.063, Walter publicly
 admitted that he had been wrong about the changelog. Andrej showed Walter that
 it _is_ worth doing something more than just a list of bugzilla issues. So, I
 would assume that whatever Andrej is unhappy with Walter for is something
 else.
Andrej wrote:
 I'm wondering whether there will be the nifty changelog like it
 was for 2.063?
 Andrej? :D
We'll see if someone else volunteers to do it. I'm not doing it out of protest. http://forum.dlang.org/thread/l3chnd$1mvs$1 digitalmars.com?page=4#post-mailman.2221.1381889714.1719.digitalmars-d-announce:40puremagic.com I interpreted that as he originally created the changelog out of protest to Walter's claim that it's not necessary. -- /Jacob Carlborg
Oct 17 2013
prev sibling parent "Tourist" <gravatar gravatar.com> writes:
On Wednesday, 16 October 2013 at 20:28:42 UTC, Jacob Carlborg 
wrote:
 On Wednesday, 16 October 2013 at 20:19:17 UTC, Brad Roberts 
 wrote:

 That's not a what, that's a who.  Would you please elaborate 
 on the what and why?  I haven't seen any obstructionism coming 
 from anyone in terms of repeating the previous style for this 
 releases notes.
Originally Walter thought it was enough to just list the bugzilla issues. -- /Jacob Carlborg
http://forum.dlang.org/thread/ko84eb$1kfo$1 digitalmars.com
Oct 16 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/16/13, Brad Roberts <braddr puremagic.com> wrote:
 That's not a what, that's a who.
- We do not have any vision or major plans ahead for the language. Currently we're stuck in a bug-driven development environment, where bugs are arbitrarily picked off of bugzilla and fixed. But there's no major plans ahead, e.g. "let's plan to fix these X major bugs for some upcoming release". We can't force people to work on X or Y, but if they're in a visual place and marked important and scheduled to be fixed, this will give an incentive for contributors to work on these problems. - We do not have any defined release timeline. When is it time to start prepping for a release? It's up to Walter's arbitrary decision for when this happens, he doesn't even talk to the community or contributors on whether it's a good time for a beta phase (maybe there's a huge or disruptive new pull request that's planning to be merged and a beta should be delayed). - We do not have a defined timeline for the beta testing period. How long before we decide that the beta has been tested for long enough before a release is made? Again, it's up to Walter's decision. Having a defined release cycle and a beta testing period will ultimately be beneficial for everyone. People who are busy can rearrange their schedule to make free time and ensure they have enough time to test a beta compiler on their projects, and contributors to D can prepare for a cycle of days or weeks where they can rapidly work on reducing regressions and polish everything up for the release (e.g. writing an elaborate changelog). - We do not have a proper release system. Nick Sabalausky has been working hard on one[1], but Walter seems to have completely ignored it. It would have been a terrific opportunity to try and make it work for this release. What better way to test it than to test it on a release? - The betas are still not visible. The homepage makes no notes on a new beta being available, the download page does not list the betas either, and AFAICT there's no RSS feed either. The social media groups are not notified either (neither Andrei's nor Walter's twitter feed make a mention of a new beta being out, the same applies to https://twitter.com/D_Programming or the #dlang hash tags). To top it all off, you cannot post to the dmd-beta newsgroups from the D Forums, you have to separately register to this mailing list. If we want user feedback on betas we absolutely must make the betas visible and give an opportunity for people to post feedback. - Walter is still not tagging the beta releases by the file name (it's always dmd2beta.zip). I've complained about this several times and IIRC someone else did as well at dconf (maybe I'm remembering wrong though). They should at least be named as "dmd2_064_beta1.zip", "dmd2_064_beta2.zip". And all of them should always be available for download (including visibility on the download page), so people who do not use Git or build manually from master can quicky check whether a regression was introduced in a specific beta version. - I still sigh when I hear about Walter and Andrei having private phone conversations, or any kind of decision is made behind-the-scenes rather than publicly where the community has a say in it. Walter's implementation of UDAs directly in master which lead to having a deprecated syntax even though nobody used this syntax is what comes to mind. - Both Walter and Andrei not following the rules and making novice mistakes w.r.t Git and Github. Walter still seems to struggle with basic usage of git, where people continually have to re-explain what's wrong and how to fix an issue. I'm sorry, but if someone bought the Git book years ago and is still struggling with *concepts* then no amount of hand-guiding is going to help. And Andrei doing things like merging a dozen pull requests at once, with complete disregard to the fact that merging to master means other pulls could easily break (and so master can be broken). You cannot make so many merges unless you're absolutely sure each pull request does not interfere with another. - Back to Walter, a few weeks ago he merged a pull request over night, without regard to the pull request not being fully tested by the test machines. The result? Master was broken **for the entire next day**. Nobody knew which commit broke master, so nothing was done until Walter came back to Github the next day and started reverting his pulls. In the meantime the entire day was wasted because nobody's pull request could get green. Luckily it was a sunday, so there weren't too many complaints. But I could have easily merged a few pulls that day (as it happens I like to do things on a sunday), and as a result we would have a smaller pull queue. -- There's just many things that are going plain wrong here, and a lot of promises are always made but ultimately never delivered (whether it's about breaking changes or an improved development process -- again think about scheduling bug fixes for the future, we could help people prepare for the breaking changes). Personally I find D to be a huge part of me right now (probably not the other way around, I'm a small part of this compared to the huge contributors), and I feel really bummed out when both Andrei and Walter take a casual stance when things are broken (whether it's the system itself or something specific like master being broken). I really think we have a great thing going here with the language, but everything else has to improve, and particularly the development and release process. So that's what I'm protesting about. [1] : https://github.com/D-Programming-Language/installer/pull/24 (release build script)
Oct 17 2013
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-10-17 22:35, Andrej Mitrovic wrote:

 - Walter is still not tagging the beta releases by the file name (it's
 always dmd2beta.zip). I've complained about this several times and
 IIRC someone else did as well at dconf (maybe I'm remembering wrong
 though). They should at least be named as "dmd2_064_beta1.zip",
 "dmd2_064_beta2.zip". And all of them should always be available for
 download (including visibility on the download page), so people who do
 not use Git or build manually from master can quicky check whether a
 regression was introduced in a specific beta version.
Please make it "dmd.2_064_beta1.zip" and "dmd.2_064_beta2.zip" instead. This will automatically make it compatible with DVM. The important thing here is "dmd.<whatever>".
 So that's what I'm protesting about.
Agree with everything you said. -- /Jacob Carlborg
Oct 17 2013
parent reply "eles" <eles eles.com> writes:
On Friday, 18 October 2013 at 06:36:43 UTC, Jacob Carlborg wrote:
 On 2013-10-17 22:35, Andrej Mitrovic wrote:

 - Walter is still not tagging the beta releases by the file 
 name (it's
 always dmd2beta.zip). I've complained about this several times 
 and
 IIRC someone else did as well at dconf (maybe I'm remembering 
 wrong
 though). They should at least be named as "dmd2_064_beta1.zip",
 "dmd2_064_beta2.zip". And all of them should always be 
 available for
 download (including visibility on the download page), so 
 people who do
 not use Git or build manually from master can quicky check 
 whether a
 regression was introduced in a specific beta version.
Please make it "dmd.2_064_beta1.zip" and "dmd.2_064_beta2.zip" instead. This will automatically make it compatible with DVM. The important thing here is "dmd.<whatever>".
IIRC, Walter wanted that file to always be named dmd.zip or dmd2.zip or whatever, in order to allow a permanent download link, while guaranteeing the file to be the latest version of the tool. In this case, I think the best compromise is simply to have the latest version download-able either as dmd2.zip and as dmd2.<version>.zip.
Oct 18 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/18/13, eles <eles eles.com> wrote:
 IIRC, Walter wanted that file to always be named dmd.zip or
 dmd2.zip or whatever, in order to allow a permanent download
 link, while guaranteeing the file to be the latest version of the
 tool.
This is the wrong approach. There should be a "latest_beta" file which holds the name of the latest beta zip. Then automatic download tools can read this file before attempting to download the beta. And for everyone else who manually downloads, they should be able to see what the latest version is on the website. This isn't a novelty approach, many open-source libraries host their sources in a tarball on an FTP server with a LATEST file. Speaking of which, insisting on using .zip files is another beef I have with Walter. The whole "everyone on Windows is stuck in the 90s" mentality is plain wrong, especially for programmers. 7zip (or Peazip or whatever) should be part of every modern programmer's toolbox. If you've tried to investigate some source code of an open-source library in the last 15 years you must have ran into the issue of having to open tarballs, or more specifically non-zip/non-rar archives. I just can't believe there would still be programmers that use Winzip or the lousy built-in Windows unzipper.
Oct 18 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 10/18/13 7:08 AM, Andrej Mitrovic wrote:
 On 10/18/13, eles <eles eles.com> wrote:
 IIRC, Walter wanted that file to always be named dmd.zip or
 dmd2.zip or whatever, in order to allow a permanent download
 link, while guaranteeing the file to be the latest version of the
 tool.
This is the wrong approach. There should be a "latest_beta" file which holds the name of the latest beta zip.
Correct, the latest beta is a link to the actual numbered file.
 Speaking of which, insisting on using .zip files is another beef I
 have with Walter. The whole "everyone on Windows is stuck in the 90s"
 mentality is plain wrong, especially for programmers. 7zip (or Peazip
 or whatever) should be part of every modern programmer's toolbox.
I don't think that makes a large difference. Probably the better thing to do is trimming the contents of the archive. I'll come back with a reply to the longer message. Andrei
Oct 18 2013
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, October 18, 2013 08:57:00 Andrei Alexandrescu wrote:
 Speaking of which, insisting on using .zip files is another beef I
 have with Walter. The whole "everyone on Windows is stuck in the 90s"
 mentality is plain wrong, especially for programmers. 7zip (or Peazip
 or whatever) should be part of every modern programmer's toolbox.
I don't think that makes a large difference. Probably the better thing to do is trimming the contents of the archive.
The #1 reason why zip has got to go is symlinks. The shared libraries for Linux in the zip are messed up, because you can't put symlinks in the zip file. We really need to have OS-specific archives with the Linux one being something like .tar.gz or .tar.bz2. - Jonathan M Davis
Oct 18 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/18/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 I don't think that makes a large difference. Probably the better thing
 to do is trimming the contents of the archive.
Right, but this is more general. He also dislikes non-zip archives in bugzilla attachments.
Oct 18 2013
prev sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
On 18 Oct 2013 19:45, "Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 On Friday, October 18, 2013 08:57:00 Andrei Alexandrescu wrote:
 Speaking of which, insisting on using .zip files is another beef I
 have with Walter. The whole "everyone on Windows is stuck in the 90s"
 mentality is plain wrong, especially for programmers. 7zip (or Peazip
 or whatever) should be part of every modern programmer's toolbox.
I don't think that makes a large difference. Probably the better thing to do is trimming the contents of the archive.
The #1 reason why zip has got to go is symlinks. The shared libraries for Linux in the zip are messed up, because you can't put symlinks in the zip
file.
 We really need to have OS-specific archives with the Linux one being
something
 like .tar.gz or .tar.bz2.

 - Jonathan M Davis
Quite simply zip is not the correct format. Zip is normally only used to distribute windows specific versions of software. Does it even support executable permissions?
Oct 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/18/2013 11:17 AM, Rory McGuire wrote:
 Does it even support executable permissions?
Yes, it does.
Oct 18 2013
parent reply Rory McGuire <rjmcguire gmail.com> writes:
On 18 Oct 2013 21:00, "Walter Bright" <newshound2 digitalmars.com> wrote:
 On 10/18/2013 11:17 AM, Rory McGuire wrote:
 Does it even support executable permissions?
Yes, it does.
Nice. It's there any particular reason you prefer zip? I guess it's irrelevant what the current format is if we start using Nick's builder.
Oct 18 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/18/2013 12:14 PM, Rory McGuire wrote:
 Nice. It's there any particular reason you prefer zip?
It's easy and works on all platforms. I also point out that, for all platforms supported, when we do a release we also build a custom download package for each platform in that platform's preferred format. If these are inadequate, then bug reports need to be filed and pull requests issued for the package building scripts. I expect that managing all this should be the responsibility of the Build Czar, which is an open position.
 I guess it's irrelevant what the current format is if we start using Nick's
 builder.
What I prefer is that all the packages are built automatically and daily by Brad's autotester, and that this process is controlled by scripts checked into github and that anyone who wishes to improve it can issue pull requests against it, and the Build Czar makes sure the process is working.
Oct 18 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On Oct 18, 2013 3:09 PM, "Andrej Mitrovic" <andrej.mitrovich gmail.com>
wrote:
 On 10/18/13, eles <eles eles.com> wrote:
 IIRC, Walter wanted that file to always be named dmd.zip or
 dmd2.zip or whatever, in order to allow a permanent download
 link, while guaranteeing the file to be the latest version of the
 tool.
This is the wrong approach. There should be a "latest_beta" file which holds the name of the latest beta zip. Then automatic download tools can read this file before attempting to download the beta. And for everyone else who manually downloads, they should be able to see what the latest version is on the website. This isn't a novelty approach, many open-source libraries host their sources in a tarball on an FTP server with a LATEST file.
+1 to tarballs and a LATEST file. Infact, a folder structure in the same manner would go away long way too. Eg: 2.063/ dmd2.tar.gz dmd2.zip 2.063.1/ dmd2.tar.gz dmd2.zip 2.064-development/ dmd2.tar.gz dmd2.zip LATEST/ <- symlink to development or last stable. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 19 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
This is a good list of things that we could and should improve. Getting 
all minded to perfection would be difficult, but definitely worth living 
into.

I appreciate your enthusiasm for and involvement in D. At the top level 
a few simple realities need to be understood.

First, there is no OSS community that doesn't have its annoyances. I've 
been a direct participant to one other and am lurking on the forums of 
three more. Some are led by juntas of mini-tyrants; some are 
unnecessarily snooty; some are consumed by intestine fighting, politics, 
and horse-trading; and so on.

Second, some of your points revolve around the fact that Walter and 
myself are not as good as we should at certain tasks and roles, such as 
build master, PR person, manager, and operational officer. The general 
argument pattern revolves around "I/we told Walter/Andrei several times 
they need to do X, and they forget/ignore/do it badly." Clearly Walter 
is a self-confessed mediocre build czar at best. But he's doing it 
because, although there is no shortage of suggestions on how he should 
be doing it, nobody has the time and inclination to actually _be_ the 
build czar (which is entirely understandable).

Within a traditional organization where people are paid to work on a 
certain project, the solution would be simple and obvious - Walter would 
be relieved of the roles he doesn't excel in, and left to focus on those 
he's really good at. Other people would fill in duties and 
responsibilities such as preparing betas, sending them out for testing, 
announcing them, etc.

Within our current organizational landscape, where nobody is paid to 
work on D (not _with_ D) except for myself, addressing issues such as 
"we should have a better build master" is much more difficult to address.

Third, for what it's worth, here's what I believe are the top issues 
with D today:

1. Nobody is being paid to work on D (aside from me since recently, and 
on work that would benefit my employer).

2. D is not backed up solidly by a large engineering organization.

3. We are unable to review and accept contributions at the rate they are 
arriving.

I tend to ask myself how various proposals for improving our process 
address these three key points. I believe your list effects mostly (3), 
albeit not directly.

More answers inline.

 - We do not have any vision or major plans ahead for the language.
 Currently we're stuck in a bug-driven development environment, where
 bugs are arbitrarily picked off of bugzilla and fixed. But there's no
 major plans ahead, e.g. "let's plan to fix these X major bugs for some
 upcoming release". We can't force people to work on X or Y, but if
 they're in a visual place and marked important and scheduled to be
 fixed, this will give an incentive for contributors to work on these
 problems.
Walter and I frequently think of ways to gently steer people toward working on specific items. Votes, categorization, discussions are of limited impact. On occasion we've emailed major contributors directly and asked politely but point blank if they could look into an issue (sometimes something they had an expertise in, or even an issue they had caused). The rate of success has been very low. People still love working on things, just not on the things they're told to. We've added the "preapproved" tag - take a look: http://d.puremagic.com/issues/buglist.cgi?quicksearch=preapproved. A couple have opened pull requests, which have not yet received reviews yet (which is not my or Walter's fault as much as a larger community issue that we need to fix, see (3) above). Most don't. You yourself didn't find the time to update a task you volunteered on. That said, it's entirely possible a formula for success does exist. Looking forward to proposals, like improving the visuals of "bugs to be fixed". What I think is obvious is that solution involving more work for Walter and myself are unlikely to work well, for the simple reason we are both impatiently waiting for the sun to rise every day to do more work on D.
 - We do not have any defined release timeline. When is it time to
 start prepping for a release? It's up to Walter's arbitrary decision
 for when this happens, he doesn't even talk to the community or
 contributors on whether it's a good time for a beta phase (maybe
 there's a huge or disruptive new pull request that's planning to be
 merged and a beta should be delayed).
I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta.
 - We do not have a defined timeline for the beta testing period. How
 long before we decide that the beta has been tested for long enough
 before a release is made? Again, it's up to Walter's decision.
We are generally aiming for two weeks, but it sometimes gets longer because of the impending regressions. One good phenomenon has been that we've got an increasing number of people who are testing the beta.
 Having a defined release cycle and a beta testing period will
 ultimately be beneficial for everyone. People who are busy can
 rearrange their schedule to make free time and ensure they have enough
 time to test a beta compiler on their projects, and contributors to D
 can prepare for a cycle of days or weeks where they can rapidly work
 on reducing regressions and polish everything up for the release (e.g.
 writing an elaborate changelog).
I also believe a better cycle would be beneficial, but I don't think it would address our core issues.
 - We do not have a proper release system. Nick Sabalausky has been
 working hard on one[1], but Walter seems to have completely ignored
 it. It would have been a terrific opportunity to try and make it work
 for this release. What better way to test it than to test it on a
 release?
We'll look into it, but this harkens back to the simple dynamics mentioned above. That is essentially a request for Walter to change the way he does releases, and people tend to get set in their ways and have difficulty finding the time to stop and change things when there are so many other things vying for their attention. The best solution here is if Nick (or someone else) would _be_ the build manager using those great tools that Nick wrote. Anyhow, I'll look into that.
 - The betas are still not visible. The homepage makes no notes on a
 new beta being available, the download page does not list the betas
 either, and AFAICT there's no RSS feed either. The social media groups
 are not notified either (neither Andrei's nor Walter's twitter feed
 make a mention of a new beta being out, the same applies to
 https://twitter.com/D_Programming or the #dlang hash tags). To top it
 all off, you cannot post to the dmd-beta newsgroups from the D Forums,
 you have to separately register to this mailing list.
As a simple start, did you consider announcing the beta yourself? Anyone can tweet #dlang D_programming, and in all likelihood we and many others would retweet. Also, did you consider submitting a pull request for placing the beta announcement on the homepage?
 If we want user feedback on betas we absolutely must make the betas
 visible and give an opportunity for people to post feedback.
I agree. "We" is the right word.
 - Walter is still not tagging the beta releases by the file name (it's
 always dmd2beta.zip). I've complained about this several times and
 IIRC someone else did as well at dconf (maybe I'm remembering wrong
 though). They should at least be named as "dmd2_064_beta1.zip",
 "dmd2_064_beta2.zip". And all of them should always be available for
 download (including visibility on the download page), so people who do
 not use Git or build manually from master can quicky check whether a
 regression was introduced in a specific beta version.
Probably that's a good thing to do, and easy enough. I don't think it would push the needle significantly.
 - I still sigh when I hear about Walter and Andrei having private
 phone conversations, or any kind of decision is made behind-the-scenes
 rather than publicly where the community has a say in it. Walter's
 implementation of UDAs directly in master which lead to having a
 deprecated syntax even though nobody used this syntax is what comes to
 mind.
I understand this is well intended but it's the kind of remark that bends me out of shape. First, there's no substitute for real communication than direct conversation. We can't have a phone conversation with the community. Then, your first three points complain about a lack of leadership, and in the same breath you complain about there being too much of it. We believe we've done well in making this community a meritocracy where competent contributors can make a difference and make their word heard. To the extent we're doing it insufficiently, it's because too few people assume the responsibility to review and accept contributions. Walter scrambled to implement UDAs in a rush and breaking protocol in order to win a corporate D user, Remedy Games. It was a major, exceptional event. Would you have preferred the protocol to have been followed at the cost of Remedy?
 - Both Walter and Andrei not following the rules and making novice
 mistakes w.r.t Git and Github. Walter still seems to struggle with
 basic usage of git, where people continually have to re-explain what's
 wrong and how to fix an issue. I'm sorry, but if someone bought the
 Git book years ago and is still struggling with *concepts* then no
 amount of hand-guiding is going to help.
I agree that's a problem. Probably what would help would be more quality reviews and pulls by our members with commit rights, of whom you are one.
 And Andrei doing things like
 merging a dozen pull requests at once, with complete disregard to the
 fact that merging to master means other pulls could easily break (and
 so master can be broken). You cannot make so many merges unless you're
 absolutely sure each pull request does not interfere with another.
If a pull request is sensible and meaningful it shall be pulled. That's the way we do things at Facebook, too, and it scales. There may be pulls that are so closely related they break the build when put in conjunction, but I believe that case is rare. I also want to convey a bit of perspective here. There are 221 open pull requests right now. These are 221 instances of good work put in by talented people, who associated hopes and wishes to improve things with that work. This bothers me. I lose sleep at night because of it. And the fact that those contributions don't get looked at is our entire community's fault as it is mine. So when I have a few free minutes, I try to take a look at the extant pull requests - really, any would do. I try to pull in those that are meaningful and uncontroversial. I agree I could probably spend more time on carefully analyzing interactions between pulls, but that's time I can't afford.
 - Back to Walter, a few weeks ago he merged a pull request over night,
 without regard to the pull request not being fully tested by the test
 machines. The result? Master was broken **for the entire next day**.
 Nobody knew which commit broke master, so nothing was done until
 Walter came back to Github the next day and started reverting his
 pulls. In the meantime the entire day was wasted because nobody's pull
 request could get green. Luckily it was a sunday, so there weren't too
 many complaints. But I could have easily merged a few pulls that day
 (as it happens I like to do things on a sunday), and as a result we
 would have a smaller pull queue.
I guess such accidents are bound to happen to the best of us. A build czar with the appropriate skills would have swiftly undone the damage. But there is no build czar.
 There's just many things that are going plain wrong here, and a lot of
 promises are always made but ultimately never delivered (whether it's
 about breaking changes or an improved development process -- again
 think about scheduling bug fixes for the future, we could help people
 prepare for the breaking changes).
Whatever we don't get delivered, it's not for the lack of trying. Whatever we do, it doesn't come easily.
 Personally I find D to be a huge part of me right now (probably not
 the other way around, I'm a small part of this compared to the huge
 contributors), and I feel really bummed out when both Andrei and
 Walter take a casual stance when things are broken (whether it's the
 system itself or something specific like master being broken). I
 really think we have a great thing going here with the language, but
 everything else has to improve, and particularly the development and
 release process.

 So that's what I'm protesting about.
The individual points are salient, but I fail to grab the most significant bit. The logic doesn't follow. We're in this together; to wit, for many of the things you're asking why they don't get done, you could be asked the same thing. You did a great job on formatting the changelog. It has been an unqualified success, it was amazing marketing for D, and it has been thoroughly appreciated by everyone. It is great work that we need more of. Now you're not doing that work in protest against... not enough work getting done. Andrei
Oct 18 2013
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/18/13, Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 nobody has the time and inclination to actually _be_ the
 build czar (which is entirely understandable).
Building something should be a command on the command-line. The whole issue is about currently having a person in place of a tool.
 You yourself didn't find the time to update a task you volunteered on.
You mean https://github.com/D-Programming-Language/dmd/pull/2235 ? I'll get back to it soon.
 We'll look into it, but this harkens back to the simple dynamics
 mentioned above. That is essentially a request for Walter to change the
 way he does releases, and people tend to get set in their ways and have
 difficulty finding the time to stop and change things when there are so
 many other things vying for their attention. The best solution here is
 if Nick (or someone else) would _be_ the build manager using those great
 tools that Nick wrote.
Like I said before, it's a command, you don't need a manager to do it, you need a reliable tool. "$ make_build" is all it takes. This "manager" and "czar" nonsense is really a corporate way of solving issues. I can see how you might have gotten used to that when you have people on a payroll that you can easily asign to a task. Even if ultimately it's beneficial for having a tool in place of a person, a company might decide against it if it can "hammer the nail right away and make the problem go away" (until the problem comes walking back). We're programmers, we should rely on tools for automated tasks. And I want this not because I'm an automation freak (I'm not), but precisely because Walter has screwed up the zip package many times before. Hence, if Walter is the one who is currently in control, why doesn't he interact with Nick to ease into using a build tool rather than use some X number of scripts that he keeps on his PC only?
 As a simple start, did you consider announcing the beta yourself?
I didn't, because I disliked the current model and tied my hands when I saw the new beta was out due to the sum of frustrations which I've listed. This will change if the situation improves, of course.
 Anyone can tweet #dlang  D_programming, and in all likelihood we and many
 others would retweet.
Good. I'll certainly start to build a better online presence, including tweeting, and I should start blogging too (there's plenty to blog about w.r.t. D). I can't be the pot calling the kettle black.
 Also, did you consider submitting a pull request
 for placing the beta announcement on the homepage?
Good idea, and it's something I can work on. But I hope you understand this isn't really about you or Walter not doing these things yourself, but rather the fact that you didn't seem to recognize this as being a problem. I've mentioned the build/release issue many times, and now we finally have a pull request that could make this problem go away. Just as I thought the problem was being resolved, Walter announced the new beta. So clearly he still doesn't see the pull request as being important.
 Probably that's a good thing to do, and easy enough. I don't think it
 would push the needle significantly.
But that's just the thing. The things I've listed are what pushed the needled "too much to the left" for me. Small improvements like this are great, and they add up. Otherwise people (like me) will keep complaining about small issues, which collect and add up to the frustration.
 We can't have a phone conversation with the community.
Why do you even need these phone conversations related to D or decision making? The community has an insane number of intelligent people who can contribute to resolving issues.
 Then, your first three points complain
 about a lack of leadership, and in the same breath you complain about
 there being too much of it.
Lack of leading the community and the development process, not lack of decision making.
 Walter scrambled to implement UDAs in a rush and breaking protocol in
 order to win a corporate D user, Remedy Games. It was a major,
 exceptional event. Would you have preferred the protocol to have been
 followed at the cost of Remedy?
This is what doesn't inspire me at all. So in the future when company X decides it wants some feature in the language you're saying we should not follow the protocol like we do for all the other user-requested features? Because the news of company X using D will create headlines?
 I agree that's a problem. Probably what would help would be more quality
 reviews and pulls by our members with commit rights, of whom you are one.
I don't see what this has to do with not understanding Git basics. If I merge more pull requests it isn't going to improve Walter's knowledge of Git. Also, I tend to review pull requests which I actually understand (doing otherwise would be counter-productive). Sometimes I fall behind track because I also want to work on some of my own D projects. I know we're all very busy, but I didn't say Walter didn't want to review something, I said in particular that Walter is still struggling with Git fundamentals.
 I agree I could probably spend more time
 on carefully analyzing interactions between pulls, but that's time I
 can't afford.
Well that's a damn shame. You see, most of us who have commit rights wait for the pull request questions to be answered, for commits to be properly reviewed, and for any final bookkeping and polishing to be done, and then we wait for the lights to go green before we pull.
 I guess such accidents are bound to happen to the best of us. A build
 czar with the appropriate skills would have swiftly undone the damage.
 But there is no build czar.
Here we go again with this corporate speak. Now you want to add another person to the mix, when we already have the tooling in place. Don't merge a pull request unless it's green, how can that be so hard to understand?
 We're in this together; to wit, for many of the things you're asking why
 they don't get done, you could be asked the same thing.
 Now you're not doing that work in protest against... not enough work
 getting done.
I see that most of your arguments ultimately revolve around throwing the ball to my side, and asking why I didn't do all the things I listed. That's completely fair game (it is), but I still can't control when we do a beta/release cycle, and I can't control zipping up a release package (and I don't want to, I just want this to become a small task of issuing a command on the command line). Now we have a shot at the second problem with automatic tooling to make the release package. Is Walter going to be ok with this? Btw, if you think that I'm just going to put my tail between my legs and run, you're out of your mind. I'll deliver on the promises I made (which includes the part about twitter/blogging/etc), and I'll make the 2.064 changelog, and probably future ones as well. I can bite the bullet and do hard work for D. But, if you're going to keep saying things like: - Damn the protocol, don't you see feature X for Company Y is important? We'll implement it regardless of community. - Damn the protocol, the pull request list is long and I'll just do whatever I want to reduce it, even if it means having a broken master. Then you cannot expect me to be silent about it. This little protest of mine was an attention grabber to the issues that we face, and especially to some issues that I'm personally frustated about. You can consider the protest over. As for me, I'll do my part to improve whatever I can with regards to D. I love D and the community too much to be stopped from contributing more just out of a few frustrations.
Oct 18 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/18/2013 1:29 PM, Andrej Mitrovic wrote:
 But I hope you understand this isn't really about you or Walter not
 doing these things yourself, but rather the fact that you didn't seem
 to recognize this as being a problem. I've mentioned the build/release
 issue many times, and now we finally have a pull request that could
 make this problem go away. Just as I thought the problem was being
 resolved, Walter announced the new beta. So clearly he still doesn't
 see the pull request as being important.
As I've posted elsewhere, I want very much to have the package build process to be a single command. I want Brad's autotester to build those packages as part of its regular build/test runs. I'd like Brad, Nick, Jordi, Jacob, and anyone else involved with the installers to get together to get this done. As to why I didn't do this for the beta zip - because the install package builders break with every new release, and for the initial beta I just wanted to see where we were with the regressions - and there's a lot of work to do just to fix those, before getting to a release candidate. We do need a Build Czar, because the install builds break every time, due to things like failure to update the manifests, new build targets, new features, etc. Somebody has to be responsible for getting all the scripts tested and working again - which is also why I want this to be part of the autotester, so problems will show up sooner. (And heck, just building the zip file exposed a lot of breakage.)
Oct 18 2013
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, October 18, 2013 15:31:05 Walter Bright wrote:
 We do need a Build Czar, because the install builds break every time, due to
 things like failure to update the manifests, new build targets, new
 features, etc. Somebody has to be responsible for getting all the scripts
 tested and working again - which is also why I want this to be part of the
 autotester, so problems will show up sooner. (And heck, just building the
 zip file exposed a lot of breakage.)
I would suggest making a very prominent post about this in the newsgroup - that you want a build czar. If you make it clear that the position needs to be filled, and that it's your intention to offload that work to the build czar, then someone may step up to do it - especially if they're unhappy with the current process. Most of the push on that thus far has been towards trying to get you to change what you're doing, and I'm not sure that it's clear enough to everyone that you're ready and willing to have someone else shoulder those responsibilities. And without that being clear, I think that it's a lot less likely for someone to step up and offer to do it. We _have_ had some folks step up to start working on some of it (e.g. Nick with the zip file generation), so maybe making it clear that the position is open and that we want it filled will make it so that someone like that will step up and do it. Sometimes the problem isn't finding someone who's ready and willing but rather making it clear what's needed so that someone who's already ready and willing knows what they can do to help. - Jonathan M Davis
Oct 18 2013
prev sibling parent "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Friday, 18 October 2013 at 20:29:29 UTC, Andrej Mitrovic wrote:
 On 10/18/13, Andrei Alexandrescu 
 <SeeWebsiteForEmail erdani.org> wrote:
 As a simple start, did you consider announcing the beta 
 yourself?
I didn't, because I disliked the current model and tied my hands when I saw the new beta was out due to the sum of frustrations which I've listed. This will change if the situation improves, of course.
 Anyone can tweet #dlang  D_programming, and in all likelihood 
 we and many
 others would retweet.
Good. I'll certainly start to build a better online presence, including tweeting, and I should start blogging too (there's plenty to blog about w.r.t. D). I can't be the pot calling the kettle black.
Idea: We can use Twittwer API to automaticly publish a news like "new betta". I did it via PHP for Drupal, and it wasn't so difficult. So, we can create a package build process. It creates new betta, publish announcement in the D forum, in the D homepage, in the D dowload page and in the D twitter.
Oct 19 2013
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 18 Oct 2013 11:45:27 -0700
schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:
 
 - We do not have any defined release timeline. When is it time to
 start prepping for a release? It's up to Walter's arbitrary decision
 for when this happens, he doesn't even talk to the community or
 contributors on whether it's a good time for a beta phase (maybe
 there's a huge or disruptive new pull request that's planning to be
 merged and a beta should be delayed).
I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta.
Why is everyone here so obsessed with feature based releases? Quoting Iain's post from 30.8:
 It has been about 3 months since the last release of the D 
 front-end implementation.  Three years experience and carrying 
 out over 100 merges into GDC tells me that each time the 
 development cycle starts edging towards it's fourth month, it 
 makes things an absolute nightmare, in both the time consumed 
 merging in the changes, and with time spent tracking down bug 
 reports for unittests/testsuite cases that test backend code 
 generation - with 2.060, 2.061 and 2.063 being the worst releases 
 I have ever had to deal with - before 2.060 the release schedule 
 (if it even qualifies as a 'schedule') was anywhere between 1-2 
 months.
Even a rough schedule (We try to release a new frontend version every 2 months) would help. Would it have been the end of the world if we just released 2.064 two months ago and 2.065 now? But what's worse: If we keep making feature based releases then the criteria for release should be documented by those making the decision. It's as simple as writing two sentences on a wiki page. Right now I don't have any clue why the 'time is ripe' now and not 2 months ago, or one month ago, or in two weeks... It seems like Walter is just flipping a coin every month (I don't say it is like that - but it looks like that because there's no information on the release criteria) And btw: 5 months between releases is just way too long for users as well. Although the features Walter envisioned for 2.064 may not have been ready 2 months ago we could have shipped many bug fixes two months earlier.
Oct 19 2013
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On Oct 19, 2013 10:11 AM, "Johannes Pfau" <nospam example.com> wrote:
 Am Fri, 18 Oct 2013 11:45:27 -0700
 schrieb Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>:

 - We do not have any defined release timeline. When is it time to
 start prepping for a release? It's up to Walter's arbitrary decision
 for when this happens, he doesn't even talk to the community or
 contributors on whether it's a good time for a beta phase (maybe
 there's a huge or disruptive new pull request that's planning to be
 merged and a beta should be delayed).
I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta.
Why is everyone here so obsessed with feature based releases? Quoting Iain's post from 30.8:
 It has been about 3 months since the last release of the D
 front-end implementation.  Three years experience and carrying
 out over 100 merges into GDC tells me that each time the
 development cycle starts edging towards it's fourth month, it
 makes things an absolute nightmare, in both the time consumed
 merging in the changes, and with time spent tracking down bug
 reports for unittests/testsuite cases that test backend code
 generation - with 2.060, 2.061 and 2.063 being the worst releases
 I have ever had to deal with - before 2.060 the release schedule
 (if it even qualifies as a 'schedule') was anywhere between 1-2
 months.
Even a rough schedule (We try to release a new frontend version every 2 months) would help. Would it have been the end of the world if we just released 2.064 two months ago and 2.065 now? But what's worse: If we keep making feature based releases then the criteria for release should be documented by those making the decision. It's as simple as writing two sentences on a wiki page. Right now I don't have any clue why the 'time is ripe' now and not 2 months ago, or one month ago, or in two weeks... It seems like Walter is just flipping a coin every month (I don't say it is like that - but it looks like that because there's no information on the release criteria) And btw: 5 months between releases is just way too long for users as well. Although the features Walter envisioned for 2.064 may not have been ready 2 months ago we could have shipped many bug fixes two months earlier.
And a big +1 to that as well. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 19 2013
parent "Kagamin" <spam here.lot> writes:
On Saturday, 19 October 2013 at 11:39:08 UTC, Iain Buclaw wrote:
 It has been about 3 months since the last release of the D
 front-end implementation.  Three years experience and 
 carrying
 out over 100 merges into GDC tells me that each time the
 development cycle starts edging towards it's fourth month, it
 makes things an absolute nightmare, in both the time consumed
 merging in the changes, and with time spent tracking down bug
 reports for unittests/testsuite cases that test backend code
 generation - with 2.060, 2.061 and 2.063 being the worst 
 releases
 I have ever had to deal with - before 2.060 the release 
 schedule
 (if it even qualifies as a 'schedule') was anywhere between 
 1-2
 months.
And a big +1 to that as well.
Can't merges be done without release at your discretion in a separate branch or repo? If you keep track of it monthly, then you would have less to merge at the time of release.
Oct 20 2013
prev sibling next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.10.2013 20:45, schrieb Andrei Alexandrescu:
 Walter and I frequently think of ways to gently steer people toward
 working on specific items. Votes, categorization, discussions are of
 limited impact. On occasion we've emailed major contributors directly
 and asked politely but point blank if they could look into an issue
 (sometimes something they had an expertise in, or even an issue they had
 caused). The rate of success has been very low. People still love
 working on things, just not on the things they're told to.
I think you should continue to do that. Even if it only has a small sucess rate. I for example wouldn't have noticed that the stack trace code I submitted into druntime did cause long startup times for D-Programms that are run directly from the root of a disk drive if Walter wouldn't have send me the e-mail with the bug in it. After the e-mail I even fixed the bug ;-) Kind Regards Benjamin Thaut
Oct 19 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On Oct 18, 2013 7:45 PM, "Andrei Alexandrescu" <
SeeWebsiteForEmail erdani.org> wrote:
 Walter scrambled to implement UDAs in a rush and breaking protocol in
order to win a corporate D user, Remedy Games. It was a major, exceptional event. Would you have preferred the protocol to have been followed at the cost of Remedy?

I would have preferred Remedy working with the community, rather than
talking behind closed doors to those who concern only them.  And I say this
as someone who was part involved before UDAs and the public announcement
came into the picture.

What I did find interesting, in reflection at dconf, was that Manu
countered all arguments (that I could recall) Walter made to keeping the
deprecation in place.

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 19 2013
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 19 October 2013 21:29, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 On Oct 18, 2013 7:45 PM, "Andrei Alexandrescu" <
 SeeWebsiteForEmail erdani.org> wrote:
 Walter scrambled to implement UDAs in a rush and breaking protocol in
order to win a corporate D user, Remedy Games. It was a major, exceptional event. Would you have preferred the protocol to have been followed at the cost of Remedy?

 I would have preferred Remedy working with the community, rather than
 talking behind closed doors to those who concern only them.  And I say this
 as someone who was part involved before UDAs and the public announcement
 came into the picture.
Surely you can appreciate that we weren't ready for it to be made public information. We didn't really have much choice. There's always company bureaucracy to deal with. What I did find interesting, in reflection at dconf, was that Manu
 countered all arguments (that I could recall) Walter made to keeping the
 deprecation in place.
I had no idea about the deprecation of the original syntax. I don't recall ever being a party to any discussion on that matter. The community clearly voted for attribute syntax, and as soon as it was done, I switched all our code over. I wasn't personally precious about which way the syntax went. We just needed the feature, and it seems to have been successfully used by many others since us too, so I really hope most people agree it was a valuable addition, despite materialising fairly abruptly. It's also not like I was the first to come up with it either, people had been talking about attributes for years, I just gave it a nudge. If we were the only people that *ever* used the initial (experimental) C#-style [attribute] syntax, then it should be removed and put an end to this criticism, since I changed our code over within minutes of the new syntax being made available :) There's probably no D code anywhere that uses the original C#-style syntax.
Oct 19 2013
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 20 October 2013 07:06, Manu <turkeyman gmail.com> wrote:
 On 19 October 2013 21:29, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On Oct 18, 2013 7:45 PM, "Andrei Alexandrescu"
 <SeeWebsiteForEmail erdani.org> wrote:
 Walter scrambled to implement UDAs in a rush and breaking protocol in
 order to win a corporate D user, Remedy Games. It was a major, exceptional
 event. Would you have preferred the protocol to have been followed at the
 cost of Remedy?
I would have preferred Remedy working with the community, rather than talking behind closed doors to those who concern only them. And I say this as someone who was part involved before UDAs and the public announcement came into the picture.
Surely you can appreciate that we weren't ready for it to be made public information. We didn't really have much choice. There's always company bureaucracy to deal with.
I can partly understand, and I never felt inclined to push them through the proper channels when I received in personal emails from staff. For me, if I use a product/project and like a product/project, I want to get involved in with the product/project. But I suppose not everyone in a games dev company wants to chip in with aiding development of a library/toolchain when they've got a deadline on a game to finish first...
 What I did find interesting, in reflection at dconf, was that Manu
 countered all arguments (that I could recall) Walter made to keeping the
 deprecation in place.
I had no idea about the deprecation of the original syntax. I don't recall ever being a party to any discussion on that matter. The community clearly voted for attribute syntax, and as soon as it was done, I switched all our code over. I wasn't personally precious about which way the syntax went. We just needed the feature, and it seems to have been successfully used by many others since us too, so I really hope most people agree it was a valuable addition, despite materialising fairly abruptly. It's also not like I was the first to come up with it either, people had been talking about attributes for years, I just gave it a nudge. If we were the only people that *ever* used the initial (experimental) C#-style [attribute] syntax, then it should be removed and put an end to this criticism, since I changed our code over within minutes of the new syntax being made available :) There's probably no D code anywhere that uses the original C#-style syntax.
That was near enough exactly the answer to the question I recall from dconf. :o) The question being on how true Walter was in saying that whoever was using the C#-style syntax had a large codebase, and change-over was not simple for them. However it is entirely possible that he was referring to another company other than Remedy. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 19 2013
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Andrei Alexandrescu, el 18 de October a las 11:45 me escribiste:
- We do not have any defined release timeline. When is it time to
start prepping for a release? It's up to Walter's arbitrary decision
for when this happens, he doesn't even talk to the community or
contributors on whether it's a good time for a beta phase (maybe
there's a huge or disruptive new pull request that's planning to be
merged and a beta should be delayed).
I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta.
Just a brief comment about this: sometimes regularity could be better than tons of new features/bugfixes.
 Walter scrambled to implement UDAs in a rush and breaking protocol
 in order to win a corporate D user, Remedy Games. It was a major,
 exceptional event. Would you have preferred the protocol to have
 been followed at the cost of Remedy?
That's not the entire story. Back then Walter still push changes to the repo himself. That was the main problem, and fortunately it finally changed. He did that all the time in the past, UDAs wasn't an exception, but it had a high impact back then because Walter was the only one not going through the review process, it so felt doubly unfair.
 So when I have a few free minutes, I try to take a look at the
 extant pull requests - really, any would do. I try to pull in those
 that are meaningful and uncontroversial. I agree I could probably
 spend more time on carefully analyzing interactions between pulls,
 but that's time I can't afford.
I think the alternative is merging one, wait for the autotester, merge another and wait for the autotester, and so on. I would be more annoying having to wait for every test, but there is really no rush to make a bunch in one go. I think it would be extremely helpful to have some help from the autotester to auto-merge too. Like marking a pull request as approved so the auto-tester merges it automatically when it passes the test. Dreaming? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- <o_O> parakenotengobarraespaciadora <o_O> aver <o_O> estoyarreglandolabarraporkeserompiounapatita
Oct 21 2013
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
Why not just copy what Linus does with the Linux kernel. Different people
in charge of different parts of the compiler. Pull requests should go to
the correct person, who then makes a pull request that goes to the main
line.



On Mon, Oct 21, 2013 at 12:31 PM, Leandro Lucarella <luca llucax.com.ar>wrote:

 Andrei Alexandrescu, el 18 de October a las 11:45 me escribiste:
- We do not have any defined release timeline. When is it time to
start prepping for a release? It's up to Walter's arbitrary decision
for when this happens, he doesn't even talk to the community or
contributors on whether it's a good time for a beta phase (maybe
there's a huge or disruptive new pull request that's planning to be
merged and a beta should be delayed).
I understand how that can be a bother. Walter figures the time is ripe for a new release when we have enough compelling features and fixes. I'll try to make the appropriate announcements in the future prior to deciding on starting a beta.
Just a brief comment about this: sometimes regularity could be better than tons of new features/bugfixes.
 Walter scrambled to implement UDAs in a rush and breaking protocol
 in order to win a corporate D user, Remedy Games. It was a major,
 exceptional event. Would you have preferred the protocol to have
 been followed at the cost of Remedy?
That's not the entire story. Back then Walter still push changes to the repo himself. That was the main problem, and fortunately it finally changed. He did that all the time in the past, UDAs wasn't an exception, but it had a high impact back then because Walter was the only one not going through the review process, it so felt doubly unfair.
 So when I have a few free minutes, I try to take a look at the
 extant pull requests - really, any would do. I try to pull in those
 that are meaningful and uncontroversial. I agree I could probably
 spend more time on carefully analyzing interactions between pulls,
 but that's time I can't afford.
I think the alternative is merging one, wait for the autotester, merge another and wait for the autotester, and so on. I would be more annoying having to wait for every test, but there is really no rush to make a bunch in one go. I think it would be extremely helpful to have some help from the autotester to auto-merge too. Like marking a pull request as approved so the auto-tester merges it automatically when it passes the test. Dreaming? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- <o_O> parakenotengobarraespaciadora <o_O> aver <o_O> estoyarreglandolabarraporkeserompiounapatita
Oct 22 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 22 October 2013 08:35, Rory McGuire <rjmcguire gmail.com> wrote:
 Why not just copy what Linus does with the Linux kernel. Different people in
 charge of different parts of the compiler. Pull requests should go to the
 correct person, who then makes a pull request that goes to the main line.
The thing is, there are too few components of D that make it work. Take DMD for example, you've got: backend, glue, front-end, ctfe. You could probably stretch it out further into port, target, lexer/parse, template, speller, cppmangle/mangle, hdrgen. But these are small and on their own don't get many changes to. Regards -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 22 2013
prev sibling next sibling parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

 This isn't a release candidate, in particular the documentation 
 needs work, but we need to shake the tree for any undetected 
 regressions.

 Further beta announcements go in the dmd-beta mailing list.

 Note that this release contains:

 29 enhancements
 307 dmd bugs fixed
 14 druntime bugs fixed
 73 phobos bugs fixed
The sizes of Phobos binaries increased by a third for every OS except FreeBSD, which seems to have remained the same (created 17 Feb 2013). Aside from the FreeBSD case which is most likely a bug, is that an expected increase, or they are just compiled with some extra options for the beta, and will shrink again when the release comes? Ivan Kazmenko.
Oct 12 2013
parent reply "Ivan Kazmenko" <gassa mail.ru> writes:
On Sunday, 13 October 2013 at 01:26:39 UTC, Ivan Kazmenko wrote:
 The sizes of Phobos binaries increased by a third for every OS 
 except FreeBSD, which seems to have remained the same (created 
 17 Feb 2013).  Aside from the FreeBSD case which is most likely 
 a bug, is that an expected increase, or they are just compiled 
 with some extra options for the beta, and will shrink again 
 when the release comes?
Just to make it clear, I mean the difference between the 2.064 beta provided by Walter and 2.063.2 release.
Oct 12 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
13-Oct-2013 05:29, Ivan Kazmenko пишет:
 On Sunday, 13 October 2013 at 01:26:39 UTC, Ivan Kazmenko wrote:
 The sizes of Phobos binaries increased by a third for every OS except
 FreeBSD, which seems to have remained the same (created 17 Feb 2013).
 Aside from the FreeBSD case which is most likely a bug, is that an
 expected increase, or they are just compiled with some extra options
 for the beta, and will shrink again when the release comes?
Just to make it clear, I mean the difference between the 2.064 beta provided by Walter and 2.063.2 release.
The reason might be Unicode tables from new std.uni. But that should be cross-platform increase in size. -- Dmitry Olshansky
Oct 13 2013
prev sibling next sibling parent "Michal Minich" <michal.minich gmail.com> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip
I found 2 issues: 1) Compile time almost doubled. Tested on vibe.d 28 seconds - dmd 2.063 + updated snn.lib 52 seconds - dmd 2.064 beta 2) Regression - After building vibe.d as a lib I was not able to link it with application. I get: Error 1: Previous Definition Different : _D12__entrypoint12__ModuleInfoZ Both tested using command line -lib -g -debug -w -property -X -Xf"x.json" -Isource -deps="x.dep" -of"x.lib" -map "x.map" -L/NOMAP
Oct 13 2013
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

 This isn't a release candidate, in particular the documentation 
 needs work, but we need to shake the tree for any undetected 
 regressions.

 Further beta announcements go in the dmd-beta mailing list.

 Note that this release contains:

 29 enhancements
 307 dmd bugs fixed
 14 druntime bugs fixed
 73 phobos bugs fixed
DIP 37 causes problems: http://forum.dlang.org/thread/qlrfzafudnfuialnjsnt forum.dlang.org#post-utjvlygdigsxtkgpfcny:40forum.dlang.org
Oct 13 2013
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, October 13, 2013 11:27:12 Namespace wrote:
 DIP 37 causes problems:
 http://forum.dlang.org/thread/qlrfzafudnfuialnjsnt forum.dlang.org#post-utjv
 lygdigsxtkgpfcny:40forum.dlang.org
Then report the bug and mark it as a regression if it works with the previous release: http://d.puremagic.com/issues - Jonathan M Davis
Oct 13 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
On Sunday, 13 October 2013 at 09:44:23 UTC, Jonathan M Davis 
wrote:
 On Sunday, October 13, 2013 11:27:12 Namespace wrote:
 DIP 37 causes problems:
 http://forum.dlang.org/thread/qlrfzafudnfuialnjsnt forum.dlang.org#post-utjv
 lygdigsxtkgpfcny:40forum.dlang.org
Then report the bug and mark it as a regression if it works with the previous release: http://d.puremagic.com/issues - Jonathan M Davis
Do not rush me. :P http://forum.dlang.org/thread/bug-11241-3 http.d.puremagic.com%2Fissues%2F#post-bug-11241-3:40http.d.puremagic.com:2Fissues:2F
Oct 13 2013
prev sibling next sibling parent reply "Olivier Pisano" <olivier.pisano laposte.net> writes:
Found one issue :

A call to std.functional.memoize crashes with the following error:

object.Error: TypeInfo.compare is not implemented
----------------
./rossignol(const(pure nothrow  trusted int 
function(const(void*), const(void*))) 
object.TypeInfo_Struct.compare+0x3a) [0x89b3032]
./rossignol(_aaInX+0x4d) [0x89b7f9d]
./rossignol(immutable(char)[] 
std.functional.memoize!(_D3xml10attributes5name_FKxS3xml10attributes9Attrib
teZAya).memoize(ref 
const(xml.attributes.Attribute))+0x44) [0x878b954]
Oct 13 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/13/2013 4:01 AM, Olivier Pisano wrote:
 Found one issue :

 A call to std.functional.memoize crashes with the following error:

 object.Error: TypeInfo.compare is not implemented
 ----------------
 ./rossignol(const(pure nothrow  trusted int function(const(void*),
 const(void*))) object.TypeInfo_Struct.compare+0x3a) [0x89b3032]
 ./rossignol(_aaInX+0x4d) [0x89b7f9d]
 ./rossignol(immutable(char)[]
 std.functional.memoize!(_D3xml10attributes5name_FKxS3xml10attributes9AttributeZAya).memoize(ref
 const(xml.attributes.Attribute))+0x44) [0x878b954]
Please file bug reports on Bugzilla!
Oct 13 2013
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 13.10.2013 00:16, schrieb Walter Bright:
 http://ftp.digitalmars.com/dmd2beta.zip
This zip does not contain the latest version of Optlink. The one at http://ftp.digitalmars.com/optlink.zip seems to be newer. Kind Regards Benjamin Thaut
Oct 14 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2013 12:50 AM, Benjamin Thaut wrote:
 Am 13.10.2013 00:16, schrieb Walter Bright:
 http://ftp.digitalmars.com/dmd2beta.zip
This zip does not contain the latest version of Optlink. The one at http://ftp.digitalmars.com/optlink.zip seems to be newer.
That one is dated 04-10-13, while the one in the zip file is dated 08/28/13, so I'm not sure why the former is newer.
Oct 14 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 14.10.2013 10:59, schrieb Walter Bright:
 On 10/14/2013 12:50 AM, Benjamin Thaut wrote:
 Am 13.10.2013 00:16, schrieb Walter Bright:
 http://ftp.digitalmars.com/dmd2beta.zip
This zip does not contain the latest version of Optlink. The one at http://ftp.digitalmars.com/optlink.zip seems to be newer.
That one is dated 04-10-13, while the one in the zip file is dated 08/28/13, so I'm not sure why the former is newer.
My bad. German dates... We write the the day first then the month and then the year.
Oct 14 2013
next sibling parent reply Rory McGuire <rjmcguire gmail.com> writes:
On Mon, Oct 14, 2013 at 11:35 AM, Benjamin Thaut <code benjamin-thaut.de>wrote:

 My bad. German dates... We write the the day first then the month and then
 the year.
Americans seem to read dates as "October 14th, 2013" which is way they write numeric dates in such an odd way :D. Since I realized that is the reason for it I've been much better at noticing the location of a person who wrote a date down.
Oct 14 2013
next sibling parent 1100110 <0b1100110 gmail.com> writes:
On 10/14/2013 04:59 AM, Rory McGuire wrote:
 On Mon, Oct 14, 2013 at 11:35 AM, Benjamin Thaut <code benjamin-thaut.de
 <mailto:code benjamin-thaut.de>> wrote:

     My bad. German dates... We write the the day first then the month
     and then the year.


 Americans seem to read dates as "October 14th, 2013" which is way they
 write numeric dates in such an odd way :D.

 Since I realized that is the reason for it I've been much better at
 noticing the location of a person who wrote a date down.
*BOTH* of you write dates in an odd way. http://xkcd.com/1179/
Oct 14 2013
prev sibling parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Monday, 14 October 2013 at 10:00:01 UTC, Rory McGuire wrote:
 On Mon, Oct 14, 2013 at 11:35 AM, Benjamin Thaut 
 <code benjamin-thaut.de>wrote:

 My bad. German dates... We write the the day first then the 
 month and then
 the year.
Americans seem to read dates as "October 14th, 2013" which is way they write numeric dates in such an odd way :D. Since I realized that is the reason for it I've been much better at noticing the location of a person who wrote a date down.
I've chosen to try writing dates using the ISO 2013-10-14 Always causes confusion, thus leading people to actually figure out the numbers. :) Of course programmers don't have an issue with it. Sadly, it can't be shortened: 13-10-14 or 10-14 I'm also ok with 2013/10/14 even though ISO isn't.
Oct 14 2013
parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 14 October 2013 at 19:17:25 UTC, 1100110 wrote:
 *BOTH* of you write dates in an odd way.

 http://xkcd.com/1179/
Amen. ISO 8601 FTW. The Japanese got it correct natively though. It's year, then month then day, seperated either by explicit 年月日 (year, month, day), or by "/" or "-". At university, we mostly used "-". Well, that's when they don't use their imperial dates :/ On Monday, 14 October 2013 at 20:39:12 UTC, Jesse Phillips wrote:
 I've chosen to try writing dates using the ISO

 2013-10-14

 Always causes confusion, thus leading people to actually figure 
 out the numbers. :) Of course programmers don't have an issue 
 with it. Sadly, it can't be shortened:

 13-10-14 or 10-14

 I'm also ok with 2013/10/14 even though ISO isn't.
It minimum, I try to keep it to "YYYY.*MM.*DD". Also, when naming files, it sorts automatically, which is always good. That's how I name my photos anyways: format("%04-%02 - LOCATION_OR_EVENT - %03", year, month, ++counter).
Oct 14 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 14 October 2013 at 21:21:29 UTC, monarch_dodra wrote:
 On Monday, 14 October 2013 at 19:17:25 UTC, 1100110 wrote:
 *BOTH* of you write dates in an odd way.

 http://xkcd.com/1179/
Amen. ISO 8601 FTW. The Japanese got it correct natively though. It's year, then month then day, seperated either by explicit 年月日 (year, month, day), or by "/" or "-". At university, we mostly used "-". Well, that's when they don't use their imperial dates :/
Yes, they are pretty good at choosing completely confusing norms, but on that one they did good :D
Oct 14 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2013 2:35 AM, Benjamin Thaut wrote:
 My bad. German dates... We write the the day first then the month and then the
 year.
Yah, that is terribly confusing, especially considering the global intarnets. I tend to write dates as year-month-day, that way they sort properly in a directory listing :-)
Oct 14 2013
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 14, 2013 14:18:33 Walter Bright wrote:
 On 10/14/2013 2:35 AM, Benjamin Thaut wrote:
 My bad. German dates... We write the the day first then the month and then
 the year.
Yah, that is terribly confusing, especially considering the global intarnets. I tend to write dates as year-month-day, that way they sort properly in a directory listing :-)
Exactly. It sorts great that way and is nice and clear. It's also what's done in the standard ISO date formats. - Jonathan M Davis
Oct 14 2013
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Monday, 14 October 2013 at 21:18:32 UTC, Walter Bright wrote:
 Yah, that is terribly confusing, especially considering the 
 global intarnets.
I get bitten by it locally too: if there's a test with an inaccurate sql query with time formatted as string, the sql server doesn't always compute it, because the default "human-readable" time format is taken from the current locale, and to parse it one first has to guess the format itself, which is quite difficult in a heterogeneous system.
Oct 14 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 15 October 2013 at 04:41:13 UTC, Kagamin wrote:
 On Monday, 14 October 2013 at 21:18:32 UTC, Walter Bright wrote:
 Yah, that is terribly confusing, especially considering the 
 global intarnets.
I get bitten by it locally too: if there's a test with an inaccurate sql query with time formatted as string, the sql server doesn't always compute it, because the default "human-readable" time format is taken from the current locale, and to parse it one first has to guess the format itself, which is quite difficult in a heterogeneous system.
This is for that very reason that I prefers to work with timestamps UTC as much as possible. No timzone hell, no format hell, no nothing. Just convert from user input directly, and convert back to text just before output.
Oct 14 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-10-15 07:16, deadalnix wrote:

 This is for that very reason that I prefers to work with timestamps UTC
 as much as possible. No timzone hell, no format hell, no nothing. Just
 convert from user input directly, and convert back to text just before
 output.
Agree. Always work with universal standards internally in your applications. Be it time, date, encodings or whatever. Then convert to and from local formats, as early as possible on input and as late as possible for output. -- /Jacob Carlborg
Oct 14 2013
prev sibling parent "Jason King" <jhking airmail.net> writes:
 I get bitten by it locally too: if there's a test with an 
 inaccurate sql query with time formatted as string, the sql 
 server doesn't always compute it, because the default 
 "human-readable" time format is taken from the current locale, 
 and to parse it one first has to guess the format itself, which 
 is quite difficult in a heterogeneous system.
DATE '2013-10-12' is the date October 12th to most SQL parsers. Locales and NLS in SQL have bitten me many times until I learned this.
Oct 18 2013
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 13.10.2013 00:16, schrieb Walter Bright:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


 This isn't a release candidate, in particular the documentation needs
 work, but we need to shake the tree for any undetected regressions.

 Further beta announcements go in the dmd-beta mailing list.

 Note that this release contains:

 29 enhancements
 307 dmd bugs fixed
 14 druntime bugs fixed
 73 phobos bugs fixed
I just upgraded to dmd 2.064 and there are most likely multiple new struct lifetime bugs. I'm going to file them as soon as I find them, but first I have to get the debugger working again. The patch I used for dmd to be able to debug D programs with visual studio no longer works for dmd 2.064.
Oct 14 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 14.10.2013 15:14, schrieb Benjamin Thaut:
 Am 13.10.2013 00:16, schrieb Walter Bright:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED



 This isn't a release candidate, in particular the documentation needs
 work, but we need to shake the tree for any undetected regressions.

 Further beta announcements go in the dmd-beta mailing list.

 Note that this release contains:

 29 enhancements
 307 dmd bugs fixed
 14 druntime bugs fixed
 73 phobos bugs fixed
I just upgraded to dmd 2.064 and there are most likely multiple new struct lifetime bugs. I'm going to file them as soon as I find them, but first I have to get the debugger working again. The patch I used for dmd to be able to debug D programs with visual studio no longer works for dmd 2.064.
I'm also getting random missing symbol linker errors with both dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine. This is really frustrating...
Oct 14 2013
next sibling parent reply "monarch_dodra" <monarchdodra gmail.com> writes:
On Monday, 14 October 2013 at 13:25:23 UTC, Benjamin Thaut wrote:
 I'm also getting random missing symbol linker errors with both 
 dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 
 64-bit windows it works fine.
 This is really frustrating...
I've encountered this too. I'll try to reduce, but the test case isn't easy.
Oct 14 2013
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 14 Oct 2013 23:13:25 +0200
"monarch_dodra" <monarchdodra gmail.com> wrote:

 On Monday, 14 October 2013 at 13:25:23 UTC, Benjamin Thaut wrote:
 I'm also getting random missing symbol linker errors with both 
 dmd 2.063.2 and dmd 2.064. But only on 32-bit windows. On 
 64-bit windows it works fine.
 This is really frustrating...
I've encountered this too. I'll try to reduce, but the test case isn't easy.
I've been bit by a similar (same?) issue. What I didn't realize is that DMD *doesn't* pass the LIB directories (from sc.ini) into optlink. Optlink *itself* reads sc.ini. So if the optlink being run isn't in the same directory as dmd.exe, then optlink may end up grabbing the wrong sc.ini and therefore the wrong Phobos as well. Hence, weird linker errors for Win32. Relevant "issue": http://d.puremagic.com/issues/show_bug.cgi?id=10729
Oct 14 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/14/2013 6:25 AM, Benjamin Thaut wrote:
 I'm also getting random missing symbol linker errors with both dmd 2.063.2 and
 dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine.
 This is really frustrating...
Is it possible you are linking together code compiled with different command line -version or -debug switches?
Oct 14 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 14.10.2013 23:19, schrieb Walter Bright:
 On 10/14/2013 6:25 AM, Benjamin Thaut wrote:
 I'm also getting random missing symbol linker errors with both dmd
 2.063.2 and
 dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine.
 This is really frustrating...
Is it possible you are linking together code compiled with different command line -version or -debug switches?
I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements?
Oct 15 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/15/2013 1:50 AM, Benjamin Thaut wrote:
 Am 14.10.2013 23:19, schrieb Walter Bright:
 On 10/14/2013 6:25 AM, Benjamin Thaut wrote:
 I'm also getting random missing symbol linker errors with both dmd
 2.063.2 and
 dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine.
 This is really frustrating...
Is it possible you are linking together code compiled with different command line -version or -debug switches?
I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements?
dmd now assumes that templates instantiated by a library module are actually in the library. But if code is turned on and off with -version or -debug command line switches, and different switches are used to compile the library than the importer, then the templates instantiations may not be in the library.
Oct 15 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 15.10.2013 11:25, schrieb Walter Bright:
 On 10/15/2013 1:50 AM, Benjamin Thaut wrote:
 Am 14.10.2013 23:19, schrieb Walter Bright:
 On 10/14/2013 6:25 AM, Benjamin Thaut wrote:
 I'm also getting random missing symbol linker errors with both dmd
 2.063.2 and
 dmd 2.064. But only on 32-bit windows. On 64-bit windows it works fine.
 This is really frustrating...
Is it possible you are linking together code compiled with different command line -version or -debug switches?
I dind't change anything on the build setup. And it worked with dmd 2.062. Is there now different mangeling depending on the -version and -debug statements?
dmd now assumes that templates instantiated by a library module are actually in the library. But if code is turned on and off with -version or -debug command line switches, and different switches are used to compile the library than the importer, then the templates instantiations may not be in the library.
The funny thing is, its not a template. Nothing fancy at all. Just a struct with two members. And the linker complains that the __init member of that struct is missing. Error 42: Symbol Undefined _D6thBase6plugin8ScanPair6__initZ Also the library and importer are compiled with exactly the same -debug and -version switches. I did setup a dustmite reduce process but its going to take a few hours for that to complete. Kind Regards Benjamin Thaut
Oct 15 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

 This isn't a release candidate, in particular the documentation 
 needs work, but we need to shake the tree for any undetected 
 regressions.

 Further beta announcements go in the dmd-beta mailing list.

 Note that this release contains:

 29 enhancements
 307 dmd bugs fixed
 14 druntime bugs fixed
 73 phobos bugs fixed
I want to thank you and also especially Kenji who has been crazy fast at fixing the regressions I have encoutered. Now everything work, and several bug I was hitting in 2.063 are fixed. Good job !
Oct 14 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-10-13 00:16, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:
Another one: http://d.puremagic.com/issues/show_bug.cgi?id=11268 -- /Jacob Carlborg
Oct 15 2013
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

 This isn't a release candidate, in particular the documentation 
 needs work, but we need to shake the tree for any undetected 
 regressions.

 Further beta announcements go in the dmd-beta mailing list.

 Note that this release contains:

 29 enhancements
 307 dmd bugs fixed
 14 druntime bugs fixed
 73 phobos bugs fixed
Hum I have several regression is SDC's test suite. I have to investigate more to fix the code or submit bug report. It looks related to AA. What are the changes that affect AA in this new release ?
Oct 16 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 16 October 2013 at 17:41:37 UTC, deadalnix wrote:
 Hum I have several regression is SDC's test suite. I have to 
 investigate more to fix the code or submit bug report. It looks 
 related to AA. What are the changes that affect AA in this new 
 release ?
It turns out that is is a closure bug. Sadly, this involve compiling SDC completely and run it on some test data. I can repro consistently, but it seems really hard to get a small repro. I just moved to the US, and am quite busy especially since the gvt shutdown have complicated things quite a bit. Anyway, It is unlikely that I'll have a redux in the next ~2 weeks. I'm not how we should proceed here, but the bug seems serious to me (the worst kind : everything compile fine, bug the codegen is bogus).
Oct 17 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 18 October 2013 at 04:14:59 UTC, deadalnix wrote:
 On Wednesday, 16 October 2013 at 17:41:37 UTC, deadalnix wrote:
 Hum I have several regression is SDC's test suite. I have to 
 investigate more to fix the code or submit bug report. It 
 looks related to AA. What are the changes that affect AA in 
 this new release ?
It turns out that is is a closure bug. Sadly, this involve compiling SDC completely and run it on some test data. I can repro consistently, but it seems really hard to get a small repro. I just moved to the US, and am quite busy especially since the gvt shutdown have complicated things quite a bit. Anyway, It is unlikely that I'll have a redux in the next ~2 weeks. I'm not how we should proceed here, but the bug seems serious to me (the worst kind : everything compile fine, bug the codegen is bogus).
More detail, and that is getting weird. The bug seem limited to the use of unittest. Anyway, let's do some dustmitting tomorow and hope it goes somewhere. Also, when NOT using the unittest flag, a lot of my code do not compile, symbol _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm is missing. It seems I have 2 bad bugs here.
Oct 17 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/17/2013 11:45 PM, deadalnix wrote:
 Also, when NOT using the unittest flag, a lot of my code do not compile, symbol
 _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm is missing.
See: http://d.puremagic.com/issues/show_bug.cgi?id=11284
Oct 18 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 18 October 2013 at 07:21:47 UTC, Walter Bright wrote:
 On 10/17/2013 11:45 PM, deadalnix wrote:
 Also, when NOT using the unittest flag, a lot of my code do 
 not compile, symbol
 _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm is missing.
See: http://d.puremagic.com/issues/show_bug.cgi?id=11284
I blasted everything from dmd/druntime/phobos and my own project and recompiled everything from master for D projects and then my project is compiled with the new dmd, everything with the same flag. I highly doubt that this fit into cases 1 to 4 as you mention. I'll however double check with that in mind. That also doesn't explain why I get a closure bug (frame pointer or frame content is corrupted) when compiling with unittest. The code that fail isn't even unittested !
Oct 18 2013
next sibling parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.10.2013 09:33, schrieb deadalnix:
 On Friday, 18 October 2013 at 07:21:47 UTC, Walter Bright wrote:
 On 10/17/2013 11:45 PM, deadalnix wrote:
 Also, when NOT using the unittest flag, a lot of my code do not
 compile, symbol
 _D6object15__T7reserveTyaZ7reserveFNaNbNeKAyamZm is missing.
See: http://d.puremagic.com/issues/show_bug.cgi?id=11284
I blasted everything from dmd/druntime/phobos and my own project and recompiled everything from master for D projects and then my project is compiled with the new dmd, everything with the same flag. I highly doubt that this fit into cases 1 to 4 as you mention. I'll however double check with that in mind. That also doesn't explain why I get a closure bug (frame pointer or frame content is corrupted) when compiling with unittest. The code that fail isn't even unittested !
I have a similar issue than yours. The symbol that is missing for me is not even contained within any version or debug block. See: http://d.puremagic.com/issues/show_bug.cgi?id=11280 Kind Regards Benjamin Thaut
Oct 18 2013
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/18/2013 12:33 AM, deadalnix wrote:
 I highly doubt that this fit into cases 1 to 4 as you mention. I'll however
 double check with that in mind.
I want to know about any other cases, so please investigate.
 That also doesn't explain why I get a closure bug (frame pointer or frame
 content is corrupted) when compiling with unittest. The code that fail isn't
 even unittested !
Right, that sounds like some thing else.
Oct 18 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Beta 3:

http://ftp.digitalmars.com/dmd.2.064.beta.3.zip
Oct 23 2013
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 24 October 2013 02:29, Walter Bright <newshound2 digitalmars.com> wrote:
 Beta 3:

 http://ftp.digitalmars.com/dmd.2.064.beta.3.zip
I suppose I better start opening a branch in gdc for the new release.... -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 23 2013
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 24 October 2013 07:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 On 24 October 2013 02:29, Walter Bright <newshound2 digitalmars.com> wrote:
 Beta 3:

 http://ftp.digitalmars.com/dmd.2.064.beta.3.zip
I suppose I better start opening a branch in gdc for the new release....
Noticed this in meld, the readme.txt file is different in the beta zip for the frontend. Don't know how you managed it... https://github.com/D-Programming-Language/dmd/blob/master/src/readme.txt -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Oct 24 2013
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:
It is a specific reason why this is kept?: http://forum.dlang.org/thread/ohduisigpwdiqhpdewdz forum.dlang.org#post-btwbpwgluzyxmhphwebp:40forum.dlang.org
Oct 25 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/25/2013 6:15 AM, eles wrote:
 It is a specific reason why this is kept?:

 http://forum.dlang.org/thread/ohduisigpwdiqhpdewdz forum.dlang.org#post-btwbpwgluzyxmhphwebp:40forum.dlang.org
Breaking peoples' build scripts and makefiles is not nice :-)
Oct 25 2013
parent reply "eles" <eles eles.com> writes:
On Friday, 25 October 2013 at 20:24:48 UTC, Walter Bright wrote:
 On 10/25/2013 6:15 AM, eles wrote:
 Breaking peoples' build scripts and makefiles is not nice :-)
On the same grounds, you could recommend them dmc. Provide, at least, a flag that passes the file without name change, for example: dmd -ntest will really pass "test" file and not test.d. Why working so hard to do a good language if you work even harder to provide the worst of tooling?
Oct 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/26/2013 12:42 AM, eles wrote:
 Provide, at least, a flag that passes the file without name change, for
example:

 dmd -ntest

 will really pass "test" file and not test.d.
I'm curious why naming the file test.d is an issue?
Oct 26 2013
parent reply "eles" <eles eles.com> writes:
On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote:
 On 10/26/2013 12:42 AM, eles wrote:

 I'm curious why naming the file test.d is an issue?
Case: This forces scrpts to bear the .d extension. For example, if you write a script on Linux named "git-test" and you put at the top: #!rdmd rdmd will pass its name to dmd, and dmd will try to compile... "git-test.d", which does not exist. Now, you have either to rename the "git-test" into "git-test.d", or to create a hardlink named "git-test.d" that points towards "git-test" so that dmd finally gets satisfied its ".d" hungriness. The solution with the hardlink carries the well-known burdness of redundancy, let's not even say its idiot and makes back-up-ing a mess. OTOH, renaming the original script into "git-test.d" has the undesirable effect wrt to git software. git uses some nice convention that you can extend its command list by writing your own "git-command1", "git-command2" scripts and they are invoked automatically by git when you type: "git command1" (this will invoke "git-command1") etc. The problem with being forced to rename "git-command1" into "git-command1.d" is that, afterwards, you have to type the following command for git: "git command1.d" (in order to have the "git-command1.d" invoked, as "git-command1" simply does not exist or, if it would exist, dmd would be blind about it). SO, you cannot type "git command1" and to have a "git-command1" script invoked, because git won't search for "git-command1.d", while dmd won't compile "git-command1". So you need both "git-command1" and "git-command1.d" doing the same thing, just to be able to type "git command1" (not even say that this allows you to invoke, also "git comman1.d", which is ugly and undesired redundancy). Now, immagine yourself having to type: "git checkout.d ." "git commit.d" "git log.d" instead of "git checkout ." "git commit" "git log" and tell me that ".d" is not an issue. Please have a look at the original thread that I linked and you'll see the problem. What use for scripting in D if I am unable to do some simple scripts because of the compiler?
Oct 26 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/26/2013 2:02 AM, eles wrote:
 On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote:
 I'm curious why naming the file test.d is an issue?
Case:
Thanks for the clear explanation. It makes a lot of sense. Let me think about it for a bit.
Oct 26 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/26/2013 2:02 AM, eles wrote:
 On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright wrote:
 On 10/26/2013 12:42 AM, eles wrote:

 I'm curious why naming the file test.d is an issue?
Case:
http://d.puremagic.com/issues/show_bug.cgi?id=11365
Oct 26 2013
parent reply "eles" <eles eles.com> writes:
On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright wrote:
 On 10/26/2013 2:02 AM, eles wrote:
 On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright 
 wrote:
 On 10/26/2013 12:42 AM, eles wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=11365
Thank you for considering it.
Oct 26 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote:
 On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright 
 wrote:
 On 10/26/2013 2:02 AM, eles wrote:
 On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright 
 wrote:
 On 10/26/2013 12:42 AM, eles wrote:
Thank you for considering it.
I cannot comment on the bugzilla, but frankly I do not like those comments at all. Why cannot I name my scripts like: script.no1 script.no2 script.no3 ? Must always use script_no1 or script_no1.d? What is this conservationism? You have a very nice way to cut a programmer's arms and legs and then yell at him why he does not run or swim faster. Just let the poor guy name the scripts how he really likes it. Speaking about that, why DMD's source files are written in C++ but bear extension .c? You seem to appreciate for yourselves a freedom that he denies to others.
Oct 31 2013
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:16:22 UTC, eles wrote:
 On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote:
 On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright 
 wrote:
 On 10/26/2013 2:02 AM, eles wrote:
 On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright 
 wrote:
 On 10/26/2013 12:42 AM, eles wrote:
 You seem to appreciate for yourselves a freedom that he denies 
 to others.
And +1 for Leandro. The day that D was declared to serve some useful purpose is the day when D gave up the right to be just a toy. Hey! I work in production! Somebody hears that?
Oct 31 2013
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
eles:

 Speaking about that, why DMD's source files are written in C++ 
 but bear extension .c?

 You seem to appreciate for yourselves a freedom that he denies 
 to others.
Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those ".c" extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages. Bye, bearophile
Oct 31 2013
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote:
 eles:

 Thank you for bringing that good example. Forbidding arbitrary 
 extensions for D code, and enforcing a common standard name 
 helps avoid mistakes like those ".c" extensions in the C++ 
 sources, that numerous persons keep criticizing. The advantages 
 of a standard suffix for D code are way larger than the 
 disadvantages.
In projects, not in scripts. C/C++ not used for scripts.
Oct 31 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote:
 eles:
 Bye,
 bearophile
Well, then allow just extension .d or NO EXTENSION, but consider files named like: script.no1 script.julia script.no5 just as being standard names without any extension (you may see for yourself that there is no extension since they lack the final .d). D is a wonderful language for which creators try hard to make the worst of tools.
Oct 31 2013
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
File content should have nothing to do with extension, it is as 
good part of name as any other. Adding any extra meaning to it is 
just some DOS legacy.
Oct 31 2013
parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:45:46 UTC, Dicebot wrote:
 File content should have nothing to do with extension, it is as 
 good part of name as any other. Adding any extra meaning to it 
 is just some DOS legacy.
When I first came to Linux I was wondering how the OS knows it should execute some file that wasn't bearing the .exe/.com extensions. "And who tells the OS this is an executable file? How could Linux know it without the .exe or .com at the end?" Well, I was DOSwashed.
Oct 31 2013
prev sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:20:54 UTC, bearophile wrote:
 eles:

 Speaking about that, why DMD's source files are written in C++ 
 but bear extension .c?

 You seem to appreciate for yourselves a freedom that he denies 
 to others.
Thank you for bringing that good example. Forbidding arbitrary extensions for D code, and enforcing a common standard name helps avoid mistakes like those ".c" extensions in the C++ sources, that numerous persons keep criticizing. The advantages of a standard suffix for D code are way larger than the disadvantages.
A computer doesn't mind if its programs are put to purposes that don't match their names. -- D. Knuth Well, then God created humans...
Dec 10 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:16:22 UTC, eles wrote:
 On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote:
 On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright 
 wrote:
 On 10/26/2013 2:02 AM, eles wrote:
 On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright 
 wrote:
 On 10/26/2013 12:42 AM, eles wrote:
Thank you for considering it.
I cannot comment on the bugzilla, but frankly I do not like those comments at all. Why cannot I name my scripts like: script.no1 script.no2 script.no3 ? Must always use script_no1 or script_no1.d?
And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious. I am bitter about this.
Oct 31 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
 Must always use script_no1 or script_no1.d?
And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious.
sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. "My boss is right: is just a toy pretending to be serious" - maybe, maybe not - but not because of your stupid file extension comments thx
Oct 31 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring 
wrote:
 3. "My boss is right: is just a toy pretending to be serious" - 
 maybe, maybe not - but not because of your stupid file 
 extension comments
It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me.
Oct 31 2013
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be serious" -
 maybe, maybe not - but not because of your stupid file
 extension comments
It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me.
question: why are you using D if 1. Python works for you 2. Python doesnt suffer from the BIG-BIG file-extension problem 3. your laughing Boss tells you D is a toy i don't get it better try to find a more experienced, serious Boss
Oct 31 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring 
wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be serious"
better try to find a more experienced, serious Boss
Do you offer yourself for his job? Maybe because I don't want to have a code base written in several languages? And seriously, about your former argument about the importance of the extension in being serious or not: accepting arbitrary extension was the reason for C++ doom? Seriously, I never hear somebody citing that the purpose why D exists is to correct the C++... file extension problem. I hear about a lot other reasons, but not this one.
Oct 31 2013
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be serious"
better try to find a more experienced, serious Boss
Do you offer yourself for his job? Maybe because I don't want to have a code base written in several languages? And seriously, about your former argument about the importance of the extension in being serious or not: accepting arbitrary extension was the reason for C++ doom?
just 0,001% of it - but a clear definition is always bettern then a floaty like "you should use .d as extension"
Oct 31 2013
prev sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be serious"
better try to find a more experienced, serious Boss
Do you offer yourself for his job?
why should i?
Oct 31 2013
parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring 
wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be 
 serious"
better try to find a more experienced, serious Boss
Do you offer yourself for his job?
why should i?
Then don't tell me what I should feel to do about my job. 'Cause you don't deserve other answer than "why should I"?
Oct 31 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.10.2013 16:01, schrieb eles:
 On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be
 serious"
better try to find a more experienced, serious Boss
Do you offer yourself for his job?
why should i?
Then don't tell me what I should feel to do about my job. 'Cause you don't deserve other answer than "why should I"?
i don't see any chance/strategy to get D in your current development - so if you don't want to code Python ("I WANT pointers") anymore - try to find a job where you can write C/C++ or D - or else your need (and real hard interest to get your Boss in the Boart) for D seems to be not big enough - i would quit my job very fast if someone forces me to write Python code most of the time - thats all
Oct 31 2013
parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring 
wrote:
 Am 31.10.2013 16:01, schrieb eles:
 On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis 
 luehring
i don't see any chance/strategy to get D in your current development - so if you don't want to code Python ("I WANT pointers") anymore - try to find a job where you can write C/C++ or D - or else your need (and real hard interest to get your Boss in the Boart) for D seems to be not big enough - i would quit my job very fast if someone forces me to write Python code most of the time - thats all
Frankly, just stop advising me to take a new job. It is the kind of advice that I really find intrusive and unbearable. I do critical software and is 90% C. Is for embedded devices that are great chances that you already used. I use Python for py.test because it is the company policy and tradition, but I am not forced to like Python. Let's keep the discussion in the terms of languages, not personal problems. I would never allow myself to tell you what you should do with your car, house, job or life. BTW, my boss is very kind and nice, but he is concerned about how the tools would increase productivity. It is he who is responsible for the budget in front of, guess it, his boss. Otherwise, no, I would simply quit D instead of my job. And this neither, I don't want to do it. Please, stop advising me in matters that I consider should remain of my personal competence.
Oct 31 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.10.2013 16:22, schrieb eles:
 On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring
 wrote:
 Am 31.10.2013 16:01, schrieb eles:
 On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis
 luehring
i don't see any chance/strategy to get D in your current development - so if you don't want to code Python ("I WANT pointers") anymore - try to find a job where you can write C/C++ or D - or else your need (and real hard interest to get your Boss in the Boart) for D seems to be not big enough - i would quit my job very fast if someone forces me to write Python code most of the time - thats all
Frankly, just stop advising me to take a new job. It is the kind of advice that I really find intrusive and unbearable.
no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen?
Oct 31 2013
parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring 
wrote:
 Am 31.10.2013 16:22, schrieb eles:
 On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring
 wrote:
 Am 31.10.2013 16:01, schrieb eles:
 On Thursday, 31 October 2013 at 14:57:15 UTC, dennis luehring
 wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis
 luehring
no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen?
He won't really care as long as I don't ask him to modify his scripts to update the names of those used by me. The latter are already hard-coded in his and others. Yes, this has a solution: use of hardlinks (of identical-content, different name files). I already explained and acknowledged that in the very first post. But is cumbersome and unpleasant and bad for backup-ing.
Oct 31 2013
parent reply "Frustrated" <c1514843 drdrb.com> writes:
On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote:
 On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring 
 wrote:
 Am 31.10.2013 16:22, schrieb eles:
 On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring
 wrote:
 Am 31.10.2013 16:01, schrieb eles:
 On Thursday, 31 October 2013 at 14:57:15 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis
 luehring
no problem :) so tell the story what would happen if D scripts will be without .d? is your Boss then more interested or can you introduce D-scripts then silently - what would happen?
He won't really care as long as I don't ask him to modify his scripts to update the names of those used by me. The latter are already hard-coded in his and others. Yes, this has a solution: use of hardlinks (of identical-content, different name files). I already explained and acknowledged that in the very first post. But is cumbersome and unpleasant and bad for backup-ing.
Why not simply rename .d to . then compile, rename back using a script? It might add a few extra seconds for very large projects but otherwise insignificant and should work most of the time. Basically you'll use the script or wrapper app instead of whatever compile you are using.
Dec 10 2013
parent reply "eles" <eles eles.com> writes:
On Tuesday, 10 December 2013 at 09:44:38 UTC, Frustrated wrote:
 On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote:
 On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring 
 wrote:
 Am 31.10.2013 16:22, schrieb eles:
 On Thursday, 31 October 2013 at 15:13:20 UTC, dennis luehring
 wrote:
 Am 31.10.2013 16:01, schrieb eles:
 On Thursday, 31 October 2013 at 14:57:15 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis
 luehring
 Why not simply rename .d to . then compile, rename back using a 
 script? It might add a few extra seconds for very large 
 projects but otherwise insignificant and should work most of 
 the time.

 Basically you'll use the script or wrapper app instead of 
 whatever compile you are using.
You are overreacting to a maybe bad joke, but I must say that I really love the solution you propose. Is even better than the one with hardlinks. The only thing that I don't have yet is a third hand to keep the window open while my fifth foot is doing some tricks with the a crow's nest. This would be quite a workable workaround, don't you think?
Dec 10 2013
parent "eles" <eles eles.com> writes:
On Tuesday, 10 December 2013 at 10:10:09 UTC, eles wrote:
 On Tuesday, 10 December 2013 at 09:44:38 UTC, Frustrated wrote:
 On Thursday, 31 October 2013 at 15:39:27 UTC, eles wrote:
 On Thursday, 31 October 2013 at 15:34:37 UTC, dennis luehring 
 wrote:
 Am 31.10.2013 16:22, schrieb eles:
 On Thursday, 31 October 2013 at 15:13:20 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 16:01, schrieb eles:
 On Thursday, 31 October 2013 at 14:57:15 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 15:45, schrieb eles:
 On Thursday, 31 October 2013 at 14:39:34 UTC, dennis 
 luehring
 wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis
 luehring
 The only thing that I don't have yet is a third hand to keep 
 the window open while my fifth foot is doing some tricks with 
 the a crow's nest.
I mean, all that to entertain the compiler and keep it happy :)
Dec 10 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring
wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be serious"
i don't get it
You never wrote git extension scripts, isn't? Then write and you will get it.
Oct 31 2013
prev sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:39:34 UTC, dennis luehring 
wrote:
 Am 31.10.2013 15:29, schrieb eles:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
 wrote:
 3. "My boss is right: is just a toy pretending to be serious" 
 -
 maybe, maybe not - but not because of your stupid file
 extension comments
It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me.
question: why are you using D if
OH, I forgot to add: I HAAAAAAAAAAATE PYTHON. I do not care if it works. Assembler works! I hate it! I like D (the language, not the compiler ;). I *want* to use D. Why don't *you* use ASM? Go and write in machine code! IT WORKS!
Oct 31 2013
prev sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring 
 wrote:
 3. "My boss is right: is just a toy pretending to be serious" 
 - maybe, maybe not - but not because of your stupid file 
 extension comments
It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me.
In my experience, when it comes to software development, bosses tend to have no clue what they are talking about anyway :o) So I would just laugh back at him/her (might keep that to myself though, depending on how secure I feel my job is). This seems like a bit of bikeshedding issue. You may have a strong preference for one option, apparently others feel differently. Is it really that big an issue? I don't think the quality of a language depends on its file naming conventions. I don't like the way Python uses whitespace .. but I still like the language. I agree the compiler shouldn't be adding anything to the supplied names, however if I understand the issue I see no real problem with requiring that D source files/scripts end with a .d extension. Finally, you've said a few times that D has crappy tooling. I am not sure how this file naming stuff has anything to do with that (other than superficial ways).
Oct 31 2013
next sibling parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh
wrote:
clip
 This seems like a bit of bikeshedding issue.  You may have a
 strong preference for one option, apparently others feel
 differently.  Is it really that big an issue?  I don't think the
 quality of a language depends on its file naming conventions.  I
 don't like the way Python uses whitespace .. but I still like 
 the
 language.
clip
 Finally, you've said a few times that D has crappy tooling.  I 
 am
 not sure how this file naming stuff has anything to do with that
 (other than superficial ways).
eles, seeing your post above, I guess my use of Python to justify my answer turns out to a bad choice on my part :o)
Oct 31 2013
parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:57:43 UTC, Craig Dillabaugh 
wrote:
 On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh
 eles, seeing your post above, I guess my use of Python to 
 justify
 my answer turns out to a bad choice on my part :o)
That's true. I hate using it, especially because I am still force to use it when writing tests because of its py.test module. I simply don't like it. I want pointers in my code.
Oct 31 2013
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh 
wrote:
 On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote:
 On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring 
 wrote:
Finally, you've said a few times that D has crappy tooling. I am not sure how this file naming stuff has anything to do with that (other than superficial ways).
Go to that bug report, read the very first message that Walter used to open the bug report, see about yourself, then come back here and tell me that the .d thing does not matter. It is the *very* reason for this debate. As to quote Walter's own understanding of the problem (unfortunately, the solution he proposed is bad): "Thanks for the clear explanation. It makes a lot of sense.". Now, if you disagree with that, you disagree with Walter.
Oct 31 2013
parent reply "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote:
 On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh 
 wrote:

 Go to that bug report, read the very first message that Walter 
 used to open the bug report, see about yourself, then come back 
 here and tell me that the .d thing does not matter.

 It is the *very* reason for this debate.

 As to quote Walter's own understanding of the problem 
 (unfortunately, the solution he proposed is bad):

 "Thanks for the clear explanation. It makes a lot of sense.".

 Now, if you disagree with that, you disagree with Walter.
I read the bug report, and the ensuing comments. It just seems that some people involved don't agree, but opinion appears to be split. Having Walter apparently on your side can't hurt though. I can see why you like having the ability to process an arbitrarily named file as a D source file, but some of the counter-arguments have some merit. Furthermore, reading the Bugzilla entry, it seems there as many who support your idea as those who disagree. I could also argue that this issue is a with git requiring a 'git-' suffix on its scripts without providing users with some means of overriding the file naming convention (maybe this is already possible, I have only minimal git experience)! Really, I can see why you want the suggested change, I am just surprised at the level of importance you seem to be ascribing to it.
Oct 31 2013
next sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh 
wrote:
 On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote:
 On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh
Really, I can see why you want the suggested change, I am just surprised at the level of importance you seem to be ascribing to it.
Maybe because it is a real problem? Usually, those who take such matters lightly never really encounter them. And it is easy to give advice about somebody's else teeth ache. You know, the usual: "c'mon, you scream too hard, it *cannot* hurt that much". Well, this is true, it does not hurt anyone, except the one who really has his teeth broken. But the others are quite insensitive to it. That's the story about the .d suffix.
Oct 31 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh 
wrote:
 On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote:
 On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh 
 wrote:
Furthermore, reading the Bugzilla entry, it seems there as many who support your idea as those who disagree.
If you are sick about to die in an hospital, would you like the medical treatment for you to be established through a majority vote involving the whole city population, or on the professional doctors that *really know* what your health problem is about? Just ask the question: "how many of you expressing advice did you really encounter this problem and felt about it?" It is so easy to offer advice about things that do not really hurt you, but only others.
Oct 31 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh 
wrote:
 On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote:
 On Thursday, 31 October 2013 at 14:54:17 UTC, Craig Dillabaugh 
 wrote:
I could also argue that this issue is a with git requiring a 'git-' suffix on its scripts without providing users with some means of overriding the file naming convention (maybe this is already possible, I have only minimal git experience)!
BTW, git is not requiring a git- suffix, but a git-prefix. It does not matter for git what the git-<name here> script extension (or name) use. It matters to the one typing git commands, because he has to type: git <name here> in order for git to invoke git-<name here> behind. I really don't feel like git is doing anything bad here or it should change. It matters, however, if one is allowed to type: "git tellmethelotterynumbers" instead of being forced to type "git tellmethelotterynumbers.d" You see, the latter version will give you the numbers spelled as: 16.d, 32.d, 18.d, 5.d, 11.d and 22.d Or, it happens, the state lottery won't deny you the prize because, guess, the real numbers that were extracted were 16, 32, 18, 5, 11 and 22.
Oct 31 2013
parent "eles" <eles eles.com> writes:
On Thursday, 31 October 2013 at 16:12:44 UTC, eles wrote:
 On Thursday, 31 October 2013 at 15:22:41 UTC, Craig Dillabaugh 
 wrote:
 On Thursday, 31 October 2013 at 14:58:33 UTC, eles wrote:
 On Thursday, 31 October 2013 at 14:54:17 UTC, Craig 
 Dillabaugh wrote:
Or, it happens, the state lottery won't deny you the prize
*will :P
Oct 31 2013
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
Craig Dillabaugh, el 31 de October a las 15:54 me escribiste:
 On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote:
On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
wrote:
3. "My boss is right: is just a toy pretending to be serious" -
maybe, maybe not - but not because of your stupid file extension
comments
It adds. Tell to my boss about that extensions and he will be grateful for you providing him ONE MORE REASON to laugh. At me.
In my experience, when it comes to software development, bosses tend to have no clue what they are talking about anyway :o) So I would just laugh back at him/her (might keep that to myself though, depending on how secure I feel my job is). This seems like a bit of bikeshedding issue.
It isn't bikeshedding at all, is a functional problem, is key to understand that before you keep discussing the issue :) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Es erróneo pensar que el repollo es una afirmación de personalidad del volátil, es una verdura, es una verdura. -- Ricardo Vaporeso
Oct 31 2013
parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
On Thursday, 31 October 2013 at 17:09:09 UTC, Leandro Lucarella
wrote:
 Craig Dillabaugh, el 31 de October a las 15:54 me escribiste:
 On Thursday, 31 October 2013 at 14:29:34 UTC, eles wrote:
On Thursday, 31 October 2013 at 14:28:05 UTC, dennis luehring
wrote:
This seems like a bit of bikeshedding issue.
It isn't bikeshedding at all, is a functional problem, is key to understand that before you keep discussing the issue :)
Since when has understanding an issue been a requirement for discussing it? As evidence I point you to the comments section on just about any major news site :) I think I understand the implications of the current requirement that d source files end with .d. However there are some workarounds that, while certainly a pain, can be applied. Also, some commentators had valid reasons to keep that status quo. I can see systems full of files with .py extensions that are actually D files and with .rb files that are actually c++ files and so forth being a bit of a maintenance nightmare for the person that replaces you (like when you quit your job because the made you code in Python). My reason for posting originally was not so much that I didn't like the request, but simply to point out that whether D is a serious language, or a toy language, doesn't really hinge on this issue. All sorts of serious programming environments/tools have 'features' that may certain workflows a pain. By the way, I like your proposed solution.
Nov 01 2013
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
dennis luehring, el 31 de October a las 15:28 me escribiste:
Must always use script_no1 or script_no1.d?
And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious.
sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. "My boss is right: is just a toy pretending to be serious" - maybe, maybe not - but not because of your stupid file extension comments
I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- Hey you, don't tell me there's no hope at all Together we stand, divided we fall.
Oct 31 2013
parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 31.10.2013 17:44, schrieb Leandro Lucarella:
 dennis luehring, el 31 de October a las 15:28 me escribiste:
Must always use script_no1 or script_no1.d?
And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious.
sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. "My boss is right: is just a toy pretending to be serious" - maybe, maybe not - but not because of your stupid file extension comments
I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging.
sorry for my wording - but pressure sentence like "My boss is right: is just a toy pretending to be serious" aren't fair also
Oct 31 2013
parent Leandro Lucarella <luca llucax.com.ar> writes:
dennis luehring, el 31 de October a las 18:25 me escribiste:
 Am 31.10.2013 17:44, schrieb Leandro Lucarella:
dennis luehring, el 31 de October a las 15:28 me escribiste:
Must always use script_no1 or script_no1.d?
And maybe one day I have a lot of .py files that I intend to replace with D scripts TRANSPARENTLY for their user. Will D bow at me why I use the .py extension? Is D trying to shoot his own foot? It really seems to succeed quite well. My boss is right: is just a toy pretending to be serious.
sorry, but this is a very stupid comment: 1. never ever was a language successful(or not) because of its file-extension behavior - maybe in your world 2. i hope there is no other tool around try to find/analyse/whatever real Python programs by using the extension - else you need to change that anyway 3. "My boss is right: is just a toy pretending to be serious" - maybe, maybe not - but not because of your stupid file extension comments
I think even when the wording isn't the best, what he says is true. Sometimes is hard to sell the language when things that are so trivial and fundamental (as letting file names have arbitrary names, at least for scripts) not only are broken, but are justified by the community. That's definitely not serious and discouraging.
sorry for my wording - but pressure sentence like "My boss is right: is just a toy pretending to be serious" aren't fair also
Let's see if this makes both sides happy: https://github.com/D-Programming-Language/dmd/pull/2700 (I still don't see any reason to enforce any extension, ever, but this at least fixes the more pressing issue, hopefully with less resistance) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- UNA ARTISTA HACE JABONES CON SU PROPIA GRASA LUEGO DE UNA LIPOSUCCION -- Crónica TV
Oct 31 2013
prev sibling parent "eles" <eles eles.com> writes:
On Saturday, 26 October 2013 at 22:35:14 UTC, eles wrote:
 On Saturday, 26 October 2013 at 21:11:02 UTC, Walter Bright 
 wrote:
 On 10/26/2013 2:02 AM, eles wrote:
 On Saturday, 26 October 2013 at 08:36:53 UTC, Walter Bright 
 wrote:
 On 10/26/2013 12:42 AM, eles wrote:
http://d.puremagic.com/issues/show_bug.cgi?id=11365
Thank you for considering it.
I am amazed how such a simple issue is provoking unbelievable philosophic discussion attempting to find the best way to bite your own tail while running circles around a tree.
Oct 31 2013
prev sibling parent reply "eles" <eles eles.com> writes:
On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
And the famous int[$] x = [1,2,3]; to declare static arrays and force the compiler to compute the length?
Oct 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 25 October 2013 at 13:24:12 UTC, eles wrote:
 On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright 
 wrote:
 http://ftp.digitalmars.com/dmd2beta.zip

 Current list of regressions:

 http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
And the famous int[$] x = [1,2,3]; to declare static arrays and force the compiler to compute the length?
When was decided to add this? I would love it, but I cannot remember that this was decided.
Oct 25 2013
parent "eles" <eles eles.com> writes:
On Friday, 25 October 2013 at 15:57:27 UTC, Namespace wrote:
 On Friday, 25 October 2013 at 13:24:12 UTC, eles wrote:
 On Saturday, 12 October 2013 at 22:16:13 UTC, Walter Bright
When was decided to add this? I would love it, but I cannot remember that this was decided.
Well, like many other ideas of its kind, Walter expressed "sympathy" for it, then fall into oblivion... Unfortunately, D puts a lot of effort in doing great things, but all the nice nuts and bolts that would make our life easire and require no more than one LOC change in dmd's source tend to be forgotten. Somebody complained about lack of vision in D development. Don't be upset on me, but I really feel the same. "People come, tried to do things... and left".
Oct 26 2013