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.
Re: DLL crash inside removethreadtableentry - where's the source code for that?
On 17.02.2013 04:07, Ben Davis wrote:
Hi,
The user-mode driver I'm working on (a 32-bit DLL) is crashing Windows
Media Player on exit. (Two other host apps exit fine.) I can catch it in
the Visual Studio debugger, but only see assembly language. Initially
I'm just after tips on where to find source for the bits of D that are
involved, but maybe someone will recognise the problem already...
I've gone through the assembly in some detail, and established that the
crash is inside some removethreadtableentry() code which is called
shortly before DllMain(DLL_THREAD_DETACH), and must look something like:
//tid is the Windows numeric thread ID for the current thread
removethreadtableentry(tid) {
foreach (i, obj in someObjArray1024EntriesLong) {
if (obj.someField == tid) goto foundIt;
}
return;
//When we get here, i is 1 (pretend it's in scope)
foundIt:
free(obj.something);//Does nothing, already 0
if (obj.somethingElse) { //Does nothing, already 0
CloseHandle(obj.somethingElse);
}
free(obj);//Crash inside this free()
}
Furthermore, I've established that:
- removethreadtableentry() doesn't get to foundIt for most threads.
_removethreadtableentry is a function in the DM C runtime library. It
has the bug that it tries to free a data record that has never been
allocated if the thread that loaded the DLL is terminated. This is the
entry at index 1.
Re: The DUB package manager
Am 16.02.2013 23:58, schrieb Rob T: I'm having good success using D itself as the build tool language, and I'm at the point now where I'm getting much better results than what I was getting out of using external build tools, so for me there's no looking back. I run rdmd on a .d script that I wrote that's setup to do exactly what I want. I did that, too, for automated and Linux builds. But this means that if you also want to work with an IDE for debugging and such things, you have to keep additional project files in sync. The DUB approach just combines the two (+ the package management) and also has less overhead than doing it with D (main function, imports, possibly distributing helper modules etc.). What is missing from D is a good library of functions that are generally useful for writing build scripts. Phobos already supplies a great deal of what is needed that can be used to construct what is missing. The benefit of using D is that I do not have to install and learn a secondary language or conform to a specific build format, or follow any weird restrictions. What I want to do is build my D code, not learn something new and perform acrobatics to get the job done. I can even use the same D process to build C/C++ code if I wanted to expand on it. But you will have to learn the API of the build script helpers, too. I'm not sure if this is actually less to learn than the JSON alternative. What I'm saying here is that I see no reason to use a language other than D itself as the build tool. What D can use is an addition to Phobos that supplies the necessary generalized functions that all build tools should supply, and I don't think there's all that much that's missing. For a package manager, some standards may be required, but it too can be done completely with D. Well, DUB is fully written in D, so the question is less D or not, but more if an additional intermediate layer for the package description makes sense or not. Why use json (which is a subset of javascript), or ruby, or python, etc? Is there something fundamentally wrong with D that makes it unsuitable for this role? I see the following points for the decision for data/JSON vs. D: - Meta information needs to be available to the package registry and for managing dependencies in general. Executing a script/program would imply a big performance risk, and worse, is a high security risk in case of the registry. So a data-driven approach is needed at least for the meta data anyway. - JSON is a nice standard format with generally low risk of errors. I agree that it is not the prettiest language in the world (although IMHO much better than something XML based). Generally the same recent discussion on the beta list for the dmd.conf format applies here, I'm not sure what is the best approach, but JSON at least is not too bad. To me the most interesting open question is this: Do we actually gain from programmatic support for the build description, or does it suffice to have a good purely descriptive system? If the former should be true for more than 1% of the cases, that would definitely be a good argument against pure data.
Re: The DUB package manager
Another issue: I understand why you are using json but it is not the best suited format IMHO. D put some restriction on module names, thus the format can be simplified. (...) Exporting to other formats will probably needed anyway. Peter I agree about the non-optimal syntax, but it comes down to nicer syntax (where JSON at least is not _too_ bad) vs. standard format (familiarity, data exchange, proven design and implementation). And while data exchange could worked around with export/import functions, considering that these files are usually just 4 to 20 lines long, I personally would put less weight on the syntax issue than on the others. BTW, I think YAML as a superset of JSON is also a good contender with nice syntax features, but also much more complex.
Re: The DUB package manager
On Sunday, February 17, 2013 09:12:00 Sönke Ludwig wrote: BTW, I think YAML as a superset of JSON is also a good contender with nice syntax features, but also much more complex. It's also whitespace-sensitive, which is downright evil IMHO. I'd take JSON over YAML any day. - Jonathan M Davis
Re: DIP26 reworked
On Sun, 2013-02-17 at 04:18 +0100, deadalnix wrote: It still introduce limitation for very poor reasons. You assumed people didn't understood you DIP but in fact, people did. Could you please explain what about the DIP is a limitation and how it affects you in practice? Maybe people understood it correctly, but I still don't understand what people don't like. So if you could explain how the DIP affects your code and why you don't like that, this would really help me to understand what the problem is. Thanks!
Re: The DUB package manager
On Sat, 2013-02-16 at 21:02 +0100, Johannes Pfau wrote: […] The benefit of splitting them in this way: You're forced to provide interfaces for the build tool to communicate with the package manager and every other build tool can use those interfaces as well. This way there are no second class build systems. Comment from a build veteran last Tuesday: I will not use any build system that cannot be used as a library. This is the modern way. -- 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: Java binaries
On Sunday, 17 February 2013 at 07:53:15 UTC, Walter Bright wrote: On 2/16/2013 7:26 PM, js.mdnq wrote: Would it ever be possible to compile D source directly to java to take advantage of what java offers. (e.g., the ability to run d code inside a browser) I'm not talking about necessarily fully fledged functionality(obviously stuff like asm isn't going to work) but basically the ability to use D's syntax and some of it's compiler features(mixins, templates, etc). Java doesn't have pointers, so right off the bat there'd be big problems. Java does have pointers... you just can't get to them easily. At the very least, you could allocate and manage your own chunk of memory and do all the pointer arithmetic yourself on that chunk. This would require the chunk to be pinned in some way and the GC to be turned off but it is an option. Also, have you looked much at sun.misc.Unsafe? Or maybe one could use the JNI to write an external memory manager for each platform and all pointer arithmetic is passed through that. Of course, if one goes this far then any javaD would need to be able to work well with importing java libraries to be of any use.
Win64, SUBSYSTEM:WINDOWS and friends
MS linker by default allocates console window for programm if he see a main function as entry point and not allocates if he see a WinMain function as entry point. So, if I don't want ugly console window for gui app, I can specify SUBSYTEM:WINDOWS linker flag and change a main to WinMain. But I want to use ENTRY linker flag and do not modify source code. With ENTRY flag a executable successfully compiled, but crashes at startup. Any valid D Way workaround? -- dmd -release -m64 -L/SUBSYSTEM:WINDOWS fl64.lib fl_test.d LIBCMT.lib(wincrt0.obj) : error LNK2019: unresolved external symbol WinMain referenced in function __tmainCRTStartup fl_test.exe : fatal error LNK1120: 1 unresolved externals --- errorlevel 1120 -- When compiling without modification in source. P.S.: Win 8 64 bit, Dmd 2.061. fl64.lib and fl64.dll - custom library.
Re: The DUB package manager
On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote: I agree about the non-optimal syntax, but it comes down to nicer syntax (where JSON at least is not _too_ bad) vs. standard format (familiarity, data exchange, proven design and implementation). And while data exchange could worked around with export/import functions, considering that these files are usually just 4 to 20 lines long, I personally would put less weight on the syntax issue than on the others. BTW, I think YAML as a superset of JSON is also a good contender with nice syntax features, but also much more complex. Peter's point is more important than the above response indicates. Using JSON (YAML, whatever) is a recipe for failure. The syntax is data exchange facing, whereas writing and maintaining a build script (even if it is only 4 lines long), is a human activity. Do not underestimate the reaction why do I have to write this data exchange format? The rapid demise of XML, Ant, Maven, etc. is testament to people awakening to the fact that they were forced to use manually a language designed for another purpose. Where Gradle, and before it Gant, Buildr, etc., got it right was to use an internal DSL mentality to ask what is a written form that has affordance for the user that we can interpret in some way to deliver for computation the data needed. Groovy provides the infrastructure for Gradle, but people write Gradle scripts not Groovy. The build/packaging system does the hard work, not the user. The lesson from SBT is that by judicious cleverness, a trivially simple internal DSL can be derived that does all the work using Scala. The only downside to SBT scripts is the extra newline needed everywhere. Surely D is better than Scala for this? So if D is to contribute to build and package management, it should be looking to replace Make, CMake, SCons, Waf, Gradle. It should be able to build D systems yes, and manage D packages, but also look to build C, C ++, Fortran, and interlink all of them. Clearly starting small is good: a successful large system always evolves from a successful small system; designed large systems always fail. (cf. Gall, Systemantics, 1975) If all the energy around DUB and Orbit leads to the situation where D cannot be used to create an internal DSL for describing build and package/artefact management, then D has failed. -- 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: Java binaries
Sorry to come to this thread late, and apologies if I am missing the real point to this thread. On Sun, 2013-02-17 at 10:13 +0100, js.mdnq wrote: On Sunday, 17 February 2013 at 07:53:15 UTC, Walter Bright wrote: On 2/16/2013 7:26 PM, js.mdnq wrote: Would it ever be possible to compile D source directly to java to take advantage of what java offers. (e.g., the ability to run d code inside a browser) Running Java in the browser is now unlikely to ever happen again. If anything the target should be JavaScript or Dart, and even Dart would be a huge risk. I'm not talking about necessarily fully fledged functionality(obviously stuff like asm isn't going to work) but basically the ability to use D's syntax and some of it's compiler features(mixins, templates, etc). A lot of work is going into creating Python executability in browsers. Skulpt, Brython, etc., but traction is minimal. Browsers mean HTML5 and ECMAScript (aka JavaScript) Java doesn't have pointers, so right off the bat there'd be big problems. Java does have pointers... you just can't get to them easily. At the very least, you could allocate and manage your own chunk of memory and do all the pointer arithmetic yourself on that chunk. This would require the chunk to be pinned in some way and the GC to be turned off but it is an option. There is the possibility of using NIO2 buffers in ways that were never envisaged. This is effectively what happened in RTSJ, which was a real-time systems framework using Java and JVM. RTSJ sadly was too far ahead of its time and so died. The last vestige will die when the Mars Rover does. Also, have you looked much at sun.misc.Unsafe? You really don't want to go there ;-) Obviously for garbage collection and concurrency and parallelism control you have to go there so as to subvert the JVM object model. The question is that unless you are working on the G1 garbage collector or java.util.concurrent primitives, is there any point? Or maybe one could use the JNI to write an external memory manager for each platform and all pointer arithmetic is passed through that. Of course, if one goes this far then any javaD would need to be able to work well with importing java libraries to be of any use. Sounds like a mountain rather than a molehill. We are looking at something vaguely analogous to get CUDA and OpenCL working from GPars/Groovy/Java. Good for users, very ugly for implementors. Unless there is a mapping of the semantics of a language to the intermediate code of the platform, then it is better not to bash head on wall but to go put energies into something more productive. If the D semantics cannot be mapped down to the JVM bytecodes, then D is not a language you want to run on the JVM. Given Java/Scala/Kotlin/Ceylon/Groovy as the static languages and Groovy/JRuby/Jython/Closure as the dynamic languages (yes Groovy is correctly in both categories!) is there really a market for a minor player native code language trying to ease itself onto the JVM platform? The world is split into native code, PVM, JVM, JavaScript/ECMAScript. D only really has a play in one of these, and needs to get real traction there first before looking for new lands to conquer. Else it risks being seen as a solution looking for a problem to solve. -- 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: Win64, SUBSYSTEM:WINDOWS and friends
Oh, sorry. Valid linker flag to do this -L/ENTRY:_Dmain
Re: The DUB package manager
Am 17.02.2013, 10:24 Uhr, schrieb Russel Winder: On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote: I agree about the non-optimal syntax, but it comes down to nicer syntax (where JSON at least is not _too_ bad) vs. standard format (familiarity, data exchange, proven design and implementation). And while data [...] Peter's point is more important than the above response indicates. I think so too. And I don't believe that it will stay by a few lines only because the demands will increase in the course of time. Think about including C/C++ compiler, a project manager etc. With a syntax as I suggested or something similar everything is mapped direct onto an AA and is easily scanned by the build system or other tools. Regarding json: It is designed for data exchange between different sources, not to be edited by people. It is too annoying and error- prone to wrap each string into quotes. And people have to edit the configuration file. Better to start in a well suited format. Peter
Re: The DUB package manager
Am 17.02.2013 11:21, schrieb Peter Sommerfeld: Am 17.02.2013, 10:24 Uhr, schrieb Russel Winder: On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote: I agree about the non-optimal syntax, but it comes down to nicer syntax (where JSON at least is not _too_ bad) vs. standard format (familiarity, data exchange, proven design and implementation). And while data [...] Peter's point is more important than the above response indicates. I think so too. And I don't believe that it will stay by a few lines only because the demands will increase in the course of time. Think about including C/C++ compiler, a project manager etc. If I were to vote for anything, that would be to never support C/C++ or any other foreign language builds. There are enough tools for that and I don't see enough value for the huge complexity that this route would add (just consider autotools or cmake). Not sure what you mean by project manager, but right now, I see no reason why it shouldn't be possible to keep the package/build description very compact. If something gets complex anyway, maybe it should be broken up into multiple packages (e.g. one with the C/C++ stuff + bindings and one using the C++ stuff). With a syntax as I suggested or something similar everything is mapped direct onto an AA and is easily scanned by the build system or other tools. Regarding json: It is designed for data exchange between different sources, not to be edited by people. It is too annoying and error- prone to wrap each string into quotes. And people have to edit the configuration file. Better to start in a well suited format. This is just wrong. JSON is just JavaScript, which is meant for human editing just as D or a custom DSL is. There definitely are nicer syntaxes, but this is putting it out of proportion, IMO. I'm surely not against using a different format, but all arguments must be weighted against each other here.
Re: My codebase have reached the critical size
On 17.02.2013 8:27, deadalnix wrote: On Saturday, 16 February 2013 at 09:54:10 UTC, Walter Bright wrote: On 2/16/2013 1:37 AM, deadalnix wrote: I cannot use separate compilation to mitigate the problem as some symbol are not emitted properly (so I get linker errors). Are there bugzilla entries for these? So reduced thing with dmd from git, and this still boils down to that : http://d.puremagic.com/issues/show_bug.cgi?id=8997 I think http://d.puremagic.com/issues/show_bug.cgi?id=9485 is about this bug too.
Re: Win64, SUBSYSTEM:WINDOWS and friends
On Sunday, 17 February 2013 at 09:13:57 UTC, Michael wrote: Any valid D Way workaround? -L/SUBSYSTEM:WINDOWS -L/ENTRY:mainCRTStartup
Re: The DUB package manager
Am 17.02.2013 10:24, schrieb Russel Winder: On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote: I agree about the non-optimal syntax, but it comes down to nicer syntax (where JSON at least is not _too_ bad) vs. standard format (familiarity, data exchange, proven design and implementation). And while data exchange could worked around with export/import functions, considering that these files are usually just 4 to 20 lines long, I personally would put less weight on the syntax issue than on the others. BTW, I think YAML as a superset of JSON is also a good contender with nice syntax features, but also much more complex. Peter's point is more important than the above response indicates. Using JSON (YAML, whatever) is a recipe for failure. The syntax is data exchange facing, whereas writing and maintaining a build script (even if it is only 4 lines long), is a human activity. Do not underestimate the reaction why do I have to write this data exchange format? The rapid demise of XML, Ant, Maven, etc. is testament to people awakening to the fact that they were forced to use manually a language designed for another purpose. I don't agree with this, as already said in my response to Peter. We are talking about rather small syntactic differences here (i.e. ',' vs ';' and omitting quotes) and XML adds a lot more overhead than the quotes around key names. Ant and the like also have the awkward approach of not only using a verbose format such as XML, but they also try to express procedural build scripts in that language, which is insane. But my idea for dub is to completely avoid the need for procedural build steps apart from invoking an external tool (which should be needed only for a minority of D projects). Where Gradle, and before it Gant, Buildr, etc., got it right was to use an internal DSL mentality to ask what is a written form that has affordance for the user that we can interpret in some way to deliver for computation the data needed. Groovy provides the infrastructure for Gradle, but people write Gradle scripts not Groovy. The build/packaging system does the hard work, not the user. The lesson from SBT is that by judicious cleverness, a trivially simple internal DSL can be derived that does all the work using Scala. The only downside to SBT scripts is the extra newline needed everywhere. Surely D is better than Scala for this? If by internal DSL, you mean compiled as D source code directly or indirectly, please also consider the server side issues (i.e. danger of DoS and hijacking the system). So if D is to contribute to build and package management, it should be looking to replace Make, CMake, SCons, Waf, Gradle. It should be able to build D systems yes, and manage D packages, but also look to build C, C ++, Fortran, and interlink all of them. Clearly starting small is good: a successful large system always evolves from a successful small system; designed large systems always fail. (cf. Gall, Systemantics, 1975) I think building foreign languages are better left to specialized tools. It should be possible to invoke those automatically, but adding their functionality directly to a D build system would blow up the complexity dramatically for an uncertain return of value (what would be the problem invoking make to build a C dependency?). My question if we can get by without procedural build scripts is still open. If we could, it would give great benefits in simplicity of the system and its usage. This may require a change in conventions for some projects, but I think that can be worth it. Maybe it would be good to have some concrete examples of complex build scenarios to better judge what is possible and what may be problematic.
Re: DLL crash inside removethreadtableentry - where's the source code for that?
On 17/02/2013 07:56, Rainer Schuetze wrote: _removethreadtableentry is a function in the DM C runtime library. It has the bug that it tries to free a data record that has never been allocated if the thread that loaded the DLL is terminated. This is the entry at index 1. That's a good start :) Can it be fixed? Who would be able to do it? Or is there some code I can put in my project that will successfully work around the issue? I get the impression the source is available for money. I found this page http://www.digitalmars.com/download/freecompiler.html which mentions complete library source under a link to the shop. I *could* buy it and see if I can fix it myself, but it seems a bit risky. By the way, thanks for Visual D :)
Re: The DUB package manager
Am 17.02.2013, 11:58 Uhr, schrieb Sönke Ludwig: Am 17.02.2013 11:21, schrieb Peter Sommerfeld: Not sure what you mean by project manager, but right now, I see no reason why it shouldn't be possible to keep the package/build description very compact. If a good configuration format for D is established, it will (or should) be used everywhere. Regarding json: It is designed ... This is just wrong. JSON is just JavaScript, which is meant for human editing just as D or a custom DSL is. OK, that is not important. The point is: Config files have to be edited by humans and all the quotes are simply superfluous, annoying and error-prone. The appropriate file format has low-priority and may be discussed when a general decision about using dub as build-tool has been made. I am for it! So let us continue with more important issues for now. Peter
Re: The DUB package manager
On Sun, 17 Feb 2013 09:24:08 + Russel Winder rus...@winder.org.uk wrote: Using JSON (YAML, whatever) is a recipe for failure. The syntax is data exchange facing, whereas writing and maintaining a build script (even if it is only 4 lines long), is a human activity. Do not underestimate the reaction why do I have to write this data exchange format? The rapid demise of XML, Ant, Maven, etc. is testament to people awakening to the fact that they were forced to use manually a language designed for another purpose. [...] If all the energy around DUB and Orbit leads to the situation where D cannot be used to create an internal DSL for describing build and package/artefact management, then D has failed. I half-agree with you. Where I disagree is with the idea that it's an issue of embedded DSL (good) vs data language (bad). I think the real issue is just simply having good clean syntax for what you need to accomplish. Note that your examples of rapid demise (XML, Ant, Maven) are all XML, which is notoriously over-verbose. JSON has much the same problem, just to a lesser degree: It's a subset of human-intended JavaScript, yes, but it just happens to be an unfortunately verbose subset (although not to the extreme degree as XML). Then on the flipside, we have the example of INI files: Definitely a purely data-language, definitely not an embedded DSL, and yet that's never been a hindrance for it: it's been a lasting success for many things. And the only time anyone complains about it is when more power is needed. (And no, I'm not suggesting DUB or Orbit use INI files. Again, specifically because more power is needed here.) So I agree JSON/YAML carries an unfortunate risk of turning people off - but because of excess syntax, not because it's a data language or because it's not embedded in D. I think SDL (Simple Declarative Language) hits the sweet spot: http://sdl.ikayzo.org/display/SDL/Language+Guide FWIW, I just resumed working on a D parser for SDL. EVen if SDL doesn't get used for DUB or Orbit or dmd.conf, I think it'll still be a great thing to have available. It's such a simple grammar, I don't think it'll take long to reach a usable point.
Re: The DUB package manager
Am 17.02.2013 12:47, schrieb Nick Sabalausky: I think SDL (Simple Declarative Language) hits the sweet spot: http://sdl.ikayzo.org/display/SDL/Language+Guide FWIW, I just resumed working on a D parser for SDL. EVen if SDL doesn't get used for DUB or Orbit or dmd.conf, I think it'll still be a great thing to have available. It's such a simple grammar, I don't think it'll take long to reach a usable point. I have to say that it looks almost exactly like the DSLs I've been using for all of my internal stuff, so I really like it (although I've never heard of it before). It would require a bit of a rework because it doesn't map to JSON 1-to-1, though.
Re: Java binaries
On Sunday, 17 February 2013 at 03:26:13 UTC, js.mdnq wrote: Would it ever be possible to compile D source directly to java to take advantage of what java offers. (e.g., the ability to run d code inside a browser) I'm not talking about necessarily fully fledged functionality(obviously stuff like asm isn't going to work) but basically the ability to use D's syntax and some of it's compiler features(mixins, templates, etc). depends on what you mean with run inside a browser, I would use NaCl instead, if I wanted to run D in a browser, but of course it requires Chrome. http://code.google.com/p/nativeclient/
Re: My codebase have reached the critical size
On Sunday, 17 February 2013 at 05:25:28 UTC, kenji hara wrote: 2013/2/17 deadalnix deadal...@gmail.com On Saturday, 16 February 2013 at 09:54:10 UTC, Walter Bright wrote: On 2/16/2013 1:37 AM, deadalnix wrote: I cannot use separate compilation to mitigate the problem as some symbol are not emitted properly (so I get linker errors). Are there bugzilla entries for these? So reduced thing with dmd from git, and this still boils down to that : http://d.puremagic.com/issues/**show_bug.cgi?id=8997http://d.puremagic.com/issues/show_bug.cgi?id=8997 Just now, I posted another fix for bug 8997. https://github.com/D-Programming-Language/dmd/pull/1667 OK, tested and it does work ! otsukare sama ! But . . . This issue was hidding another one. I still have linking issue. I'm dustmiting it right now, but this will take a while !
Re: WPFfor d
On 2013-02-17 04:28, js.mdnq wrote: WPF is pretty nice for .net. Is there any work towards building a nice gui presentation layer for D, something that has or will have all those nice modern features we are seeing in stuff like WPF, QT, etc? DWT is a GUI library written in D. It's a port of the Java library SWT. I'm don't know exactly which features you're referring to. DWT: https://github.com/d-widget-toolkit/dwt -- /Jacob Carlborg
Re: The DUB package manager
On 2013-02-16 20:35, Russel Winder wrote: Thus I suggest that it is not that the build tool is embedded in the package manager but that package and dependency management is part of the build system. In general yes, but I think that there should be two separated tools and handle what they're designed to handled. On top of that they should have great integration with each other. I'm not talking about processes invoking each other. I'm talking about both tools are built as libraries and can be easily integrated with each other. Say we have build tool A and package manager B. I don't want to force anyone using A just to use B, or the opposite. -- /Jacob Carlborg
Re: WPFfor d
On Sunday, 17 February 2013 at 03:28:29 UTC, js.mdnq wrote: WPF is pretty nice for .net. Is there any work towards building a nice gui presentation layer for D, something that has or will have all those nice modern features we are seeing in stuff like WPF, QT, etc? WPF - hardware accelerated gui. gtk3 (in D - gtkD) or any with open gl window support. If about xaml - Qt/qml, gtk/glade etc. If I understand correctly ;) But even MS promote C++/xaml without wpf. Wpf generally for corporate users, legacy reasons.
Re: The DUB package manager
On 2013-02-16 23:58, Rob T wrote: Why use json (which is a subset of javascript), or ruby, or python, etc? Is there something fundamentally wrong with D that makes it unsuitable for this role? You generally will get a more verbose syntax using D. It's not really made to execute statements on the top level. -- /Jacob Carlborg
Re: DIP26 reworked
On Sunday, 17 February 2013 at 08:35:44 UTC, Robert wrote: On Sun, 2013-02-17 at 04:18 +0100, deadalnix wrote: It still introduce limitation for very poor reasons. You assumed people didn't understood you DIP but in fact, people did. Could you please explain what about the DIP is a limitation and how it affects you in practice? Maybe people understood it correctly, but I still don't understand what people don't like. So if you could explain how the DIP affects your code and why you don't like that, this would really help me to understand what the problem is. Thanks! I'm sorry this is reversed logic. You introduce limitation (IE no UFCS setter for instance) it is up to you to justify the tradeoff. Secondly, I still think this proposal is bad for getter as they are now both bad function and bad properties. For instance typeof(a) == int and typeof(a) == function is really bad. Plus it cascade into all kind of possible weird cases. What about ternary operator ? Coma expressions ?
Re: The DUB package manager
On 2013-02-17 02:49, Nick Sabalausky wrote:
I largely agree, except:
1. For simple projects with trivial build system requirements, D is
overkill compared to a purely data-only language.
It might be but the syntax is no that different:
Yaml:
flags: -l-L. -release
foo: bar
Json:
{
flags: -l-L. -release
foo: bar
}
D:
flags = -l-L. -release;
foo = bar;
In this example D has less syntax than Json.
--
/Jacob Carlborg
Re: The DUB package manager
On 2013-02-17 09:02, Sönke Ludwig wrote: But you will have to learn the API of the build script helpers, too. I'm not sure if this is actually less to learn than the JSON alternative. You still have to learn this: http://registry.vibed.org/package-format - Meta information needs to be available to the package registry and for managing dependencies in general. Executing a script/program would imply a big performance risk, and worse, is a high security risk in case of the registry. So a data-driven approach is needed at least for the meta data anyway. You can just serialize the D data structure to XML/JSON to make it safe for the registry. -- /Jacob Carlborg
Re: The DUB package manager
On 2013-02-16 20:37, H. S. Teoh wrote: I think Sönke's idea is actually very good. I know we all have our own preferences for build systems (I know I do -- for example, I abhor anything to do with makefiles), but having a standardized way to specify a build has many advantages. Imagine the user-unfriendliness of downloading a bunch of packages from the D package manager, only to discover that one requires make, another requires cmake, another requires SCons, another requires Ant, pretty soon, what should be just a simple automatic download turns into a nightmare of installing 20 different build systems just so you can use a bunch of packages from the standard D package manager. Having a standardized way of generating build scripts is good, because then the D package manager can target the *end user*'s preferred build system, rather than whatever build system the package writers chose. The package writers can just specify how to build the stuff, then let the D packager generate makefiles for one user, Ant files for another user, etc.. This makes it much more friendly to use, and therefore, more likely people will actually use it. The build system doesn't need to embedded in the package manager just to have a standardize build system. See this: http://forum.dlang.org/thread/kfoei9$bmd$1...@digitalmars.com?page=4#post-kfqium:24unf:241:40digitalmars.com -- /Jacob Carlborg
Re: DIP26 reworked
I'm sorry this is reversed logic. You introduce limitation (IE no UFCS setter for instance) it is up to you to justify the tradeoff. I thought I did, if you disagree I think it is not too much to ask why? I surely might have missed really good use cases, that is why I want to discuss it, so if you have one, please tell me. For instance typeof(a) == int and typeof(a) == function is really bad. Plus it cascade into all kind of possible weird cases. What about ternary operator ? Coma expressions ? I in fact forgot about those issues, I will check them out. Thanks! Although this critique does not really apply to DIP26, but rather DIP23 (they still need to be resolved as DIP26 builds on the concept of optional parentheses of DIP23) but I would like to know what is bad about the things DIP26 introduces and most importantly why. Thanks again for constructive feedback.
Re: DIP26 reworked
On Sunday, 17 February 2013 at 12:55:46 UTC, Robert wrote: Although this critique does not really apply to DIP26, but rather DIP23 (they still need to be resolved as DIP26 builds on the concept of optional parentheses of DIP23) but I would like to know what is bad about the things DIP26 introduces and most importantly why. Thanks again for constructive feedback. Yes, I oppose the same critic to DIP23.
Re: The DUB package manager
Am 17.02.2013 13:47, schrieb Jacob Carlborg: On 2013-02-17 09:02, Sönke Ludwig wrote: But you will have to learn the API of the build script helpers, too. I'm not sure if this is actually less to learn than the JSON alternative. You still have to learn this: http://registry.vibed.org/package-format Yes, I meant that with the JSON alternative. JSON itself is so simple and widely known, that I think it can be neglected compared to the possible fields. - Meta information needs to be available to the package registry and for managing dependencies in general. Executing a script/program would imply a big performance risk, and worse, is a high security risk in case of the registry. So a data-driven approach is needed at least for the meta data anyway. You can just serialize the D data structure to XML/JSON to make it safe for the registry. But that would need to happen as a separate step and then there would be two redundant files in the repository, with the usual danger of inconsistencies between the two. Since a build script may behave differently on different systems, it could also happen that the contents cannot really be described as JSON/XML. For example someone might get the idea to search the system for some library and only add a corresponding dependency if it is found. There would be no way for the registry to represent that.
Re: The DUB package manager
On 2013-02-16 21:02, Johannes Pfau wrote:
Having a common standard build tool is always good. But some kind of
projects require custom build scripts (calling swig, generating
interface files for ipc stuff, executing the C compiler to check if a
function is available to disable / enable additional features, calling
pkgconfig for some reason, compiling additional c/c++ files, assembling
additional files, ...).
I think splitting DUB into a package manger and build tool would be a
good idea. Ship them as one package, so that everyone using the package
manager also has the build tool installed. And integrate them as much
as possible, the default setup can still work exactly the same as if
they were integrated.
The benefit of splitting them in this way: You're forced to provide
interfaces for the build tool to communicate with the package manager
and every other build tool can use those interfaces as well. This way
there are no second class build systems.
As an example:
package.json
{
name: myproject,
description: A little web service of mine.,
authors: [Peter Parker],
homepage: http://myproject.com;,
license: GPL v2,
dependencies: {
vibe-d: =0.7.11
},
build: DUB
}
build.json
{
configurations: {
metro-app: {
versions: [MetroApp],
libs: [d3d11]
},
desktop-app: {
versions: [DesktopApp],
libs: [d3d9]
}
}
}
doing a dub-pkg install myproject should fetch the sources, then call
dub-build build.json. dub-build will have to ask the package manager
for some information: dub-pkg package.json --query dependencies,
dub-pkg package.json --query --package=vibe.d --link-path. Or it
might require some additional actions: dup-pkg --install-dependency
d3d9
Exactly. But I see no reason for communicating with processes. Just make
them both into libraries and call functions plain functions.
--
/Jacob Carlborg
Re: The DUB package manager
On 2013-02-16 23:19, Peter Sommerfeld wrote: Another issue: I understand why you are using json but it is not the best suited format IMHO. D put some restriction on module names, thus the format can be simplified. Compare: Inventing a new format is pointless. I you want it less verbose Yaml is an alternative. -- /Jacob Carlborg
Re: The DUB package manager
Am 17.02.2013, 11:58 Uhr, schrieb Sönke Ludwig: Am 17.02.2013 11:21, schrieb Peter Sommerfeld: Not sure what you mean by project manager, but right now, I see no reason why it shouldn't be possible to keep the package/build description very compact. If a good configuration format for D is established, it will (or should) be used everywhere. Regarding json: It is designed ... This is just wrong. JSON is just JavaScript, which is meant for human editing just as D or a custom DSL is. OK, that is not important. The point is: Config files have to be edited by humans and all the quotes are simply superfluous, annoying and error-prone. The appropriate file format has low-priority and may be discussed when a general decision about using dub as build-tool has been made. I am for it! So let us continue with more important issues for now. Peter
Re: The DUB package manager
Am 17.02.2013, 14:03 Uhr schrieb Jacob Carlborg: On 2013-02-16 23:19, Peter Sommerfeld wrote: Another issue: I understand why you are using json but it is not the best suited format IMHO. D put some restriction on module names, thus the format can be simplified. Compare: Inventing a new format is pointless. I you want it less verboseYaml is an alternative. If you prefer indentation. I would never touch it. Peter
Re: The DUB package manager
Am 17.02.2013, 11:58 Uhr, schrieb Sönke Ludwig: Am 17.02.2013 11:21, schrieb Peter Sommerfeld: Not sure what you mean by project manager, but right now, I see no reason why it shouldn't be possible to keep the package/build description very compact. If a good configuration format for D is established, it will (or should) be used everywhere. Regarding json: It is designed ... This is just wrong. JSON is just JavaScript, which is meant for human editing just as D or a custom DSL is. OK, that is not important. The point is: Config files have to be edited by humans and all the quotes are simply superfluous, annoying and error-prone. The appropriate file format has low-priority and may be discussed when a general decision about using dub as build-tool has been made. I am for it! So let us continue with more important issues for now. Peter
Re: The DUB package manager
On Sun, 17 Feb 2013 14:28:14 +0100
Peter Sommerfeld nore...@rubrica.at wrote:
Am 17.02.2013, 14:03 Uhr schrieb Jacob Carlborg:
On 2013-02-16 23:19, Peter Sommerfeld wrote:
Another issue: I understand why you are using json but it is
not the best suited format IMHO. D put some restriction on
module names, thus the format can be simplified. Compare:
Inventing a new format is pointless. I you want it less verboseYaml
is an alternative.
If you prefer indentation. I would never touch it.
Plus, some of it's syntax is rather non-intuitive:
!!map {
? !!str ---
: !!str foo,
? !!str ...,
: !!str bar
}
WTF?
Re: The DUB package manager
On 2013-02-17 10:24, Russel Winder wrote:
On Sun, 2013-02-17 at 09:12 +0100, Sönke Ludwig wrote:
I agree about the non-optimal syntax, but it comes down to nicer syntax
(where JSON at least is not _too_ bad) vs. standard format (familiarity,
data exchange, proven design and implementation). And while data
exchange could worked around with export/import functions, considering
that these files are usually just 4 to 20 lines long, I personally would
put less weight on the syntax issue than on the others.
BTW, I think YAML as a superset of JSON is also a good contender with
nice syntax features, but also much more complex.
Peter's point is more important than the above response indicates.
Using JSON (YAML, whatever) is a recipe for failure. The syntax is data
exchange facing, whereas writing and maintaining a build script (even if
it is only 4 lines long), is a human activity. Do not underestimate the
reaction why do I have to write this data exchange format? The rapid
demise of XML, Ant, Maven, etc. is testament to people awakening to the
fact that they were forced to use manually a language designed for
another purpose.
Where Gradle, and before it Gant, Buildr, etc., got it right was to use
an internal DSL mentality to ask what is a written form that has
affordance for the user that we can interpret in some way to deliver for
computation the data needed. Groovy provides the infrastructure for
Gradle, but people write Gradle scripts not Groovy. The build/packaging
system does the hard work, not the user.
The lesson from SBT is that by judicious cleverness, a trivially simple
internal DSL can be derived that does all the work using Scala. The only
downside to SBT scripts is the extra newline needed everywhere. Surely D
is better than Scala for this?
Unfortunately I don't think D is better than Scala. I would say that you
can do everything/most that Scala/Groovy can but not with as nice syntax
as Scala/Groovy.
So if D is to contribute to build and package management, it should be
looking to replace Make, CMake, SCons, Waf, Gradle. It should be able to
build D systems yes, and manage D packages, but also look to build C, C
++, Fortran, and interlink all of them. Clearly starting small is good:
a successful large system always evolves from a successful small system;
designed large systems always fail. (cf. Gall, Systemantics, 1975)
I don't think it necessarily needs to be able to build non-D projects.
I'm looking at Gradle now. The first example they show is this:
task hello {
doLast {
println 'Hello world!'
}
}
That translated to D would probably look something like this:
task(hello, {
doLast({
writeln(Hello World);
});
});
Which in my opinion is a lot uglier the the original Groovy code. A
couple of problems with D:
* Semicolons
* Parentheses when making function calls
* No block syntax. Not possible to pass a delegate after the regular
arguments
If all the energy around DUB and Orbit leads to the situation where D
cannot be used to create an internal DSL for describing build and
package/artefact management, then D has failed.
As I've said. I will change Orbit to use D for the DSL.
--
/Jacob Carlborg
Re: The DUB package manager
On 2013-02-16 20:07, Sönke Ludwig wrote: I was thinking more along the lines of make, cmake, D based build scripts in the form as proposed in the past here and others. Such procedural build files often tend to get bloated over time and hard to work with. While this is not necessarily a problem with the tools itself, it can still make people look for alternatives. That said, if a scripting language is used (almost) purely to provide a declarative system as in your example, it doesn't have to be bad at all. The question that arguably remains is just if the added flexibility is actually useful or necessary and if such a thing pulls its own weight (WRT implementation and API complexity). I think so. -- /Jacob Carlborg
Re: The DUB package manager
Am 17.02.2013 14:51, schrieb Jacob Carlborg: On 2013-02-16 20:07, Sönke Ludwig wrote: I was thinking more along the lines of make, cmake, D based build scripts in the form as proposed in the past here and others. Such procedural build files often tend to get bloated over time and hard to work with. While this is not necessarily a problem with the tools itself, it can still make people look for alternatives. That said, if a scripting language is used (almost) purely to provide a declarative system as in your example, it doesn't have to be bad at all. The question that arguably remains is just if the added flexibility is actually useful or necessary and if such a thing pulls its own weight (WRT implementation and API complexity). I think so. Any examples?
Re: The DUB package manager
On 2013-02-17 10:01, Russel Winder wrote: Comment from a build veteran last Tuesday: I will not use any build system that cannot be used as a library. This is the modern way. Agree. -- /Jacob Carlborg
Re: The DUB package manager
On 2013-02-17 13:58, Sönke Ludwig wrote: But that would need to happen as a separate step and then there would be two redundant files in the repository, with the usual danger of inconsistencies between the two. The tool generates the JSON/Yaml/XML from the D script. The user never have to see the Json file. Since a build script may behave differently on different systems, it could also happen that the contents cannot really be described as JSON/XML. For example someone might get the idea to search the system for some library and only add a corresponding dependency if it is found. There would be no way for the registry to represent that. Sure, it's always possible to do stupid things. -- /Jacob Carlborg
Re: The DUB package manager
On 2013-02-17 14:40, Nick Sabalausky wrote:
Plus, some of it's syntax is rather non-intuitive:
!!map {
? !!str ---
: !!str foo,
? !!str ...,
: !!str bar
}
WTF?
I have used Yaml quite a lot but I have never seen that. I think the
below is very intuitive:
point:
x: 1
y: 2
--
/Jacob Carlborg
Re: The DUB package manager
On 2013-02-17 14:53, Sönke Ludwig wrote: Any examples? The DWT build script if fairly complex: D: https://github.com/d-widget-toolkit/dwt/blob/master/build.d Rakefile: https://github.com/d-widget-toolkit/dwt/blob/master/rakefile -- /Jacob Carlborg
Re: The DUB package manager
Am 17.02.2013 15:09, schrieb Jacob Carlborg: On 2013-02-17 14:53, Sönke Ludwig wrote: Any examples? The DWT build script if fairly complex: D: https://github.com/d-widget-toolkit/dwt/blob/master/build.d Rakefile: https://github.com/d-widget-toolkit/dwt/blob/master/rakefile I see some things like windows/non-windows specific flags and a lot of path handling and infrastructure stuff (which the build tool would do itself). Anything in particular that you think is not easily doable with the data driven approach? BTW, I think build files like these are the perfect example for what I mean with complexity and scaring away people. I'm sure it all makes sense, but my vision of a build system is that it goes out of the developers way instead of forcing him to maintain a whole sister project alongside the actual code.
Re: The DUB package manager
Am 17.02.2013 15:04, schrieb Jacob Carlborg: On 2013-02-17 13:58, Sönke Ludwig wrote: But that would need to happen as a separate step and then there would be two redundant files in the repository, with the usual danger of inconsistencies between the two. The tool generates the JSON/Yaml/XML from the D script. The user never have to see the Json file. But the registry gets its information about a package directly from the github repository (this is quite a central idea), so it must also be committed there. Since a build script may behave differently on different systems, it could also happen that the contents cannot really be described as JSON/XML. For example someone might get the idea to search the system for some library and only add a corresponding dependency if it is found. There would be no way for the registry to represent that. Sure, it's always possible to do stupid things. But at least not this particular this with the data driven approach ;)
Re: The DUB package manager
Don't really have a vision how it will look like in practice based on released data, but looking at current discussion I'd like to state that I am most interested in a centralized library/app list, dependency tracker and an easy way to get sources. Support for a popular build systems may be fine as a bonus, but only as an added feature, with no coupling. I'd hate to see a ruby gem (or similar) hell pushed as a D way. Packaging is best done (and should be) by OS package manager, not hundreds of languages-specific managers. Good language package manager in my opinion is just an information source for OS package builders.
Re: The DUB package manager
On 2013-02-17 15:32, Sönke Ludwig wrote: But the registry gets its information about a package directly from the github repository (this is quite a central idea), so it must also be committed there. Aha, that would be a problem. With Orbit you build a package out of an orbspec (the DSL) and the package will contain the meta info. -- /Jacob Carlborg
Re: The DUB package manager
On 2013-02-17 15:28, Sönke Ludwig wrote: I see some things like windows/non-windows specific flags and a lot of path handling and infrastructure stuff (which the build tool would do itself). The D script contains a lot of utility functions that would be available in the build tool. It emulates the rakefile to stay backwards compatible. Anything in particular that you think is not easily doable with the data driven approach? I don't know the build scripts very well since I have not written them. It has several targets. Base, swt, snippets and so on. BTW, I think build files like these are the perfect example for what I mean with complexity and scaring away people. I'm sure it all makes sense, but my vision of a build system is that it goes out of the developers way instead of forcing him to maintain a whole sister project alongside the actual code. I really hate that build script. I really hope that a proper build system will handle DWT with just a simple build script. -- /Jacob Carlborg
Re: The DUB package manager
On 2013-02-17 15:40, Dicebot wrote: Don't really have a vision how it will look like in practice based on released data, but looking at current discussion I'd like to state that I am most interested in a centralized library/app list, dependency tracker and an easy way to get sources. Support for a popular build systems may be fine as a bonus, but only as an added feature, with no coupling. I'd hate to see a ruby gem (or similar) hell pushed as a D way. Packaging is best done (and should be) by OS package manager, not hundreds of languages-specific managers. Good language package manager in my opinion is just an information source for OS package builders. There are no package managers out of the box for Mac OS X or Windows. -- /Jacob Carlborg
Re: The DUB package manager
On Sunday, 17 February 2013 at 15:08:08 UTC, Jacob Carlborg wrote: There are no package managers out of the box for Mac OS X or Windows. Thus I admit that adding _possibility_ of getbuild in one box may be useful. But it makes no sense to make linux users suffer (by making it The Way to Do Things) because of design mistakes of other OSes. After all, as far as I am aware, Windows gets a package manager in form of application store in last released version, doesn't it?
Re: The DUB package manager
Am Sun, 17 Feb 2013 00:20:48 -0800 schrieb Jonathan M Davis jmdavisp...@gmx.com: On Sunday, February 17, 2013 09:12:00 Sönke Ludwig wrote: BTW, I think YAML as a superset of JSON is also a good contender with nice syntax features, but also much more complex. It's also whitespace-sensitive, which is downright evil IMHO. I'd take JSON over YAML any day. - Jonathan M Davis Are you sure? YAML 1.1 required whitespace after comma and in some more cases, but YAML 1.2 dropped that to be 100% compatible with JSON. If you write JSON you have valid YAML and you can write YAML that is valid JSON. http://en.wikipedia.org/wiki/YAML#JSON http://en.wikipedia.org/wiki/YAML#cite_note-9
Re: The DUB package manager
There are no package managers out of the box for Mac OS X or Windows. That's right, so we have to provide a custom way. Which also is necessary for non root installs and for experimentation and trying out (your own) packages. Nevertheless I think in the long run it should not be a problem to integrate with: http://openbuildservice.org/ in order to also provide packages for distributions? Ideally the build systems configuration contains everything needed to automatically create a spec file for Fedora, for example.
