Walter Bright, el  1 de January a las 15:46 me escribiste:
> The big news is Win64 is now supported (in alpha).
> 
> http://www.digitalmars.com/d/download.html
> 
> D 1.076 changelog: http://www.digitalmars.com/d/1.0/changelog.html

BTW, Changelogs looks extremely naked now, I think release notes are really needed now. Al least for new features. Is far from ideal to make people go through a bug report to know how they can adapt their code to new features.

And sometimes bug reports are not updated on how things turned out, for example #7041[1], a feature I implemented myself. The bug report is outdated AFAIK, the title talks about a -di flags which doesn't even exist, you actually have to go through the pull request[2] to see what the hell is going on. And even then the behaviour of that pull request was changed in a subsequent one[3], and there are no visible links between those 2 pull requests.

So, unless you are a private investigator, you will have a very hard time to know that what really happened is that now DMD show deprecations as a warning message (compilation is not halted anymore) by default, and there are 2 new compiler flags, -de (to get the old default behaviour to make deprecation to be errors) and -dw, to explicitly enable the new default behaviour (make them warnings) in case you changed it in a config file and want to override it in the command line (so people wanting the old behaviour by default can put -de in the dmd.conf file and they can still override that default by using -dw when compiling).

The -d flag stay the same (silently ignore any deprecated feature or
symbol).

Anyway, at least for this particular change, the changelog is basically useless, and I don't think the bug report is the right place to inform users about compiler changes. Users don't care about the history and discussion around a change, they just only want to know how to take advantage of new features and how to fix their code (possibly with some exceptions of course, in which case they can still go back to the bug report and pull requests).

Glad that the long waited new release is out, though, and the release process is still improving :)

Happy new year to everyone!

[1] http://d.puremagic.com/issues/show_bug.cgi?id=7041
[2] https://github.com/D-Programming-Language/dmd/pull/1185
[3] https://github.com/D-Programming-Language/dmd/pull/1287

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

On 13-01-03 3:11 PM, Philippe Sigaud wrote:
>
>
> On Thu, Jan 3, 2013 at 9:00 PM, David Nadlinger <see@klickverbot.at
> <mailto:see@klickverbot.at>> wrote:
>
>     On Thursday, 3 January 2013 at 19:36:31 UTC, Jonathan M Davis wrote:
>
>         In fact, I think that _every_ item in Phobos' changelog.d was
>         lost. That information needs to be presented to users.
>
>
>     Agreed – while it is great to finally see the manually maintained
>     list of fixed bugs being replaced with a Bugzilla query, there will
>     always be reasons for well-curated release notes to exist: they are
>     invaluable for discussing high-level changes, drawing attention to
>     (future) breaking changes, …
>
>
> For example, UDA... They seem interesting, but I don't remember all the
> discussions and now that the dust settled somewhat, I'd like to know
> what's the syntax, how they are inspected.
>
> I used the link Walter (http://dlang.org/changelog.html) provided and
> all I could find is http://d.puremagic.com/issues/show_bug.cgi?id=9222
>

FWIW, you can see some info here: http://forum.dlang.org/thread/k7afq6$2832$1@digitalmars.com

> That's a bit short... How can someone coming to D today know this
> language has user-defined attributes?
>

But, yes, I agree, someone (like me) that has been watching D for long time, used it a very little, read the books but never actually had the time to use it (for all sorts of reasons), will find that the best way is to read the newsgroup and invest quite a bit of time.

I would say, the best thing would be to implement release notes similar to the way the Python project does it would be great.  I have been using Python for a while and I find their documentation and processes awesome.

Is there something similar for D?

/Pierre

On 3 January 2013 20:27, Leandro Lucarella <luca@llucax.com.ar> wrote:

> Walter Bright, el  1 de January a las 15:46 me escribiste:
> > The big news is Win64 is now supported (in alpha).
> >
> > http://www.digitalmars.com/d/download.html
> >
> > D 1.076 changelog: http://www.digitalmars.com/d/1.0/changelog.html
>
> BTW, Changelogs looks extremely naked now, I think release notes are really needed now. Al least for new features. Is far from ideal to make people go through a bug report to know how they can adapt their code to new features.
>

Each new language feature should have a corresponding link to http://dlang.org/language-reference.html



-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 01/03/2013 10:49 AM, Walter Bright wrote:
> On 1/3/2013 10:11 AM, Ali Çehreli wrote:
>> On 01/01/2013 03:46 PM, Walter Bright wrote:
>>
>> > 1. the dlang.org isn't updated yet.
>>
>> Is the change log available somewhere else? I want to spread the news
>> but it is
>> not very interesting without knowing what has changed. :)
>
> http://dlang.org/changelog.html

That's what I have been looking at. The top of the page was saying 2.060 and had the changelist for 2.060.

The problem is solved for me only after I told my browser to refresh that page. :-/

Ali

On Thursday, 3 January 2013 at 18:36:32 UTC, Jonathan M Davis wrote:
> On Thursday, January 03, 2013 17:59:22 deadalnix wrote:
>> On Thursday, 3 January 2013 at 16:43:06 UTC, bearophile wrote:
>> > deadalnix:
>> >> I still have code broken all over the place.
>> > 
>> > D2 is getting its corner case problems sorted out and fixed,
>> > but this still causes some breakage in user code. As more
>> > people use D2, issues are found, discussed and fixed, the
>> > breakages will get more and more uncommon.
>> 
>> Is this breakage intended ? To me it doesn't make sense, the
>> generated code is :
>> 
>> (Bar bar = Bar.init; , bar).this()
>
> It is most definitely intended. ref requires an lvalue. A struct literal is a
> temporary and therefore should be an rvalue, not an lvalue.
>

