Re: D 2.062 release
On Monday, 18 February 2013 at 07:09:03 UTC, Walter Bright wrote: On 2/17/2013 10:27 PM, Nick Sabalausky wrote: I'm happy that http://dlang.org/changelog.html; no longer shows a link for a yet-to-be-released version of DMD (no sarcasm intended), but the release date listed for 2.062 is wrong. Probably because the site was generated from the master branch rather than the 2.062 branch (which has the correct date). One of the reasons which discourage committing to changelog is that it is placed in another repository, and that repository has strange building process. Maybe having a working copy of changelog in dmd (and phobos, druntime) repository (with requirement that each pull involves changelog as like a test case) can be an option?
Re: D 2.062 release
On 2013-02-18 08:31, Walter Bright wrote: As long as it isn't written in Ruby :-) I was not referring to what's usually called a scripting language. I was referring to a script, regardless of language. -- /Jacob Carlborg
Re: D 2.062 release
On Monday, 18 February 2013 at 07:31:53 UTC, Walter Bright wrote: As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. Here is a simpleton hack: ### RUBY require nokogiri require open-uri # provided the urls are given changes_new_features_url = http://...blah blah... d_runtime_fixes_url = http://...blah blah... phobos_fixes_url = http://...blah blah... def get_summaries(url) summaries = [] page = Nokogiri::HTML(open(url)) table = page.css(.bz_buglist) rows = table.css(tr) rows.each do |row| summary = row.css(td:last-child).text.strip summaries summary if !summary.empty? end summaries end puts \nChanges and New Features: puts get_summaries(changes_new_features_url) puts \nD Runtime Fixes: puts get_summaries(d_runtime_fixes_url) puts \nPhobos Fixes: puts get_summaries(phobos_fixes_url) ### END I guess the correct approach is to use Bugzilla's REST api, but its 1am... and this might be good enough?
Re: D 2.062 release
Steven Schveighoffer, el 17 de February a las 22:36 me escribiste: Also, anyone can go in and change the bugzilla issue titles to make them more readable. That actually is not a good thing... Anyone can maliciously affect the changlog, or alter the changelog at some later point because they wanted to 'reopen' a bug. +1 Having a dynamic changelog is a no-no. Is going against one of the most basic properties of a changelog. -- 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.
Re: D 2.062 release
On 2013-02-18 10:02, Joshua Niehus wrote: On Monday, 18 February 2013 at 07:31:53 UTC, Walter Bright wrote: As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. Here is a simpleton hack: ### RUBY require nokogiri require open-uri # provided the urls are given changes_new_features_url = http://...blah blah... d_runtime_fixes_url = http://...blah blah... phobos_fixes_url = http://...blah blah... def get_summaries(url) summaries = [] page = Nokogiri::HTML(open(url)) table = page.css(.bz_buglist) rows = table.css(tr) rows.each do |row| summary = row.css(td:last-child).text.strip summaries summary if !summary.empty? end summaries end puts \nChanges and New Features: puts get_summaries(changes_new_features_url) puts \nD Runtime Fixes: puts get_summaries(d_runtime_fixes_url) puts \nPhobos Fixes: puts get_summaries(phobos_fixes_url) ### END I guess the correct approach is to use Bugzilla's REST api, but its 1am... and this might be good enough? This time it wasn't me :) -- /Jacob Carlborg
Re: D 2.062 release
18-Feb-2013 11:31, Walter Bright пишет: On 2/17/2013 11:23 PM, Jacob Carlborg wrote: On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? -- Dmitry Olshansky
Re: D 2.062 release
Walter Bright, el 17 de February a las 19:54 me escribiste: If someone wants to step up and take charge of doing a better job with the changelog, I'm all for it. The old way was NOT a better job. It was usually left to me (and Jonathan) to try to cobble something together. When I was the only committer, I'd edit the changelog as things got changed. With the larger number of committers today, this got overlooked. The result was incomplete, inaccurate, and a lot of belated hey, you left out these changes after the release. Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. A missing changelog entry is like missing documentation or code comments, a pull request that doesn't update it shouldn't be merged! Making the changelog update go to just one person is the problem, that work should be distributed and the better person to do it is the one that made the change. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- For long you live and high you fly But only if you ride the tide And balanced on the biggest wave You race towards an early grave.
Re: D 2.062 release
On Monday, 18 February 2013 at 10:55:39 UTC, David Nadlinger wrote: On Monday, 18 February 2013 at 10:07:58 UTC, Leandro Lucarella wrote: Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. We tried that in the past, and it lead to tons of merging errors. They are easy to resolve manually, of course, but still very annoying because this breaks the GitHub Merge button. David So maybe every changelog message should be stored in separated file. The release script would merge those according to the git history.
Re: D 2.062 release
Am Mon, 18 Feb 2013 10:05:10 +0100 schrieb Leandro Lucarella l...@llucax.com.ar: Steven Schveighoffer, el 17 de February a las 22:36 me escribiste: Also, anyone can go in and change the bugzilla issue titles to make them more readable. That actually is not a good thing... Anyone can maliciously affect the changlog, or alter the changelog at some later point because they wanted to 'reopen' a bug. +1 Having a dynamic changelog is a no-no. Is going against one of the most basic properties of a changelog. I think we need two things: A changelog. Should be automatically exported from bugzilla (but not a link to bugzilla, the changelog shouldn't change after the release), some projects even use the git commit log for this. Release notes describing the most important changes in the release as a concise, easy to read text.
Re: D 2.062 release
Am Mon, 18 Feb 2013 03:10:27 +0100 schrieb Andrej Mitrovic andrej.mitrov...@gmail.com: For the next release I propose that we get more involved in the release process: - We make an agreement on when exactly a release is made, without wondering when Walter might end up doing it himself. Maybe we should agree on a long-term release schedule. Here's an example for the next 10 releases with 6 weeks between every release and 2 additional minor releases per major release: http://wiki.dlang.org/User:Jpf/Release_Schedule The D script which was used to create the wiki page is linked from the wiki page. This makes it easy to change the duration between beta, rc and final releases, number of minor releases, etc.
Re: D 2.062 release
On Monday, 18 February 2013 at 10:55:39 UTC, David Nadlinger wrote: On Monday, 18 February 2013 at 10:07:58 UTC, Leandro Lucarella wrote: Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. We tried that in the past, and it lead to tons of merging errors. They are easy to resolve manually, of course, but still very annoying because this breaks the GitHub Merge button. David Than maybe don't include changelog entry in a pull, but require that it is supplied with pull description as text, so that whoever mergers pull, separately pushes it to the branch? I would be nice if auto-tester could handle it automatically.
Re: D 2.062 release
dlangspec v2.062 in several formats: dlangspec.chm http://d-packages.googlecode.com/files/dlangspec.chm dlangspec.epub http://d-packages.googlecode.com/files/dlangspec.epub dlangspec.mobi http://d-packages.googlecode.com/files/dlangspec.mobi dlangspec.pdf http://d-packages.googlecode.com/files/dlangspec.pdf -- Jordi Sayol
Re: Crystal
On 2/17/13 5:46 PM, Jacob Carlborg wrote: On 2013-02-17 21:22, Ary Borenszweig wrote: Since it's not yet implemented, it could be like that, or it can be that it is evaluated when you execute the program (but not at compile time). But if I just but code that the top level of a file, when at runtime is that executed? In the order it was analyzed. Same as in Ruby.
Re: Crystal
On 2013-02-18 13:46, Ary Borenszweig wrote: In the order it was analyzed. Same as in Ruby. I see. -- /Jacob Carlborg
Re: D 2.062 release
David Nadlinger, el 18 de February a las 11:55 me escribiste: On Monday, 18 February 2013 at 10:07:58 UTC, Leandro Lucarella wrote: Again, the problem is making the changelog update optional! No pull request should be merged if it doesn't include a proper changelog entry, that's how it's done. We tried that in the past, and it lead to tons of merging errors. They are easy to resolve manually, of course, but still very annoying because this breaks the GitHub Merge button. Argh, I have the Merge button anyway (and it's Merge Art), but that's a different topic. An easy way to solve that is to add each changelog entry in a separate file, to avoid conflicts between changelog files, you could pick a schema like [date]-[user]-[some_id], for example: 20130118-llucax-fix9304.txt. Then all you need is a small script that put all the entries together that is executed when releasing. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Instead of doing a wash, I just keep buying underwear. My goal is to have over 360 pair. That way I only have to do wash once a year. -- George Constanza
Re: D 2.062 release
Steven Schveighoffer, el 18 de February a las 00:37 me escribiste: I propose that when you post the beta on the mailing list, you also post the reports of the fixed bugs and enhancements. Then people can edit the descriptions before the release. Then I think after the release, the descriptions should be locked, and the bugs cannot be reopened. Please, don't do that, is the changelog what's broken, don't break the issue tracker too to try to make a changelog out of it! I also would love to see an automatically generated changelog similar to the original based on the bugzilla data. Can we add a changelog description field to bug reports so if the bug description (which arguably shouldn't be changed) isn't a very good changelog entry, that is used instead? All we need to do is force people to update the changelog when making a pull request. That's it. You are making everything more complex than it should be... -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Decile que ponga rails generate tp_prof_fiuba en la consola y en una semana se recibe. -- Mazzi, filósofo estilista
Re: D 2.062 release
18-Feb-2013 17:22, Leandro Lucarella пишет: I also would love to see an automatically generated changelog similar to the original based on the bugzilla data. Can we add a changelog description field to bug reports so if the bug description (which arguably shouldn't be changed) isn't a very good changelog entry, that is used instead? All we need to do is force people to update the changelog when making a pull request. That's it. You are making everything more complex than it should be... Or instead somebody just has to take time and write down 10 most important things in new release. Add this task to release manager role. *That's* what interesting not pushing more grunt work on contributors that basically doesn't work at all. Other then this a small script to expand the bugzilla entries into a webpage (just like before title + link to bugzilla). -- Dmitry Olshansky
Re: D 2.062 release
On Mon, 18 Feb 2013 01:31:47 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 10:18 PM, Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No it isn't. Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. This statement is provably false. See here: http://dlang.org/changelog.html#new2_057 First element in the changelog is: Better use of XMM registers in 64 bit targets. Searching in bugzilla I get: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedshort_desc=Better%20use%20of%20XMMshort_desc_type=substring Zero issues found This text cannot have been copy and pasted out of bugzilla. These 'changelog-like' messages are what I miss. For a list of bugs fixed, sure, just give me a report, I don't care (better if the report is extracted into the changelog instead of a query into a live database). But I want the new/changed features list back. -Steve
Re: D 2.062 release
18-Feb-2013 13:18, Dmitry Olshansky пишет: 18-Feb-2013 11:31, Walter Bright пишет: On 2/17/2013 11:23 PM, Jacob Carlborg wrote: On 2013-02-18 07:31, Walter Bright wrote: Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. How about a script that doesn't it automatically? Then we at least don't have to go to bugzilla. As long as it isn't written in Ruby :-) But more seriously, a D tool to do it might be interesting. This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? The output of said D script for 2.062 is: $(DMDBUGSFIXED $(LI $(BUGZILLA 1369): Unable to find 'this' in __traits(getMember)) $(LI $(BUGZILLA 1730): Bogus error message calling a non-const struct method on a const struct reference) $(LI $(BUGZILLA 1841): Closure detection doesn't work when variable is used in a nested function) $(LI $(BUGZILLA 2452): Unimplemented method errors should show function overload) $(LI $(BUGZILLA 2630): ddoc should be able to document unittests) $(LI $(BUGZILLA 3321): debug flags) $(LI $(BUGZILLA 3404): JSON output should retain original alias names) $(LI $(BUGZILLA 3466): Wrong JSON output for templated classes, structs, and interfaces) $(LI $(BUGZILLA 4178): destructor missing in JSON output) $(LI $(BUGZILLA 4194): Attributes included in JSON output) $(LI $(BUGZILLA 4269): Regression(2.031): invalid type accepted if evaluated while errors are gagged) $(LI $(BUGZILLA 4477): JSON output for function definitions includes insufficient type information) $(LI $(BUGZILLA 4478): JSON output omits import statements) $(LI $(BUGZILLA 4540): Better error message for wrong switch type) $(LI $(BUGZILLA 5168): String enums don't work with -g compiler switch) $(LI $(BUGZILLA 5461): Invalid declaration for auto functions in .di files generated by DMD -H) $(LI $(BUGZILLA 5529): std.system.endian for pure functions?) $(LI $(BUGZILLA 5893): Allow simple aliases for operator overloading) $(LI $(BUGZILLA 5933): Cannot retrieve the return type of an auto-return member function) $(LI $(BUGZILLA 5978): ICE(mtype.c) when calling __traits(parent) on the child of an anonymous function.) $(LI $(BUGZILLA 6057): Problem with defining enum in function) $(LI $(BUGZILLA 6171): rdmd: cache dependency file to improve startup time [patch]) $(LI $(BUGZILLA 6319): debug's relaxed purity does not apply to nested scopes) $(LI $(BUGZILLA 6332): Auto-return function cannot be inferred as @safe) $(LI $(BUGZILLA 6408): string[].init gives a wrong type) $(LI $(BUGZILLA 6538): ICE(mangle.c) Invalid template constraints) $(LI $(BUGZILLA 6552): Wrong fallthrough warning for CaseRange) $(LI $(BUGZILLA 6652): foreach parameter with number range is always ref) $(LI $(BUGZILLA 6708): immutable ref implicit cast to const ref) $(LI $(BUGZILLA 6743): ICE(mars.c) attempting to compile an exe file) $(LI $(BUGZILLA 6833): Floating point literals lose fractional part in headers) $(LI $(BUGZILLA 6873): Multiple storage class is not allowed on template argument) $(LI $(BUGZILLA 6902): Different pure nothrow int() types) $(LI $(BUGZILLA 6905): ref acts as auto ref when return type is missing) $(LI $(BUGZILLA 6962): Wrong Code With Scope Exit and Array Parameter, only with -O) $(LI $(BUGZILLA 6963): pure/nothrow inference doesn't work for function pointers) $(LI $(BUGZILLA 7152): Can't assign null to default argument) $(LI $(BUGZILLA 7159): Forward reference when casting auto return method) $(LI $(BUGZILLA 7408): traits compiles fails for built-in properties of template instances) $(LI $(BUGZILLA 7420): Duplicate cannot be read at compile time error messages) $(LI $(BUGZILLA 7585): functions in templates inferred as delegate) $(LI $(BUGZILLA 7740): unicodeProperties cannot be read at compile time for ctRegex) $(LI $(BUGZILLA 7950): Type tuples are incorrectly flattened in base type list of interface) $(LI $(BUGZILLA 8053): Recursive alias this causes infinite loop) $(LI $(BUGZILLA 8105): Implement in ref) $(LI $(BUGZILLA 8128): unittest blocks should be allowed in interfaces) $(LI $(BUGZILLA 8152): Linking C library causes Seg-fault) $(LI $(BUGZILLA 8153): Warning about toHash signature is incorrect on x86_64) $(LI $(BUGZILLA 8504): Template attribute inferrence doesn't work) $(LI $(BUGZILLA 8583): [64 bit] AA ushort[dchar] byValue range is corrupted on x86_64) $(LI $(BUGZILLA 8631): illegal overrides accepted) $(LI $(BUGZILLA 8717): `private` and `protected` restrict member usage in same module) $(LI $(BUGZILLA 8742): Anonymous nested class derived from another nested class makes DMD crash) $(LI $(BUGZILLA 8763): struct
Re: D 2.062 release
Must be a problem with mobile Chrome then. Probably not specific to the new change log handling. In chrome that entire content pane has a tendency to disappear. --bb Sent from my Android. On Feb 17, 2013 11:20 PM, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 5:40 PM, Bill Baxter wrote: The new change log also seems inaccessible from mobile. (At least it seems to freak out chrome on android). I tried it on my ipod with Safari. Both changelog.html and bugzilla render fine, though it helps to turn the ipod sideways to get 'landscape' mode.
Re: D 2.062 release
On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. Has anyone even tested the release package? I get make: *** No rule to make target `../VERSION', needed by `verstr.h'. Stop. during building of dmd. People in #d report the same. It can't work, the file isn't even in the package.
Re: D 2.062 release
Am Sun, 17 Feb 2013 17:02:20 -0800 schrieb Walter Bright newshou...@digitalmars.com: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. I didn't read the whole thread now. Just reporting that the .zip package cannot be compiled due to missing VERSION file and that all the Phobos documentation now has empty Examples: sections (which I thought was already fixed). -- Marco
Re: [OT] Region-Based Storage Management: ParaSailing without a (Garbage) Chute
Am 18.02.2013 01:22, schrieb Tucker Taft: On Sunday, 10 February 2013 at 09:50:30 UTC, Paulo Pinto wrote: Hi, some might find this interesting. A presentation about the ParaSail, system programming language based on Ada. ... ParaSail is not really based on Ada, but it does try to incorporate good ideas from a number of languages, including Ada, ML/OCaml, Modula/Oberon, D ;-), etc. Thanks for clearing that up. I got that impression due to the Ada like syntax and being developed by Ada Core. Only afterwards I discovered that you were already developing ParaSail before joining Ada Core. It looks nice though. -- Paulo
Re: D 2.062 release
On Monday, February 18, 2013 18:43:37 Dmitry Olshansky wrote: 18-Feb-2013 17:22, Leandro Lucarella пишет: I also would love to see an automatically generated changelog similar to the original based on the bugzilla data. Can we add a changelog description field to bug reports so if the bug description (which arguably shouldn't be changed) isn't a very good changelog entry, that is used instead? All we need to do is force people to update the changelog when making a pull request. That's it. You are making everything more complex than it should be... Or instead somebody just has to take time and write down 10 most important things in new release. Add this task to release manager role. *That's* what interesting not pushing more grunt work on contributors that basically doesn't work at all. Other then this a small script to expand the bugzilla entries into a webpage (just like before title + link to bugzilla). Exactly. It would be nice to have the list of bug fixes and whatnot listed on the page directly rather than linked to, but having that managed automatically is great. The real problem is that we need a set of release notes at the top which lists the important changes. That just means that someone needs to take the time to write that up for each release. Updating the changelog manually is not only broken because stuff gets missed, but it's broken because it causes merge problems if you merge in the changelog changes at the same time as the commit. We don't need all of that extra grunt work. We just need the release notes section to be written by someone (or someones) in preparation for the release. - Jonathan M Davis
Re: D 2.062 release
On 2/18/2013 8:47 AM, Bill Baxter wrote: Must be a problem with mobile Chrome then. Probably not specific to the new change log handling. In chrome that entire content pane has a tendency to disappear. I'm still not sure if you're referring to the changelog.html page or the bugzilla page.
Re: D 2.062 release
On 2/18/2013 9:02 AM, Sven-Hendrik Haase wrote: On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. Has anyone even tested the release package? I get make: *** No rule to make target `../VERSION', needed by `verstr.h'. Stop. during building of dmd. People in #d report the same. It can't work, the file isn't even in the package. I forgot to include VERSION in the zip file. Its contents are: 2.062 all on one line. I'll fix the packages.
A Mathematician looks at D
http://www.reddit.com/r/programming/comments/18r7zk/a_mathematician_looks_at_d/ No REPL, I guess we are rubbish?
Re: A Mathematician looks at D
Personally I find REPLs super annoying, especially when you need
to import or require something or like to use multiple lines.
Serious how hard is it to just do:
### Ruby
#!/usr/bin/ruby
require pp
puts do stuff
// D
#!/usr/bin/rdmd
import std.stdio;
void main() {
writeln(do stuff);
}
then press Command+b (Sublime text) and watch it work/fail?
Re: D 2.062 release
On Monday, 18 February 2013 at 01:31:47 UTC, Mike Parker wrote: On Monday, 18 February 2013 at 01:02:43 UTC, Walter Bright wrote: I've lost the motivation to even look at the changelog now. +1
Re: A Mathematician looks at D
Joshua Niehus: Serious how hard is it to just do: then press Command+b (Sublime text) and watch it work/fail? With a REPL you don't need to repeat the precedent computations every time you add something. You keep building on what you have already done. This saves you time (beside saving you the time of hundreds of compilations). A REPL is handy when you don't know the correct usage of something: you try something, read the error it gives you, ask for some help to the system, and try again, etc. A REPL is very handy when you are doing http://en.wikipedia.org/wiki/Exploratory_programming If your interactive system also has some cumulative graphics output this is very handy, you can rotate and change plot parameters interactively until you find some good ones (this is possible in Mathematica). Bye, bearophile
Re: A Mathematician looks at D
On Mon, 18 Feb 2013 23:37:00 +0100 bearophile bearophileh...@lycos.com wrote: A REPL is handy when you don't know the correct usage of something: you try something, read the error it gives you, ask for some help to the system, and try again, etc. I can do that just as easily without a REPL. If your interactive system also has some cumulative graphics output this is very handy, you can rotate and change plot parameters interactively until you find some good ones (this is possible in Mathematica). This, however, is certainly not a bad benefit of REPL.
Re: D 2.062 release
On 2/18/13, Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: I agree we need to improve on this. One way to achieve that, seeing as marketing is not Walter's focus, is to denote a release czar who has that particular task around releases. Andrej, would you want to try that role? How about I write how a release would look like for 2.062 (a mockup), and if we're all fond of it we can base this on the upcoming release? That way we don't have to argue days before a release on what the release should look like.
Re: D 2.062 release
On 2/19/13, Brad Roberts bra...@puremagic.com wrote: How about writing one for 2.062 that can be inserted into the change log instead of the current links rather than a mockup that might represent what a change log might look like? Yes. I'll get to it and make a pull request once it's ready.
Re: D 2.062 release
On 2/19/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: http://digitalmars.com/d/download.html Argh the chm generation is awful now. I mean when I try to generate the .chm file myself. I can see now there's a d.chm file in \bin. It doesn't have loading issues, however there is no styling in the .chm file.
Re: D 2.062 release
On 2/19/13, Andrej Mitrovic andrej.mitrov...@gmail.com wrote: Error while processing file: .\spec.html object.Error: Access Violation I've filed it: http://d.puremagic.com/issues/show_bug.cgi?id=9533
Re: A Mathematician looks at D
On Tue, 19 Feb 2013 00:55:44 +0100 bearophile bearophileh...@lycos.com wrote: Nick Sabalausky: I can do that just as easily without a REPL. With a much reduced interactivity and more slowly. Slightly so. I wouldn't say much. But of course, I'm not saying that a REPL wouldn't be nice to have. Just saying that edit, re-compile/run really isn't all *that* bad.
Re: A Mathematician looks at D
Joshua Niehus: I'll take your word for it, in my narrow experience, I've found REPLs slow me down. Thankfully in most cases you are not forced to use it. I have met several persons that don't like to use a REPL, for unknown reasons. Different persons have a brain shaped in different ways. And for some kind of problems it's not so good. So it's not for everyone everytime. But from the presence of a REPL in many languages (Python, Ruby, C, Haskell, Scala, Lisp-like languages, and so on) and in most mathematics systems, clearly it's appreciated by some others. Bye, bearophile
Re: D 2.062 release
On 2/18/2013 1:18 AM, Dmitry Olshansky wrote: This D script dumps all fixed bugs between 2 dates as DDOC entries. https://gist.github.com/blackwhale/3734045 (or just starting from one date till today). That being said I've brought it up like 5 times already. Must be not what you are looking for? Please add this to the tools repository on github.
Re: D 2.062 release
On 2/18/2013 6:46 AM, Steven Schveighoffer wrote: On Mon, 18 Feb 2013 01:31:47 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 10:18 PM, Nick Sabalausky wrote: Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No it isn't. Since I (and Jonathan) wrote the changelog, I can attest that I cut pasted it character for character out of the bugzilla titles, and received no comments or complaints about it. I did it that way because people on the n.g. asked me to do it that way. This statement is provably false. See here: http://dlang.org/changelog.html#new2_057 First element in the changelog is: Better use of XMM registers in 64 bit targets. Searching in bugzilla I get: http://d.puremagic.com/issues/buglist.cgi?query_format=advancedshort_desc=Better%20use%20of%20XMMshort_desc_type=substring Zero issues found This text cannot have been copy and pasted out of bugzilla. Part of the idea of the new system is that all of those one-liners become one-liners in bugzilla.
Re: D 2.062 release
Personally, I just wish there was a quick blurb at the top of the changelog indicating the highlights of this release. For example, with 2.058, the very first two lines of the changelog were: Add new = lambda syntax. Allow 1.userproperty syntax. NOTE: 1.f is no longer a float literal, add a 0. You can look at that and decide Awesome, new lambda syntax and UFCS!. You get a quick 10-20 lines indicating what you need to know about that release, what's interesting about it, and what the new features or most important bug fixes were. For the people who care, you can then see bug fixes / larger list of changes at the bottom (I personally don't have a preference as to whether they'd be on the same page or just a bugzilla link). However the really important thing is the quick blurb at the top. For example, with this release, something about how 'in ref' is now supported, how you can document unittests and have them appear with the documentation of the above symbol, improved JSON output, and unittests being allowed in interfaces. This is just a quick 10 line overview of some of the highlights of this release. Not necessarily just new features either. For example, if example bug#314 was fixed, there is absolutely no way I would know about it given that it's buried in the list of bug fixes, even though it has affected almost every single D user at one point and would definitely be considered a highlight.
Re: D 2.062 release
On 2013-02-19 07:25, Kapps wrote: Personally, I just wish there was a quick blurb at the top of the changelog indicating the highlights of this release. For example, with 2.058, the very first two lines of the changelog were: Add new = lambda syntax. Allow 1.userproperty syntax. NOTE: 1.f is no longer a float literal, add a 0. You can look at that and decide Awesome, new lambda syntax and UFCS!. You get a quick 10-20 lines indicating what you need to know about that release, what's interesting about it, and what the new features or most important bug fixes were. For the people who care, you can then see bug fixes / larger list of changes at the bottom (I personally don't have a preference as to whether they'd be on the same page or just a bugzilla link). However the really important thing is the quick blurb at the top. For example, with this release, something about how 'in ref' is now supported, how you can document unittests and have them appear with the documentation of the above symbol, improved JSON output, and unittests being allowed in interfaces. This is just a quick 10 line overview of some of the highlights of this release. Not necessarily just new features either. For example, if example bug#314 was fixed, there is absolutely no way I would know about it given that it's buried in the list of bug fixes, even though it has affected almost every single D user at one point and would definitely be considered a highlight. I agree. I think documenting mixins was added in this release. -- /Jacob Carlborg
