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.



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.



 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)

this criticism, since I changed our code over within minutes of the new
syntax being made available :)




 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)

 this criticism, since I changed our code over within minutes of the new
 syntax being made available :)



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

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 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