struct Bar {
	uint i;

	this(uint foo) {
		import std.stdio;
		writeln(&this);
	}
}

void main() {
	Bar(0);
}

> Before, you had the stupid situation of
>
> foo(Bar()); //compiles
> foo(funcWhichReturnsBar()); //fails to compile
>
> Both are dealing with temporaries, so both should be rvalues, and neither
> should compile. You need an actual variable or other non-temporary memory
> location (e.g. dereferenced pointer) if you want to pass an argument to a ref
> function. The previous behavior was broken and should have been fixed ages ago.
>
> - Jonathan M Davis

The compiler actually create this storage to pass it to the constructor. Why can't it pass it to something else ?

Iain Buclaw, el  3 de January a las 21:48 me escribiste:
> On 3 January 2013 20:27, Leandro Lucarella <luca@llucax.com.ar> wrote:
> 
> > Walter Bright, el  1 de January a las 15:46 me escribiste:
> > > The big news is Win64 is now supported (in alpha).
> > >
> > > http://www.digitalmars.com/d/download.html
> > >
> > > D 1.076 changelog: http://www.digitalmars.com/d/1.0/changelog.html
> >
> > BTW, Changelogs looks extremely naked now, I think release notes are really needed now. Al least for new features. Is far from ideal to make people go through a bug report to know how they can adapt their code to new features.
> >
> 
> Each new language feature should have a corresponding link to http://dlang.org/language-reference.html

Where? In the bug report? If so, I think it is extremely odd and user unfriendly. If is in the releases notes, perfect, but even then I think it would be nice to include a short summary of the new feature, not just a link (someone else mentioned Python release notes and I agree that Python is an excellent example of how I, as an user, would like to see it in D too).

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
A veces quisiera ser un auto,
para chocar como choco siendo humano,
para romperme en mil pedazos.

On Tuesday, 1 January 2013 at 23:46:32 UTC, Walter Bright wrote:
> The big news is Win64 is now supported (in alpha).
>
> http://www.digitalmars.com/d/download.html
>
> D 1.076 changelog: http://www.digitalmars.com/d/1.0/changelog.html
>
> A couple issues:
>
> 1. the dlang.org isn't updated yet.
> 2. the OS X package hasn't been built yet (problems with the package script).
>
> I hope to get these resolved shortly. In the meantime, enjoy and have a Happy D Year!

Ran into some trouble to make it work, but awesome news : the GC collecting live stuff problem is gone (most likely a closure bug rather than a GC bug).

That is awesome !

On 1/3/2013 11:17 AM, Andrei Alexandrescu wrote:
> Andrei "I don't yet run my own SMTP and IMAP server" Alexandrescu

Sheesh. How can you ever hold your head up again after that admission?

On 1/3/2013 11:36 AM, Jonathan M Davis wrote:
> Oh. Those are links. I was wondering when the data was actually going to be
> posted. When compared to the previous ones, it looks like there's only headers
> with no information.

The idea is to add explanatory information to the bugzilla issue being pointed to.

Making some effort to clarify the title of the bugzilla issue is also justified.

This change to the changelog presentation does require that we up our game with bugzilla - accurate tags (you can see at the top what is being keyed on), accurate titles, and accurate information.

On 1/3/2013 12:27 PM, Leandro Lucarella wrote:
> BTW, Changelogs looks extremely naked now, I think release notes are
> really needed now. Al least for new features. Is far from ideal to make
> people go through a bug report to know how they can adapt their code to
> new features.

On the other hand, the older way of doing changelogs routinely missed a *lot* of things. Relatively few people doing the pulls would bother to log the changes. I think there were easy double the number of changes showing up in the search than were in the log.


> And sometimes bug reports are not updated on how things turned out, for
> example #7041[1], a feature I implemented myself. The bug report is
> outdated AFAIK, the title talks about a -di flags which doesn't even
> exist, you actually have to go through the pull request[2] to see what
> the hell is going on. And even then the behaviour of that pull request
> was changed in a subsequent one[3], and there are no visible links
> between those 2 pull requests.

Please update that bugzilla issue. As I posted elsewhere in this thread, this method does require upping our game with bugzilla tags, titles, and descriptions.

I don't see that it is any *harder* to update the bugzilla issue than it is to provide a brief summary in the changelog.

As for what's new, the failure here is the failure to document those changes. This is not a failure of the changelog - it's a failure of the documentation pages. The bugzilla should have a link to the relevant documentation.

I do *not* think that a changelog new feature entry takes the place of updating the documentation, and I do not agree with writing the documentation twice (changelog and documentation).


> Anyway, at least for this particular change, the changelog is basically
> useless, and I don't think the bug report is the right place to inform
> users about compiler changes.

We've been using bugzilla for a long time to organize enhancement requests.

> Users don't care about the history and
> discussion around a change, they just only want to know how to take
> advantage of new features and how to fix their code (possibly with some
> exceptions of course, in which case they can still go back to the bug
> report and pull requests).

I agree this new system is imperfect - but I argue it is better than what we were doing before.