Re: Crystal
17.02.2013 10:28, Ary Borenszweig пишет:
Hello everyone :-)
...
(you might remember me: I'm the author of Descent)
A Hero is here! Let me kowtow to you, a Descent Creator!
... Let's save this world's energy.
It's pleasantly to see this point of view at efficiency.
But... do we really have to specify const pure safe nothrow and whatnot?
Can't the compiler be smarter? I'm sure there must be a better way. Most
new programming languages look like older ones. Newness comes slowly...
One time I asked in this newsgroup if it was possible to have an auto
keyword for function/method arguments. And... why not make all
functions/methods be templates on the type of its arguments?
I think nobody liked this idea. I said Ruby is like this: you never
specify types in method definitions.
But Ruby is not efficient. Ruby is a dynamic language. D is
compiled, so it's faster. Don't make the mistake of comparing a
dynamic language with a static/systems programming language. This were
some of the answers I got.
I started thinking about this idea: a compiled language that looked like
a dynamic language. Is it possible?
Looks like it is, by what is the reason?
I'd like to specify function attributes explicitly because I do want to
get a compilation error when I e.g. use non-safe stuff in safe function
instead of a just compiler silently changing the function (and all
functions which use it) to unsafe. I also don't use type inference
everywhere because sometimes I do want to see exact types (yes, IDE
problem) and sometimes I just don't want a type to be accidentally
changed because of some function signature change as in the worst case
the code will still compile but will work incorrect.
Now about argument types. I do not understand the purpose of dynamic
typing at all and consider such languages too dangerous to use in real
projects. You proposal is a bit better as it will give CT errors
(instead of RT in dynamic typing case) but still bad as the code can
accidentally compile and work incorrect. Also this looks as a step back
as your proposal is like making from a function something like C's
preprocessor macro. And I remember how somebody defended C's macros and
told you can do it with macro, then he gave his code where he made a
fatal mistake by passing two parameters to a macro in a wrong order. And
that code accidentally compiled. Same thing can happen with every high
templated code where it is hard to predict every possible argument
combination.
I also have seen a lot of mistakes of any types in D templated code so I
consider such code almost as dangerous as pointer arithmetic and you
proposal to make everything a template looks as insane.
...
Thanks for your comments,
Ary
P.S.: bin/crystal -e 'a = 0; 10.times { |i| a += i }; puts a' -O3 -ll
Sorry for such cruel comment, I it is just my opinion.
--
Денис В. Шеломовский
Denis V. Shelomovskij
Re: Crystal
Ary Borenszweig: I started thinking about this idea: a compiled language that looked like a dynamic language. Is it possible? Of course it's possible, I given my help in the development of ShedSkin: http://code.google.com/p/shedskin/ Its compilation times are significant and they keep growing quickly as the amount of compiled code grows. Bye, bearophile
Re: Crystal
Why is this thread on the announce mailing list instead of the discussion list? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Crystal
On 2013-02-17 08:46, Paulo Pinto wrote: Have you looked into Ruby Motion or Mirah as well? Or MacRuby. It's free (as in free beer) and open source, not something that Ruby Motion is. -- /Jacob Carlborg
Re: Crystal
Am 17.02.2013 12:57, schrieb Jacob Carlborg: On 2013-02-17 08:46, Paulo Pinto wrote: Have you looked into Ruby Motion or Mirah as well? Or MacRuby. It's free (as in free beer) and open source, not something that Ruby Motion is. My problem with MacRuby and Ruby Motion is they are tied to Mac OS X. Crystal's usage of LLVM is actually quite positive in that regard. -- Paulo
Re: Crystal
On 2013-02-17 14:21, Paulo Pinto wrote: My problem with MacRuby and Ruby Motion is they are tied to Mac OS X. Yeah, I agree. But developing for iOS is pretty tied to Mac OS X anyway. -- /Jacob Carlborg
Re: Crystal
On 2/17/13 6:29 AM, Denis Shelomovskij wrote: I'd like to specify function attributes explicitly because I do want to get a compilation error when I e.g. use non-safe stuff in safe function instead of a just compiler silently changing the function (and all functions which use it) to unsafe.= It's something I didn't have time to write in that wiki page, but you can restrict the types of a function. def foo(x : Int) 1 end foo Hello # Gives a compile-time error This is similar to what you can do with D templates. You can also restrict an overload an use another one unrestricted and it will choose the correct one: def foo(x : Int) 1 end def foo(x) 2 end foo Hello # Chooses the second one So theoretically you can type everything you want. We might also support typing a variable in order to disallow it to change to another type (I think this is what is done in the Julia language). Now about argument types. I do not understand the purpose of dynamic typing at all and consider such languages too dangerous to use in real projects. In the place I work we've written several web applications and programs in Ruby and they work just fine. We writes lots of test units to make sure everything works (you don't have another option, really, with dynamic languages). Sorry for such cruel comment, I it is just my opinion. It's not cruel at all. I really appreciate your comments.
Re: Crystal
On 2/17/13 9:14 AM, Jacob Carlborg wrote: I find it very interesting. But actually I'm going to agree with Denis, mostly. If I was going to use Crystal I would probably use a lot more static typing than it's probably made for. I quite often miss static typing in Ruby. Often there are functions that are supposed to only work with a given type, I don't see why I shouldn't explicitly write that type out then. As I replied to Denis, you can specify type restrictions in functions and methods. def foo(x : Int) 1 end foo Hello # Gives a compile error It works similar to overloaded templates: you don't specify the type of the function, but which types you can give to it. In the case of Int, of course it will always just accept an Int. But you can specify for example def foo(x : Enumerable) end And there's a special restriction, self, that will only match for the owner of the method. This is used for example in the Comparable module: https://github.com/manastech/crystal/blob/master/std/comparable.cr A couple of questions: * Executable code at class level, is that supported? If that's the case, when is it run? Example: class Foo puts asd end I thought it was supported but it's not. It would be very easy to support it, but it would execute at run time, as if you had put it before the class declaration. However, there's another thing I didn't mention in that wiki page and that is macros. You can write; --- macro define_something def something; 1; end end define_something() # This defines the something method something() # And this invokes it --- Again, this is different from Ruby. Macros are executed at compile time. You can pass arguments to them, and their type will be the AST node of the expression you give them. They must return a String (for now), and it will be mixed in the program (later we'll support returning AST nodes directly). We use macros for attr_accessor and the like: https://github.com/manastech/crystal/blob/master/std/object.cr Just note that this is an experimental feature, and for now only variables, strings and symbols are allowed for macros. Macros can execute arbitrary code and have access to what you defined in your program. That means they can open a file, read/write a database and so on. I believe this can be very powerful for metaprogramming. (this is inspired mainly from Lisp) * With a statically typed languages you quite soon get the need for interfaces, abstract classes and similar. How is this handled? If you don't need them in Ruby I don't see why would you need them in Crystal. The only use of interfaces is to satisfy the compiler. But since Crystal is mostly duck-typed interfaces have no use. Another use is probably performance, and we are still considering how to fit everything together. We are writing code in Crystal and see where it's slow, and think of the most little change that's not a burden for the programmer that can help speed up compilation times. * Is Ruby code supposed to be able to run of out the box in Crystal? That is can I take arbitrary Ruby code and compile it with Crystal and expect it to work. If that's the case, what's currently supported and what's not supported? You probably won't have eval, define_method and so on. You will be able to do some of those things with macros, but it's not the same. Most Ruby code should run out of the box, unless something is missing from the standard library. For example I tried running this code: https://gist.github.com/havenwood/4724778 (removing the Time.now lines, because we don't have that yet) and it just worked. And it was much faster than all of the other languages. Our idea was to make a language as similar as Ruby, not with the intention of compiling Ruby. But accidentally (or not :-P) it is happening, slowly. Thanks for your comments and questions!
Re: Crystal
Have you looked into Ruby Motion or Mirah as well? Ruby Motion is not open source, so we couldn't (or didn't want) to take a look at that. Mirah compiles for the JVM, and we want to compile to native code. We try to escape from virtual machines...
Re: Crystal
Am 17.02.2013 17:41, schrieb Ary Borenszweig: Have you looked into Ruby Motion or Mirah as well? Ruby Motion is not open source, so we couldn't (or didn't want) to take a look at that. I know, the question was more in the value proposal kind of way. Mirah compiles for the JVM, and we want to compile to native code. We try to escape from virtual machines... Currently yes, but there have been discussions to get it to compile to native code via LLVM.
Re: Crystal
On 2013-02-17 17:34, Ary Borenszweig wrote: As I replied to Denis, you can specify type restrictions in functions and methods. def foo(x : Int) 1 end foo Hello # Gives a compile error It works similar to overloaded templates: you don't specify the type of the function, but which types you can give to it. In the case of Int, of course it will always just accept an Int. But you can specify for example def foo(x : Enumerable) end Yeah, I saw there's explicit static typing. And there's a special restriction, self, that will only match for the owner of the method. This is used for example in the Comparable module: https://github.com/manastech/crystal/blob/master/std/comparable.cr So in that case self would evaluate, at compile time, to whatever Comparable is mixed in to? I thought it was supported but it's not. It would be very easy to support it, but it would execute at run time, as if you had put it before the class declaration. That code will be executed as soon as the file has been loaded using require? However, there's another thing I didn't mention in that wiki page and that is macros. You can write; --- macro define_something def something; 1; end end define_something() # This defines the something method something() # And this invokes it --- Yeah, I saw that. Again, this is different from Ruby. Macros are executed at compile time. You can pass arguments to them, and their type will be the AST node of the expression you give them. They must return a String (for now), and it will be mixed in the program (later we'll support returning AST nodes directly). We use macros for attr_accessor and the like: https://github.com/manastech/crystal/blob/master/std/object.cr Just note that this is an experimental feature, and for now only variables, strings and symbols are allowed for macros. Macros can execute arbitrary code and have access to what you defined in your program. That means they can open a file, read/write a database and so on. I believe this can be very powerful for metaprogramming. (this is inspired mainly from Lisp) This looks cool. If you don't need them in Ruby I don't see why would you need them in Crystal. You don't need them in Ruby because it's dynamically typed. The only use of interfaces is to satisfy the compiler. But since Crystal is mostly duck-typed interfaces have no use. But it does support explicit static typing. It doesn't look easy to restrict a method for a given type for something like an interface. So what will happen is one use duck typing and it will basically be the same as templates without constrains. Another use is probably performance, and we are still considering how to fit everything together. We are writing code in Crystal and see where it's slow, and think of the most little change that's not a burden for the programmer that can help speed up compilation times. * Is Ruby code supposed to be able to run of out the box in Crystal? That is can I take arbitrary Ruby code and compile it with Crystal and expect it to work. If that's the case, what's currently supported and what's not supported? You probably won't have eval, define_method and so on. You will be able to do some of those things with macros, but it's not the same. Most Ruby code should run out of the box, unless something is missing from the standard library. For example I tried running this code: https://gist.github.com/havenwood/4724778 (removing the Time.now lines, because we don't have that yet) and it just worked. And it was much faster than all of the other languages. Our idea was to make a language as similar as Ruby, not with the intention of compiling Ruby. But accidentally (or not :-P) it is happening, slowly. I see. -- /Jacob Carlborg
Re: Crystal
On Sunday, 17 February 2013 at 12:14:40 UTC, Jacob Carlborg wrote: Except from what others already have mentioned someone created a language with a Python like syntax written in D. But I think that had explicit types. http://delight.sourceforge.net/
Re: Crystal
On 2/17/13 4:09 PM, Jacob Carlborg wrote: On 2013-02-17 17:34, Ary Borenszweig wrote: As I replied to Denis, you can specify type restrictions in functions and methods. def foo(x : Int) 1 end foo Hello # Gives a compile error It works similar to overloaded templates: you don't specify the type of the function, but which types you can give to it. In the case of Int, of course it will always just accept an Int. But you can specify for example def foo(x : Enumerable) end Yeah, I saw there's explicit static typing. And there's a special restriction, self, that will only match for the owner of the method. This is used for example in the Comparable module: https://github.com/manastech/crystal/blob/master/std/comparable.cr So in that case self would evaluate, at compile time, to whatever Comparable is mixed in to? Yes. I thought it was supported but it's not. It would be very easy to support it, but it would execute at run time, as if you had put it before the class declaration. That code will be executed as soon as the file has been loaded using require? 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).
Re: Crystal
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? -- /Jacob Carlborg
Re: Crystal
On 2013-02-17 20:50, JN wrote: http://delight.sourceforge.net/ There we go, thanks. -- /Jacob Carlborg
Re: [OT] Region-Based Storage Management: ParaSailing without a (Garbage) Chute
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. For more information on the design and implementation of ParaSail see: http://parasail-programming-language.blogspot.com -Tuck P.S. the e-mail address is a fake. If you want to reach me best is to post a question to the blog or the ParaSail Google Group: http://groups.google.com/group/parasail-programming-language -T
Re: [OT] Region-Based Storage Management: ParaSailing without a (Garbage) Chute
Tucker Taft: 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. Wow Tucker Taft himself :-) You seem quite expert, despite the very friendly attitude shown in this talk. As seen in a talk slide ParaSail throws away *lot* of stuff, to fulfill its main purpose of allowing lot of parallelism in an imperative language. While D is more a kitchen sink language, that takes lot of stuff from C, C++, Java and more. So D seems much more complex than ParaSail. On the other hand most things present in D are useful/handy. I don't know how well D will work on CPUs with 50-200 cores. The current simple GC has problems even on a single core, so on 100 cores I think it will become a mess. The Rust memory model seems quite more fit for that: http://i.imgur.com/16rxWXY.png The ParaSail idea of the need to specify what variables to use from outer scope is an idea that I like since few years, and I'd like a form of it in D (with an optional @outer() or something similar) because in the years I have seen many problems caused by using by mistake identifiers from outer scopes. Bye, bearophile
Re: D 2.062 release
On 2/17/2013 5:07 PM, Andrej Mitrovic wrote: On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. The zip download is broken: http://downloads.dlang.org.s3-website-us-east-1.amazonaws.com/releases/2013/dmd.2.062.zip It's there now (along with the other variations of the packaging).
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. Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release.
Re: D 2.062 release
The new change log also seems inaccessible from mobile. (At least it seems to freak out chrome on android). --bb Sent from my Android. On Feb 17, 2013 5:25 PM, Brad Roberts bra...@puremagic.com wrote: On 2/17/2013 5:07 PM, Andrej Mitrovic wrote: On 2/18/13, Walter Bright newshou...@digitalmars.com wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. The zip download is broken: http://downloads.dlang.org.s3-website-us-east-1.amazonaws.com/releases/2013/dmd.2.062.zip It's there now (along with the other variations of the packaging).
Re: D 2.062 release
On Sun, 17 Feb 2013 20:31:45 -0500, Mike Parker aldac...@gmail.com 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. Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release. +1 -Steve
Re: D 2.062 release
On 2/17/2013 5:31 PM, Mike Parker wrote: Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. It wasn't before, either. It was a list sorted by bugzilla number - no other sort - and it's the same now. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release. I'm sorry, I'm baffled at this. The ordering and the information is exactly the same - a list of issue numbers and the issue title.
Re: D 2.062 release
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). The changelog.html uses the same template as the rest of the dconf.org site.
Re: D 2.062 release
On 2/18/13, Mike Parker aldac...@gmail.com wrote: But I just want to throw in my 2 cents about the new changelog format. Not just the changelog, but this release announcement too. Two sentences, without any information about what is being released, who is involved, and a short few sentences on what's new. Very cold, and a complete marketing failure. 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. - We maintain a list of open pull requests which have to be merged before a release is made (we can even use DWiki for this). We could also maintain a list of bugs which should be the focus of each upcoming release. - Next to the buzilla queries in the changelog we should write a list of changes in some informative manner (split up categorically e.g. bugfixes, new syntax, new phobos features, etc), what's new, how some bug may or may not affect its users and how they can work around any code breakage. - We split up the changelog so it isn't one gigantic page. - We write an announcement post to NG that's short but informative, making sure we give a thanks to our users, reporters, maintainers and bug fixers (I'm not saying list all of their names but just a general thank you note). - We make sure the announcement can be seen on the dlang.org front page! For some examples of how other language maintainers make announcements, see: http://mail.python.org/pipermail/python-announce-list/2012-September/009630.html http://dev.perl.org/perl5/news/2012/perl-5.16.0.html https://groups.google.com/forum/#!topic/scala-announce/cRNUEBmcZYw
Re: D 2.062 release
On Sun, 17 Feb 2013 20:55:21 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 5:31 PM, Mike Parker wrote: Love the new release! Thanks to everyone who contributed. But I just want to throw in my 2 cents about the new changelog format. It's impossible now to tell at a glance what the major changes/fixes are. It wasn't before, either. It was a list sorted by bugzilla number - no other sort - and it's the same now. Clicking through four links to find them is bad enough, but the layout and color scheme of the Bugzilla search results makes it even more time consuming. I know it's easier from a maintenance perspective, but I've lost the motivation to even look at the changelog now. And it's something I really used to look forward to with each release. I'm sorry, I'm baffled at this. The ordering and the information is exactly the same - a list of issue numbers and the issue title. Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Now, I'll sure love the new replace compile error, the missing Duration.max, and the need to document extern as much as the next guy, but can we get some better descriptions? ;) Some of the descriptions work well for a changelog, but many of them don't. Even ones that are clear that they were a new feature are worded awkwardly. For example, the new feature std.random.uniform!Enum should return random enum member should really be std.random.uniform!Enum now returns a random enum member instead of a random integer The 'bugs fixed' report can be a link to bugzilla, but being able to read it inline on the changelog would be a good improvement. These are going to be static lists, there is no need to query them from a DB every time. -Steve
Re: D 2.062 release
Walter Bright: I'm sorry, I'm baffled at this. I too prefer the precedent style of the changelog. Sometimes the reality is more complex than the frame you try to shove it in :-) Reality of human brains is complex. Bye, bearophile
Re: D 2.062 release
Walter Bright: I'm sorry, I'm baffled at this. I read bugzilla entries all day long, but I think as a release page information that page gives too much information (the Sev Pri OS Assignee Status Resolution columns) that's just distracting noise. Sometimes giving less is more. Bye, bearophile
Re: D 2.062 release
On 2/17/13 9:10 PM, Andrej Mitrovic wrote: On 2/18/13, Mike Parkeraldac...@gmail.com wrote: But I just want to throw in my 2 cents about the new changelog format. Not just the changelog, but this release announcement too. Two sentences, without any information about what is being released, who is involved, and a short few sentences on what's new. Very cold, and a complete marketing failure. 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? Andrei
Re: D 2.062 release
On 2/17/13 8:02 PM, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. I've updated the website, too. Enjoy! Andrei
Re: D 2.062 release
On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. Also, anyone can go in and change the bugzilla issue titles to make them more readable.
Re: D 2.062 release
On Sun, 17 Feb 2013 21:44:18 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No. We have quite a few messages that were not bug reports in prior releases. These messages have no corresponding bugzilla entry. These were truly useful descriptions. The bug reports were few, and yes, there were a few instances like the ones I gave (I saw relax inout rules which is terrible as a description). for example: * std.array.insert has been deprecated. Please use std.array.insertInPlace instead. * Major overhaul of std.regex module's implementation. Breaking change in std.regex.replace with delegate, use Captures!string instead of RegexMatch!string as delegate parameter. The latest versions have almost none of those useful descriptions. They are almost exclusively of the cryptic you-have-to-click-on-me-to-understand-what-I-mean type. Even if there are past examples of poor descriptions for the changelog, that is not not an excuse to make them all bugzilla reports. A good first step would be to examine the bugzilla reports that will be listed as new features (should be easy since it's a report that's already being used by the web site), and change the descriptions to real useful enhancement descriptions before the release. But I think the release needs a hard copy of these descriptions. I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. I did a search for the above two examples in bugzilla, and I found nothing. Clearly, this is not the exact same information. 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. -Steve
Re: D 2.062 release
On 2/17/2013 7:36 PM, Steven Schveighoffer wrote: On Sun, 17 Feb 2013 21:44:18 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No. We have quite a few messages that were not bug reports in prior releases. These messages have no corresponding bugzilla entry. These were truly useful descriptions. The bug reports were few, and yes, there were a few instances like the ones I gave (I saw relax inout rules which is terrible as a description). for example: * std.array.insert has been deprecated. Please use std.array.insertInPlace instead. * Major overhaul of std.regex module's implementation. Breaking change in std. regex.replace with delegate, use Captures!string instead of RegexMatch!string as delegate parameter. The latest versions have almost none of those useful descriptions. They are almost exclusively of the cryptic you-have-to-click-on-me-to-understand-what-I-mean type. All that's necessary is to edit the title description. I've done that on a few of them. Even if there are past examples of poor descriptions for the changelog, that is not not an excuse to make them all bugzilla reports. It is no more or less effort to fix the bugzilla titles than it is to edit the changelog. A good first step would be to examine the bugzilla reports that will be listed as new features (should be easy since it's a report that's already being used by the web site), and change the descriptions to real useful enhancement descriptions before the release. But I think the release needs a hard copy of these descriptions. I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. I did a search for the above two examples in bugzilla, and I found nothing. Clearly, this is not the exact same information. With the new system, all changes should have a bugzilla entry for them. With the old, there were occasional vacuous statements in the changelog with no links to any discussion or just what it was. Look at the changelogs that list an issue number. All of them have the exact same text as the corresponding bugzilla title. I know they're the same because: 1. people requested that they be the same 2. I created them using cut paste With bugzilla entries for each item in the changelog, you have: 1. a title 2. discussion 3. link to the pull request that shows the code that changed to implement it 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. I know that there is the potential for malicious behavior, but thankfully we haven't seen any of that. If we do, we'll have to restrict write access to bugzilla. That'll be a sad day. 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.
Re: D 2.062 release
On Sun, 17 Feb 2013 22:54:54 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 7:36 PM, Steven Schveighoffer wrote: On Sun, 17 Feb 2013 21:44:18 -0500, Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No. We have quite a few messages that were not bug reports in prior releases. These messages have no corresponding bugzilla entry. These were truly useful descriptions. The bug reports were few, and yes, there were a few instances like the ones I gave (I saw relax inout rules which is terrible as a description). for example: * std.array.insert has been deprecated. Please use std.array.insertInPlace instead. * Major overhaul of std.regex module's implementation. Breaking change in std. regex.replace with delegate, use Captures!string instead of RegexMatch!string as delegate parameter. The latest versions have almost none of those useful descriptions. They are almost exclusively of the cryptic you-have-to-click-on-me-to-understand-what-I-mean type. All that's necessary is to edit the title description. I've done that on a few of them. Sure, so we need someone to do that. But a changelog that is *potentially* informative is not actually informative now. The previous changelogs were informative. Even if there are past examples of poor descriptions for the changelog, that is not not an excuse to make them all bugzilla reports. It is no more or less effort to fix the bugzilla titles than it is to edit the changelog. Who edited the changelog before? Can that person or people edit the bugzilla entries? I understand many people do not like the change to the changelog - but I ask for a reason that make sense. I keep hearing that the text is different, but that is simply not so. It's the same exact information. Even the categories are the same. I did a search for the above two examples in bugzilla, and I found nothing. Clearly, this is not the exact same information. With the new system, all changes should have a bugzilla entry for them. With the old, there were occasional vacuous statements in the changelog with no links to any discussion or just what it was. I found the statements in the changelog not requiring extra research. Yes, it is important to have background for the reasoning of a change. I agree that the statements should have any referenced bugzilla reports included. But if you are not interested in the background for why a change was made, or the discussion that resulted in the change, or the original concern that led to the change, it is tedious to have to sift through that information to get to the conclusion. Most changes can be summarized in one sentence for the casual observer. In the past, I could scan the changelog, look for interesting changes, and the ones I was more interested in, I could drill down into. A bug is a bug, and saying we fixed this bug, here was the original description: xxx is fine. But new/changed features should have a full explanation and, if necessary, examples right in the description. Look at the changelogs that list an issue number. All of them have the exact same text as the corresponding bugzilla title. Right, and for bugs, that is fine. For bugs where the bugzilla description completely describes the change, that is fine. For feature enhancements like std.array.replace compile error (string and immutable string), I can't determine anything from that, you might as well have just said Bug 1234. With bugzilla entries for each item in the changelog, you have: 1. a title 2. discussion 3. link to the pull request that shows the code that changed to implement it I don't disagree bug links should be in the changelog, nor do I really fundamentally disagree that replacing the changelog with a bugzilla query is a valid changelog. What I disagree with though is the position that the previous changelog entries that were hand-written were no more informative than the current changelog. 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. I know that there is the potential for malicious behavior, but thankfully we haven't seen any of that. If we do, we'll have to restrict write access to bugzilla. That'll be a sad day. It doesn't have to be deliberately malicious behavior. People think bug reports are bug reports, I've seen several cases where bug reports are re-opened with an issue that is
Re: D 2.062 release
On 2/17/2013 9:37 PM, Steven Schveighoffer wrote: 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. The changelog is up on github, anyone can create a pull request for it. I invite you to.
Re: D 2.062 release
On Sun, 17 Feb 2013 18:44:18 -0800 Walter Bright newshou...@digitalmars.com wrote: On 2/17/2013 6:11 PM, Steven Schveighoffer wrote: Let me give you some examples of new features std.array.replace compile error (string and immutable string) There's no Duration.max Document extern properly etc. Compare the earlier changelogs with the bugzilla entries. It's EXACTLY THE SAME TEXT. EXACTLY. No it isn't. First of all, it's now split across four separate pages. Five if you count the page that doesn't actually contain any real information besides the four links. Secondly, the new format contains loads of superfluous data. Did the old changelog page dedicate over 1/3 of the page to rows and rows and rows of nor P2 All No Owner RESO FIXE, none of wehich belongs in a changelog? No it didn't. Definitely NOT the exact same text. Third, the old changelog's formatting was overall jsut far more readable. Fourth, as people said, the wording in the old changelog was much more appropriate for a changelog. Yea, people can update the titles of the zilla entries: Thus making them *very strangely* worded for archived bug reports. But does that actually happen? No (And I'm unconviunced that it even should). Did changelog-appropriate wording happen with the old changelog? Yes. DO you really think that so many people would be so annoyed with the new format if there *weren't* real problems with it?
Re: D 2.062 release
On Sun, 17 Feb 2013 17:56:20 -0800 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). The changelog.html uses the same template as the rest of the dconf.org site. !-- Really? Not to be an ass, but how the *(^ is that fact going to help him read the changelog on his mobile when the changelog info *isn't on that page*? -- Erm, I mean, he's talking about the bugzilla-hosted pages with the actual changelog information.
Re: D 2.062 release
On Sun, 17 Feb 2013 21:30:27 -0500 Andrei Alexandrescu seewebsiteforem...@erdani.org wrote: On 2/17/13 8:02 PM, Walter Bright wrote: http://digitalmars.com/d/download.html The dlang.org site isn't updated yet, but the downloads are there. I've updated the website, too. Enjoy! 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.
Re: D 2.062 release
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. DO you really think that so many people would be so annoyed with the new format if there *weren't* real problems with it? I was far more annoyed at the very inaccurate incomplete changelogs caused by it being edited by hand. Obviously, the formatting of the changelog is important to several people. I seriously invite you to issue pull requests for it - it's all here: https://github.com/D-Programming-Language/d-programming-language.org
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. Thank you Walter Bright. I appreciate your work.
Re: D 2.062 release
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).
Re: D 2.062 release
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 Sunday, February 17, 2013 23:08:41 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). We should probably start generating the site from the latest released branch rather than master in order to avoid that sort of problem. - Jonathan M Davis
Re: D 2.062 release
On 2013-02-18 06:37, Steven Schveighoffer wrote: I agree, we need a better system. Manually edited has its faults, and the current system has its faults. We could have a section that is edited manually with some important highlights with proper full description of new features and deprecated/removed ones. Then, in addition to that we could have a link to bugzilla for the rest. -- /Jacob Carlborg
Re: D 2.062 release
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. -- /Jacob Carlborg
Re: D 2.062 release
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.
